A WebSocket egy hálózati protokoll, ami egy full-duplex, perzisztens kapcsolatot ad a böngésző (vagy bármely kliens) és a szerver között. Szemben a HTTP kérdezz-felelek modelljével, ahol minden interakcióhoz új TCP-kapcsolat kell, a WebSocket egyszer felépül és aztán szabadon küldhetsz üzeneteket bármelyik irányban — valós időben, low-latency-vel. Ezért lett a chat-alkalmazások, élő dashboardok, kollaboratív szerkesztők (Google Docs, Figma), és multiplayer játékok alaprétege. Az IETF szabványként 2011-ben (RFC 6455) ratifikálódott, és ma minden modern böngésző natívan támogatja.
Így is ismerheted
Magyarul nincs általánosan elterjedt fordítás — szinte mindenki WebSocket-nek nevezi. Néha web socket (külön írva), néha WS rövidítésként. Régebbi szakirodalom „full-duplex protokoll”-ként vagy „kétirányú kommunikációként” hivatkozik rá. Kapcsolódó fogalmak: Socket.io (a legnépszerűbb JS-könyvtár fölötte, fallback-okkal), SSE (Server-Sent Events — egyirányú alternatíva), WebRTC (peer-to-peer, médiához), long polling (a WebSocket előtti hack-megoldás).
Hogyan működik? — HTTP upgrade-mechanizmus
A WebSocket trükkje, hogy egy normál HTTP-kéréssel kezdődik, amit a szerver „upgrade-el” WebSocket-kapcsolattá. A kliens egy speciális Upgrade: websocket header-rel küld GET-et, a szerver, ha támogatja, 101 Switching Protocols-szal válaszol, és innentől ugyanaz a TCP-kapcsolat WebSocket-frame-eket szállít HTTP helyett.
Egy WebSocket-kapcsolat tipikusan percekig-órákig is él — addig amíg valamelyik fél le nem zárja. A frame-formátum bináris, alacsony overhead (2-14 byte header), így nagy üzenet-volumen mellett is hatékony. Az URL-séma ws:// vagy biztonságos verzió esetén wss:// (a HTTPS-nek megfelelő). Modern projekten szinte mindig wss:// — egyébként a sok proxy és tűzfal eldobja a kapcsolatot.
Mire jó? — tipikus felhasználási esetek
A WebSocket akkor a jó választás, ha valódi kétirányú, alacsony késleltetésű kommunikáció kell. Tipikus use case-ek:
- Chat-alkalmazás — minden új üzenet azonnal megjelenik mindkét félnél. Slack, WhatsApp Web, Discord mind WebSocket-tel működik.
- Élő dashboard / monitorozás — szerver-metrikák, részvénypiaci adatok, élő statisztikák valós időben. Cloudflare admin-panel, Grafana, részvény-trader app-ok.
- Kollaboratív szerkesztő — Google Docs, Figma, Notion. Minden gépeléses esemény szétküldve a többi résztvevőnek.
- Multiplayer játék — minden játékos akciója szétkürtölve a többinek 50-100 ms-on belül.
- Push-értesítés a böngészőben — egy bejövő e-mail, új komment, foglalási státusz változás. Service Worker + WebSocket kombóval.
- IoT-eszközök — szenzor-adatok streaming-je, távoli vezérlés.
Ha egyirányú adatforgalom elég (csak a szerver küld a kliensnek), érdemes inkább SSE-t (Server-Sent Events) használni — egyszerűbb, automatikusan reconnect-el, HTTP-alapú így a proxy-k jobban kezelik.
HTTP vs WebSocket — mikor melyiket?
Sokszor a kérdés inkább: kell-e a perzisztens kapcsolat, vagy elég a HTTP polling. A döntéshez pár szempont:
- HTTP REST jó: ha a tartalom statikus vagy ritkán változik (pl. termék-katalógus, blog). Cache-elhető CDN-en (lásd a CDN cikket), HTTP/2 over multiplexed, jól skálázódik.
- WebSocket jó: ha valódi kétirányú real-time kommunikáció kell, és a kapcsolat-fenntartás költsége elviselhető.
- SSE jó: ha csak szerver → kliens egyirányú stream (pl. live blog, push-értesítés). Egyszerűbb mint a WebSocket.
- Long polling: legacy fallback. Ha a tűzfal/proxy nem enged WebSocket-et, ezzel hídelhető át.
Egy tipikus hiba: chat-alkalmazás esetén az egyszerű polling-ra optimalizálnak. „5 másodpercenként lekérjük az új üzeneteket” — a UI lassú lesz, a backend felesleges DB-kérésekkel terhelt, és a user-élmény gyenge. WebSocket-tel ugyanez 50 ms és kevesebb erőforrás.
Tooling — könyvtárak és szolgáltatók
Szerveroldalon (Node.js):
- Socket.io — a legnépszerűbb. Saját protokollt épít a WebSocket fölé, fallback-ekkel (long polling, ha a WS nem megy). Beépített rooms, namespaces, broadcast. Tipikus választás 90%-on, de overkill, ha tiszta WebSocket elég.
- ws — natív WebSocket-implementáció Node.js-re. Minimal, gyors. Ha tudod mit csinálsz, ezt válaszd Socket.io helyett.
- uWebSockets.js — a leggyorsabb (C++ alapú). Extrém terhelésen használatos.
Egyéb stack-eken: django-channels (Python), Phoenix Channels (Elixir — kifejezetten WebSocket-re tervezve), SignalR (.NET), Action Cable (Rails). PHP-ban a Ratchet a legismertebb, de PHP nem ideális WebSocket-szerverre — érdemes inkább Node.js sidecart futtatni mellé.
Managed szolgáltatások, ha nem akarsz saját WS-szervert üzemeltetni: Pusher, Ably, PubNub, Soketi (Pusher-kompatibilis self-hosted). Tipikus áraik: $50-200/hó kis-közepes forgalomra. Ha real-time-feature kell egy másik egyszerű projekten, ezekkel 2-3 óra alatt működik.
Mire figyelj — buktatók
Egy gyakori probléma: a WebSocket-kapcsolat „titokban” elszakad, de a kliens nem tudja. A TCP-szinten a connection still „alive”, de valójában nem érkezik adat. Megoldás: heartbeat mechanizmus — ping üzenetet küldesz 30 másodpercenként, és ha nincs válasz, manuálisan újrakapcsolódsz. A Socket.io ezt automatikusan kezeli; tiszta WebSocket-en saját kódot kell írnod hozzá.
Skálázás: WebSocket-szerver állapotos (stateful), egy szerver-instance-on bizonyos sok konkurens kapcsolat lehet (50-100 ezer egy átlag Node.js-en). Több szerverre osztás esetén szükség van egy pub/sub broker-re (Redis, NATS), ami szétküldi az üzeneteket a node-ok között.
Reverse-proxy konfig: nginx-en kell proxy_set_header Upgrade $http_upgrade és proxy_set_header Connection "upgrade" a WebSocket átengedéséhez. Egy korábbi projekten 4 órán át nyomoztuk, miért szakad meg az élő dashboard 60 másodperc után — kiderült, hogy az nginx proxy_read_timeout alapból 60 sec, és ezt explicit kell felemelni WebSocket-route-on (pl. 7 napra).
Ha WebSocket-alapú real-time feature-t építenénk neked — chat-modult, élő dashboardot, kollaboratív funkciót — lásd az egyedi weboldal-fejlesztés és a mobil app fejlesztés szolgáltatásunkat. Kapcsolódó cikkek: GraphQL (van GraphQL Subscription is, ami WebSocket fölött fut), Webhook, CDN.
