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). Baza HTTP este tehnologia „client-server”, adică presupune existența unor consumatori (clienți) care inițiază o conexiune și trimit o solicitare, iar furnizorii (serverele) care așteaptă o conexiune pentru a primi o solicitare, efectuează acțiunile necesare și returnează înapoi un mesaj cu rezultatul.

HTTP este, de asemenea, folosit ca „transport” pentru alte protocoale de nivel de aplicație, cum ar fi SOAP, XML-RPC, WebDAV.

Obiectul principal de manipulare în HTTP este resursa indicată de 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 diverși parametri: format, codificare, limbă etc. Datorită capacității de a specifica metoda de codificare a mesajelor clientul și serverul poate face schimb de date binare, deși acest protocol este text.

HTTP este un protocol de nivel de aplicație, similar cu FTP și SMTP - un protocol simplu de transfer de e-mail. 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 menține în mod independent informațiile de stare legate de solicitările și răspunsurile recente. Browserul care trimite solicitările poate urmări întârzierile de răspuns. Serverul poate stoca adresele IP și poate solicita antetele 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.

Extensibilitate

Protocolul este ușor de extensibil prin injectarea propriilor anteturi, menținând în același timp compatibilitatea cu alți clienți și servere. Ei vor ignora anteturile pe care nu le cunosc, dar pot obține funcționalitatea de care au nevoie pentru anumite sarcini.

HTTP/1.1- versiunea actuală a protocolului. Nou în această versiune a fost un mod „conexiune persistentă”: o conexiune TCP poate rămâne deschisă după ce a fost trimis un răspuns la o solicitare, permițând trimiterea mai multor cereri pe aceeași conexiune. Clientului i se cere acum 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 nu salvează informații despre tranzacții, așa că următoarea tranzacție trebuie să înceapă de la capăt. Avantajul este că serverul HTTP poate deservi mult mai mulți clienți într-o anumită perioadă de timp, deoarece suprasolicitarea sesiunilor de urmărire de la o conexiune la alta este eliminată. Există un dezavantaj: programele CGI mai complexe trebuie să folosească câmpuri de intrare ascunse sau instrumente externe, cum ar fi cookie-urile, pentru a stoca informații despre tranzacție.

Metode de solicitare HTTP

Metoda HTTP- o secvență de orice caractere, cu excepția controlului și a delimitatorilor, care indică operația principală asupra resursei. 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.

Fiecare server trebuie să accepte cel puțin metodele GET și HEAD. 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 este returnat un mesaj 405 (Metoda nu este permisă). În ambele cazuri, serverul TREBUIE să includă un antet Allow cu o listă de metode acceptate în mesajul de răspuns.

Pe lângă metodele GET și HEAD, este adesea folosită metoda POST.

• Anteturile (parametrii) cererii HTTP, răspunsului, entitate

  Toate anteturile din protocolul HTTP sunt împărțite în patru grupuri principale (se recomandă trimiterea antetelor către destinatar în următoarea ordine):

  Anteturi generale(Anteturi principale) - trebuie incluse în orice mesaj client și server.

  Antete de solicitare(Anteturi de solicitare) - Folosit numai în solicitările clientului.

  antete de răspuns(Anteturi de răspuns) - numai pentru răspunsurile de la server.

  Anteturi de entitate(Anteturi de entitate) - însoțesc fiecare entitate de mesaj. Anteturile de entitate sunt separate într-o clasă separată pentru a nu fi confundate cu anteturile de solicitare sau cu anteturile de răspuns atunci când se transmite conținut multiplu (MIME).

  Toate anteturile necesare pentru ca HTTP să funcționeze sunt descrise în RFC-urile de bază. Dacă este necesar, vă puteți crea propriile anteturi. În mod tradițional, numele acestor anteturi suplimentare sunt prefixate cu „X-” pentru a evita conflictele de nume cu cele posibile existente.

  Liniile de după șirul de interogare principal (GET /index.html HTTP/1.1) au următorul format: Parametru: valoare. Așa sunt setați parametrii de solicitare. Acest lucru este opțional, toate liniile de după șirul de interogare principal pot lipsi; în acest caz, serverul acceptă valoarea lor implicită sau în funcție de rezultatele solicitării anterioare (când lucrează în modul Conexiune: Keep-Alive).

  Parametru conexiune(conexiune) - poate lua valorile Keep-Alive and close. În HTTP 1.0, transmiterea datelor solicitate de către server este urmată de o deconectare cu clientul, iar tranzacția este considerată finalizată dacă nu este trecut antetul Connection: Keep Alive. În HTTP 1.1, serverul nu închide conexiunea în mod implicit și clientul poate trimite alte solicitări. Deoarece multe documente sunt încorporate cu alte documente - imagini, cadre, applet-uri și așa mai departe - acest lucru economisește timp și costuri pentru client, care altfel ar trebui să se conecteze la același server de mai multe ori pentru a obține o singură pagină. Astfel, în HTTP 1.1, o tranzacție poate trece până când clientul sau serverul închide în mod explicit conexiunea.

  Parametru Agent utilizator- valoarea este „desemnarea codului” a browserului.

  Parametru Accept- o listă de tipuri de conținut acceptate de browser, în ordinea preferințelor acestora de către acest browser.

  Parametru Gazdă- numele domeniului de la care se solicită resursa. Este util dacă serverul are mai multe servere virtuale sub aceeași adresă IP. În acest caz, numele domeniului virtual este determinat din acest câmp.

  Parametru Modificat ultima dată(Ultima modificare) (Ultima modificare W3C) - Data și ora la care documentul a fost modificat ultima dată. Folosindu-l, clientul, asemanator cu cazul ETag-ului, poate contacta serverul cu o solicitare „If-Modified-Since” - in acest caz, serverul trebuie sa compare data ultimei modificari a copiei stocate pe client cu data curentă a ultimei modificări. Dacă se potrivesc, copia din memoria cache a clientului nu este învechită și nu este necesară o redescărcare (codul de răspuns „304 Not Modified”). Last-Modified este, de asemenea, necesar pentru prelucrarea corectă a site-ului de către roboții care folosesc informații despre data modificării paginii pentru a sorta rezultatele căutării după dată, precum și pentru a determina frecvența actualizării site-ului dumneavoastră.

  Pentru documentele SSI, Apache va emite „Last-Modified” dacă este specificată directiva „XBitHack full” (de exemplu, în fișierul .htaccess)

  Parametru ETag(etichetă obiect) - introdus în HTTP 1.1(W3C ETag). ETag este utilizat pentru a atribui un identificator unic fiecărei pagini, a cărui valoare se modifică atunci când pagina (documentul) se modifică. ETag este un hash („amprentă”) al octeților documentului, dacă cel puțin un octet se modifică în document, atunci ETag se va schimba și el. ETag este utilizat atunci când memorarea în cache a unui document. Acest antet este stocat pe client, iar în cazul re-accesării documentului, permite browserului să contacteze serverul cu cererea „If-None-Match”, iar serverul trebuie să determine, după valoarea ETag-ului. etichetă, dacă documentul (pagina) s-a modificat și, dacă nu, răspundeți cu codul „304 Not Modified”.

  Parametru Expiră(expiration) (W3C Expires) - îi spune browserului cât timp se poate considera că copia paginii din cache este proaspătă și nu contactează serverul cu solicitări deloc. Acest lucru este util pentru fișierele despre care știți sigur că nu se vor schimba în următoarea oră/zi/lună: imaginea de fundal a unei pagini, de exemplu.

  Alte anteturi HTTP:

  HTTP_X_FORWARDED_FOR

  HTTP_X_FORWARDED

  HTTP_FORWARDED_FOR

  • HTTP_X_COMING_FROM

    HTTP_COMING_FROM

  • HTTP_X_CLUSTER_CLIENT_IP

  • HTTP_XROXY_CONNECTION

    HTTP_PROXY_CONNECTION

    HTTP_USERAGENT_VIA - proxy

  Exemplu de analiză a cererii HTTP

  O cerere HTTP constă din trei părți: o linie de cerere (răspuns), o secțiune antet, urmată de un corp opțional. Anteturile sunt text simplu, fiecare antet fiind separat de următorul printr-un caracter de linie nouă (\r\n), în timp ce corpul poate fi text sau date binare. Corpul este separat de anteturi prin două linii noi.

  Antetul cererii este format din linia principală (prima) a cererii și liniile ulterioare care rafinează cererea în linia principală. Este posibil să lipsească și rândurile ulterioare.

  Clientul inițiază o tranzacție după cum urmează:

  Clientul comunică cu serverul pe numărul portului alocat, numărul oficial implicit al portului este 80. Clientul trimite apoi o cerere de document, specificând metoda, adresa documentului și numărul versiunii HTTP. De exemplu, în șirul de interogare principal GET /index.html HTTP/1.1

  se folosește metoda GET, care folosește HTTP versiunea 1.1 pentru a solicita documentul index.html.

  Clientul trimite informații de antet (opțional, este necesar antetul gazdei) pentru a spune serverului informații despre configurația sa și formatele de document pe care le poate accepta. Toate informațiile din antet sunt specificate rând cu rând, cu un nume și o valoare pe fiecare linie. De exemplu, următorul antet trimis de un client conține numele clientului și numărul versiunii, precum și informații despre unele dintre tipurile de documente preferate ale clientului: Gazdă: list.mail.ru User-Agent: Mozilla/5.0 (Ubuntu; X11; Linux x86_64; rv :8.0) Gecko/20100101 Firefox/8.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

  Titlul se termină cu o linie goală.

  Prin trimiterea cererii și a anteturilor, clientul poate trimite date suplimentare, de exemplu, pentru scripturi CGI.

  Serverul răspunde la cererea clientului după cum urmează:

  Prima parte a răspunsului serverului este o linie de stare care conține trei câmpuri: versiune HTTP, cod de stare și descriere. Câmpul versiune conține numărul versiunii HTTP pe care acest server îl folosește pentru a trimite răspunsul. Codul de stare este un număr din trei cifre care indică rezultatul cererii clientului procesate de server. Descrierea care urmează codului de stare este pur și simplu text care poate fi citit de om care explică codul de stare. De exemplu, linia de stare HTTP/1.1 304 Not Modified

  indică faptul că serverul utilizează versiunea HTTP 1.1 pentru răspuns. Cod de stare 304 înseamnă că clientul a solicitat documentul folosind metoda GET, a folosit antetul If-Modified-Since sau If-None-Match, iar documentul nu s-a schimbat de la ora specificată.

  După linia de stare, serverul trimite către client informații de antet care conțin informații despre server însuși și documentul solicitat. Iată un exemplu de antet: Data: joi, 15 decembrie 2011 09:34:15 GMT Server: Apache/2.2.21 (Debian) X-Powered-By: PHP/5.3.8-1+b1 Expiră: joi, 19 nov. 1981 08:52:00 GMT Cache-Control: fără stocare, fără cache, revalidare obligatorie, post-verificare=0, pre-verificare=0 Pragma: fără cache Variare: Acceptare codificare Codificare conținut: gzip Keep - Alive: timeout=5, max=100 Conexiune: Keep-Alive Content-Type: text/html; set de caractere=utf-8

  Antetul se termină cu un șir gol.

  Dacă solicitarea clientului are succes, atunci datele solicitate sunt trimise. Aceasta poate fi o copie a unui fișier sau rezultatul unui program CGI. Dacă cererea clientului nu poate fi satisfăcută, se transmit date suplimentare sub forma unei explicații ușor de utilizat a motivelor pentru care serverul nu a putut îndeplini această solicitare.

  Cod de stare HTTP

  Cod de stare HTTP face parte din prima linie a răspunsului serverului. Este un număr întreg de trei cifre. Prima cifră indică clasa 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.

  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:

  1xx: informativ. Codurile de stare informaționale care îi spun clientului că serverul este în proces de procesare a unei cereri. Reacția clientului la aceste coduri nu este necesară;

  2xx: Succes.

  1. 200 OK(Bun). Introdus în HTTP/1.0. Solicitare de resurse reușită. Dacă au fost solicitate date de către client, acestea se află în antetul și/sau corpul mesajului.

  3xx: Redirecționare Codurile de clasă 3xx îi spun clientului că trebuie făcută o altă solicitare (de obicei un URI diferit) pentru ca operațiunea să reușească. Din această clasă, cinci coduri 301, 302, 303, 305 și 307 se referă direct la redirecționări (redirecționare). Adresa la care clientul ar trebui să facă cererea este specificată de server în antetul Locație. Mulți clienți cu redirecționări 301 și 302 aplică în mod greșit metoda GET la a doua resursă, în ciuda faptului că prima solicitare a fost cu o metodă diferită. Pentru a evita confuzia, HTTP/1.1 a introdus codurile 303 și 307 în loc de 302. Trebuie doar să schimbați metoda de solicitare dacă serverul a răspuns cu 303. În alte cazuri, faceți următoarea cerere cu metoda originală.

  1. 302 Găsit(Găsite). Introdus în HTTP/1.0. Documentul solicitat este disponibil temporar la un alt URI specificat în antetul din câmpul Locație.

  4xx: Eroare client. Clasa de cod 4xx este destinată să indice erorile din partea clientului. Când utilizați toate metodele, cu excepția HEAD , serverul trebuie să returneze o explicație hipertext pentru utilizator în corpul mesajului.

  1. 404 Nu a fost gasit. Introdus în HTTP/1.0. Serverul a înțeles cererea, dar nu a găsit o resursă potrivită la URI-ul specificat.

  5xx: Eroare de server

  Legături înrudite HTTP 1.1

  HTTP/2

  HTTP/2 (inițial HTTP/2.0) este a doua versiune majoră a protocolului de rețea HTTP. Protocolul se bazează pe SPDY (protocol compatibil HTTP dezvoltat de Google).

  Protocolul HTTP/2 este binar. Față de standardul anterior, s-au schimbat modalitățile de împărțire a datelor în fragmente și de transportul acestora între server și client.

  În HTTP/2, serverul are dreptul de a trimite conținut care nu a fost încă solicitat de client. Acest lucru va permite serverului să trimită imediat fișiere suplimentare de care browserul va avea nevoie pentru a afișa paginile, fără ca browserul să fie nevoit să analizeze pagina principală și să solicite completările necesare.

Atenția dumneavoastră este invitată la o descriere a principalelor aspecte ale protocolului HTTP - un protocol de rețea care de la începutul anilor 90 și până în prezent permite browserului dumneavoastră să descarce pagini web. Acest articol este scris pentru cei care abia încep să lucreze cu rețele de calculatoare și să dezvolte aplicații de rețea și pentru care este încă dificil 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 vă permit să organizați trecerea către alte documente).

Abrevierea HTTP reprezintă Protocolul de transfer hipertext, „Protocol de transfer hipertext”. Conform specificației OSI, HTTP este un protocol de aplicație (superior, al 7-lea). Versiunea actuală a protocolului, HTTP 1.1, este descrisă în specificația RFC 2616.

Protocolul HTTP presupune utilizarea unei structuri de transfer de date client-server. Aplicația client formează o cerere și o trimite către server, după care software-ul serverului procesează această solicitare, generează un răspuns și îl trimite înapoi clientului. După aceea, aplicația client poate continua să trimită alte solicitări, care vor fi procesate în același mod.

Sarcina 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 este asigurată funcționarea World Wide Web.

HTTP este adesea folosit ca protocol de comunicare pentru alte protocoale de nivel de aplicație, cum ar fi SOAP, XML-RPC și WebDAV. Într-un astfel de 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 regulă, transmisia de date prin protocolul HTTP se realizează prin conexiuni TCP / IP. Software-ul serverului utilizează de obicei portul TCP 80 (și dacă portul nu este specificat în mod explicit, atunci software-ul client utilizează de obicei portul 80 în mod implicit pentru deschiderea conexiunilor HTTP), deși poate fi utilizat orice alt port.

Cum se trimite o solicitare HTTP?

Să presupunem că a introdus următoarele în bara de adrese:

http://alizar.habrahabr.ru/

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

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

Telnet alizar.habrahabr.ru 80

Pentru a clarifica imediat, dacă vă răzgândiți brusc, apăsați Ctrl + „]”, apoi introduceți - acest lucru vă va permite să închideți conexiunea HTTP. Pe lângă telnet, puteți încerca nc (sau ncat) - după gust.

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 forma o cerere HTTP, trebuie să compuneți o linie de pornire și, de asemenea, să setați cel puțin un antet - acesta este antetul Host, care este obligatoriu și trebuie să fie prezent în fiecare solicitare. Faptul este că conversia unui nume de domeniu î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.habrahabr.ru, habrahabr.ru sau m.habrahabr.ru - și în toate aceste cazuri răspunsul poate diferi. Cu toate acestea, de fapt, conexiunea la rețea în toate cazurile este deschisă cu nodul 212.24.43.44, și chiar dacă inițial, la deschiderea conexiunii, nu a fost specificată această adresă IP, ci un nume de domeniu, serverul nu este informat despre acest lucru în în orice fel - și de aceea această adresă este necesară trecerea în antetul Gazdă.

Șirul de interogare de început (inițial) pentru HTTP 1.1 este compus după cum urmează:

De exemplu (o astfel de linie de start 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.

Succes și învățare fericită!

Etichete: Adăugați etichete

Vă permite să obțineți diverse resurse, cum ar fi documente HTML. Protocolul HTTP stă la baza comunicării 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, de obicei un browser web. Documentul final rezultat va fi reconstruit din diferite sub-documente, de exemplu, din text obținut separat, descrierea 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 întrebări, iar mesajele trimise de server sunt apelate răspunsuri.

Deși HTTP a fost dezvoltat la începutul anilor 1990, a evoluat în timp 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 trimite mesajele, totuși, 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 a primi documente hipertext sau imagini și videoclipuri către client, ci și pentru a transfera conținut pe servere, de exemplu, folosind formulare HTML. HTTP poate fi, de asemenea, utilizat pentru a prelua doar porțiuni dintr-un document pentru a actualiza o pagină web la cerere.

Componentele sistemelor bazate pe HTTP

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

Fiecare cerere individuală cerere) este trimis către server, care îl procesează și returnează un răspuns. 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, există mult mai multe dispozitive intermediare între browser și server 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 (straturi) de interacțiune, 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 „aplicație” (sau stratul „aplicație”). 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 de-a lungul anilor de web 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 prelua documentul HTML al paginii. După aceea, 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 plus, 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 acestei 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 obține și, în consecință, afișa o nouă pagină web. Acest lucru permite utilizatorului să-și ghideze agentul utilizator în timp ce navighează pe Web. Browserul traduce aceste „indicații de trafic” în solicitări HTTP și apoi interpretează răspunsurile HTTP într-un mod ușor de utilizat.

server web

Pe cealaltă parte a canalului de comunicație este un server care servește (ing. servi) al utilizatorului, punându-i la dispoziție documente la cerere. Din punctul de vedere al utilizatorului final, serverul este întotdeauna un fel de 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 redistribuiți sau software complex care sondajează alte computere (cum ar fi servere de cache, servere de baze de date, servere de aplicații de comerț electronic și altele).

Serverul nu se află neapărat pe aceeași 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 Host, 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 stratificate, majoritatea funcționează și la rețeaua de transport sau la nivelul fizic, devenind transparente la nivelul HTTP și potențial degradând performanța. Aceste operații la nivelul aplicației sunt numite proxy . Ele pot fi sau nu transparente (cererile de modificare nu vor fi acceptate) și pot îndeplini o varietate de 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ți mai multor servere să servească cereri diferite)
• autentificare (controlul accesului la diferite resurse)
• înregistrare (permisiunea de a stoca istoricul operațiunilor)

Aspecte de bază ale HTTP

HTTP - 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

Introducerea antetelor HTTP în HTTP/1.0 a 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 despre semantica 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 posibilitatea de a avea probleme pentru un utilizator care încearcă să interacționeze cu o anumită pagină în succesiune, cum ar fi atunci când folosește un coș de cumpărături într-un magazin electronic. 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 nivel de transport și, prin urmare, merge dincolo de HTTP. În timp ce 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 reprezentând o eroare). 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, care se bazează 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ă atunci când sunt trimise mai multe mesaje sau când mesajele sunt trimise regulat: cald compușii sunt mai eficienți 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 subiacentă poate fi controlată parțial prin antetul Connection. HTTP/2 a făcut un pas mai departe, adăugând multiplexarea mesajelor printr-o conexiune simplă pentru a menține conexiunea caldă și mai eficientă.

Sunt în curs de desfășurare 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 din istoria HTTP. În schimb, capacitatea de a relaxa restricțiile inițiale a fost adăugată în anii 2010.

Mai jos sunt enumerate caracteristicile 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 cache-urile intermediare proxy să ignore documentele stocate.
• Relaxarea restricțiilor de sursă
  Pentru a preveni programele spion și alte intruziuni în confidențialitate, browserul web impune o separare 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 impun o povară serverului, anteturile HTTP pot slăbi segregarea strictă pe partea de server, 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 antetului WWW-Authenticate și altele asemenea, 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ă nucleul HTTP este un protocol fără stat. Acest lucru este util nu numai pentru coșurile de cumpărături din magazinele online, ci și pentru orice site care permite utilizatorului să personalizeze rezultatul.

Flux HTTP

Când un client dorește să interacționeze cu un server, fie că este un server de destinație sau un proxy intermediar, urmează următorii pași:

1. Deschiderea unei conexiuni TCP: conexiunea TCP va fi utilizată 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: mesaje HTTP (pre-HTTP/2) -- care pot fi citite de om. Începând cu HTTP/2, mesajele simple sunt încapsulate în cadre, făcându-le imposibil de citit direct, dar rămân în principiu aceleași. GET / HTTP/1.1 Gazdă: site Accept-Language: fr
3. Citiți 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ți, 01 decembrie 2009 20:18:22 GMT ETag: "51142bc1-7449-479b07b"b2 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 primului răspuns complet. Conducta HTTP este puternic încorporată în rețelele existente, unde vechile bucăți de software coexistă cu versiunile moderne. Conducta HTTP a fost înlocuită în HTTP/2 cu cereri multiplex mai fiabile într-un cadru.

Mesaje HTTP

HTTP/1.1 și mesajele HTTP anterioare pot fi citite de om. În versiunea HTTP/2, aceste mesaje sunt încorporate într-o nouă structură binară, frame, permițând 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.

6.1 Serviciu WWW

Serviciul WWW (World Wide Web) este destinat schimbului de informații hipertext.

Proiectul a fost propus în 1989. În 1993, a apărut primul browser.

WWW-ul este construit conform schemei „client-server”.

Browser(Internet Explorer, Opera...) este un client multi-protocol și un interpret HTML. Și ca un interpret tipic, clientul îndeplinește diverse funcții în funcție de comenzi (tag-uri). Aceste funcții includ nu numai plasarea textului pe ecran, ci și schimbul de informații cu serverul pe măsură ce textul HTML primit este analizat, ceea ce se întâmplă cel mai clar la afișarea imaginilor grafice încorporate în text.

Server HTTP(Apeche, IIS...) se ocupă de solicitările clienților pentru un fișier (în cel mai simplu caz).

Interacțiunea dintre client și server prin protocolul HTTP.

La început, serviciul WWW se baza pe trei standarde:

HTML (HyperText Markup Language) - limbaj de marcare hipertext a documentelor;

URL (Universal Resource Locator) - o modalitate universală de a aborda resursele din rețea;

HTTP (HyperText Transfer Protocol) este un protocol pentru schimbul de informații hipertext.

CGI (Common Gateway Interface) este o interfață gateway universală. Creat pentru interacțiunea serverului HTTP - cu alte programe instalate pe server (de exemplu, un SGBD).

6.2 Protocolul HTTP

Primul document (dar nu un standard) este RFC1945 (Hypertext Transfer Protocol -- HTTP/1.0 T. Berners-Lee, R. Fielding, H. Frystyk mai 1996)

Câteva caracteristici ale programului:

setarea adâncimii de accesare cu crawlere a site-ului și a linkurilor externe

setarea tipului de fișier (extensie) pentru descărcare, de exemplu, puteți descărca numai elemente grafice.

setați o limită de dimensiune a fișierului.

scanarea plăcilor grafice.

programarea locurilor de muncă, planificator încorporat.

stabilirea numelui clientului, dacă există o restricție pentru unii clienți.

setarea numărului de fișiere descărcate simultan.

Protocolul HTTP sau HyperText Transfer Protocol este principala punctie (a World Wide Web). Sarcina principală a protocolului este de a asigura transmiterea hipertextului în rețea. Protocolul descrie cu precizie formatul mesajelor care urmează să fie schimbate între clienți și servere.

Protocolul HTTP este descris în RFC 2616(HTTP1.1).

Baza protocolului este de a asigura interacțiunea între client și server printr-o cerere ASCII și următorul răspuns la aceasta în standardul RFC 822 MIME.

În practică, protocolul HTTP funcționează pe baza portului 80, dar îl puteți configura diferit. Și deși TCP/IP nu este obligatoriu, rămâne de preferat, deoarece se ocupă de împărțirea și asamblarea mesajelor pe sine și nu „stresează” nici browserul, nici serverul.

Trebuie remarcat faptul că protocolul HTTP poate fi utilizat nu numai în tehnologiile web, ci și în alte aplicații OOP (orientate pe obiective).

URL

Baza comunicării web client-server este o solicitare. Solicitarea este trimisă folosind o adresă URL, Internet Uniform Resource Locator. Permiteți-mi să vă reamintesc ce este o adresă URL.

O structură URL clară și simplă constă din următoarele elemente:

• Protocol;
• gazdă;
• Port;
• catalog de resurse;
• Etichete (Solicitare).

Notă: Protocolul http este un protocol pentru conexiuni simple, nesecurizate. Conexiunile securizate funcționează prin protocolul https. Este mai sigur pentru schimbul de date.

Metode de solicitare HTTP

Unul dintre parametrii URL specifică numele gazdei cu care dorim să comunicăm. Dar acest lucru nu este suficient. Trebuie să determinați acțiunea care trebuie luată. Acest lucru se poate face folosind o metodă definită de protocolul HTTP.

Metode HTTP

• Metoda/Descriere
• HEAD / Citiți titlul paginii web
• GET/Citiți o pagină web
• POST/Adăugați la pagina web
• PUT/Save Web Page
• TRACE/Trimite cererea înapoi
• DELETE / Șterge o pagină web
• OPȚIUNI/Opțiuni de afișare
• CONECTARE/Rezervat pentru utilizare ulterioară

Să aruncăm o privire mai atentă la metodele HTTP

metoda GET. solicită o pagină (fișier, obiect) codificată conform standardului MIME. Aceasta este metoda cea mai folosită. Structura metodei:
GET numele fișierului HTTP/1.1

Metoda HEAD. Această metodă solicită antetul mesajului. În acest caz, pagina nu se încarcă. Această metodă vă permite să aflați ora ultimei actualizări a paginii, care este necesară pentru a gestiona memoria cache a paginii. Această metodă vă permite să verificați funcționalitatea adresei URL solicitate.

Metoda PUT. Această metodă poate pune pagina pe server. Corpul cererii PUT include pagina găzduită, care este codificată MIME. Această metodă necesită identificarea clientului.

metoda POST. Această metodă adaugă conținut unei pagini existente. Folosit ca exemplu pentru a adăuga o intrare pe un forum.

metoda DELETE. Această metodă distruge pagina. Metoda de ștergere necesită confirmarea drepturilor utilizatorului de a șterge.

Metoda TRACE. Această metodă de depanare. Spune serverului să trimită cererea înapoi și vă informează dacă cererea clientului este alterată sau nu atunci când revine de la server.

Metoda CONNECT– metoda rezervei, nefolosita.

Metoda OPȚIUNI vă permite să interogați proprietățile serverului și proprietățile oricărui fișier.

În comunicarea cerere-răspuns între client și server, serverul generează în mod necesar un răspuns. Aceasta poate fi o pagină web sau o bară de stare cu un cod de stare. Codul de stare vă este bine cunoscut. Unul dintre coduri este binecunoscutul cod 404 – Page Not Found.

Grupuri de coduri de stare

1хх: Server gata, Cod 100 – serverul este gata să proceseze cererile clientului;

2xx: Succes.

• Cod 200 - cererea a fost procesată cu succes;
• Cod 204 - Fără conținut.

3xx: Redirecționare.

• Cod 301 - Pagina solicitată a fost mutată;
• Cod 304 - Pagina din cache este încă valabilă.

4xx: Eroare client.