Totul despre protocoalele de transfer de date http și https.

18.08.2019 Photoshop 3D

Dacă ai vrut să știi cum se transferă datele pe Internet, acest articol este pentru tine. Vă voi spune tot ce știu despre protocoalele HTTP și HTTPS, vă voi arăta diferența și diferențele dintre ele. Lectură fericită!

HTTP 1.1 - ce este acest protocol?

HTTP (în engleză: „Hypertext Transfer Protocol”) este un protocol de rețea de nivel superior pentru transmiterea de date hipertext și arbitrare pe Internet.

Folosind HTTP, browserul primește date de la serverele web și le poate afișa într-o formă care este acceptabilă și pe înțelesul utilizatorilor de internet. Procesul invers are loc exact în același mod - trimiterea datelor utilizatorului înapoi la server (de exemplu, în timpul înregistrării).

Conținutul trimis de la și către server poate fi prezentat sub orice formă: imagini, fișiere, documente, link-uri și cod - în orice caz, datorită HTTP, oamenii pot folosi Internetul și pot încărca sute de pagini web în browser.

Versiunea curentă protocol - 1.1. Descrierea sa este în specificația RFC.

HTTP este utilizat în infrastructura de transfer de date client-server. Cum funcţionează asta? Aplicația din partea „client” generează o cerere de procesare pe partea „server”, după care răspunsul este trimis înapoi către „client”. „Clientul” poate iniția apoi solicitări suplimentare și poate primi răspunsuri noi. Și așa mai departe.

Cea mai comună aplicație „client” este un browser web prin care sunt accesate resursele web. Odată cu dezvoltarea tehnologiilor mobile, au fost adăugate mai multe browsere aplicații mobile pe o varietate de smartphone-uri și tablete. Mai mult, partea de server a aplicațiilor multidisciplinare moderne poate procesa simultan date atât din browser, cât și din smartphone. Toate acestea se fac prin protocolul HTTP.

Mai mult decât atât, HTTP acționează adesea ca un protocol de transport pentru transferul altor protocoale de aplicație și API-urile acestora: WebDAV, XML-RPC, REST, SOAP. Ei bine, datele transmise prin API pot avea o varietate de formate: XML, JSON și altele.

Cum se transmit aceste date? Cel mai adesea printr-o conexiune TCP/IP: aplicația client folosește implicit portul TCP 80, iar serverul poate folosi orice altul, dar de obicei acesta este și portul 80.

Un obiect de manipulare HTTP este o resursă specificată în URI-ul de solicitare al unei aplicații client pentru a identifica corect „ce este de fapt necesar”. De obicei, acestea sunt fișiere, date sau obiecte logice, care sunt stocate pe server. În acest caz, cererea poate indica exact cum să prezinte aceleași date: ce format, codificare, limbă să alegeți. Această „funcție” vă permite să faceți schimb nu numai de hipertext, ci și de date binare.

Doilea Caracteristica HTTP este lipsa persistenței stării între perechi succesive cerere-răspuns. Dar aceasta nu este o problemă deoarece componentele aplicației de pe partea client sau server pot stoca ele însele informații de stare ultimele cereri si raspunsuri. Pe partea de client, astfel de informații se numesc cookie-uri, pe partea de server - sesiuni.

În același timp, nu este o problemă pentru browser-ul client să monitorizeze întârzierea de răspuns a serverului, iar pentru server nu este o problemă să stocheze anteturile celor mai recente solicitări și adresele IP ale clientului. Dar, subliniez încă o dată, protocolul în sine nu știe nimic despre asta - transmite doar date.

Intermediarii (servere proxy) pot lua parte și la transferul de date pentru a distinge proxy-urile de serverele finale (așa-numitul „server sursă”).

Magia începe atunci când același program (client sau server) poate îndeplini funcțiile de intermediar, client sau server - în funcție de sarcini.

HTTP/2 - ce fel de protocol este acesta?

Versiunea originală a protocolului HTTP a apărut la CERN în 1991. Deja în 1992, a fost publicată versiunea publică a HTTP 0.9 și specificațiile sale, datorită cărora regulile de interacțiune între client și aplicații server, precum și o delimitare clară a funcționalității.

HTTP/1.0 a apărut în 1996, iar versiunea modernă a protocolului - HTTP/1.1 - în 1999. La începutul mileniului, protocolul HTTP a învățat să accepte modul de conectare persistentă, adică. lăsați conexiunea deschisă după ce a fost primit un răspuns la o solicitare. Acest lucru a făcut posibilă trimiterea mai multor solicitări simultan într-o singură conexiune, mai degrabă decât deschiderea și închiderea sesiunii de fiecare dată.

Timpul a trecut și pe măsură ce internetul s-a dezvoltat, dimensiunea paginilor a crescut, numărul de solicitări a crescut - erau necesare din ce în ce mai multe resurse. Așa a apărut necesitatea unui nou protocol.

Și șaisprezece ani mai târziu, în 2015, a fost publicat versiunea finală proiect de specificație pentru următoarea versiune a protocolului - HTTP/2. Protocolul binar HTTP/2 este mai pregătit pentru realități moderne decât progenitorul HTTP 1.1 deoarece noul protocol rezolvă cea mai importantă problemă a transferului de date pe Internet - conexiuni multiple deschise.

Și totul pentru că site-urile actuale încarcă o mulțime de elemente, atât de pe serverul lor, cât și de pe CDN: scripturi JS, stiluri CSS, fonturi și imagini. Când transferați un set complet de fișiere folosind protocolul HTTP 1.1, sunt create mai multe conexiuni. Dacă pe viitor trecem la protocolul HTTP/2, transferul se va face în cadrul unei singure conexiuni între client și server, ceea ce va accelera și optimiza semnificativ încărcarea conținutului site-ului.

Caracteristici cheie HTTP/2, care va fi util pentru site-uri:

Aranjarea și gestionarea priorităților cererilor/fluxurilor - clientul stabilește în mod independent prioritatea resurselor și datelor pentru server
compresie antet HTTP;
Solicitare multiplexare sau încărcare paralelă a mai multor elemente de site printr-o conexiune TCP - mai multe solicitări sunt trimise printr-o singură conexiune, iar clientul poate primi răspunsuri în orice ordine, adică. acum nu ai nevoie de mai multe conexiuni TCP deschise;
Disponibilitate și suport de la serverul notificărilor push proactive - serverul poate trimite în mod independent către client date pe care clientul nu le-a solicitat încă (de exemplu, pe baza informațiilor despre ce pagină va deschide utilizatorul după aceasta).

Desigur, principalul lucru aici este multiplexarea fluxului. Principiul de funcționare este ușor de explicat: pachetele de conexiune TCP/IP sunt amestecate într-o singură conexiune. Astfel, în modul mixt, mai multe „mașini de date” sunt conectate într-un „tren”, care sunt separate „la sosire”. Anterior, „mașinile” erau obligate să călătorească mai mult și separat, dar acum vor călători împreună și mai repede.

Avantajele de mai sus ale protocolului HTTP/2 vor permite dezvoltatorilor web să respire adânc și să abandoneze astfel de „cârje” precum:

Utilizare Mai mult domenii aferente pentru a asigura instalarea cantitate mare Conexiuni TCP/IP (pentru descărcarea fișierelor);
Sprite-uri de imagine - atunci când imaginile sunt combinate într-un singur fișier pentru a reduce numărul de solicitări către serverul web (și fișierul în sine „se „umfla” deoarece sunt scrise mai multe imagini în el);
Combinarea fișierelor CSS și JS, care sunt, de asemenea, făcute pentru a reduce solicitările.

Mai recent avantaj evident Problema este că nu trebuie să faceți nimic suplimentar cu site-ul în sine (pentru a activa HTTP/2) - toată munca se desfășoară pe server în aproape „1 clic”, iar pentru clienții de găzduire partajată și VPS va în general trec neobservate.

Într-un cuvânt, vom trăi!

HTTP/2 a fost creat și dezvoltat pe baza protocolului SPDY/3 (Google) și l-a depășit - Google a recunoscut avantajele HTTP/2 ca fiind mai promițătoare și va abandona suportul pentru SPDY/2 în viitor.

Accelerarea prevăzută a răspunsului serverului prin protocolul HTTP/2 va fi de aproximativ 30% - testele reale au arătat deja viteze cu 19-23% mai mari și aceasta nu este limita.

Conform rezultatelor testelor efectuate de Airi.rf, creșterea vitezei de la doar activarea protocolului HTTP/2 este de 13-18% (fără optimizare). De ce este acest lucru important?

În ciuda faptului că site-ul nu acceptă protocolul HTTP/2 în acest moment nu afectează direct clasarea site-urilor în Google și pozițiile Yandex în rezultatele căutării sunt afectate de viteza de încărcare. Și din moment ce protocolul arată mai multe de mare viteză descărcări (care este un factor destul de semnificativ), afectează indirect clasamentele.

In primul rand datorita factori comportamentali. Accelerația de încărcare permite utilizatorilor să fie mai puțin obosiți și mai concentrați pe explorarea site-ului: vizualizarea mai multor pagini și nu părăsirea site-ului din cauza timpilor lungi de încărcare (săriturile sunt reduse).

Cele mai multe browsere moderne acceptă deja HTTP/2 - ~70% din traficul de internet trece prin ele:

Chrome 41-52 și Chrome 46+ pe Android;
Firefox 36-48 și Firefox 41+ pe Android;
Opera 28-34 și Opera 30+ pe Android;
Safari 9 și Safari în iOS 9.1;
IE 11 pe Windows 10 și Browser Edge 12, 13.

Nu este încă clar când va avea loc o tranziție completă la HTTP/2 - cel mai probabil în viitorul foarte apropiat. Principalul lucru este că nimeni nu va abandona în grabă HTTP/1.x. După cum se spune: „Dacă funcționează, nu-l atinge”.

Ce înseamnă protocolul HTTPS și unde este utilizat?

Ei bine, știți deja totul despre schimbul de date folosind protocolul HTTP: orice transfer de date se realizează prin solicitări folosind acest protocol de transport. Atunci de ce avem nevoie de HTTPS și ce este? La urma urmei, am trăit normal fără el?

Problema este că datele prin HTTP nu sunt protejate și sunt transmise către formă deschisă. Internetul este o rețea globală distribuită de noduri. Și dacă transmiteți date deschise printr-un protocol nesecurizat (Wi-Fi într-un centru comercial se aplică și aici), atunci unul dintre aceste noduri le poate intercepta.

Nu intenționat, desigur, ar putea fi doar hacking de către criminali. HTTPS a fost creat pentru a se asigura că conexiunea este sigură, iar datele sunt transmise în formă criptată folosind protocolul criptografic SSL/TLS. Acesta este un „înveliș” special deasupra HTTP, acesta criptează datele, făcându-le inaccesibile intrușilor și persoanelor neautorizate.

HTTPS - engleză „Protocol de transfer hipertext securizat”.

Deci, spre deosebire de portul implicit 80 în HTTP, HTTPS folosește portul TCP 443 și are o cheie de criptare. Cheia poate avea o lungime de 40, 56, 128 sau 256 de biți, un nivel suficient de securitate începe în prezent cu chei de 128 de biți.

Acum toate browserele acceptă HTTPS - este pornit automat atunci când este posibil și serverul o cere.

Este vital să utilizați HTTPS în următoarele servicii:

Sisteme electronice de plată (bănci, monedă electronică etc.);
Servicii care primesc și trimit informații private și date personale, de exemplu, Yandex are: Pașaport, Taxi, Direct, Metrica, Mail, Money, Webmaster și altele;
Rețele sociale și conturi personale în serviciile de internet;
Motoarele de căutare.

HTTPS funcționează simplu. O sa explic cu un exemplu.

Puneți informații importante (login, parolă, detalii card, date personale) într-o celulă, „blocați-o cu o cheie”: celula vă criptează datele folosind această cheie.

Acum trimiteți-l prin poștă destinatarului. Destinatarul primește celula coletului, dar nu o poate deschide - nu deține cheia. Apoi blochează (criptează) celula cu un al doilea lacăt și îți returnează coletul înapoi. Primești un pachet cu două încuietori, dar ai cheia la unul. Acum puteți debloca blocarea (decripta datele) și trimiteți pachetul înapoi destinatarului inițial.

În același timp, datele rămân protejate - până la urmă, nu au fost vizualizate sau modificate de nimeni și până când sunt primite de destinatar, sunt protejate de o cheie criptată. Destinatarul primește coletul, deja cu o singură lacăt, îl decriptează și prelucrează datele dumneavoastră. De exemplu, efectuează tranzacția dvs.

Asta este - așa funcționează HTTPS.

Trucul aici este că în timpul primului astfel de schimb, cheia de criptare este schimbată astfel încât să fie cunoscută de ambii destinatari finali, dar nu este cunoscută de niciunul dintre nodurile de-a lungul rutei de date. După ce ați schimbat cifrul, puteți schimba liber mesaje (criptate) fără teama de a intercepta aceste date, deoarece fără cheia de cifră nu va fi posibilă deschiderea și citirea acesteia.

Singura avertizare aici este că trebuie să știți că trimiteți datele exact acolo unde este nevoie. Și că punctul final este destinația. Dar trebuie să confirmați și să știți sigur că destinația finală există și este controlată chiar de serverul unde sunt trimise datele.

Pentru a face acest lucru, serverele primesc certificate speciale de securitate HTTPS de la centrele de certificare, care confirmă „finalitatea” destinației (că site-ul nu este un nod care transmite date în continuare) și funcționalitatea tehnologiei de criptare SSL/TLS, de exemplu. securitatea conexiunii.

Și iată cum arată certificatul în sine:

În prezent, HTTPS este încorporat în toate browsere moderneși tot ceea ce este necesar de la utilizator pentru a menține securitatea trimiterii de date prin HTTPS este actualizarea regulată software pentru navigare, primirea și trimiterea de date importante pe Internet.

Efectuarea interacțiunii client-server prin Protocolul HTTPS nu trebuie să vă faceți griji cu privire la siguranța datelor dvs. - sunteți protejat în mod fiabil de interceptări conexiune la rețea: atacuri sniffer și man-in-the-middle.

Ce înseamnă pictograma HTTPS tăiată? pictograma verde HTTPS, care este diferența? Seif. Verdele este sigur, roșu și tăiat sunt nesigure.

Și este foarte convenabil ca pictograma HTTPS tăiată înseamnă că, în ciuda utilizării acestui protocol, conexiunea nu este sigură. Acest lucru se întâmplă atunci când elementele site-ului nu sunt încărcate prin HTTPS sau certificatul a expirat. Utilizatorul poate vedea imediat - da, este nesigur. Și poate părăsi site-ul sau își poate risca datele.

Care este mai bun HTTP 1.1, HTTP/2 sau HTTPS?

Pentru a rezuma, voi atinge subiectul utilizării preferabile a protocoalelor.

Este clar că în acest moment HTTP 1.1 este cel mai comun protocol și este folosit implicit. Momentul HTTP/2 nu a venit încă, dar în curând majoritatea traficului de Internet va trece prin cea de-a doua versiune a protocolului HTTP. Acest lucru va ușura viața utilizatorilor, deoarece site-urile se vor încărca mai repede. Administratorii de servere și site-uri web vor fi, de asemenea, fericiți, deoarece noul protocol vă permite să optimizați site-urile într-un mod nou, grăbind încărcarea și încărcarea datelor.

În același timp, cu greu este posibil ca toate site-urile să treacă la HTTPS, deoarece în scopul consumului de conținut de divertisment, criptarea este inutilă. Da, acum 10% dintre site-uri folosesc HTTPS în clasamentul Alexa al celor mai vizitate resurse web. Dar aceasta este doar zece procente, inclusiv giganți precum Google, PayPal, Amazon, Aliexpress și alții. Adică, există multe site-uri unde a nu folosi HTTPS înseamnă încălcarea dreptului utilizatorului de internet la securitatea și integritatea datelor.

Dar site-urile obișnuite precum blogul a șapte bloggeri nu au nevoie de HTTPS - nu există nicio recepție de date personale sau de plată, nicio înregistrare și trimitere. mesaje importante.

Deci, în viitorul apropiat ne vom îndepărta treptat de HTTP 1.1 în favoarea HTTP/2 și HTTPS.

HTTP (HyperText Protocolul de transfer- protocol de transfer hipertext) a fost dezvoltat ca bază În toată lumea Web.

Protocolul HTTP funcționează după cum urmează: programul client stabilește o conexiune TCP cu serverul (portul standard numărul 80) și îi emite o solicitare HTTP. Serverul procesează această solicitare și emite un răspuns HTTP către client.

Structura cererii HTTP

O solicitare HTTP constă dintr-un antet de cerere și un corp de cerere, separate printr-o linie goală. Corpul cererii poate lipsi.

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

Interogarea pe linia principală constă din trei părți, separate prin spații:

Metodă(cu alte cuvinte, comanda HTTP):

OBŢINE- cerere document. Metoda cea mai des folosită; în HTTP/0.9, spun ei, era singurul.

CAP- cerere titlu document. Diferă de GET prin faptul că este returnat doar antetul cererii cu informații despre document. Documentul în sine nu este emis.

POST- această metodă este folosită pentru a transfera date către scripturi CGI. Datele în sine apar în rândurile ulterioare ale cererii sub formă de parametri.

PUNE- plasați documentul pe server. Din cate stiu eu, este rar folosit. O cerere cu această metodă are un corp în care este transmis documentul în sine.

Resursă- aceasta este calea către un anumit fișier de pe server pe care clientul dorește să îl primească (sau să plaseze - pentru metoda PUT). Dacă resursa este pur și simplu un fișier de citit, serverul trebuie să îl returneze în corpul răspunsului pentru această solicitare. Dacă aceasta este calea către un script CGI, atunci serverul rulează scriptul și returnează rezultatul execuției acestuia. Apropo, datorită acestei unificări de resurse, clientul este practic indiferent la ceea ce reprezintă pe server.

Versiunea protocolului-versiunea protocolului HTTP cu care funcționează programul client.

Deci, o cerere HTTP simplă ar putea arăta astfel:

Aceasta solicită fișierul rădăcină din directorul rădăcină al serverului web.

Liniile de după linia principală de interogare au următorul format:

Parametru: valoare.

Așa sunt setați parametrii de solicitare. Acest lucru este opțional toate liniile de după linia de interogare principală pot lipsi; în acest caz, serverul acceptă valoarea lor implicit sau pe baza rezultatelor solicitării anterioare (când lucrează în modul Keep-Alive).

Voi enumera câțiva dintre cei mai des utilizați parametrii de solicitare HTTP:

Conexiune(conexiune) - poate lua valorile Keep-Alive and close. Keep-Alive înseamnă că după emiterea acestui document, conexiunea la server nu este întreruptă și pot fi emise mai multe solicitări. Majoritatea browserelor funcționează în modul Keep-Alive, deoarece vă permite să „descărcați” o pagină html și imagini pentru aceasta într-o singură conexiune la server. Odată setat, modul Keep-Alive este menținut până la prima eroare sau până la următoarea solicitare Connection: close este specificată în mod explicit.
close ("închidere") - conexiunea este închisă după ce răspunde la această solicitare.

User-Agent- valoarea este „codul” browserului, de exemplu:

Mozilla/4.0 (compatibil; MSIE 5.0; Windows 95; DigExt)

Accepta- o listă de tipuri de conținut acceptate de browser în ordinea preferințelor pentru un anumit browser, de exemplu pentru IE5:

Accept: imagine/gif, imagine/x-xbitmap, imagine/jpeg, imagine/pjpeg, application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint, */*

Acest lucru este evident necesar pentru cazul în care serverul poate scoate același document în formate diferite.

Valoarea acestui parametru este folosită în principal de scripturile CGI pentru a genera un răspuns adaptat pentru un anumit browser.

Referitor- URL de la care ați ajuns la această resursă.

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

Accept-Limba- limbaj suportat. Semnificativ pentru un server care poate servi același document în versiuni lingvistice diferite.

Format de răspuns HTTP

Formatul răspunsului este foarte asemănător cu formatul cererii: are, de asemenea, un antet și un corp separate printr-o linie goală.

Antetul constă, de asemenea, dintr-o linie principală și linii de parametri, dar formatul liniei principale este diferit de cel al antetului cererii.

Șirul de interogare principal este format din 3 câmpuri separate prin spații:

Versiunea protocolului- similar cu parametrul de cerere corespunzător.

Cod de eroare- denumirea de cod a „succesului” cererii. Codul 200 înseamnă „totul este normal” (OK).

Descrierea verbală a erorii- „descifrarea” codului anterior. De exemplu, pentru 200 este OK, pentru 500 este Intern Eroare de server.

Cei mai comuni parametri de răspuns http:

Conexiune- similar cu parametrul de cerere corespunzător.
Dacă serverul nu acceptă Keep-Alive (există), atunci valoarea Connection din răspuns este întotdeauna apropiată.

Prin urmare, în opinia mea, tactica corectă de browser este următoarea:
1. emite Conexiune: Keep-Alive în cerere;
2. Starea conexiunii poate fi evaluată după câmpul Conexiune din răspuns.

Tip de conținut(„tipul de conținut”) - conține o desemnare a tipului de conținut al răspunsului.

În funcție de valoarea Content-Type, browserul interpretează răspunsul ca o pagină HTML, imagine gif sau jpeg, ca fișier pentru a fi salvat pe disc, sau orice altceva, și ia măsurile corespunzătoare. Valoarea Content-Type pentru browser este aceeași cu valoarea extensiei de fișier pentru Windows.

Unele tipuri de conținut:

text/html - text în format HTML (pagina web);
text/plain - text simplu (similar cu Notepad);
imagine/jpeg - imagine în format JPEG;
imagine/gif - la fel, în format GIF;
application/octet-stream - un flux de „octeți” (adică doar octeți) pentru a scrie pe disc.

De fapt, există mai multe tipuri de conținut.

Conținut-Lungime(„lungimea conținutului”) - lungimea conținutului răspunsului în octeți.

Ultima modificare("Modificat ultima dată") - data ultima schimbare document.

Am eliberat carte noua„Marketing de conținut pe rețelele sociale: cum să intri în capul urmăritorilor tăi și să-i faci să se îndrăgostească de marca ta.”

HTTP este ceea ce permite transferul datelor. Inițial, a fost creat pentru trimiterea și primirea documentelor care conțin link-uri în interior pentru a face tranziția la resurse terțe.

Abrevierea este „HyperText Transfer Protocol”, care tradus înseamnă „protocol de transfer”. HTTP aparține grupului de straturi de aplicații pe baza specificului utilizat de OSI.

Pentru a înțelege mai bine ce înseamnă HTTP, să ne uităm la o analogie simplă. Să ne imaginăm că comunici cu un străin pe o rețea de socializare. Îți trimite un mesaj engleză, ai inteles. Dar nu puteți înțelege conținutul pentru că nu vorbiți bine limba. Pentru a descifra mesajul, utilizați un dicționar. După ce ați înțeles esența, îi răspundeți străinului în rusă și trimiteți răspunsul. Străinul primește răspunsul și, cu ajutorul unui traducător, descifrează mesajul. Pentru a simplifica întregul mecanism, protocoalele Internet HTTP îndeplinesc funcția de traducător. Cu ajutorul lor, browserul poate traduce conținutul criptat al paginilor web și poate afișa conținutul acestora.

Pentru ce este HTTP?

Protocolul HTTP este folosit pentru a schimba informații folosind un model client-server. Clientul compune și transmite o cerere către server, apoi serverul o prelucrează și o analizează, după care se creează un răspuns și se trimite utilizatorului. La sfârșitul acestui proces, clientul lansează o nouă comandă și totul se repetă.

Astfel, protocolul HTTP permite schimbul de informații între aplicatii diverse utilizatori și servere web speciale, precum și conectarea la resurse web (de obicei browsere). Astăzi, protocolul descris asigură funcționarea întregii rețele. Protocolul de transfer de date HTTP este, de asemenea, utilizat pentru a transfera informații peste alte protocoale pentru mai mult de nivel scăzut de ex. WebDAV sau SOAP. În acest caz, protocolul este un mijloc de transport. Multe programe se bazează, de asemenea, pe HTTP ca instrument principal pentru schimbul de informații. Datele sunt prezentate în diverse formate, de exemplu, JSON sau XML.

HTTP este un protocol pentru schimbul de informații printr-o conexiune IP/TCP. De obicei, serverul folosește portul TCP 80 în acest scop. Dacă portul nu este specificat, software-ul client va folosi implicit portul 80 de tip TCP. În unele cazuri, pot fi utilizate alte porturi.

Protocolul HTTP folosește o schemă de criptare simetrică și utilizează criptosisteme simetrice. Criptosistemele simetrice implică utilizarea aceleiași chei pentru a cripta și decripta informațiile.

Care este diferența dintre HTTP și HTTPS

Diferența poate fi detectată chiar și din decodarea abrevierilor. HTTPS înseamnă Hypertext Transfer Protocol Security. Astfel, HTTP este un protocol independent, iar HTTPS este o extensie pentru a-l proteja. HTTP transmite informații neprotejate, în timp ce HTTPS oferă protecție criptografică. Acest lucru este valabil mai ales pentru resursele cu autorizare responsabilă. Ar putea fi social media sau site-uri ale sistemelor de plată.

Care sunt pericolele transmiterii datelor neprotejate? Un program interceptor le poate transfera atacatorilor în orice moment. HTTPS are o organizare tehnică complexă, care vă permite să protejați în mod fiabil informațiile și să eliminați posibilitatea accesului neautorizat la acestea. Diferența constă în porturi. HTTPS funcționează de obicei pe portul 443.

Astfel, HTTP este folosit pentru transferul de date, iar HTTPS permite transferul securizat de date folosind criptarea și autorizarea pe resurse cu un nivel ridicat de securitate.

Funcționalitate suplimentară

HTTP este bogat în funcționalități și este compatibil cu diferite extensii. Specificația 1.1 folosită astăzi permite ca antetul Upgrade să fie utilizat pentru a comuta și a lucra prin alte protocoale atunci când se schimbă date. Pentru a face acest lucru, utilizatorul trebuie să trimită o cerere către server cu acest antet. Dacă serverul trebuie să treacă la un anumit schimb folosind un alt protocol, acesta returnează o solicitare către client, care afișează starea „426 Upgrade Required”.

Această caracteristică este relevantă în special pentru schimbul de informații prin WebSocket (are specificația RFC 6455, permițându-vă să faceți schimb de date în orice moment, fără solicitări HTTP inutile). Pentru a migra la WebSocket, un utilizator trimite o solicitare cu antetul Upgrade și valoarea „websocket”. Apoi, serverul răspunde cu „101 Switching Protocols”. După acest moment, începe transferul de informații prin WebSocket.

Pentru World Wide Web. Astfel de protocoale sunt text structurat care utilizează conexiuni logice (hiperlinkuri) între noduri care conțin date specifice. Astfel, este o modalitate de schimb sau transmitere a hipertextului.

Protocolul HTTP funcționează ca o funcție cerere-răspuns într-un model de calcul client-server. Deci, browserul web acționează ca un client, iar găzduirea site-ului web este serverul. Clientul trimite un mesaj de solicitare HTTP către un server care furnizează anumite resurse (cum ar fi fișiere HTML și alte materiale) și apoi returnează un mesaj de răspuns. Răspunsul conține informații despre cerere și poate conține, de asemenea, conținutul solicitat în corpul mesajului.

Browserul este un exemplu de bază de agent utilizator (client). Alte tipuri de agenți utilizatori includ software-ul utilizat pentru indexare de către furnizorii de căutare, aplicațiile mobile și alte resurse care consumă sau afișează conținut web.

Protocolul HTTP este conceput pentru a oferi elemente de rețea intermediare pentru a îmbunătăți sau a permite comunicarea între clienți și servere. Site-urile cu trafic mare beneficiază adesea de servere web stocate în cache care servesc conținut în numele resurselor din amonte, reducând timpul de încărcare. Cache-ul browserelor web permite utilizatorului să reducă trafic de rețea. Serverele proxy care utilizează protocolul HTTP într-o rețea locală pot furniza comunicații pentru clienții care nu permit rutarea globală a adreselor prin transmiterea mesajelor de la servere externe.

O sesiune HTTP este proces secvenţial din cereri și răspunsuri. Clientul inițiază cererea prin crearea unei conexiuni TCP la port specific pe server, iar acesta din urmă ascultă pe acest port și așteaptă un mesaj de solicitare. Când este primit, serverul trimite un mesaj de răspuns. Corpul acestui mesaj reprezintă de obicei resursa solicitată, deși poate fi afișat un mesaj de eroare sau alte informații.

Când se ia în considerare scopul protocolului HTTP, trebuie remarcat că acesta definește metode cu scopul de a specifica acțiunea dorită a fi efectuată asupra resurselor identificate. În acest caz, tipul de informații afișate (date preexistente sau generate dinamic) depinde de implementarea serverului. Adesea, o astfel de resursă corespunde unui fișier sau script situat pe găzduire.

Unele metode pe care le folosește protocolul HTTP de transfer hipertext sunt destinate doar regăsirii informațiilor și nu ar trebui să schimbe starea serverului. Cu alte cuvinte, nu au un impact serios, cu excepția efectelor relativ inofensive ale stocării în cache sau ale creșterii statisticilor vizitatorilor.

Pe de altă parte, protocolul HTTP poate folosi și metode care sunt destinate acțiunilor care pot influența fie serverul, fie alte resurse externe - activarea tranzacțiilor financiare sau efectuarea unui transfer e-mail. Ocazional, astfel de metode sunt folosite de roboții web sau unele site-uri și pot face solicitări indiferent de sarcina principală.

HTTP este un protocol pentru transferul hipertextului între sistemele distribuite. De fapt, http este un element fundamental al web-ului modern. În calitate de dezvoltatori web care se respectă, ar trebui să știm cât mai multe despre asta.

Să privim acest protocol prin prisma profesiei noastre. În prima parte, vom trece peste elementele de bază și vom analiza solicitările/răspunsurile. În articolul următor ne vom uita la caracteristici mai detaliate, cum ar fi stocarea în cache, procesarea conexiunii și autentificarea.

De asemenea, în acest articol mă voi referi în principal la standardul RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1.

Bazele HTTP

HTTP permite comunicarea între mai multe gazde și clienți și acceptă o serie de setări de rețea.

Practic, TCP/IP este folosit pentru comunicare, dar acesta nu este singurul opțiune posibilă. În mod implicit, TCP/IP utilizează portul 80, dar pot fi utilizați alții.

Comunicarea dintre gazdă și client are loc în două etape: cerere și răspuns. Clientul generează o cerere HTTP, ca răspuns la care serverul oferă un răspuns (mesaj). Puțin mai târziu, ne vom uita la această schemă de lucru în detaliu.

Versiunea actuală a protocolului HTTP este 1.1, în care au fost introduse câteva funcții noi. În opinia mea, cele mai importante dintre ele sunt: sprijinul constant conexiune deschisă, nou mecanism de transfer de date codare de transfer în bucăți, antete noi pentru stocarea în cache. Ne vom uita la unele dintre acestea în a doua parte a acestui articol.

URL

Miezul comunicării web este cererea, care este trimisă prin intermediul URL-ului (Uniform Resource Locator). Sunt sigur că știți deja ce este o adresă URL, dar pentru a fi complet, am decis să spun câteva cuvinte. Structura URL-ului este foarte simplă și constă din următoarele componente:

Protocolul poate fi fie http pentru conexiuni obișnuite, fie https pentru un schimb de date mai sigur. Portul implicit este 80. Acesta este urmat de calea către resursa de pe server și de un lanț de parametri.

Metode

Folosind URL-ul, definim numele exact gazdă cu care dorim să comunicăm, dar ce acțiune trebuie să facem poate fi comunicată numai folosind metoda HTTP. Desigur, există mai multe tipuri de acțiuni pe care le putem întreprinde. HTTP le implementează pe cele mai necesare, potrivite pentru nevoile majorității aplicațiilor.

Metode existente:

OBŢINE: Accesați o resursă existentă. Adresa URL listează toate informatiile necesare, astfel încât serverul să poată găsi și returna resursa necesară ca răspuns.

POST: Folosit pentru a crea o resursă nouă. O solicitare POST conține de obicei toate informatiile necesare pentru a crea o nouă resursă.

PUNE: Actualizați resursa curentă. cerere PUT conţine date actualizate.

ŞTERGE: Folosit pentru a șterge o resursă existentă.

Aceste metode sunt cele mai populare și sunt cel mai des folosite de diverse instrumente și cadre. În unele cazuri, solicitările PUT și DELETE sunt trimise prin trimiterea POST, al cărui conținut indică acțiunea care trebuie efectuată cu resursa: creați, actualizați sau ștergeți.

HTTP acceptă și alte metode:

CAP: Similar cu GET. Diferența este că la acest tip de solicitare nu se transmite niciun mesaj. Serverul primește doar anteturile. Folosit, de exemplu, pentru a determina dacă o resursă a fost modificată.

URMĂ: în timpul transmiterii, cererea trece prin multe puncte de acces și servere proxy, fiecare dintre acestea introducând propriile informații: IP, DNS. Folosind această metodă, puteți vedea toate informațiile intermediare.

OPȚIUNI: Folosit pentru a defini capabilitățile serverului, setările și configurația pentru o anumită resursă.

Coduri de stare

Ca răspuns la o solicitare din partea clientului, serverul trimite un răspuns, care conține și un cod de stare. Acest cod are o semnificație specială, astfel încât clientul să poată înțelege mai clar cum să interpreteze răspunsul:

1xx: Mesaje informative

Un set de aceste coduri a fost introdus în HTTP/1.1. Serverul poate trimite o cerere de formularul: Expect: 100-continue, ceea ce înseamnă că clientul încă trimite restul solicitării. Clienții care rulează HTTP/1.0 ignoră aceste anteturi.

2xx: Mesaje de succes

Dacă clientul a primit un cod din seria 2xx, atunci cererea a fost trimisă cu succes. Cea mai comună opțiune este 200 OK. La cerere GET, serverul trimite răspunsul în corpul mesajului. Există și alte răspunsuri posibile:

202 Acceptat: Solicitarea este acceptată, dar este posibil să nu conțină resursa în răspuns. Acest lucru este util pentru cererile asincrone din partea serverului. Serverul determină dacă să trimită sau nu resursa.
204 Fără conținut: Nu există niciun mesaj în corpul răspunsului.
205 Resetare conținut: Instruiește serverului să reseteze prezentarea documentului.
206 Conținut parțial: Răspunsul conține doar o parte din conținut. Anteturile suplimentare determină lungimea totală a conținutului și a altor informații.

3xx: Redirecționare

Un fel de mesaj către client despre necesitatea de a mai întreprinde o acțiune. Cel mai frecvent caz de utilizare este redirecționarea clientului către o altă adresă.

301 Mutat permanent: resursa poate fi găsită acum diferit adresa URL.
303 Vezi Altele: resursa poate fi găsită temporar la o adresă URL diferită. Antetul Locație conține o adresă URL temporară.
304 Nemodificat: Serverul stabilește că resursa nu a fost modificată și clientul trebuie să utilizeze versiunea cache a răspunsului. Pentru a verifica identitatea informațiilor, se folosește ETag (Entity Tag hash);

4xx: erori de client

Această clasă de mesaje este utilizată de server dacă decide că cererea a fost trimisă din greșeală. Cel mai comun cod: 404 Nu a fost găsit. Aceasta înseamnă că resursa nu a fost găsită pe server. Alte coduri posibile:

400 Solicitare greșită: Întrebarea a fost formulată incorect.
401 Neautorizat: Este necesară autentificarea pentru a face o solicitare. Informațiile sunt transmise prin antetul Autorizație.
403 Interzis: Serverul nu a permis accesul la resursă.
405 Metoda nu este permisă: a fost folosită o metodă HTTP nevalidă pentru a accesa resursa.
409 Conflict: serverul nu poate procesa complet cererea deoarece încercând să schimbi mai mult noua versiune resursă. Acest lucru se întâmplă adesea cu cererile PUT.

5xx: erori de server

O serie de coduri care sunt folosite pentru a detecta o eroare de server la procesarea unei cereri. Cel mai frecvent: 500 Eroare Interna Server. Alte optiuni:

501 Neimplementat: Serverul nu acceptă funcționalitatea solicitată.
503 Service indisponibil: Acest lucru se poate întâmpla dacă serverul are o eroare sau este supraîncărcat. De obicei, în acest caz, serverul nu răspunde, iar timpul acordat pentru răspuns expiră.

Formate de mesaje de cerere/răspuns

În imaginea următoare puteți vedea un proces schematic de trimitere a unei cereri de către client, procesare și trimitere a unui răspuns de către server.

Să ne uităm la structură mesaj transmis prin HTTP:

Mesaj = *() CRLF [ ] = Linia de solicitare | Linie de stare = Câmp-Nume ":" Câmp-Valoare

Trebuie să existe o linie goală între antetul și corpul mesajului. Pot exista mai multe titluri:

Corpul de răspuns poate conține informatii complete sau o parte a acestuia, dacă funcția corespunzătoare este activată (Transfer-Encoding: chunked). HTTP/1.1 acceptă, de asemenea, antetul Transfer-Encoding.

Titluri generale

Iată mai multe tipuri de anteturi care sunt utilizate atât în cereri, cât și în răspunsuri:

Am tratat deja câteva lucruri în acest articol, unele pe care le vom discuta mai detaliat în a doua parte.

Antetul via este utilizat într-o solicitare TRACE și este actualizat de toate serverele proxy.

Antetul Pragma este folosit pentru a lista antete personalizate. De exemplu, Pragma: no-cache este același cu Cache-Control: no-cache. Vom vorbi mai multe despre asta în partea a doua.

Antetul Date este folosit pentru a stoca data și ora cererii/răspunsului.

Antetul Upgrade este folosit pentru a schimba protocolul.

Transfer-Encoding are scopul de a împărți răspunsul în mai multe bucăți folosind Transfer-Encoding: chunked. Aceasta este o caracteristică nouă în HTTP/1.1.

Anteturi de entitate

Antetele entităților transmit meta informații despre conținut:

Toate anteturile prefixate cu conținut - oferă informații despre structura, codificarea și dimensiunea corpului mesajului.

Antetul Expires conține ora și data de expirare a entității. Valoarea „nu expiră niciodată” înseamnă timp + 1 cod din momentul curent. Ultima modificare conține ora și data la care entitatea a fost modificată ultima dată.

Folosind aceste anteturi, puteți specifica informațiile necesare sarcinilor dvs.

Format de solicitare

Cererea arată cam așa:

SP este separatorul dintre jetoane. Versiunea HTTP este specificată în HTTP-Version. Cererea reală arată astfel:

GET /articles/http-basics HTTP/1.1 Gazdă: www.articles.com Conexiune: keep-alive Cache-Control: fără cache Pragma: fără cache Accept: text/html,application/xhtml+xml,application/xml; q=0,9,*/*;q=0,8

Lista de antete posibile de solicitare:

Antetul Accept specifică tipurile de mime acceptate, limba și codificarea caracterelor. Antetele De la, Gazdă, Referer și User-Agent conțin informații despre client. If- prefixele sunt menite să creeze condiții. Dacă condiția nu trece, va apărea o eroare 304 Not Modified.

Format de răspuns

Formatul răspunsului diferă doar prin stare și un număr de anteturi. Starea arată astfel:

Status-Line = HTTP-Version SP Status-Code SP Motiv-Expresie CRLF

Versiunea HTTP
Cod de stare
Mesaj de stare care poate fi citit de om

Starea normală arată cam așa:

HTTP/1.1 200 OK

Anteturile de răspuns pot fi după cum urmează:

Vârsta este timpul în secunde când mesajul a fost creat pe server.
ETag entități MD5 pentru a verifica modificările și modificările răspunsului.
Locația este folosită pentru redirecționare și conține noua adresă URL.
Server specifică serverul pe care a fost generat răspunsul.

Cred că este suficientă teorie pentru azi. Acum să aruncăm o privire la instrumentele pe care le putem folosi pentru a monitoriza mesajele HTTP.

Instrumente pentru detectarea traficului HTTP

Există multe instrumente pentru monitorizarea traficului HTTP. Iată câteva dintre ele:

Cel mai des folosit este Chrome Developers Tools:

Dacă vorbim despre un depanator, puteți folosi Fiddler:

Pentru a monitoriza traficul HTTP veți avea nevoie de curl, tcpdump și tshark.

Biblioteci pentru lucrul cu HTTP - jQuery AJAX

Deoarece jQuery este atât de popular, are și instrumente pentru procesare HTTP răspunde când solicitări AJAX. Informații despre jQuery.ajax(settings) pot fi găsite pe site-ul oficial.

Prin trecerea obiectului setări și, de asemenea, prin utilizarea funcției sună din nou beforeSend, putem seta anteturile cererii folosind metoda setRequestHeader().

$.ajax(( url: "http://www.articles.com/latest", tip: "GET", beforeSend: function (jqXHR) ( jqXHR.setRequestHeader("Accepts-Language", "en-US,ro "); ) ));

Dacă doriți să procesați starea cererii, o puteți face astfel:

$.ajax(( statusCode: ( 404: function() ( alert("pagina nu a fost gasita"); ) ) ));