Long polling

Célok

A lecke végére el tudod magyarázni a long polling működését, a polling-hoz képesti előnyét és költségeit, és meg tudod nevezni a megbízható használat feltételeit.

Miért kell?

A polling késleltet, mert a kliens csak a periódus végén kérdez újra, és sokszor üresen. A long polling azt változtatja meg, hogy a szerver mikor válaszol: nem azonnal, hanem amikor van mit mondania.

Mi a long polling?

Az RFC 6202 szerint a long polling esetén a szerver a kérést nyitva tartja, és csak akkor válaszol, ha egy esemény, állapotváltozás vagy időtúllépés bekövetkezett. A kliens a válasz feldolgozása után azonnal új kérést nyit.

sequenceDiagram
  participant K as Kliens
  participant S as Szerver
  K->>S: GET /events?after=90
  Note over S: A kérés nyitva marad
  S-->>K: 91. esemény
  K->>S: GET /events?after=91
  Note over S: Időkeret lejárt, nincs esemény
  S-->>K: Üres válasz
  K->>S: Következő kérés

Mit ad, és mi az ára?

• Kisebb észlelési késés, kevesebb üres válasz, mint a pollingnál.
• Az RFC 6202 szerint a maximális késleltetés mégis három hálózati átvitelnél is több lehet, és minden üzenet teljes HTTP-csere, így a fejlécek az átvitt adat nagy részét tehetik ki. Csomagvesztés és újraküldés tovább növelheti.
• A válasz és a következő kérés között eltelt időben esemény keletkezhet. Hogy ne vesszen el, a szerződésnek kurzort (például az utolsó ismert eseményazonosítót) és szerveroldali megőrzést kell tartalmaznia. Az RFC 6202 ezt a versenyhelyzetet nem tárgyalja, a megoldás a tananyag saját javaslata.

Gyakorlati szabályok (RFC 6202, 5. fejezet)

• Időtúllépés: a böngészők alapértelmezése 300 másodperc, de a hálózati elemek gyakran korábban lezárják a kapcsolatot; az RFC szerint a 30 másodperc „általában biztonságosabb érték”, és voltak kísérletek 120 másodperccel is.
• Kapcsolatok száma: a HTTP korábban kettőnél több kapcsolatot nem javasolt egy szerverhez; a mai böngészők 6–8-at engednek, de ez helyben nem deríthető ki, ezért a szerver észlelhet több long pollt ugyanattól a böngészőtől (például sütivel), hogy ne éheztesse ki a kapcsolatokat.
• Gyorsítótár: közbenső gyorsítótárak zavarhatják; ajánlott a gyorsítótárazás tiltása (Cache-Control: no-cache).
• Válasz: 200 OK csak akkor, ha esemény vagy időtúllépés történt.
• Proxy: a proxyk azonnal továbbítsák a long poll válaszokat a kliensnek.

Jellemzők

Szempont	Long polling
Irány	A kliens kérdez, a szerver késleltetve válaszol
Kezdeményező	A kliens
Kapcsolat tartóssága	Kérésenként új, de a kérés hosszan nyitva marad
Késleltetés	Alacsony az eseményre, de a válasz–újrakérés rés mindig megvan
Terhelés	Kevesebb üres kérés; nyitott kapcsolat per kliens a szerveren
Hibatűrés	Kurzor és megőrzés kell a kihagyás ellen; újrakérés hálózati hiba után
Mikor jó?	Kisebb késés kell, de tartós csatorna nem lehetséges (régi infrastruktúra, tűzfal)
Mikor nem?	Gyakori üzenetek (a fejlécköltség); kétirányú vezérlés

Hogyan viszonyul a többihez?

A long polling a pollingnál alacsonyabb késleltetést ad, de minden válasz után új HTTP-csere kell. A következő lecke SSE-je ugyanazt a kapcsolatot tartja nyitva több üzenetre, ezzel kikerüli az ismételt fejlécköltséget.

Gyakori tévhitek

Állítás	Pontosítás
„A long polling tartós kapcsolat.”	Minden válasz után új kérés indul.
„A long polling nem veszít eseményt.”	Kurzor és megőrzés nélkül veszíthet.
„A long polling nem terheli a szervert.”	Nyitott kérések per kliens; időtúllépést és proxyt kezelni kell.

Röviden

• A szerver a kérést addig tartja nyitva, amíg esemény vagy időtúllépés történik; a kliens utána újat nyit.
• Alacsonyabb észlelési késés, kevesebb üres válasz, de minden üzenet teljes HTTP-csere.
• Időtúllépés, kapcsolatszám, gyorsítótár és proxy kezelése szükséges (RFC 6202).
• Kurzor nélkül események veszhetnek el.

Ellenőrző kérdések

1. Miben különbözik a long polling a pollingtól?
2. Miért szükséges kurzor?
3. Milyen időtúllépést tart biztonságosnak az RFC 6202?

Források

• RFC 6202: Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP — 2.1–2.2 és 5. fejezet.