WebSocket Nedir? Gerçek Zamanlı İletişim Nasıl Çalışır?

WebSocket nedir?

WebSocket, tarayıcı ile sunucu arasında tek bir bağlantı üzerinden iki yönlü ve sürekli açık iletişim kurmanızı sağlayan bir ağ protokolüdür. Bağlantı bir kez açıldıktan sonra istemci de sunucu da istediği anda mesaj gönderebilir, yani her bilgi için yeni bir istek başlatmanız gerekmez.

Bunu bir mektup ile telefon görüşmesi arasındaki fark gibi düşünün. HTTP'de siz bir mektup yazarsınız, karşı taraf cevap yazar ve zarf kapanır. WebSocket'te ise telefonu bir kez açarsınız; hat açık kaldığı sürece iki taraf da istediği zaman konuşabilir.

Bu yazıda yalnızca bu terime, yani WebSocket nedir sorusuna odaklanıyoruz: nasıl başladığını, ne işe yaradığını, nerede zorlandığını ve ne zaman hiç gerekmediğini anlatıyoruz. Komşu konular için ilgili yazılarımıza kısa bağlantılar veriyoruz. Hem yeni başlayan hem deneyimli geliştirici, ihtiyacı olan bölümü doğrudan bulabilsin diye başlıkları soru biçiminde yazdık.

WebSocket nedir ve HTTP tek başına neden yetmez?

HTTP, soru ve cevap düzeniyle çalışır. İstemci bir istek gönderir, sunucu bir yanıt döndürür ve konuşma biter. Sunucu kendiliğinden istemciye "yeni bir şey oldu" diyemez; önce istemcinin sorması gerekir.

Bu düzen sayfa açmak, form göndermek ya da bir ürün listesini çekmek için çok uygundur. Ancak canlı sohbet, anlık bildirim ya da canlı skor gibi durumlarda sorun çıkar. Çünkü bilginin ne zaman değişeceğini önceden bilemezsiniz.

Bu açığı kapatmak için geliştiriciler yıllarca yoklama (polling) yöntemini kullandı. İstemci birkaç saniyede bir "yeni mesaj var mı?" diye sorar. Çoğu cevap "hayır" olur ve her soru yeni bir HTTP isteği demektir.

WebSocket nedir sorusuna geçmeden önce yoklamanın bedelini görmek gerekir. Sonuçta hem gereksiz trafik hem de gecikme ortaya çıkar. Soru sıklığını artırırsanız gecikme azalır ama sunucu yükü büyür. Azaltırsanız yük düşer ama kullanıcı bekler. WebSocket, bu ikilemi çözmek için ortaya çıktı: sunucu, söyleyecek bir şey olduğunda hemen konuşur.

WebSocket nasıl başlar: HTTP el sıkışması ve protokol yükseltme nedir?

WebSocket bağlantısı sıradan bir HTTP isteğiyle başlar. Tarayıcı sunucuya, bu bağlantıyı WebSocket protokolüne yükseltmek istediğini söyleyen özel başlıklar içeren bir istek gönderir. Bu aşamaya el sıkışma (handshake) denir.

Sunucu isteği kabul ederse "101 Switching Protocols" durum koduyla yanıt verir. Bu yanıttan sonra aynı TCP bağlantısı artık HTTP konuşmaz; WebSocket çerçeveleri taşır. IETF'nin RFC 6455 belgesi bu akışı ayrıntılı tanımlar.

Kavramsal olarak akış şöyle ilerler:

1. Tarayıcı, ws ya da wss ile başlayan bir adrese bağlanmak ister.
2. Normal bir HTTP isteği gider; içinde yükseltme talebi ile rastgele üreteceğiniz bir anahtar yer alır.
3. Sunucu, bu anahtardan türettiği bir doğrulama değeriyle 101 yanıtı döndürür.
4. İstemci doğrulama değerini kontrol eder ve bağlantıyı açık sayar.
5. Bu andan sonra iki taraf da çerçeve (frame) halinde mesaj gönderir.

Başlangıcın HTTP olması önemli bir avantajdır. Mevcut portlar, proxy yapıları ve altyapı bu başlangıcı tanıdığı için WebSocket çoğu ağdan geçebilir. Ayrıca doğrulama değeri, sunucunun gerçekten WebSocket konuştuğunu kanıtlar; rastgele bir HTTP sunucusu yanlışlıkla bağlantıyı kabul etmiş olmaz.

WebSocket nedir sorusunun teknik yanıtı: bağlantı açıldıktan sonra mesajlar nasıl akar?

El sıkışma bittiğinde veri artık çerçevelerle akar. Çerçeve, WebSocket'in en küçük iletişim birimidir. Bir mesaj tek çerçeveden oluşabilir ya da parçalara bölünebilir. Bu sayede büyük bir mesajı beklemeden küçük parçalar halinde göndermeniz mümkün olur.

Mesajlar iki türde olur: metin ve ikili (binary). Metin mesajları çoğunlukla JSON gibi biçimleri taşır. İkili mesajlar ise ses, görüntü parçası ya da sıkıştırdığınız veri için uygundur.

Protokol ayrıca üç tür kontrol çerçevesi tanımlar:

• Ping çerçevesi, karşı tarafın hâlâ canlı olup olmadığını yoklar.
• Pong çerçevesi, ping'e verilen otomatik yanıttır.
• Kapatma (close) çerçevesi, bağlantıyı nazikçe bitirir ve bir kapanış nedeni taşıyabilir.

Ping ve pong, özellikle sessiz kalan bağlantılar için işe yarar. Araya giren bir proxy ya da güvenlik duvarı uzun süre veri görmezse bağlantıyı sessizce kesebilir. Düzenli bir ping bunu önler.

WebSocket mesajları için hangi biçimi ve alt protokolü seçersiniz?

WebSocket yalnızca bir taşıma kanalıdır; mesajın içinde ne yazacağını söylemez. Bu boşluğu sizin doldurmanız gerekir. Çoğu ekip metin mesajı olarak JSON seçer, çünkü okunması ve hata ayıklaması kolaydır.

Protokol, el sıkışma sırasında bir alt protokol (subprotocol) adı üzerinde anlaşmaya da izin verir. İstemci desteklediği adları sıralar, sunucu birini seçer. Böylece iki taraf, bu kanaldan hangi mesaj dilinin konuşulacağını baştan bilir.

Mesaj tasarımında şu alışkanlıklar işinizi kolaylaştırır:

• Her mesaja bir tür (örneğin "sipariş oluştu") ve bir sürüm numarası koyun.
• Mesaj gövdesini küçük tutun; yalnızca değişen alanları gönderin.
• İstemciden gelen her mesajı sunucuda şemaya göre doğrulayın.
• Bilinmeyen mesaj türlerini sessizce yok sayın; böylece eski istemciler yeni sunucuyla çalışmaya devam eder.

Sıkı bir mesaj sözleşmesi, ekipler farklı hızlarda yayın yaptığında en çok işe yarar.

WebSocket nedir sorusunun pratik yanıtı: hangi uygulamalarda kullanırsınız?

WebSocket, bilginin ne zaman geleceğini bilmediğiniz ve gecikmenin kullanıcı deneyimini bozduğu yerlerde parlar. Ortak özellik, sunucudan istemciye sık ve beklenmedik veri akışıdır.

Tipik kullanım alanlarını şöyle sıralayabiliriz:

• Canlı sohbet ve müşteri destek pencereleri; mesajın anında karşıya düşmesi gerekir.
• Anlık bildirimler; yeni sipariş, onay ya da uyarı kullanıcıya hemen ulaşır.
• Canlı skor ve takip ekranları; sonuçlar değiştiği anda herkes aynı veriyi görür.
• Ortak çalışma araçları; birden fazla kişi aynı belge ya da tahta üzerinde çalışır.
• Yönetim panoları; stok, sipariş ya da sistem durumu yenileme düğmesine basmadan değişir.
• Çok oyunculu oyunlar ve etkileşimli canlı yayınlar.

WebSocket nedir sorusunu somutlaştıran bu listedeki her örnekte iki yönlü akış ya da çok sık güncelleme vardır. Eğer verinizi günde birkaç kez çekiyorsanız, aşağıda anlatacağımız gibi daha basit seçenekler yeterli olabilir.

WebSocket, HTTP yoklama, uzun yoklama ve SSE arasındaki fark nedir?

Gerçek zamanlı iletişim için dört yaygın yaklaşım vardır. Her biri farklı bir denge kurar; bu yüzden "hangisi en iyisi" sorusu yerine "hangisi sizin işinize uyar" sorusunu sormak daha doğrudur.

Tablodan çıkan sonuç, WebSocket nedir sorusunun cevabını da tamamlar: yön ve sıklık ihtiyacınız seçimi belirler. İki yönlü ve sık veri varsa WebSocket öne çıkar. Yalnızca sunucudan haber akıyorsa SSE çoğu zaman yeterlidir.

Server-Sent Events ne zaman WebSocket'ten daha uygundur?

Server-Sent Events, tarayıcının EventSource arayüzüyle kullandığı, sunucudan istemciye tek yönlü bir akıştır. MDN belgelerine göre bağlantı koparsa tarayıcı kendiliğinden yeniden bağlanmayı dener. Bu davranış size hazır gelir.

Bir borsa tablosu, haber akışı ya da bir işlemin ilerleme çubuğu düşünün. Bu örneklerde istemci sunucuya sık veri göndermez, yalnızca dinler. SSE düz HTTP üzerinde çalıştığı için proxy ve güvenlik duvarı uyumu da genellikle kolaydır.

Öte yandan SSE'nin sınırları vardır. Yalnızca sunucudan istemciye gider, istemci tarafı veri için ayrı bir HTTP isteği gerekir. Ayrıca ikili veri taşımaz. Bu yüzden sohbet, ortak düzenleme ya da oyun gibi iki yönlü senaryolarda WebSocket daha doğal bir tercihtir.

Kısacası ilk soru şudur: istemci de sık sık konuşuyor mu? Cevap hayırsa önce SSE'yi değerlendirmenizi öneririz. Cevap evetse WebSocket nedir sorusunun cevabı sizin için artık bir ihtiyaçtır.

Örnek senaryo: canlı sipariş panosu WebSocket ile nasıl çalışır?

Küçük bir restoran zincirinin mutfak ekranını düşünelim. Bu bir örnek senaryodur; gerçek bir müşteriye ait değildir. Garsonlar tabletten sipariş girer, mutfak ekranı siparişi anında göstermelidir.

Yoklama yöntemiyle ekran birkaç saniyede bir sunucuya sorar. Sipariş tam sorgudan hemen sonra gelirse mutfak bir sonraki sorguyu bekler. Yoğun saatte bu bekleyiş artık gözünüze batar.

WebSocket ile ise mutfak ekranı açılışta bir bağlantı kurar ve açık tutar. Garson siparişi gönderdiğinde sunucu bu bağlantılara anında bir "yeni sipariş" mesajı yollar. Mutfak "hazır" mesajını geri gönderdiğinde garsonun tableti bunu hemen gösterir.

Burada iki yönlü akış kritiktir, çünkü mutfaktan garsona da haber gitmesi gerekir. Aynı kanal hem siparişi hem durum değişikliğini taşır. Ayrıca sunucu hangi ekranın bağlı olduğunu bildiği için, bağlantısı kopan bir ekranı fark edip personele uyarı verebilir.

Bu senaryoda bile her şeyi WebSocket'e yüklemezsiniz. Menü listesi ya da geçmiş sipariş raporu gibi sık değişmeyen veriyi normal HTTP ile çekmek daha sade kalır.

WebSocket ölçeklenirken hangi sorunlar ortaya çıkar?

WebSocket'in en büyük bedeli, bağlantıların uzun süre açık kalmasıdır. Klasik HTTP'de sunucu bir isteği işler ve kaynağı hemen bırakır. WebSocket'te her bağlı kullanıcı sunucuda bellek ve bir bağlantı yuvası tutar.

Bu yüzden iki ayrı yük düşünmelisiniz: mesaj hızı ve eşzamanlı bağlantı sayısı. Çok az mesaj gönderen ama çok sayıda açık bağlantı tutan bir sistem, farklı kaynakları tüketir.

Sık karşılaşılan zorluklar şunlardır:

• Bağlantı durumu sunucuda yaşadığı için sunucu değiştiğinde bağlantı koparsa durum da gider.
• Bir kullanıcının bağlı olduğu sunucu ile mesajı üreten sunucu farklı olabilir.
• Yavaş bir istemci, mesaj kuyruğunu şişirip sunucu belleğini zorlayabilir.
• Yeni sürüm yayınlarken tüm bağlantılar aynı anda kopar ve hepsi birden yeniden bağlanmaya çalışır.

Son madde özellikle önemlidir. Yeniden bağlanma dalgası sunucuyu kendi kullanıcılarıyla boğabilir. Bu nedenle ölçekleme planını ilk günden düşünmeniz gerekir.

Yavaş istemciler ve geri basınç WebSocket sunucusunu nasıl etkiler?

Sunucu mesajı hızlı üretip istemci yavaş tüketirse aradaki fark bir kuyrukta birikir. Bu duruma geri basınç (backpressure) sorunu denir. MDN, tarayıcı WebSocket arayüzünün geri basınç denetimi sunmadığını belirtir.

Sunucu tarafında bu birikimi görmezden gelirseniz bellek yavaş yavaş dolar. Tek bir takılı istemci bile bir süre sonra tüm süreci zora sokabilir. Bu nedenle her bağlantı için bir tampon sınırı belirlemeniz gerekir.

Kullanabileceğiniz önlemler şunlardır:

• Her bağlantının bekleyen mesaj kuyruğuna üst sınır koyun.
• Sınır aşılınca eski ara değerleri atın; canlı skor gibi akışlarda yalnızca son değer önemlidir.
• Çok yavaş kalan bağlantıyı kapatın ve istemcinin yeniden bağlanmasına izin verin.
• Sık değişen veriyi birleştirip daha seyrek gönderin.

Hangi mesajın atılabileceğine, hangisinin mutlaka ulaşması gerektiğine iş kuralları karar verir. Bunu önceden netleştirmek tasarımı sadeleştirir.

Yük dengeleyici ve mesaj aracısı WebSocket mimarisinde ne işe yarar?

Yük dengeleyici, gelen bağlantıları birden fazla sunucuya dağıtır. WebSocket için dikkat edeceğiniz nokta, dengeleyicinin yükseltme isteğini ve uzun ömürlü bağlantıları desteklemesidir. Boşta kalma süresi ayarı kısa kalırsa bağlantılar beklenmedik biçimde kopar. Genel mantığı yük dengeleyici rehberimizde anlattık.

İkinci sorun, sunucular arası haberleşmedir. A sunucusuna bağlı bir kullanıcının mesajı, B sunucusundaki kullanıcıya nasıl gider? Çözüm genellikle bir mesaj aracısı (message broker) kullanmaktır.

Aracı, bir yayın ve abonelik düzeni sağlar. Her WebSocket sunucusu aracıya abone olur. Mesaj geldiğinde aracı onu tüm ilgili sunuculara dağıtır; her sunucu da kendi bağlı istemcilerine iletir.

Bu desen, olay güdümlü mimarinin küçük bir uygulamasıdır. Kavramın tamamını olay güdümlü mimari yazımızda bulabilirsiniz. Mikroservis tarafında hangi bileşenin hangi bağlantıyı tuttuğunu planlamak için mikroservis mimarisi yazımız da yol gösterir.

Ağın ortasındaki her katman bağlantıyı etkileyebilir. Ters proxy, içerik dağıtım ağı ve güvenlik duvarı gibi bileşenler uzun ömürlü bağlantıya göre ayarlı olmayabilir. Sorun yaşarsanız önce uygulamayı değil, yolun üzerindeki katmanları kontrol edin ve her birinin yükseltme isteğini geçirdiğinden emin olun.

WebSocket nedir sorusunun güvenlik boyutu: ws ile wss farkı nedir?

ws, korumasız WebSocket bağlantısıdır. wss ise TLS ile koruduğunuz olanıdır; tıpkı http ile https arasındaki ilişki gibi. Canlı ortamda her zaman wss kullanmanızı öneririz.

Şifresiz bağlantıda araya giren biri mesajları okuyabilir ya da değiştirebilir. Ayrıca bazı proxy yapıları şifresiz WebSocket trafiğini bozabilir. Şifreli bağlantı bu sorunları büyük ölçüde azaltır.

Sertifikanızın geçerli ve zincirinin eksiksiz olduğunu SSL sorgulama aracımızla kontrol edebilirsiniz. Bir sayfa https ile açılıyorsa, tarayıcılar çoğunlukla şifresiz ws bağlantısını da engeller; bu davranış karışık içerik kuralından gelir.

Unutmayın: wss yalnızca taşıma katmanını korur. Kimin bağlanabileceği, hangi mesajı gönderebileceği gibi sorular ayrı bir uygulama katmanı tasarımı ister.

WebSocket bağlantısında kaynak kontrolü neden gerekir?

Tarayıcı bir WebSocket el sıkışması başlattığında isteğe, sayfanın geldiği kaynağı belirten bir Origin başlığı ekler. RFC 6455 sunucunun bu başlığa bakıp istemediği kaynakları reddedebileceğini söyler.

Bu kontrol neden önemli? WebSocket, tarayıcının aynı kaynak politikasına bağlı kalmadan çalıştığı için başka bir sitedeki sayfa, kullanıcının tarayıcısından sizin sunucunuza bağlanmayı deneyebilir. Kimlik doğrulama yalnızca çerezde duruyorsa, kullanıcının oturumu kendi bilgisi dışında kullanılabilir. Bu riske siteler arası WebSocket ele geçirme adını veriyoruz.

Savunma yaklaşımı basittir:

• İzin verdiğiniz kaynakların açık bir listesini tutun.
• Listede olmayan kaynaktan gelen el sıkışmayı reddedin.
• Çerezle oturum kullanıyorsanız ek bir doğrulama değeri isteyin.

Origin başlığı tarayıcılar için güvenilirdir, ancak tarayıcı dışı bir istemci onu istediği gibi yazabilir. Bu nedenle tek başına yeterli değildir; kimlik doğrulama ile birlikte düşünün.

WebSocket bağlantısında kimlik doğrulamayı nasıl kurarsınız?

Tarayıcıdaki WebSocket arayüzü, el sıkışma sırasında istediğiniz özel başlıkları (örneğin Authorization) göndermenize izin vermez. Bu kısıt, kimlik doğrulama tasarımını etkiler. MDN belgeleri de bu sınırı vurgular.

Yaygın yaklaşımlar şunlardır:

• Aynı alan adındaki oturum çerezine güvenmek ve Origin kontrolüyle desteklemek.
• Önce normal bir HTTP çağrısıyla kısa ömürlü, tek kullanımlık bir bilet almak, sonra bağlanırken bu bileti sunmak.
• Bağlantı açıldıktan sonraki ilk mesajda kimliği doğrulamak ve doğrulayamadığınız bağlantıyı kapatmak.

Token kullanıyorsanız adresin içine uzun ömürlü bir anahtar yazmaktan kaçının; adresler günlüklerde ve proxy kayıtlarında kalabilir. Token yapısını ve imza mantığını JWT yazımızda kavramsal olarak anlattık.

Bir de yetkilendirme vardır. Bağlantı açık diye her kanala abone olmaya izin vermeyin; her abonelikte "bu kullanıcı bu kanalı görebilir mi?" sorusunu sunucuda yeniden sorun.

Bağlantı koptuğunda yeniden bağlanmayı nasıl tasarlarsınız?

Gerçek ağlar kopar. Telefon tünele girer, kullanıcı Wi-Fi'dan mobil veriye geçer, sunucu yeniden başlar. Tarayıcı WebSocket arayüzü, SSE'nin aksine kendiliğinden yeniden bağlantı denemez; bu mantığı sizin yazmanız gerekir.

İyi bir yeniden bağlanma tasarımı birkaç parçadan oluşur:

1. Bekleme süresini her denemede artırın; buna üstel geri çekilme denir.
2. Bekleme süresine küçük bir rastgelelik ekleyin ki tüm istemciler aynı anda dönmesin.
3. Bağlantı geri geldiğinde kaçırdığınız mesajları nasıl alacağınızı belirleyin, örneğin son görülen mesaj numarasıyla.
4. Kullanıcıya bağlantı durumunu dürüstçe gösterin.

Kaçırılan mesaj konusunu çoğu ekip atlar. WebSocket mesajı teslim edeceğini garanti etmez; bağlantı kopmuşsa mesaj kaybolabilir. Önemli verilerde sunucu tarafında kalıcı bir kayıt tutmak, istemcinin de kaldığı yerden devam etmesini sağlar.

WebSocket bağlantılarını nasıl izler ve ölçersiniz?

Açık bağlantılar gözünüzün önünde durmadığı için sorunlar geç ortaya çıkar. Bu yüzden WebSocket sistemlerinde izleme, normal bir API'den daha da önemlidir. Birkaç temel ölçüm çoğu sorunu erken gösterir.

• Anlık açık bağlantı sayısı; ani düşüşler toplu kopmaya, sürekli artış sızıntıya işaret eder.
• Saniyedeki bağlanma ve kopma sayısı; yeniden bağlanma dalgalarını yakalar.
• Kapanış nedenleri; ağ kopması ile sunucu kararı aynı şey değildir.
• Mesaj gecikmesi; mesajın üretilmesi ile istemciye ulaşması arasındaki süre.
• Bağlantı başına kuyruk boyu; yavaş istemcileri ortaya çıkarır.

Bu ölçümleri günlük, metrik ve iz kayıtlarıyla birleştirmek istiyorsanız gözlemlenebilirlik yazımızdaki yaklaşım işinize yarar. Ayrıca ağ gecikmesinin temelini ping ve gecikme yazımızda bulabilirsiniz.

WebSocket tarayıcı dışında da kullanılır mı?

Evet. RFC 6455, protokolü web sayfalarındaki betikler için tasarladığını söyler; ancak aynı protokolü herhangi bir istemci konuşabilir. Mobil uygulamalar, masaüstü programlar ve sunucudan sunucuya bağlantılar bunun örnekleridir.

Örneğin bir mobil uygulama, kullanıcıya gelen mesajı anında göstermek için sunucuyla açık bir WebSocket bağlantısı tutabilir. Bir izleme servisi de başka bir servisten gelen olay akışını bu yolla dinleyebilir. Böylece tarayıcı dışındaki istemciler de aynı mesajlaşma modelini kullanır.

Fakat bir fark var: tarayıcı dışı istemcilerde Origin başlığı güvenilir bir kimlik sayılmaz, çünkü istemci onu istediği gibi yazabilir. Üstelik bu istemciler özel başlık gönderebildiği için kimlik doğrulamayı başlıklarla kurmak mümkündür. Her istemci türü için tehdit modelini ayrı düşünmeniz gerekir.

Mobil tarafta ağ geçişleri sık olduğu için yeniden bağlanma mantığı daha da kritik hale gelir. Pil tüketimini de unutmayın; sürekli açık bir bağlantı, düzensiz kullanılan bir uygulama için gereksiz olabilir.

Kanal ve oda mantığı WebSocket mesajlarını nasıl yönlendirir?

WebSocket protokolü, mesajın kime gideceğini bilmez. Bir bağlantıya yazdığınız veri yalnızca o bağlantıya gider. "Bu siparişi sadece o şubenin ekranlarına gönder" gibi kuralları uygulama katmanında siz kurarsınız.

Bunun için kanal ya da oda kavramına başvurursunuz. Her bağlantı, ilgilendiği kanallara abone olur. Örneğin bir şube numarası, bir sohbet odası ya da bir belge kimliği kanal adı olabilir. Mesaj bir kanala yazılınca sunucu yalnızca o kanalın abonelerine dağıtır.

Bu yaklaşımın üç faydası vardır:

• Kullanıcı yalnızca ilgili veriyi alır, böylece ağ yükü azalır.
• Yetki kontrolünü tek bir yerde, aboneliğin başlangıcında yaparsınız.
• Mesaj aracısıyla birleştiğinde, kanal adı sunucular arası dağıtımın anahtarı olur.

Kanal adlarını tahmin edilemez tutmak tek başına güvenlik sağlamaz. Yetki kontrolünü her zaman sunucuda yapın.

Gerçek zamanlı bir özelliği nasıl test edersiniz?

Yerel makinede birkaç sekmeyle çalışan bir sohbet, canlı ortamda aynı şekilde davranmayabilir. Bu yüzden testleri gerçek koşullara yaklaştırmanız gerekir. Yalnızca "mesaj ulaştı mı" sorusu yeterli değildir.

Planınıza şu senaryoları ekleyin:

1. Bağlantıyı bilerek kesin ve istemcinin yeniden bağlanıp kaçırdığı mesajları aldığını doğrulayın.
2. Çok sayıda istemciyi aynı anda bağlayarak sunucunun bellek ve işlemci davranışına bakın.
3. Yavaş bir ağı taklit edin ve kuyruk sınırının işlediğini görün.
4. Sunucuyu yeniden başlatın ve tüm istemcilerin kademeli döndüğünü kontrol edin.
5. Yetkisiz kullanıcının başka bir kanala abone olamadığını deneyin.

WebSocket nedir sorusunu ekibinize anlatmak kolaydır, ama davranışını görmek için bu denemeleri canlıya çıkmadan önce ayrı bir test ortamında yapın. Ayrıca sonuçları not edin; gelecekte ölçekleme kararı verirken elinizde somut veri olur.

WebSocket ne zaman gereksizdir?

Her gerçek zamanlı görünen ihtiyaç WebSocket istemez. Altyapıyı karmaşıklaştırmadan önce şu soruları sorun: veri gerçekten saniyeler içinde değişmeli mi, kullanıcı bunu fark eder mi?

Şu durumlarda daha basit çözümler çoğu zaman yeterlidir:

• Veri dakikada bir ya da daha seyrek değişiyorsa düzenli yoklama yeterlidir.
• Yalnızca sunucudan istemciye akış varsa SSE daha hafif olabilir.
• Kullanıcı sayfayı zaten sık yeniliyorsa ek bir kanal gereksizdir.
• Önbelleğe alabildiğiniz, herkese aynı görünen içerik için klasik HTTP daha ucuzdur.

Önbellekleme mantığı için önbellekleme yazımıza bakabilirsiniz. Ayrıca sunucusuz altyapılarda uzun ömürlü bağlantı tutmak zor olabilir; ayrıntılar için serverless yazımızı okuyun.

Basit olan çoğu zaman daha dayanıklıdır. Gerekçesi net olmayan bir WebSocket, yalnızca bakım yükü ekler.

WebSocket projelerinde sık yapılan hatalar nelerdir?

Ekiplerin en sık düştüğü hatalar teknik değil, tasarım hatalarıdır. Birkaçını tanımak size iyi bir başlangıç noktası verir.

• Her şeyi WebSocket üzerinden geçirmek. Oturum açma, dosya yükleme gibi işler normal HTTP ile daha rahat yürür.
• Mesajlara şema ve sürüm koymamak. İstemci ve sunucu ayrı hızlarda ilerleyince eski mesajlar anlam kaybeder.
• Bağlantı sayısını izlememek. Açık bağlantılar sessizce birikir ve bir gün sınıra dayanır.
• Her olayı herkese yayınlamak. Kullanıcıya yalnızca ilgili kanalın mesajını gönderin.
• Hata ve kapanış nedenlerini kaydetmemek. Kopmaların sebebini bilmezseniz iyileştirme yapamazsınız.
• İstemci girdisine güvenmek. Gelen her mesajı sunucuda doğrulayın.

WebSocket nedir sorusunu yüzeysel yanıtlayan ekipler, onu sihirli bir hız düğmesi sanar; hataların ortak noktası budur. Oysa bağlantı yönetimi, güvenlik ve ölçekleme sorumluluğu sizde kalır.

WebSocket nedir sorusunu proje kararına çevirirken kontrol listesi nedir?

Aşağıdaki liste, bir gerçek zamanlı özellik planlarken sorabileceğiniz soruları toplar. Hepsine "evet" demeniz gerekmez; amaç, atladığınız noktayı görmektir.

• Veri akışı iki yönlü mü, yoksa yalnızca sunucudan mı geliyor?
• Güncelleme sıklığı saniyeler mertebesinde mi?
• Canlı ortamda wss kullanıyor musunuz?
• İzin verdiğiniz kaynak listesini sunucuda kontrol ediyor musunuz?
• Kimlik doğrulama ve kanal yetkilendirmesi tanımlı mı?
• Yeniden bağlanma ve kaçırılan mesajları alma mantığı var mı?
• Yük dengeleyici yükseltme isteklerini ve uzun bağlantıları destekliyor mu?
• Birden çok sunucu varsa mesaj aracısını planladınız mı?
• Bağlantı sayısını, kopmayı ve gecikmeyi ölçüyor musunuz?
• Önemli veriler için kalıcı bir kayıt tutuyor musunuz?

Listeyi ekibinizle bir toplantıda birlikte doldurmak, çoğu zaman gizli varsayımları ortaya çıkarır.

WebSocket tabanlı bir özellik için ekibimizden nasıl destek alırsınız?

Canlı bildirim, sohbet ya da panel gibi bir özelliği planlıyorsanız, önce gerçekten WebSocket gerekip gerekmediğini birlikte netleştirebiliriz. Bazen basit bir çözüm yeterlidir; bazen de mimariyi baştan doğru kurmak sonradan çok zaman kazandırır.

Özel yazılım tarafındaki çalışma biçimimizi özel yazılım geliştirme sayfamızda anlattık. Güvenlik ayrıntıları için OWASP güvenlik açıkları yazımız iyi bir tamamlayıcıdır.

Bu yazıdaki bilgiler genel bilgilendirme amaçlıdır. Kendi altyapınızdaki kararlar için güncel belgelere ve gerçek yük testlerine bakın.

Kaynaklar: protokolün kendisi için IETF RFC 6455, tarayıcı arayüzü için MDN WebSockets API sayfası, sunucu yazarlarına yönelik MDN WebSocket sunucusu yazma kılavuzu ve MDN Server-Sent Events sayfası.