Vedvarende HTTP -tilkobling - HTTP persistent connection
| HTTP |
|---|
| Be om metoder |
| Overskriftsfelt |
| Responsstatuskoder |
| Sikkerhetskontrollmetoder |
| Sikkerhetsproblemer |
Vedvarende HTTP- tilkobling , også kalt HTTP keep-alive , eller gjenbruk av HTTP-tilkobling , er tanken på å bruke en enkelt TCP- tilkobling til å sende og motta flere HTTP-forespørsler /svar, i motsetning til å åpne en ny tilkobling for hvert enkelt forespørsel /svarpar. Den nyere HTTP/2 -protokollen bruker den samme ideen og tar den videre for å tillate flere samtidige forespørsler/svar å bli multiplekset over en enkelt tilkobling.
Operasjon
HTTP 1.0
Under HTTP 1.0 skal tilkoblinger alltid stenges av serveren etter at svaret er sendt.
Siden slutten av 1996 begynte utviklere av populære produkter (nettlesere, webservere, etc.) som bruker HTTP/1.0, å legge til en uoffisiell utvidelse (til protokollen) med navnet "keep-alive" for å tillate gjenbruk av en tilkobling for flere forespørsler/svar.
Hvis klienten støtter keep-alive, legger den til en ekstra overskrift til forespørselen:
Connection: keep-alive
Når serveren mottar denne forespørselen og genererer et svar, hvis den støtter keep-alive, legger den også til den samme overskriften ovenfor i svaret. Etter dette blir forbindelsen ikke brutt, men den holdes i stedet åpen. Når klienten sender en annen forespørsel, bruker den samme tilkobling.
Dette vil fortsette til enten klienten eller serveren bestemmer seg for at samtalen er over, og i dette tilfellet utelater de "Connection:"overskriften fra den siste meldingen som ble sendt, eller, bedre, de legger til søkeordet "close":
Connection: close
Etter det blir forbindelsen stengt etter spesifiserte regler.
Siden 1997 har de forskjellige versjonene av HTTP/1.1-spesifikasjonene kjent bruken av denne uoffisielle utvidelsen og inkluderte noen forbehold om interoperabilitet mellom HTTP/1.0 (keep-alive) og HTTP/1.1-klienter/servere.
HTTP 1.1
I HTTP 1.1 regnes alle tilkoblinger som vedvarende med mindre annet er erklært. De vedvarende HTTP -tilkoblingene bruker ikke separate keepalive -meldinger, de lar bare flere forespørsler bruke en enkelt tilkobling. Standard timeout for tilkobling for Apache httpd 1.3 og 2.0 er imidlertid så lite som 15 sekunder og bare 5 sekunder for Apache httpd 2.2 og nyere. Fordelen med en kort timeout er muligheten til å levere flere komponenter på en webside raskt, samtidig som det ikke bruker ressurser for å kjøre flere serverprosesser eller tråder for lenge.
Keepalive med delte overføringskoder
Keepalive gjør det vanskelig for klienten å avgjøre hvor det ene svaret slutter og det neste svaret begynner, spesielt under pipeline HTTP -drift. Dette er et alvorlig problem når det Content-Lengthikke kan brukes på grunn av streaming. For å løse dette problemet introduserte HTTP 1.1 en delaktig overføringskoding som definerer last-chunklitt. Den last-chunkbiten er satt til slutten av hvert svar, slik at kunden vet hvor neste reaksjon begynner.
Fordeler
- Redusert ventetid i påfølgende forespørsler (ingen håndtrykk ).
- Redusert CPU- bruk og rundturer på grunn av færre nye tilkoblinger og TLS-håndtrykk .
- Aktiverer HTTP -pipelining av forespørsler og svar.
- Redusert nettstopp (færre TCP -tilkoblinger ).
- Feil kan rapporteres uten straff for å lukke TCP -tilkoblingen.
I følge RFC 7230, avsnitt 6.4 , "bør en klient begrense antallet samtidige åpne tilkoblinger som den opprettholder til en gitt server". Den forrige versjonen av HTTP/1.1 -spesifikasjonen angav spesifikke maksimumsverdier, men med ordene til RFC 7230 "ble dette funnet upraktisk for mange applikasjoner ... i stedet ... vær konservativ når du åpner flere tilkoblinger". Disse retningslinjene er ment å forbedre HTTP -responstider og unngå overbelastning. Hvis HTTP -rørledning er korrekt implementert, er det ingen ytelsesfordel å hente fra flere tilkoblinger, mens flere tilkoblinger kan forårsake problemer med overbelastning.
Ulemper
Hvis klienten ikke stenger tilkoblingen når alle dataene den trenger er mottatt, vil ressursene som trengs for å holde forbindelsen åpen på serveren være utilgjengelige for andre klienter. Hvor mye dette påvirker serverens tilgjengelighet og hvor lenge ressursene er utilgjengelige, avhenger av serverens arkitektur og konfigurasjon.
Også en rase tilstand kan oppstå hvor klienten sender en forespørsel til serveren samtidig at serveren lukker TCP forbindelsen. En server bør sende en 408 Request Timeout -statuskode til klienten umiddelbart før tilkoblingen stenges. Når en klient mottar 408-statuskoden, etter at den har sendt forespørselen, kan den åpne en ny tilkobling til serveren og sende forespørselen på nytt. Ikke alle klienter sender forespørselen på nytt, og mange som gjør det, vil bare gjøre det hvis forespørselen har en idempotent HTTP-metode .
Bruk i nettlesere
Alle moderne nettlesere inkludert Google Chrome , Firefox , Internet Explorer (siden 4.01), Opera (siden 4.0) og Safari bruker vedvarende tilkoblinger.
Som standard bruker Internet Explorer versjon 6 og 7 to vedvarende tilkoblinger mens versjon 8 bruker seks. Vedvarende tilkoblinger timeout etter 60 sekunders inaktivitet som kan endres via Windows -registret.
I Firefox kan antall samtidige tilkoblinger tilpasses (per server, per proxy, totalt). Vedvarende tilkoblinger timeout etter 115 sekunder (1,92 minutter) av inaktivitet som kan endres via konfigurasjonen.
Se også
- HTTP -rørledning , der flere forespørsler kan sendes uten å vente på svar
- HTTP/2 , som tillater utrangerte pipelining av forespørsler og svar, og også prediktiv skyving av innhold før det har blitt forespurt