Összevetés és választás: honnan érkezik a változás, és mibe kerül?

Célok

A lecke végére a hét szempont mentén össze tudod hasonlítani a kommunikációs módszereket, tudod, hová illik a Socket.IO, és indokolni tudsz egy választást konkrét igényre.

Miért kell?

A kurzus a kérés–válasz stílusoktól a tartós, kétirányú csatornáig vezetett. A feladat mindig ugyanaz: melyik módszer illik az adott igényhez, és mit ad cserébe. A legismertebb eszköz nem feltétlenül a legegyszerűbb megfelelő megoldás.

Összevetés

Módszer	Irány	Kezdeményező	Kapcsolat	Késleltetés	Terhelés	Hibatűrés	Mikor jó?	Mikor nem?
Kérés–válasz (REST, RPC, GraphQL; 7. f.)	Kérés + válasz	Kliens	Kérésenként	Egy körút	Kérésszámmal arányos	Idempotens kérés ismételhető	Műveletek, erőforrás-olvasás	Szerver felől érkező változás
Üzenetsor / pub-sub / napló (8. f.)	Termelő → fogyasztó(k)	Termelő	Közvetítőn át	Sorhossztól függ	Puffer, backpressure	Nyugta, ismétlés, DLQ	Szolgáltatások közti aszinkron munka	Azonnali válasz kell
Webhook (8.5)	Forrás → fogadó	Forrás	Eseményenként egy kérés	Esemény után gyors	Eseményenként	Duplikáció, idempotens fogadó	Szerver–szerver értesítés	Böngészős frissítés
Polling (9.1)	Kliens kérdez	Kliens	Kérésenként	Periódus fele–egész	N/T, állandó	Egyszerű	Ritka változás, egyszerűség	Sűrű változás, sok kliens
Long polling (9.2)	Szerver késleltetve válaszol	Kliens	Hosszan nyitott kérés	Alacsony, de újrakérési rés	Kevesebb üres kérés	Kurzor kell	Kisebb késés, nincs tartós csatorna	Gyakori üzenet
SSE (9.3)	Szerver → kliens	Kliens nyitja, szerver küld	Tartós HTTP-válasz	Alacsony	Nyitott kapcsolat	Auto-reconnect + Last-Event-ID	Egyirányú élő státusz	Kétirányú sűrű forgalom
WebRTC DataChannel (9.4)	Peer ↔ peer	Bármelyik peer	Tartós, közvetlen	Alacsony	Peerek között	Beállítható megbízhatóság	Peer-kommunikáció, gyorsan elavuló adat	Hiteles központi állapot
WebSocket (10. f.)	Kétirányú	Kapcsolat: kliens; üzenet: bármelyik	Tartós	Alacsony	Kapcsolat × ütem	Alkalmazásra bízva	Gyakori kétirányú üzenet	Ritka egyirányú értesítés

A táblázat architekturális különbségeket mutat; a pontos képesség környezetfüggő, és nem helyettesíti a böngészői és infrastrukturális vizsgálatot.

Socket.IO helye

A Socket.IO magasabb szintű kommunikációs megoldás saját protokollal, kliens- és szerverkönyvtárral. A dokumentáció szerint két rétegből áll: az alacsony szintű Engine.IO a kapcsolatot kezeli (WebSocket, WebTransport vagy a legrosszabb esetben HTTP long polling szállítással; alapértelmezésben a kliens long polling kapcsolattal indul, majd megpróbál frissíteni), a magas szintű Socket.IO pedig további képességeket ad: automatikus újracsatlakozás, csomagpufferelés, nyugták, szétküldés (broadcast) minden kliensnek vagy egy részhalmaznak. Az Engine.IO életjel-mechanizmust is tartalmaz.

Fontos: a Socket.IO nem azonos a natív WebSockettel. A Socket.IO saját protokollt használ a WebSocket (vagy más szállítás) fölött, ezért egy egyszerű WebSocket-kliens nem tud vele automatikusan beszélni. A Socket.IO garanciái: a sorrendet a szállítástól függetlenül garantálja; alapértelmezésben legfeljebb egyszeri kézbesítést ad; a szétkapcsolt kliens pufferelheti az eseményeket az újracsatlakozásig, a szerver viszont nem; kliensről szerverre nyugtával és ismétléssel legalább egyszeri kézbesítés érhető el; szerverről kliensre a tartósságot az alkalmazásnak kell megoldania, egyedi eseményazonosítókkal és tárolt eltolással.

Döntési kérdések

1. Ki kezdeményez? Csak a kliens, csak a szerver, vagy mindkettő?
2. Milyen gyakran változik az adat, és mennyi késleltetés elfogadható? Néhány másodperc: polling; azonnali egyirányú: SSE; azonnali kétirányú: WebSocket.
3. Elég a legfrissebb állapot, vagy minden köztes esemény kell? A másodikhoz napló, visszajátszás vagy tartós sor kell.
4. Központi szerverrel vagy peerrel jön létre a kapcsolat?
5. Szerver–szerver értesítésről van szó? Webhook vagy üzenetsor.
6. Mi a megbízhatósági igény? Legfeljebb egyszer, legalább egyszer; ki dolgozik duplikációval?
7. Mit bír az infrastruktúra? Proxy, tétlenségi időkorlát, kapcsolatszám.

Példák (nem receptek): egy hosszú feladat állapotához elég lehet a polling; egy értesítési folyamhoz természetes az SSE; chathez WebSocket vagy magasabb szintű könyvtár; gyorsan elavuló pozíciókhoz részben megbízható peer-csatorna; szolgáltatások közti esemény-átadáshoz üzenetsor vagy webhook.

Tartalék szállítás és ugyanaz a jelentés

Ha a WebSocket helyett long pollingra váltanak, az alkalmazási szerződésnek továbbra is ugyanazt az eredményt kell jelentenie; ne legyen más jogosultság vagy ismétlésvédelem pusztán a szállítás különbsége miatt. A kapcsolatállapotot és a teljesítménykorlátokat viszont mindkét úton ellenőrizni kell.

Gyakori tévhitek

Állítás	Pontosítás
„Valós idejű frissítéshez mindig WebSocket kell.”	Polling vagy SSE is megfelelhet.
„A Socket.IO = WebSocket.”	Saját protokoll és könyvtár, több szállítással.
„A magasabb szintű könyvtár pontosan egyszeri kézbesítést ad.”	Az alapértelmezés legfeljebb egyszeri; a többit konfigurálni vagy építeni kell.
„Egy módszer mindenre jó.”	Minden módszer kompromisszum; több is együtt élhet.

Röviden

• A módszerek irány, kezdeményező, tartósság, késleltetés, terhelés, hibatűrés és alkalmazhatóság szerint hasonlíthatók össze.
• A választást a kezdeményező, a gyakoriság, a megbízhatóság és az infrastruktúra dönti el.
• A Socket.IO saját protokoll és könyvtár, nem natív WebSocket.
• A WebSocket akkor indokolt, ha mindkét fél gyakran kezdeményez; máskor egyszerűbb módszer is elég.

Ellenőrző kérdések

1. Melyik módszert választanád ritkán változó állapothoz, és melyiket közös szerkesztéshez?
2. Miben különbözik a Socket.IO a natív WebSockettől?
3. Mi a teendő, ha a szállítás long pollingra vált vissza?

Források

• How it works (Socket.IO) — Engine.IO, szállítások, funkciók.
• Delivery guarantees (Socket.IO) — sorrend, legfeljebb egyszeri kézbesítés, nyugták.
• WebSocket API (MDN) — a WebSocket és a WebTransport viszonya.