WebSockets и SSE

1) Qısa: nə və nə üçün

WebSocket (WS/WSS) - tam dubleks kanala HTTP bağlantısının yenilənməsi. Söhbətlər, canlı oyunlar, əməkdaşlıq, iki yönlü telemetriya üçün uyğundur.
Server-Sent Events (SSE) - serverdən brauzerə (MIME 'text/event-stream') birtərəfli axın. Tikerlər, bildirişlər, kotirovkalar, tapşırıqların tərəqqisi üçün idealdır. Müştəri - «EventSource».

• Real vaxt müştəridən giriş lazımdır (tez-tez və çox) → WebSocket.
• Yalnız server push-updates, uyğunluq və sadəlik daha vacibdir → SSE.

2) Şəbəkə və protokollar

2. 1 Nəqliyyat və uyğunluq

WebSocket: HTTP 'GET kimi başlayır... Upgrade: websocket` (HTTP/1. 1). RFC 8441 (CONNECT + ': protocol = websocket') HTTP/2 üçün mümkündür, dəstək proxydən asılıdır. TLS (WSS) üzərində işləyir - prodda mütləq.
SSE: normal uzun müddət davam edən HTTP cavabı ('200 OK'). Gözəl HTTP/1 keçir. 1/2/3, CDN/proxy ilə uyğun (uzun konnektlər kəsilmədikdə).

2. 2 Proxy/Balans/CDN

Check-in: uzunömürlü bağlantıları, Idle və Taymaut, Sticky-seansları dəstəkləyir (əgər vəziyyət qovşaqda olarsa).
WS üçün: 'proxy _ read _ timeout', 'upgrade' başlıqlarını, per-link limitlərini daxil edin.
SSE üçün: proxy cavabını tamponlamadığından əmin olun (əks halda müştəri hadisələri vaxtında görməyəcək).

3) Mesaj modeli və axın idarəetmə

WebSocket: çərçivələr mətn və ya ikili; 'ping/pong' var, lakin daxili backpressure yoxdur - proqramda həyata keçirin (növbələr, pəncərələr, drop-policy).
SSE: mətn hadisələri (UTF-8); müştəri daxili gecikmə ilə reconnect bilər; server 'retry:' təyin edə bilər. Var 'id:' və başlıq 'Last-Event-ID' istədiyiniz mövqedən bərpa üçün.

• per-müştəri gedən mesajları kvota.
• Göndərilməmiş hadisələrin növbəsini məhdudlaşdırın; daşdıqda - aşağı prioritet atmaq/yığmaq.
• WS üçün: tətbiq səviyyəsində «sürüşmə pəncərəsi» və ACK sxemindən istifadə edin.

4) Birləşmə etibarlılığı

4. 1 Deteksiya və keepalive

WS: "ping 'i hər N saniyədə göndərin; zaman fasiləsi - eksponensial backoff + jitter ilə reconnect.
SSE: server «şərhlər» göndərir ':\n' heartbeat kimi ki, əlaqə idle sayılmasın; müştəri özü yenidən qoşulacaq.

4. 2 Axını bərpa edin

WS: offset/sequence mesajları saxlamaq və reconnect sonra delta tələb.
SSE: hər bir hadisə üçün 'id:' istifadə edin və sorğuda 'Last-Event-ID' - server buraxılmış hadisələri göndərir.

5) Autentifikasiya və avtorizasiya

Sorğu URL-də (WS) JWT Bearer təhlükəsiz deyil (log sızması). Başlığı (birincil HTTP hendshake vasitəsilə) və ya 'Secure', 'HttpOnly', 'SameSite' bayraqları olan kukiləri istifadə edin.
mTLS (xüsusilə B2B üçün), həmçinin ilkin sorğunun üstündəki imzalar (HMAC) mümkündür.
Cookies ilə SSE üçün CORS ('Access-Control-Allow-Origin', 'Allow-Credentials') haqqında unutmayın.

Tokenin rotasiyası: axını kəsməyin. «Tezliklə bitəcək» deyin → müştəri yeni tokenlə əlaqəni yenidən açacaq.

6) Data formatı və sıxılma

WebSocket: permessage-deflate ehtiyatlı (CPU) daxil edin; artıq sıxılmış formatlarda sıxılmaqdan çəkinin (Proto, Avro). İkili payload JSON-dan daha qənaətlidir.
SSE: Bu mətn; Böyük məlumatlar üçün REST/gRPC resurs və ya chunk fayllarına link göndərin; SSE üçün nəqliyyat gzip - uyğun, lakin proxy/CDN tamponlama nəzarət.

7) Miqyas və fan-out

7. 1 Üfüqi miqyaslandırma

Proqramın yenidən başlamasını təmin edin. Birləşmələrin vəziyyəti - ön təbəqədə; məlumat - brokerdən.
Sticky (session/user hash) yerli növbələr varsa lazımdır.
İdeal - stateless cəbhə: qovşaq yalnız abunə multiplex; hadisələr ümumi pub/sub gəlir.

7. 2 Pub/Sub və brokerlər

Geniş fan-out üçün Kafka/NATS/Redis Streams istifadə edin.
«Fanout Gateway» təbəqəsi WS/SSE ilə müştərilərə top və pushit abunə olunur.
Nodlar arasında yükü balanslaşdırmaq üçün marşrut açarını (məsələn, 'userId', 'matchId') tətbiq edin.

8) İstehsal konfiqləri

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 (buferləşməni söndürmək vacibdir)

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 nümunələri

9. 1 SSE müştəri (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 Server (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 müştəri (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) Təhlükəsizlik və məhdud

Rate limiting per-link və per-istifadəçi: Daxil olan mesajların tezliyini (WS) və gedən axın sürətini (WS/SSE) məhdudlaşdırın.
Əlaqə ömrü və ümumi trafik ilə Quota.
Message size limit и max messages/sec.
Hendsheyk mərhələsində WAF/bot filtrləri; connection flooding qorunması (bir çox qısa konnektlər).
tenant/namespace ilə izolyasiya: ayrı-ayrı resurslar hovuzları.

11) Müşahidə

• `connections_active`, `connections_new_total`, `bytes_in/out`,
• `messages_in/out_total`, `dropped_messages_total`,
• `reconnects_total`, `latency_delivery_ms{p50,p95,p99}`.
• Qeydlər: IP/UA, userId/tenantId, bağlanma səbəbi ('close _ code'), müddəti.
• Trace: hadisələri orijinal komanda ilə əlaqələndirin (korrelyasiya ID); WS üçün «virtual» yataqlardan istifadə edin.

12) Əməliyyat nüansları

TLS terminasiyası müştəriyə daha yaxındır (CDN/edge).
Deploylar zamanı birləşmələrin proaktiv rotasiyası (graceful): bayrağı «yenidən bağla».
«Isti» kanalları bərabər paylamaq üçün açar çardağı.
Son abunəçilər üçün vəziyyət şəkilləri (snapshot + delta).
Son dəyər cache (xüsusilə SSE) - «soyuq» müştəri üçün faydalıdır.

13) Anti-nümunələr

WS vasitəsilə SSE və ya JSON vasitəsilə böyük ikili parçaları axın - HTTP download və link istifadə edin.
Yalnız qoşulma anında avtorizasiya və uzun sessiyalarda təkrar yoxlamaların olmaması.
ehtiyac olmadan qlobal sticky → disbalance və «isti» nodes.
Fasiləsiz vaxt/limitlər → donmuş konektlər hovuzu yeyir.
SSE proxy/CDN → «real vaxt» buferizasiyası gecikmə dəqiqələrinə çevrilir.
reconnect müştəri məlumatların bütövlüyünü itirdikdən sonra sequence/offset → yoxdur.

14) Giriş çek siyahısı

• Model seçildi: WS (iki yönlü) və ya SSE (birtərəfli).
• Time, keepalive və reconnect (backoff + jitter) konfiqurasiya.
• sequence/offset və (SSE üçün) 'id '/' Last-Event-ID' tərəfindən dizayn edilmişdir.
• Müəyyən edilmiş limitlər: ölçüsü/sürəti/əlaqələri/kvotaları, DoS qorunması.
• proxy/ingress: upgrade, off (SSE), read/send timeouts.
• Miqyaslandırma: pub/sub-broker, fan-out-şlyuz, yalnız lazım olduqda sticky.
• Autentifikasiya: təhlükəsiz token ötürülməsi, fasiləsiz rotasiya.
• Müşahidə: metriklər, yuvalar, yollar; daşbordlar və alertlər.
• Release planı: graceful-drain bağlantıları, müştəri keçid siqnal.
• Game Days: şəbəkənin qırılması, nodların düşməsi, brokerin həddindən artıq yüklənməsi, uzun RTT.

15) FAQ

CDN vasitəsilə SSE-ni keşləşdirmək mümkündürmü?
Adətən yox: bu fərdi axındır. İctimai kanallar üçün - qısa TTL və chunked-delivery ilə mümkündür, lakin "real vaxt 'ı pozmaq asandır.

WebSocket HTTP/2/3 üzərində işləyirmi?
Browser WS HTTP/1 başlayır. 1-upgrade; h2 üçün RFC 8441 var, proxy/serverdə dəstək ayrıca tələb olunur. h3 ilə - hərəkətdə; h3 axını üçün WebTransport var, lakin fərqli bir API var.

gRPC vs WS brauzer üçün?
Təmiz brauzer gRPC danışmır; gRPC-Web Envoy vasitəsilə lazımdır. İnteraktiv UI üçün çox vaxt WS + REST daha asandır.

16) Nəticələr

WebSocket - real vaxt dialoqu və kompakt iki yönlü kanal lazım olduqda.
SSE - server-müştəri sadə və etibarlı push lazım olduqda, minimal mürəkkəblik və avtomatik reconnect.
Məhsulun müvəffəqiyyəti düzgün taymaut və limitlərdir, offset, pub/sub-fan-out, düzgün proxy parametrləri və aydın müşahidə.