A lecke végére el tudod magyarázni, miért nem tud a szerver magától szólni a HTTP-ben, mi a polling, és hogyan hat a lekérdezési periódus a késleltetésre és a terhelésre.
Miért kell?
Az RFC 6202 megfogalmazásában a szabványos HTTP-modellben a szerver nem kezdeményezhet kapcsolatot a klienssel és nem küldhet kéretlen választ; ezért ha a kliens az eseményekről minél előbb értesülni akar, rendszeresen lekérdezi a szervert. A felület elavul, ha ezt nem tesszük; a kérdés az, milyen költséggel.
Mi a polling?
A polling (más néven short polling) az RFC 6202 szerint azt jelenti, hogy a kliens kéréseket küld a szervernek, és a válasz után egy ideig vár, mielőtt újabb lekérdezést küld. Az új adat észlelése csak a következő lekérdezéskor történik meg.
sequenceDiagram
participant K as Kliens
participant S as Szerver
K->>S: Van újdonság?
S-->>K: Nincs
Note over K: várakozás egy periódusig
K->>S: Van újdonság?
S-->>K: Van: adat
Késleltetés és terhelés
Ha a változás időpontja egyenletesen oszlik el a periódusban, az észlelés átlagosan körülbelül a periódus felét késik, a legrosszabb esetben egy teljes periódust, plusz a kérés idejét. A terhelés a kliensek számának és a lekérdezési gyakoriságnak a szorzata: N kliens T másodpercenkénti lekérdezésnél N/T kérést jelent másodpercenként, akkor is, ha semmi sem változik (szemléltető számítás: tízezer kliens, ötmásodperces periódus → másodpercenként kétezer kérés, átlagosan 2,5 másodperc késés). Az RFC 6202 is megjegyzi, hogy az állandó lekérdezés jelentős sávszélességet fogyaszthat, ha nincs új adat, és hogy az adat addig várakozik, amíg a szerver megkapja a következő lekérdezést.
Csökkenthető a költség feltételes kéréssel (7.2: If-None-Match, 304) és gyorsítótárral, de a kérés kezelésének költsége megmarad. A kliensek indításának véletlenszerű eltolása (jitter) elkerüli, hogy minden kliens ugyanabban a pillanatban kérdezzen.
Adaptív polling
Egy várakozó feladatnál a periódus változhat: kezdetben rövid, később hosszabb, végleges állapotnál megáll. A szerver javasolhat következő ellenőrzési időt. A kliens ne indítson új kérést, ha az előző még fut; lassú hálózaton különben egyre több párhuzamos lekérés halmozódik fel. A „nincs változás” és a „nem sikerült lekérni” külön állapot, és hálózati hiba után érdemes ritkítani a próbálkozást (6.5); végleges jogosultsági hibánál nem szabad korlátlanul folytatni.
Jellemzők
Szempont
Polling
Irány
A kliens kérdez, a szerver válaszol
Kezdeményező
A kliens
Kapcsolat tartóssága
Kérésenként új (vagy újrahasznosított)
Késleltetés
Átlagosan a periódus fele, legfeljebb egy periódus
Terhelés
Állandó, a változástól függetlenül (N/T)
Hibatűrés
Egyszerű: nincs tartós állapot, a kihagyott lekérdezést a következő pótolja
Mikor jó?
Ritkán változó adat, néhány másodperc késés elfogadható, egyszerű infrastruktúra
Mikor nem?
Sűrűn változó adat, sok kliens, azonnali értesítés igénye
Gyakori tévhitek
Állítás
Pontosítás
„A polling elavult.”
Ritkán változó adatnál egyszerű és megfelelő.
„Gyakoribb polling = valós idejű.”
A késleltetés a periódussal arányos, a terhelés is nő.
„A polling nem terheli a szervert, ha nincs változás.”
A kérések kezelése akkor is költség.
„Nincs változás = hiba.”
A két állapot külön kezelendő.
Röviden
A HTTP-ben a szerver nem küldhet kéretlen választ; a kliensnek kell kérdeznie.
A polling késleltetése a periódussal arányos, terhelése N/T.
Adaptív periódus és jitter csökkenti a költséget.
Ritka változásra és egyszerű infrastruktúrára jó.
Ellenőrző kérdések
Mennyi az átlagos késleltetés T másodperces periódusnál?
Hogyan számolható egy pollingot használó rendszer kérésterhelése?
Miért külön állapot a „nincs változás” és a „nem sikerült lekérni”?
A frissesség problémája és a polling
Célok
A lecke végére el tudod magyarázni, miért nem tud a szerver magától szólni a HTTP-ben, mi a polling, és hogyan hat a lekérdezési periódus a késleltetésre és a terhelésre.
Miért kell?
Az RFC 6202 megfogalmazásában a szabványos HTTP-modellben a szerver nem kezdeményezhet kapcsolatot a klienssel és nem küldhet kéretlen választ; ezért ha a kliens az eseményekről minél előbb értesülni akar, rendszeresen lekérdezi a szervert. A felület elavul, ha ezt nem tesszük; a kérdés az, milyen költséggel.
Mi a polling?
A polling (más néven short polling) az RFC 6202 szerint azt jelenti, hogy a kliens kéréseket küld a szervernek, és a válasz után egy ideig vár, mielőtt újabb lekérdezést küld. Az új adat észlelése csak a következő lekérdezéskor történik meg.
Késleltetés és terhelés
Ha a változás időpontja egyenletesen oszlik el a periódusban, az észlelés átlagosan körülbelül a periódus felét késik, a legrosszabb esetben egy teljes periódust, plusz a kérés idejét. A terhelés a kliensek számának és a lekérdezési gyakoriságnak a szorzata: N kliens T másodpercenkénti lekérdezésnél N/T kérést jelent másodpercenként, akkor is, ha semmi sem változik (szemléltető számítás: tízezer kliens, ötmásodperces periódus → másodpercenként kétezer kérés, átlagosan 2,5 másodperc késés). Az RFC 6202 is megjegyzi, hogy az állandó lekérdezés jelentős sávszélességet fogyaszthat, ha nincs új adat, és hogy az adat addig várakozik, amíg a szerver megkapja a következő lekérdezést.
Csökkenthető a költség feltételes kéréssel (7.2:
If-None-Match,304) és gyorsítótárral, de a kérés kezelésének költsége megmarad. A kliensek indításának véletlenszerű eltolása (jitter) elkerüli, hogy minden kliens ugyanabban a pillanatban kérdezzen.Adaptív polling
Egy várakozó feladatnál a periódus változhat: kezdetben rövid, később hosszabb, végleges állapotnál megáll. A szerver javasolhat következő ellenőrzési időt. A kliens ne indítson új kérést, ha az előző még fut; lassú hálózaton különben egyre több párhuzamos lekérés halmozódik fel. A „nincs változás” és a „nem sikerült lekérni” külön állapot, és hálózati hiba után érdemes ritkítani a próbálkozást (6.5); végleges jogosultsági hibánál nem szabad korlátlanul folytatni.
Jellemzők
Gyakori tévhitek
Röviden
Ellenőrző kérdések
Források