QQ Proxy: Kalıcı Bağlantıyı Ayakta Tutmak ve Erişimi Çözmek

QQ, uzun geçmişi olan ve masaüstü kullanımı hâlâ güçlü olan bir mesajlaşma platformudur. Kimlik, e-posta adresi yerine sayısal bir hesap numarasına bağlıdır ve istemci, sohbet dışında grup, dosya paylaşımı ve bağlı servisler için de aynı oturumu kullanır. Bu yapı, proxy tarafında web sitelerinden çok farklı bir profil üretir.

Fark tek bir cümleyle özetlenebilir: burada istek-yanıt döngüsü değil, açık kalması gereken bir kanal yönetiliyor. Bir web sayfası için sorunsuz çalışan proxy yapılandırması, dakikalarca boşta kalan bir bildirim kanalını ayakta tutmakta zorlanabilir. Bölümler bu farkın sonuçlarını sırayla açıyor.

Sayfadaki öneriler erişim, kurumsal ağ yönetimi ve geliştirme testi bağlamındadır. Herhangi bir kısıtın teknik olarak devre dışı bırakılması ya da otomatik etkileşim üretilmesi konu dışıdır.

İstemcinin ağ profili neden sıradan bir web istemcisine benzemez?

Tarayıcı bir sayfa açar, kaynakları indirir ve bağlantıyı bir süre sonra bırakır. QQ istemcisi ise oturum boyunca ayakta kalan bir kanal kurar ve bu kanalı düzenli canlılık paketleriyle besler. Mesaj geldiğinde sunucu istemciyi bu kanaldan uyarır; istemci sürekli soru sormaz. Bu model bildirim gecikmesini düşük tutar ama ara katmandaki her bileşene bağımlı hâle gelir.

Ara katmanda bir proxy varsa, kanal artık iki parçadan oluşur: istemciden proxy’ye ve proxy’den hedefe. İki parçanın zaman aşımı politikaları farklıysa zayıf halka kanalı belirler. Proxy tarafında boşta kalma süresi kısa ayarlanmışsa, hiçbir mesaj gelmeyen bir öğle arasından sonra kanal sessizce düşer ve istemci yeniden bağlanmaya çalışır.

İkinci fark taşıma çeşitliliğidir. İstemci, metin ve durum bilgisi için güvenilir bir TCP akışı kullanırken dosya aktarımı ve gerçek zamanlı ses için farklı yollar deneyebilir. Bu yüzden tek bir HTTP kuralı bazen her şeyi kapsamaz. Protokol seçiminde izlenecek karar sırası kısadır: taşınan akışların tamamı TCP ise iki protokol de yeterlidir, ad çözümlemesinin uzakta yapılması gerekiyorsa ya da UDP devredeyse tercih SOCKS5 tarafına kayar.

Üçüncü fark oturum kimliğidir. Sayısal hesap numarası, oturum jetonuyla birlikte taşınır ve sunucu tarafında bağlantının geldiği adresle birlikte değerlendirilir. Kanal her düştüğünde yeniden kurulan bağlantı farklı bir çıkış adresinden geliyorsa, tutarsız bir tablo oluşur. Bu nedenle rotasyon değil sabit çıkış tercih edilir.

Oturum boyunca hangi trafik türü ne kadar yer kaplar?

Bir QQ oturumunda taşınan baytların dağılımı, çoğu kullanıcının beklediğinden farklıdır. Kalıcı kanal sürekli açık olmasına rağmen az veri taşır; asıl hacim dosya paylaşımı ve grup içi medyadan gelir. Kimlik doğrulama ise yalnızca oturum başında ve yeniden bağlanmalarda görünür.

Bu dağılımı bilmek iki kararı doğrudan etkiler. Birincisi kota planıdır: ölçülen trafik üzerinden çalışan bir hat seçiyorsanız bütçenizi dosya paylaşımına göre kurun. İkincisi bağlantı sayısıdır: kalıcı kanal tek bir soket tutarken dosya aktarımı paralel soketler açar ve sağlayıcının eşzamanlılık sınırına ilk çarpan bu olur.

Yeniden bağlanma döngüsüne giren bir istemci üçüncü bir yük üretir. Her deneme yeni bir el sıkışma, yeni bir TLS kurulumu ve yeni bir kimlik doğrulama turu demektir. Kanal kopmaları sıklaştığında bu tur masrafı toplam trafikte fark edilir hâle gelir ve proxy tarafında gereksiz oturum açılışları birikir.

Eşzamanlılık sınırına dayandığınızda ortaya çıkan belirti, kota aşımınınkinden farklıdır ve ikisini ayırmak zaman kazandırır. Sınır dolduğunda sağlayıcı yalnızca yeni soket açma isteklerini reddeder: hâlihazırda kurulmuş kalıcı kanal ayakta kalmaya devam eder, mesaj gidip gelir, ama o sırada başlatılan bir dosya aktarımı ya hiç başlamaz ya da ilk parçadan sonra yarıda kalır. Grup içinde birkaç kişi aynı anda dosya gönderdiğinde tablo daha da belirginleşir, çünkü her aktarım kendi paralel soketlerini ister.

Kota aşımında sıra terstir: orada kurulmuş bağlantılar da dâhil olmak üzere trafiğin tamamı durur ya da hız sınırına iner, dolayısıyla sohbet dâhil her akış aynı anda etkilenir. Pratik ayrım şudur — sohbet çalışıyor ama paralel aktarımlar takılıyorsa önce eşzamanlı bağlantı sayısına bakın; hiçbir akış ilerlemiyorsa panelinizdeki veri sayacını kontrol edin. Sınırın nasıl hesaplandığını eşzamanlı bağlantı limiti yazısı, taşınacak hacmin nasıl tahmin edileceğini bant genişliği hesaplama yazısı adım adım anlatıyor.

Kanal neden düşer: zaman aşımı, canlılık paketi ve yeniden bağlanma

Kalıcı bağlantıyı ayakta tutan üç ayar vardır: istemcinin canlılık paketi aralığı, proxy’nin boşta kalma zaman aşımı ve yol üzerindeki ağ ekipmanlarının oturum tablosu ömrü. Üçünden en kısası kanalın gerçek ömrünü belirler. Kurumsal ağlarda genellikle en kısa olan üçüncüsüdür, çünkü güvenlik duvarı oturum tablosunu sınırlı tutar.

Belirti tanıdıktır: uygulama açık kalır, arayüz normal görünür, ama bir süre sonra gönderilen mesaj gitmez ve ardından bağlantı göstergesi kısa süreliğine düşer. Burada suçlu çoğu zaman proxy’nin kendisi değil, aradaki bir bileşenin sessizce kapattığı sokettir. Proxy tarafında boşta kalma süresini uzatabiliyorsanız ilk deneyeceğiniz ayar budur.

İkinci çare canlılık aralığını kısaltmaktır; ancak bu ayar her istemcide açığa çıkmaz. Yapamıyorsanız, kanalı doğal biçimde meşgul tutan bir kullanım düzeni ya da oturum tablosu ömrü daha uzun bir çıkış seçmek kalır. Havuz davranışı ve yeniden kullanım için keep-alive ve bağlantı havuzu yazısı ayrıntılı bir çerçeve sunuyor.

Trafik hangi katmanlardan geçiyor?

Sorun giderirken katmanları ayırmak, tahmin etmekten çok daha hızlı sonuç verir. En üstte istemci uygulaması ve onun oturum mantığı vardır. Bunun altında şifreleme katmanı çalışır; TLS el sıkışması burada tamamlanır ve proxy bu noktadan sonra yalnızca şifreli baytları taşır.

Üçüncü katman proxy taşımasıdır. HTTP proxy kullanıyorsanız bağlantı CONNECT ile açılır ve bir tünel kurulur; SOCKS5 kullanıyorsanız el sıkışma kendi biçiminde yapılır ve isteğe bağlı olarak kimlik doğrulama eklenir. İkisi arasındaki farkı CONNECT metodu yazısı ayrıntısıyla açıklıyor.

En altta çıkış ağı yer alır. Bağlantının hedefe göründüğü adres ve bu adresin ait olduğu otonom sistem buradadır. Hedef tarafın gördüğü tek şey bu katmandır; üstteki üç katman hakkında doğrudan bilgisi yoktur. Adresin hangi otonom sisteme kayıtlı olduğu, o adresin bir veri merkezinden mi yoksa bir erişim sağlayıcısının abone havuzundan mı geldiğini ele verir; sınıflandırma büyük ölçüde bu kayda bakılarak yapılır.

Bir arıza yaşandığında hangi katmanda durduğunuzu bilmek, hangi ayarı değiştireceğinizi de söyler. Kimlik doğrulama hatası üçüncü katmandadır, sertifika uyarısı ikinci katmanda, sürekli yeniden bağlanma ise genellikle birinci ve üçüncü katmanın zaman aşımı uyuşmazlığındadır.