Ihållande HTTP -anslutning - HTTP persistent connection

HTTP
Begär metoder
Rubrikfält
Svarsstatuskoder
Säkerhetsåtkomstkontrollmetoder
Säkerhetsproblem

Ihållande HTTP- anslutning , även kallad HTTP keep-alive , eller återanvändning av HTTP-anslutning , är tanken på att använda en enda TCP- anslutning för att skicka och ta emot flera HTTP-förfrågningar /svar, i motsats till att öppna en ny anslutning för varje enskilt begäran /svarspar. Det nyare HTTP/2 -protokollet använder samma idé och tar det vidare för att tillåta multipla samtidiga begäranden/svar att multiplexeras över en enda anslutning.

Drift

HTTP 1.0

Under HTTP 1.0 ska anslutningar alltid stängas av servern efter att svaret har skickats.

Sedan slutet av 1996 har utvecklare av populära produkter (webbläsare, webbservrar, etc.) med HTTP/1.0 börjat lägga till ett inofficiellt tillägg (till protokollet) med namnet "keep-alive" för att möjliggöra återanvändning av en anslutning för flera förfrågningar/svar.

Om klienten stöder att hålla sig vid liv, lägger den till en extra rubrik till begäran: 

Connection: keep-alive

När servern tar emot denna begäran och genererar ett svar, om den stöder keep-alive så lägger den också till samma rubrik ovan till svaret. Efter detta tappas inte anslutningen utan hålls istället öppen. När klienten skickar en annan begäran använder den samma anslutning.

Detta kommer att fortsätta tills antingen klienten eller servern bestämmer att konversationen är över och i det här fallet utelämnar de "Connection:"rubriken från det senaste meddelandet som skickades eller, bättre, de lägger till sökordet "nära" till det: 

Connection: close

Därefter stängs anslutningen enligt angivna regler.

Sedan 1997 har de olika versionerna av HTTP/1.1-specifikationerna känt till användningen av denna inofficiella tillägg och inkluderat några varningar om interoperabilitet mellan HTTP/1.0 (keep-alive) och HTTP/1.1-klienter/servrar.

HTTP 1.1

I HTTP 1.1 anses alla anslutningar vara bestående om inte annat anges. De persistenta HTTP -anslutningarna använder inte separata keepalive -meddelanden, de tillåter bara att flera förfrågningar använder en enda anslutning. Standardanslutningstiden för Apache httpd 1.3 och 2.0 är dock så lite som 15 sekunder och bara 5 sekunder för Apache httpd 2.2 och senare. Fördelen med en kort timeout är möjligheten att snabbt leverera flera komponenter på en webbsida utan att behöva använda resurser för att köra flera serverprocesser eller trådar för länge.

Keepalive med delad överföringskodning

Keepalive gör det svårt för klienten att avgöra var ett svar slutar och nästa svar börjar, särskilt under pipeline HTTP -drift. Detta är ett allvarligt problem när det Content-Lengthinte kan användas på grund av streaming. För att lösa detta problem introducerade HTTP 1.1 en delad överföringskodning som definierar last-chunklite. Den last-chunkbit är satt till slutet av varje svar så att kunden vet var nästa svar börjar.

Fördelar

Enligt RFC 7230, avsnitt 6.4 , "bör en klient begränsa antalet samtidiga öppna anslutningar som den underhåller till en given server". Den tidigare versionen av HTTP/1.1 -specifikationen angav specifika maximivärden men i orden i RFC 7230 "visade det sig vara opraktiskt för många applikationer ... istället ... var försiktig när du öppnar flera anslutningar". Dessa riktlinjer är avsedda att förbättra HTTP -svarstider och undvika överbelastning. Om HTTP -pipelining är korrekt implementerad finns det ingen prestandafördel att hämta från ytterligare anslutningar, medan ytterligare anslutningar kan orsaka problem med överbelastning.

Nackdelar

Om klienten inte stänger anslutningen när all data den behöver har tagits emot är resurserna som behövs för att hålla anslutningen öppen på servern inte tillgängliga för andra klienter. Hur mycket detta påverkar serverns tillgänglighet och hur länge resurserna är otillgängliga beror på serverns arkitektur och konfiguration.

Ett tävlingsvillkor kan också uppstå där klienten skickar en begäran till servern samtidigt som servern stänger TCP -anslutningen. En server ska skicka en 408 Request Timeout -statuskod till klienten omedelbart innan anslutningen stängs. När en klient mottar 408-statuskoden, efter att ha skickat begäran, kan den öppna en ny anslutning till servern och skicka förfrågan igen. Inte alla klienter kommer att skicka förfrågan igen, och många som gör det kommer bara att göra det om begäran har en idempotent HTTP-metod .

Använd i webbläsare

Schema för flera kontra ihållande anslutning.

Alla moderna webbläsare inklusive Google Chrome , Firefox , Internet Explorer (sedan 4.01), Opera (sedan 4.0) och Safari använder ihållande anslutningar.

Som standard använder Internet Explorer version 6 och 7 två beständiga anslutningar medan version 8 använder sex. Ihållande anslutningar timeout efter 60 sekunder av inaktivitet som kan ändras via Windows -registret.

I Firefox kan antalet samtidiga anslutningar anpassas (per server, per proxy, totalt). Ihållande anslutningar timeout efter 115 sekunder (1,92 minuter) av inaktivitet som kan ändras via konfigurationen.

Se även

  • HTTP -pipelining , där flera förfrågningar kan skickas utan att vänta på svar
  • HTTP/2 , som möjliggör urkoppling av pipeline av förfrågningar och svar, och även prediktiv pushing av innehåll innan det har begärts

Referenser

externa länkar