Caracteristicile protocolului HTTP. Vedeți ce este „HTTP” în alte dicționare

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 strat 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.site/

În consecință, tu, ca browser web, acum trebuie să te conectezi la serverul web de la alizar.site.

Pentru a face acest lucru, puteți utiliza orice utilitar adecvat de linie de comandă. De exemplu, telnet:

Telnet alizar.site 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 solicitare 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 într-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..ru sau m.. Cu toate acestea, de fapt, conexiunea la rețea se deschide în toate cazurile cu nodul 212.24.43.44, și chiar dacă inițial la deschiderea conexiunii nu era această adresă IP, ci un nume de domeniu care a fost specificat, apoi serverul raportează că acest lucru nu este informat în niciun fel - și de aceea această adresă trebuie trecută î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 început 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:

• http
• alizar
• spdy

Adaugă etichete

Scopul prelegerii: formați o înțelegere a funcționării protocolului HTTP/HTTPS.

HTTP (HyperText Transfer Protocol) este unul dintre cele mai importante protocoale care permite transferul de date prin Internet. Protocolul HTTP este situat la al șaptelea strat de aplicație al modelului OSI și funcționează pe baza protocolului TCP.

Deoarece protocolul HTTP se află la nivelul aplicației, aplicațiile de aplicație îl pot folosi direct pentru a organiza comunicarea în rețea. În plus, protocolul HTTP este o parte critică a aplicațiilor web. În acest caz, browserul, folosind capabilitățile HTTP, interacționează cu serverul pentru a obține datele necesare.

Protocolul HTTP implică transferul de date în modul „cerere-răspuns”.. Mai mult, în cadrul unei astfel de interacțiuni pot fi transmise date de aproape orice tip - text simplu, hipertext (HTML), foi de stil, scripturi client, imagini, documente în diferite formate, informații binare etc.

În cadrul protocolului HTTP, există întotdeauna o distincție clară între client și server. Clientul este întotdeauna inițiatorul interacțiunii. Serverul, la rândul său, ascultă toate conexiunile de intrare și procesează fiecare dintre ele. Deoarece comunicarea HTTP funcționează pe bază de cerere-răspuns, trebuie generată o solicitare HTTP pentru a iniția o sesiune de transfer de date. Ca parte a acestei solicitări, clientul descrie ce resursă dorește să primească de la server și, de asemenea, specifică diverși parametri suplimentari. După aceasta, cererea este trimisă către server și acesta, la rândul său, procesează cererea și generează un răspuns HTTP, care conține informații despre serviciu și conținutul resursei care a fost solicitată. În general, procesul poate fi descris schematic după cum urmează.

O solicitare HTTP și un răspuns HTTP sunt similare ca structură și sunt apelate Mesaje HTTP. De fapt, toată comunicarea în cadrul protocolului HTTP se reduce la redirecționarea mesajelor HTTP. Fiecare mesaj HTTP este informație text simplu prezentată într-un format specific. Să aruncăm o privire mai atentă la formatul mesajului HTTP.

Fiecare mesaj HTTP este format din mai multe linii. Prima linie este întotdeauna linia de bun venit, diferă semnificativ pentru o solicitare HTTP și un răspuns HTTP. De obicei, conține informații generale despre cerere. După prima linie dintr-un mesaj HTTP există antete HTTP - fiecare antet se află pe o linie nouă. Antetele HTTP sunt prezente atât în ​​cererea HTTP, cât și în răspunsul HTTP. Scopul antetelor HTTP este de a clarifica mesajul HTTP, astfel încât partea care primește acest mesaj HTTP să poată procesa mai precis mesajul primit. Numărul de anteturi ale mesajelor HTTP este variabil și depinde de mesajul HTTP specific. Dacă partea expeditoare consideră că acest antet HTTP este necesar în acest mesaj HTTP, atunci îl adaugă, dacă nu, atunci nu îl adaugă. Fiecare antet HTTP începe pe o linie nouă. Un antet HTTP constă dintr-un nume și o valoare, iar numele antetului îi definește scopul. Setul de anteturi HTTP este urmat de o linie goală, urmată de corpul mesajului HTTP. Astfel, structura generală a unui mesaj HTTP poate fi reprezentată după cum urmează.

Solicitare HTTP este generat pe client și trimis către server pentru a primi informații de la acesta. Conține informații despre resursa pe care trebuie să o descărcați, precum și informații suplimentare. Prima linie conține metoda de solicitare (pe care o vom analiza mai târziu în această prelegere), numele resursei (inclusiv calea relativă pe server) și versiunea protocolului. De exemplu, tipul de linie de salut ar putea fi definit ca " GET /images/corner1.png HTTP/1.1". O astfel de solicitare cere serverului să returneze o imagine aflată în folderul " imagini" și numită "corner1.png". Anteturile HTTP sunt importante pentru o solicitare HTTP deoarece indică informații clare despre cerere - versiunea browserului, capacitatea clientului de a accepta conținut comprimat, capabilități de stocare în cache și alți parametri importanți care pot afecta formarea unui răspuns. . Corpul unei solicitări HTTP conține de obicei informații care trebuie transferate pe server , plasarea datelor în corpul solicitării HTTP nu este permisă pentru toate metodele HTTP. De exemplu, corpul unei solicitări HTTP este întotdeauna necompletat dacă se utilizează metoda GET.

În următoarea solicitare HTTP, clientul contactează serverul " microsoft.com", solicită resurse" imagini/colț.png„ și indică faptul că este capabil să accepte conținut comprimat „gzip” sau „deflate”, limba sa este engleza și indică versiunea browserului său. După cum sa menționat mai devreme, numărul și setul de anteturi pot varia semnificativ. Un alt exemplu este HTTP - cerere.

Această solicitare diferă de cea anterioară prin faptul că folosește metoda POST, care încarcă și date pe server. În acest caz, datele în sine sunt conținute în corpul cererii HTTP după o linie goală.

Răspuns HTTP generat de serverul web ca răspuns la o solicitare HTTP primită. Este similară ca structură cu o solicitare HTTP, dar are anumite diferențe. Principala diferență este în prima linie. În loc de numele resursei solicitate și metoda de solicitare, indică starea răspunsului. Starea indică cât de reușită a fost solicitarea HTTP. De exemplu, dacă un document este găsit pe server și poate fi emis clientului, atunci starea are valoarea " Bine", ceea ce indică faptul că solicitarea a fost finalizată cu succes. Totuși, pot apărea situații excepționale - de exemplu, documentul nu se află pe server sau utilizatorul nu are drepturi de a primi resursa. Vom lua în considerare un set de diferite stări de răspuns HTTP mesajele mai târziu în această prelegere, prima linie a răspunsului HTTP poate fi „HTTP/1.1 200 în răspunsul HTTP sunt, de asemenea, un element important , aceste antete HTTP pot conține informații despre tipul de conținut (document HTML, imagine etc.), lungimea conținutului (dimensiunea în octeți), data modificării, modul cache etc. Toate aceste antete afectează modul în care sunt afișate datele. client și, de asemenea, setați reguli pentru stocarea datelor în memoria cache a clientului. Un răspuns HTTP tipic ar putea arăta astfel.

În exemplul de mai sus, serverul indică faptul că resursa a fost găsită, tipul acesteia este un document HTML și indică, de asemenea, dimensiunea și data modificării. După linia goală vine conținutul documentului HTML, adică. în esență ceea ce a cerut clientul. Ca și în cazul unei cereri HTTP, numărul de anteturi dintr-un răspuns HTTP poate varia la discreția serverului web.

Când sa luat în considerare structura unei solicitări HTTP, conceptul a fost atins Metoda de solicitare HTTP. Metoda de solicitare HTTP determină modul în care va fi procesată cererea HTTP specificată, de exemplu. într-un anumit sens îi determină semantica. Deoarece cererile HTTP pot avea o mare varietate de semnificații, specificarea metodei este o parte importantă a construirii unei cereri HTTP. Solicitările HTTP pot avea următoarele semnificații: solicitarea unei resurse de pe server, crearea sau modificarea unei resurse pe server, ștergerea unei resurse de pe server etc.

Cele mai comune metode de solicitare HTTP sunt următoarele tipuri de metode:

OBȚINE	vă permite să primiți informații de la server, corpul cererii rămâne mereu gol;
CAP	similar cu GET, dar corpul răspunsului rămâne întotdeauna gol, vă permite să verificați disponibilitatea resursei solicitate și să citiți anteturile HTTP ale răspunsului;
POST	vă permite să încărcați informații pe server, în esență schimbă resursa de pe server, dar este adesea folosit pentru a crea o resursă pe server, corpul cererii conține resursa în curs de modificare/creare;
A PUNE	similar cu POST, dar în esență este implicat în crearea unei resurse, mai degrabă decât în ​​modificarea acesteia, corpul cererii conține resursa creată;
ȘTERGE	elimină o resursă de pe server.

În plus față de aceste metode HTTP, există un număr mare de alte metode definite în specificația protocolului HTTP. Cu toate acestea, în ciuda acestui fapt, browserele folosesc adesea doar metodele GET și POST. Cu toate acestea, alte aplicații pot utiliza metode HTTP la discreția lor.

După cum am văzut mai devreme, răspunsul HTTP conține codul de stare sau cod de retur. Această stare arată starea răspunsului HTTP care a fost primit de la server. Acest mecanism este necesar pentru funcționarea protocolului HTTP, deoarece pot apărea diverse situații non-standard la procesarea unei cereri. Toate codurile de stare sunt numere din trei cifre. În plus, răspunsul HTTP poate conține o descriere text a stării. Toate codurile de stare sunt împărțite în cinci grupuri.

Fiecare grup de coduri de stare identifică situația în care s-a găsit solicitarea. Grupul este determinat de prima cifră a codului de stare. De exemplu, codurile de stare ale grupului 2xx indică succesul solicitării HTTP. Cele mai frecvent utilizate coduri de stare sunt prezentate în tabelul de mai jos.

Cod		Descriere
1xx		Codurile de informații
2xx		Finalizarea cu succes a cererii
	200	Solicitarea a fost procesată cu succes
	201	Obiect creat
	202	Informații acceptate
	203	Informații care nu sunt de încredere
	204	Fara continut
	205	Resetați conținutul
	206	Conținut parțial (de exemplu, la „descărcarea” fișierelor)
3xx		Redirecționare (este necesară o acțiune pentru a finaliza solicitarea)
	300	Mai multe opțiuni din care să alegeți
	301	Resursa este mutată permanent
	302	Resursa mutată temporar
	303	Vedeți o altă resursă
	304	Conținutul nu s-a schimbat
	305	Utilizați un server proxy
4xx		Problema nu este cu serverul, ci cu cererea
	400	Cerere invalida
	401	Fără permisiunea de a vizualiza resursa
	402	Este necesară plata
	403	Accesul este interzis
	404	Resursa nu a fost găsită
	405	Metodă nevalidă
	406	Cerere nepotrivită
	407	Este necesară înregistrarea pe un server proxy
	408	Procesarea cererii a expirat
	409	Conflict
	410	Nu mai există resursă
	411	Lungimea necesară
	412	Condiția prealabilă nu este îndeplinită
	413	Elementul solicitat este prea mare
	414	Identificatorul de resurse (URI) este prea lung
	415	Tip de resursă neacceptat
5xx		Erori de server
	500	Internal Server Error
	501	Funcția nu este implementată
	502	Defect de gateway
	503	Serviciu indisponibil
	504	Timpul gateway-ului a expirat
	505	Versiune HTTP neacceptată

Acestea și alte coduri de stare sunt folosite pentru a transmite informații despre starea unei solicitări de la client către server.

O caracteristică distinctivă a protocolului HTTP este că în cadrul acestui protocol informațiile sunt transmise sub formă de text. Aceasta înseamnă că lucrul cu un astfel de protocol este destul de simplu. În plus, inginerii de securitate lasă deschis protocolul HTTP chiar și cu un regim de securitate strict. Prin urmare, implementarea interacțiunii rețelei în cadrul protocolului HTTP este una dintre domeniile promițătoare.

Cu toate acestea, în ciuda simplității protocolului, există o problemă de scurgere a informațiilor transmise. Deoarece informațiile sunt transmise în text simplu, interceptarea acestor informații este destul de simplă. În unele situații, această problemă nu este critică. Cu toate acestea, pentru aplicațiile web care funcționează cu informații confidențiale, acesta este un dezavantaj destul de semnificativ.

Din acest motiv, există o modificare a acestui protocol - HTTPS, adică Protocol HTTP cu suport de criptare.

După cum știți, există algoritmi clasici de criptare puternici care criptează datele pe baza unei chei existente. Aceeași cheie este folosită pentru a cripta și decripta datele - dacă cineva cunoaște cheia informațiilor criptate, atunci o poate decripta. O cheie este o secvență obișnuită de biți de o anumită lungime. Cu cât cheia este mai lungă, cu atât este mai dificil să spargi algoritmul de criptare. Prin urmare, pentru a vă proteja informațiile, trebuie să păstrați secretă cheia de criptare. Cu toate acestea, cum se poate realiza acest lucru în cadrul interacțiunii prin protocolul HTTP? La urma urmei, dacă transmiteți această cheie în text clar, atunci sensul criptării dispare. În acest caz, se utilizează un tip suplimentar de criptare - asimetric. În acest caz, există o pereche de chei - publice și private. Folosind o cheie publică, puteți doar cripta informațiile, iar folosind o cheie privată, o puteți decripta. De obicei, cu această abordare, cheia privată este păstrată secretă, iar cheia publică este disponibilă public. Totuși, algoritmul asimetric este mai lent decât cel simetric, deci este folosit pentru schimbul inițial de chei simetrice. Să ne uităm la întregul algoritm pentru cum funcționează o conexiune HTTP criptată.

Când un client contactează un server printr-un canal securizat, serverul stochează o cheie publică și privată. În momentul inițial de timp, serverul transmite clientului cheia publică de criptare asimetrică. Clientul generează aleatoriu o cheie de criptare simetrică și o criptează folosind cheia publică primită de la server. După aceasta, clientul trimite cheia criptată către server și, în acest moment, clientul și serverul au aceleași chei pentru criptarea simetrică. Urmează interacțiunea HTTP, care este criptată folosind această cheie simetrică. Cheia simetrică rămâne secretă și nu poate fi interceptată deoarece cheia privată (care poate fi folosită pentru a decripta primul mesaj care conține cheia simetrică) rămâne secretă pe server. Astfel, este asigurată confidențialitatea și integritatea datelor transmise prin HTTP

Rezumat scurt

Toate aplicațiile web se bazează pe protocolul HTTP. Protocolul HTTP transmite informații text și funcționează în modul cerere-răspuns. O cerere HTTP și un răspuns HTTP au o structură strict definită - o linie de bun venit, anteturi și un corp de mesaj. Numărul de anteturi HTTP este variabil. Antetele HTTP sunt separate de corpul mesajului printr-o linie goală. Fiecare cerere HTTP este trimisă la server ca parte a unei metode HTTP. Metoda HTTP determină semantica cererii (obține resursa, adaugă, schimbă, șterge etc.). În răspunsul HTTP, pe lângă informațiile de serviciu și datele utile, este trimisă starea cererii, care informează clientul despre succesul cererii. Toate codurile de stare sunt împărțite în grupuri. Deoarece datele transmise prin HTTP pot fi interceptate, aceasta nu asigură confidențialitatea informațiilor transmise. Dacă este necesar un astfel de nivel de securitate, atunci trebuie să utilizați protocolul HTTPS, care oferă criptarea informațiilor transmise pe baza unei combinații de algoritmi de criptare simetrici și asimetrici.

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 hyperlinkului. 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 add-on 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, și 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 (proxy-server) sunt un program intermediar care îndeplinește atât funcțiile unui client, cât și ale unui server pentru 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 la conectarea rețelelor locale la Internet.

Gateway - ca un server proxy, difuzează 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. Cu toate acestea, 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 de spațiu (cod ASCII 20h, denumit în continuare SP) și se termină cu o combinație de două caractere: retur 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.

Protocolul de transfer hipertext HTTP (RFC 1945, 2068) este conceput pentru a transfera documente hipertext de la un server la un client. Protocolul HTTP este un protocol de nivel de aplicație. Conform RFC, protocolul său de transport trebuie să fie un protocol orientat spre conexiune care transferă datele în mod fiabil și nu păstrează granițele dintre mesaje. În practică, în marea majoritate a cazurilor, protocolul de transport pentru HTTP este TCP, serverul HTTP (server Web) așteaptă o conexiune din partea clientului, standard pe portul TCP 80, iar clientul HTTP (browser Web) inițiază conexiunea.

În termeni web, tot ceea ce poate accesa un utilizator - documente, imagini, programe - se numește resurse. Fiecare resursă are o adresă unică pentru Web, numită un identificator universal de resurse (URI - Universal Resource Identifier). În cel mai general caz, URI-ul arată astfel:

protocol://utilizator:parolă@gazdă:port/cale/fișier?paremeters#fragment

Câmpurile URI individuale au următoarea semnificație:

protocol - protocol de aplicație prin care se accesează resursa;

utilizator - utilizatorul în numele căruia este accesată resursa sau utilizatorul însuși ca resursă;

parola - parola de utilizator pentru autentificare la accesarea resursei;

gazdă - adresa IP sau numele serverului pe care se află resursa;

port - numărul portului pe care rulează serverul, oferind acces la resursă;

cale - calea către fișierul care conține resursa;

fișier - fișier care conține resursa;

parametri - parametrii de prelucrare de către programul-resursă;

fragment - punctul din fișier de la care ar trebui să fie afișată resursa.

Interacțiunea dintre client și serverul Web se realizează prin schimbul de mesaje. Mesajele HTTP sunt împărțite în solicitări client către server și răspunsuri server către client.

Mesajele de solicitare și răspuns au un format comun. Ambele tipuri de mesaje arată astfel: mai întâi există o linie de început, apoi poate unul sau mai multe câmpuri de antet, numite și antete, apoi o linie goală (adică o linie formată din caracterele CR și LF), care indică sfârșitul din câmpurile antetului și apoi, eventual, corpul mesajului:

linia de start

câmpul antet 1

câmpul antet 2

câmpul antet N

Conținutul mesajului

Formatele liniei de pornire client și server diferă și vor fi discutate mai jos. Există patru tipuri de titluri:

anteturi generale, care pot fi prezente atât în ​​cerere, cât și în răspuns;

anteturile cererii, care pot fi prezente doar în cerere;

anteturi de răspuns, care pot fi prezente numai în răspuns;

anteturile de entitate, care se referă la corpul mesajului și descriu conținutul acestuia.

Fiecare antet constă dintr-un titlu, un caracter două puncte „:” și o valoare. Cele mai importante titluri sunt prezentate în tabel. 1.

tabelul 1
Antetele protocolului HTTP
Titlu	Scop
Anteturi obiect
	Listează metodele acceptate de server
Codificarea conținutului	Modul în care este codificat corpul mesajului, de exemplu pentru a reduce dimensiunea
	Lungimea mesajului în octeți
	Tipul de conținut și eventual câțiva parametri
	O etichetă unică de resurse pe server care vă permite să comparați resurse
	Data și ora la care resursa de pe server se va modifica și va trebui recuperată din nou
	Data și ora la care conținutul a fost modificat ultima dată
Antete de răspuns
	Numărul de secunde după care solicitarea trebuie repetată pentru a obține conținut nou
	URI-ul resursei de accesat pentru a obține conținutul
	Data și ora sau numărul de secunde după care cererea trebuie repetată pentru a obține un răspuns de succes
	Numele software-ului server care a trimis răspunsul
Antete de solicitare
	Tipuri de conținut pe care clientul le „înțelege” și pe care le poate reda
	Codificări de caractere în care clientul poate accepta conținut text
	Modul în care serverul poate codifica mesajul
	Numărul gazdei și portului de la care este solicitat documentul
Dacă-Modificat-De vreme ce Dacă-Nemodificat-De vreme ce	Antete de solicitare pentru acces condiționat la resurse
	Solicitați o parte dintr-un document
	Nume software client
Titluri generale
	Indică serverului să închidă sau să mențină sesiunea în viață
	Data și ora la care a fost generat mesajul

O descriere detaliată a antetelor HTTP/1.0 poate fi găsită în RFC 2068.

Corpul mesajului conține informațiile reale care sunt transmise - sarcina utilă a mesajului. Corpul mesajului este o secvență de octeți (octeți). Corpul mesajului poate fi codificat, de exemplu, pentru a reduce cantitatea de informații transmise, iar metoda de codificare este indicată în antetul obiectului Content-Encoding.

Un mesaj de solicitare de la un client către un server constă dintr-o linie de solicitare, anteturi (general, cereri, obiect) și, eventual, un corp de mesaj. Linia de solicitare începe cu metoda, urmată de identificatorul resursei solicitate, versiunea protocolului și caracterele de final de linie:

<Метод> <Идентификатор> <Версия HTTP>

Metoda specifică o comandă de protocol HTTP pentru a se aplica resursei solicitate. De exemplu, metoda GET indică faptul că clientul dorește să recupereze conținutul unei resurse. Identificatorul identifică resursa solicitată. Versiunea HTTP este indicată printr-o linie ca aceasta:

HTTP/<версия>.<подверсия>

RFC 2068 introduce protocolul HTTP/1.1.

Să ne uităm la principalele metode ale protocolului HTTP.

Metoda OPȚIUNI solicită informații despre opțiunile de conectare (de exemplu, metode, tipuri de documente, codificări) pe care serverul le suportă pentru resursa solicitată. Această metodă permite unui client să specifice opțiunile și/sau cerințele asociate cu o resursă sau cu capabilitățile serverului fără a efectua nicio acțiune asupra resursei sau a determina încărcarea acesteia.

Dacă răspunsul serverului nu este un mesaj de eroare, atunci anteturile obiectelor conțin informații care pot fi considerate opțiuni de conexiune. De exemplu, antetul Allow listează toate metodele acceptate de server pentru o anumită resursă.

Dacă identificatorul de resursă solicitat este un asterisc (“*”), atunci cererea OPȚIUNI este destinată să se adreseze serverului în întregime.

Dacă ID-ul resursei solicitate nu este un asterisc, atunci solicitarea OPȚIUNI se aplică opțiunilor care sunt disponibile la conectarea la resursa specificată.

Metoda GET vă permite să obțineți orice informație legată de resursa solicitată. În cele mai multe cazuri, dacă ID-ul resursei solicitat indică un document (de exemplu, document HTML, document text, grafic, video), atunci serverul returnează conținutul acelui document (conținutul fișierului). Dacă resursa solicitată este o aplicație (program) care generează unele date în timpul funcționării sale, atunci aceste date sunt returnate în corpul mesajului de răspuns, și nu o imagine binară a fișierului executabil. Acesta este folosit, de exemplu, la crearea aplicațiilor CGI. Dacă identificatorul resursei solicitate indică către un director (director, folder), atunci, în funcție de setările serverului, fie conținutul directorului (lista de fișiere), fie conținutul unuia dintre fișierele aflate în acest director (de obicei index.html sau Default.htm). Când vi se solicită un folder, numele acestuia poate fi sau nu indicat cu un „/” la sfârșit. Dacă acest caracter nu este prezent la sfârșitul identificatorului de resursă, serverul emite unul dintre răspunsurile de redirecționare (cu codurile de stare 301 sau 302).

O variantă a metodei GET este „GET condiționat”, în care mesajul de solicitare include anteturi de solicitare If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match sau If-Range. Metoda GET condiționată solicită transferul unui obiect numai dacă îndeplinește condițiile descrise în anteturile date. De exemplu, dacă este prezent antetul If-Modified-Since, conținutul resursei solicitate va fi preluat numai dacă nu s-a schimbat de la momentul specificat ca valoare a acestui antet. Metoda GET condiționată este menită să reducă încărcarea inutilă a rețelei, deoarece evită reîncărcarea datelor deja salvate de client.

Există, de asemenea, un „GET parțial” în care mesajul de solicitare include un antet de solicitare Range. Un GET parțial solicită ca doar o parte a unui obiect să fie transferată. Metoda GET parțială este concepută pentru a reduce supraîncărcarea inutilă a rețelei prin solicitarea doar a unei părți a unui obiect atunci când o altă parte a fost deja descărcată de client. Valoarea antetului Range este șirul „bytes=" urmat de intervalul de octeți care trebuie recuperați. Octeții sunt numerotați începând de la 0. Octeții de început și de sfârșit ai intervalului sunt separați printr-un caracter „–”. Atât octeții de început, cât și de sfârșit din interval pot lipsi. Dacă trebuie să obțineți mai multe intervale, acestea sunt listate separate prin virgule. Dacă unele dintre intervalele listate se intersectează, serverul le îmbină. Mesajul de răspuns pentru o solicitare GET parțială trebuie să conțină un antet Content-Range care specifică intervalul care trebuie transmis. Dacă serverul trimite mai multe intervale care nu se suprapun, antetul Content-Type ia valoarea specială „multypart/byteranges”. Corpul mesajului este împărțit în părți separate printr-un separator generat de server și transmis ca parametru de antet Content-Type. Fiecare parte individuală conține propriile sale anteturi Content-Type și Content-Range, cu o linie goală înainte de conținutul intervalului.

Metoda HEAD este identică cu GET, cu excepția faptului că serverul nu returnează corpul mesajului în răspuns. Informațiile conținute în anteturile HTTP ale unui răspuns la o solicitare HEAD sunt identice cu informațiile furnizate ca răspuns la o solicitare GET pentru aceeași resursă. Această metodă poate fi folosită pentru a obține informații despre un obiect de solicitare fără a trece direct corpul obiectului. Metoda HEAD poate fi folosită pentru a testa legăturile hipertext.

Metoda POST este utilizată pentru o cerere în care serverul adresat acceptă datele incluse în corpul mesajului de cerere (obiect) și le trimite către aplicația specificată ca resursă solicitată pentru procesare. POST este conceput pentru a implementa următoarele funcții într-un mod general:

adnotarea resurselor existente;

postarea unui mesaj pe un sistem de buletin board (BBS), grupuri de știri, liste de corespondență sau un grup similar de articole;

transferul unui bloc de date, de exemplu rezultatul unei intrări într-un formular, către un proces de prelucrare;

executarea de interogări către baze de date;

De fapt, funcția îndeplinită de metoda POST este determinată de aplicația la care se indică ID-ul resursei solicitate. Alături de metoda GET, metoda POST este utilizată la crearea aplicațiilor CGI. Browserul poate emite solicitări cu metoda POST atunci când trimite formulare. Pentru a face acest lucru, elementul FORM al documentului HTML care conține formularul trebuie să aibă un atribut de metodă cu valoarea POST.

O aplicație inițiată de POST poate efectua o acțiune pe server și nu returnează niciun conținut ca rezultat. În funcție de faptul dacă răspunsul include un corp de mesaj care descrie rezultatul sau nu, codul de stare din răspuns poate fi fie 200 (OK) fie 204 (Fără conținut).

Dacă resursa de pe server a fost creată, răspunsul conține un cod de stare 201 (Creat) și include un antet de răspuns Locație.

Corpul mesajului care este trimis într-o cerere PUT este stocat pe server, iar identificatorul resursei solicitate va fi identificatorul documentului stocat. Dacă identificatorul de resurse solicitat indică o resursă deja existentă, atunci obiectul inclus în corpul mesajului este tratat ca o versiune modificată a resursei situate pe server. Dacă a fost creată o nouă resursă, serverul notifică agentul utilizator răspunzând cu codul de stare 201 (Creat).

Diferența dintre metodele POST și PUT este valoarea ID diferită a resursei solicitate. URI-ul din cererea POST identifică resursa care procesează obiectul inclus în corpul mesajului. Această resursă ar putea fi aplicația care primește datele. În schimb, URI-ul dintr-o cerere PUT identifică entitatea inclusă în cerere ca fiind corpul mesajului, adică agentul utilizator atribuie URI-ul dat resursei incluse.

Metoda DELETE solicită serverului să șteargă o resursă care are ID-ul solicitat. O solicitare cu această metodă poate fi respinsă de server dacă utilizatorul nu are drepturi de a șterge resursa solicitată.

Metoda TRACE este utilizată pentru a returna cererea transmisă la nivel de protocol HTTP. Destinatarul cererii (serverul Web) trimite mesajul primit înapoi clientului ca corp al unui mesaj de răspuns cu un cod de stare 200 (OK). Solicitarea TRACE nu trebuie să conțină un corp de mesaj.

TRACE permite clientului să vadă ce primește serverul la celălalt capăt și să utilizeze aceste date pentru testare sau diagnosticare.

Dacă cererea are succes, răspunsul conține întregul mesaj de solicitare în corpul mesajului de răspuns, iar antetul obiectului Content-Type este „message/http”.

Informații detaliate despre metodele de protocol HTTP/1.1 pot fi găsite în RFC 2068.

După primirea și interpretarea mesajului de solicitare, serverul răspunde cu un mesaj de răspuns HTTP.

Prima linie a răspunsului este linia de stare. Acesta constă din versiunea protocolului, un cod de stare numeric, o frază explicativă, separate prin spații și caractere de final de linie:

<Версия HTTP> <Код состояния> <Поясняющая фраза>

Versiunea de protocol are aceeași semnificație ca și în cerere.

Elementul Status-Code este un cod întreg din trei cifre (trei cifre) pentru rezultatul înțelegerii și satisfacerii cererii. Motivul-Expresia este o scurtă descriere text a codului de stare. Codul de stare este destinat să fie procesat de software, iar fraza explicativă este destinată utilizatorilor.

Prima cifră a codului de stare determină clasa răspunsului. Ultimele două cifre nu au un rol specific în clasificare. Există 5 semnificații pentru prima cifră:

1xx: Coduri de informații – cererea primită, procesarea continuă.

2xx: Coduri de succes - acțiunea a fost primită, înțeleasă și procesată cu succes.

3xx: coduri de redirecționare - trebuie luate măsuri suplimentare pentru a finaliza solicitarea.

4xx: coduri de eroare client - cererea are o eroare de sintaxă sau nu poate fi finalizată.

5xx: coduri de eroare server - serverul nu poate finaliza o solicitare validă.

Fraze explicative pentru fiecare cod de stare sunt listate în RFC 2068 și sunt recomandate, dar pot fi înlocuite cu altele echivalente fără restricții de protocol. De exemplu, în versiunile localizate în limba rusă ale serverelor HTTP, aceste expresii sunt înlocuite cu cele rusești. În tabel 2 arată codurile de răspuns ale serverului HTTP.

masa 2
Codurile de răspuns ale serverului HTTP
	Sintagma explicativă conform
1xx: coduri de informații
		Continua
2xx: coduri de succes
		Fara continut
		Resetați conținutul
	Conținut parțial	Conținut parțial
3xx: coduri de redirecționare
	Mutat temporar	Mutat temporar
		Nemodificat
4xx: coduri de eroare client
		Cerere greşită
		Neautorizat
		Nu a fost găsit
	metoda nepermisa	Metoda nepermisa
	Solicitare Timeout	Cererea a expirat
		Conflict
	Lungimea necesară	Lungimea necesară
	Entitatea solicitată este prea mare	Obiectul de solicitare este prea mare

Sfârșitul mesei. 2
	Sintagma explicativă conform	Expresie explicativă echivalentă în rusă
5xx: coduri de eroare ale serverului
	Internal Server Error	Internal Server Error
	Neimplementat	Neimplementat
	Serviciu indisponibil	Serviciul nu este disponibil
	Versiunea HTTP nu este acceptată	Versiunea HTTP nu este acceptată

Informații detaliate despre codurile de răspuns și anteturile care însoțesc aceste răspunsuri pot fi găsite în RFC 2068.

Linia de stare este urmată de anteturi (general, răspuns și obiect) și, eventual, un corp de mesaj.

Una dintre cele mai importante funcții ale unui server Web este de a oferi acces la o parte a sistemului de fișiere local. Pentru a face acest lucru, în setările serverului este specificat un anumit director, care este directorul rădăcină pentru acest server Web. Pentru a publica un document, adică pentru a-l pune la dispoziția utilizatorilor care „vizitează” acest server (conectându-se la acesta prin HTTP), trebuie să copiați acest document în directorul rădăcină al serverului Web sau într-unul dintre subdirectoarele acestuia. La conectarea prin HTTP, pe server este creat un proces cu drepturi de utilizator, care, de regulă, nu există cu adevărat, dar este creat special pentru a vizualiza resursele serverului. Prin configurarea drepturilor și permisiunilor unui anumit utilizator, puteți controla accesul la resursele Web.

Vă permite să primiți diverse resurse, cum ar fi documente HTML. Protocolul HTTP stă la baza schimbului de date pe Internet. HTTP este un protocol de comunicare client-server, ceea ce înseamnă că cererile către server sunt inițiate de către destinatar însuși, de obicei un browser web. Documentul final rezultat va fi reconstruit din diferite sub-documente, de exemplu, din text obținut separat, o descriere a structurii documentului, imagini, fișiere video, scripturi și multe altele.

Clienții și serverele comunică prin schimbul de mesaje individuale (mai degrabă decât un flux de date). Mesajele trimise de un client, de obicei un browser web, sunt apelate cereri, iar mesajele trimise de server sunt apelate răspunsuri.

Deși HTTP a fost dezvoltat la începutul anilor 1990, a fost îmbunătățit continuu datorită extensibilității sale. HTTP este un protocol de nivel de aplicație care utilizează cel mai adesea capacitățile unui alt protocol - TCP (sau TLS - TCP securizat) - pentru a-și redirecționa mesajele, dar orice alt protocol de transport de încredere poate fi, teoretic, utilizat pentru a livra astfel de mesaje. Datorită extensibilității sale, este folosit nu numai pentru ca clientul să primească documente hipertext sau imagini și videoclipuri, ci și pentru transmiterea conținutului către servere, de exemplu, folosind formulare HTML. HTTP poate fi folosit și pentru a prelua doar părți ale unui document în scopul actualizării unei pagini web la cerere.

Componentele sistemelor bazate pe HTTP

HTTP este un protocol client-server, adică cererile sunt trimise de o parte - agentul utilizator (sau un proxy în schimb). Cel mai adesea, un browser web acționează ca un agent de utilizator, dar poate fi oricine, de exemplu, un robot care călătorește pe Web pentru a completa și actualiza datele de indexare a paginilor web pentru motoarele de căutare.

Fiecare cerere individuală cerere) este trimis la server, care îl procesează și returnează un răspuns (ing. raspuns). Între aceste solicitări și răspunsuri există numeroși intermediari numiți proxy, care efectuează diverse operațiuni și acționează ca gateway-uri sau cache-uri, de exemplu.

În realitate, între browser și server există mult mai multe dispozitive intermediare diferite care joacă un rol în procesarea cererii: routere, modemuri și așa mai departe. Datorită faptului că Rețeaua este construită pe baza unui sistem de niveluri de interacțiune (straturi), acești intermediari sunt „ascunși” la nivel de rețea și de transport. În acest sistem de straturi, HTTP ocupă stratul superior, care se numește stratul „aplicație” (sau „stratul aplicației”). Cunoașterea straturilor de rețea, cum ar fi prezentarea, sesiunea, transportul, rețeaua, legătura și fizicul, deși este esențială pentru înțelegerea funcționării rețelei și diagnosticarea problemelor potențiale, nu este necesară pentru a descrie și înțelege HTTP.

Client: agent utilizator

Un agent de utilizator este orice instrument sau dispozitiv care acționează în numele unui utilizator. Acest rol aparține în primul rând browserului web; În unele cazuri, agenții utilizator sunt programe care sunt utilizate de ingineri și dezvoltatori web pentru a-și depana aplicațiile.

Browser Mereu este entitatea care inițiază cererea. Serverul nu face niciodată acest lucru (deși în mulți ani de existență a rețelei au fost create mecanisme care pot simula cererile de la server).

Pentru a afișa o pagină web, browserul trimite o solicitare inițială pentru a obține documentul HTML al paginii respective. După aceasta, browserul analizează acest document și solicită fișiere suplimentare necesare pentru afișarea conținutului paginii web (scripturi executabile, informații despre aspectul paginii - foi de stil CSS, resurse suplimentare sub formă de imagini și fișiere video). În continuare, browserul conectează toate aceste resurse pentru a le afișa utilizatorului sub forma unui singur document - o pagină web. Scripturile executate de browser însuși pot primi resurse suplimentare prin rețea în etapele ulterioare ale procesării paginii web, iar browserul actualizează vizualizarea utilizatorului asupra acelei pagini în consecință.

O pagină web este un document hipertext. Aceasta înseamnă că unele părți ale textului afișat sunt link-uri care pot fi activate (de obicei făcând clic pe un buton al mouse-ului) pentru a prelua și, prin urmare, a afișa o nouă pagină web. Acest lucru permite utilizatorului să-și direcționeze agentul utilizator atunci când navighează pe Web. Browserul traduce aceste „indicații de trafic” în solicitări HTTP și, ulterior, interpretează răspunsurile HTTP într-o formă care poate fi citită de utilizator.

server web

Pe cealaltă parte a canalului de comunicație există un server care servește (ing. servi) utilizator, furnizându-i documentele la cerere. Din punctul de vedere al utilizatorului final, serverul este întotdeauna o singură mașină virtuală care generează complet sau parțial un document, deși de fapt poate fi un grup de servere între care încărcarea este echilibrată, adică solicitări de la diferiți utilizatori. sunt redistribuite sau software complexe care interoghează alte computere (cum ar fi servere de cache, servere de baze de date, servere de aplicații de comerț electronic și altele).

Un server nu este neapărat localizat pe o singură mașină și invers - mai multe servere pot fi localizate (găzduite) pe aceeași mașină. Conform versiunii HTTP/1.1 și având un antet gazdă, pot chiar să partajeze aceeași adresă IP.

Proxy

Între browser web și server există un număr mare de noduri de rețea care transmit mesaje HTTP. Datorită structurii lor stratificate, majoritatea funcționează și la rețeaua de transport sau la straturile fizice, devenind transparente pentru nivelul HTTP și reducând potențial performanța. Aceste operații la nivel de aplicație sunt numite proxy . Ele pot fi sau nu transparente (cererile de modificare nu vor trece prin ele) și pot îndeplini multe funcții:

• stocarea în cache (cache-ul poate fi public sau privat, cum ar fi cache-ul browserului)
• filtrare (cum ar fi scanarea antivirus, controlul parental, ...)
• echilibrare a încărcăturii (permite mai multor servere să servească cereri diferite)
• autentificare (controlul accesului la diferite resurse)
• înregistrare (permisiunea de a stoca istoricul tranzacțiilor)

Bazele HTTP

HTTP este simplu

Chiar și cu complexitatea mai mare introdusă în HTTP/2 prin încapsularea mesajelor HTTP în cadre, HTTP este în general simplu și ușor de citit de om. Mesajele HTTP pot fi citite și înțelese de oameni, oferind testare mai ușoară pentru dezvoltatori și complexitate redusă pentru noii utilizatori.

HTTP - extensibil

Antetele HTTP introduse în HTTP/1.0 au făcut ca protocolul să fie ușor de extins și de experimentat. Noua funcționalitate poate fi introdusă chiar printr-un simplu acord între client și server asupra semanticii noului antet.

HTTP este apatrid, dar are o sesiune

HTTP este apatrid: nu există nicio relație între două cereri care sunt executate secvenţial prin aceeași conexiune. Acest lucru implică imediat potențialul de probleme pentru un utilizator care încearcă să interacționeze secvențial cu o anumită pagină, cum ar fi atunci când folosește un coș de cumpărături într-un magazin online. Dar, în timp ce nucleul HTTP este fără stat, cookie-urile permit sesiuni cu stare. Folosind extensibilitatea antetului, cookie-urile sunt adăugate la firul de lucru, permițând sesiunii să partajeze un anumit context sau stare la fiecare solicitare HTTP.

HTTP și conexiuni

Conexiunea este gestionată la nivelul de transport și, prin urmare, depășește în mod fundamental granițele HTTP. Deși HTTP nu necesită ca protocolul de transport de bază să fie bazat pe conexiune, necesită doar fiabilitate, sau niciun mesaj pierdut (adică, cel puțin o reprezentare a erorii). Printre cele mai comune două protocoale de transport pe Internet, TCP este fiabil, în timp ce UDP nu este. HTTP se bazează ulterior pe standardul TCP bazat pe conexiune, chiar dacă o conexiune nu este întotdeauna necesară.

HTTP/1.0 a deschis o conexiune TCP pentru fiecare schimb de cerere/răspuns, cu două dezavantaje importante: deschiderea unei conexiuni necesită schimburi multiple de mesaje și, prin urmare, este lentă, deși devine mai eficientă la trimiterea mai multor mesaje sau la trimiterea regulată a mesajelor: cald conexiunile sunt mai eficiente decât rece.

Pentru a atenua aceste neajunsuri, HTTP/1.1 a introdus pipelining (care s-a dovedit dificil de implementat) și conexiuni persistente: conexiunea TCP de bază poate fi controlată parțial prin antetul Connection. HTTP/2 a făcut următorul pas adăugând multiplexarea mesajelor printr-o conexiune simplă, ajutând la menținerea conexiunii calde și mai eficiente.

Se fac experimente pentru a dezvolta un protocol de transport mai bun, mai potrivit pentru HTTP. De exemplu, Google experimentează cu QUIC, care se bazează pe UDP, pentru a oferi un protocol de transport mai fiabil și mai eficient.

Ce poate fi controlat prin HTTP

Extensibilitatea naturală a HTTP a permis un control mai mare și o funcționalitate mai mare a Web-ului de-a lungul timpului. Cache-ul și metodele de autentificare au fost caracteristici timpurii în istoria HTTP. Pe de altă parte, capacitatea de a relaxa restricțiile inițiale a fost adăugată în anii 2010.

Următoarele sunt funcții comune gestionate cu HTTP.

• 
  Serverul poate instrui proxy-urilor și clienților ce să memoreze în cache și pentru cât timp. Clientul poate instrui proxy cache intermediar să ignore documentele stocate.
• Relaxarea constrângerilor de sursă
  Pentru a preveni programele spion și alte intruziuni care încalcă confidențialitatea, browserul web impune o segregare strictă între site-uri web. Doar pagini din aceeași sursă pot accesa informațiile de pe pagina web. Deși astfel de restricții sunt impunătoare pentru server, anteturile HTTP pot relaxa separarea strictă pe partea serverului, permițând documentului să devină parte a informațiilor din diferite domenii (din motive de securitate).
• Autentificare
  Unele pagini sunt disponibile numai pentru utilizatori speciali. Autentificarea de bază poate fi furnizată prin HTTP, fie prin utilizarea WWW-Authenticate și a antetelor similare, fie prin configurarea unei sesiuni speciale folosind cookie-uri.
• Proxy și tunel
  Serverele și/sau clienții sunt adesea localizați pe un intranet și își ascund adevăratele adrese IP de alții. Solicitările HTTP trec printr-un proxy pentru a trece această barieră de rețea. Nu toți proxy-urile sunt proxy HTTP. Protocolul SOCKS, de exemplu, operează la un nivel inferior. Altele, cum ar fi ftp, pot fi gestionate de acești proxy.
• Sesiuni
  Utilizarea unui cookie HTTP vă permite să asociați o solicitare cu o stare de pe server. Acest lucru creează o sesiune, chiar dacă HTTP este un protocol fără stat la baza sa. Acest lucru este util nu numai pentru coșurile de cumpărături din magazinele online, ci și pentru orice site-uri care permit utilizatorului să personalizeze ieșirea.

Flux HTTP

Când un client dorește să comunice cu un server, fie că este un server final sau un proxy intermediar, urmează acești pași:

1. Deschiderea unei conexiuni TCP: O conexiune TCP va fi folosită pentru a trimite o cerere sau solicitări și pentru a primi un răspuns. Clientul poate deschide o nouă conexiune, poate reutiliza una existentă sau poate deschide mai multe conexiuni TCP la server.
2. Trimiterea unui mesaj HTTP: mesajele HTTP (înainte de HTTP/2) pot fi citite de om. Începând cu HTTP/2, mesajele simple sunt încapsulate în cadre, ceea ce le face imposibil de citit direct, dar rămân în principiu aceleași. GET / HTTP/1.1 Gazdă: site Accept-Language: fr
3. Citește răspunsul de la server: HTTP/1.1 200 OK Data: Sâmbătă, 09 Oct 2010 14:28:02 GMT Server: Apache Ultima modificare: Mar, 01 Dec 2009 20:18:22 GMT ETTag: "51142bc1-7449-479b907" Accept-Range: bytes Content-Length: 29769 Content-Type: text/html
4. Închide sau reutiliza conexiunea pentru solicitări ulterioare.

Dacă conducta HTTP este activată, pot fi trimise mai multe solicitări fără a aștepta primirea în întregime a primului răspuns. Conducta HTTP este dificil de integrat în rețelele existente, unde vechile bucăți de software coexistă cu versiunile moderne. Conducta HTTP a fost înlocuită în HTTP/2 cu cereri multiplexate mai fiabile într-un cadru.

Mesaje HTTP

HTTP/1.1 și mesajele HTTP anterioare pot fi citite de om. În HTTP/2, aceste mesaje sunt încorporate într-o nouă structură binară, un cadru, care permite optimizări precum compresia antetului și multiplexarea. Chiar dacă o parte a mesajului HTTP original este trimisă în această versiune de HTTP, semantica fiecărui mesaj nu este modificată și clientul recreează (practic) cererea HTTP originală. De asemenea, este util pentru înțelegerea mesajelor HTTP/2 în format HTTP/1.1.