Protocol de transfer hipertext

De la Wikipedia, enciclopedia liberă.
Salt la navigare Salt la căutare
Notă despre dezambiguizare.svg Dezambiguizare - "HTTP" se referă aici. Dacă căutați alte semnificații, consultați HTTP (dezambiguizare) .

În telecomunicații și tehnologia informației HTTP ( protocolul de transfer hipertext ) este un protocol de strat de aplicație folosit ca sistem principal pentru transmiterea informațiilor pe web sau într-o arhitectură tipică client-server . Specificațiile protocolului sunt menținute de World Wide Web Consortium ( W3C ). Un server HTTP ascultă de obicei cererile clientului pe portul 80 folosind stratul de transport TCP .

Istorie

Prima versiune a HTTP, 0.9, datează de la sfârșitul anilor 1980 și a constituit, împreună cu limbajul HTML și adresele URL , nucleul de bază al inițiativei de informare globală World Wide Web (WWW) dezvoltată de Tim Berners-Lee la CERN din Geneva pentru schimbul de informații între comunitatea fizicienilor cu energie ridicată . Înainte de HTTP, protocolul de referință pentru astfel de scopuri era FTP-ul mai simplu și mai ușor. Prima versiune efectiv disponibilă a protocolului, HTTP / 1.0, a fost implementată de Berners-Lee însuși în 1991 și propusă ca RFC 1945 [1] autorității de reglementare IETF în 1996.

Odată cu răspândirea NCSA Mosaic , un browser grafic ușor de utilizat, WWW a cunoscut un succes din ce în ce mai mare și unele limitări ale versiunii 1.0 a protocolului au devenit evidente, în special:

  • incapacitatea de a găzdui mai multe site-uri web pe același server ( gazdă virtuală );
  • eșecul reutilizării conexiunilor disponibile;
  • insuficiența mecanismelor de securitate .

Protocolul a fost apoi extins în versiunea HTTP / 1.1, prezentată ca RFC 2068 [2] în 1997 și ulterior actualizată în 1999 așa cum este descris de RFC 2616 [3] .

Noua versiune a protocolului, HTTP / 2 , a fost publicată în RFC 7540 [4] în mai 2015.

Operațiune

HTTP este un protocol care funcționează cu o arhitectură client / server : clientul face o cerere și serverul returnează răspunsul trimis de o altă gazdă. În utilizare obișnuită, clientul corespunde browserului și serverului mașinii pe care se află site - ul web . Prin urmare, există două tipuri de mesaje HTTP : mesaje de solicitare și mesaje de răspuns.

HTTP diferă de alte protocoale de nivel 7 , cum ar fi FTP, prin faptul că conexiunile sunt de obicei închise odată ce o anumită cerere (sau o serie de cereri conexe) a fost satisfăcută. Acest comportament face ca protocolul HTTP să fie ideal pentru World Wide Web, în ​​care paginile conțin foarte des linkuri către pagini găzduite de alte servere, scăzând astfel numărul de conexiuni active limitându-le la cele de fapt necesare cu o creștere a eficienței (încărcare mai mică și ocupare) atât pe client, cât și pe server. Cu toate acestea, uneori pune probleme dezvoltatorilor de conținut web, deoarece natura apatridă a sesiunii de navigare îi obligă să folosească metode alternative - de obicei bazate pe cookie - uri - pentru a menține statutul utilizatorului.

Solicitați un mesaj

Mesajul de solicitare este format din patru părți:

  • linie de cerere;
  • secțiunea antet (informații suplimentare);
  • linie necompletată (CRLF: cele două caractere returnează transportul și avansează linia);
  • corp (corp mesaj).

Linie de solicitare

Linia de solicitare constă din metodă, URI și versiunea protocolului. Metoda de solicitare, pentru versiunea 1.1, poate fi una dintre următoarele:

  • OBȚINE
  • POST
  • CAP
  • A PUNE
  • ȘTERGE
  • PLASTURE
  • URMĂ
  • OPȚIUNI
  • CONECTAȚI

URI - ul , identificator uniform al resurselor , indică subiectul cererii (de exemplu, pagina web care urmează să fie obținută).

Cele mai comune metode HTTP sunt GET , HEAD și POST . Metoda GET este utilizată pentru a obține conținutul resursei indicat ca un URI (cum ar fi conținutul unei pagini HTML ). HEAD este similar cu GET , dar returnează doar câmpurile de antet, de exemplu pentru a verifica data modificării fișierului. O cerere cu metoda HEAD nu necesită utilizarea corpului.

Metoda POST este de obicei utilizată pentru a trimite informații către server (cum ar fi datele formularului ). În acest caz, URI indică ce este trimis, iar corpul indică conținutul acestuia.

Anteturile cererii

Cele mai frecvente anteturi de solicitare sunt:

Gazdă : numele serverului la care se referă adresa URL . Este necesar în cererile compatibile HTTP / 1.1 deoarece permite utilizarea gazdelor virtuale bazate pe nume .
User-Agent : identificarea tipului de client: tip browser, producător, versiune ...
Cookie-uri: utilizate de aplicațiile web pentru a stoca și a prelua informații pe termen lung din partea clientului. Adesea folosit pentru a stoca un jeton de autentificare sau pentru a urmări activitatea utilizatorului.

Mesaj de răspuns

Mesajul de răspuns este textual și constă din patru părți:

  • status-line ;
  • secțiunea antet;
  • linie necompletată (CRLF: cele două caractere returnează transportul și avansează linia);
  • corp (conținutul răspunsului).

Linia de stare

Pictogramă lupă mgx2.svg Același subiect în detaliu: coduri de stare HTTP .

Linia de stare arată un cod din trei cifre catalogat după cum urmează:

  • 1xx: Informativ (mesaje informative)
  • 2xx: reușită (solicitarea a fost satisfăcută)
  • 3xx: Redirecționare (nu există un răspuns imediat, dar cererea are sens și i se spune cum să obțineți răspunsul)
  • 4xx: Eroare client (solicitarea nu poate fi satisfăcută deoarece este greșită)
  • 5xx: Eroare de server (solicitarea nu poate fi satisfăcută din cauza unei probleme interne a serverului)

Cele mai frecvente coduri de răspuns sunt:

  • 200 OK . Serverul a furnizat cu succes conținutul din secțiunea corp.
  • 301 mutat permanent . Resursa pe care am solicitat-o ​​nu este accesibilă, deoarece a fost mutată definitiv.
  • 302 găsit . Resursa este accesibilă cu un alt URI indicat în antetul Locație. Browserele fac de obicei cererea către URI-ul specificat automat, fără interacțiunea utilizatorului.
  • 400 Cerere greșită . Resursa solicitată nu este de înțeles de server.
  • 404 Nu a fost găsit . Resursa solicitată nu a fost găsită și locația sa este necunoscută. Acest lucru apare de obicei atunci când URI-ul a fost introdus incorect sau conținutul a fost eliminat de pe server.
  • 500 Eroare server intern . Serverul nu poate răspunde la cerere din cauza unei probleme interne.
  • 502 Bad Gateway. Serverul web care acționează ca proxy invers nu a primit un răspuns valid de la serverul din amonte.
  • Versiunea 505 HTTP neacceptată . Versiunea http nu este acceptată.

Anteturile de răspuns

Cele mai frecvente anteturi de răspuns sunt:

  • Server . Indică tipul și versiunea serverului. Poate fi văzut ca echivalentul antetului cererii utilizator-agent
  • Tipul conținutului . Indică tipul de conținut returnat. Codificarea acestor tipuri (numită tip Media) este înregistrată în IANA (I nternet A ssigned N umber A uthority); sunt denumite tipuri MIME (M ultimedia I nternet M ail E XTensions), a căror codificare este descrisă în documentul RFC 1521 . Unele tipuri MIME obișnuite întâlnite într-un răspuns HTTP sunt:
    • document HTML text / html
    • text / simplu Document text neformatat
    • document XML text / xml
    • imagine / jpeg imagine în format JPEG

Tipul conexiunii

Clientul poate cere serverului, în mesajul de solicitare, să utilizeze două tipuri de comunicare.

Nu este persistent
Pentru fiecare cerere și răspunsul acesteia, se stabilește o conexiune TCP dedicată.
Persistent
Fiecare solicitare și răspunsul acesteia sunt transferate utilizând aceeași conexiune TCP. Acesta este comportamentul implicit al HTTP 1.1.

Pe de o parte, conexiunile non-persistente introduc o latență suplimentară comparativ cu cele persistente de cel puțin 3 ori de călătorie dus-întors (RTT). De fapt, la sfârșitul fiecărui răspuns de la server devin necesare

  • 1,5 sau 2 RTT-uri pentru închiderea conexiunii curente, cu FIN-ul său în trei sau patru trepte și strângerea de mână ACK ( strângere de mână cu trei sau patru căi ).
  • 1.5 RTT pentru deschiderea noii conexiuni, pentru cei trei pași ai SYN și ACK.

Pe de altă parte, conexiunile persistente împiedică paralelismul în comunicații, deoarece clientul care are mai multe cereri de trimitere la același server este obligat să le proceseze secvențial, unul după altul. Din aceste motive, browserele exploatează de obicei complementaritățile de performanță ale celor două politici de comunicare pentru a maximiza eficiența acestora: de obicei deschid mai multe conexiuni TCP în paralel cu fiecare server, pe care comunică cu o strategie persistentă.

Exemple de mesaje HTTP

Urmează exemple de mesaje de solicitare și răspuns HTTP / 1.1.

Exemplele se referă la recuperarea conținutului din această enciclopedie web și pot fi reproduse - și, prin urmare, verificate - pe computerul dvs. prin copierea și lipirea textului cu un client TCP (de exemplu: telnet it.wikipedia.org 80 în cazul URL http: / /) sau client TCP cu suport SSL (de exemplu: openssl s_client -connect it.wikipedia.org:443 în cazul URL-ului https: //).

În scopul reproducerii, se observă că:

  • singurul antet obligatoriu din cererea HTTP / 1.1 este antetul Host care conține partea gazdă a adresei URL (așa cum este scris mai sus);
  • browserele adaugă de obicei antetul Accept-Encoding pentru a specifica capacitatea de a primi răspunsul într-un format comprimat. Antetul este eliminat pentru a face răspunsul lizibil (de exemplu: Accept-Encoding: x-gzip, x-deflate, gzip, deflate, identity );
  • la sfârșitul anteturilor o linie goală este întotdeauna obligatorie (adică două „linii noi” consecutive)
  • părțile identificate cu [...] indică părțile omise

Solicitare GET și răspuns de succes

Obțineți resursa web prezentă la adresa URL https://it.wikipedia.org/wiki/Pagina_principale

GET / wiki / HTTP main_page / 1.1
Gazdă : it.wikipedia.org
User-Agent : Mozilla / 5.0 (compatibil; Konqueror / 3.2; Linux) (KHTML, cum ar fi Gecko)
Acceptați : text / html, image / jpeg, image / png, text / *, image / *, * / *
Accept-Charset : iso-8859-1, utf-8; q = 0,5, *; q = 0,5
Accept-Language : it
Conexiune : Keep-Alive

Răspuns reușit (200 OK):

 HTTP / 1.1 200 OK
Date : vineri, 22 februarie 2019 10:50:37 GMT
Tip conținut : text / html; charset = UTF-8
Lungime conținut : 22208
Conexiune : păstrați-vii
Server : mw1215.eqiad.wmnet
Limbajul conținutului : it
Codificare conținut : gzip
Ultima modificare : vineri, 22 februarie 2019 08:46:20 GMT
Vârstă : 20548
Control cache : privat, s-maxage = 0, max-age = 0, trebuie revalidat
Variați : Acceptare-codificare, cookie-uri, autorizare
[...]
 
<! DOCTYPE html>
< html class = "client-nojs" lang = "it" dir = "ltr" >
< cap >
< meta charset = "UTF-8" />
< title > Wikipedia, enciclopedia liberă </ title >
[...]
</ body >
</ html >

Solicitare GET și răspuns de redirecționare permanentă

Aici clientul preia adresa URL http://it.wikipedia.org/wiki/Pagina_principale (diferă de cea anterioară ca http în loc de https).

Cererea rămâne aceeași ca în exemplul anterior.

Răspunsul se modifică afișând un cod de mutare permanent (301 mutat permanent):

 HTTP / 1.1 301 mutat permanent
Data : Miercuri, 19 aprilie 2017 16:50:43 GMT
Server : Lac
Locație : https://it.wikipedia.org/wiki/Pagina_principale
Lungime conținut : 0
Conexiune : păstrați-vii

Solicitare POST și răspuns de redirecționare temporară

Aceasta este o cerere POST pentru a vă schimba preferințele Wikipedian cu tema „Albastru de colonie” ( șirul & wpskin = cologneblue din prima linie a corpului de solicitare POST)

 POST / wiki / Special: Preferințe HTTP / 1.1
Gazdă : it.wikipedia.org
User-Agent : Mozilla / 5.0 (compatibil; Konqueror / 3.2; Linux) (KHTML, cum ar fi Gecko)
Acceptați : text / html, image / jpeg, image / png, text / *, image / *, * / *
Accept-Charset : iso-8859-1, utf-8; q = 0,5, *; q = 0,5
Accept-Language : it
Conexiune : Keep-Alive
Control cache : fără cache
Lungimea conținutului : 1291
Tipul conținutului : application / x-www-form-urlencoded
 
wplanguage = ro & wpgender = necunoscut & wpnickname = & wpdisablemail = 1 & wpskin = coloniablue & wppopups = 0 & wpdate = implicit & wpServerTime = 1034 & wptimecorrection = Sistem% 7C120 & wptimecorrection-other = 02% 3A00 & wpimages = 2 & wpmultimediaviewer-enable = 1 & wpunderline = 2 & wpstubthreshold = 0 & wpmath = mathml & wpcompact-language-links = 1 & wpeditfont = implicit & wpuseeditwarning = 1 & wpshowtoolbar = 1 & wpusebetatoolbar = 1 & wpusebetatoolbar-c & wppreviewontop = 1 & wprcdays = 7 & wprclimit = 50 & wphidecategorization = 1 & wpwatchlistdays = 3 & wpwllimit = 250 & wpwatchlisthidecategorization = 1 & wpcirrussearch-pref-complete-profile = fuzzy & wpgadgets% 5B% 5D = Hidden % 5D = OpenStreetMap & wpgadgets% 5B% 5D = ReferenceTooltips & wpgadgets% 5B% 5D = WikiMiniAtlas & wpgadgets% 5B% 5D = ExternalSearch & wpecho-email-frequency = 0 & wpecho-email-format = html & wpecho-subscriptions% 5B % 5D = email-edit-user-talk & wpecho-subscriptions% 5B% 5D = web-edit-thank & wpecho subscriptions% 5B% 5D = web-flow-discussion & wpecho-subscriptions% 5B% 5D = web-mention & wpecho-subscriptions% 5B% 5D = web-user-rights & wpecho-subscriptions% 5B% 5D = email-user-rights & wpecho-subscriptions% 5B% 5D = web-reverted & wpecho-subscriptions% 5B% 5D = web-emailuser & wpecho-cross-wiki-notifications = 1 & wpecho -show-alert = 1 & wpEdit588129009809809809807897809807897897897897 2B% 5C & title = Special% 3APreferences & wpenotifusertalkpages

Răspunsul HTTP de redirecționare temporară (302 găsit) duce la pagina de autentificare

 HTTP / 1.1 302 găsit
Data : Miercuri, 19 aprilie 2017 17:21:16 GMT
Tip conținut : text / html; charset = utf-8
Lungime conținut : 0
Conexiune : păstrați-vii
Server : mw2224.codfw.wmnet
Variați : Accept-Coding, X-Forwarded-Proto, Cookie, Autorizare
Expiră : joi, 01 ianuarie 1970 00:00:00 GMT
Locație : https://it.wikipedia.org/w/index.php?title=Speciale:Entra&returnto=Speciale%3APreferenze&returntoquery=&warning=prefsnologintext2
Vârsta : 0
Control cache : privat, s-maxage = 0, max-age = 0, trebuie revalidat

Cereri utile în versiunea 1.0

GET / HTTP / 1.0

GET în versiunea HTTP / 1.0 este convenabil pentru profesori, se poate face cu o singură linie, deoarece în versiunea 1.0 a protocolului nu era obligatoriu să introduceți antetul „Host:”

Pentru a efectua acest lucru, faceți:

 GET / HTTP / 1.0

Nu uitați să lăsați o linie goală după cerere. Așteptați răspunsul de la serverul web ...

HEAD / HTTP / 1.0

De asemenea, este foarte convenabil să faceți cererea HEAD a protocolului care returnează numai anteturile cu:

 HEAD / HTTP / 1.0

Versiuni sigure

Deoarece tot traficul HTTP este anonim și are un text clar , au fost dezvoltate mai multe alternative pentru a garanta diferite niveluri de securitate , în ceea ce privește

Prima propunere a venit direct de la NCSA , cu versiunile de server 1.1 și client 2.2 care susțin un mecanism de autentificare a utilizatorului și de criptare a datelor bazat pe mesaje în format PEM și chei PGP .

Ulterior, două versiuni sigure ale protocolului HTTP numite SHTTP și HTTPS au fost standardizate. Primul, modelat pe poștă criptată S / MIME , a căzut acum în uz și oferă mecanisme criptografice la nivelul sarcinii utile : cererile și antetele sunt schimbate în text clar, în timp ce conținutul paginii este criptat ca o structură MIME multipart . În schimb, mecanismul HTTPS, inventat de Netscape , folosește canalul criptat al stratului de transport subiacent utilizând SSL sau TLS pentru a preveni interceptarea oricărei părți a tranzacției. Ambele protocoale pot garanta identitatea expeditorului, dar numai SHTTP poate garanta și integritatea conținutului după ce, de exemplu, l-a stocat pe un disc.

Streaming HTTP

Utilizarea materialului multimedia pe paginile WEB, cum ar fi audio sau video, este gestionată într-un mod complet similar cu descărcarea fișierelor, printr-o încărcare progresivă sau distribuție progresivă , în care fișierul este descărcat progresiv de la început până la sfârșit (prin Real Time Protocol de streaming și Protocol de transport în timp real ) și dacă rata de biți este excesivă pentru rețeaua care îl transportă, poate avea loc o reîncărcare continuă a bufferului

Pentru a evita aceste probleme există și alte sisteme alternative, care permit adaptarea fișierului la rețeaua utilizatorului final, aceste sisteme se caracterizează prin protocoale:

Pe de altă parte, aceste soluții sunt considerabil mai complexe decât tehnologiile tradiționale de streaming. Unele dintre considerațiile documentate se referă la stocare, costuri suplimentare de codificare și dificultatea de a menține calitatea generală. Au existat, de asemenea, unele dinamici interesante găsite în jurul interacțiunilor complexe între logica adaptivă a ratei de biți care concurează cu logica complexă de control al fluxului TCP. [7] [8]

Notă

  1. ^ (EN) RFC 1945 pe Internet Engineering Task Force .
  2. ^ (EN) RFC 2068 pe Internet Engineering Task Force .
  3. ^ (EN) RFC 2616 pe Internet Engineering Task Force .
  4. ^ (EN) RFC 7540 pe Internet Engineering Task Force .
  5. ^ IIS Smooth Streaming Technical Arhivat 5 iunie 2011 la Internet Archive .
  6. ^ Smooth Streaming
  7. ^ An Experimental Evaluation of Rate-Adaptation Algorithms in Adaptive Streaming over HTTP Arhivat 17 octombrie 2011 la Internet Archive .
  8. ^ Este rata de biți adaptivă drumul din cărămidă galbenă sau aurul prostului pentru streaming HD? , pe fierceonlinevideo.com . Adus la 20 septembrie 2011 (arhivat din original la 7 septembrie 2011) .

Bibliografie

Elemente conexe

Alte proiecte

linkuri externe

Controlul autorității LCCN (EN) sh97000529 · GND (DE) 4479982-2 · BNF (FR) cb12556450f (data)
Adus de la „ https://it.wikipedia.org/w/index.php?title=Hypertext_Transfer_Protocol&oldid=121404642 ”