HTTP

HTTP
Nume Protocolul de transfer hipertext
Nivel (conform modelului OSI ) Aplicat
Familie TCP/IP
Creat în 1992
Port/ID 80/ TCP
Specificație RFC 124 , RFC 1945 , RFC 2616 , RFC 2617 , RFC 6266 , RFC 7230 , RFC 7240 , RFC 8446 .
Principalele implementări (clienți) Browsere web , de exemplu, Internet Explorer , Mozilla Firefox , Opera , Google Chrome , Yandex Browser , Microsoft Edge etc.
Implementări de bază ( servere ) Apache , IIS , nginx , Google Web Server etc.
 Fișiere media la Wikimedia Commons

HTTP ( HyperText  Transfer Protocol  - „ protocol de transfer hipertext ”) este un protocol de transfer de date la nivel de aplicație , inițial sub formă de documente hipertext în format HTML , este utilizat în prezent pentru a transfera date arbitrare.

Proprietăți de bază

Baza HTTP este tehnologia „client-server” , adică existența:

HTTP este acum omniprezent pe World Wide Web pentru a prelua informații de pe site-uri web . În 2006, traficul HTTP din America de Nord l-a depășit pe cel al rețelelor P2P cu 46%, din care aproape jumătate era streaming video și audio [1] .

HTTP este folosit și 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 un URI (Uniform Resource Identifier) ​​într-o solicitare a 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 modul în care aceeași resursă este reprezentată de diferiți parametri: format , codificare , limbă etc. (în special, antetul HTTP este folosit pentru aceasta ). Datorită capacității de a specifica modul în care este codificat mesajul, clientul și serverul pot face schimb de date binare , deși acest protocol este text.

HTTP este un protocol de nivel de aplicație ; omologii săi sunt FTP și SMTP . Mesajele sunt schimbate conform schemei obișnuite „cerere-răspuns”. HTTP utilizează URI globale pentru a identifica resursele . Spre deosebire de multe alte protocoale, HTTP este apatrid. Aceasta înseamnă că nu este stocată nicio stare intermediară între perechile cerere-răspuns. Componentele care utilizează HTTP pot stoca în mod independent informații de stare legate de solicitările și răspunsurile recente (de exemplu, „ cookie -uri ” pe partea clientului, „sesiuni” pe partea serverului). Browserul care trimite solicitările poate urmări întârzierile de răspuns. Serverul poate stoca adresele IP și poate solicita antetele clienților recent. Cu toate acestea, protocolul în sine nu este la curent cu solicitările și răspunsurile anterioare, nu oferă suport intern de stat, nu are astfel de cerințe.

Majoritatea protocoalelor prevăd stabilirea unei sesiuni TCP în timpul căreia autorizarea are loc o singură dată, iar acțiunile ulterioare sunt efectuate în contextul acestei autorizari. HTTP stabilește o sesiune TCP separată pentru fiecare cerere; versiunile ulterioare de HTTP au permis efectuarea de cereri multiple într-o singură sesiune TCP, dar browserele de obicei solicită doar pagina și obiectele incluse în ea (imagini, stiluri în cascadă, etc.) și apoi încheie imediat sesiunea TCP. HTTP utilizează cookie -uri pentru a sprijini accesul autorizat (non-anonim) ; Mai mult, această metodă de autorizare vă permite să salvați sesiunea chiar și după ce clientul și serverul sunt reporniți.

La accesarea datelor prin FTP sau protocoale de fișiere, tipul fișierului (mai precis, tipul de date conținute în acesta) este determinat de extensia numelui fișierului, ceea ce nu este întotdeauna convenabil. HTTP, înainte de a transmite datele în sine, transmite antetul Content-Type: tip / subtip, care permite clientului să determine fără ambiguitate modul de procesare a datelor trimise. Acest lucru este deosebit de important atunci când lucrați cu scripturi CGI , când extensia numelui fișierului indică nu tipul de date trimise către client, ci necesitatea de a rula acest fișier pe server și de a trimite rezultatele programului scris în acest fișier către client. (în acest caz, același fișier în funcție de argumentele cererii și de propriile considerații, poate genera răspunsuri de diferite tipuri - în cel mai simplu caz, imagini în formate diferite).

În plus, HTTP permite clientului să trimită parametri către server, care vor fi transmise scriptului CGI care se execută. Pentru aceasta , formularele au fost introduse în HTML .

Aceste caracteristici ale HTTP au făcut posibilă crearea motoarelor de căutare (dintre care primul a fost AltaVista , creat de DEC ), forumuri și magazine de internet. Aceasta a comercializat Internetul, au apărut firme, al căror domeniu principal de activitate a fost furnizarea de acces la Internet (furnizori) și crearea de site-uri web.

Software

Toate programele pentru lucrul cu protocolul HTTP sunt împărțite în trei categorii mari:

Pentru a distinge serverele finale de proxy , documentația oficială folosește termenul server de origine .  Unul și același produs software poate îndeplini simultan funcțiile unui client, server sau intermediar, în funcție de sarcini. Specificațiile protocolului HTTP detaliază comportamentul pentru fiecare dintre aceste roluri.

Clienți

Protocolul HTTP a fost conceput inițial pentru a accesa documente hipertext de pe World Wide Web. Prin urmare, principalele implementări ale clientului sunt browserele (agenți utilizator). Pentru a vizualiza conținutul salvat al site-urilor pe un computer fără conexiune la internet, au fost inventate browsere offline . Când conexiunea este instabilă, managerii de descărcare sunt utilizați pentru a descărca fișiere mari ; acestea vă permit să descărcați fișierele specificate în orice moment după ce conexiunea la serverul web este pierdută. Unele atlase virtuale (cum ar fi Google Earth și NASA World Wind ) folosesc și HTTP.

Adesea, protocolul HTTP este folosit de programe pentru a descărca actualizări.

O întreagă gamă de programe robotizate este utilizată în motoarele de căutare de pe Internet . Printre aceștia se numără păianjenii web ( crawler -uri) care traversează hyperlinkuri, alcătuiesc o bază de date cu resurse de server și stochează conținutul acestora pentru analize ulterioare.

Servere sursă

Principalele implementări: Apache , Internet Information Services (IIS), nginx , LiteSpeed ​​​​Web Server (LSWS), Google Web Server , lighttpd .

Servere proxy

Principalele implementări: Squid , UserGate , Multiproxy , Naviscope , nginx .

Structura mesajului HTTP

Fiecare mesaj HTTP este format din trei părți, care sunt trimise în ordinea enumerată:

  1. Starting line ( ing.  Starting line ) - determină tipul mesajului;
  2. Anteturi (anteturi engleze )  - caracterizează corpul mesajului, parametrii de transmisie și alte informații;
  3. Corpul mesajului ( Corpul mesajului în engleză  ) - datele direct ale mesajului. Trebuie să fie separate de anteturi printr-o linie goală.

Corpul mesajului poate fi omis, dar linia de început și antetul sunt elemente obligatorii. Excepția este versiunea 0.9 a protocolului, unde mesajul de solicitare conține doar linia de început, iar mesajul de răspuns conține doar corpul mesajului.

Pentru versiunea de protocol 1.1, mesajul de solicitare trebuie să conțină antetul gazdă .

Linia de pornire

Șirurile de început sunt diferite pentru cerere și răspuns. Șirul de interogare arată astfel:

GET URI — pentru versiunea de protocol 0.9; Метод URI HTTP/Версия - pentru alte versiuni.

Aici:

Pentru a solicita o pagină pentru acest articol, clientul trebuie să treacă șirul (doar un antet dat):

GET /wiki/HTTP HTTP/1.0 Gazdă: en.wikipedia.org

Linia de început a răspunsului serverului are următorul format: HTTP/Версия КодСостояния Пояснение, unde:

De exemplu, linia de început a răspunsului serverului la o solicitare anterioară ar putea arăta astfel:

HTTP/1.0 200 OK

Metode

Metoda HTTP ( English  HTTP Method ) - o secvență de orice caractere, cu excepția controlului și a delimitatorilor, care indică operația principală pe resursă. De obicei, metoda este un cuvânt scurt englezesc scris cu majuscule. Rețineți că numele metodei face distincție între majuscule și minuscule.

Serverul poate folosi orice metodă, nu există metode obligatorii pentru server sau client. Dacă serverul nu recunoaște metoda specificată de client, atunci ar trebui să returneze starea 501(Neimplementat). Dacă metoda este cunoscută de server, dar nu este aplicabilă unei anumite resurse, atunci 405este returnat un mesaj cu un cod (Metoda nu este permisă). În ambele cazuri, serverul TREBUIE să includă un antet Allowcu o listă de metode acceptate în mesajul de răspuns.

În plus față de metodele GETși HEAD, metoda este adesea folosită POST.

OPȚIUNI

Folosit pentru a determina capabilitățile serverului web sau opțiunile de conectare pentru o anumită resursă. Ca răspuns, serverul TREBUIE să includă un antet Allowcu o listă de metode acceptate. Antetul răspunsului poate include și informații despre extensiile acceptate.

Se presupune că cererea clientului poate conține un corp de mesaj care să indice informațiile care îl interesează. Formatul corpului și ordinea de lucru cu acesta nu sunt definite în prezent; serverul ar trebui să-l ignore deocamdată. Situația este similară cu corpul în răspunsul serverului.

Pentru a afla capabilitățile întregului server, clientul trebuie să specifice un asterisc - " *" - în URI. Solicitările „ OPTIONS * HTTP/1.1” pot fi, de asemenea, utilizate pentru a verifica starea de sănătate a serverului (similar cu „ ping ”) și pentru a testa dacă serverul acceptă protocolul HTTP versiunea 1.1.

Rezultatul executării acestei metode nu este stocat în cache .

GET

Folosit pentru a interoga conținutul resursei specificate. GETDe asemenea, puteți începe un proces folosind o metodă . În acest caz, informațiile despre progresul procesului ar trebui incluse în corpul mesajului de răspuns.

Clientul poate trece parametrii de execuție a cererii în URI-ul resursei țintă după caracterul „ ?”:
GET /path/resource?param1=value1&param2=value2 HTTP/1.1

Conform standardului HTTP, cererile de tip GETsunt considerate idempotente [2]

Pe lângă metoda obișnuită GET, există și

Ordinea de executare a unor astfel de cereri este definită separat de standarde.

CAP

Similar cu metoda GET, cu excepția faptului că nu există niciun corp în răspunsul serverului. Interogarea HEADeste de obicei utilizată pentru a prelua metadate , pentru a verifica existența unei resurse ( validare URL ) și pentru a vedea dacă aceasta s-a modificat de la ultima accesare.

Anteturile de răspuns pot fi stocate în cache. Dacă metadatele resursei nu se potrivesc cu informațiile corespunzătoare din cache, copia resursei este marcată ca învechită.

POST

Folosit pentru a transmite date utilizator către o anumită resursă. De exemplu, în bloguri , vizitatorii își pot introduce, de obicei, comentariile la postări într-un formular HTML, după care sunt trimiși la server prin metoda POST și îi pune pe pagină. În acest caz, datele transmise (în exemplul blogului, 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 POSTnu este considerată idempotentă [2] , adică repetarea repetată a acelorași interogări POSTpoate returna rezultate diferite (de exemplu, după trimiterea fiecărui comentariu, va apărea o altă copie a acestui comentariu).

Dacă rezultatul execuției este 200(Ok), corpul răspunsului ar trebui să includă un mesaj despre rezultatul solicitării. Dacă o resursă a fost creată, serverul TREBUIE să returneze un răspuns 201(Creat) cu URI -ul noii resurse în Location.

Mesajul de răspuns al serverului de execuție a metodei POSTnu este stocat în cache.

PUTS

Folosit pentru a descărca conținutul solicitării în URI-ul specificat în cerere. Dacă o resursă nu există pentru URI-ul dat, atunci serverul o creează și returnează starea 201(Creat). Dacă resursa a fost schimbată, atunci serverul revine 200(Ok) sau 204(Fără conținut). Serverul NU TREBUIE să ignore anteturile nevalide Content-*trimise de client împreună cu mesajul. Dacă oricare dintre aceste anteturi nu poate fi recunoscut sau este invalid în condițiile actuale, atunci 501trebuie returnat un cod de eroare (NeImplementat).

Diferența fundamentală dintre metode POSTconstă PUTîn înțelegerea intenției URI-urilor de resurse. Metoda POSTpresupune că conținutul transmis de client va fi procesat la URI-ul specificat. Folosind PUT, clientul presupune că conținutul încărcat se potrivește cu resursa la URI-ul dat.

Mesajele de răspuns ale serverului la o metodă PUTnu sunt stocate în cache.

PATCH

Similar cu PUT, dar se aplică numai unui fragment de resursă.

ȘTERGE

Șterge resursa specificată.

TRACE

Returnează solicitarea primită, astfel încât clientul să poată vedea ce informații adaugă sau modifică serverele intermediare în cerere.

CONECTAȚI

Convertește conexiunea 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. Este un întreg de trei cifre [3] . Prima cifră indică clasa de stare. Codul de răspuns este de obicei urmat de o frază explicativă, separată de spațiu, în limba engleză, care explică persoanei motivul unui astfel de răspuns. Exemple:

201 Pagina web creată 403 Accesul permis numai utilizatorilor înregistrați 507 Depozitare 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 documentele RFC relevante . Introducerea noilor coduri ar trebui făcută numai după consultarea cu IETF . Este posibil ca clientul să nu cunoască toate codurile de stare, dar trebuie să răspundă în funcție de clasa de cod.

În prezent, există cinci clase de coduri de stare

Codul Clasă Scop
1xx Informațional

(ing. informativ )

Informații 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 nimic nu trebuie trimis la server.

Mesajele de la server în sine conțin doar linia de început a răspunsului și, dacă este necesar, câteva câmpuri de antet specifice răspunsului. Serverele proxy ar trebui să trimită astfel de mesaje mai departe de la server către client.

2xx Succes

( Succes în engleză )

Informarea cu privire la cazurile de acceptare și procesare cu succes a cererii clientului. În funcție de stare, serverul poate trimite în continuare anteturile și corpul mesajului.
3xx redirecţiona

(ing. Redirecționare )

Informează clientul că trebuie făcută o altă solicitare (de obicei printr-un URI diferit) pentru a finaliza cu succes operația. Din această clasă, cinci coduri 301, 302, 303, 305și 307se referă direct la redirecționări (redirecționare). Adresa la care clientul ar trebui să facă o cerere este indicată de server în fișierul Location. Acest lucru permite utilizarea fragmentelor în URI-ul țintă.
4xx Eroare client

( Eroare client engleză )

Indicarea erorilor din partea clientului. Când utilizați toate metodele, cu excepția HEAD, serverul trebuie să returneze o explicație hipertext pentru utilizator în corpul mesajului.
5xx Eroare de server

( Eroare server engleză )

Informarea cu privire la cazurile de funcționare nereușită din vina serverului. Pentru toate situațiile, altele decât utilizarea metodei HEAD, serverul TREBUIE să includă o explicație în corpul mesajului pe care clientul o va afișa utilizatorului.

Titluri

Antetele HTTP sunt șiruri dintr-un mesaj HTTP care conțin o pereche parametru-valoare, separată de două puncte .  Formatul antetelor urmează formatul general al antetelor mesajelor de rețea text ARPA (vezi RFC 822 ). Anteturile trebuie separate de corpul mesajului prin cel puțin o linie goală.

Exemple de antet:

Server: Apache/2.2.11 (Win32) PHP/5.3.0 Ultima modificare: sâmbătă, 16 ianuarie 2010 21:16:42 GMT Tip de conținut: text/plan simplu; set de caractere=windows-1251 Limbă de conținut: en

În exemplul de mai sus, fiecare linie reprezintă un antet. În acest caz, ceea ce este înainte de două puncte se numește nume (nume englezesc )  , iar ceea ce este după el se numește valoare ( valoare engleză ).  

Toate titlurile sunt împărțite în patru grupuri principale:

  1. Anteturi generale („anteturi principale”) – pot fi incluse în orice mesaj al clientului și serverului;
  2. Antete de solicitare ("Request Headers") - utilizate numai în cererile clientului;
  3. Antete de răspuns („Anteturi de răspuns”) – numai pentru răspunsurile de la server;
  4. Anteturi de entitate ("Headers of the entity") - însoțesc fiecare entitate a mesajului.

Aceasta este ordinea în care se recomandă trimiterea antetelor către destinatar.

Toate anteturile necesare pentru ca HTTP să funcționeze sunt descrise în RFC -urile de bază . Dacă nu există suficiente, atunci le puteți introduce pe ale dvs. În mod tradițional, numele acestor anteturi suplimentare sunt prefixate cu „ X-” pentru a evita conflictele de nume cu cele posibile existente. De exemplu, ca în anteturi X-Powered-Bysau X-Cache. Unii dezvoltatori folosesc propriile prefixe personalizate. Exemple de astfel de anteturi sunt cele Ms-Echo-Requestintroduse Ms-Echo-Replyde Microsoft pentru extensia WebDAV .

Corpul mesajului

Corpul mesajului HTTP ( message-body), dacă este prezent, este utilizat pentru a transmite corpul obiectului asociat cu cererea sau răspunsul. Corpul mesajului diferă de corpul obiectului ( entity-body) numai atunci când se aplică o codificare de transmisie, așa cum este indicat de câmpul antet Transfer-Encoding.

mesaj-corp = entitate-corp | <corp-entitate codificat conform transfer-codare>

Câmpul Transfer-Encodingtrebuie utilizat pentru a indica orice codificare de transmisie aplicată de aplicație pentru a se asigura că mesajul este transmis în siguranță și corect. Un câmp Transfer-Encoding este o proprietate a unui mesaj, nu un obiect, și astfel poate fi adăugat sau eliminat de orice aplicație din lanțul de cereri/răspuns.

Regulile care guvernează validitatea unui corp de mesaj într-un mesaj sunt diferite pentru cereri și răspunsuri.

Prezența unui corp de mesaj într-o cerere este indicată prin adăugarea unui câmp de antet Content-Lengthsau la anteturile cererii Transfer-Encoding. Un corp de mesaj poate fi adăugat la o solicitare numai atunci când metoda de solicitare permite un corp de obiect.

Dacă corpul mesajului 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 cerere cu o metodă HEADnu trebuie să includă un corp de mesaj, chiar dacă entity-headersunt prezente câmpuri de antet obiect ( ) pentru a face să pară că obiectul este prezent. Niciun răspuns cu coduri 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ă este de lungime zero.

Exemple de dialoguri HTTP

Solicitare GET obișnuită

Solicitarea clientului:

GET /wiki/ HTTP/1.1 pagina Gazdă: en.wikipedia.org Agent utilizator: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9b5) Gecko/2008050509 Firefox/3.0b5 Accept: text/html Conexiune: aproape (linie goală)

Răspunsul serverului:

HTTP/1.1 200 OK Data: miercuri, 11 februarie 2009 11:20:59 GMT Server: Apache X-Powered-By: PHP/5.2.4-2ubuntu5wm1 Ultima modificare: miercuri, 11 februarie 2009 11:20:59 GMT Limbă de conținut: en Tip de conținut: text/html; set de caractere=utf-8 Lungimea conținutului: 1234 Conexiune: aproape (șir gol) (pagina solicitată în HTML )

Răspunsul arată la fel 203. Ceea ce este important - datele solicitate direct sunt separate de antetele HTTP folosind CR , LF , CR, LF.

Redirecționări

Să presupunem că compania fictive „Example Corp”. există un site principal la „http://example.com” și un domeniu alias „example.org” . Clientul trimite o solicitare pentru pagina „Despre” către domeniul secundar (unele anteturi au fost omise):

GET /about.html HTTP/1.1 Gazdă: example.org Agent utilizator: MyLonelyBrowser/5.0

Deoarece domeniul „example.org” nu este un domeniu principal și compania nu intenționează să-l folosească în alte scopuri în viitor, serverul său va returna un cod pentru o redirecționare permanentă, indicând Locationadresa URL țintă în antet:

HTTP/1.x 301 mutat definitiv Locație: http://example.com/about.html#contacts Data: joi, 19 februarie 2009 11:08:01 GMT Server: Apache/2.2.4 Tip de conținut: text/html; set de caractere=windows-1251 Lungimea conținutului: 110 (linie goală) <html><body><a href="http://example.com/about.html#contacts">Faceți clic aici</a></body></html>

În titlu Location, puteți specifica fragmente ca în acest exemplu. Browserul nu a specificat un fragment în cerere deoarece este interesat de întregul document. Dar va derula automat pagina la fragmentul „contacte” imediat ce o încarcă. Un scurt document HTML a fost plasat, de asemenea, în corpul răspunsului, cu un link care ar duce vizitatorul la pagina de destinație dacă browserul nu a navigat automat la aceasta. Titlul Content-Typeconține caracteristicile acelei explicații HTML specifice, nu ale documentului găsit la URI-ul țintă.

Să presupunem că aceeași companie „Example Corp”. are mai multe birouri regionale în întreaga lume. Și pentru fiecare agenție au un site web cu un ccTLD corespunzător . Solicitarea paginii de pornire pentru site-ul principal „example.com” ar putea arăta astfel:

GET /HTTP/1.1 gazdă: example.com Agent utilizator: MyLonelyBrowser/5.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: ru,en-us;q=0.7,en;q=0.3 Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.7

Serverul a luat în considerare antetul Accept-Languageși a format un răspuns cu o redirecționare temporară către serverul rus „example.ru” , indicând adresa sa în antet Location:

HTTP/1.x 302 găsit Locație: http://example.ru/ Cache-Control: privat Data: joi, 19 februarie 2009 11:08:01 GMT Server: Apache/2.2.6 Tip de conținut: text/html; set de caractere=windows-1251 Lungimea conținutului: 82 (linie goală) <html><body><a href="http://example.ru">Example Corp.</a></body></html>

Fiți atenți la antet Cache-Control: valoarea „privată” le spune restului serverelor (în primul rând proxy-urilor) că răspunsul poate fi stocat în cache doar pe partea clientului. În caz contrar, este posibil ca următorii vizitatori din alte țări să meargă întotdeauna la o altă reprezentanță.

303Codurile de răspuns (Vezi Altele) și 307(Redirecționare temporară) sunt, de asemenea, folosite pentru redirecționare .

Reluați și descărcați fragmente

Să presupunem că o organizație fictivă oferă să descarce un videoclip al conferinței anterioare de pe site-ul web la: „http://example.org/conf-2009.avi” - aproximativ 160 MB în dimensiune . Să luăm în considerare modul în care acest fișier este reluat în caz de eșec și modul în care managerul de descărcări ar organiza descărcarea cu mai multe fire a mai multor fragmente.

În ambele cazuri, clienții vor face prima cerere astfel:

GET /conf-2009.avi HTTP/1.0 Gazdă: example.org Accept: */* Agent utilizator: Mozilla/4.0 (compatibil; MSIE 5.0; Windows 98) Referer: http://example.org/

Titlul Refererindică faptul că fișierul a fost solicitat de pe pagina principală a site-ului. De obicei, managerii de descărcare îl specifică și pentru a emula tranziția de la pagina site-ului. Fără acesta, serverul poate răspunde 403(Acces interzis) dacă solicitările de la alte site-uri nu sunt permise. În cazul nostru, serverul a returnat un răspuns de succes:

HTTP/1.1 200 OK Data: joi, 19 februarie 2009 12:27:04 GMT Server: Apache/2.2.3 Ultima modificare: miercuri, 18 iunie 2003 16:05:58 GMT Etichetă: „56d-9989200-1132c580” Tip de conținut: video/x-msvideo Lungimea conținutului: 160993792 Accept-Range: octeți Conexiune: aproape (șir gol) (conținut binar al întregului fișier)

Antetul Accept-Rangesinformează clientul că poate solicita fragmente de la server prin specificarea decalajelor acestora de la începutul fișierului în octeți. Dacă acest antet lipsește, atunci clientul POATE avertiza utilizatorul că cel mai probabil fișierul nu va putea descărca.

Pe baza valorii antetului Content-Length, managerul de descărcare va împărți întregul volum în fragmente egale și le va solicita separat, organizând mai multe fluxuri. Dacă serverul nu specifică o dimensiune, atunci clientul nu va putea implementa descărcări paralele, dar va putea în continuare să descarce fișierul până când serverul răspunde 416(Interval solicitat nu este satisfăcător).

Să presupunem că la al 84-lea megaoctet conexiunea la internet a fost întreruptă și procesul de descărcare s-a oprit. Când conexiunea la internet a fost restabilită, managerul de descărcare a trimis automat o nouă solicitare către server, dar cu o instrucțiune de a returna conținutul de la al 84-lea megaoctet:

GET /conf-2009.avi HTTP/1.0 Gazdă: example.org Accept: */* Agent utilizator: Mozilla/4.0 (compatibil; MSIE 5.0; Windows 98) Interval: octeți=88080384- Referer: http://example.org/

Serverul nu este obligat să-și amintească ce și de la cine au fost făcute cereri înainte și, prin urmare, clientul a inserat din nou antetul Referer, ca și cum ar fi prima sa cerere. Valoarea antetului specificată Rangeîi spune serverului: „Dați conținutul de la octetul 88080384 până la capăt”. În acest sens, serverul va returna un răspuns:

HTTP/1.1 206 Conținut parțial Data: joi, 19 februarie 2009 12:27:08 GMT Server: Apache/2.2.3 Ultima modificare: miercuri, 18 iunie 2003 16:05:58 GMT Etichetă: „56d-9989200-1132c580” Accept-Range: octeți Interval de conținut: octeți 88080384-160993791/160993792 Lungimea conținutului: 72913408 Conexiune: aproape Tip de conținut: video/x-msvideo (șir gol) (conținut binar de la al 84-lea megaoctet)

Antetul Accept-Rangesnu mai este necesar aici, deoarece clientul este deja conștient de această capacitate de server. Faptul că un fragment este transmis este cunoscut clientului prin cod 206(Partial Content). Antetul Content-Rangeconține informații despre acest fragment: numerele octetului de început și de sfârșit, iar după bară oblică, dimensiunea totală a întregului fișier în octeți. Atenție la antet Content-Length - indică dimensiunea corpului mesajului, adică fragmentul transmis. Dacă serverul returnează mai multe fragmente, acesta Content-Lengthva conține volumul total al acestora.

Acum reveniți la managerul de descărcare. Cunoscând dimensiunea totală a fișierului „conf-2009.avi” , programul l-a împărțit în 10 secțiuni egale.

Managerul inițial se va încărca chiar la prima solicitare, întrerupând conexiunea imediat ce ajunge la începutul celei de-a doua. Restul se va solicita separat. De exemplu, a patra secțiune ar fi solicitată cu următoarele antete (unele antete au fost omise - vezi exemplul complet de mai sus):

GET /conf-2009.avi HTTP/1.0 Interval: octeți=64397516-80496894

Răspunsul serverului în acest caz va fi următorul (o parte din anteturi sunt omise - vezi exemplul complet de mai sus):

HTTP/1.1 206 Conținut parțial Accept-Range: octeți Interval de conținut: octeți 64397516-80496894/160993792 Lungimea conținutului: 16099379 (șir gol) (partea a patra conținut binar)

Dacă o astfel de solicitare este trimisă către un server care nu acceptă fragmente, atunci va returna un răspuns standard 200(OK) așa cum se arată la început, dar fără antetul Accept-Ranges.

Vezi, de asemenea , GET parțial , intervale de octeți , răspunsul 206 , răspunsul 416 .

Mecanismele de bază ale protocolului

GET-uri parțiale

HTTP vă permite să solicitați nu tot conținutul resursei simultan, ci doar fragmentul specificat. Astfel de cereri se numesc parțiale GET; capacitatea de a le executa este opțională (dar de dorit) pentru servere. Parțialele sunt GETutilizate în principal pentru reluarea fișierelor și descărcări paralele rapide în mai multe fire. Unele programe descarcă antetul arhivei, afișează utilizatorului structura internă și apoi solicită fragmente cu elementele de arhivă specificate.

Pentru a primi un fragment, clientul trimite o cerere către server cu un antet Rangecare specifică intervalele de octeți solicitate în acesta . Dacă serverul nu înțelege cererile parțiale (ignoră antetul Range), atunci va returna tot conținutul cu starea 200, la fel ca în cazul unui GET. În cazul finalizării cu succes, serverul returnează un 200răspuns cu stare 206(Conținut parțial) în loc de cod, inclusiv antetul din răspuns Content-Range. Fragmentele în sine pot fi transmise în două moduri:

GET-uri condiționate

Metoda GETse schimbă în „condițional GET” dacă mesajul de solicitare include un câmp de antet If-Modified-Since. Ca răspuns la „condițional GET”, corpul resursei solicitate este trimis numai dacă s-a schimbat de la data specificată în antet If-Modified-Since. Algoritmul pentru determinarea acestui lucru include următoarele cazuri:

Utilizarea metodei „GET condiționat” are ca scop descărcarea rețelei, deoarece permite să nu se transmită informații redundante prin rețea.

Negociere de conținut

Negocierea conținutului este un  mecanism pentru determinarea automată a resursei necesare în prezența mai multor versiuni diferite ale unui document. Subiectele de negociere pot fi nu numai resurse de server, ci și pagini returnate cu mesaje de eroare ( 403 , 404 , etc.).

Există două tipuri principale de acorduri:

Ambele tipuri pot fi utilizate în același timp sau fiecare dintre ele separat.

Specificația principală a protocolului ( RFC 2616 ) evidențiază, de asemenea, așa-numita negociere transparentă ca combinație preferată a ambelor tipuri .  Cel din urmă mecanism nu trebuie confundat cu tehnologia independentă Transparent Content Negotiation (TCN) , care nu face parte din protocolul HTTP, dar poate fi utilizată împreună cu acesta. Ambele au o diferență semnificativă în principiul de funcționare și în însuși sensul cuvântului „transparent” (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 cererii clientului pentru a returna ceea ce crede că este cel mai bun. Titlurile Accept, Accept-Charset, Accept-Encoding, Accept-Languagesși sunt în principal analizate User-Agent. Este de dorit ca serverul să includă un antet în răspuns Varycare indică parametrii prin care se distinge conținutul prin URI-ul solicitat.

Locația geografică a clientului poate fi determinată de la 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 publicului, 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 cu o acuratețe maximă a orașului (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 cele mai apropiate suburbii, atunci abonații săi pot observa pe unele site-uri că sunt din Moscova și nu din Krasnogorsk sau Dzerzhinsky .

Negocierea gestionată de 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ă).
  • Există o mulțime de anteturi de grup Accept, dar puține resurse cu mai multe opțiuni. Din această cauză, echipamentul este supraîncărcat.
  • Cache-ul partajat este limitat în capacitatea sa de a emite 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.
Gestionat de client

În acest caz, tipul de conținut este determinat doar de partea clientului. Pentru a face acest lucru, serverul returnează într-un răspuns cu un cod de stare 300(Alegeri multiple) sau 406(Neacceptat) o listă de opțiuni, dintre care utilizatorul o selectează pe cea potrivită. Negocierea gestionată de client funcționează bine atunci când conținutul diferă în cele mai obișnuite moduri (cum ar fi limba și codificarea) și se utilizează un cache public.

Principalul dezavantaj este supraîncărcarea, deoarece trebuie să faceți o cerere suplimentară pentru a obține conținutul dorit.

Negociere 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, ca pentru o negociere gestionată de client. Dacă memoria cache înțelege toate aceste opțiuni, atunci face alegerea în sine, ca într-o negociere administrată 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.

Continut multiplu

Protocolul HTTP acceptă transferul mai multor entități într-un singur mesaj. Mai mult, entitățile pot fi transferate nu numai ca o secvență cu un singur nivel, ci și ca o ierarhie cu elemente imbricate unele în altele. Tipurile media sunt folosite pentru a desemna mai multe conținuturi multipart/*. 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ă receptorul nu știe cum să lucreze cu tipul, atunci îl tratează în același mod ca multipart/mixed.

Parametrul limită înseamnă separatorul dintre diferitele tipuri de mesaje trimise. 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 .jpg

Pe partea de server, mesajele cu conținut multiplu pot fi trimise ca răspuns la mesaje parțialeGET atunci când sunt solicitate mai multe fragmente de resurse. În acest caz, se utilizează tipul media multipart/byteranges.

Pe partea clientului, atunci când trimiteți un formular HTML , POST. Un exemplu tipic sunt paginile de trimitere prin e-mail cu fișiere atașate. La trimiterea unei astfel de scrisori, browserul generează un mesaj de tipul multipart/form-data, integrând în el 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 Agent utilizator: BrowserForDummies/4.67b Tip de conținut: date multiple/form-date; boundary="Asrf456BGe4h" Lungimea conținutului: (lungimea totală, inclusiv antetele copiilor) Conexiune: păstrați-vă în viață Păstrați-vă în viață: 300 (șir gol) (preambul lipsește) --Asrf456BGe4h Conținut-Dispoziție: formular-date; name="DestAddress" (linie goală) [email protected] --Asrf456BGe4h Conținut-Dispoziție: formular-date; name="MessageTitle" (linie goală) Am retrimis --Asrf456BGe4h Conținut-Dispoziție: formular-date; name="MessageText" (linie goală) Salut Vasily! Leul tău de companie pe care l-ai lăsat în urmă Eu săptămâna trecută, mi-am rupt toată canapea. Vă rugăm să-l ridicați în curând! Atașez două poze cu consecințele. --Asrf456BGe4h Conținut-Dispoziție: formular-date; name="AttachedFile1"; filename="horror-photo-1.jpg" Tip de conținut: imagine/jpeg (șir gol) (conținutul binar al primei fotografii) --Asrf456BGe4h Conținut-Dispoziție: formular-date; name="AttachedFile2"; filename="horror-photo-2.jpg" Tip de conținut: imagine/jpeg (șir gol) (conținutul binar al celei de-a doua fotografii) --Asrf456BGe4h-- (lipsește epilog)

În exemplul din anteturi , Content-Dispositionparametrul namese potrivește cu atributul namedin etichetele HTML <INPUT>și <TEXTAREA>. Parametrul filenameeste egal cu numele fișierului original de pe computerul utilizatorului. Consultați RFC 1867 pentru mai multe informații despre generarea formularelor HTML și atașarea fișierelor .

Istoricul dezvoltării

HTTP/0.9 HTTP a fost propus în martie 1991 de Tim Berners-Lee , pe atunci la CERN , ca mecanism de accesare a documentelor de pe Internet și de facilitare a navigării prin utilizarea hipertextului . Cea mai veche versiune a protocolului HTTP/0.9 a fost publicată pentru prima dată în ianuarie 1992 (deși implementarea datează din 1990 ). Specificația protocolului a condus la o simplificare a regulilor de interacțiune între clienții HTTP și servere, precum și la o separare clară a funcțiilor între aceste două componente. Au fost documentate principalele prevederi sintactice și semantice . HTTP/1.0 În mai 1996, a fost emis RFC 1945 pentru implementarea practică a HTTP , oferind baza pentru implementarea majorității componentelor HTTP/1.0. HTTP/1.1 Versiunea modernă a protocolului; adoptată în iunie 1999 [4] . Nou în această versiune a fost un mod „conexiune persistentă”: o conexiune TCP poate rămâne deschisă după ce a fost trimis un răspuns la o solicitare, permițând trimiterea mai multor cereri pe aceeași conexiune. Clientul este acum obligat să trimită informații despre numele gazdei pe care o accesează, ceea ce a făcut posibilă o organizare mai ușoară a găzduirii partajate . HTTP/2 La 11 februarie 2015 au fost publicate versiunile finale ale proiectului următoarei versiuni a protocolului. Spre deosebire de versiunile anterioare, protocolul HTTP/2 este binar . Caracteristicile cheie includ multiplexarea cererilor, prioritizarea cererilor, compresia antetului, încărcarea mai multor articole în paralel printr-o singură conexiune TCP , suport pentru notificări push proactive pe partea de server [5] . HTTP/3 HTTP/3  este un succesor propus pentru HTTP/2 [6] [7] care este deja utilizat pe Web pe baza UDP în loc de TCP ca protocol de transport. La fel ca HTTP/2, nu depreciază versiunile majore anterioare ale protocolului. Suportul HTTP/3 a fost adăugat la Cloudflare și Google Chrome în septembrie 2019 [8] [9] și poate fi activat în versiunile stabile de Chrome și Firefox [10] .

Vezi și

Note

  1. ↑ Volumul traficului HTTP a depășit P2P pentru prima dată Arhivat 22 decembrie 2007 la Wayback Machine // Compulenta, 22 iunie 2007 ( document alb de la Ellacoya Networks arhivat 22 iunie 2007 la Wayback Machine ).
  2. ↑ 1 2 HTTP/1.1: Definiții metode  (engleză)  (downlink) . Arhivat din original pe 23 iunie 2012.
  3. ↑ Vezi prima propoziție a secțiunii „ 6.1.1 Cod de stare și expresie de motiv ” din RFC 2068. Există , de asemenea, o declarație BNF mărită la pagina 40.) " extension-code = 3DIGIT" pentru codurile de extensie.
  4. ↑ Specificația HTTP/1.1 a fost publicată pentru prima dată în ianuarie 1997 RFC 2068 ; în versiunea modernă a RFC 2616 , greșelile de scriere au fost corectate, terminologia și formatarea au fost îmbunătățite pe alocuri. De asemenea, a clarificat comportamentul acceptabil al clientului (browserului), serverului și serverelor proxy în unele situații discutabile. Adică, versiunea 1.1 a apărut până la urmă în 1997.
  5. ↑ HTTP/2 Schiță . Consultat la 25 februarie 2015. Arhivat din original pe 20 februarie 2015.
  6. ↑ Bishop, Mike Hypertext Transfer Protocol Versiunea 3 (HTTP/3  ) . tools.ietf.org (9 iulie 2019). Preluat la 16 august 2019. Arhivat din original la 31 august 2019.
  7. ↑ Cimpanu, Cătălin . HTTP-over-QUIC va fi redenumit HTTP/3 | ZDNet  (engleză) , ZDNet . Arhivat din original pe 13 noiembrie 2018. Preluat la 10 august 2020.
  8. ↑ Cimpanu, Catalin Cloudflare , Google Chrome și Firefox adaugă suport HTTP/3 . ZDNet (26 septembrie 2019). Preluat la 27 septembrie 2019. Arhivat din original la 26 septembrie 2019.
  9. ↑ HTTP/3: trecutul, prezentul și  viitorul . Blogul Cloudflare (26 septembrie 2019). Consultat la 30 octombrie 2019. Arhivat din original la 26 septembrie 2019.
  10. ↑ Firefox Nightly acceptă HTTP 3 - General - Comunitate Cloudflare (19 noiembrie 2019). Preluat la 23 ianuarie 2020. Arhivat din original la 6 iunie 2020.

Link -uri

 scheme URI
Oficial
neoficial
 web semantic
Bazele
Subsecțiuni
Aplicații
subiecte asemănătoare
Standarde
  • Istoric : HTML semantic vechi simplu
  • DAML+ULEI
 HTTP
Concepte generale
Metode
Titluri
Codurile de stare