Pysyvä HTTP -yhteys - HTTP persistent connection
HTTP |
---|
Pyydä menetelmiä |
Otsikkokentät |
Vastauksen tilakoodit |
Pääsyn suojausmenetelmät |
Suojaushaavoittuvuudet |
HTTP pysyvä yhteys , jota kutsutaan myös HTTP-prosessit , tai HTTP-yhteyttä uudelleenkäyttö , on ajatus käyttää yhden TCP- yhteyden lähettää ja vastaanottaa useita HTTP pyyntöjä / vastauksia, eikä uuden yhteyden avaamiseksi jokaisesta pyyntö / vastaus pari. Uudempi HTTP/2 -protokolla käyttää samaa ajatusta ja vie sen pidemmälle, jotta useat samanaikaiset pyynnöt/vastaukset voidaan multipleksoida yhdellä yhteydellä.
Operaatio
HTTP 1.0
HTTP 1.0 : ssa palvelimen tulee aina sulkea yhteydet vastauksen lähettämisen jälkeen.
Vuoden 1996 lopusta lähtien suosittujen tuotteiden (selaimet, verkkopalvelimet jne.) Kehittäjät HTTP/1.0: n avulla ovat alkaneet lisätä epävirallista laajennusta (protokollaan) nimeltä "pidä hengissä", jotta yhteys voidaan käyttää uudelleen useille pyyntöjä/vastauksia.
Jos asiakas tukee ylläpitoa, se lisää pyyntöön ylätunnisteen:
Connection: keep-alive
Kun palvelin vastaanottaa tämän pyynnön ja luo vastauksen, jos se tukee pysyvää ylläpitoa, se myös lisää saman yläotsikon vastaukseen. Tämän jälkeen yhteyttä ei katkaista, vaan se pidetään auki. Kun asiakas lähettää toisen pyynnön, se käyttää samaa yhteyttä.
Tämä jatkuu, kunnes joko asiakas tai palvelin päättää, että keskustelu on päättynyt, ja tässä tapauksessa he jättävät "Connection:"
otsikon pois viimeksi lähetetystä viestistä tai, mikä parasta, he lisäävät siihen avainsanan "lähellä":
Connection: close
Tämän jälkeen yhteys suljetaan tiettyjen sääntöjen mukaisesti.
Vuodesta 1997 lähtien HTTP/1.1-määritysten eri versiot ovat tiedostaneet tämän epävirallisen laajennuksen käytön ja sisälsivät muutamia varoituksia HTTP/1.0: n (pysy hengissä) ja HTTP/1.1-asiakkaiden/palvelimien välisestä yhteentoimivuudesta.
HTTP 1.1
HTTP 1.1: ssä kaikkia yhteyksiä pidetään jatkuvina, ellei toisin ilmoiteta. Pysyvät HTTP -yhteydet eivät käytä erillisiä säilytysviestejä, vaan sallivat vain useiden pyyntöjen käyttää yhtä yhteyttä. Apache httpd 1.3: n ja 2.0: n oletusyhteyden aikakatkaisu on kuitenkin vain 15 sekuntia ja vain 5 sekuntia Apache httpd 2.2: ssa ja uudemmissa. Lyhyen aikakatkaisun etuna on kyky toimittaa useita verkkosivun osia nopeasti samalla, kun se ei kuluta resursseja useiden palvelinprosessien tai säikeiden suorittamiseen liian kauan.
Pysy aktiivisena paloitellulla siirtokoodauksella
Keepalive tekee asiakkaan vaikeaksi määrittää, missä yksi vastaus päättyy ja seuraava vastaus alkaa, etenkin liitetyn HTTP -toiminnan aikana. Tämä on vakava ongelma, kun Content-Length
sitä ei voi käyttää suoratoiston vuoksi. Tämän ongelman ratkaisemiseksi HTTP 1.1 esitteli palasetun siirtokoodauksen, joka määrittelee last-chunk
bitin. last-chunk
Bitti on asetettu jokaisen vastauksen, niin että asiakas tietää, missä seuraava reaktio alkaa.
Edut
- Pienempi viive myöhemmissä pyynnöissä (ei kättelyä ).
- Vähentynyt suorittimen käyttö ja edestakaiset lennot, koska uusia yhteyksiä ja TLS-kättelyjä on vähemmän .
- Mahdollistaa pyyntöjen ja vastausten HTTP -yhdistämisen .
- Vähentynyt verkon ruuhkautuminen (vähemmän TCP -yhteyksiä ).
- Virheistä voidaan ilmoittaa ilman sakkoa TCP -yhteyden sulkemisesta.
Mukaan RFC 7230, osa 6.4 , "asiakkaan pitäisi rajoittaa samanaikaisten avointen yhteyksien että se säilyttää tietyn palvelin". HTTP/1.1 -määrityksen edellinen versio sisälsi tietyt enimmäisarvot, mutta RFC 7230: n sanoin "tämän havaittiin olevan epäkäytännöllinen monille sovelluksille ... sen sijaan ... ole varovainen avattaessa useita yhteyksiä". Näiden ohjeiden tarkoituksena on parantaa HTTP -vasteaikoja ja välttää ruuhkia. Jos HTTP -prosessointi on toteutettu oikein, lisäyhteyksistä ei ole hyötyä suorituskyvystä, kun taas lisäyhteydet voivat aiheuttaa ongelmia ruuhkissa.
Haitat
Jos asiakas ei sulje yhteyttä, kun kaikki tarvitsemasi tiedot on vastaanotettu, resurssit, jotka tarvitaan yhteyden pitämiseksi auki palvelimella, eivät ole käytettävissä muille asiakkaille. Se, kuinka paljon tämä vaikuttaa palvelimen käytettävyyteen ja kuinka kauan resurssit eivät ole käytettävissä, riippuu palvelimen arkkitehtuurista ja kokoonpanosta.
Myös kilpailutilanne voi ilmetä, kun asiakas lähettää pyynnön palvelimelle samanaikaisesti, kun palvelin sulkee TCP -yhteyden. Palvelimen tulee lähettää 408 -pyynnön aikakatkaisun tilakoodi asiakkaalle juuri ennen yhteyden sulkemista. Kun asiakas vastaanottaa 408-tilakoodin pyynnön lähettämisen jälkeen, se voi avata uuden yhteyden palvelimelle ja lähettää pyynnön uudelleen. Kaikki asiakkaat eivät lähetä pyyntöä uudelleen, ja monet lähettävät sen vain, jos pyynnössä on idempotentti HTTP-menetelmä .
Käytä selaimissa
Kaikki nykyaikaiset verkkoselaimet, mukaan lukien Google Chrome , Firefox , Internet Explorer (alkaen 4.01), Opera (vuodesta 4.0) ja Safari, käyttävät pysyviä yhteyksiä.
Internet Explorerin versiot 6 ja 7 käyttävät oletuksena kahta pysyvää yhteyttä, kun taas versio 8 käyttää kuutta. Pysyvät yhteydet aikakatkaistaan 60 sekunnin käyttämättömyyden jälkeen, mikä voidaan muuttaa Windowsin rekisterin kautta.
In Firefox , samanaikaisten yhteyksien voidaan räätälöidä (per-palvelin, per-proxy, yhteensä). Jatkuvien yhteyksien aikakatkaisu 115 sekunnin (1,92 minuutin) käyttämättömyyden jälkeen, joka voidaan muuttaa kokoonpanon avulla.
Katso myös
- HTTP -pipelining , jolloin useita pyyntöjä voidaan lähettää odottamatta vastausta
- HTTP/2 , jonka avulla pyynnöt ja vastaukset voidaan järjestää epäjärjestyksessä ja myös sisällön ennakoiva siirtäminen ennen sen pyytämistä