Viber ve Proxy: Tünel Seçimi, Medya Aktarımı ve Bölgesel Görünüm

Viber; metin mesajı, sesli arama, görüntülü görüşme, dosya aktarımı ve topluluk yayını gibi birbirinden farklı işleri tek bir arayüzde toplar. Bu işlerin hepsi aynı taşıma katmanını kullanmaz. Mesajlar uzun ömürlü bir TCP oturumundan geçer, medya dosyaları ayrı depolama uç noktalarına yüklenir, görüşme sesi ise gerçek zamanlı bir akışa düşer.

Proxy tanımladığınızda bu üç yol otomatik olarak birlikte yönlendirilmez. Bir tünel türü yalnızca TCP taşıyabilir; bir diğeri UDP’yi de taşıyabilir ama istemci bunu talep etmezse fark yaratmaz. Kurulumun “çalışıyor ama bir kısmı eksik” hâlde kalmasının nedeni neredeyse her zaman budur.

Aşağıdaki bölümler önce trafiğin nerede ayrıştığını, sonra tünel türü kararını, medya aktarımının bant genişliği davranışını, bölgesel görünüm farklarını ve kurulum sonrası doğrulamayı sırayla ele alıyor.

Viber istemcisi ağda kaç ayrı yol açar?

Uygulama açıldığında ilk kurulan şey kimlik doğrulamayı ve mesaj teslimini taşıyan uzun ömürlü bir TCP oturumudur. Okundu bilgisi, yazıyor göstergesi, çevrimiçi durumu ve bildirim tetikleyicileri bu kanaldan akar. Kanal sürekli açık tutulduğu için trafiği küçük ama kesintisizdir; bağlantı düştüğünde istemci artan aralıklarla yeniden bağlanmayı dener. Proxy açısından bu en kolay taşınan yoldur: tek bir TCP akışıdır ve TLS ile şifrelenir.

İkinci yol medya deposudur. Gönderdiğiniz fotoğraf, ses kaydı, video veya belge sohbet kanalının içinden akmaz; ayrı bir yükleme uç noktasına gider ve karşı taraf aynı depodan indirir. Bu istekler HTTPS üzerinden yapılır ve çoğu kurulumda sinyalleşme kanalından farklı ana bilgisayar adlarına yönelir. Proxy kuralınız yalnızca dar bir alan adı kümesini kapsıyorsa mesajlar sorunsuz gider, ekler ise takılır veya beklenenden yavaş iner.

Üçüncü yol gerçek zamanlı görüşmedir. Sesli ve görüntülü arama, paketlerin gecikmesiz ulaşmasını yeniden iletim garantisine tercih eden bir akıştır; bu yüzden TCP yerine UDP üzerinde ilerler. İki taraf NAT arkasındaysa istemciler önce doğrudan bir yol aramaya çalışır, bulamazlarsa aktarma sunucusuna düşer. Bu keşif süreci sinyalleşme kanalından ayrı yürür.

CONNECT tüneli ile SOCKS5 arasındaki pratik ayrım

Bir HTTP proxy üzerinden şifreli trafik taşımanın yolu CONNECT metodudur. İstemci proxy’ye “şu ana bilgisayarın şu portuna bir TCP bağlantısı aç” der; proxy bağlantıyı kurar ve bundan sonra iki taraf arasındaki baytları yorumlamadan aktarır. Yöntem TLS için tasarlandığından çoğu sağlayıcı CONNECT hedefini 443 gibi TLS portlarıyla sınırlar. Düz HTTP istekleri bu yoldan geçmez: tünel açılmadan, mutlak URI taşıyan bir istek olarak proxy’ye gider ve proxy isteği hedefe kendisi yeniden kurar. Yani “80 ve 443’e izin veriliyor” cümlesi iki farklı mekanizmayı tek torbaya koyar; tünel yalnızca TLS portlarında açılır. Mekanizmanın adım adım anlatımı HTTP CONNECT metodu yazısında var.

SOCKS5 bir katman aşağıda çalışır. HTTP semantiği taşımaz, istek başlıklarını okumaz ve hedef portu daraltmak zorunda değildir; bu yüzden standart dışı port kullanan istemcilerle daha uyumludur. İkinci farkı UDP ASSOCIATE komutudur: protokol, UDP paketlerinin de proxy üzerinden taşınabileceği bir mekanizma tanımlar. Ancak bu mekanizmanın işlemesi için hem sağlayıcının komutu etkinleştirmesi hem de istemcinin bunu talep etmesi gerekir.

Üçüncü fark alan adının nerede çözüldüğüdür. CONNECT kullanıldığında istemci hedefi ad olarak gönderir ve çözümleme proxy tarafında yapılır. SOCKS5’te belirleyici olan istemcinin ayarıdır: yerel çözümleme seçilirse hangi ana bilgisayara gittiğiniz yerel DNS sunucunuza görünür, uzak çözümleme seçilirse sorgu da tünelden geçer. Bu ayrımın pratik sonucu şudur: tünel kurulmuş ve trafik şifrelenmiş olsa bile, hangi servisle konuştuğunuz bilgisi yanlış bir istemci ayarı yüzünden tünelin dışında kalabilir.

Karar pratikte şöyle özetlenir: yalnızca tarayıcı ve web tabanlı panelleri yönlendirecekseniz HTTP proxy yeterlidir; masaüstü istemcilerini ve standart dışı portları kapsamanız gerekiyorsa SOCKS5 proxy daha geniş bir kapsam sunar.

Sesli ve görüntülü görüşmede tünel neden devre dışı kalır?

Görüşme trafiği UDP üzerinde ilerlediği için CONNECT tabanlı bir HTTP proxy bu akışı taşıyamaz. Tünel yalnızca TCP bağlantısı açar ve UDP paketleri için bir karşılığı yoktur. Sonuç genellikle gürültüsüz bir ayrışmadır: mesajlar proxy çıkışından gider, arama ise işletim sisteminin varsayılan yolunu kullanır. Uygulama hata göstermediği için kullanıcı bu ayrımı çoğu zaman fark etmez.

SOCKS5 tarafında teorik bir yol vardır, ama üç koşulun birden sağlanması gerekir: sağlayıcı UDP ASSOCIATE komutunu etkinleştirmiş olmalı, aradaki güvenlik duvarı ilgili portlara izin vermeli ve istemci UDP’sini proxy üzerinden göndermeyi desteklemeli. Masaüstü ve mobil sohbet istemcilerinin çoğu bu son adımı uygulamaz; sistem proxy ayarını yalnızca TCP oturumları için okur. Mekanizmanın nasıl kurulduğu SOCKS5 UDP desteği yazısında anlatılıyor.

Bunun pratik sonucu gizlilik beklentisiyle ilgilidir. Sohbet trafiğiniz proxy adresinden görünürken görüşme trafiğiniz gerçek adresinizden çıkabilir. Tek bir çıkış üzerinden bütünsel bir görünüm istiyorsanız, uygulama seviyesindeki proxy yerine tüm paketleri kapsayan bir ağ katmanı çözümü gerekir. İki yaklaşımın sınırlarını proxy ile VPN farkı yazısı karşılaştırıyor.

Medya aktarımı bant genişliğini nasıl harcar?

Proxy üzerinden geçen trafik iki yönlü hareket eder: gönderdiğiniz dosya yükleme, aldığınız dosya indirme olarak aynı çıkıştan geçer. Kotalı bir plan kullanıyorsanız faturalandırma çoğu kurulumda bu toplam üzerinden yapılır. Metin mesajları bu tabloda neredeyse görünmez; tüketimi belirleyen kalem video, uzun ses kaydı ve sıkıştırılmadan gönderilen belgedir.

Uygulamanın otomatik indirme davranışı ikinci belirleyicidir. Kalabalık bir grupta veya takip ettiğiniz bir toplulukta paylaşılan her görsel, siz açmasanız bile önceden indirilebilir. Kotalı bir çıkışta bu ayarı daraltmak aylık tüketimi tahmin edilebilir hâle getirir. Kaba bir hesap için günlük ortalama ek sayınızı ortalama dosya boyutuyla çarpıp otuz günle genişletmek yeterlidir; çıkan rakamı ikiyle çarpın, çünkü aynı dosya hem gönderilirken hem karşı tarafça indirilirken kotadan düşer.

Üçüncüsü yeniden deneme davranışıdır. Büyük bir yükleme yarıda kesildiğinde istemci parçayı baştan göndermek zorunda kalabilir; kararsız bir çıkışta aynı dosya için birden fazla kez ücret ödersiniz. Bu yüzden medya ağırlıklı kullanımda ham hız kadar kararlılık da önemlidir. Sağlayıcı ağında barındırılan sabit ISP çıkışları ve veri merkezi çıkışları bu tarafta avantajlıdır, çünkü aktarım boyunca adres değişmez; operatör ağından gelen mobil çıkışlar ise genellikle kotalıdır ve hacimli aktarım için ekonomik değildir.

• Kotalı çıkışlarda otomatik medya indirmeyi kapatın veya yalnızca Wi-Fi ile sınırlayın.
• Büyük dosyaları kararlı bir çıkış üzerinden gönderin ve aktarım sırasında rotasyonu devre dışı bırakın.
• Aynı anda çok sayıda aktarım başlatmayın; eşzamanlı bağlantı limitinin üstündeki istekler sıraya girer.
• Aylık tüketimi panelden izleyin ve beklenmedik sıçramaların kaynağını araştırın.