Kontrollü bir MITM (Man-in-the-Middle) proxy ortamı kurmak için Charles Proxy veya Fiddler gibi araçlar kullanarak WebSocket çerçevelerini kesmek ve incelemek, tüm bağlantı durumu geçişlerini kaydetmek için sistematik bir metodoloji uygulanır. Bu kurulum, test edicilerin, kurumsal güvenlik duvarı davranışlarını taklit eden belirli ağ hatalarını, örneğin TCP sıfırlamaları veya gecikme artışları enjekte etmelerini sağlar. Test ediciler, her proxy zaman aşımı olayını karşılık gelen UI durumu ve konsol hata mesajları ile eşleştiren ayrıntılı bir günlük korelasyon tablosu tutmalıdır.
Kurum içindeki kullanıcıların Palo Alto Networks güvenlik duvarları arkasında kısa süreli ağ kesintileri sırasında çizim vuruşlarını kaybettiklerini bildirdikleri React tabanlı bir işbirliği tahta uygulamasını test ediyorduk. Standart ofis WiFi testi sorunsuz yeniden bağlantı gösterirken, VPN kullanıcıları rastgele görünen veri kayıpları yaşadı. İlk araştırma, Socket.IO kütüphanesinin oturumları doğru bir şekilde yeniden başlatmadığını öne sürdü.
Ana zorluk, veri kaybının istemci tarafındaki yeniden bağlantı tampon mantığında bir hatadan mı kaynaklandığını yoksa proxy’nin 30 saniyelik algılanan faaliyetsizlik sonrası WebSocket bağlantılarını zorla sonlandırmasından mı kaynaklandığını belirlemekti. Ayrıca, geçiş süresi boyunca geri dönüş HTTP uzun bekletme taşımasının doğru bir şekilde mesajları tamponlayıp tamponlayamadığını doğrulamamız gerekiyordu. Kesin hata noktasını anlamak kritikti çünkü sorun yalnızca agresif zaman aşımı politikaları olan belirli kurumsal proxy’lerin arkasında ortaya çıkıyor, bu da standart test ortamlarında yeniden üretimini imkansız hale getiriyordu.
Çözüm 1: Doğrudan VPN ortamında test
Gerçek davranışı gözlemlemek için kurumsal VPN içinde doğrudan test yapmayı değerlendirdik. Bu yaklaşım gerçek dünya doğrulaması sağladı ama kurumsal TLS denetim politikaları nedeniyle WebSocket çerçeve trafiği üzerinde sıfır görünürlük sağladı, iletim sırasında mesajların kaybolup kaybolmadığını veya istemci tarafı render'ında kaybolup kaybolmadığını belirlemeyi imkansız hale getirdi. Ayrıca, BT güvenlik ekipleriyle sürekli koordinasyonu gerektirdi ve iterasyon döngülerini önemli ölçüde yavaşlattı.
Çözüm 2: yalnızca Tarayıcı Geliştirici Araçları ile gecikme simülasyonu
Chrome DevTools kullanarak çevrimdışı durumları ve yavaş 3G ağlarını simüle etmek başka bir seçimdi. Bu yöntem, temel çevrimdışı tespitini ve yeniden bağlantı UI durumlarını hızlı bir şekilde doğruladı, ancak proxy’ye özgü davranışları, örneğin HTTP CONNECT tünel zaman aşımı veya üretim ortamını karakterize eden ani TCP bağlantı sıfırlamaları gibi durumları tekrarlamada başarısız oldu. Tarayıcının ağ soyutlama katmanı, sahada gerçekleşen belirli taşıma hatalarını gizleyerek uygulamanın dayanıklılığı konusunda yanlış bir güven verdi.
Çözüm 3: Trafik incelemesiyle yerel proxy simülasyonu
WebSocket trafiğini deşifre edip incelemek için Charles Proxy'yi yerel bir SOCKS proxy olarak kullanmayı tercih ettik ve Windows üzerinde %5 paket kaybı ve 200ms gecikme enjekte etmek için Clumsy kullandık. Bu çözüm, WebSocket el sıkışmasının başarısız olduğu anı gözlemlememizi sağladı ve Socket.IO istemcisinin, geçiş süresince iletilen olayları doğru bir şekilde tamponlayıp tamponlamadığını doğrulamamıza yardımcı oldu. Proxy zaman aşımını tetiklemek için Charles trafiğini askıya alarak, gerçek VPN erişimine ihtiyaç duymadan kurumsal güvenlik duvarı davranışını yansıtan tekrarlanabilir koşullar sağlamış olduk.
Seçilen çözüm ve sonuç
Çözüm 3'ü seçtik çünkü uygulama ve altyapı hatalarını ayırt etmek için gerekli ayrıntıyı sağladı ve kurumsal güvenlik politikalarını ihlal etmedi. Test, istemci uygulamamızın transport yükseltme el sıkışması sırasında ping çerçevelerini kabul etmediğini ortaya çıkardı ve bu da proxy’nin bağlantıyı sonlandırmasına neden oldu. Kalp atışı kabul mantığını düzeltmek suretiyle veri kaybı raporlarını ortadan kaldırdık ve manuel test belgeleri, geliştiricilere birim test simülasyonları için kesin paket yakalamalarını sağladı.
Hızlı yeniden bağlantı döngüleri sırasında WebSocket mesajlarının sırayla teslim edilmediğini nasıl manuel olarak doğruluyorsunuz?
Birçok testçi, UI gözlemine yalnızca güvenmekte ve geçici sıralama sorunlarını kaçırmaktadır. Bunu manuel olarak test etmek için, her mesaj yüküne benzersiz sıra tanımlayıcıları ve zaman damgaları enjekte edin, ardından tam olarak 5 saniye için Uçak Modu'nu açıp kapatarak yeniden bağlantıyı zorlayın. WebSocket çerçeve günlüğündeki mesajların sırasını Ağ sekmesindeki mesajların sırasıyla karşılaştırarak, özellikle sunucunun onaylanmamış paketleri yeniden gönderdiği "mesaj tekrarı" senaryolarını kontrol edin.
Socket.IO taşıma geri düşürme ile yerel WebSocket yeniden bağlantısı testi arasındaki kritik fark nedir ve bu durum manuel QA için neden önemlidir?**
Socket.IO, taşıma mekanizmalarını Engine.IO üzerinden soyutlar, bu da API'deki "bağlantı kesildi" olayının, gerçek bir WebSocket kapanmasını veya WebSocket ile HTTP uzun bekletme arasında sessiz bir yükseltme veya geri düşürmeyi temsil edebileceği anlamına gelir. Manuel testçilerin, JavaScript olay dinleyicilerine güvenmek yerine, Chrome DevTools'taki gerçek ağ taşımalarını (yani XHR bekleme isteklerini ve WS çerçevelerini) incelemesi gerekir. Bu önemlidir çünkü mesaj tamponlama davranışları taşıma yöntemine göre önemli ölçüde farklıdır; HTTP bekletme, alımın açık onayını gerektirirken, WebSocket sürekli bir akış üzerinde çalışır ve bu durum "en az bir kez" teslim garantilerini doğrulamanız şekilde etkiler.
Kurumsal proxyler SSL denetimi yaptığında (man-in-the-middle), bu WebSocket TLS el sıkışmalarını nasıl etkiler ve manuel testçilerin araması gereken spesifik belirti nedir?
SSL denetim proxyleri, TLS bağlantılarını sonlandırır ve yeniden şifreler, bu da proxy'nin HTTP Upgrade başlığını desteklemediği veya istemcide sertifika sabitlemenin uygulandığı durumlarda WebSocket yükseltmelerini bozabilir. Testçiler, WebSocket el sıkışmasının 101 Protokoller Değiştiriliyor yerine HTTP 200 OK döndürdüğü durumları aramalıdır; bu, istemcinin sonsuz bir bekleme döngüsüne girmesine neden olur. Bunu manuel olarak doğrulamak için, Chrome DevTools'ta yanıt başlıklarını inceleyin; eksik bir Sec-WebSocket-Accept başlığı ve başarılı HTTP yanıtları kombinasyonu, uygulama hatası yerine proxy müdahalesini gösterir.