Canlı sohbet, anlık bildirim veya gerçek zamanlı gösterge paneli eklemek istiyorsunuz. Bu özellikler klasik istek-yanıt döngüsünden farklı bir bağlantı modeli gerektirir — ve sunucunuzda farklı bir yük profili oluşturur.
Bu yazı, uzun süreli bağlantıların sunucu tarafındaki etkilerini ele alıyor.
Klasik Modelden Farkı
Normal bir web isteği kısa ömürlüdür: istek gelir, yanıt gider, bağlantı kapanır. WebSocket bunu tersine çevirir:
- Bağlantı açık kalır. Dakikalar, saatler boyunca.
- İki yönlü iletişim vardır. Sunucu da mesaj başlatabilir.
- Her bağlantı bellek tüketir. Boşta dursa bile.
- Durum sunucuda tutulur. Kim nerede bağlı?
Dördüncü madde en önemli mimari sonucu doğurur: klasik web uygulamaları durumsuzdur, WebSocket ise doğası gereği durumludur.
Bu fark, ölçeklendirme yaklaşımınızı tamamen değiştirir — istekleri rastgele dağıtamazsınız, çünkü kullanıcının bağlantısı belirli bir sunucuda durur.
Ne Zaman Gerekli?
Her gerçek zamanlı görünen özellik WebSocket gerektirmez:
| İhtiyaç | Uygun yöntem |
|---|---|
| Dakikada bir güncelleme | Basit periyodik sorgu |
| Tek yönlü bildirim akışı | Sunucu gönderimli olaylar |
| Çift yönlü, sık mesajlaşma | WebSocket |
| Nadir ama anlık bildirim | Anlık bildirim servisi |
İkinci satır sıkça atlanan bir seçenektir: yalnızca sunucudan istemciye veri akıyorsa, sunucu gönderimli olaylar WebSocket'ten daha basittir ve normal HTTP altyapısı üzerinde çalışır.
Birinci satır ise dürüst bir değerlendirmedir. Güncelleme sıklığınız düşükse, düzenli aralıklarla yapılan basit bir sorgu hem daha az kaynak tüketir hem daha az karmaşıklık getirir.
Sunucu Kaynak Etkisi
Uzun süreli bağlantıların kaynak profili şöyledir:
- Bellek doğrusal artar. Bağlantı başına sabit bir maliyet.
- CPU düşük kalır. Mesaj akmadığı sürece.
- Dosya tanıtıcısı tüketilir. Sistem sınırına takılabilirsiniz.
- Bağlantı sayısı port sınırına dayanabilir.
Üçüncü madde ilk karşılaşılan duvardır: işletim sistemi varsayılan olarak süreç başına açık dosya sayısını sınırlar ve her bağlantı bir dosya tanıtıcısı tüketir.
Bu sınır artırılabilir ancak varsayılan değerlerle birkaç bin bağlantıda tıkanırsınız. Yapılandırmayı önceden ayarlamak gerekir — VDS altyapısı üzerinde bu sistem sınırlarına doğrudan müdahale edebilirsiniz.
Ters Vekil Yapılandırması
Uygulamanızın önünde bir ters vekil varsa ek ayar gerekir:
- Yükseltme başlıkları iletilmelidir. Bağlantı protokol değiştirir.
- Zaman aşımı süreleri uzatılmalıdır. Varsayılanlar çok kısadır.
- Tamponlama kapatılmalıdır. Mesajlar gecikmesin.
- Bağlantı sayısı sınırları gözden geçirilmelidir.
İkinci madde en sık yaşanan sorunun kaynağıdır: ters vekilin varsayılan zaman aşımı süresi genellikle bir dakikadır ve boştaki WebSocket bağlantısı bu sürede kapatılır.
Kullanıcı tarafında bu, bağlantının rastgele kopması olarak görünür. Çözüm iki yönlüdür: vekildeki süreyi uzatmak ve uygulamada düzenli canlılık sinyali göndermek.
Canlılık Sinyali
Açık bağlantıların sağlığını korumak için gereken düzen:
- Sunucu düzenli aralıklarla sinyal gönderir
- İstemci yanıt verir
- Yanıt gelmezse bağlantı ölü sayılır
- Kaynaklar serbest bırakılır
- İstemci yeniden bağlanmayı dener
Üçüncü madde kaynak sızıntısını önler: ağ kesintisinde bağlantı düzgün kapanmaz ve sunucu tarafında ölü bir kayıt olarak asılı kalır. Canlılık kontrolü olmayan sistemlerde bu kayıtlar birikir.
Beşinci madde istemci tarafı sorumluluğudur ama sunucu tasarımını etkiler: yeniden bağlanma denemeleri kademeli olarak seyrekleşmelidir, aksi hâlde kesinti sonrası tüm istemciler aynı anda bağlanmaya çalışır.
Ölçeklendirme Sorunu
Birden fazla sunucuya geçtiğinizde ortaya çıkan zorluk:
| Sorun | Çözüm |
|---|---|
| Kullanıcılar farklı sunucularda | Sunucular arası mesaj dağıtımı |
| Bağlantı hangi sunucuda? | Merkezi bağlantı kaydı |
| Yük dengeleyici dağıtımı | Oturum yapışkanlığı |
| Sunucu yeniden başlarsa | İstemci yeniden bağlanmalı |
Birinci satır temel zorluktur: A sunucusundaki kullanıcı, B sunucusundaki kullanıcıya mesaj gönderemez — sunucular arasında bir mesaj dağıtım katmanı gerekir.
Bu genellikle bir yayınla-abone ol yapısıyla çözülür: mesaj merkezi bir kanala yazılır, tüm sunucular o kanalı dinler ve kendi bağlantılarına iletir.
Güvenlik Noktaları
Uzun süreli bağlantılarda dikkat edilecekler:
- Kimlik doğrulama bağlantı kurulurken yapılmalıdır.
- Yetki değişiklikleri açık bağlantıya yansımalıdır.
- Mesaj hızı sınırlanmalıdır. Tek istemci sunucuyu boğmasın.
- Mesaj boyutu sınırlanmalıdır.
- Şifreli bağlantı kullanılmalıdır.
İkinci madde ince bir açıktır ve gözden kaçar: kullanıcının yetkisi kaldırıldığında, açık duran WebSocket bağlantısı çalışmaya devam eder. Yetki değişikliklerinde ilgili bağlantıların kapatılması gerekir.
Üçüncü madde ise basit bir kötüye kullanımı önler — sınırsız mesaj gönderebilen tek bir istemci, sunucu kaynaklarını tüketebilir.
Sonuç
WebSocket'in getirdiği asıl değişiklik teknik değil mimaridir: klasik web uygulamaları durumsuzdur, uzun süreli bağlantılar ise doğası gereği durumludur ve bu, ölçeklendirme yaklaşımınızı baştan değiştirir. Kurulumda ilk çarpacağınız duvar, işletim sisteminin açık dosya sayısı sınırıdır. İkinci sorun ters vekilde çıkar: varsayılan zaman aşımı genellikle bir dakikadır ve boştaki bağlantıyı kapatır — süreyi uzatın ve canlılık sinyali gönderin. Ayrıca her gerçek zamanlı özellik WebSocket gerektirmez; tek yönlü akış için daha basit yöntemler var.
Sıkça Sorulan Sorular (SSS)
Gerçek zamanlı özellik için WebSocket şart mı?
Değil. Veri yalnızca sunucudan istemciye akıyorsa sunucu gönderimli olaylar daha basittir ve normal HTTP altyapısında çalışır. Güncelleme sıklığınız düşükse periyodik bir sorgu hem daha az kaynak tüketir hem daha az karmaşıklık getirir.
Bağlantılar rastgele kopuyor, neden?
Büyük olasılıkla ters vekilin zaman aşımı süresi. Varsayılan genellikle bir dakikadır ve boştaki bağlantı bu sürede kapatılır. Vekildeki süreyi uzatın ve uygulamada düzenli canlılık sinyali gönderin.
Kaç eşzamanlı bağlantı taşıyabilirim?
Öncelikle işletim sisteminin açık dosya sayısı sınırına takılırsınız — varsayılan değerlerle birkaç bin bağlantıda tıkanırsınız. Bu sınır artırılabilir; asıl kısıt sonrasında bellektir, çünkü her bağlantı boşta dursa bile sabit bir bellek maliyeti taşır.
Birden fazla sunucuya nasıl dağıtırım?
Yük dengeleyicide oturum yapışkanlığı açın ki kullanıcı hep aynı sunucuya gitsin. Ayrıca sunucular arası bir mesaj dağıtım katmanı kurun — aksi hâlde farklı sunuculardaki kullanıcılar birbirine mesaj gönderemez.
