Protocolul HTTP (HyperText Transfer Protocol) este un protocol la nivel de aplicație care comunică aplicațiile în cadrul sistemelor de informații distribuite, colaborative sau eterogene. Protocolul permite aplicațiilor să facă schimb de date prezentate într-o formă care poate fi citită de om.
După cum sugerează și numele, HTTP a fost inițial destinat să transfere așa-numitul hipertext între aplicații, care este un tip special de date creat în conformitate cu standardul HTML (HyperText Markup Language). Un document hipertext constă din date marcate folosind etichete HTML și este o combinație de text, imagini, hyperlinkuri și alte mijloace de prezentare a datelor. Hyperlinkurile, una dintre cele mai importante componente ale unui document HTML, sunt zone interactive care, atunci când se acționează asupra lor, produc date asociate cu hyperlinkul. Acest lucru permite unui utilizator care lucrează cu informații hipertext să navigheze într-un set de documente sau chiar pe întregul Internet, obținând informații de interes folosind hyperlinkuri contextuale.
Protocolul HTTP este un supliment la protocolul TCP și este un mijloc de control al conținutului datelor transmise. Spre deosebire de TCP, care nu a ținut cont de structura pachetelor transmise, HTTP încorporează metainformații în date, permițând destinatarului să interpreteze corect datele primite. Internetul global (numit și World Wide Web sau WWW) funcționează pe baza HTTP. Prima versiune a protocolului - HTTP/0.9 - avea capabilități destul de limitate, dar odată cu dezvoltarea activă a World Wide Web au apărut noi versiuni: HTTP/1.0 și HTTP/1.1, care fac posibilă controlul transmisiei nu numai informații hipertext prin rețele de calculatoare, dar și fișiere binare arbitrare: sunet, grafică, arhivă etc.
Datorită faptului că HTTP este o suprastructură peste protocolul TCP, există și două părți ale transferului de date: client și server.
Clientul inițiază conexiunea și solicită unele date sau servicii de la server. Clientul, de regulă, este un program numit browser, care permite atât afișarea informațiilor hipertext, cât și acceptarea fișierelor de alte formate. Pentru a obține unele informații de interes, clientul trimite o solicitare către server care conține o descriere a informațiilor solicitate.
Serverul atunci când transmite date prin HTTP este numit server web. Acest program prelucrează cererile de la clienți, transmitând datele solicitate sub formă de răspunsuri, conținând, pe lângă datele solicitate, metainformații care le descriu.
Obținerea de către utilizator a datelor de care este interesat constă în următorii pași:
Utilizatorul introduce adresa resursei de care este interesat în linia browserului.
Browserul, pe baza informațiilor primite de la utilizator, precum și luând în considerare setările acestuia și configurația sistemului de operare, generează o solicitare.
Browserul se conectează la un server, eventual situat pe un computer la distanță, și îi trimite o solicitare.
Serverul, analizând cererea, efectuează acțiunile necesare: generează un răspuns, inclusiv corpul documentului solicitat. Dacă este un document hipertext, acesta este încărcat dintr-un fișier sau generat dinamic printr-un script. Răspunsul include și informații despre datele pe care le conține.
Serverul trimite răspunsul către browser.
Browserul analizează răspunsul și fie salvează datele rezultate într-un fișier, fie, în cazul unui document hipertext, analizează etichetele HTML și afișează documentul pe ecran.
Trebuie remarcat faptul că programul client nu poate fi doar un browser, totuși, toți pașii, cu posibila excepție a primului, sunt efectuate în orice caz.
Trebuie remarcat faptul că aici luăm în considerare o conexiune directă a clientului la server care conține informațiile de interes, însă acest lucru nu este întotdeauna posibil din cauza diverselor circumstanțe. În acest caz, conexiunea se poate face prin unul sau mai multe puncte intermediare de conectare. Aceste puncte intermediare pot fi împărțite în trei grupe:
Serverele proxy (server-proxy) sunt un program intermediar care îndeplinește atât funcțiile unui client, cât și ale unui server în scopul de a crea cereri în numele altor clienți. Cererile sunt deservite de serverul proxy sau transmise acestuia cu modificările aduse acestora (caz în care serverul proxy se numește opac) sau fără modificări (caz în care serverul proxy se numește transparent). Un server proxy permite unui grup de computere să acționeze ca un singur client, care este adesea folosit atunci când se conectează rețele locale la Internet.
Gateway - ca un server proxy, transmite cereri, cu toate acestea, nu le schimb. Gateway-ul primește o solicitare de la client ca și cum ar fi un server care conține resursa solicitată. Astfel, clientul nu poate determina dacă se conectează prin gateway sau direct la serverul care conține resursa.
Tunnel este un program intermediar care menține o conexiune. Deși tunelul nu este considerat parte a transportului HTTP odată ce conexiunea este stabilită, conexiunea este de obicei inițiată printr-o solicitare HTTP. Tunelul își încheie funcționarea dacă cel puțin unul dintre participanții la schimbul de date închide conexiunea.
Pentru a menține funcționalitatea transferului de date la conectarea prin puncte intermediare, nu sunt necesare modificări la solicitări și răspunsuri, cu excepția cazului unui server proxy: în acest caz, cererea clientului trebuie să conțină câmpuri suplimentare. Totuși, din punctul de vedere al serverului, datele sunt schimbate direct cu clientul, prin urmare, nu apar modificări în cereri. Prin urmare, la elaborarea programului nu a fost luată în considerare posibilitatea conectării prin puncte intermediare.
Solicitarea trimisă de client către server servește la identificarea cu acuratețe a resursei solicitate și, de asemenea, conține informații necesare procesării corecte a cererii.
Structura cererii este formată din trei părți:
Șir de interogare
Bloc de antet
Linia de solicitare constă din trei câmpuri separate prin caractere spațiale (cod ASCII 20h, denumit în continuare SP) și se termină cu o combinație de două caractere: returnare transport (cod ASCII 0Dh, denumit în continuare CR) și avans de linie (cod ASCII 0Ah, denumit în continuare LF) . Elementele șirului de interogare sunt reprezentate de următoarele câmpuri:
Metodă - definește metoda de procesare aplicată resursei solicitate. În funcție de metoda specificată, formatul cererii poate fi diferit. Metode valabile:
În timpul dezvoltării programului a fost introdus suport doar pentru metoda GET, datorită faptului că tocmai această metodă o specifică browserul în cererea creată implicit.
URI (Universal Resource Identifier) resursa (URI de resurse) - indică locația resursei solicitate într-un format standardizat, adică este adresa resursei. Când se folosește metoda GET, acest șir poate include un set de parametri transmisi serverului sub formă de șiruri de format „nume_parametru = valoare_parametru”, despărțiți prin caractere ampersand „&”. Blocul de parametri este situat la sfârșitul șir URI și este separat de adresă prin semnul de întrebare `?".
Versiunea protocolului HTTP - în timpul dezvoltării programului a fost implementat suport pentru primirea cererilor corespunzătoare versiunilor 1.0 și 1.1, care corespund liniilor „HTTP/1.0” și respectiv „HTTP/1.1”.
Blocul antet care urmează liniei de interogare poate consta din unul sau mai multe anteturi:
Antetul cererii - conține câmpuri care servesc ca modificatori de solicitare și conțin informații despre cerere și configurația mașinii client.
Antet obiect - dacă cererea include un obiect (un set arbitrar de date), câmpurile acestui antet descriu obiectul, indicând formatul, codificarea și alți parametri ai acestuia.
Antet general - conține parametrii de serviciu necesari pentru a asigura corectitudinea transferului și pentru a permite servicii suplimentare, cum ar fi stocarea în cache.
Secțiunea antet se termină cu două perechi de caractere CR și LF, ceea ce facilitează stabilirea că cererea a fost primită, deoarece cererea în sine nu poate conține o astfel de combinație de caractere.
Răspunsul trimis de server către client poate fi generat doar prin procesarea cererii clientului. Conține o descriere a rezultatelor interogării și, dacă au fost solicitate date, include resursa solicitată.
Structura răspunsului constă din următoarele părți:
Bara de stare
Bloc de antet
Linia de stare constă din trei câmpuri separate prin caractere SP și conține secvența de caractere CR, LF la sfârșit. Elementele barei de stare:
Versiunea protocolului HTTP - programul dezvoltat folosește întotdeauna șirul „HTTP/1.1”.
Codul de stare este un cod numeric din trei caractere care identifică rezultatul unei solicitări. Deși standardul definește un set destul de mare de coduri de stare, următoarele coduri sunt utilizate în program:
- 200 - executare cu succes;
- 400 - cerere nevalidă;
- 401 - acces neautorizat;
- 404 - resursă negăsită;
- 405 - metoda nu se aplica;
- 505 - versiune HTTP neacceptată.
Expresie de motiv - o frază scurtă care explică codul de stare a execuției cererii. Standardul oferă un set standard de fraze, dar în program acest set a fost ușor modificat.
Blocul antet care urmează linia de stare poate consta din unul sau mai multe anteturi:
Antetul cererii
Titlul obiectului
Titlul general
Titlurile au fost discutate în detaliu în secțiunea 2.2.3.3.
Secțiunea antet se termină cu două perechi de caractere CR și LF, urmate de un set arbitrar de caractere - un obiect. Când programul rulează, astfel de obiecte pot fi doar documente hipertext în format HTML, generate dinamic de plug-in-uri.
Am lansat o nouă carte, Social Media Content Marketing: How to Get Inside Your Followers' Heads and Make them to Love with Your Brand.
HTTP este ceea ce permite transferul datelor. Inițial, a fost creat pentru trimiterea și primirea documentelor care conțin linkuri în interior pentru a face tranziția către resurse terțe.
Abrevierea este „HyperText Transfer Protocol”, care tradus înseamnă „protocol de transfer”. HTTP aparține grupului de straturi de aplicații pe baza specificului utilizat de OSI.
Pentru a înțelege mai bine ce înseamnă HTTP, să ne uităm la o analogie simplă. Să ne imaginăm că comunici cu un străin pe o rețea de socializare. Îți trimite un mesaj în engleză, îl primești. Dar nu puteți înțelege conținutul pentru că nu vorbiți bine limba. Pentru a descifra mesajul, utilizați un dicționar. După ce ați înțeles esența, îi răspundeți străinului în rusă și trimiteți răspunsul. Străinul primește răspunsul și, cu ajutorul unui traducător, descifrează mesajul. Pentru a simplifica întregul mecanism, protocoalele Internet HTTP îndeplinesc funcția de traducător. Cu ajutorul lor, browserul poate traduce conținutul criptat al paginilor web și poate afișa conținutul acestora.
Pentru ce este HTTP?
Protocolul HTTP este folosit pentru a schimba informații folosind un model client-server. Clientul compune și transmite o cerere către server, apoi serverul o prelucrează și o analizează, după care se creează un răspuns și se trimite utilizatorului. La sfârșitul acestui proces, clientul lansează o nouă comandă și totul se repetă.
Astfel, protocolul HTTP vă permite să faceți schimb de informații între diverse aplicații de utilizator și servere web speciale, precum și să vă conectați la resurse web (de obicei browsere). Astăzi, protocolul descris asigură funcționarea întregii rețele. Protocolul de transfer de date HTTP este, de asemenea, utilizat pentru a transfera informații peste alte protocoale de nivel inferior, de exemplu, WebDAV sau SOAP. În acest caz, protocolul este un mijloc de transport. Multe programe se bazează, de asemenea, pe HTTP ca instrument principal pentru schimbul de informații. Datele sunt prezentate în diferite formate, de exemplu, JSON sau XML.
HTTP este un protocol pentru schimbul de informații printr-o conexiune IP/TCP. De obicei, serverul folosește portul TCP 80 în acest scop. Dacă portul nu este specificat, software-ul client va folosi implicit portul 80 de tip TCP. În unele cazuri, pot fi utilizate alte porturi.
Protocolul HTTP folosește o schemă de criptare simetrică și utilizează criptosisteme simetrice. Criptosistemele simetrice implică utilizarea aceleiași chei pentru a cripta și decripta informațiile.
Care este diferența dintre HTTP și HTTPS
Diferența poate fi detectată chiar și din decodarea abrevierilor. HTTPS înseamnă Hypertext Transfer Protocol Security. Astfel, HTTP este un protocol independent, iar HTTPS este o extensie pentru a-l proteja. HTTP transmite informații neprotejate, în timp ce HTTPS oferă protecție criptografică. Acest lucru este valabil mai ales pentru resursele cu autorizare responsabilă. Acestea ar putea fi rețele sociale sau site-uri cu sisteme de plată.
Care sunt pericolele transmiterii datelor neprotejate? Un program interceptor le poate transfera atacatorilor în orice moment. HTTPS are o organizare tehnică complexă, care vă permite să protejați în mod fiabil informațiile și să eliminați posibilitatea accesului neautorizat la acestea. Diferența constă în porturi. HTTPS funcționează de obicei pe portul 443.
Astfel, HTTP este folosit pentru transferul de date, iar HTTPS permite transferul securizat de date folosind criptarea și autorizarea pe resurse cu un nivel ridicat de securitate.
Funcționalitate suplimentară
HTTP este bogat în funcționalități și este compatibil cu diferite extensii. Specificația 1.1 folosită astăzi permite ca antetul Upgrade să fie utilizat pentru a comuta și a lucra prin alte protocoale atunci când se schimbă date. Pentru a face acest lucru, utilizatorul trebuie să trimită o cerere către server cu acest antet. Dacă serverul trebuie să treacă la un anumit schimb folosind un alt protocol, acesta returnează o solicitare către client, care afișează starea „426 Upgrade Required”.
Această caracteristică este relevantă în special pentru schimbul de informații prin WebSocket (are specificația RFC 6455, permițându-vă să faceți schimb de date în orice moment, fără solicitări HTTP inutile). Pentru a migra la WebSocket, un utilizator trimite o solicitare cu antetul Upgrade și valoarea „websocket”. Apoi, serverul răspunde cu „101 Switching Protocols”. După acest moment, începe transferul de informații prin WebSocket.
Vă prezentăm o descriere a principalelor aspecte ale protocolului HTTP - un protocol de rețea care, de la începutul anilor 90 până în prezent, permite browserului dvs. să încarce pagini web. Acest articol a fost scris pentru cei care abia încep să lucreze cu rețele de calculatoare și să dezvolte aplicații de rețea și care încă le este greu să citească singuri specificațiile oficiale.
HTTP- un protocol de transfer de date utilizat pe scară largă, destinat inițial transferului de documente hipertext (adică documente care pot conține link-uri care permit navigarea către alte documente).
Abrevierea HTTP reprezintă Protocolul de transfer hipertext, „protocol de transfer hipertext”. Conform specificației OSI, HTTP este un protocol de aplicație (superior, al 7-lea). Versiunea actuală a protocolului, HTTP 1.1, este descrisă în specificația RFC 2616.
Protocolul HTTP implică utilizarea unei structuri de transfer de date client-server. Aplicația client generează o cerere și o trimite către server, după care software-ul server procesează cererea, generează un răspuns și îl trimite înapoi clientului. Aplicația client poate continua apoi să trimită alte solicitări, care vor fi procesate în același mod.
O sarcină care este rezolvată în mod tradițional folosind protocolul HTTP este schimbul de date între o aplicație de utilizator care accesează resurse web (de obicei un browser web) și un server web. În prezent, datorită protocolului HTTP operează World Wide Web.
HTTP este adesea folosit ca protocol de transport pentru alte protocoale de nivel de aplicație, cum ar fi SOAP, XML-RPC și WebDAV. În acest caz, se spune că protocolul HTTP este folosit ca „transport”.
API-ul multor produse software implică și utilizarea HTTP pentru transferul de date - datele în sine pot fi în orice format, de exemplu, XML sau JSON.
De obicei, transferul de date HTTP se realizează prin conexiuni TCP/IP. În acest caz, software-ul server utilizează de obicei portul TCP 80 (și, dacă portul nu este specificat explicit, atunci software-ul client utilizează de obicei portul 80 în mod implicit pentru deschiderea conexiunilor HTTP), deși poate folosi oricare altul.
Cum se trimite o solicitare HTTP?
Cel mai simplu mod de a înțelege protocolul HTTP este să încercați să accesați manual o resursă web. Imaginează-ți că ești browser și ai un utilizator care își dorește foarte mult să citească articole de Anatoly Alizar.Să presupunem că a introdus următoarele în bara de adrese:
Http://alizar.habrahabr.ru/
În consecință, tu, ca browser web, acum trebuie să te conectezi la serverul web de la alizar.habrahabr.ru.
Pentru a face acest lucru, puteți utiliza orice utilitar adecvat de linie de comandă. De exemplu, telnet:
Telnet alizar.habrahabr.ru 80
Permiteți-mi să clarific imediat că, dacă vă răzgândiți brusc, apăsați Ctrl + „]” și apoi introduceți - acest lucru vă va permite să închideți conexiunea HTTP. Pe lângă telnet, puteți încerca nc (sau ncat) - în funcție de gusturi.
După ce vă conectați la server, trebuie să trimiteți o solicitare HTTP. Acest lucru, apropo, este foarte ușor - cererile HTTP pot consta doar din două linii.
Pentru a genera o cerere HTTP, trebuie să compuneți o linie de pornire și, de asemenea, să setați cel puțin un antet - acesta este antetul Host, care este obligatoriu și trebuie să fie prezent în fiecare solicitare. Faptul este că conversia unui nume de domeniu la o adresă IP se realizează pe partea clientului și, în consecință, atunci când deschideți o conexiune TCP, serverul la distanță nu are nicio informație despre adresa care a fost folosită pentru conexiune: ar putea fi, de exemplu, adresa alizar.habrahabr.ru, habrahabr.ru sau m.habrahabr.ru - și în toate aceste cazuri răspunsul poate diferi. Cu toate acestea, de fapt, în toate cazurile conexiunea la rețea este deschisă cu nodul 212.24.43.44, și chiar dacă inițial la deschiderea conexiunii nu a fost specificată această adresă IP, ci un nume de domeniu, serverul nu este informat despre acest lucru în în orice fel - și de aceea această adresă este necesară trecerea în antetul Gazdă.
Linia de cerere de pornire (inițială) pentru HTTP 1.1 este compusă conform următoarei scheme:
De exemplu (o astfel de linie de pornire poate indica faptul că pagina principală a site-ului este solicitată):
Și, desigur, nu uitați că orice tehnologie devine mult mai simplă și mai clară atunci când începeți să o utilizați.
Mult succes si invatare fructuoasa!
Etichete: Adăugați etichete
HTTP(HyperText Transfer Protocol - „protocol de transfer hipertext”) este un protocol la nivel de aplicație pentru transferul de date (inițial sub formă de documente hipertext). Baza HTTP este tehnologia client-server, adică presupune existența consumatorilor (clienților) care inițiază o conexiune și trimit o solicitare, iar furnizorii (serverele) care așteaptă o conexiune pentru a primi o solicitare, efectuează operațiunile necesare. acțiuni și returnează un mesaj cu rezultatul.
HTTP este, de asemenea, folosit ca „transport” pentru alte protocoale de nivel de aplicație, cum ar fi SOAP, XML-RPC, WebDAV.
Obiectul principal de manipulare în HTTP este resursa indicată de URI (Uniform Resource Identifier) în cererea clientului. De obicei, aceste resurse sunt fișiere stocate pe server, dar pot fi obiecte logice sau ceva abstract. O caracteristică a protocolului HTTP este capacitatea de a specifica în cerere și răspuns metoda de reprezentare a aceleiași resurse în funcție de diferiți parametri: format, codificare, limbă etc. Este datorită capacității de a specifica metoda de codificare a unui mesaj. că clientul și serverul pot face schimb de date binare, deși acest protocol este text.
HTTP este un protocol de nivel de aplicație, similar cu acesta este FTP și SMTP - Simple Mail Transfer Protocol. Mesajele sunt schimbate conform schemei obișnuite de cerere-răspuns. HTTP utilizează URI globale pentru a identifica resursele. Spre deosebire de multe alte protocoale, HTTP este apatrid. Aceasta înseamnă că nu există persistență a stării intermediare între perechile cerere-răspuns. Componentele care utilizează HTTP pot menține în mod independent informațiile de stare asociate cu cererile și răspunsurile recente. Browserul care trimite solicitările poate urmări întârzierile de răspuns. Serverul poate stoca adresele IP și poate solicita antetele celor mai recent clienți. Cu toate acestea, protocolul în sine nu este la curent cu solicitările și răspunsurile anterioare, nu oferă sprijin intern de stat și nu i se impun astfel de cerințe.
Extensibilitate
Capacitățile protocolului sunt extinse cu ușurință prin introducerea propriilor anteturi, menținând în același timp compatibilitatea cu alți clienți și servere. Ei vor ignora anteturile necunoscute pentru ei, dar în același timp pot obține funcționalitatea necesară pentru rezolvarea unor probleme specifice.
HTTP/1.1- versiunea actuală a protocolului. Nou în această versiune a fost un mod „conexiune persistentă”: o conexiune TCP poate rămâne deschisă după trimiterea unui răspuns la o solicitare, permițând trimiterea mai multor cereri într-o singură conexiune. Clientul este acum obligat să trimită informații despre numele gazdei la care accesează, ceea ce a făcut posibilă organizarea găzduirii virtuale mai ușor.
HTTP nu stochează informații despre tranzacții, așa că trebuie să o luați de la capăt la următoarea tranzacție. Avantajul este că serverul HTTP poate deservi mult mai mulți clienți într-o anumită perioadă de timp, deoarece suprasarcina de urmărire a sesiunilor de la o conexiune la alta este eliminată. Există un dezavantaj: programele CGI mai complexe trebuie să utilizeze câmpuri de intrare ascunse sau instrumente externe, cum ar fi cookie-urile, pentru a stoca informații despre tranzacție.
Metode de solicitare HTTP
Metoda HTTP- o secvență de orice caractere, cu excepția controalelor și a separatorilor, care indică operația principală asupra resursei. De obicei, metoda este un cuvânt scurt englezesc scris cu majuscule. Vă rugăm să rețineți că numele metodei face distincție între majuscule și minuscule.
Fiecare server trebuie să accepte cel puțin metodele GET și HEAD. Dacă serverul nu recunoaște metoda specificată de client, ar trebui să returneze starea 501 (Neimplementat). Dacă serverul cunoaște metoda, dar aceasta nu este aplicabilă unei anumite resurse, atunci este returnat un mesaj cu codul 405 (Metoda nu este permisă). În ambele cazuri, serverul TREBUIE să includă un antet Allow în mesajul de răspuns cu o listă de metode acceptate.
Pe lângă metodele GET și HEAD, este adesea folosită metoda POST.
-
Solicitare HTTP, răspuns, anteturi de entitate (parametri)
Toate anteturile din protocolul HTTP sunt împărțite în patru grupuri principale (se recomandă trimiterea antetelor către destinatar în ordinea de mai jos):
Anteturi generale(Anteturi principale) - trebuie incluse în orice mesaj client și server.
Antete de solicitare(Anteturi de solicitare) - utilizate numai în cererile clientului.
Antete de răspuns(Anteturi de răspuns) - numai pentru răspunsurile de la server.
Anteturi de entitate(Entity Headers) - însoțește fiecare entitate de mesaj. Anteturile de entitate sunt separate într-o clasă separată, pentru a nu le confunda cu anteturile de solicitare sau anteturile de răspuns la transferul de conținuturi multiple (MIME).
Toate anteturile necesare pentru ca HTTP să funcționeze sunt descrise în RFC-urile principale. Dacă este necesar, vă puteți crea propriile titluri. În mod tradițional, numele unor astfel de anteturi suplimentare sunt prefixate cu „X-” pentru a evita conflictele de nume cu cele posibile existente.
Liniile de după linia principală de solicitare (GET /index.html HTTP/1.1) au următorul format: Parametru: valoare. Așa sunt setați parametrii de solicitare. Acest lucru este opțional; toate liniile de după linia de interogare principală pot lipsi; în acest caz, serverul acceptă valoarea lor implicit sau pe baza rezultatelor solicitării anterioare (când lucrează în modul Conexiune: Keep-Alive).
Parametru Conexiune(conexiune) - poate lua valorile Keep-Alive and close. În HTTP 1.0, transmiterea de către server a datelor solicitate este urmată de o deconectare de la client, iar tranzacția este considerată finalizată dacă nu este trimis antetul Connection: Keep Alive. În HTTP 1.1, serverul nu închide conexiunea în mod implicit și clientul poate trimite alte solicitări. Deoarece multe documente au alte documente încorporate — imagini, cadre, applet-uri etc. — acest lucru economisește timp și costuri pentru client, care altfel ar trebui să se conecteze de mai multe ori la același server pentru a obține o singură pagină. Astfel, în HTTP 1.1, o tranzacție poate face buclă până când clientul sau serverul închide în mod explicit conexiunea.
Parametru Agent utilizator- valoarea este „codul” browserului.
Parametru Accept- o listă de tipuri de conținut acceptate de browser în ordinea preferințelor pentru acest browser.
Parametru Gazdă- numele domeniului de la care se solicită resursa. Util dacă serverul are mai multe servere virtuale sub aceeași adresă IP. În acest caz, numele domeniului virtual este determinat de acest câmp.
Parametru Modificat ultima dată(ultima modificare) (W3C Last-Modified) - data și ora ultimei modificări a documentului. Folosind-o, clientul, asemănător cu cazul ETag-ului, poate contacta serverul cu o solicitare „If-Modified-Since” - în acest caz, serverul trebuie să compare data ultimei modificări a copiei stocate pe client cu cea reală. data ultimei modificări. Dacă se potrivesc, aceasta înseamnă că copia din memoria cache a clientului nu este învechită și nu este necesară o re-descărcare (codul de răspuns „304 Not Modified”). Last-Modified este, de asemenea, necesar pentru prelucrarea corectă a site-ului de către roboți, care folosesc informații despre data modificării paginilor pentru a sorta rezultatele căutării după dată, precum și pentru a determina frecvența actualizării site-ului dumneavoastră.
Pentru documentele SSI, Apache va emite „Last-Modified” dacă este specificată directiva „XBitHack full” (de exemplu, în fișierul .htaccess)
Parametru ETag(etichetă obiect) - introdus în HTTP 1.1 (W3C ETag). ETag este folosit pentru a atribui fiecărei pagini un identificator unic, a cărui valoare se modifică atunci când pagina (documentul) este schimbată. ETag este un hash („amprentă”) al octeților documentului; dacă chiar și un octet din document se modifică, atunci ETag-ul se va schimba. ETag este utilizat atunci când memorarea în cache a unui document. Acest antet este stocat pe client, iar în cazul accesului repetat la document, permite browserului să contacteze serverul cu o solicitare „If-None-Match”, iar serverul trebuie să determine după valoarea etichetei ETag dacă documentul (pagina) s-a schimbat, iar dacă nu, răspundeți cu codul „304 Not Modified”.
Parametru Expiră(expiration)(W3C Expires) - îi spune browserului în ce perioadă de timp poate presupune că copia paginii din cache este proaspătă și nu contactează serverul cu solicitări deloc. Acest lucru este convenabil pentru fișierele despre care știți sigur că nu se vor schimba în următoarea oră/zi/lună: imaginea de fundal a unei pagini, de exemplu.
Alte anteturi HTTP:
HTTP_X_COMING_FROM
HTTP_COMING_FROM
HTTP_X_CLUSTER_CLIENT_IP
HTTP_XROXY_CONNECTION
HTTP_PROXY_CONNECTION
HTTP_USERAGENT_VIA - proxy
HTTP_X_FORWARDED_FOR
HTTP_X_FORWARDED
HTTP_FORWARDED_FOR
Exemplu de analiză a cererii HTTP
O cerere HTTP constă din trei părți: o linie de solicitare (răspuns), o secțiune antet, urmată de un corp opțional. Anteturile sunt text simplu, fiecare antet fiind separat de următorul printr-un caracter de linie nouă (\r\n), în timp ce corpul poate fi text sau date binare. Corpul este separat de anteturi prin două linii noi.
Antetul cererii este format din linia principală (prima) a cererii și liniile ulterioare care clarifică cererea în linia principală. Este posibil să lipsească și rândurile ulterioare.
Clientul inițiază o tranzacție după cum urmează:
Clientul comunică cu serverul pe numărul portului alocat, numărul oficial implicit al portului este 80. Clientul trimite apoi o cerere de document specificând metoda, adresa documentului și numărul versiunii HTTP. De exemplu, în linia principală de solicitare GET /index.html HTTP/1.1
Metoda GET este folosită pentru a solicita documentul index.html folosind versiunea HTTP 1.1.
Clientul trimite informații de antet (opțional; antetul gazdei este necesar) pentru a spune serverului informațiile sale de configurare și informații despre formatele de document pe care le poate accepta. Toate informațiile din antet sunt listate rând cu rând, fiecare linie conținând un nume și o valoare. De exemplu, următorul antet trimis de un client conține numele și numărul versiunii acestuia, precum și informații despre unele dintre tipurile de documente preferate ale clientului: Gazdă: list.mail.ru User-Agent: Mozilla/5.0 (Ubuntu; X11; Linux x86_64; rv :8.0) Gecko/20100101 Firefox/8.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Antetul se termină cu o linie goală.
După ce a trimis o solicitare și anteturi, clientul poate trimite date suplimentare, de exemplu, pentru scripturi CGI.
Serverul răspunde la cererea clientului după cum urmează:
Prima parte a răspunsului serverului este linia de stare, care conține trei câmpuri: versiune HTTP, cod de stare și descriere. Câmpul versiune conține numărul versiunii HTTP pe care acest server îl folosește pentru a trimite răspunsul. Codul de stare este un număr din trei cifre care indică rezultatul procesării de către server a cererii clientului. Descrierea care urmează codului de stare este pur și simplu text care poate fi citit de om care explică codul de stare. De exemplu, bara de stare HTTP/1.1 304 Nemodificat
indică faptul că serverul folosește versiunea HTTP 1.1 pentru a răspunde. Cod de stare 304 înseamnă că clientul a solicitat documentul folosind metoda GET, a folosit antetul If-Modified-Since sau If-None-Match, iar documentul nu s-a schimbat de la momentul specificat.
După linia de stare, serverul trimite către client informații de antet care conțin informații despre server însuși și documentul solicitat. Mai jos este un exemplu de antet: Data: joi, 15 decembrie 2011 09:34:15 GMT Server: Apache/2.2.21 (Debian) X-Powered-By: PHP/5.3.8-1+b1 Expiră: joi, 19 nov. 1981 08:52:00 GMT Cache-Control: fără stocare, fără cache, revalidare obligatorie, post-verificare=0, pre-verificare=0 Pragma: fără cache Variare: Acceptare codificare Codificare conținut: gzip Keep - Alive: timeout=5, max=100 Conexiune: Keep-Alive Content-Type: text/html; set de caractere=utf-8
Antetul se termină cu o linie goală.
Dacă solicitarea clientului are succes, atunci datele solicitate sunt trimise. Aceasta poate fi o copie a unui fișier sau rezultatul unui program CGI. Dacă cererea clientului nu poate fi satisfăcută, se transmit date suplimentare sub forma unei explicații ușor de utilizat a motivelor pentru care serverul nu a putut îndeplini cererea.
Cod de stare HTTP
Cod de stare HTTP face parte din prima linie a răspunsului serverului. Este un număr întreg de trei cifre. Prima cifră indică clasa afecțiunii. Codul de răspuns este de obicei urmat de o frază explicativă în limba engleză, separată de un spațiu, care explică persoanei motivul acestui răspuns particular.
Este posibil ca clientul să nu cunoască toate codurile de stare, dar trebuie să răspundă în funcție de clasa codului. În prezent, există cinci clase de coduri de stare:
200 OK(Amenda). Introdus în HTTP/1.0. Solicitare de resurse reușită. Dacă clientul a solicitat date, acestea se găsesc în antetul și/sau corpul mesajului.
1xx: informativ. Codurile de stare informaționale care îi spun clientului că serverul este în proces de procesare a unei cereri. Reacția clientului la aceste coduri nu este necesară;
2xx: Succes.
302 Găsit(Găsite). Introdus în HTTP/1.0. Documentul solicitat este disponibil temporar la un alt URI specificat în antetul din câmpul Locație.
404 Nu a fost gasit. Introdus în HTTP/1.0. Serverul a înțeles cererea, dar nu a găsit o resursă corespunzătoare la URI-ul specificat.
3xx: Redirecționare. Codurile clasa 3xx îi spun clientului că trebuie făcută o cerere diferită (de obicei către un alt URI) pentru ca operațiunea să reușească. Din această clasă, cinci coduri 301, 302, 303, 305 și 307 se referă direct la redirecționări (redirecționare). Adresa la care clientul ar trebui să facă cererea este indicată de server în antetul Locație. Mulți clienți, atunci când redirecționează cu codurile 301 și 302, aplică în mod greșit metoda GET la a doua resursă, în ciuda faptului că cererea către prima a fost cu o metodă diferită. Pentru a evita neînțelegerile, în versiunea HTTP/1.1 au fost introduse codurile 303 și 307 în loc de 302. Trebuie să schimbați metoda de solicitare doar dacă serverul a răspuns cu 303. În alte cazuri, faceți următoarea cerere folosind metoda originală.
4xx: Eroare client. Clasa de cod 4xx este destinată să indice erorile din partea clientului. Când utilizați toate metodele, cu excepția HEAD, serverul trebuie să returneze utilizatorului o explicație hipertext în corpul mesajului.
5xx: Eroare de server
Legături înrudite HTTP 1.1
HTTP/2
HTTP/2 (inițial HTTP/2.0) este a doua versiune majoră a protocolului de rețea HTTP. Protocolul se bazează pe SPDY (protocol compatibil HTTP dezvoltat de Google).
Protocolul HTTP/2 este binar. În comparație cu standardul anterior, metodele de împărțire a datelor în fragmente și transportarea acestora între server și client au fost modificate.
În HTTP/2, serverul are dreptul de a trimite conținut care nu a fost încă solicitat de client. Acest lucru va permite serverului să trimită imediat fișiere suplimentare de care browserul va avea nevoie pentru a afișa paginile, fără ca browserul să fie nevoit să analizeze pagina principală și să solicite completările necesare.
.) Datorită capacității de a specifica modul în care este codificat un mesaj, clientul și serverul pot face schimb de date binare, deși acest protocol este bazat pe text.
Servere proxy
Istoria dezvoltării
HTTP/0.9
Pe lângă metoda obișnuită GET, există și o distincție. Solicitările GET condiționate conțin anteturi If-Modified-Since, If-Match, If-Range și similare. GET-urile parțiale conțin Range în cerere. Procedura de executare a unor astfel de solicitări este definită separat de standarde.
CAP
Similar cu metoda GET, cu excepția faptului că nu există niciun corp în răspunsul serverului. Solicitarea HEAD este utilizată de obicei pentru a prelua metadate, a verifica existența unei resurse (validare URL) și pentru a vedea dacă aceasta s-a schimbat de la ultima accesare.
Anteturile de răspuns pot fi stocate în cache. Dacă metadatele unei resurse nu se potrivesc cu informațiile corespunzătoare din memoria cache, copia resursei este marcată ca învechită.
POST
Folosit pentru a transfera datele utilizatorului către o resursă specificată. De exemplu, pe bloguri, vizitatorii pot introduce, de obicei, comentarii la postări într-un formular HTML, după care acestea sunt POSTATE pe server și plasate pe pagină. În acest caz, datele transmise (în exemplul cu bloguri, textul comentariului) sunt incluse în corpul solicitării. În mod similar, folosind metoda POST, fișierele sunt de obicei încărcate pe server.
Spre deosebire de metoda GET, metoda POST nu este considerată idempotentă, ceea ce înseamnă că repetarea acelorași solicitări POST de mai multe ori poate returna rezultate diferite (de exemplu, după ce este trimis fiecare comentariu, va apărea o copie a acelui comentariu).
Dacă rezultatul execuției este 200 (Ok), în corpul răspunsului ar trebui să fie inclus un mesaj despre finalizarea cererii. Dacă o resursă a fost creată, serverul TREBUIE să returneze un răspuns 201 (Creat) cu URI-ul noii resurse în antetul Locație.
Mesajul de răspuns al serverului la metoda POST nu este stocat în cache.
A PUNE
Folosit pentru a încărca conținutul cererii la URI-ul specificat în cerere. Dacă o resursă nu există la URI-ul dat, serverul o creează și returnează starea 201 (Creată). Dacă resursa a fost modificată, serverul returnează 200 (Ok) sau 204 (Fără conținut). Serverul NU TREBUIE să ignore anteturile Content-* nevalide trimise de client împreună cu mesajul. Dacă oricare dintre aceste anteturi nu poate fi recunoscut sau nu este valabil în condițiile actuale, atunci trebuie returnat un cod de eroare de 501 (Neimplementat).
Diferența fundamentală dintre metodele POST și PUT este înțelegerea scopului URI-ului resursei. Metoda POST presupune că URI-ul specificat va procesa conținutul trimis de client. Prin utilizarea PUT, clientul presupune că conținutul descărcat se potrivește cu resursa situată la URI-ul dat.
Mesajele de răspuns ale serverului la metoda PUT nu sunt stocate în cache.
PLASTURE
Similar cu PUT, dar se aplică doar unui fragment din resursă.
ȘTERGE
Șterge resursa specificată.
URMĂ
Returnează solicitarea primită, astfel încât clientul să poată vedea ce informații adaugă sau modifică serverele intermediare în cerere.
LEGĂTURĂ
Stabilește o conexiune între resursa specificată și altele.
DECONECTARE
Îndepărtează conexiunea resursei specificate cu altele.
CONECTAȚI
Convertește o conexiune de solicitare într-un tunel TCP/IP transparent, de obicei pentru a facilita stabilirea unei conexiuni SSL securizate printr-un proxy necriptat.
Coduri de stare
Codul de stare face parte din prima linie a răspunsului serverului. Reprezintă un număr întreg de trei cifre arabe. Prima cifră indică clasa afecțiunii. Codul de răspuns este de obicei urmat de o frază explicativă în limba engleză, separată de un spațiu, care explică persoanei motivul acestui răspuns particular. Exemple:
201 Pagina web creată 403 Acces permis numai utilizatorilor înregistrați 507 Stocare insuficientă
Clientul învață din codul de răspuns despre rezultatele solicitării sale și stabilește ce acțiuni să întreprindă în continuare. Setul de coduri de stare este un standard și sunt descrise în RFC-urile corespunzătoare. Introducerea de noi coduri ar trebui făcută numai după acordul cu IETF. Este posibil ca clientul să nu cunoască toate codurile de stare, dar trebuie să răspundă în funcție de clasa codului.
În prezent, există cinci clase de coduri de stare.
1xx Informațional (rusă) Informațional)Această clasă conține coduri care informează despre procesul de transfer. În HTTP/1.0, mesajele cu astfel de coduri ar trebui ignorate. În HTTP/1.1, clientul trebuie să fie pregătit să accepte această clasă de mesaje ca răspuns normal, dar nu trebuie să trimită nimic către server. Mesajele în sine de la server conțin doar linia de început a răspunsului și, dacă este necesar, câteva câmpuri de antet specifice răspunsului. Serverele proxy trebuie să trimită astfel de mesaje mai departe de la server către client.
2xx Success (rusă) Succes)Mesajele acestei clase informează despre cazurile de acceptare și procesare cu succes a unei cereri de client. În funcție de stare, serverul poate transmite și anteturile și corpul mesajului.
Redirecționare 3xx (rusă) Redirecționare )Codurile din clasa 3xx îi spun clientului că, pentru a finaliza cu succes operația, este necesar să se facă o altă solicitare (de obicei către un alt URI). Din această clasă, cinci coduri , , , și se referă direct la redirecționări (redirecționare). Serverul specifică adresa la care clientul ar trebui să facă cererea în antetul Locație. Cu toate acestea, este posibil să se utilizeze fragmente în URI-ul țintă.
Eroare client 4xx (rusă) Eroare client)Clasa de cod 4xx este destinată să indice erorile din partea clientului. Când utilizați toate metodele, cu excepția HEAD, serverul trebuie să returneze utilizatorului o explicație hipertext în corpul mesajului.
Pentru a reține valorile codurilor de la 400 la 417, există tehnici mnemonice ilustrative
Eroare server 5xx (rusă) Eroare de server)Codurile 5xx sunt alocate pentru cazurile de operare nereușită din vina serverului. Pentru toate situațiile, altele decât utilizarea metodei HEAD, serverul trebuie să includă în corpul mesajului o explicație pe care clientul o va afișa utilizatorului.
Titluri
Conținutul mesajului
Corpul mesajului HTTP (corpul mesajului), dacă este prezent, este utilizat pentru a transmite corpul obiectului asociat cu cererea sau răspunsul. Corpul mesajului (corpul mesajului) diferă de corpul entității numai atunci când se aplică codificarea transferului, așa cum este indicat de câmpul antet Transfer-Encoding.
Corpul mesajului = corp-entitate |
Câmpul Transfer-Encoding trebuie utilizat pentru a indica orice codificare de transfer aplicată de aplicație pentru a se asigura că mesajul este transmis în siguranță și corect. Câmpul Transfer-Encoding este o proprietate a mesajului, nu a obiectului și, prin urmare, poate fi adăugat sau eliminat de orice aplicație din lanțul de cerere/răspuns.
Regulile care guvernează dacă un corp de mesaj este acceptabil într-un mesaj sunt diferite pentru cereri și răspunsuri.
Prezența unui corp de mesaj într-o solicitare este indicată prin adăugarea unui câmp de antet Content-Length sau Transfer-Encoding la anteturile cererii. Un corp de mesaj (corp de mesaj) POATE fi adăugat la o cerere numai atunci când metoda de solicitare permite un corp de entitate.
Dacă un mesaj-corp este sau nu inclus în mesajul de răspuns depinde atât de metoda de solicitare, cât și de codul de stare a răspunsului. Toate răspunsurile la o solicitare cu metoda HEAD nu trebuie să includă un corp de mesaj, chiar dacă sunt prezente câmpuri de antet de entitate pentru a face să creadă că entitatea este prezentă. Niciun răspuns cu codurile de stare 1xx (Informațional), 204 (Fără conținut) și 304 (Nemodificat) trebuie să conțină un corp de mesaj. Toate celelalte răspunsuri conțin un corp de mesaj, chiar dacă are lungime zero.
Exemple de dialog HTTP
Solicitare GET obișnuită
Există două tipuri principale de aprobări:
- Gestionat de server Controlat de server).
- Client gestionat Condus de agent).
Ambele tipuri sau fiecare dintre ele separat pot fi utilizate simultan.
Specificația principală a protocolului (RFC 2616) evidențiază și așa-numita negociere transparentă. Negociere transparentă) ca opțiune preferată pentru combinarea ambelor tipuri. Cel din urmă mecanism nu trebuie confundat cu tehnologia independentă Transparent Content Negotiation (TCN, rusă. Aprobare transparentă a conținutului , vezi RFC 2295), care nu face parte din protocolul HTTP, dar poate fi folosit cu acesta. Ambele au diferențe semnificative în ceea ce privește principiul de funcționare și însuși sensul cuvântului „transparent”. În specificația HTTP, transparența înseamnă că procesul este invizibil pentru client și server, iar în tehnologia TCN, transparența înseamnă disponibilitatea unei liste complete de opțiuni de resurse pentru toți participanții la procesul de livrare a datelor.
Administrat de server
Dacă există mai multe versiuni ale unei resurse, serverul poate analiza anteturile de solicitare ale clientului pentru a produce ceea ce consideră că este cea mai potrivită versiune. Principalele antete analizate sunt Accept, Accept-Charset, Accept-Encoding, Accept-Languages și User-Agent. Este recomandabil ca serverul să includă un antet Vary în răspuns care indică parametrii prin care diferă conținutul URI-ului solicitat.
Locația geografică a clientului poate fi determinată de adresa IP de la distanță. Acest lucru este posibil datorită faptului că adresele IP, cum ar fi numele de domenii, sunt înregistrate la o anumită persoană sau organizație. La înregistrare, specificați regiunea în care va fi utilizat spațiul de adresă dorit. Aceste date sunt disponibile public, iar pe Internet puteți găsi bazele de date corespunzătoare distribuite gratuit și module software gata făcute pentru a lucra cu acestea (ar trebui să vă concentrați pe cuvintele cheie „Geo IP”).
Trebuie amintit că această metodă este capabilă să determine locația la maximum un oraș (de aici se determină țara). În acest caz, informațiile sunt relevante doar în momentul înregistrării spațiului de adresă. De exemplu, dacă un furnizor din Moscova înregistrează o serie de adrese care indică Moscova și începe să ofere acces clienților din cea mai apropiată regiune Moscova, atunci abonații săi pot observa pe unele site-uri că sunt din Moscova și nu din Krasnogorsk sau Dzerzhinsky.
Negocierea bazată pe server are mai multe dezavantaje:
- Serverul presupune doar care opțiune este cea mai preferată pentru utilizatorul final, dar nu poate ști exact ce este necesar în acest moment (de exemplu, o versiune în rusă sau engleză).
- Au fost trimise o mulțime de anteturi de grup Accept, dar puține resurse cu mai multe opțiuni. Din acest motiv, echipamentul suferă o sarcină excesivă.
- Cache-ul partajat este limitat în capacitatea sa de a produce același răspuns la solicitări identice de la diferiți utilizatori.
- Trecerea antetelor Accept poate dezvălui, de asemenea, unele informații despre preferințele sale, cum ar fi limbile utilizate, browser, codificare.
Condus de client
În acest caz, tipul de conținut este determinat doar de partea clientului. Pentru a face acest lucru, serverul returnează cu codul de stare 300 (Alegeri multiple) sau 406 (Inacceptabil) o listă de opțiuni din care utilizatorul o selectează pe cea corespunzătoare. Reconcilierea bazată pe client este bună atunci când conținutul variază în moduri obișnuite (cum ar fi limba și codificarea) și se utilizează un cache public.
Principalul dezavantaj este încărcarea suplimentară, deoarece trebuie să faceți o cerere suplimentară pentru a obține conținutul dorit.
Aprobare transparentă
Această negociere este complet transparentă pentru client și server. În acest caz, se folosește un cache partajat care conține o listă de opțiuni, similar cu negocierea bazată pe client. Dacă memoria cache înțelege toate aceste opțiuni, atunci face alegerea în sine, ca în negocierea condusă de server. Acest lucru reduce sarcina pe serverul de origine și elimină cererea suplimentară de la client.
Specificația de bază HTTP nu descrie mecanismul transparent de negociere în detaliu.
Continuturi multiple
Protocolul HTTP acceptă transferul mai multor entități într-un singur mesaj. Mai mult, entitățile pot fi transmise nu numai sub forma unei secvențe cu un singur nivel, ci și sub forma unei ierarhii cu imbricarea elementelor unele în altele. Tipurile media multipart/* sunt folosite pentru a indica mai multe conținuturi. Lucrul cu astfel de tipuri se realizează conform regulilor generale descrise în RFC 2046 (dacă nu este definit altfel de un anumit tip de media). Dacă destinatarul nu știe cum să gestioneze tipul, atunci îl tratează în același mod ca multipart/mixed .
Parametrul limită înseamnă separatorul dintre diferitele tipuri de mesaje transmise. De exemplu, parametrul DestAddress transmis din formular transmite valoarea adresei de e-mail, iar elementul AttachedFile1 care îl urmează trimite conținutul binar al imaginii în format .jpg
Pe partea de server, mesajele cu conținut multiplu pot fi trimise ca răspuns la solicitările de fragmente de resurse multiple. În acest caz, este utilizat tipul media multipart/byteranges.
Pe partea clientului, atunci când trimiteți un formular HTML, metoda POST este folosită cel mai des. Un exemplu tipic: pagini de trimitere de e-mailuri cu fișiere atașate. La trimiterea unei astfel de scrisori, browserul generează un mesaj de tip multipart/form-data, integrând în acesta ca părți separate introduse de utilizator, subiectul scrisorii, adresa destinatarului, textul în sine și fișierele atașate:
POST /send-message.html HTTP/1.1 Gazdă: mail.example.com Referer: http://mail.example.com/send-message.html User-Agent: BrowserForDummies/4.67b Content-Type: multipart/form- date; boundary="Asrf456BGe4h" Lungimea conținutului: (volum total, inclusiv anteturile copiilor) Conexiune: keep-alive Keep-Alive: 300 (linie goală) (lipsește preambul) --Asrf456BGe4h Content-Disposition: form-data; name="DestAddress" (linie goală) [email protected]--Asrf456BGe4h Content-Disposition: form-data; name="MessageTitle" (linie goală) Sunt indignat --Asrf456BGe4h Content-Disposition: form-data; name="MessageText" (linie goală) Salut Vasily! Leul tău de companie, pe care mi l-ai lăsat săptămâna trecută, mi-a rupt toată canapea. Vă rog să-l ridicați curând! Atașez două fotografii cu consecințele. --Asrf456BGe4h Content-Disposition: form-data; name="AttachedFile1"; filename="horror-photo-1.jpg" Tip de conținut: imagine/jpeg (linie goală) (conținutul binar al primei fotografii) --Asrf456BGe4h Content-Disposition: form-data; name="AttachedFile2"; filename="horror-photo-2.jpg" Tip de conținut: imagine/jpeg (linie goală) (conținutul binar al celei de-a doua fotografii) --Asrf456BGe4h-- (lipsește epilog)
În exemplul din antetele Content-Disposition, parametrul nume corespunde atributului nume din etichetele HTML Și