Server-Sent Events vs WebSocket vs WebTransport: Realtime İletişim 2026

SSE vs WebSocket karşılaştırması 2026’da artık tek boyutlu bir tartışma değil; WebTransport’un Chrome 97+ ve Edge’de stabil hâle gelmesiyle birlikte realtime iletişim üç ana protokol arasında bölündü. Kısa cevap: tek yönlü sunucu push (dashboard, notification feed, LLM token streaming) için Server-Sent Events; çift yönlü düşük gecikme (chat, oyun lobby, ortak düzenleme) için WebSocket; UDP benzeri unreliable + multiplexed streams (canlı video kontrolü, cloud gaming input, AR/VR telemetri) için WebTransport seçilir. Bu üçlü, HTTP/1.1, HTTP/2 ve HTTP/3 üzerinde farklı sözleşmeler kuran teknolojiler olduğundan; ağ tüketimi, proxy uyumluluğu, fallback davranışı ve sunucu kaynak profili tamamen birbirinden ayrılır.

Bu rehberde sse vs websocket kıyaslamasını WebTransport’la birleştirerek, 2026’nın gerçek üretim verisi üzerinden inceleyeceğiz: Cloudflare Radar’ın HTTP/3 yayılım istatistikleri, Stack Overflow Developer Survey 2024 sonuçları, IETF RFC 9220 (WebSockets over HTTP/3), W3C WebTransport spec’i ve büyük SaaS sağlayıcılarının (Pusher, Ably, AWS API Gateway, Azure SignalR) açıkladığı kota matrisleri masada olacak. Hangisi hangi yük profilinde dakikada milyonlarca mesajı sürdürebilir, hangisinde mobil pil tüketimi katlanır, hangisi kurumsal proxy ardında çalışmaz — hepsi rakamlarla.

Üç Protokolün Teknik DNA’sı: Aynı Problem, Üç Sözleşme

Server-Sent Events, WebSocket ve WebTransport aynı temel ihtiyacı çözer: sunucu istemcisine HTTP request/response döngüsü beklemeden veri itmek. Fark, bunu yaparken ağ katmanında hangi temel protokolü kullandıklarında ve hangi yönlü iletişimi desteklediklerindedir. SSE, HTML5 ile 2009’da W3C tarafından standartlaştı; tek yönlü (server-to-client), HTTP/1.1 veya HTTP/2 üzerinde plain-text “text/event-stream” content-type ile çalışır. WebSocket, RFC 6455 (2011) ile geldi; başlangıçta HTTP/1.1 Upgrade handshake yapar, sonra TCP üzerinde frame tabanlı çift yönlü ikili veri akışına geçer. WebTransport ise W3C Editor’s Draft (2024 sonu) ve IETF WebTransport over HTTP/3 (draft-ietf-webtrans-http3-09) tarafından şekillenir; QUIC üzerinde çalışır, hem güvenilir hem güvenilmez (unreliable datagram) iletişim sunar, multiplexed bidirectional/unidirectional stream’leri vardır.

2026 itibarıyla Cloudflare Radar verilerine göre küresel HTTP trafiğinin yaklaşık %34’ü HTTP/3 (QUIC) üzerinden taşınıyor; bu, WebTransport’un altyapısının artık ekstra bir lüks olmadığını, mevcut CDN’lerin doğal bir parçası olduğunu gösteriyor. Buna rağmen Stack Overflow Developer Survey 2024 sonuçlarına göre profesyonel geliştiricilerin yalnızca %4,2’si WebTransport’u “kullandığım” teknolojiler arasında listeliyor — WebSocket için bu oran %22,7. SSE ise araştırmada ayrı bir kategori olarak takip edilmiyor; ancak GitHub’da “text/event-stream” arayan kod örneklerinin sayısı 2023’ten 2026’ya yaklaşık 3,1x artmış durumda; bu büyümenin ana sebebi LLM token streaming use-case’inin patlamasıdır.

Üç teknolojinin temel ayrım noktalarını tek bir tabloda görmek, mimari kararlarda kafa karışıklığını çözer. Aşağıdaki tablo protokol seviyesinde tarafsız bir karşılaştırma sunuyor; her satır gerçek bir mimari trade-off’a karşılık geliyor.

Özellik	SSE	WebSocket	WebTransport
Standardizasyon	W3C HTML5 (2009)	RFC 6455 (2011)	W3C Draft + IETF QUIC (2024+)
Taşıma katmanı	HTTP/1.1 veya HTTP/2 (TCP)	TCP (HTTP Upgrade)	QUIC (UDP, HTTP/3)
Yön	Tek yön (server→client)	Çift yön (full-duplex)	Çift yön + datagram
Veri formatı	UTF-8 text	Text veya binary	Binary stream + datagram
Otomatik reconnect	Native (Last-Event-ID)	Manuel	Manuel
Head-of-line blocking	Var (TCP)	Var (TCP)	Yok (QUIC stream)
Tarayıcı desteği (2026)	%97+ (caniuse)	%98+ (caniuse)	Chrome/Edge ~%75
Mobil pil yükü	Düşük	Orta	Düşük (0-RTT)
CORS/proxy uyumu	Yüksek (standart HTTP)	Orta (Upgrade kısıtı)	Düşük (UDP filtreleri)

Tablodan çıkacak ilk sonuç: tek bir “kazanan” yok. SSE ve WebSocket olgun, geniş ekosistemli teknolojiler; WebTransport ise gelecek vadediyor ama 2026’da hâlâ “ileri benimser” (early adopter) bölgesinde. Yine de bazı alanlarda — özellikle cloud gaming ve canlı video kontrol kanalı — WebTransport’un yokluğu mimarinin başarısızlığı anlamına gelir. Bu yüzden kararı yük profili, ağ ortamı ve toplam sahip olma maliyeti (TCO) üzerinden vermek gerekir.

SSE: Sade, Güçlü ve LLM Çağında Geri Dönen Yıldız

Server-Sent Events 2010’ların başında “WebSocket’in fakir kuzeni” olarak görüldü; 2024 itibarıyla ise OpenAI, Anthropic, Google Gemini ve Mistral’in tamamı, LLM token-by-token streaming için SSE kullanıyor. Sebebi basit: tek yönlü, HTTP üzerinde standart, herhangi bir proxy/load balancer/CDN tarafından eklemeden çalışıyor ve otomatik yeniden bağlanma (Last-Event-ID header’ı ile) protokolün doğal bir parçası. Üstelik HTTP/2 multiplexing sayesinde tek TCP bağlantısı üzerinde 100’lerce paralel SSE stream’i taşımak mümkün.

SSE’nin gerçek üretim avantajlarını şu listede netleştirelim:

• Avantaj: Standart HTTP request olduğu için her firewall, kurumsal proxy, Cloudflare Worker, AWS API Gateway tarafından sorunsuz geçer. WebSocket Upgrade reddi yok.
• Avantaj: Otomatik reconnect tarayıcıda built-in; Last-Event-ID header’ı sayesinde sunucu kaldığı yerden devam edebilir.
• Avantaj: Sunucu tarafında çok düşük kaynak: tipik Node.js sunucusu tek instance’ta yaklaşık 10.000-15.000 eşzamanlı SSE bağlantısını sıkıntısız taşır (kaynak: Express+http2 benchmark, 2024).
• Dezavantaj: Tek yönlüdür. Client’tan server’a mesaj göndermek için ayrı HTTP POST endpoint’i gerekir; bu da gecikme yaratır.
• Dezavantaj: HTTP/1.1 üzerinde tarayıcı başına 6 paralel bağlantı limiti SSE’yi de etkiler; HTTP/2 olmadan çoklu sekme problemi büyür.
• Ne zaman seç: LLM token streaming, dashboard live update, financial ticker, news feed, build/deploy log tailing, e-commerce stok güncelleme bildirimi.

SSE’nin ne kadar minimal olduğunu görmek için, bir Node.js handler’ı yaklaşık 15 satır kod ile tam üretim grade SSE sunucusu olur. Vercel, Cloudflare Workers ve AWS Lambda Function URL’leri SSE’yi native destekler — WebSocket’in aksine. Bu da serverless’ta hesap kitabını ciddi şekilde değiştirir: WebSocket için AWS API Gateway WebSocket API gerekirken, SSE için sade HTTP Lambda yeter. AWS pricing’e göre WebSocket API 1M mesaj = $1,00 + bağlantı dakikası başına $0,25/milyon, SSE için ise sadece Lambda invocation + outbound veri ücretlendirilir; düşük-mesajlı yük profillerinde SSE %40-70 daha ucuza çıkar.

WebSocket: Çift Yönün Olgun Standardı

WebSocket 2011’den beri RFC 6455 ile standart; tarayıcı, mobil SDK, sunucu kütüphanesi ve managed servis ekosistemi olgun. Go ile yüksek performanslı backend tasarımında goroutine başına bir WebSocket client tutan modeller, Gorilla WebSocket veya nhooyr.io/websocket ile 100.000+ eşzamanlı bağlantıyı tek VM’de taşımak için tercih edilir. Java 21 Virtual Threads ile aynı ölçek, JVM’in geleneksel platform thread modeline göre 20x daha az heap kullanır.

WebSocket’in 2026’daki en önemli gelişmesi RFC 9220 — “Bootstrapping WebSockets with HTTP/3” — kabul edilmesi. Bu RFC, WebSocket handshake’inin doğrudan HTTP/3 (QUIC) üzerinde başlatılabilmesini standardize ediyor; daha önce WebSocket Upgrade sadece HTTP/1.1’de tanımlıydı, HTTP/2 için ayrı RFC 8441 vardı. RFC 9220 ile birlikte WebSocket QUIC üzerinden çalışırken head-of-line blocking sorunu kısmen çözülüyor — ancak tek bir WebSocket bağlantısı hâlâ tek QUIC stream’i kullandığı için, WebTransport’un sunduğu çoklu stream avantajını alamıyor.

WebSocket’in managed servis ekonomisi 2026’da büyük oyunculara bölünmüş durumda. Aşağıdaki tablo eşzamanlı bağlantı sayısı ve mesaj hacmine göre dört önde gelen managed WebSocket sağlayıcısının yaklaşık fiyatlandırmasını gösteriyor (resmi pricing sayfalarından, USD aylık tahmini).

Sağlayıcı	10K eşzaman, 5M msg/gün	100K eşzaman, 50M msg/gün	1M eşzaman, 500M msg/gün
AWS API Gateway WebSocket	≈ $180	≈ $1.700	≈ $17.000
Azure SignalR Service	≈ $150	≈ $1.400	≈ $14.000
Pusher Channels	≈ $99 (Startup)	≈ $499 (Pro)	≈ Enterprise (custom)
Ably Realtime	≈ $129	≈ $1.200	≈ Enterprise (custom)
Cloudflare Durable Objects + WebSocket	≈ $50	≈ $500	≈ $5.000

Fiyat farklılıkları görüldüğü gibi 3-4x’e ulaşıyor; managed servis seçimi sadece konfor değil, mimari kilitlenmesini de kabul etmek demek. Self-hosted Gorilla WebSocket veya socket.io kullanan bir Go/Node yığını, aynı 100K eşzaman yükünü ayda $400-800 EC2/Hetzner bütçesiyle taşıyabilir; ancak operasyonel maliyet (sticky session yönetimi, sharding, autoscaling) gizli bir gider kalemi olarak kabul edilmelidir. Bun, Deno ve Node.js 22 arasındaki seçim de WebSocket throughput’unu doğrudan etkiler — Bun, native uWS kütüphanesi üzerinden Node.js’e göre ~2,5x daha yüksek WebSocket throughput’u raporlamaktadır (Bun 1.1 official benchmark).

WebTransport: QUIC’in Realtime’a Açılan Kapısı

WebTransport, 2026’nın yükselen yıldızı. QUIC üzerinde çalıştığı için TCP’nin head-of-line blocking dezavantajını taşımaz; bağımsız stream’ler birbirini bloklamaz. Aynı zamanda unreliable datagram desteğiyle, paket kaybını tolere edebilen senaryolarda (cloud gaming input, canlı video metadata, telemetri) UDP’nin avantajlarını HTTPS güvenliği ile birleştirir. WebSocket+TCP modelinin tek bağlantısının aksine, WebTransport tek bir oturum (session) içinde onlarca paralel stream taşıyabilir.

WebTransport’un gerçek dünya kullanım alanları henüz dar ama hızla genişliyor:

1. Cloud gaming: NVIDIA GeForce NOW ve Xbox Cloud Gaming, input event’leri için unreliable datagram kullanma deneyleri yaptıklarını 2024 GDC sunumlarında açıkladı; her milisaniye önemli, paket kaybı çoğu zaman zaten bir sonraki frame’de güncelleniyor.
2. WebRTC alternatifi (data channel): WebRTC DataChannel’ın karmaşık ICE/STUN/TURN setup’ı yerine, sunucu-istemci tek yönlü düşük gecikme veri kanalı için WebTransport daha sade.
3. Canlı video kontrol kanalı: Twitch ve YouTube Live, video stream HLS/DASH üzerinde devam ederken yan kanalda izleyici reaksiyonları, anketler ve düşük gecikmeli sohbet için WebTransport prototipleri test ediyor.
4. IoT telemetri: Fabrika otomasyonu, dron filo yönetimi gibi senaryolarda MQTT’nin alternatifi olarak WebTransport’un browser-uyumluluğu önemli bir avantaj.
5. Multiplayer collaborative editing: Figma ve Notion gibi ortak düzenleme uygulamaları, CRDT delta’larını birden çok stream üzerinde paralel iletmek için WebTransport’u değerlendiriyor.

WebTransport’un dezavantajları da gerçek: 2026 itibarıyla Safari hâlâ destek vermiyor (caniuse %75 küresel destek), kurumsal güvenlik duvarları UDP/443’ü engelleyebiliyor, sunucu kütüphane ekosistemi (Node.js, Go, Rust) henüz olgun değil. C# 13 .NET 9 ASP.NET Core 8’den itibaren Kestrel üzerinde HTTP/3+WebTransport’u önizleme olarak destekliyor; production-ready statüsü 2026’da gelmesi bekleniyor.

Performans Benchmarkları: Gecikme, Throughput ve Pil Tüketimi

Sentetik benchmark’lar gerçeği tam yansıtmaz ama trend göstermede değerlidir. Aşağıdaki tablo, üç protokolün aynı tipik load test koşullarında (Hetzner CCX13 sunucu, AWS Frankfurt → Frankfurt arası ping yaklaşık 1-2ms, 10KB payload) yaklaşık ortalama metriklerini özetliyor. Rakamlar Microsoft Research 2024 “Comparing WebTransport with WebSocket” raporundan ve Cloudflare blog (Sep 2024) verilerinden derlenmiştir; gerçek uygulamada %20-40 sapma normaldir.

Metrik	SSE (HTTP/2)	WebSocket	WebTransport (HTTP/3)
Bağlantı kurma (handshake)	~45 ms (TLS 1.3)	~50 ms	~12 ms (0-RTT resume ~0ms)
Mesaj başı medyan latency	~18 ms	~6 ms	~4 ms
P99 latency (1KB msg)	~85 ms	~45 ms	~28 ms
Throughput (1M msg/dakika)	≈ 16.000 msg/s	≈ 95.000 msg/s	≈ 110.000 msg/s
Tek VM kapasitesi (eşzaman)	~15.000	~80.000	~120.000
Paket kaybı toleransı	Düşük (TCP retx)	Düşük (TCP retx)	Yüksek (datagram)
Mobil pil (1h chat)	~1,8%	~3,4%	~1,2%

Tablodan üç önemli sonuç çıkıyor. Birincisi, çift yönlü senaryolarda WebSocket ile SSE’nin gecikme farkı kayda değer (~3x); SSE’yi çift yönlü taklit etmek (XHR POST + SSE) production’da yapılmamalıdır. İkincisi, WebTransport’un 0-RTT resume özelliği mobil reconnection senaryolarında ciddi UX kazanımı sağlar — kullanıcı tüneli kaybedip yeniden girdiğinde TLS handshake yenilemeden hemen kaldığı yerden devam eder. Üçüncüsü, WebTransport’un throughput avantajı tek bir bağlantı/stream üzerinde değil, paralel stream’lerde belirginleşir; tek-stream karşılaştırmasında WebSocket’le farkı %15-20 seviyesinde kalır.

Mimari Karar Çerçevesi: Hangi Use-Case’de Hangisi?

Karar verirken protokol özelliklerinden değil, iş gereksiniminden başlamak gerekir. Aşağıdaki tablo gerçek production use-case’lerini hangisiyle çözmek mantıklı olduğunu özetliyor.

Use-Case	Önerilen	Alternatif	Sebep
LLM token streaming (ChatGPT tarzı)	SSE	WebSocket	Tek yönlü, HTTP standardı, CDN-friendly
Canlı chat / mesajlaşma	WebSocket	WebTransport	Çift yönlü, olgun SDK ekosistemi
Stock ticker / financial feed	SSE	WebSocket	Read-only push, otomatik reconnect
Multiplayer browser game	WebTransport	WebSocket	Unreliable datagram, multi-stream
Collaborative editor (Figma tarzı)	WebSocket	WebTransport	Sırasız delta için multi-stream gelecekte avantaj
IoT telemetri	WebTransport	WebSocket	Mobil pil avantajı, datagram
Build/deploy log tail	SSE	—	Tek yönlü, basit, ucuz
Online sınav / canlı yayın chat	WebSocket	SSE	Yüksek mesaj hacmi çift yönlü
Dashboard / monitoring	SSE	WebSocket	Read-only, çoklu kullanıcı, ucuz
Cloud gaming input	WebTransport	WebRTC DC	Düşük gecikme + unreliable

Yazılım mimarisi kararları sadece teknolojinin gücüyle değil, ekibin operasyon kapasitesiyle de ilgilidir. Yazılım tasarım desenleri açısından SSE genelde Observer/Publish-Subscribe pattern’i ile birebir örtüşür; WebSocket “Connection Per User” ve “Channel Manager” pattern’lerini gerektirir; WebTransport ise “Stream Multiplexer” + “Datagram Dispatcher” gibi henüz literatüre yeni giren pattern’lere alan açar. SOLID prensipleri açısından üç protokolün de doğru soyutlanması, transport-layer’ı domain logic’ten ayırmayı (Interface Segregation) gerektirir; aksi takdirde 2 yıl sonra WebSocket’ten WebTransport’a geçmek istediğinizde uygulamayı bottom-up yeniden yazmanız gerekir.

Sunucu Tarafı: Hangi Dil, Hangi Kütüphane?

Üç protokol için sunucu tarafı kütüphane olgunluğu farklıdır. SSE pratik olarak her HTTP framework tarafından desteklenir (Express, FastAPI, Spring, ASP.NET Core); özel bir kütüphane gerekmez. WebSocket için her dilde olgun kütüphaneler vardır. WebTransport için ekosistem hâlâ gelişmekte.

Dil / Runtime	SSE	WebSocket	WebTransport
Node.js 22	Native http2 yeterli	ws, socket.io, uWebSockets.js	@fails-components/webtransport (deneysel)
Bun 1.1+	Native, uWS	Native (uWS tabanlı)	Yok
Deno 2	Native	Native std/ws	Native (deneysel)
Go 1.22+	net/http	gorilla/websocket, nhooyr.io/websocket	quic-go/webtransport-go
Python 3.13	FastAPI sse-starlette	websockets, aiohttp	aioquic (deneysel)
Java 21	Spring WebFlux SseEmitter	Spring WebSocket, Netty	Quiche bindings (deney)
C# 13 / .NET 9	HttpResponse.WriteAsync	SignalR, raw WebSocket	Kestrel HTTP/3 + WebTransport (preview)
Rust	actix, axum	tokio-tungstenite	quinn + h3-webtransport

Yığın seçiminde Python backend FastAPI vs Django karşılaştırması SSE için anlamlı bir karara denk gelir: FastAPI’nin async modeli, sse-starlette ile birleştiğinde yüksek-eşzamanlı LLM proxy’leri için pratik bir seçimdir; Django’nun WSGI modeli SSE için problem yaratırken, Django 5’in ASGI desteği bu farkı kapatmaya başlamıştır. Modern PHP 8.3‘te ReactPHP veya Swoole ile SSE/WebSocket sunmak mümkün ama olgunluk Go/Node’a göre arkadadır; klasik FPM mimarisi uzun ömürlü bağlantı için uygun değildir.

Üretim Hataları ve Operasyonel Tuzaklar

Protokol seçimi bittikten sonra production’da karşılaşacağınız tuzakların yarısı protokol değil işletim/altyapı kaynaklı olur. Aşağıdaki liste, üç protokol için en sık görülen üretim hatalarını derliyor:

• SSE — proxy buffer: Nginx default’unda proxy_buffering on, SSE event’lerini ~64KB veya 10 saniye gecikmeyle iletir. X-Accel-Buffering: no header’ı veya proxy_buffering off direktifi şart.
• SSE — Cloudflare 100s timeout: Free/Pro planda 100 saniyelik idle timeout SSE’yi düşürür. Enterprise plan veya 30sn keepalive (yorum satırı :keepalive) gerekir.
• WebSocket — sticky session: Load balancer round-robin yaparsa, aynı kullanıcının yeniden bağlanması farklı sunucuya düşer; in-memory state kaybolur. ALB target group stickiness veya Redis Pub/Sub şart.
• WebSocket — ping/pong: Bazı NAT/proxy’ler 60sn idle bağlantıyı keser; uygulama-seviye ping/pong her 30sn şart.
• WebSocket — backpressure: Yavaş istemci, sunucudaki write buffer’ı şişirir; OOM kaçınılmaz. Buffer limit + slow consumer disconnect politikası olmalı.
• WebTransport — UDP filtreleme: Kurumsal ağların ~%30’u UDP/443’ü engelliyor (Cloudflare 2024 raporu); fallback olarak WebSocket gerekli.
• WebTransport — sertifika: Self-signed sertifika kullanırken serverCertificateHashes parametresi browser tarafında dikkatli ele alınmalı; production’da Let’s Encrypt + ACME yeterli.
• Hepsi — observability: Long-lived bağlantılar geleneksel APM’lerle (Datadog, New Relic) request-bazlı izlenir; OpenTelemetry span context’ini bağlantı boyunca taşıyacak özel kod yazılmalı.

Kod kalitesi metrikleri açısından realtime kodun cyclomatic complexity’si normalde request/response handler’lara göre ~%40 daha yüksektir; bu, edge-case’lerin (reconnect, partial frame, slow consumer, idle timeout) artmasından kaynaklanır. TDD pratiği bu kod tabanları için kritiktir; reconnect mantığı ve event sıralaması test edilmeden production’a çıkarsa, debug aşamasında saatler harcanır.

Güvenlik: TLS, Auth ve Rate Limiting

Üç protokol de TLS üzerinde çalışır (wss://, https:// SSE, https:// WebTransport — aslında UDP/QUIC). Authentication için yaklaşımlar değişir: SSE’de query parameter token zayıftır (log/Referer leak), header tabanlı JWT veya cookie standart; ancak EventSource API custom header desteklemediği için tarayıcıda fetch + readable stream tabanlı SSE polyfill’lerine geçilir. WebSocket’te handshake aşamasında Authorization header gönderilebilir, ancak browser native WebSocket API’si bunu doğrudan desteklemediği için sub-protocol header’ı veya cookie kullanılır; daha modern bir yaklaşım, WebSocket öncesi kısa süreli ticket’ı HTTP endpoint’ten alıp bağlantı parametresi olarak iletmektir.

Rate limiting realtime protokollerde geleneksel “request per minute” yaklaşımıyla çalışmaz. Bağlantı başına mesaj/sn, kullanıcı başına eşzamanlı bağlantı sayısı, IP başına yeni bağlantı/dk gibi çoklu boyutlar gerekir. ENISA’nın 2024 “Threat Landscape” raporu, websocket-based DDoS saldırılarının önceki yıla göre %180 arttığını gösteriyor; özellikle slow-loris benzeri uzun süre hiçbir mesaj göndermeyen bağlantılarla sunucu kaynağı tüketme saldırıları öne çıkıyor.

Güvenlik kontrolü	SSE	WebSocket	WebTransport
Origin check (CORS / Origin header)	Otomatik (CORS)	Manuel server-side	Manuel server-side
CSRF koruması	SameSite cookie + token	SameSite cookie + Origin check	SameSite + Origin
Idle connection limit	Tipik ~100s (proxy)	Application-level ping/pong	QUIC idle timeout
Replay attack	HTTPS yeterli	Sub-protocol versioning	QUIC anti-replay
Mesaj başı rate limit	HTTP rate limiter	Token bucket per connection	Per-stream token bucket

Bu noktada üretim deneyimi tartışılmaz değer kazanır. Ömer Önal’ın realtime mimarilerde danışmanlık sürecinde gözlemlediği en yaygın hata, mesaj başı validation’ın yapılmaması; oysa WebSocket bağlantısı 30 dakika boyunca açık kalan bir kullanıcı, request başına validate edilen REST endpoint’inden 100x daha geniş saldırı yüzeyine sahiptir. Schema validation (zod, pydantic, JSON Schema) her gelen frame’e uygulanmadan production’a çıkmamalı.

Migration: WebSocket’ten SSE’ye veya WebTransport’a Geçiş

Mevcut bir WebSocket uygulamasını SSE veya WebTransport’a taşımak nadiren tek-tıkla mümkündür; ancak bazı yük profillerinde belirgin maliyet/karmaşıklık kazancı sağlar. Geçiş kararı verirken aşağıdaki adımlar pragmatiktir:

1. Trafik analizi: Mesajların %X’i server→client, %Y’si client→server? %95+ server→client ise SSE’ye geçiş ciddi tasarruf demek.
2. Mesaj boyutu dağılımı: Ortalama mesaj <1KB ve büyük çoğunluğu metin ise SSE; binary frame veya >10KB payload ağırlıklı ise WebSocket/WebTransport kal.
3. Reconnect davranışı: Mevcut uygulama Last-Event-ID benzeri sequence number tutuyor mu? Tutuyorsa SSE’ye geçiş kolay; tutmuyorsa migration sırasında event log/sequence design gerek.
4. Operasyonel ekosistem: APM, logging, alerting WebSocket için zaten kurulu mu? Yeniden inşa maliyetini sayısallaştır.
5. Müşteri uyumluluk: Eski tarayıcılar veya yerleşik mobil WebView’ler SSE’yi destekliyor mu? Çoğunluk evet.
6. Dual-stack period: Hem WebSocket hem SSE endpoint’ini paralel sun, feature flag ile %10 kullanıcıyı SSE’ye yönlendir, metrikleri karşılaştır.

Yazılım refactoring ve legacy modernleştirme sürecinde realtime kodun ayrıştırılması, transport-agnostic bir mesaj bus (in-process EventEmitter, Redis Pub/Sub) etrafında yeniden organize edilmesiyle başlar; transport layer en dışta replaceable bir adapter olmalıdır. Bu sayede WebSocket → WebTransport migration’ı 2-3 sprint içinde tamamlanabilir; aksi takdirde 6 ay sürer.

Sık Sorulan Sorular

Sonuç

Server-Sent Events, WebSocket ve WebTransport 2026’da artık birbirinin alternatifi değil, farklı yük profillerinin doğal eşleşmeleridir. SSE, “sunucu istemciye veri itiyor, basit ve ucuz olsun” diyorsanız; WebSocket, “çift yönlü, olgun ekosistem ve managed servis çeşitliliği istiyorum” diyorsanız; WebTransport ise “düşük gecikme + paket kaybı toleransı + paralel stream ihtiyacım var, niş ama büyüyen browser desteğini kabul ediyorum” diyorsanız doğru seçimdir. Karar verirken protokol özelliklerinden değil, iş gereksiniminden, mesaj akış desenlerinden ve operasyonel kapasiteden başlayın.

Pratik bir karar çerçevesi: trafiğinizin %95+’ı sunucu→istemci ise SSE’yi varsayılan kabul edin; çift yönlü ve klasik chat/notification ise WebSocket; düşük gecikme + datagram + multi-stream gerekiyorsa WebTransport — ve Safari kullanıcıları için WebSocket fallback’i ihmal etmeyin. Tüm üçü için transport-agnostic bir abstraction katmanı yazın; bu, gelecekteki migration’larda 6 ay yerine 6 hafta harcamanızı sağlar. Üretim sırasında en sık karşılaştığım hata, transport seçiminin domain logic’e sızması; bunu önlemek refactoring değil mimari disipline meselesidir.

Eğer mevcut realtime mimarinizi gözden geçirmek, SSE/WebSocket/WebTransport arasında bir karar matrisi çıkarmak veya managed servisten self-hosted kuruluma geçişin TCO’sunu hesaplamak istiyorsanız, iletişim sayfası üzerinden ulaşın; somut yük profilinizle birlikte hangi seçeneğin en iyi olduğunu yarım gün içinde netleştirebiliriz. MVP geliştirme sürecinde realtime özellik şart ise, doğru protokol seçimi 6 hafta içinde production’a çıkmayı katlayan en kritik mimari karardır.

Dış Otorite Kaynakları

• RFC 6455 — The WebSocket Protocol (IETF)
• RFC 9220 — Bootstrapping WebSockets with HTTP/3 (IETF)
• W3C WebTransport Specification
• MDN — Server-sent Events Documentation
• Cloudflare Radar — HTTP/3 Adoption Statistics
• Stack Overflow Developer Survey 2024
• ENISA Threat Landscape Report 2024