Share
I min tidigare artikel täckte vi några av HTTP: s grunder, till exempel URL-schema, statuskoder och begäran / svarhuvud. Med det som vår grund kommer vi att titta på de finare aspekterna av HTTP, som anslutningshantering, autentisering och HTTP-caching. Dessa ämnen är ganska omfattande, men vi täcker de viktigaste bitarna.
En anslutning måste etableras mellan klienten och servern innan de kan kommunicera med varandra, och HTTP använder det tillförlitliga TCP-transportprotokollet för att göra denna anslutning. Som standard använder webtrafik TCP-port 80. En TCP-ström bryts i IP-paket, och det säkerställer att dessa paket alltid kommer fram i rätt ordning utan att misslyckas. HTTP är ett programlagerprotokoll över TCP, vilket är över IP.
HTTPS är en säker version av HTTP, och lägger in ytterligare ett lager mellan HTTP och TCP som heter TLS eller SSL (Transport Layer Security eller Secure Sockets Layer, respektive). HTTPS kommunicerar via port 443 som standard, och vi kommer att titta på HTTPS senare i den här artikeln.
En HTTP-anslutning identifieras av
Servern ansvarar för att alltid svara med rätt rubriker och svar.
I HTTP / 1.0 stängdes alla anslutningar efter en enda transaktion. Så om en klient ville begära tre separata bilder från samma server gjorde det tre separata anslutningar till fjärrvärden. Som du kan se från ovanstående diagram kan detta introducera mycket nätverksförseningar, vilket resulterar i en suboptimal användarupplevelse.
För att minska fördröjningarna för anslutningsinrättningar infördes HTTP / 1.1 ihållande anslutningar, långlivade förbindelser som är öppna tills kunden stänger dem. Hållbara anslutningar är standard i HTTP / 1.1, och det krävs att en enkel transaktionsanslutning kräver att klienten ställer in Anslutning: nära begära rubrik Detta berättar att servern stänger anslutningen efter att ha skickat svaret.
Förutom ihållande anslutningar använder webbläsare / klienter också en teknik som heter parallella anslutningar, för att minimera nätverksförseningar. Det åldrade begreppet parallella anslutningar innebär att man skapar en anslutningspool (i allmänhet avkortad vid sex anslutningar). Om det finns sex tillgångar som klienten behöver ladda ner från en webbplats, gör klienten sex parallella anslutningar för att hämta dessa tillgångar, vilket resulterar i snabbare vändning. Det här är en stor förbättring jämfört med seriella anslutningar där klienten endast hämtar en tillgång efter att ha laddat ner nedladdningen för en tidigare tillgång.
Parallella anslutningar, i kombination med ihållande anslutningar, är dagens svar för att minimera nätverksförseningar och skapa en jämn upplevelse på klienten. För en fördjupad behandling av HTTP-anslutningar, se avsnittet Anslutningar i HTTP-specifikationen.
Servern lyssnar mestadels på inkommande anslutningar och behandlar dem när den mottar en förfrågan. Verksamheten omfattar:
Accentsconagua
Anslutning: nära begäran om rubrik hittadesDet här är naturligtvis inte en uttömmande lista över verksamheter. De flesta applikationer / webbplatser behöver veta vem som gör en förfrågan för att skapa mer anpassade svar. Detta är riken till Identifiering och autentisering.
HTTP är ett programlagerprotokoll över TCP, vilket är över IP.
Det är nästan obligatoriskt att veta vem som ansluter till en server för att spåra en applikations eller webbplatsens användning och användarnas allmänna interaktionsmönster. Identifikationsprincipen är att skräddarsy svaret för att ge en personlig upplevelse. Naturligtvis måste servern veta vem en användare är för att tillhandahålla den funktionen.
Det finns några olika sätt som en server kan samla in den här informationen, och de flesta webbplatser använder en hybrid av dessa tillvägagångssätt:
Från, referer, User-Agent - Vi såg dessa rubriker i del 1.Cookies tillåter servern att bifoga godtycklig information för utgående svar via Set-Cookie svarhuvud. En cookie är inställd med en eller flera name = värde par separerade av semikolon (;), som i Set-Cookie: session-id = 12345ABC; användarnamn = nettuts.
En server kan också begränsa cookies till en specifik domän och väg, och det kan göra dem ihållande med en löper ut värde. Cookies skickas automatiskt av webbläsaren för varje begäran som görs till en server, och webbläsaren ser till att endast domän- och väg-Speciella cookies skickas i förfrågan. Förfrågan header Kaka: namn = värde [; namn2 = värde2] används för att skicka dessa cookies till servern.
Det bästa sättet att identifiera en användare är att kräva att de registrerar sig och loggar in, men att implementera denna funktion kräver en viss insats av utvecklaren, såväl som användaren.
Tekniker som OAuth förenklar denna typ av funktion, men det kräver fortfarande användarens samtycke för att fungera korrekt. Autentisering spelar en stor roll här, och det är förmodligen det enda sättet att identifiera och verifiera användaren.
HTTP stöder en rudimentär form av autentisering som heter Grundläggande autentisering, såväl som säkrare Digest Authentication.
I Basic Authentication nekar servern ursprungligen klientens begäran med en WWW-Authenticate svarhuvud och a 401 Ej auktoriserad statuskod. När du tittar på den här rubriken visar webbläsaren en inloggningsdialog som kräver ett användarnamn och lösenord. Denna information skickas i ett bas-64 kodat format i autentisering begära rubrik Servern kan nu validera förfrågan och tillåta åtkomst om referensuppgifterna är giltiga. Vissa servrar kan också skicka en Authentication-Info rubrik som innehåller ytterligare autentiseringsuppgifter.
En följd av Basic-Authentication är Proxy-autentisering. Istället för en webbserver begärs autentikationsutmaningen av en mellanproxy. Proxy skickar en Proxy-Autentisera rubrik med a 407 Ej auktoriserad statuskod. I gengäld ska kunden skicka referenser via Proxy-Tillstånd begära rubrik.
Digest Authentication liknar Basic och använder samma handskakningsteknik med WWW-Authenticate och Tillstånd rubriker, men Digest använder en säkrare hashing-funktion för att kryptera användarnamnet och lösenordet (vanligtvis med MD5 eller KD-digestfunktioner). Även om Digest Authentication ska vara säkrare än Basic använder webbplatser vanligtvis Basic Authentication på grund av dess enkelhet. För att mildra säkerhetsproblemen används Basic Auth i samband med SSL.
HTTPS-protokollet ger en säker anslutning på webben. Det enklaste sättet att veta om du använder HTTPS är att kontrollera webbläsarens adressfält. HTTPs säkra komponent innebär att infoga ett lager av kryptering / dekryptering mellan HTTP och TCP. Det här är Secure Sockets Layer (SSL) eller den förbättrade transportlagssäkerheten (TLS).
SSL använder en kraftfull form av kryptering med hjälp av RSA och public key-kryptering. Eftersom säkra transaktioner är så viktiga på webben har en allmänt förekommande standardbaserad Public Key Key Infrastructure (PKI) ansträngning pågått ganska länge.
Befintliga kunder / servrar behöver inte ändra hur de hanterar meddelanden eftersom det mesta av det hårda arbetet händer i SSL-lagret. Således kan du utveckla din webbapplikation med Basic Authentication och skörda automatiskt fördelarna med SSL genom att växla till https: // protokoll. Men för att få webbapplikationen att fungera över HTTPS måste du ha ett fungerande digitalt certifikat som används på servern.
Precis som du behöver ID-kort för att visa din identitet behöver en webbserver ett digitalt certifikat för att identifiera sig själv. Certifikat (eller "certs") utfärdas av en certifikatmyndighet (CA) och garanterar din identitet på webben. CA: erna är väktare till PKI. Den vanligaste formen av certifikat är X.509 v3-standarden, som innehåller information, till exempel:
När en klient gör en begäran via HTTPS försöker den först att hitta ett certifikat på servern. Om certifikatet hittas försöker det verifiera det mot sin kända lista över certifierade myndigheter. Om det inte är en av de angivna CA: erna, kan det visa en dialogruta för användarens varning om webbplatsens certficate.
När certifikatet är verifierat är SSL-handslaget fullständigt och säker överföring är i kraft.
Det är allmänt överens om att göra samma arbete två gånger är slösigt. Detta är vägledande för begreppet HTTP-caching, en grundläggande pelare för HTTP-nätverksinfrastrukturen. Eftersom de flesta operationerna är över ett nätverk, hjälper en cache till att spara tid, kostnad och bandbredd, samt ge en förbättrad upplevelse på webben.
Cacher används på flera ställen i nätverksinfrastrukturen, från webbläsaren till ursprungsservern. Beroende på var den ligger kan en cache kategoriseras som:
Oavsett var en cache finns är processen för att behålla en cache ganska lik:
Självklart är servern ansvarig för att alltid svara med rätt rubriker och svar. Om ett dokument inte har ändrats, ska servern svara med en 304 Ej modifierad. Om den cachade kopian har gått ut bör den generera ett nytt svar med uppdaterade svarhuvud och returnera med en 200 OK. Om resursen raderas bör den komma tillbaka med 404 Ej Hittad. Dessa svar hjälper till att ställa in cacheminnet och se till att det gamla innehållet inte hålls för länge.
Parallella anslutningar, i kombination med ihållande anslutningar, är dagens svar för att minimera nätverksförseningar.
Nu när vi har en känsla av hur en cache fungerar, är det dags att titta på begäran och svarhuvudet som aktiverar cachningsinfrastrukturen. Att hålla innehållet fräscht och aktuellt är ett av de främsta ansvaren för cacheminnet. För att hålla den cachade kopian i enlighet med servern, ger HTTP några enkla mekanismer, nämligen Dokumentets utgång och Server Revalidation.
HTTP tillåter en ursprungsserver att bifoga en utgångsdatum till varje dokument med hjälp av Cache-Control och Utgår svar rubriker. Detta hjälper klienten och andra cacheservrar att veta hur länge ett dokument är giltigt och friskt. Cacheminnet kan servera kopian så länge som ålder av dokumentet är inom förfallodagen. När ett dokument har löpt ut måste cachen kontrollera med servern för en nyare kopia och uppdatera dess lokala kopia i enlighet med detta.
Utgår är en äldre HTTP / 1.0-responsrubrik som anger värdet som ett absolut datum. Detta är bara användbart om serverns klockor synkroniseras med klienten, vilket är ett hemskt antagande att göra. Den här rubriken är mindre användbar jämfört med den nyare Cache-Control: max-age = rubrik introducerad i HTTP / 1.1. Här, max-ålder är en relativ ålder, specificerad i sekunder, från det att svaret skapades. Således om ett dokument skulle upphöra efter en dag, bör expirationsrubriken vara Cache-Control: max-age = 86400.
När ett cachelagrat dokument har löpt ut måste cachen uppdateras med servern för att kontrollera om dokumentet har ändrats. Det här kallas server förnyelse och fungerar som en frågemekanism för inaktuella-ness av ett dokument. Bara för att en cachad kopia har löpt ut betyder inte att servern faktiskt har nyare innehåll. Förnyelse är bara ett sätt att se till att cacheminnet blir friskt. På grund av utgångstiden (som anges i ett tidigare serverns svar) behöver cachen inte kontrollera med servern för varje enskild begäran, vilket sparar bandbredd, tid och sänker nätverkstrafiken.
Kombinationen av expiration av dokument och serverförnyelse är en mycket effektiv mekanism, det gör det möjligt för distribuerade system att behålla kopior med ett utgångsdatum.
Om innehållet är känt att det ofta ändras kan utloppstiden minskas, vilket gör det möjligt för systemen att synkronisera oftare.
Förhöjningstrinnet kan åstadkommas med två typer av begäranhuvuden: If-Modified-Since och Om-None-Match. Den tidigare är för datumbaserad validering medan den senare använder Entity-Tags (ETags), en hash av innehållet. Dessa rubriker använder datum eller ETag-värden som erhållits från ett tidigare serverns svar. I fall att If-Modified-Since, de Senast ändrad svarhuvud används för Om-None-Match, det är ETag svarhuvud.
Giltighetsperioden för ett dokument ska definieras av servern som genererar dokumentet. Om det är en tidningswebbplats bör hemsidan gå ut efter en dag (eller ibland även varje timme!). HTTP tillhandahåller Cache-Control och Utgår svarhuvud för att ange utgången på dokument. Som tidigare nämnts, Utgår baseras på absoluta datum och inte en tillförlitlig lösning för kontroll av cacheminnet.
De Cache-Control rubrik är mycket mer användbar och har några olika värden för att begränsa hur klienter ska cacha svaret:
Som en sida, om servern inte skickar någon Cache-Control rubriker är klienten fri att använda sin egen heuristiska utgångsalgoritm för att bestämma friskhet.
Cachability är inte bara begränsad till servern. Det kan också anges från klienten. Detta gör att klienten kan införa begränsningar på vad det är villigt att acceptera. Detta är möjligt via samma Cache-Control header, om än med några olika värden:
HTTP-caching är faktiskt ett mycket intressant ämne, och det finns några mycket sofistikerade algoritmer för att hantera cachad innehåll. För en djupare titt på detta ämne, se avsnittet Caching i HTTP-specifikationen.
Vår tur på HTTP började med grunden för URL-scheman, statuskoder och begäran / svarhuvud. På grundval av dessa begrepp tittade vi på några av de finare områdena av HTTP, såsom anslutningshantering, identifiering och autentisering och caching. Jag hoppas att denna turné har gett dig en bra smak för HTTPs bredd och tillräckligt med tips för att ytterligare utforska detta protokoll.
