Cu siguranță trebuie să înțelegeți cum funcționează caching-ul HTTP. Sincer, este necesar. Am menționat de multe ori că alegerea HTTP-metode sunt extrem de importante în proiectarea de servicii Web - în special, alegerea metodei GET vă permite să beneficieze de utilizarea HTTP-cache. Deci: pentru a obține toate avantajele pe care le poate oferi folosind metoda GET, trebuie să înțelegeți cum funcționează caching-ul HTTP și cum îl puteți utiliza în mod eficient pentru a crește performanța serviciului dvs.
În acest articol, nu voi explica cum să configurați cache-ul în serverul web pe care îl utilizați și nu voi descrie diferitele tipuri de cache-uri. Dacă sunteți interesat de toate acestea, vă recomandăm să citiți manualul remarcabil privind caching-ul HTTP de la Mark Nottingham.
Primul lucru pe care trebuie să-l înțelegeți este ce obiective sunt urmărite de modelul de caching utilizat în HTTP. Un astfel de obiectiv este acela de a permite atât clientului, cât și serverului să specifice condițiile în care documentul transmis poate fi preluat din memoria cache. Este ușor de observat că numai acest lucru aduce o anumită complexitate modelului de cache.
Baza modelului utilizat în cache HTTP, formează validatoare - o parte din interogarea utilizată de către client pentru a se asigura că documentul în cache este încă valabil (de exemplu, nu depășite). Utilizarea validatorilor permite clientului sau serverului intermediar să verifice starea curentă a documentului fără a transfera întreaga copie cache la server. Serverul, la rândul său, transmite documentul ca răspuns numai dacă validatorul acestuia indică prezența unei copii învechite (invalide) în memoria cache a clientului.
validatoare
Unul dintre validatorii utilizați în HTTP este ETag. ETAG este un hash ("amprentă") a octeților de document: dacă documentul modifică cel puțin un octet, ETag se va schimba.
Înainte de a utiliza acest validator, aveți nevoie de cel puțin o dată pentru a solicita un document utilizând metoda GET. dacă serverul acceptă această caracteristică, antetul ETag din răspunsul său va conține hash-ul versiunii de document transferat. În acest caz, clientul salvează ETag-ul în memoria cache împreună cu documentul însuși. și în cererile ulterioare ale aceluiași document utilizează ETag salvat ca validator.
De exemplu, permiteți-mi să solicit un document de pe serverul example.org. și a primit un astfel de răspuns:
Apoi data viitoare când solicit același document utilizând metoda GET. Pot folosi validatorul. Notă: valoarea ETag salvată este trecută în antetul If-None-Match.
Dacă documentul nu sa schimbat în timpul dintre solicitări, serverul va returna codul 304 Nu este modificat.
Dacă documentul se modifică, serverul returnează codul 200 și trimite o nouă versiune a documentului ca răspuns, precum și valoarea ETag a acestei versiuni noi.
Cache-Control
Validatorii sunt utilizați pentru a verifica dacă documentul sa modificat; Pentru a gestiona salvarea copiei sale în cache, se utilizează antetul Cache-Control. Cea mai importantă directivă privind gestionarea cache-ului este maxima. indică faptul că copia documentului stocat în cache expiră în secunde maxime. Această directivă poate fi utilizată atât în cerere, cât și în răspuns, astfel încât atât clientul, cât și serverul pot decide cât timp documentele pe care le transferă vor fi valide. Dacă serverul are un răspuns destul de nou în cache, acesta poate fi returnat direct din memoria cache; altfel, are loc procedura de validare de mai sus.
Luați în considerare din nou răspunsul pe care l-am primit de la server. În el, antetul Cache-Control specifică max-age = 7200. și anume copia memorată în cache a documentului încetează să mai fie valabilă după 2 ore.
În plus față de vârsta maximă. O serie de alte directive sunt permise în antetul Cache-Control. Fiecare dintre acestea poate fi utilizată fie în interogări, fie în răspunsuri sau - ca vârstă maximă - atât în interogări, cât și în răspunsuri.
Directivele permise în cereri
La fel cum trebuie - revalidați. dar funcționează numai pe un server proxy.
Iată câteva exemple de utilizare a antetului Cache-Control:
Cache-Control: private, max-age = 3600
Valabil în răspunsul de la server; înseamnă că răspunsul poate fi stocat într-o cache închis timp de o oră.
Controlul cache-ului: public, must-revalidate, max-age = 7200
Aceasta înseamnă că răspunsul poate fi stocat într-o memorie cache deschisă timp de două ore; După expirarea acestora, valabilitatea copiei salvate trebuie verificată pentru fiecare solicitare.
Cache-Control: must-revalidate, max-age = 0
Obligă clientul să reexamineze validitatea copiei salvate pentru fiecare solicitare; max-age = 0 indică faptul că documentul devine caduc în momentul în care acesta este primit de client. Articolul lui Mark Nottingham "Folosirea web-ului: Caching" oferă un exemplu interesant al unui caz în care puteți folosi o astfel de poziție.
Practic la fel ca în exemplul anterior; singura diferență este că clientul ar putea folosi directiva max-stale în solicitare și va primi un răspuns învechit, în timp ce directiva "must-revalidate" ar depăși acțiunea maximă învechită. Un astfel de sistem complex este necesar deoarece, așa cum am observat anterior, atât serverul, cât și clientul pot afecta simultan utilizarea memoriei cache.
Toate aceste exemple de utilizare a antetului Cache-Control examinează utilizarea acestuia în răspunsul de la server. Luați în considerare exemplele atunci când acest antet este utilizat într-o interogare.
Cauzează o actualizare completă a documentelor: memoria cache a accesului clientului trebuie să solicite din nou documentul de la serverul de la care a fost primit.
Cu acest antet, clientul solicită un document care va rămâne valabil timp de 200 de secunde după solicitare.
Cred că vă întrebați dacă memoria cache devine confuză în toate aceste situații. De exemplu, ce ar trebui să facă dacă serverul poate returna diferite documente pentru același URI? Pentru astfel de cazuri, antetul Vary este furnizat în HTTP. Acest antet indică memoria cache a numelui tuturor antetelor de cerere, atunci când modificați care ar fi returnat un alt document.
Să presupunem că serverul este de acord cu clientul cu tipul documentului returnat - răspunsurile diferite pentru același URI ar putea avea un antet de tip Content-Tip diferit. în funcție de tipul de document convenit. Apoi serverul poate adăuga Vary: acceptă antetul răspunsului. iar memoria cache va păstra răspunsuri separate la cereri cu diferite valori ale antetului Accept.
În acest exemplu, serverul indică faptul că răspunsul poate fi stocat în memoria cache timp de două ore, separat pentru cererile cu valori diferite ale Accept-Encoding și User-Agent.
conexiune
După ce serverul verifică cu succes validitatea rezultatului memorat, de exemplu, utilizând validatorul în antetul If-None-Match. - returnează codul 304 Nu este modificat. Mai mult, în acest caz, nu se întâmplă nimic, nu? De fapt, nu într-adevăr: serverul poate trimite valoarea titlurilor de document împreună cu răspunsul 304 nu modificat pentru a le actualiza în cache. În plus, serverul poate să afișeze în antetul conexiunii numele acelor anteturi care nu trebuie să fie actualizate în memoria cache.
În mod implicit, unele antete nu sunt stocate în memoria cache - așa-numitele „compuși din titlu» ( «hop-by-hop»): Connection, Keep-Alive, Proxy-autentificaþi, Proxy-Autorizare, TE, Remorci, Transfer-Encoding și upgrade . Valorile tuturor celorlalte anteturi - "anteturi de documente" ("end-to-end") - sunt stocate în memoria cache implicit.
În acest exemplu, valoarea antetului Date. care nu este antetul conexiunii și nu este specificat în antetul conexiunii. vor fi stocate în memoria cache.
Dacă totul era atât de simplu
Deși toate mecanismele descrise în cache reprezintă o anumită complexitate a percepției, cel puțin ei formează un sistem logic armonios. Firește, totul este complicat de necesitatea de a lucra cu serverele existente și cu clienții care utilizează protocolul HTTP 1.0. În acest protocol mai vechi, alte antete sunt folosite pentru a gestiona gestionarea cache-time-management; toate aceste anteturi mai vechi sunt acceptate în HTTP 1.1 pentru compatibilitate înapoi.
Modelul de cache folosit în HTTP 1.0 este construit în jurul duratei de expirare a documentului. Validatorul ultimei modificări verifică momentul în care documentul a fost modificat ultima dată. Cache-ul folosește anteturile Date pentru a verifica validitatea documentului. Expiră. Modificat ultima dată și dacă este modificată din moment ce.
Acum că înțelegeți cum funcționează caching-ul în HTTP, probabil că vă întrebați dacă există o bibliotecă gata pregătită cu suport pentru cache pentru limba dvs. preferată. Pot să răspund despre Python: din păcate, încă nu. Îmi pare foarte rău că nici una dintre cele mai bune implementări ale clienților HTTP nu este scrisă în limba mea preferată. Și trebuie să corectați această neînțelegere.
Mă bucur să vă prezint biblioteca httplib2 - un client HTTP complet, scris în Python. Această bibliotecă acceptă o cache privat local și înțelege toate operațiile descrise în acest articol. În plus, are multe caracteristici care de obicei nu sunt disponibile în alte biblioteci HTTP:
Puteți afla despre alte opțiuni pe pagina proiectului httplib2.
Data viitoare
Trimiteți-le prietenilor: