Állandó HTTP kapcsolat - HTTP persistent connection

A HTTP állandó kapcsolat , más néven HTTP-életben tartás , vagy HTTP-kapcsolat újrafelhasználása , az az ötlet, hogy egyetlen TCP- kapcsolatothasználjontöbb HTTP-kérés / -válasz küldésére és fogadására, szemben azzal, hogy minden egyes kérés /válaszpárhoz új kapcsolatot nyitnak. Az újabb HTTP/2 protokoll ugyanazt az ötletet használja, és továbbviszi, hogy több egyidejű kérést/választ multiplexelhessen egyetlen kapcsolaton keresztül.

Művelet

HTTP 1.0

A HTTP 1.0 alatt a kapcsolatokat a szervernek mindig le kell zárnia a válasz elküldése után.

1996 vége óta a népszerű termékek (böngészők, webszerverek stb.) Fejlesztői a HTTP/1.0 protokollt használva nem hivatalos kiterjesztést (a protokollhoz) adtak hozzá a „keep-élet” elnevezéssel annak érdekében, hogy lehetővé tegyék a kapcsolat többféle használatát kérések/válaszok.

Ha az ügyfél támogatja az életben maradást, akkor egy további fejlécet ad hozzá a kéréshez:

Connection: keep-alive

Amikor a szerver megkapja ezt a kérést, és választ generál, ha támogatja az életben maradást, akkor ugyanazt a fenti fejlécet is hozzáadja a válaszhoz. Ezt követően a kapcsolat nem szakad meg, hanem nyitva marad. Amikor az ügyfél újabb kérést küld, ugyanazt a kapcsolatot használja.

Ez addig folytatódik, amíg az ügyfél vagy a szerver úgy dönt, hogy a beszélgetés véget ért, és ebben az esetben kihagyják a "Connection:"fejlécet az utolsó elküldött üzenetből, vagy jobb esetben hozzáadják a "közel" kulcsszót:

Connection: close

Ezt követően a kapcsolat megszűnik a meghatározott szabályok szerint.

1997 óta a HTTP/1.1 specifikációk különböző változatai ismerték ennek a nem hivatalos kiterjesztésnek a használatát, és tartalmaztak néhány óvintézkedést a HTTP/1.0 (életben maradás) és a HTTP/1.1 kliensek/kiszolgálók közötti együttműködéssel kapcsolatban.

HTTP 1.1

A HTTP 1.1 -ben minden kapcsolat tartósnak minősül, hacsak másképp nem jelezzük. A HTTP állandó kapcsolatok nem használnak külön Keepalive üzeneteket, csak lehetővé teszik több kérés egyetlen kapcsolat használatát. Az Apache httpd 1.3 és 2.0 alapértelmezett csatlakozási időtúllépése azonban mindössze 15 másodperc, az Apache httpd 2.2 és újabb verziói esetén pedig mindössze 5 másodperc. A rövid időtúllépés előnye, hogy képes egy weboldal több összetevőjének gyors szállítására, miközben nem igényel erőforrásokat több szerverfolyamat vagy szál túl hosszú ideig történő futtatásához.

Tartsa életben a darabolt átviteli kódolást

A Keepalive megnehezíti az ügyfél számára annak meghatározását, hogy hol végződik az egyik válasz, és hol kezdődik a következő válasz, különösen a folyamatban lévő HTTP -művelet során. Ez komoly probléma, ha Content-Lengtha streamelés miatt nem használható. A probléma megoldásához a HTTP 1.1 bevezetett egy darabos átviteli kódolást, amely egy last-chunkkicsit definiál . A last-chunkbit minden válasz végén úgy van beállítva, hogy az ügyfél tudja, hol kezdődik a következő válasz.

Előnyök

Csökkentett késleltetés a későbbi kérelmekben (nincs kézfogás ).
Csökkent CPU- használat és oda-vissza út a kevesebb új kapcsolat és a TLS kézfogás miatt .
Lehetővé teszi a kérések és válaszok HTTP -folyamatát .
Csökkentett hálózati torlódás (kevesebb TCP -kapcsolat ).
A hibák a TCP -kapcsolat lezárásának büntetése nélkül is jelenthetők.

Az RFC 7230 6.4. Szakasza szerint "az ügyfélnek korlátoznia kell az egyidejűleg megnyitott kapcsolatok számát, amelyeket egy adott szerverhez tart fenn". A HTTP/1.1 specifikáció előző verziója meghatározott maximális értékeket határozott meg, de az RFC 7230 szavaival élve "ez sok alkalmazásnál nem volt praktikus, hanem ... konzervatív több kapcsolat megnyitásakor". Ezek az irányelvek célja a HTTP válaszidők javítása és a torlódások elkerülése. Ha a HTTP csővezetés helyesen van megvalósítva, akkor a további kapcsolatok nem járnak előnyökkel a teljesítményhez, míg a további kapcsolatok problémákat okozhatnak a torlódásban.

Hátrányok

Ha az ügyfél nem zárja le a kapcsolatot, amikor az összes szükséges adat megérkezett, a kapcsolat nyitva tartásához szükséges erőforrások a kiszolgálón más ügyfelek számára nem érhetők el. Az, hogy ez mennyire befolyásolja a szerver elérhetőségét, és mennyi ideig nem állnak rendelkezésre az erőforrások, a szerver architektúrájától és konfigurációjától függ.

Szintén a versenyhelyzet is előfordulhat, ha a kliens küld egy kérést a szerver ugyanakkor, hogy a szerver lezárja a TCP kapcsolatot. A kiszolgálónak közvetlenül a kapcsolat lezárása előtt el kell küldenie a kliensnek a 408 kérés időtúllépési állapotkódját. Amikor az ügyfél megkapja a 408 állapotkódot, a kérelem elküldése után új kapcsolatot nyithat a szerverrel, és újra elküldi a kérést. Nem minden ügyfél küldi el újra a kérelmet, és sokan csak akkor teszik ezt, ha a kérés idempotens HTTP metódussal rendelkezik .

Használja webböngészőkben

A többszörös és a tartós kapcsolat sémája.

Minden modern webböngésző, köztük a Google Chrome , a Firefox , az Internet Explorer (4.01 -től), az Opera (4.0 -tól) és a Safari állandó kapcsolatot használ.

Alapértelmezés szerint az Internet Explorer 6. és 7. verziója két állandó kapcsolatot használ, míg a 8. verzió hatot. A tartós kapcsolatok időtúllépése 60 másodperc tétlenség után történik, amely a Windows rendszerleíró adatbázisán keresztül módosítható.

A Firefoxban az egyidejű kapcsolatok száma testreszabható (kiszolgálónként, proxyként, összesen). A tartós kapcsolatok időtúllépése 115 másodperc (1,92 perc) inaktivitás után történik, amely a konfiguráción keresztül módosítható.

Lásd még

HTTP csővezeték , amelynek során több kérés is elküldhető a válasz megvárása nélkül
HTTP/2 , amely lehetővé teszi a kérések és válaszok soron kívüli feldolgozását, valamint a tartalom prediktív leküldését , mielőtt azt kérték

Languages

In other projects