Gerçek zamanlı bir web özelliği planlanırken ekiplerin karşısına çoğu zaman iki seçenek çıkar: WebSocket ve Server-Sent Events. İkisi de sayfayı sürekli yenilemeden sunucudan yeni veri almayı sağlar; ancak aynı problemi aynı yöntemle çözmez. WebSocket, istemci ile sunucu arasında çift yönlü bir mesaj kanalı kurarken Server-Sent Events yalnızca sunucudan istemciye doğru sürekli bir olay akışı oluşturur.
Doğru seçim “hangisi daha modern?” sorusuyla değil, veri akışının yönüyle başlamalıdır. Kullanıcının aynı bağlantı üzerinden sık sık mesaj göndermesi gerekiyorsa WebSocket güçlü bir adaydır. İstemci standart HTTP istekleriyle işlem yapıyor, yalnızca sunucudan canlı güncellemeler alıyorsa SSE daha yalın bir çözüm olabilir.
Bu rehber WebSocket’ın temel çalışma mantığını yeniden anlatmak yerine iki yaklaşımı karar açısından karşılaştırır. Odak; iletişim yönü, yeniden bağlanma, veri biçimi, tarayıcı davranışı, altyapı uyumu, güvenlik ve ölçekleme farklarıdır.
WebSocket ve Server-Sent Events arasındaki temel fark nedir?
WebSocket bağlantısı açıldıktan sonra hem istemci hem sunucu mesaj başlatabilir. IETF’nin RFC 6455 standardı WebSocket’ı açılış el sıkışmasının ardından TCP üzerinde iki yönlü mesajlaşma sağlayan bir protokol olarak tanımlar IETF RFC 6455. Bu yapı sohbet, çok kullanıcılı etkileşim ve istemciden sunucuya sık mesaj gönderilen akışlar için uygundur.
Server-Sent Events ise EventSource arayüzü üzerinden sunucunun tarayıcıya olay göndermesini sağlar. WHATWG HTML standardında EventSource, sunucunun web sayfasına HTTP üzerinden veri itebilmesi için tanımlanmıştır WHATWG Server-Sent Events Standardı. İstemcinin sunucuya veri göndermesi gerektiğinde standart HTTP isteği veya ayrı bir API çağrısı kullanılır.
Kısa karşılaştırma tablosu
| Kriter | WebSocket | Server-Sent Events |
|---|---|---|
| İletişim yönü | İstemci ve sunucu arasında çift yönlü | Sunucudan istemciye tek yönlü |
| Bağlantı modeli | HTTP el sıkışmasından sonra WebSocket protokolü | Uzun süre açık tutulan HTTP yanıt akışı |
| Tarayıcı arayüzü | WebSocket | EventSource |
| Veri biçimi | Metin ve ikili mesajlar | UTF-8 tabanlı metin olay akışı |
| Yeniden bağlanma | Uygulama tarafından tasarlanır | EventSource tarafından yerleşik olarak denenir |
| Kaçırılan olayı sürdürme | Uygulamaya özel kimlik ve senkronizasyon gerekir | Olay kimliği ve Last-Event-ID kullanılabilir |
| Uygun örnek | Sohbet, ortak çalışma, etkileşimli sistem | Bildirim, işlem durumu, rapor veya log akışı |
| Operasyonel yapı | Çift yönlü mesaj ve bağlantı durumu yönetilir | HTTP akışı, tamponlama ve olay geçmişi yönetilir |
İletişim yönü seçimi nasıl belirler?
İletişim yönü bu karşılaştırmanın en önemli kriteridir. Bir destek sohbetinde kullanıcı mesaj gönderir, yazıyor durumu iletir ve sunucudan yeni mesaj alır. İki yön de sık ve olay tabanlı çalıştığı için WebSocket doğal bir seçenektir. Ortak belge düzenleme, canlı oyun ve cihaz kumandası gibi akışlarda da istemciden sunucuya sürekli olay gönderilir.
Bir sipariş takip ekranında ise kullanıcı çoğunlukla sayfayı açar ve durum değişikliklerini izler. Filtre değiştirmek veya işlem başlatmak için standart API çağrıları kullanılabilir; canlı durum güncellemeleri SSE üzerinden gelebilir. Bu model, istemciden sunucuya gerçek zamanlı bir mesaj kanalı gerektirmeden canlı deneyim sağlar.
Bir projede iki yöntemden yalnızca biri kullanılmak zorunda değildir. Standart işlemler API entegrasyonu üzerinden, sunucudan gelen olaylar SSE üzerinden yürütülebilir. Gerçek çift yönlü özellikler için ayrıca WebSocket kanalı eklenebilir.
Server-Sent Events bağlantısı nasıl çalışır?
Tarayıcı bir EventSource nesnesi oluşturarak sunucudaki olay akışı adresine bağlanır. Sunucu yanıtı text/event-stream içerik türüyle açık tutar ve olayları metin blokları halinde gönderir. MDN’nin SSE uygulama rehberi, sunucunun bu içerik türünü kullanması ve her bildirimi boş satırla ayrılan olay blokları şeklinde iletmesi gerektiğini açıklar MDN Server-Sent Events Kullanımı.
Akışta veri alanının yanında olay adı, olay kimliği ve yeniden deneme süresi gibi alanlar bulunabilir. İstemci adlandırılmış olayları ayrı dinleyebilir veya genel mesaj olayını işleyebilir. Bu yapı, özel bir mesaj çerçeveleme protokolü tasarlamadan sunucudan tarayıcıya düzenli olay iletmeyi kolaylaştırır.
SSE’nin yalın olması, sunucu tarafında hiçbir operasyon yükü bulunmadığı anlamına gelmez. Bağlantıların uzun süre açık kalması, proxy tamponlaması, zaman aşımı, kimlik doğrulama, kapasite ve kontrollü kapanış yine planlanmalıdır.
Yeniden bağlanma açısından hangisi daha kolaydır?
EventSource bağlantısı kesildiğinde tarayıcı varsayılan olarak yeniden bağlanmayı dener. Sunucu olay akışında retry alanı göndererek yeniden deneme süresini yönlendirebilir. Bağlantı tamamen kapatılmak isteniyorsa istemci EventSource bağlantısını açıkça kapatmalıdır. EventSource arayüzünün kalıcı HTTP bağlantısı açtığı resmî API tanımında belirtilir MDN EventSource.
WebSocket tarafında yeniden bağlanma davranışı uygulamaya bırakılır. Bağlantı kapandığında artan bekleme süresi, rastgele gecikme, maksimum deneme, çevrimdışı durum ve sunucu bakım senaryosu ayrıca kodlanmalıdır. Yeniden bağlanan istemcinin hangi mesajları kaçırdığı da uygulamaya özel bir senkronizasyon yöntemiyle çözülür.
SSE bu konuda daha fazla yerleşik davranış sunsa da iş mantığı yine düşünülmelidir. Aynı olayın tekrar gelmesi, olay sırasının değişmesi veya uzun kesinti sonrasında geçmiş verinin artık tutulmaması gibi durumlar istemci tarafından güvenli biçimde yönetilmelidir.
Last-Event-ID ne işe yarar?
SSE olaylarına kimlik verildiğinde tarayıcı son işlenen olay kimliğini takip edebilir. Bağlantı yeniden kurulurken Last-Event-ID bilgisi sunucuya iletilebilir; sunucu da mümkünse bu kimlikten sonraki olayları göndererek akışı sürdürebilir. WHATWG standardı olay kimliğinin işlenmesini ve Last-Event-ID başlığının kullanımını tanımlar WHATWG Server-Sent Events Standardı.
Bu mekanizma otomatik olarak kalıcı mesaj garantisi oluşturmaz. Sunucunun olay geçmişini tutması, kimlikleri anlamlı biçimde üretmesi ve belirli bir kimlikten devam edebilmesi gerekir. Kritik iş olayları yalnızca açık bağlantının belleğinde tutulmamalı; güvenilir veri veya olay deposunda saklanmalıdır.
WebSocket’ta benzer bir standart alan yoktur. Mesaj kimliği, onay, tekrar teslim, sıralama ve kaçırılan olayların geri alınması uygulama protokolünün parçası olarak tasarlanır.
Metin ve ikili veri açısından fark nedir?
WebSocket metin ve binary mesaj çerçevelerini destekler. Bu nedenle küçük ikili paketler, özel protokoller veya yoğun çift yönlü mesajlaşma gereken uygulamalarda daha esnek olabilir. WHATWG WebSockets standardı, web uygulamalarının sunucu süreçleriyle çift yönlü iletişim kurmasını sağlayan API davranışını tanımlar WHATWG WebSockets Standardı.
SSE olay akışı UTF-8 tabanlı metindir. JSON verisi taşımak için uygundur; ancak ham ikili içerik için doğal bir kanal değildir. Büyük dosya, medya veya binary veri akışı gerekiyorsa dosyanın ayrı HTTP adresinden alınması, verinin başka bir protokolle taşınması veya WebSocket kullanılması daha uygun olabilir.
İş uygulamalarındaki canlı bildirimler, durum değişiklikleri ve metin tabanlı loglar çoğunlukla JSON ile temsil edilebilir. Bu nedenle binary desteğinin bulunmaması tek başına SSE’yi elemek için yeterli değildir.
Tarayıcı desteği ve bağlantı sınırları nasıl değerlendirilmelidir?
WebSocket ve EventSource modern tarayıcı ekosisteminde uzun süredir kullanılan arayüzlerdir. Yine de hedef cihazlar, gömülü tarayıcılar, kurumsal ağlar ve eski istemciler proje özelinde test edilmelidir. Sadece masaüstü tarayıcıda çalışan bir prototip, gerçek müşteri ağıyla aynı sonucu vermeyebilir.
SSE’de HTTP/1.1 kullanılırken aynı tarayıcı ve alan adı için eş zamanlı açık bağlantı sınırları sorun oluşturabilir. MDN, HTTP/1.1 altında düşük bağlantı sınırına dikkat çeker; HTTP/2’de ise eş zamanlı akış sayısı taraflar arasında müzakere edilir MDN Server-Sent Events Kullanımı. Çok sekmeli uygulamalarda her bileşen için ayrı EventSource açmak yerine olayları tek bağlantıda birleştirmek daha sağlıklı olabilir.
WebSocket bağlantılarında da her kullanıcı, sekme veya özellik için kontrolsüz kanal açmak kaynak tüketimini artırır. Bağlantı sayısı, kullanıcı oturumu ve kanal abonelikleri mimarinin parçası olarak ölçülmelidir.
Proxy, CDN ve sunucu altyapısı bakımından hangisi daha kolaydır?
SSE standart HTTP yanıtı üzerinden çalıştığı için mevcut HTTP altyapılarıyla çoğu zaman daha doğal bütünleşir. Buna rağmen bazı reverse proxy veya uygulama sunucuları yanıtı tamponlayabilir; olayların istemciye anında ulaşması yerine birikmesine neden olabilir. Tamponlama, zaman aşımı ve sıkıştırma ayarları gerçek akış davranışıyla test edilmelidir.
WebSocket için ara katmanların bağlantı yükseltmesini ve uzun ömürlü bağlantıları desteklemesi gerekir. Yük dengeleyici, güvenlik duvarı, proxy ve barındırma hizmetinin WebSocket ayarları doğrulanmalıdır. Yanlış boşta kalma zaman aşımı değeri, aktif görünen uygulamada düzenli bağlantı kopmalarına neden olabilir.
Her iki yaklaşım da “sunucuda çalıştı” kontrolünden fazlasını gerektirir. Üretim ortamındaki CDN, WAF, reverse proxy ve ağ politikalarıyla uçtan uca test yapılmalıdır.
Kimlik doğrulama ve güvenlik farkları nelerdir?
SSE ve WebSocket bağlantısı uzun süre açık kaldığı için yalnızca ilk bağlantıda yapılan kontrol yeterli olmayabilir. Kullanıcının oturumu sona erdiğinde, rolü değiştiğinde veya erişimi kaldırıldığında açık bağlantının davranışı belirlenmelidir. Sunucu, yalnızca kullanıcının yetkili olduğu olayları göndermelidir.
Yerel EventSource arayüzü URL ve withCredentials seçeneği üzerinden bağlantı kurar; tarayıcı API’si keyfî istek başlığı eklemek için genel bir alan sunmaz. Bu yüzden kimlik doğrulama çoğunlukla güvenli oturum çerezleri, aynı origin yapısı veya kısa ömürlü imzalı bağlantı yaklaşımıyla tasarlanır. URL içine uzun ömürlü gizli anahtar koymak log ve geçmiş sızıntısı riski doğurabilir.
Tarayıcı WebSocket bağlantısında da kimlik, origin, oturum ve mesaj bazlı yetki kontrolü gerekir. WebSocket’ın çift yönlü olması, istemciden gelen her mesajın şema, boyut, hız ve işlem yetkisi açısından doğrulanmasını daha da önemli hale getirir.
Ölçekleme ve kaynak tüketimi açısından farklar
Her iki teknoloji de açık bağlantı tuttuğu için eş zamanlı bağlantı sayısı temel kapasite metriğidir. Ancak WebSocket sunucusu iki yönlü mesajları, oda veya kanal üyeliklerini ve istemciden gelen olayları yönetir. SSE sunucusu çoğunlukla olayları ilgili istemcilere dağıtır; istemci komutları ayrı HTTP istekleri üzerinden gelir.
Birden fazla sunucu örneğine geçildiğinde olayın doğru bağlantılara ulaşması için ortak mesaj dağıtım katmanı gerekebilir. Kullanıcının hangi sunucuya bağlı olduğu, hangi kanalları dinlediği ve bağlantı koptuğunda nasıl devam edeceği planlanmalıdır. Bu gereksinimler, gerçek zamanlı özelliklerin özel web yazılım altyapısı içinde ayrı bir mimari sorumluluk olarak ele alınmasını gerektirir.
Kaynak tüketimi yalnızca protokole bakılarak tahmin edilmemelidir. Mesaj sıklığı, mesaj boyutu, bağlantı süresi, kullanıcı başına kanal sayısı, yeniden bağlanma oranı ve sunucudaki işleme maliyeti birlikte ölçülmelidir.
WebSocket hangi senaryolarda daha doğru seçimdir?
- Sohbet: Mesaj, yazıyor bilgisi, okunma durumu ve çevrim içi varlık iki yönlü akar.
- Ortak çalışma: Kullanıcının düzenlemeleri ve imleç hareketleri sunucuya sürekli gönderilir.
- Çok oyunculu veya etkileşimli sistem: İstemci eylemleri düşük gecikmeyle sunucuya ulaşmalıdır.
- Canlı cihaz kontrolü: Durum sunucudan gelirken komutlar aynı kanal üzerinden geri gönderilir.
- Özel mesaj protokolü: Metin ve binary mesajların iki yönde sürekli taşınması gerekir.
Bu senaryolarda WebSocket’ın çift yönlü yapısı gereksiz bir özellik değil, ürünün temel iletişim modelidir. Yine de mesaj sözleşmesi, yeniden bağlanma, onay ve senkronizasyon tasarımı ayrıca yapılmalıdır.
Server-Sent Events hangi senaryolarda daha doğru seçimdir?
- Canlı bildirimler: Kullanıcının açık ekranına yeni uyarı ve durum bilgisi gönderilir.
- İşlem ilerleme ekranı: Rapor oluşturma, dosya işleme veya toplu aktarım aşamaları yayınlanır.
- Operasyon paneli: Sipariş, görev veya sistem durumu sunucudan düzenli olarak güncellenir.
- Metin üretim akışı: Sunucunun ürettiği metin parçaları tarayıcıya sırayla aktarılır.
- Log ve olay akışı: Yönetim ekranına metin tabanlı olaylar iletilir.
İstemci eylemleri standart HTTP çağrılarıyla rahatça yürütülebiliyorsa SSE, iki yönlü özel protokol kurmadan canlı deneyim sağlayabilir. Bu yaklaşım özellikle mevcut yazılım geliştirme altyapısına tek yönlü güncelleme kanalı eklenirken değerlidir.
Hibrit mimari kullanılabilir mi?
Evet. Bir yönetim panelinde kayıt oluşturma, güncelleme ve silme işlemleri REST API üzerinden yürütülürken değişiklik bildirimleri SSE ile yayınlanabilir. Kullanıcı bir işlem başlattığında standart POST isteği gönderir; sunucu işlemin aşamalarını aynı kullanıcının SSE kanalına aktarır.
Başka bir modülde sohbet veya ortak çalışma gerektiğinde WebSocket kullanılabilir. Böylece tüm ürün tek protokole zorlanmaz. Her akış için en düşük karmaşıklıkla gereksinimi karşılayan yöntem seçilir.
Hibrit yapı protokol sayısını artırdığı için isimlendirme, kimlik doğrulama, gözlemlenebilirlik ve hata yönetimi ortak standartlara bağlanmalıdır. Aksi halde aynı iş olayı farklı kanallarda birbirinden kopuk davranabilir.
Yanlış seçim belirtileri nelerdir?
- Yalnızca sunucudan güncelleme alınmasına rağmen karmaşık WebSocket protokolü kurulması.
- İstemcinin sık komut göndermesi gerekirken SSE yanında sürekli HTTP isteği üretilmesi.
- Bağlantı koptuğunda kaçırılan olayların nasıl alınacağının belli olmaması.
- Her tarayıcı sekmesinin ve bileşenin ayrı bağlantı açması.
- Proxy tamponlaması veya zaman aşımı nedeniyle canlı güncellemelerin gecikmesi.
- Kritik iş durumunun yalnızca geçici mesaj akışında tutulması.
- Kimlik doğrulamanın bağlantı açıldıktan sonra hiç yeniden değerlendirilmemesi.
Karar vermeden önce sorulması gerekenler
- Veri yalnızca sunucudan mı gelecek, yoksa istemci de aynı kanalda sık mesaj gönderecek mi?
- Mesajlar metin tabanlı mı, binary veri gerekiyor mu?
- Bağlantı koptuğunda otomatik yeniden bağlanma ve kaldığı yerden devam ihtiyacı nedir?
- Standart HTTP API istemciden sunucuya işlemler için yeterli mi?
- Hedef tarayıcılar, mobil webview’lar ve kurumsal ağlar iki yöntemi nasıl destekliyor?
- Proxy, CDN ve yük dengeleyici uzun süre açık bağlantılara uygun mu?
- Mesaj hacmi ve eş zamanlı bağlantı sayısı ne kadar?
- Olay geçmişi nerede tutulacak ve tekrar teslim nasıl yönetilecek?
- Kimlik doğrulama, origin ve mesaj bazlı yetkilendirme nasıl uygulanacak?
- Bağlantı sayısı, gecikme, yeniden bağlanma ve hata oranı nasıl izlenecek?
Sonuç: İletişim yönü, teknoloji tercihinden önce gelir
WebSocket ve Server-Sent Events aynı kategori içinde görünse de farklı iletişim ihtiyaçlarını çözer. WebSocket gerçek çift yönlü mesajlaşma için esneklik sunar. SSE ise standart HTTP üzerinden sunucudan istemciye olay akışı, yerleşik yeniden bağlanma ve olay kimliği mekanizmalarıyla birçok canlı güncelleme senaryosunu daha yalın biçimde karşılayabilir.
Doğru yaklaşım, ürünün bütününü tek protokole zorlamak değildir. İstemci komutları standart API çağrılarıyla yürüyebiliyorsa ve yalnızca sunucudan güncelleme gerekiyorsa SSE güçlü bir adaydır. İki tarafın da düşük gecikmeyle sürekli mesaj başlatması gerekiyorsa WebSocket daha uygun olur. Kritik veriler ise hangi kanal kullanılırsa kullanılsın kalıcı veri katmanında güvenceye alınmalıdır.
Sıkça Sorulan Sorular
WebSocket mı SSE mi daha hızlıdır?
Tek başına protokol adı kesin bir hız sonucu vermez. Gecikme; ağ, sunucu, mesaj sıklığı ve uygulama tasarımına bağlıdır. İki yönlü yoğun mesajlaşmada WebSocket, yalnızca sunucudan gelen metin güncellemelerinde ise SSE daha uygun ve yalın olabilir.
Server-Sent Events ile istemciden sunucuya veri gönderilebilir mi?
EventSource kanalı yalnızca sunucudan istemciye veri taşır. İstemci, sunucuya veri göndermek için fetch, form gönderimi veya başka bir HTTP API çağrısı kullanabilir.
SSE bağlantısı koptuğunda otomatik olarak yeniden bağlanır mı?
EventSource varsayılan olarak yeniden bağlanmayı dener. Sunucu retry alanıyla bekleme süresini yönlendirebilir; olay kimlikleri kullanılıyorsa Last-Event-ID ile kaldığı yerden devam etmeye yönelik bir sistem kurulabilir.
WebSocket binary veri gönderebilir mi?
Evet. WebSocket metin ve binary mesajları destekler. SSE ise UTF-8 tabanlı metin olay akışıdır; ham binary veri için doğal bir taşıma kanalı değildir.
Aynı projede WebSocket ve SSE birlikte kullanılabilir mi?
Evet. Örneğin operasyon bildirimleri SSE, sohbet veya ortak çalışma bölümü WebSocket, standart kayıt işlemleri ise HTTP API üzerinden yürütülebilir.
SSE her zaman WebSocket’tan daha kolay mıdır?
Hayır. Tek yönlü metin akışında genellikle daha yalındır; ancak açık bağlantılar, proxy tamponlaması, zaman aşımı, yetkilendirme, ölçekleme ve olay geçmişi yine doğru biçimde planlanmalıdır.
