Share
I det första kapitlet pratade vi om resurser, men mestadels fokuserade på webbadresser och hur man tolka en webbadress. Resurser är dock höjdpunkten för HTTP. Nu när vi förstår HTTP-meddelanden, metoder och anslutningar kan vi återvända för att titta på resurser i ett nytt ljus. I det här kapitlet talar vi om den verkliga vägen för att arbeta med resurser när vi arkitekturerar webbapplikationer och webbtjänster.
Även om det är lätt att tänka på en webresurs som en fil på en webbservers filsystem, respekterar tanken på dessa sätt den verkliga förmågan hos resursabstraktionen. Många webbsidor kräver fysiska resurser på ett filsystem - JavaScript-filer, bilder och stilark. Men konsumenter och användare av webben bryr sig inte mycket om dessa bakgrundsresurser. Istället bryr de sig om resurser som de kan interagera med, och ännu viktigare resurser de kan namnge. Resurser som:
Alla dessa resurser är de typer av resurser vi bygger applikationer runt och det vanliga temat i listan är hur varje objekt är tillräckligt stor för att identifiera och namnge. Om vi kan identifiera en resurs kan vi också ge resursen en URL för att någon ska hitta resursen. En URL är en praktisk sak att ha runt. Med en webbadress kan du självklart hitta en resurs, men du kan också ge webbadressen till någon annan genom att bädda in webbadressen i en hyperlänk eller skicka den till ett mail.
Men det finns många saker som du inte kan göra med en webbadress. Snarare finns det många saker som en URL inte kan göra. En webbadress kan till exempel inte begränsa klienten eller servern till en viss typ av teknik. Alla talar HTTP. Det spelar ingen roll om din klient är C ++ och din webbapplikation är i Ruby.
En URL kan inte tvinga servern att lagra en resurs med någon särskild teknik. Resursen kan vara ett dokument på filsystemet, men en webbram kan också svara på begäran om resursen och bygga resursen med hjälp av information som lagras i filer, lagras i databaser, hämtas från webbtjänster eller härleda resursen från den aktuella tidpunkt på dygnet.
En URL kan inte ens ange representation av en specifik resurs och en resurs kan ha flera representationer. Som vi lärt oss tidigare kan en klient begära en viss representation med hjälp av rubriker i HTTP-förfrågan. En klient kan begära ett specifikt språk eller en viss innehållstyp. Om du någonsin har arbetat med en webbapplikation som tillåter innehållsförhandlingar, har du sett flexibiliteten i resurserna i åtgärd. JavaScript kan begära patientens 123 data i JSON-format, C # kan begära samma resurs i XML-format, och en webbläsare kan begära data i HTML-format. De arbetar alla med samma resurs, men använder tre olika representationer.
Det finns en sak en URL kan inte göra - det kan inte säga vad en användare vill do med en resurs. En URL säger inte om jag vill hämta en resurs eller redigera en resurs. Det är jobbet i HTTP-förfrågningsmeddelandet för att beskriva denna avsikt med hjälp av en av HTTP-standardmetoderna. Som vi pratade om i del 2 av denna session finns det ett begränsat antal standard HTTP-metoder, inklusive SKAFFA SIG, POSTA, SÄTTA, och RADERA.
När du börjar tänka på resurser och webbadresser som vi är i det här kapitlet börjar du se webben som en del av din ansökan och som ett flexibelt arkitektoniskt lager som du kan bygga på. För mer inblick i denna tankegång, se Roy Fieldings berömda avhandling med titeln "Architectural Styles and the Design of Network-Based Software Architectures". Denna avhandling är det papper som introducerar arkitekturens representativa statsöverföring (REST) stil och går in mer i detalj om idéerna och koncepten i det här avsnittet och nästa. Artikeln finns på http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm.
Hittills har vi fokuserat på vilken webbadress kan inte göra, när vi bör fokusera på vilken webbadress kan göra. Eller hellre, fokusera på vad en URL och HTTP kan göra, eftersom de fungerar vackert tillsammans. Fielding beskriver i sin avhandling fördelarna med att omfatta HTTP. Dessa fördelar inkluderar skalbarhet, enkelhet, tillförlitlighet och lös koppling. HTTP erbjuder dessa fördelar till viss del eftersom du kan tänka dig en webbadress som en pekare eller en enhet av indirection mellan en klient och en serverapplikation. Återigen dikterar URL-adressen inte en specifik resursrepresentation, teknikimplementation eller klientens avsikt. Istället kan en klient uttrycka önskad avsikt och representation i ett HTTP-meddelande.
Ett HTTP-meddelande är ett enkelt, vanligt textmeddelande. Skönheten i HTTP-meddelandet är hur både begäran och svaret är helt självbeskrivande. En förfrågan inkluderar HTTP-metoden (vad kunden vill göra), sökvägen till resursen och ytterligare rubriker som ger information om önskad representation. Ett svar innehåller en statuskod för att ange resultatet av transaktionen, men inkluderar också rubriker med cachinstruktioner, resursens innehållstyp, resursens längd och eventuellt andra värdefulla metadata.
Eftersom all information som krävs för en transaktion finns i meddelandena och eftersom informationen är synlig och lätt att analysera kan HTTP-applikationer förlita sig på ett antal tjänster som ger värde som ett meddelande rör sig mellan klientprogrammet och serverns applikation.
Eftersom ett HTTP-meddelande flyttas från minnesutrymmet i en process på en maskin till minnesutrymmet i en process på en annan maskin, kan den gå igenom flera bitar av programvara och maskinvara som inspekterar och eventuellt ändrar meddelandet. Ett bra exempel är webbserverns ansökan själv. En webbserver som Apache eller IIS kommer att vara en av de första mottagarna av en inkommande HTTP-begäran på en servermaskin och som en webbserver kan den ruttra meddelandet till den korrekta applikationen.
Webbservern kan använda information i ett meddelande, till exempel webbadressen eller värdhuvudet, när man bestämmer var man ska skicka ett meddelande. Servern kan också utföra ytterligare åtgärder med meddelandet, till exempel att logga meddelandet till en lokal fil. Applikationerna på servern behöver inte oroa sig för att logga, eftersom servern är konfigurerad att logga alla meddelanden.
På samma sätt, när en applikation skapar ett HTTP-svarmeddelande, har servern en chans att interagera med meddelandet på väg ut. Återigen kan detta vara en enkel loggningsoperation, men det kan också vara en direkt modifiering av meddelandet själv. En server kan till exempel veta om en klient stöder gzip-komprimering, eftersom en klient kan annonsera detta faktum genom en Accept-Encoding rubrik i HTTP-förfrågan. Komprimering gör det möjligt för en server att ta en 100-KB-resurs och göra den till en 25-kb resurs för snabbare överföring. Du kan konfigurera många webbservrar att automatiskt använda komprimering för vissa innehållstyper (vanligtvis texttyper), och detta händer utan att själva programmet bekymrar sig om komprimering. Komprimering är ett mervärde som tillhandahålls av webbserverprogramvaran själv.
Applikationer behöver inte oroa sig för att logga på HTTP-transaktioner eller komprimering, och det här är allt tack vare de självbeskrivande HTTP-meddelandena som tillåter andra delar av infrastrukturen att bearbeta och omforma meddelanden. Denna typ av bearbetning kan ske när meddelandet rör sig över nätverket också.
en proxyserver är en dator som sitter mellan en klient och en server. En proxy är mest transparent för slutanvändare. Du tror att du skickar HTTP-förfrågningsmeddelanden direkt till en server, men meddelandena går faktiskt till en proxy. Proxyn accepterar HTTP-förfrågningsmeddelanden från en klient och vidarebefordrar meddelanden till den önskade servern. Proxyn tar sedan serverns svar och vidarebefordrar svaret tillbaka till klienten. Innan vidarebefordran av dessa meddelanden kan proxyn inspektera meddelandena och eventuellt vidta några ytterligare åtgärder.
En av de klienter jag jobbar för använder en proxyserver för att fånga all HTTP-trafik som lämnar kontoret. De vill inte att anställda och entreprenörer spenderar hela sin tid på Twitter och Facebook, så HTTP-förfrågningar till de servrarna kommer aldrig att nå deras destination och det finns ingen tweeting eller Farmville på kontoret. Detta är ett exempel på en populär roll för proxyservrar, som ska fungera som en åtkomstkontrollenhet.
En proxyserver kan dock vara mycket mer sofistikerad än att bara släppa meddelanden till specifika värdar. En enkel brandvägg kan utföra den plikten. En proxyserver kan också inspektera meddelanden för att ta bort konfidentiella data, som t.ex. referer rubriker som pekar på interna resurser på företagsnätverket. En proxy för åtkomstkontroll kan också logga in HTTP-meddelanden för att skapa revisionsspår på all trafik. Många åtkomstkontrollproxys kräver användarautentisering, ett ämne som vi ser på i nästa artikel.
Den proxy som jag beskriver i föregående stycke är vad vi kallar a vidarebefordra proxy. Framåtvolymer är vanligtvis närmare klienten än servern, och vidarebefordringsförvaltare behöver vanligtvis någon konfiguration i klientprogramvaran eller webbläsaren för att arbeta.
en omvänd proxy är en proxyserver som ligger närmare servern än klienten och är helt transparent för klienten.
Framåt och omvänd proxy Båda typer av proxyer kan erbjuda ett brett utbud av tjänster. Om vi återvänder till gzip-komprimeringsscenariot vi pratade om tidigare har en proxyserver möjlighet att komprimera meddelanden för svarmeddelanden. Ett företag kan använda en omvänd proxyserver för komprimering för att ta bort beräkningsbelastningen från webbservrarna där applikationen lever. Nu behöver varken applikationen eller webbservern oroa sig för komprimering. I stället är komprimering en funktion som är inlagd via en proxy. Det är skönheten i HTTP.
Några andra populära proxitjänster inkluderar följande.
Lastbalansering proxies kan ta ett meddelande och vidarebefordra det till en av flera webbservrar på round-robin-basis eller genom att veta vilken server som för närvarande behandlar det färsta antalet förfrågningar.
SSL-acceleration proxy kan kryptera och dekryptera HTTP-meddelanden, varvid krypteringsbelastningen av en webbserver. Vi pratar mer om SSL i nästa kapitel.
Proxies kan ge ytterligare ett lager av säkerhet genom att filtrera ut potentiellt farliga HTTP-meddelanden. Specifikt, meddelanden som ser ut som om de kanske försöker hitta en sårbarhet för cross-site scripting (XSS) eller starta en SQL-injektionsattack.
Caching proxies kan lagra kopior av ofta åtkomna resurser och svara på meddelanden som begär dessa resurser direkt. Vi kommer att gå in mer i detalj om caching i nästa avsnitt.
Slutligen är det värt att påpeka att en proxy inte behöver vara en fysisk server. Fiddler, ett verktyg som nämns i föregående kapitel, är en HTTP-debugger som låter dig fånga och inspektera HTTP-meddelanden. Fiddler fungerar genom att berätta för Windows att vidarebefordra all utgående HTTP-trafik till port 8888 på IP-adress 127.0.0.1. Denna IP-adress är loopback-adressen, vilket innebär att trafiken helt enkelt går direkt till den lokala maskinen där Fiddler nu lyssnar på port 8888. Fiddler tar HTTP-förfrågningsmeddelandet, loggar det, vidarebefordrar det till destinationen och tar även in svaret innan vidarebefordran svaret på den lokala ansökan. Du kan visa proxyinställningarna i Internet Explorer (IE) genom att gå till Verktyg, Internet-alternativ, klicka på anslutningar fliken och klicka sedan på LAN-inställningar knapp. Under Proxyserver område, klicka på Avancerad knappen för att se proxyserverns detaljer.
Proxy-inställningar i Internet Explorer Proxies är ett perfekt exempel på hur HTTP kan påverka arkitekturen för en webbapplikation eller webbplats. Det finns många tjänster du kan lagra in i nätverket utan att påverka programmet. Den en tjänst vi vill undersöka mer i detalj är caching.
Caching är en optimering för att förbättra prestanda och skalbarhet. När det finns flera förfrågningar om samma resursrepresentation kan en server skicka samma byte över nätverket tid och tid igen för varje förfrågan. Eller en proxyserver eller en klient kan cache representationen lokalt och minska mängden tid och bandbredd som krävs för en fullständig hämtning. Caching kan minska latensen, hjälpa till att hindra flaskhalsar och låta en webbapplikation överleva när varje användare visar sig omedelbart för att köpa den senaste produkten eller se det senaste pressmeddelandet. Cachning är också ett utmärkt exempel på hur metadata i HTTP-meddelandehuvudena underlättar ytterligare lager och tjänster.
Det första du vet är att det finns två typer av cacher.
en offentlig cache är en cache delad bland flera användare. En allmän cache finns generellt på en proxyserver. Ett offentligt cacheminne på en proxy-proxy kramar i allmänhet de resurser som är populära i ett användarnamn, som användare av ett visst företag eller användarna av en viss Internetleverantör. En offentlig cache på en omvänd proxy kramar i allmänhet de resurser som är populära på en viss webbplats, som populära produktbilder från Amazon.com.
en privat cache är tillägnad en enda användare. Webbläsare behåller alltid en privat cache med resurser på din disk (det här är "Temporary Internet Files" i IE, eller skriv om: cache i adressfältet i Google Chrome för att se filer i Chrome: s privata cache). Allt som en webbläsare har cachat på filsystemet kan visas nästan direkt på skärmen.
Reglerna om hur du cachar, när du ska cacha och när du ska invalidera ett cachepunkt (det vill säga sparka det ur cacheminnet) är tyvärr komplicerat och fördrivet av några äldre beteenden och oförenliga implementeringar. Ändå kommer jag att sträva efter att påpeka några av de saker du bör veta om caching.
I HTTP 1.1, ett svarmeddelande med en 200 (OK) statuskod för en HTTP SKAFFA SIG begäran är cacheable som standard (vilket betyder att det är lagligt för proxy och klienter att cache svaret). En applikation kan påverka denna standard genom att använda rätt rubriker i ett HTTP-svar. I HTTP 1.1 är denna rubrik den Cache-Control header, även om du också kan se en Utgår header i många meddelanden också. De Utgår rubriken är fortfarande runt och stöds allmänt trots att den avlägsnas i HTTP 1.1. Pragma är ett annat exempel på en rubrik som används för att styra caching beteende, men det är verkligen bara runt för bakåtkompatibilitet. I den här boken fokuserar jag på Cache-Control.
Ett HTTP-svar kan ha ett värde för Cache-Control av offentlig, privat, eller no-cache. Ett värde av offentlig betyder att offentliga proxyservrar kan cache svaret. Ett värde av privat betyder att endast webbläsaren kan cache svaret. Ett värde av no-cache betyder att ingen ska cache svaret. Det finns även en no-store värde, vilket innebär att meddelandet kan innehålla känslig information och bör inte fortsättas, men ska tas bort från minnet så snart som möjligt.
Hur använder du den här informationen? För populära delade resurser (som startsida-logotypen), kanske du vill använda en offentlig cacheskontrolldirektivet och låta alla cache bilden, även proxyservrar.
För svar på en specifik användare (som HTML för hemsidan som innehåller användarens namn) vill du använda ett privat cacherdirektiv.
Notera: I ASP.NET kan du styra dessa inställningar via Response.Cache.
En server kan också ange a max-ålder värde i Cache-Control. De max-ålder värdet är antalet sekunder att cache svaret. När dessa sekunder löper ut, bör begäran alltid gå tillbaka till servern för att hämta ett uppdaterat svar. Låt oss titta på några exempel svar.
Här är ett partiellt svar från Flickr.com för en av Flickr CSS-filerna.
HTTP / 1.1 200 OK Senast ändrad: ons 25 jan 2012 17:55:15 GMT Utgår: lör, 22 jan 2022 17:55:15 GMT Cache-Control: max-age = 315360000, offentlig
Lägg märke till Cache-Control tillåter offentliga och privata cacher att cache filen, och de kan hålla den kvar i mer än 315 miljoner sekunder (10 år). De använder också en Utgår rubrik för att ge ett visst datum för utgången. Om en klient är HTTP 1.1-kompatibel och förstår Cache-Control, det ska använda värdet i max-ålder istället för Utgår. Observera att det inte betyder att Flickr planerar att använda samma CSS-fil i 10 år. När Flickr ändrar sin design, brukar den bara använda en annan URL för sin uppdaterade CSS-fil.
Svaret innehåller också a Senast ändrad rubrik för att ange när representationen senast ändrades (vilket kanske bara var begäranens gång). Cache-logiken kan använda detta värde som en validator, eller ett värde som klienten kan använda för att se om den cachade representationen fortfarande är giltig. Till exempel, om agenten bestämmer att den måste kontrollera resursen kan den utfärda följande förfrågan.
GET ... HTTP / 1.1 If-Modified-Since: Wed, 25 Jan 2012 17:55:15 GMT
De If-Modified-Since rubrik berättar servern klienten behöver bara det fulla svaret om resursen har ändrats. Om resursen inte har ändrats kan servern svara med en 304 Ej modifierad meddelande.
HTTP / 1.1 304 Ej modifierad Utgår: lör, 22 jan 2022 17:16:19 GMT Cache-Control: max-age = 315360000, offentlig
Servern berättar för klienten: Gå vidare och använd de byte du redan har cachat.
En annan validator som du vanligtvis ser är den ETag.
HTTP / 1.1 200 OK Server: Apache Senast ändrad: fre, 06 jan 2012 18:08:20 GMT ETag: "8e5bcd-59f-4b5dfef104d00" Innehållstyp: text / xml Variera: Accept-Encoding Content-Encoding: gzip-innehåll -Längd: 437
De ETag är en ogenomskinlig identifierare, vilket betyder att den inte har någon inneboende mening. En ETag skapas ofta med en hashingalgoritm mot resursen. Om resursen ändras ändras servern en ny ETag. En cache-post kan valideras genom att jämföra två ETags. Om ETags är desamma, inget har förändrats. Om ETags är annorlunda, det är dags att upphäva cacheminnet.
I det här kapitlet täckte vi några arkitektoniska teorier samt praktiska fördelar med HTTP-arkitekturen. Möjligheten att lagra caching och andra tjänster mellan en server och klient har varit en drivkraft bakom framgången för HTTP och webben. Synligheten för de självbeskrivande HTTP-meddelandena och indirection som tillhandahålls av webbadresser gör det möjligt. I nästa kapitel ska vi prata om några av de ämnen vi har skirtat runt, ämnen som autentisering och kryptering.
Accentsconagua