Jan Mikoláš
Slovník pojmů
WebSocket
WebSocket umožňuje živě aktualizovat rozhraní, ale nezaručuje doručení business události ani nenahrazuje serverovou autorizaci.
Stručná definice
Jedno otevřené spojení pro zprávy v obou směrech.
WebSocket začíná HTTP handshakem, při kterém se klient a server dohodnou na přechodu protokolu. Potom už nejde o běžný cyklus request–response: spojení zůstává otevřené a server může poslat zprávu okamžitě, například při vzniku nové objednávky.
Hodí se pro stav, který se mění během práce uživatele. Nevytváří však spolehlivou frontu ani trvalý záznam událostí. Spojení může zaniknout, zpráva se může ztratit a po návratu online musí aplikace umět ověřit aktuální stav přes běžné API.
K čemu se používá
Kde má živé spojení praktický přínos
WebSocket je užitečný, když server potřebuje reagovat rychle a průběžně, nikoli až na další dotaz klienta.
- živý přehled nových objednávek, plateb nebo skladových změn v administraci
- stav dlouhotrvajícího importu, exportu nebo jiné asynchronní úlohy
- chat, spolupráce více uživatelů nebo editace dokumentu s průběžnými změnami
- monitoring provozu a aktuální upozornění pro obsluhu interního systému
- doplněk k HTTP API, které dál načítá úplný a autoritativní stav dat
Praktický příklad
Přihlášení k živým událostem jednoho tenanta
Administrace po úspěšné autentizaci otevře zabezpečené spojení wss://. Server z identity spojení určí uživatele a při žádosti o odběr sám ověří, zda tento uživatel smí číst události konkrétní organizace. Název kanálu, který poslal prohlížeč, nikdy není důkazem oprávnění.
Po výpadku klient počká s rostoucím odstupem, spojení otevře znovu a načte aktuální seznam objednávek přes API. Tím opraví případnou mezeru mezi poslední přijatou zprávou a stavem v databázi.
JavaScript
const socket = new WebSocket('wss://app.example.cz/live');
socket.addEventListener('open', () => {
socket.send(JSON.stringify({ type: 'subscribe', tenantId: 'tenant-42' }));
});
socket.addEventListener('message', (event) => {
const message = JSON.parse(event.data);
if (message.type === 'order.updated') refreshOrders();
});Jak funguje
Textový diagram: klient → HTTP upgrade → otevřené spojení → zprávy → obnova stavu
Síťové spojení je jen dopravní cesta. Aplikace musí samostatně řešit identitu, práva, pořadí a obnovu po výpadku.
- Navázání přes HTTPS Klient otevře ws:// nebo v běžné produkci wss:// URL. Úvodní HTTP handshake požádá o přechod na WebSocket; reverse proxy jej musí podporovat.
- Ověření identity Server ověří session nebo jiný přihlašovací mechanismus. Otevřené spojení není samo o sobě důkaz, že uživatel smí číst každý kanál.
- Autorizace tématu Při odběru server vyhodnotí tenant, roli a konkrétní data. Stejná kontrola platí i pro zprávu, která má něco změnit.
- Přenos zpráv Obě strany si posílají malé zprávy. Ping a pong mohou pomoci rozpoznat neaktivní spojení, neřeší ale businessové potvrzení.
- Odpojení a návrat Klient počítá s uzavřením, omezeně opakuje připojení a po návratu si přes API synchronizuje stav, který mu mohl uniknout.
Důležité pojmy
Spojení, kanál a potvrzení mají různé významy
Přesné pojmenování pomáhá navrhnout systém, který se chová předvídatelně i při výpadku.
Plný duplex
Klient i server mohou posílat zprávy nezávisle na sobě. To se liší od běžného HTTP, kde server typicky odpovídá až na klientův request.
Kanál nebo téma
Aplikace může seskupit události podle organizace, objednávky či projektu. Takové pojmenování je pouze vstup do autorizačního rozhodnutí, ne bezpečnostní ochrana.
Reconnect
Po odpojení klient znovu naváže spojení, obvykle s omezeným exponenciálním odstupem. Je nutné zabránit bouři připojení při výpadku služby.
Backpressure
Pomalý klient nebo server nemusí stíhat příchozí zprávy. Aplikace proto omezuje velikost fronty, agreguje méně důležité změny nebo klientovi nabízí načtení aktuálního stavu.
Koordinace více serverů
Při horizontálním škálování mohou být odběratel a producent na jiných uzlech. K distribuci události je pak potřeba broker nebo jiná sdílená koordinace.
Vztah k podobným pojmům
WebSocket není webhook, polling ani garance doručení
Volba závisí na četnosti změn, důležitosti události, síťových omezeních a schopnosti obnovit stav.
- WebSocket a polling
- Polling pravidelně otevírá HTTP request a klient zjišťuje stav sám. WebSocket sníží prodlevu pro průběžné změny, ale přidá péči o otevřená spojení.
- WebSocket a webhook
- Webhook oznamuje jednu událost HTTP požadavkem z poskytovatele na příjemce. WebSocket je dlouhodobý kanál mezi klientem a serverem.
- WebSocket a Server-Sent Events
- SSE posílá události zejména jedním směrem ze serveru do prohlížeče přes HTTP. WebSocket je vhodný, když obě strany běžně posílají zprávy.
- Síťová zpráva a business výsledek
- Přijetí zprávy neznamená, že se změna bezpečně zapsala. Důležité operace potřebují validaci, idempotenci, trvalé uložení a dohledatelný stav.
Výhody a omezení
Nižší prodleva výměnou za složitější provoz a obnovu stavu
Přínosy
- server může informovat klienta bez čekání na další polling
- jedno spojení stačí pro více souvisejících živých změn
- lepší odezva pro chat, monitoring nebo administraci s rychle se měnícím stavem
- lze kombinovat s HTTP API bez vytváření vlastního dlouhého pollingu
Časté chyby
- předpokládat, že připojený klient vždy dostane každou zprávu
- důvěřovat názvu kanálu zaslanému prohlížečem bez autorizace
- neřešit reconnect, mezeru v událostech a načtení aktuálního stavu
- držet neomezené množství pomalých spojení nebo zpráv ve frontě
- zapomenout na podporu upgrade, limitů a timeoutů v proxy či load balanceru
Kdy jej použít
Když změna musí dorazit rychle, ne když stačí občasný dotaz.
Pro veřejný katalog, který se změní několikrát denně, bývá jednodušší běžná HTTP cache nebo občasné načtení. WebSocket se vyplatí tam, kde uživatel právě sleduje měnící se objekt a každé nové načtení by zbytečně zatěžovalo klienta i server.
Pro kritické integrační události nestačí pouze odeslat WebSocket zprávu. Spolehlivější návrh trvale uloží změnu, klientovi pošle upozornění a po reconnectu mu umožní načíst stav nebo chybějící události přes zdokumentované API.
Na co myslet
Živý kanál vyžaduje stejné bezpečnostní hranice jako API.
Připojení, každá zpráva i obnova po výpadku musí mít předvídatelný kontrakt.
- použít wss:// a správně nastavit WebSocket upgrade v reverzní proxy
- ověřit identitu a autorizovat každé téma i akci na serveru
- omezit velikost zpráv, počet odběrů a rychlost odesílání
- navrhnout reconnect s odstupem, synchronizaci stavu a pozorovatelné chyby
- měřit počet spojení, zpoždění, ukončení, neúspěšná připojení a zahlcené klienty
Časté otázky
WebSocket bez častých záměn
Je WebSocket rychlejší než HTTP?
Odpadá opakované navazování requestů a server může zprávu poslat ihned. Celkovou odezvu ale stále ovlivní síť, práce backendu, velikost zprávy i vytížení klienta.
Nahradí WebSocket REST API?
Obvykle ne. API zůstává vhodné pro načtení aktuálního stavu, historii, explicitní příkazy a obnovu po odpojení. WebSocket může tyto operace doplnit živým upozorněním.
Zaručí WebSocket doručení zprávy?
Ne na úrovni business významu. Spojení může vypadnout a aplikace musí sama navrhnout potvrzení, deduplikaci, historii nebo opětovné načtení stavu podle důležitosti zprávy.
Stačí uživatele ověřit jen při připojení?
Ne. Přihlášení určí identitu, ale přístup k tenantovi, kanálu a konkrétním datům musí server ověřovat podle aktuální autorizace.
Jak navrhuji integrační a aplikační toky v praxi
Živé aktualizace propojuji s autoritativním stavem a jasným kontraktem.
U systémů s objednávkami, skladem a integracemi řeším nejen zprávu v reálném čase, ale i výpadek, oprávnění, dohledatelnost a bezpečnou obnovu dat.