WebSockets и SSE

1) Qisqacha: nima va nima uchun

WebSocket (WS/WSS) - to’liq dubleks kanalgacha bo’lgan HTTP ulanishini yangilash. Chatlar, jonli o’yinlar, hamkorlik, ikki yo’nalishli telemetriya uchun mos keladi.
Server-Sent Events (SSE) - serverdan brauzerga bir tomonlama oqim (MIME’text/event-stream’). Tikerlar, xabarnomalar, kotirovkalar, vazifalar taraqqiyoti uchun ideal. Mijoz’EventSource’.

• Mijozdan real vaqt rejimida (tez-tez va koʻp) kirish kerak → WebSocket.
• Faqat serverdan push-yangilanishlar, moslik va soddalik SSEdan muhimroqdir.

2) Tarmoq va protokollar

2. 1 Transport va muvofiqlik

WebSocket: HTTP’GET sifatida boshlanadi... Upgrade: websocket` (HTTP/1. 1). HTTP/2 uchun RFC 8441 (CONNECT +’: protocol = websocket’) mavjud, qoʻllab-quvvatlash proksiga bogʻliq. TLS (WSS) ustida ishlaydi - albatta.
SSE: oddiy uzoq davom etgan HTTP javobi (’200 OK’). Bu juda yaxshi HTTP/1. 1/2/3, CDN/proxy bilan mos keladi.

2. 2 Proxy/balanschilar/CDN

Tekshiring: uzoq umr koʻradigan ulanishlar, idl va taymautlar, sticky-seanslar (agar holat uzelda boʻlsa).
WS uchun:’proxy _ read _ timeout’,’upgrade’- qopqoqlari, per-ulanish limitlarini kiriting.
SSE uchun: proksi javobni bufer qilmasligiga ishonch hosil qiling (aks holda mijoz voqealarni oʻz vaqtida koʻrmaydi).

3) Xabarlar modeli va oqimni boshqarish

WebSocket: matn yoki binar kadrlar; ’ping/pong’ mavjud, lekin oʻrnatilgan backpressure mavjud emas - ilovada (navbatlar, derazalar, drop-policy) amalga oshiring.
SSE: matnli hodisalar (UTF-8); mijoz kechikish bilan ichki reconnect biladi; server’retry:’vazifasini bajarishi mumkin. ’id:’ va’Last-Event-ID’sarlavhasi mavjud.

• Chiqadigan xabarlarni per-mijozga kvota qiling.
• Yozilmagan voqealarning navbatini cheklang; to’lib-toshganda - past prioritetlilarni tashlab yuborish/agregatsiya qilish.
• WS uchun: ilova darajasidagi «harakatlanuvchi oyna» va ACK sxemasidan foydalaning.

4) Ulanishlarning ishonchliligi

4. 1 Deteksiya va keepalive

WS: «ping» ni har n soniyada yuboring; taymaut bo’yicha uzilish - eksponensial backoff + jitter bilan reconnect.
SSE: server’izohlarni’:\n’heartbeat sifatida yuboradi, shunda ulanish idle hisoblanmaydi; mijoz o’zi ulanadi.

4. 2 Oqimni tiklash

WS: offset/sequence xabarlarni saqlang va reconnect tugaganidan keyin deltani soʻrang.
SSE: har bir hodisa uchun’id:’dan foydalaning va’Last-Event-ID’soʻrovda serverda oʻtkazib yuborilgan hodisalarni yuboradi.

5) Autentifikatsiya va avtorizatsiya

JWT Bearer soʻrov URL (WS) da xavfsiz emas. «Secure», «HttpOnly», «SameSite» bayroqlari bilan sarlavhadan (birlamchi HTTP xandsheyk orqali) yoki kukidan foydalaning.
mTLS (ayniqsa B2B uchun) va dastlabki soʻrov ustidagi imzolar (HMAC) boʻlishi mumkin.
Kukli SSE uchun CORS (’Access-Control-Allow-Origin’,’Allow-Credentials’) haqida eslang.

Tokenning aylanishi: oqimni uzmang. «Tez orada tugaydi» deb xabar bering → mijoz yangi tokenga ulanishni qayta ochadi.

6) Ma’lumotlar formati va kompresssiya

WebSocket: permessage-deflate’ni ehtiyotkorlik bilan yoqing (CPU); siqilgan formatlarni siqishdan qoching (Proto, Euro). Binar payload JSON’dan tejamkor.
SSE: bu matn; katta ma’lumotlar uchun REST/gRPC resurs yoki chunk-fayllarga havolani yuboring; SSE uchun transport gzip - mos, lekin proxy/CDN’dagi buferizatsiyani kuzating.

7) Ko’paytirish va fan-aut

7. 1 Gorizontal kattalashtirish

Ilovani qayta ishga tushirish uchun nuqsonsiz saqlang. Birikmalarning holati - front qatlamida; ma’lumotlar - brokerdan.
Agar lokal navbatlar boʻlsa, Sticky (session/user xesh) kerak.
Ideal - stateless front: tugun faqat obunalarni multiplekslaydi; hodisalar umumiy pub/sub dan keladi.

7. 2 Pub/Sub va brokerlar

Keng fan-out uchun Kafka/NATS/Redis Streams dan foydalaning.
«Fanout Gateway» qatlami WS/SSE bo’yicha mijozlarga topiklar va pushitlarga obuna bo’ladi.
Tugmalar orasidagi yukni muvozanatlash uchun marshrutlash kalitini (masalan,’userId’,’matchId’) qoʻllang.

8) Ishlab chiqarish konfiguralari

8. 1 NGINX — WebSocket

nginx map $http_upgrade $connection_upgrade { default upgrade; '' close; }

server {
listen 443 ssl http2;
server_name ws. example. com;

location /ws {
proxy_set_header Host $host;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_http_version 1. 1;
proxy_read_timeout 75s; # increase for long sessions proxy_send_timeout 15s;
proxy_pass http://ws-backend;
}
}

8. 2 NGINX - SSE (buferlashni oʻchirish muhim)

nginx location /events {
proxy_http_version 1. 1;
proxy_set_header Connection "";
proxy_buffering off; # is critical for proxy_cache off threads;
chunked_transfer_encoding on;
proxy_read_timeout 60m;
proxy_pass http://sse-backend;
}

8. 3 Kubernetes (Ingress Annotations, NGINX Ingress)

yaml metadata:
annotations:
nginx. ingress. kubernetes. io/proxy-read-timeout: "3600"
nginx. ingress. kubernetes. io/proxy-send-timeout: "3600"
nginx. ingress. kubernetes. io/enable-websocket: "true"
nginx. ingress. kubernetes. io/proxy-buffering: "off"  # для SSE

9) Kod namunalari

9. 1 SSE mijozi (brauzer)

js const es = new EventSource("/events? channel=odds", { withCredentials: true });

es. addEventListener("message", (e) => {
const data = JSON. parse(e. data);
renderOdds(data);
});

es. addEventListener("error", () => {
//EventSource will reconnect itself; can be shown spinner
});

9. 2 SSE serveri (Node. js/Express)

js app. get('/events', (req, res) => {
res. writeHead(200, {
'Content-Type': 'text/event-stream',
'Cache-Control': 'no-cache',
'Connection': 'keep-alive',
});
res. write ('retry: 3000\n\n') ;//3s backoff to client

const sub = subscribe(req. query. channel, (event) => {
res. write(`id: ${event. id}\n`);
res. write(`event: message\n`);
res. write(`data: ${JSON. stringify(event. payload)}\n\n`);
});

req. on('close', () => sub. unsubscribe());
});

9. 3 WebSocket mijozi (brauzer)

js const ws = new WebSocket("wss://ws. example. com/ws");
ws. onopen = () => ws. send(JSON. stringify({ type: "join", room: "chat-1" }));
ws. onmessage = (m) => handle(JSON. parse(m. data));
ws. onclose = () => scheduleReconnect();

10) Xavfsizlik va limitlash

Rate limiting per-ulanish va per-foydalanuvchi: kirish xabarlarining chastotasini (WS) va chiqish oqimining tezligini (WS/SSE) cheklang.
Ulanish muddati va umumiy trafik boʻyicha quota.
Message size limit и max messages/sec.
hendsheyk bosqichida WAF/bot-filtrlar; connection flooding (ko’plab qisqa konnektlar) dan himoya qilish.
tenant/namespace bo’yicha izolyatsiya: alohida resurslar pullari.

11) Kuzatish

• `connections_active`, `connections_new_total`, `bytes_in/out`,
• `messages_in/out_total`, `dropped_messages_total`,
• `reconnects_total`, `latency_delivery_ms{p50,p95,p99}`.
• Logi: IP/UA, userId/tenantId, yopilish sababi (’close _ code’), davomiyligi.
• Treysing: voqealarni boshlang’ich buyruq (korrelyatsiya ID) bilan bog’lang; WS uchun «virtual» uyqulardan foydalaning.

12) Ekspluatatsiya nuanslari

TLS terminatsiyasi mijozga yaqinroq (CDN/edge).
Deplolarda graceful rotatsiyasi: bayroqni «qayta ulash».
«Issiq» kanallarni bir tekis taqsimlash uchun kalit bilan shardlash.
Keyingi obunachilar uchun holat rasmlari (snapshot + delta).
Oxirgi qiymatli kesh (ayniqsa SSE) - «sovuq» mijoz uchun foydalidir.

13) Anti-patternlar

SSE yoki JSON orqali WS orqali katta binar boʻlaklarni oqizish - HTTP orqali yuklash va xabardagi havolani ishlating.
Faqat ulanish vaqtida avtorizatsiya qilish va uzoq sessiyalarda qayta tekshirishlar boʻlmasligi.
Ehtiyojsiz global sticky → nomutanosiblik va «issiq» nodlar.
O’chirilgan taymautlar/limitlar → osilgan konnektlar pulni iste’mol qiladi.
SSE proxy/CDN → ning buferlanishi kechikish daqiqalariga aylanadi.
Sequence/offset → ning yoʻqligi reconnect dan keyin mijoz maʼlumotlar yaxlitligini yoʻqotadi.

14) Joriy etish chek-varaqasi

• Tanlangan model: WS (ikki tomonlama) yoki SSE (bir tomonlama).
• Taymautlar, keepalive va reconnect (backoff + jitter) moslashtirilgan.
• Sequence/offset va (SSE uchun)’id ’/’ Last-Event-ID’loyihalashtirilgan.
• Belgilangan limitlar: o’lcham/tezlik/ulanish/kvotalar, DoS himoyasi.
• Proksi/ingress : upgrade, off (SSE), read/send timeouts.
• Masshtab: pub/sub-broker, fan-out-shlyuz, faqat kerak bo’lganda sticky.
• Autentifikatsiya: tokenni xavfsiz uzatish, uzilishsiz rotatsiya.
• Kuzatish darajasi: metrika, loglar, trassalar; dashbordlar va alertlar.
• Reliz rejasi: graceful-drain ulanishlar, mijozga qayta ulanish haqida signal.
• Game Days: tarmoq uzilishlari, nod qulashi, brokerning ortiqcha yuklanishi, uzun RTT.

15) FAQ

SSEni CDN orqali keshlash mumkinmi?
Odatda yo’q: bu shaxsiylashtirilgan oqim. Ommaviy kanallar uchun - ehtimol qisqa TTL va chunked-delivery bilan, lekin «real vaqt» ni buzish oson.

WebSocket HTTP/2/3 ustida ishlaydimi?
Brauzer WS HTTP/1. 1-upgrade; h2 uchun RFC 8441 mavjud, proksi/serverda alohida yordam talab qilinadi. S h3 - harakatda; h3 da striming uchun WebTransport mavjud, ammo bu boshqa API.

gRPC vs WS brauzer uchun?
Sof brauzer gRPC demaydi; Envoy orqali gRPC-Web kerak. Interaktiv UI uchun ko’pincha WS + REST osonroq.

16) Yakunlar

WebSocket - real vaqt muloqoti va ixcham ikki yo’nalishli kanal kerak bo’lganda.
SSE - serverdan mijozga oddiy va ishonchli push kerak bo’lganda, minimal murakkablik va avtomatik reconnect.
Oziq-ovqatda muvaffaqiyat - bu to’g’ri taymautlar va limitlar, offset-dan tiklash, pub/sub-fan-aut, to’g’ri proksi sozlamalari va aniq kuzatish.