Share
În primul capitol am vorbit despre resurse, dar am concentrat mai mult pe adrese URL și despre modul în care să interpretăm o adresă URL. Cu toate acestea, resursele reprezintă elementul central al HTTP. Acum, când înțelegem mesajele HTTP, metodele și conexiunile, ne putem întoarce să privim resursele într-o lumină nouă. În acest capitol vom vorbi despre adevărata esență de lucru cu resurse atunci când arhitectura aplicații web și servicii web.
Deși este ușor să se gândească la o resursă web ca fiind un fișier pe un sistem de fișiere al serverului web, gândirea de-a lungul acestor linii disrespectează capacitatea reală a abstractizării resurselor. Multe pagini web necesită resurse fizice pe un sistem de fișiere - fișiere JavaScript, imagini și foi de stil. Cu toate acestea, consumatorii și utilizatorii de pe Internet nu le pasă prea mult de aceste resurse de fond. În schimb, le pasă de resursele cu care pot interacționa și, mai important, de resursele pe care le pot numi. Resurse cum ar fi:
Toate aceste resurse sunt tipurile de resurse pe care le construim în jurul aplicațiilor, iar tema comună din listă este modul în care fiecare element este suficient de semnificativ pentru a identifica și a denumi. Dacă putem identifica o resursă, putem da resurselor o adresă URL pentru ca cineva să găsească resursa. O adresă URL este un lucru util pentru a avea în jur. Având în vedere o adresă URL, puteți găsi o resursă, desigur, dar puteți, de asemenea, să trimiteți adresa URL unei alte persoane, încorporând adresa URL într-un hyperlink sau trimițând-o într-un e-mail.
Dar, există multe lucruri pe care nu le puteți face cu o adresă URL. Mai degrabă, există multe lucruri pe care un URL nu le poate face. De exemplu, o adresă URL nu poate restricționa clientul sau serverul la un anumit tip de tehnologie. Toată lumea vorbește HTTP. Nu contează dacă clientul tău este C ++ și aplicația ta web este în Ruby.
De asemenea, o adresă URL nu poate forța serverul să stocheze o resursă utilizând o anumită tehnologie. Resursa ar putea fi un document despre sistemul de fișiere, dar un cadru web ar putea, de asemenea, să răspundă cererii pentru resursă și să construiască resursele utilizând informațiile stocate în fișiere, stocate în baze de date, preluate din serviciile web sau să obțină resursele din actual ora din zi.
O adresă URL nu poate specifica chiar reprezentarea unei resurse specifice, iar o resursă poate avea reprezentări multiple. După cum am aflat mai devreme, un client poate solicita o reprezentare specială utilizând anteturile în mesajul de solicitare HTTP. Un client poate solicita o anumită limbă sau un anumit tip de conținut. Dacă ați lucrat vreodată cu o aplicație web care permite negocierea conținutului, ați văzut flexibilitatea resurselor în acțiune. JavaScript poate solicita datele pacientului 123 în format JSON, C # poate solicita aceeași resursă în format XML și un browser poate solicita datele în format HTML. Toți lucrează cu aceeași resursă, dar folosesc trei reprezentări diferite.
Există încă un lucru pe care o adresă URL nu o poate face - nu poate spune ce vrea un utilizator do cu o resursă. O adresă URL nu spune dacă vreau să recuperez o resursă sau să editez o resursă. Este sarcina mesajului de solicitare HTTP să descrie această intenție utilizând una dintre metodele standard HTTP. Așa cum am vorbit în partea a doua a acestei sesiuni, există un număr limitat de metode standard HTTP, inclusiv OBȚINE, POST, A PUNE, și ȘTERGE.
Când începeți să vă gândiți la resurse și adrese URL așa cum suntem în acest capitol, începeți să vedeți webul ca parte a aplicației dvs. și ca un strat arhitectural flexibil pe care să puteți construi. Pentru o mai bună cunoaștere a acestei linii de gândire, vedeți celebra disertație a lui Roy Fielding intitulată "Stiluri arhitecturale și proiectarea arhitecturilor software de rețea". Această teză este lucrarea care introduce stilul de arhitectură de transfer reprezentat de stat (REST) și intră în detaliu cu privire la ideile și conceptele din această secțiune și din următoarea. Articolul se află la http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm.
Până acum, ne-am concentrat asupra unei adrese URL nu pot face, când ar trebui să ne concentrăm asupra unei adrese URL pot face. Sau mai degrabă, concentrați-vă asupra a ceea ce poate face o adresă URL și HTTP, deoarece acestea funcționează frumos împreună. În disertație, Fielding descrie beneficiile adoptării HTTP. Aceste beneficii includ scalabilitatea, simplitatea, fiabilitatea și cuplajul liber. HTTP oferă aceste beneficii în parte pentru că vă puteți gândi la o adresă URL ca indicator sau o unitate de indirecție între o aplicație client și server. Din nou, URL-ul în sine nu dictează o reprezentare specifică a resurselor, o implementare a tehnologiei sau intenția clientului. În schimb, un client poate exprima intenția și reprezentarea dorită într-un mesaj HTTP.
Un mesaj HTTP este un mesaj simplu, simplu text. Frumusețea mesajului HTTP este modul în care atât cererea, cât și răspunsul se descriu pe deplin. O solicitare include metoda HTTP (ceea ce clientul dorește să facă), calea spre resursă și anteturile suplimentare care oferă informații despre reprezentarea dorită. Un răspuns include un cod de stare pentru a indica rezultatul tranzacției, dar include și antete cu instrucțiuni de memorie cache, tipul de conținut al resursei, lungimea resursei și, eventual, alte metadate valoroase.
Deoarece toate informațiile necesare pentru o tranzacție sunt conținute în mesaje și deoarece informațiile sunt vizibile și ușor de analizat, aplicațiile HTTP se pot baza pe un număr de servicii care oferă valoare ca urmare a mutării unui mesaj între aplicația client și aplicația server.
Întrucât un mesaj HTTP se deplasează din spațiul de memorie dintr-un proces pe o singură mașină în spațiul de memorie într-un proces de pe altă mașină, acesta se poate deplasa prin mai multe bucăți de software și hardware care inspectează și eventual modifică mesajul. Un exemplu bun este aplicația serverului web în sine. Un server web, cum ar fi Apache sau IIS, va fi unul dintre primii destinatari ai unei cereri de HTTP primite pe o mașină server, iar ca server web poate direcționa mesajul la aplicația corespunzătoare.
Serverul web poate utiliza informațiile dintr-un mesaj, cum ar fi adresa URL sau antetul gazdei, atunci când se decide unde să trimită un mesaj. Serverul poate efectua, de asemenea, acțiuni suplimentare cu mesajul, cum ar fi logarea mesajului într-un fișier local. Aplicațiile de pe server nu trebuie să vă faceți griji cu privire la logare, deoarece serverul este configurat să înregistreze toate mesajele.
De asemenea, atunci când o aplicație creează un mesaj de răspuns HTTP, serverul are șansa de a interacționa cu mesajul pe cale de ieșire. Din nou, aceasta ar putea fi o operație simplă de înregistrare, dar ar putea fi și o modificare directă a mesajului însuși. De exemplu, un server poate ști dacă un client acceptă compresie gzip, deoarece un client poate face public acest fapt printr-un Accept-Encoding antet în solicitarea HTTP. Compresia permite unui server să ia o resursă de 100 KB și să o transforme într-o resursă de 25 KB pentru o transmisie mai rapidă. Puteți configura multe servere web să utilizeze automat compresia pentru anumite tipuri de conținut (de obicei tipuri de text), iar acest lucru se întâmplă fără ca aplicația să fie îngrijorată de compresie. Compresia este o valoare adăugată furnizată de software-ul serverului web în sine.
Aplicațiile nu trebuie să vă faceți griji cu privire la logarea tranzacțiilor HTTP sau a comprimării, și asta datorită mesajelor HTTP auto-descriptive care permit altor piese de infrastructură să proceseze și să transforme mesajele. Acest tip de procesare se poate întâmpla ca mesajul să se deplaseze și în rețea.
A server proxy este un computer care se află între un client și un server. Un proxy este în mare parte transparent pentru utilizatorii finali. Credeți că trimiteți mesaje de solicitare HTTP direct către un server, dar mesajele merg de fapt la un proxy. Proxy-ul acceptă mesaje de solicitare HTTP de la un client și transmite mesajele către serverul dorit. Proxy-ul primește răspunsul serverului și transmite răspunsul clientului. Înainte de a redirecționa aceste mesaje, proxy-ul poate inspecta mesajele și poate efectua eventuale acțiuni suplimentare.
Unul dintre clienții la care lucrez utilizează un server proxy pentru a capta tot traficul HTTP care iese din birou. Ei nu vor ca angajații și contractorii să-și petreacă timpul pe Twitter și Facebook, astfel că cererile HTTP către acele servere nu vor ajunge niciodată la destinație și nu există tweeting sau Farmville în interiorul biroului. Acesta este un exemplu al unui rol popular pentru serverele proxy, care trebuie să funcționeze ca un dispozitiv de control al accesului.
Cu toate acestea, un server proxy poate fi mult mai sofisticat decât să renunțe la mesaje către anumite gazde - un firewall simplu ar putea să-și îndeplinească datoria. Un server proxy ar putea, de asemenea, să inspecteze mesajele pentru a elimina datele confidențiale, cum ar fi referer care indică resursele interne din rețeaua companiei. Un proxy de control al accesului poate loga, de asemenea, mesaje HTTP pentru a crea trasee de audit pentru tot traficul. Multe proxy-uri de control al accesului necesită autentificare de utilizator, un subiect pe care îl vom examina în următorul articol.
Proxy-ul pe care îl descriu în paragraful anterior este ceea ce numim a transmite proxy. Proxy-urile forward sunt, de obicei, mai aproape de client decât serverul, iar proxy-urile forward necesită de obicei o anumită configurație în software-ul clientului sau în browserul web pentru a funcționa.
A inversă proxy este un server proxy care este mai aproape de server decât clientul și este complet transparent pentru client.
Redirecționare proxy și proxy Ambele tipuri de proxy-uri oferă o gamă largă de servicii. Dacă revenim la scenariul de compresie gzip despre care am vorbit mai devreme, un server proxy are capacitatea de a comprima corpurile de mesaje de răspuns. O companie ar putea folosi un server proxy invers pentru compresie pentru a lua sarcina computațională de pe serverele web în care trăiește aplicația. Acum, nici aplicația, nici serverul web nu trebuie să-și facă griji în ceea ce privește compresia. În schimb, compresia este o caracteristică care este stratificată prin intermediul unui proxy. Aceasta este frumusețea HTTP.
Unele alte servicii proxy populare includ următoarele.
Load balancing proxy-urile pot să primească un mesaj și să le transmită către unul din mai multe servere web pe o bază rotundă sau prin cunoașterea serverului care procesează în prezent cel mai mic număr de solicitări.
Accelerarea SSL proxy-urile pot cripta și decripta mesajele HTTP, preluând sarcina de criptare de pe un server web. Vom vorbi mai multe despre SSL în capitolul următor.
Proxy-urile pot oferi un strat suplimentar de Securitate prin filtrarea mesajelor HTTP potențial periculoase. Mai exact, mesajele care arata ca s-ar putea incerca sa gaseasca o vulnerabilitate de scripting cross-site (XSS) sau sa lanseze un atac de injectie SQL.
Caching proxy-uri pot stoca copii ale resurselor accesate frecvent și pot răspunde la mesajele care solicită direct aceste resurse. Vom face mai multe detalii despre cache în secțiunea următoare.
În cele din urmă, merită să subliniem că un proxy nu trebuie să fie un server fizic. Fiddler, un instrument menționat în capitolul precedent, este un program de depanare HTTP care vă permite să capturați și să inspectați mesajele HTTP. Fiddler funcționează spunând Windows să transmită tot traficul HTTP la portul 8888 pe adresa IP 127.0.0.1. Această adresă IP este adresa de retur, ceea ce înseamnă că traficul merge direct la mașina locală unde Fiddler ascultă acum pe portul 8888. Fiddler primește mesajul de solicitare HTTP, îl înregistrează, îl transmite către destinație și captează răspunsul înainte de redirecționare răspunsul la cererea locală. Puteți vedea setările proxy din Internet Explorer (IE) accesând Unelte, optiuni de internet, dând clic pe Conexiuni , apoi faceți clic pe Setări LAN buton. Sub Server proxy zona, faceți clic pe Avansat pentru a vedea detaliile serverului proxy.
Setări proxy în Internet Explorer Proxy-urile sunt un exemplu perfect de modul în care HTTP poate influența arhitectura unei aplicații web sau a unui site Web. Există multe servicii pe care le puteți strela în rețea fără a afecta aplicația. Singurul serviciu pe care dorim să îl examinăm în detaliu este caching-ul.
Caching este o optimizare făcută pentru a îmbunătăți performanța și scalabilitatea. Atunci când există mai multe solicitări pentru aceeași reprezentare a resurselor, un server poate trimite aceleași octeți prin rețeaua din timp și din nou pentru fiecare solicitare. Sau, un server proxy sau un client poate cache reprezentarea locală și poate reduce timpul și lățimea de bandă necesare pentru o recuperare completă. Caching-ul poate reduce latența, poate ajuta la prevenirea blocajelor și permite unei aplicații web să supraviețuiască atunci când fiecare utilizator apare imediat pentru a cumpăra cel mai nou produs sau pentru a vedea cel mai recent comunicat de presă. Caching-ul este, de asemenea, un exemplu foarte bun pentru modul în care metadatele din antetele mesajului HTTP facilitează straturi și servicii suplimentare.
Primul lucru de știut este că există două tipuri de cache-uri.
A cache publică este un cache partajat între mai mulți utilizatori. O cache publică se află în general pe un server proxy. O cache publică pe un proxy proxy este, în general, cache resursele care sunt populare într-o comunitate de utilizatori, cum ar fi utilizatorii unei anumite companii sau utilizatorii unui anumit furnizor de servicii Internet. O cache publică pe un proxy invers este, în general, cache resursele care sunt populare pe un anumit site web, cum ar fi imagini populare produs de la Amazon.com.
A cache privat este dedicat unui singur utilizator. Browserele Web păstrează întotdeauna o cache privat de resurse pe disc (acestea sunt "Temporary Internet Files" în IE, sau tip despre: cache în bara de adrese a Google Chrome pentru a vedea fișiere în cache-ul privat al Chrome). Orice browser are cache în sistemul de fișiere poate apărea aproape instantaneu pe ecran.
Regulile despre ceea ce să stocheze cache-ul, când să cache și când să invalideze un element cache (de exemplu, să-l scoateți din memoria cache) sunt din păcate complicate și împovărate de unele comportamente moștenite și de implementări incompatibile. Cu toate acestea, mă voi strădui să subliniez câteva dintre lucrurile pe care ar trebui să le știi despre caching.
În HTTP 1.1, un mesaj de răspuns cu un cod de stare 200 (OK) pentru un HTTP OBȚINE cererea este disponibilă în mod implicit în cache (ceea ce înseamnă că este legal ca proxy-urile și clienții să cacheze răspunsul). O aplicație poate influența această valoare implicită utilizând antetele potrivite într-un răspuns HTTP. În HTTP 1.1, acest antet este Cache-Control header, deși puteți vedea și un expiră antet în mai multe mesaje. expiră antetul este încă în jur și este acceptat pe scară largă, în ciuda faptului că a fost depreciat în HTTP 1.1. Pragma este un alt exemplu de antet utilizat pentru a controla comportamentul de cache, dar este chiar într-adevăr numai în jurul pentru compatibilitate înapoi. În această carte mă voi concentra Cache-Control.
Un răspuns HTTP poate avea o valoare pentru Cache-Control de public, privat, sau no-cache. O valoare de public înseamnă că serverele proxy publice pot memora cache răspunsul. O valoare de privat înseamnă că numai browserul poate memora cache răspunsul. O valoare de no-cache înseamnă că nimeni nu ar trebui să cacheze răspunsul. Este deasemenea o no-magazin valoare, ceea ce înseamnă că mesajul ar putea conține informații sensibile și nu ar trebui să fie persistent, ci ar trebui să fie eliminat din memorie cât mai curând posibil.
Cum folosiți aceste informații? Pentru resursele partajate populare (cum ar fi imaginea de siglă a paginii de pornire), este posibil să doriți să utilizați a public directiva de control al cache-ului și permite tuturor să cacheze imaginea, chiar serverele proxy.
Pentru răspunsurile la un anumit utilizator (cum ar fi codul HTML pentru pagina de pornire care include numele utilizatorului), doriți să utilizați o directivă cache privată.
Notă: În ASP.NET puteți controla aceste setări prin Response.Cache.
Un server poate specifica și a max-age valoare în Cache-Control. max-age valoarea este numărul de secunde în memoria cache a răspunsului. Odată ce aceste secunde expiră, cererea ar trebui întotdeauna să revină la server pentru a prelua un răspuns actualizat. Să ne uităm la câteva exemple de răspunsuri.
Iată un răspuns parțial de la Flickr.com pentru unul dintre fișierele CSS Flickr.
HTTP / 1.1 200 OK Ultima modificare: Wed, 25 Jan 2012 17:55:15 GMT Expiră: Sat, 22 Jan 2022 17:55:15 GMT Cache-Control: max-age = 315360000, public
Observați Cache-Control permite cache-urilor publice și private să stocheze fișierul și să-l păstreze în jur de 315 de milioane de secunde (10 ani). De asemenea, folosesc un expiră antetul pentru a da o anumită dată de expirare. Dacă un client este compatibil cu HTTP 1.1 și înțelege Cache-Control, ar trebui să utilizeze valoarea în max-age in loc de expiră. Rețineți că acest lucru nu înseamnă că Flickr intenționează să utilizeze același fișier CSS timp de 10 ani. Când Flickr își modifică designul, probabil va folosi doar o adresă URL diferită pentru fișierul CSS actualizat.
De asemenea, răspunsul include a Modificat ultima dată antetul pentru a indica momentul ultimei modificări a reprezentării (care ar putea fi momentul solicitării). Memoria cache poate folosi această valoare ca a validator, sau o valoare pe care clientul o poate utiliza pentru a vedea dacă reprezentarea memorată în cache este încă valabilă. De exemplu, dacă agentul decide că trebuie să verifice resursele, poate emite următoarea solicitare.
GET ... HTTP / 1.1 Dacă-Modificat-Din-Joi, 25 Jan 2012 17:55:15 GMT
If-Modified-Since antetul spune serverului că clientul are nevoie doar de răspunsul complet dacă resursa sa schimbat. Dacă resursele nu s-au schimbat, serverul poate răspunde cu un a 304 Nu a fost modificat mesaj.
HTTP / 1.1 304 Modificat expiră: Sat, 22 Jan 2022 17:16:19 GMT Cache-Control: max-age = 315360000, public
Serverul îi spune clientului: Continuați și utilizați octeții pe care îi aveți deja în cache.
Un alt validator pe care îl veți vedea în mod obișnuit este ETag.
HTTP / 1.1 200 OK Server: Apache Ultima modificare: Fri, 06 Jan 2012 18:08:20 GMT ETAG: "8e5bcd-59f-4b5dfef104d00" Content-Type: text / xml Vary: Acceptare codificare conținut: -Lungime: 437
ETag este un identificator opac, adică nu are niciun înțeles inerent. Un ETag este adesea creat folosind un algoritm de hash împotriva resursei. Dacă resursa se modifică vreodată, serverul va calcula un nou ETag. O intrare în cache poate fi validată prin compararea a două ETags. În cazul în care ETags sunt la fel, nimic nu sa schimbat. În cazul în care ETags sunt diferite, este timpul să invalideze memoria cache.
În acest capitol am abordat câteva teorii arhitecturale, precum și beneficii practice ale arhitecturii HTTP. Abilitatea de a cache strat și alte servicii între un server și un client a fost o forță motrice în spatele succesului HTTP și a web-ului. Vizibilitatea mesajelor HTTP autoportante și indirecției oferite de adresele URL face totul posibil. În capitolul următor vom vorbi despre câteva subiecte pe care le-am abordat în jurul nostru, subiecte precum autentificarea și criptarea.
Accentsconagua