Share
În articolul meu anterior, am acoperit câteva dintre elementele de bază ale HTTP, cum ar fi schema de adrese URL, codurile de stare și antetele de solicitare / răspuns. Cu această bază, vom examina aspectele mai fine ale HTTP, cum ar fi manipularea conexiunilor, autentificarea și caching-ul HTTP. Aceste subiecte sunt destul de extinse, dar vom acoperi cei mai importanți biți.
Trebuie să se stabilească o conexiune între client și server înainte de a putea comunica între ele și HTTP utilizează protocolul de transport TCP de încredere pentru a realiza această conexiune. Implicit, traficul web utilizează portul TCP 80. Un flux TCP este rupt în pachete IP și asigură că acele pachete intră întotdeauna în ordinea corectă, fără a eșua. HTTP este un protocol de strat aplicație peste TCP, care este peste IP.
HTTPS este o versiune sigură a HTTP, care introduce un strat suplimentar între HTTP și TCP numit TLS sau SSL (Transport Layer Security sau Secure Sockets Layer, respectiv). HTTPS comunica prin portul 443 în mod implicit și vom examina HTTPS mai târziu în acest articol.
O conexiune HTTP este identificată prin
Serverul este responsabil pentru întotdeauna să răspundă cu antetele și răspunsurile corecte.
În HTTP / 1.0, toate conexiunile au fost închise după o singură tranzacție. Deci, dacă un client dorea să ceară trei imagini separate de la același server, a făcut trei conexiuni separate la gazda de la distanță. După cum puteți vedea din diagrama de mai sus, acest lucru poate introduce multe întârzieri în rețea, rezultând o experiență sub-optimă a utilizatorului.
Pentru a reduce întârzierea stabilirii conexiunilor, a fost introdus HTTP / 1.1 conexiuni persistente, conexiuni de lungă durată care rămân deschise până când clientul le închide. Conexiunile persistente sunt implicite în HTTP / 1.1, iar efectuarea unei singure conexiuni de tranzacție necesită setarea clientului Conexiune: aproape solicitați antetul. Acest lucru îi spune serverului să închidă conexiunea după ce a trimis răspunsul.
Pe lângă conexiunile persistente, browserele / clienții folosesc și o tehnică numită conexiuni paralele, pentru a minimiza întârzierile în rețea. Conceptul vechi de conexiuni paralele presupune crearea unei baze de conexiuni (în general, limitată la șase conexiuni). Dacă există șase bunuri pe care clientul trebuie să le descarce de pe un site web, clientul realizează șase conexiuni paralele pentru a descărca aceste active, rezultând o revenire mai rapidă. Aceasta este o imbunatatire imensa in raport cu conexiunile seriale in care clientul descarca doar un activ dupa ce a terminat descarcarea pentru un activ anterior.
Conexiunile paralele, în combinație cu conexiunile persistente, reprezintă răspunsul de astăzi la minimizarea întârzierilor în rețea și la crearea unei experiențe netede a clientului. Pentru tratamentul în profunzime a conexiunilor HTTP, consultați secțiunea Connections a spec. HTTP.
Serverul ascultă mai ales conexiunile primite și le procesează atunci când primește o solicitare. Operațiunile implică:
Accentsconagua
Conexiune: aproape antetul de solicitare a fost găsitDesigur, aceasta nu este o listă exhaustivă de operațiuni. Majoritatea aplicațiilor / site-urilor web trebuie să știe cine face o solicitare pentru a crea răspunsuri mai personalizate. Acesta este tărâmul Identificare și autentificare.
HTTP este un protocol de strat aplicație peste TCP, care este peste IP.
Este aproape obligatoriu să știți cine se conectează la un server pentru a urmări utilizarea unei aplicații sau a unui site și modelele de interacțiune generală ale utilizatorilor. Premisa identificării este de a adapta răspunsul pentru a oferi o experiență personalizată; în mod firesc, serverul trebuie să știe cine este un utilizator pentru a oferi această funcționalitate.
Există câteva moduri diferite în care un server poate colecta aceste informații, iar majoritatea site-urilor Web folosesc un hibrid al acestor abordări:
Din, referer, Agent utilizator - Am văzut aceste titluri în partea 1.Cookie-urile permit serverului să atașeze informații arbitrare pentru răspunsurile la ieșire prin intermediul Set-Cookie răspuns antet. Un cookie este setat cu unul sau mai multe name = valoarea perechi separate prin punct și virgulă (;), ca în Set-cookie: session-id = 12345ABC; username = nettuts.
Un server poate, de asemenea, restricționa cookie-urile la un anumit domeniu și cale, și le poate face persistente cu un expiră valoare. Cookie-urile sunt trimise automat de către browser pentru fiecare cerere făcută unui server, iar browser-ul asigură că numai domeniu- și cale-cookie-uri specifice sunt trimise în cerere. Antetul cererii Cookie: nume = valoare [; name2 = valoare2] este folosit pentru a trimite aceste cookie-uri pe server.
Cea mai bună modalitate de a identifica un utilizator este să îi solicitați să se înregistreze și să se conecteze, însă implementarea acestei funcții necesită un efort din partea dezvoltatorului, precum și a utilizatorului.
Tehnicile precum OAuth simplifică acest tip de caracteristică, însă acesta necesită în continuare consimțământul utilizatorului pentru a funcționa corect. Autentificarea joacă un rol important aici și este probabil singura modalitate de a identifica și verifica utilizatorul.
HTTP suportă o formă rudimentară de autentificare numită Autentificare de bază, precum și cele mai sigure Digest Autentificare.
În autentificarea de bază, serverul refuză inițial cererea clientului cu un WWW-autentificaþi răspuns antet și a 401 Neautorizat codul de stare. Când vedeți acest antet, browserul afișează un dialog de conectare, solicitând un nume de utilizator și o parolă. Această informație este trimisă într-un format codificat de bază 64 în Autentificare solicitați antetul. Serverul poate valida cererea și permite accesul dacă acreditările sunt valide. Unele servere ar putea trimite, de asemenea Autentificarea-Info antetul care conține detalii suplimentare privind autentificarea.
Un corolar al autentificării de bază este Proxy Authentication. În locul unui server web, provocarea de authetare este solicitată de un proxy intermediar. Proxy-ul trimite a Proxy-autentificaþi antet cu a 407 Neautorizat codul de stare. În schimb, clientul trebuie să trimită acreditările prin Proxy-Autorizare solicitați antetul.
Digest Autentificarea este similară cu Basic și utilizează aceeași tehnică de strângere a mâinilor cu WWW-autentificaþi și Autorizare dar Digest folosește o funcție hashing mai sigură pentru a cripta numele de utilizator și parola (de obicei, cu funcții digest MD5 sau KD). Deși se presupune că Digest Authentication este mai sigur decât Basic, site-urile folosesc de obicei autentificarea de bază din cauza simplității sale. Pentru a atenua preocupările legate de securitate, Basic Auth este utilizat împreună cu SSL.
Protocolul HTTPS asigură o conexiune securizată pe web. Cea mai ușoară modalitate de a afla dacă utilizați HTTPS este să verificați bara de adrese a browserului. Componenta securizată a componentelor HTTP implică inserarea unui strat de criptare / decriptare între HTTP și TCP. Acesta este Secure Sockets Layer (SSL) sau TLS (Transport Layer Security).
SSL utilizează o formă puternică de criptare utilizând RSA și criptografia cu chei publice. Deoarece tranzacțiile sigure sunt atât de importante pe web, un efort omniprezent bazat pe standarde de infrastructură publică (PKI) este în plină desfășurare de ceva timp.
Clienții / serverele existente nu trebuie să schimbe modul în care gestionează mesajele, deoarece majoritatea muncii grele se întâmplă în stratul SSL. Astfel, puteți dezvolta aplicația dvs. Web folosind Authentication Basic și puteți profita automat de avantajele SSL prin trecerea la https: // protocol. Cu toate acestea, pentru a face ca aplicația Web să funcționeze pe HTTPS, trebuie să aveți un certificat digital de lucru implementat pe server.
La fel cum aveți nevoie de carduri de identitate pentru a vă prezenta identitatea, un server web are nevoie de un certificat digital pentru a se identifica. Certificatele (sau "certificatele") sunt emise de o autoritate de certificare (CA) și garantează pentru identitatea dvs. pe web. AC sunt gardienii PKI. Cea mai comună formă de certificate este standardul X.509 v3, care conține informații, cum ar fi:
Atunci când un client face o cerere prin HTTPS, mai întâi încearcă să găsească un certificat pe server. În cazul în care cert este găsit, ea încearcă să verfiy împotriva lista sa cunoscută de CAs. Dacă nu este una dintre CA-urile listate, ar putea afișa o fereastră de dialog cu avertismentul utilizatorului despre certficatul site-ului web.
Odată ce certificatul este verificat, strângerea de mână SSL este completă și transmisia sigură este în vigoare.
În general, este de acord că realizarea aceleiași lucrări de două ori este risipă. Acesta este principiul călăuzitor în jurul conceptului de caching HTTP, un pilon fundamental al infrastructurii rețelei HTTP. Deoarece majoritatea operațiunilor se desfășoară într-o rețea, o memorie cache contribuie la economisirea timpului, a costurilor și a lățimii de bandă, precum și la îmbunătățirea experienței pe web.
Cache-urile sunt utilizate în mai multe locuri în infrastructura de rețea, de la browser la serverul de origine. În funcție de locul în care se află, o memorie cache poate fi clasificată ca:
Indiferent de locul în care se află o memorie cache, procesul de menținere a unei cache este destul de similar:
Desigur, serverul este responsabil pentru întotdeauna să răspundă cu antetele și răspunsurile corecte. Dacă un document nu sa schimbat, serverul ar trebui să răspundă cu un a 304 Nu a fost modificat. Dacă copia memorată în memoria cache a expirat, aceasta ar trebui să genereze un nou răspuns cu anteturile de răspuns actualizate și să se întoarcă cu un a 200 OK. Dacă resursa este ștearsă, ar trebui să revină cu ea 404 Nu a fost gasit. Aceste răspunsuri ajută la reglarea memoriei cache și asigurați-vă că conținutul vechi nu este păstrat prea mult timp.
Conexiunile paralele, în combinație cu conexiuni persistente, reprezintă răspunsul de astăzi la minimizarea întârzierilor în rețea.
Acum, că avem un sentiment de funcționare a unui cache, este timpul să examinăm antetele de solicitare și de răspuns care permit infrastructura de cache. Păstrarea conținutului în stare proaspătă și actualizată este una dintre responsabilitățile principale ale cache-ului. Pentru a păstra copia în memoria cache în concordanță cu serverul, HTTP oferă câteva mecanisme simple, și anume Exitarea documentului și Revalidarea serverului.
HTTP permite unui server de origine să atașeze un server data expirării la fiecare document utilizând Cache-Control și expiră raspuns antetele. Acest lucru ajută clientul și alte servere de memorie să știe cât timp un document este valabil și proaspăt. Cache-ul poate servi copia atâta timp cât vârstă a documentului se află în data de expirare. Odată ce un document expiră, memoria cache trebuie să verifice cu serverul pentru o copie mai nouă și să actualizeze copia locală în consecință.
expiră este un antet mai vechi de răspuns HTTP / 1.0 care specifică valoarea ca dată absolută. Acest lucru este util doar dacă ceasurile serverului sunt sincronizate cu clientul, ceea ce este o presupunere teribilă de făcut. Acest antet este mai puțin util în comparație cu cel mai nou Controlul cache-ului: max-age = antet introdus în HTTP / 1.1. Aici, max-age este o vârstă relativă, specificată în câteva secunde, de la momentul creării răspunsului. Astfel, dacă un document ar trebui să expire după o zi, antetul de expirare ar trebui să fie Controlul cache-ului: max-age = 86400.
Odată ce un document memorat în memoria cache expiră, memoria cache trebuie revalidată cu serverul pentru a verifica dacă documentul sa modificat. Aceasta se numește revalidarea serverului și servește ca un mecanism de interogare pentru stale-ness a unui document. Doar pentru că o copie cache a expirat nu înseamnă că serverul are de fapt conținut mai nou. Revalidarea este doar un mijloc de a vă asigura că memoria cache rămâne proaspătă. Din cauza timpului de expirare (așa cum este specificat într-un răspuns anterior al serverului), cache-ul nu trebuie să verifice cu serverul pentru fiecare solicitare, economisind astfel lățimea de bandă, timpul și reducerea traficului de rețea.
Combinația dintre expirarea documentului și revalidarea serverului este un mecanism foarte eficient și permite sistemelor distribuite să păstreze copii cu o dată de expirare.
Dacă se știe că conținutul se schimbă frecvent, timpul de expirare poate fi redus - permițând sistemelor să se sincronizeze mai frecvent.
Etapa de revalidare poate fi realizată cu două tipuri de anteturi de cerere: If-Modified-Since și Dacă-Fără-Match. Primul este pentru validarea bazată pe date, în timp ce acesta din urmă utilizează Entity-Tags (ETags), un hash al conținutului. Aceste anteturi utilizează date sau valori ETag obținute dintr-un răspuns anterior al serverului. In caz de If-Modified-Since, Modificat ultima dată este folosit un antet de răspuns; pentru Dacă-Fără-Match, este ETag răspuns antet.
Perioada de valabilitate a unui document trebuie definită de serverul care generează documentul. Dacă este un site de ziare, pagina de pornire ar trebui să expire după o zi (sau uneori chiar la fiecare oră!). HTTP oferă Cache-Control și expiră pentru a stabili expirarea documentelor. Ca menționat mai devreme, expiră se bazează pe datele absolute și nu o soluție fiabilă pentru controlul memoriei cache.
Cache-Control antetul este mult mai util și are câteva valori diferite pentru a limita modul în care clienții ar trebui să fie cache răspunsul:
Ca o parte, dacă serverul nu trimite niciunul Cache-Control headers, clientul este liber să utilizeze propriul algoritm de expirare euristică pentru a determina prospețimea.
Cachabilitatea nu se limitează numai la server. De asemenea, poate fi specificat de la client. Acest lucru permite clientului să impună constrângeri asupra a ceea ce este dispus să accepte. Acest lucru este posibil prin intermediul aceluiași lucru Cache-Control antet, deși cu câteva valori diferite:
Caching-ul HTTP este de fapt un subiect foarte interesant și există algoritmi foarte sofisticați pentru gestionarea conținutului stocat în cache. Pentru o privire mai aprofundată asupra acestui subiect, consultați secțiunea Caching din specificația HTTP.
Turul HTTP a început cu crearea schemelor URL, a codurilor de stare și a antetelor de solicitare / răspuns. Bazându-ne pe aceste concepte, ne-am uitat la unele dintre zonele mai fine ale HTTP, cum ar fi manipularea conexiunilor, identificarea și autentificarea și cache-ul. Sunt convins că acest turneu ți-a dat un gust bun pentru lățimea HTTP și indicii suficienți pentru a explora în continuare acest protocol.
