WebSocket ile Canlı Veri Akışı Nasıl Kurulur

Gerçek zamanlı iletişim neden ayrı bir tasarım konusu?

Klasik web isteği sorgu-yanıt düzenindedir: istemci sorar, sunucu yanıtlar ve bağlantı kapanır. Sohbet, canlı skor tablosu, ortak belge düzenleme, bildirim ya da sipariş takibi gibi senaryolarda ise sunucunun istemciye kendiliğinden veri göndermesi gerekir. İstemcinin sürekli "yeni bir şey var mı" diye sormasına (polling) göre, kalıcı bir bağlantı hem gecikmeyi hem gereksiz istek yükünü azaltır.

WebSocket, istemci ile sunucu arasında kalıcı, çift yönlü bir kanal açan protokoldür. Bağlantı normal bir HTTP isteğiyle başlar, ardından protokol yükseltilir ve taraflar istediği zaman mesaj gönderebilir. Ancak kalıcı bağlantı, sunucunun durumlu çalışması anlamına gelir; bu da bağlantı yönetimi, ölçekleme ve hata toleransı gibi yeni tasarım sorularını beraberinde getirir.

Hangi durumda WebSocket, hangisinde alternatifler?

Her gerçek zamanlı ihtiyaç WebSocket gerektirmez. Seçim, veri akışının yönüne ve sıklığına bağlıdır. • Uzun aralıklı polling: yeni veri nadiren gelirse ve basit çözüm yeterliyse kabul edilebilir, ama yük ve gecikme artar. • Sunucu gönderimli olaylar (SSE): akış yalnızca sunucudan istemciye ise, örneğin bildirim ya da ilerleme çubuğu, daha basit ve HTTP ile uyumludur. • WebSocket: istemci de sık mesaj gönderiyorsa, örneğin sohbet, oyun, ortak düzenleme ya da canlı kontrol paneli, çift yönlü kanal gerekir. • Mesaj aracısı destekli çözümler: birden çok sunucu ve tüketici arasında yayın gerekiyorsa WebSocket ucunun arkasına bir mesaj aracı konur.

Gereksinimi "gerçek zamanlı" kelimesinden çıkarmayın; kullanıcının kaç saniye gecikmeyi fark edeceğini sorun. Bu yanıt, seçilecek teknolojinin karmaşıklığını belirler.

Sunucu mimarisi ve bağlantı yönetimi

WebSocket sunucusu her açık bağlantı için bellek ve dosya tanıtıcısı tutar. Bu nedenle olay döngüsü tabanlı ya da eşzamanlılık odaklı bir çalışma zamanı seçmek yaygındır. Bağlantı kurulduğunda sunucu istemciyi tanımlar, hangi odalara ya da kanallara abone olduğunu kaydeder ve gelen mesajları ilgili abonelere dağıtır.

Bağlantı yönetiminde şunlara dikkat edilir: • Sağlık kontrolü: karşılıklı ping ve pong mesajlarıyla ölü bağlantıları tespit etmek • Boşta kalan bağlantıları zaman aşımıyla kapatmak • Mesaj boyutu ve hız sınırı koymak; bir istemcinin sunucuyu doldurmasını engellemek • Yavaş tüketen istemciler için çıkış kuyruğunu sınırlamak, aksi halde bellek şişer • Kapanışta kaynakları temizlemek, abonelikleri silmek

Ağ ara katmanları (yük dengeleyici, vekil sunucu) bağlantıyı sessizce kesebilir; bu yüzden düzenli canlı tutma mesajları gerekir.

Kimlik doğrulama, yetki ve mesaj sözleşmesi

WebSocket bağlantısı kurulurken kimlik doğrulama yapılmalıdır. Yaygın yaklaşım, bağlantı isteğinde kısa ömürlü bir belirteç taşımak ve sunucuda doğrulamaktır. Belirtecin adres satırında taşınması günlüklere sızabileceği için dikkat gerektirir. Kimlik bir kez doğrulansa bile her mesajda yetki kontrolü gerekir: kullanıcı yalnızca yetkili olduğu odalara abone olabilmeli, yalnızca izin verilen işlemleri tetikleyebilmelidir. Ayrıca bağlantının geldiği kaynak alan adı denetlenmelidir.

Mesaj sözleşmesi, istemci ile sunucunun ortak dilidir. Her mesajın bir tipi, sürümü ve yükü bulunur; bilinmeyen tipler güvenle yok sayılır. Sözleşme baştan şemayla tanımlanırsa istemci ve sunucu birbirinden bağımsız geliştirilebilir. Mesajlara kimlik numarası eklemek, tekrar gönderimlerde mükerrer işlemi önlemeye ve onay (ack) mekanizması kurmaya yarar.

Güvenilirlik: yeniden bağlanma ve mesaj kaybı

Bağlantılar mutlaka kopar: mobil ağlar arası geçiş, cihazın uykuya dalması, sunucunun yeniden başlatılması. Güvenilir bir uygulama bu kopmayı normal durum sayar. İstemci, kopma halinde artan bekleme süresiyle ve rastgele sapmayla yeniden bağlanmayı dener. Rastgele sapma olmazsa sunucu yeniden başladığında bütün istemciler aynı anda saldırır ve sunucu tekrar düşer.

Yeniden bağlanan istemcinin kaçırdığı mesajları nasıl alacağı önceden kararlaştırılır. Mesajlara artan sıra numarası verilir; istemci son aldığı numarayı bildirir ve sunucu aradaki mesajları yeniden gönderir ya da istemci güncel durumu yeniden çeker. Her mesajın kaybolmasına izin veren akışlar (örneğin anlık konum) ile hiçbirinin kaybolmaması gereken akışlar (örneğin ödeme bildirimi) farklı ele alınır. Bu son tür için kalıcı kuyruk ya da veritabanı desteği gerekir.

Ölçekleme ve dağıtım

Bir sunucu tüm bağlantıları taşıyabildiği sürece sorun yoktur. Kullanıcı arttığında bağlantılar birden çok sunucuya dağılır ve yeni bir sorun çıkar: A sunucusuna bağlı kullanıcıdan gelen mesajın B sunucusundaki kullanıcıya iletilmesi. Çözüm, sunucular arasında bir yayın katmanıdır; çoğu zaman bellek içi bir veri deposunun yayın-abonelik özelliği ya da bir mesaj aracı kullanılır.

Yük dengeleyicide bağlantının uzun süre açık kalabileceği ve çoğu zaman yapışkan oturum gerektirmeyecek biçimde tasarlanması gerektiği akılda tutulmalıdır. Dağıtım sırasında sunucuyu aniden kapatmak bütün bağlantıları düşürür; bunun yerine yeni bağlantı kabulünü durdurup mevcut bağlantıları kademeli boşaltmak istemcilerin üzerindeki yükü azaltır. Kapasite planı için bağlantı başına bellek ve mesaj hızı ölçülmeli, yük testiyle doğrulanmalıdır.

İzleme, test ve sık hatalar

Üretimde izlenmesi gereken göstergeler arasında açık bağlantı sayısı, bağlantı kurma ve kopma oranı, mesaj gecikmesi, çıkış kuyruğu uzunluğu ve hata tipleri bulunur. Gerçek zamanlı sistemde sorun genellikle "yavaş" olarak değil "mesaj gelmiyor" olarak bildirilir; bu yüzden uçtan uca bir sentetik istemciyle mesajın yolculuğunu düzenli ölçmek yararlıdır.

Test tarafında birim testlerinin yanında, ağ kopmasını, gecikmeyi ve sunucu yeniden başlamasını simüle eden senaryolar gerekir. Çok sayıda eşzamanlı istemciyle yük testi yapılmadan kapasite iddia edilmemelidir.

Sık hatalar: • Yeniden bağlanmayı hiç düşünmemek • Her mesajda yetki kontrolü yapmamak • Çıkış kuyruğunu sınırsız bırakmak • Mesaj sözleşmesine sürüm koymamak ve istemci güncellemesinde sunucuyu kırmak • Tüm durumu sunucu belleğinde tutup yeniden başlatmada kaybetmek

Mindset programlarında gerçek zamanlı iletişim

Mindset'in WebSocket ve Gerçek Zamanlı İletişim Mimarisi eğitiminin modülleri bu başlıkları izler: gerçek zamanlı iletişim seçenekleri, sunucu mimarisi ve bağlantı yönetimi, kimlik doğrulama, yetki ve mesaj sözleşmesi, güvenilirlik ve yeniden bağlanma, ölçeklenme ve dağıtım, izleme, test ve üretim pratikleri.

Bu sıra, canlı bir sistemin tasarım kararlarının verildiği sırayla ele alır: önce kanalın seçimi, sonra bağlantı ve güvenlik, en son işletme ve gözlem.