WebSocket 101 döndü ama bağlantı kopuyor: yaşam süresi ve oturum kabulü

WebSocket bağlantısında 101 yanıtını görmek iyi bir başlangıçtır; fakat uygulamanın uzun süre güvenilir ve yetkili iletişim kurduğunu göstermez. Bağlantı boşta kalınca kopabilir, yeniden bağlantı aynı işlemi iki kez üretebilir veya kullanıcı çıkış yaptıktan sonra açık kalabilir. Bu rehber genel HTTPS kurulumundan farklı olarak açılıştan sonraki yaşam döngüsüne odaklanır. Örnek hizmet ws.batuhanyazici.com'dur ve gerçek altyapıyı tarif etmez.

Protokol geçişini uygulama kabulünden ayırın

Nginx belgesi WebSocket tünelinin istemcinin yükseltme isteğiyle arka uçtan gelen uygun yanıtın birlikte değerlendirilmesiyle kurulduğunu açıklar. Upgrade ve Connection gibi bağlantıya özgü başlıkların ters vekil davranışında ayrıca ele alınması gerekir. Kurulu Nginx sürümünün belgesine bakın; farklı sürümlerin varsayılan HTTP davranışını birbirine taşımayın. Kopyalanan bir yapılandırma parçasının mevcut server ve location kapsamına uyduğunu ayrıca doğrulayın.

101 sonrasında uygulamanın beklediği ilk mesajı, yanıtı ve hata biçimini test edin. Yanlış uç noktaya açılan ama mesaj işleyemeyen bağlantıyı başarılı saymayın. Tarayıcı ağı sekmesiyle sunucu kaydını anonim bir bağlantı kimliği üzerinden eşleştirin. Gerçek mesaj gövdelerini, oturum belirteçlerini veya özel kullanıcı verisini tanılama kaydına taşımak gerekmez. Olay türü ve zaman bilgisiyle başlayın.

1. Açılış yanıtını doğrula
2. Yetkili mesajı sına
3. Boşta kalmayı gözle
4. Oturumu sonlandır
5. Yeniden bağlantıyı sınırla

Boşta kalmayı ayrı bir senaryo yapın

Ters vekil, uygulama sunucusu ve istemcinin farklı zaman aşımı veya kalp atışı kuralları olabilir. Nginx proxy_read_timeout, ardışık okuma işlemleri arasındaki süreyi değerlendirir; bütün oturumun toplam ömrü olarak yorumlanmamalıdır. Hangi katmanın kapattığını ölçmeden süreleri çok büyütmeyin. Açık kalan gereksiz bağlantılar kaynak tüketir ve gerçek arızanın fark edilmesini geciktirebilir. Kullanılan protokolün kalp atışı davranışı ayrıca belgelenmelidir.

Test matrisinde etkin mesajlaşma, belirlenmiş süre boşta bekleme ve ağın kontrollü kesilip geri gelmesi ayrı satırlar olsun. Kapanış nedeni, istemci gözlemi ve sunucu gözlemi birlikte kaydedilsin. Her kopuş aynı nedene bağlanmamalıdır. Güvenlik duvarı veya yük dengeleyici varsa onların oturum sınırları da değerlendirilir. Bu yazıda belirli bir zaman aşımı değeri bütün ortamlar için önerilmiyor; beklenen iş davranışı ölçüt olarak seçiliyor.

Açık kanal üzerinde yetki devam etmelidir

OWASP, WebSocket açılışında Origin denetimiyle kimlik doğrulamasını ve mesaj düzeyindeki yetkilendirmeyi birlikte ele alır. Origin kontrolü tek başına kullanıcı kimliği değildir; tarayıcı dışı istemcileri de hesaba katın. Bir kanala bağlanan kullanıcının her mesajda her kaynağa erişebileceğini varsaymayın. İzinli kökenleri açıkça sınırlandırmak, genel joker veya gevşek alt dize eşleştirmesinden daha belirgin bir kural sağlar.

Kullanıcı çıkış yaptığında veya yetkisi değiştiğinde mevcut kanalın nasıl etkileneceğini tanımlayın. Yalnız yeni bağlantıları reddetmek açık oturumları sonlandırmayabilir. Kontrollü kabulde zararsız bir test hesabıyla çıkış sonrası mesajı, yetki kaybını ve yeniden bağlantıyı ayrı sınayın. Sunucu açık bağlantının güncel yetki durumunu doğrulamadan hassas işleme devam etmemelidir. Oturum süresiyle kalp atışı süresi farklı amaçlara hizmet eder.

Yeniden bağlantı ve geri dönüş

İstemcinin sınırsız ve eşzamanlı yeniden denemeler üretmesini önleyin. Gecikme, deneme üst sınırı ve bağlantı sahipliği açık olsun. Yeniden bağlantıda önceki mesajın tekrarlanması durum değiştiren işlemlerde ayrıca ele alınmalıdır. Sunucudan onay gelmediyse işlemin kesinlikle yapılmadığını varsaymayın. Tekrar güvenliği uygulamanın iş sözleşmesinde çözülür; tünelin yeniden açılması bunu kendiliğinden sağlamaz.

Geri dönüşte önceki onaylı Nginx ve uygulama ayarlarını birlikte değerlendirin. Aktif bağlantıların yeni kuralları ne zaman kullanacağını kontrollü bakım planıyla belirleyin. Normal mesaj, boşta kalma ve çıkış sonrası reddetme kabulünü temiz bağlantıyla yeniden yürütün. Bu yazıdaki kesinti senaryoları üretimde uygulanmadı; amaç bağlantı açılışı, süreklilik ve oturum güvenliği için ayrı kanıt toplamaktır.

Nasıl yapılır: ayrıntılı uygulama

Ortam ve ön koşullar: Nginx WebSocket yaşam süresi — Mevcut HTTPS server/location, gerçek upstream ve uygulamanın oturum modeli bilinmeli.

1. 101, veri akışı ve oturumu ayrı ölçün
2. HTTP bağlamındaki map ve server/location’ı tamamlayın
3. Yedek, configtest ve reload sırasını izleyin
4. Idle, heartbeat ve auth expiry testini yapın
5. Origin/kimlik reddi ve geri dönüşü kabul edin

1. 101, veri akışı ve oturumu ayrı ölçün

Tarayıcı DevTools > Network > WS görünümünde handshake, Frames/Messages, kapanış kodu ve süreyi okuyun. 101 yalnız yükseltmedir; token/Origin/application authorization kontrolü backend’de devam eder.

2. HTTP bağlamındaki map ve server/location’ı tamamlayın

Mevcut Nginx config’te map http içinde bir kez, location gerçek HTTPS server içinde yer alır. Bu parça TLS vhost’un tamamı değildir; backend URL’si temsili yerel porttur. 90s iki ardışık upstream okuması arasındaki pilot sınırdır.

# http baglaminda:
map $http_upgrade $connection_upgrade {
    default upgrade;
    '' close;
}
# Mevcut HTTPS server baglaminda:
location /ws/ {
    proxy_pass http://localhost:8080;
    proxy_http_version 1.1;
    proxy_set_header Host $host;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;
    proxy_read_timeout 90s;
    proxy_send_timeout 90s;
}

3. Yedek, configtest ve reload sırasını izleyin

Gerçek include dosyası/önceki içerik yedeği hazır olmalı. nginx -t geçmeden reload yapılmaz; diğer vhost’lar korunur.

sudo nginx -t && sudo systemctl reload nginx
systemctl status nginx --no-pager
journalctl -u nginx --since "10 minutes ago" --no-pager

4. Idle, heartbeat ve auth expiry testini yapın

İzinli laboratuvar oturumunda ping/pong veya uygulama heartbeat aralığı, idle timeout, ağ kesilmesi ve token expiry’yi ayrı deneyin. Reconnect exponential backoff/sınır ve eski komutun yeniden yürütülmemesi uygulama sözleşmesinde tanımlanır.

5. Origin/kimlik reddi ve geri dönüşü kabul edin

İzin dışı origin/kimlikte backend reddi olmalı; CORS tek başına WebSocket authorization değildir. Önceki map/location ve uyumlu backend heartbeat ayarına dönüp aynı testleri tekrar uygulayın.

Beklenen sonuç: Yükseltme başlıkları doğru taşınır; kimlik ve Origin kontrolü uygulamada sürer. 90s yalnız temsili pilot değerdir.

Sonuç farklıysa: proxy_read_timeout toplam bağlantı ömrü değil iki okuma arasındaki bekleme sınırıdır.

Geri dönüş: Önceki Nginx dosyasını geri yükleyip configtest ve bağlantı kabulünü tekrarlayın.