Need for Speed Proxy: Launcher Trafiği, UDP Aktarma ve NAT

Yarış oyunlarında proxy sorusu genellikle tek bir cümleyle sorulur ve o cümle en az üç ayrı soruyu içinde saklar: hesap tarafı mı, indirme tarafı mı, yoksa yarış oturumu mu? Bu üçü aynı süreçte çalışmaz, aynı protokolü kullanmaz ve aynı ayarı okumaz.

Aşağıdaki bölümler bu üç alanı ayırıyor. Önce trafiğin kaç parçaya bölündüğünü, sonra SOCKS5’in UDP aktarma yeteneğinin gerçek sınırlarını, ardından oyuncular arasında doğrudan bağlantı kurulduğunda NAT’ın neden belirleyici hâle geldiğini ele alıyoruz.

Beklentiyi baştan doğru kurmak için bir not: proxy, ağınızın yolunu kısaltan bir araç değildir. Araya bir durak koyar ve bu durak bazı işlerde çok yararlı, bazı işlerde tamamen gereksizdir. Hangisinin sizin durumunuz olduğuna karar vermek bu sayfanın asıl amacı.

Launcher bir şey yapar, oyun istemcisi başka bir şey

Masaüstünde oyunu başlatan ile oyunu oynatan süreç aynı değildir. Launcher hesabınızı doğrular, kütüphanenizi listeler, hak sahipliğini kontrol eder, mağaza vitrinini çeker ve güncellemeleri yönetir. Oyun istemcisi ise çalıştıktan sonra kendi ağ yığınını kullanır ve launcher’ın ayarlarına bakmak zorunda değildir.

Bu iş bölümünün kullanıcı tarafındaki karşılığı şudur: aynı proxy bilgisini nereye yazdığınız, hangi akışın yönlendirileceğini belirler. Launcher’a yazılan bir ayar hesap ve mağaza isteklerini kapsar, yarış oturumunu kapsamaz. Sistem geneline yazılan bir ayar ikisini de kapsamaya çalışır, ama oyun istemcisi kendi soketlerini doğrudan açıyorsa yine kapsam dışında kalabilir.

Kimlik doğrulama tarafında da bir ayrım vardır. Kullanıcı adı ve parola isteyen bir çıkışı kullanabilmek için istemcinin bu bilgileri girecek bir alan sunması gerekir; oyun istemcilerinde böyle bir alan neredeyse hiç bulunmaz. Bu yüzden oyun senaryolarında IP yetkilendirmesi çoğu zaman tek uygulanabilir yöntemdir. İki yöntemin farkı proxy kimlik doğrulama yöntemleri yazısında karşılaştırılıyor.

Kurulum öncesinde şu envanteri çıkarın: hangi süreçler ağ kullanıyor, hangisi proxy ayarı okuyor ve hangisine kural yazma imkânınız var? Bu üç sütunlu küçük liste, sonradan yapılacak teşhisin yarısını baştan halleder.

Yama ve içerik indirme trafiği nereden geçer?

Yarış oyunlarında içerik paketleri büyüktür: araç modelleri, ses dosyaları, çevre varlıkları ve sezon içerikleri düzenli olarak güncellenir. Bu dosyalar bir içerik dağıtım ağından iner ve hangi düğümün seçileceği, isteğin çıkış adresine ve alan adını çözen sunucunun konumuna göre belirlenir.

Proxy devredeyken bu seçim proxy’nin konumuna göre yapılır. Sonuç iki yönlü olabilir: çıkışınız dağıtım ağına yakınsa fark hissedilmez, uzaksa her parça gereksiz bir tur atar ve indirme belirgin biçimde yavaşlar. Kotalı bir çıkış kullanıyorsanız ikinci bir maliyet daha vardır; aktarılan her bayt sizin paketinizden düşer. Aylık planı sayıya dökmek için bant genişliği hesaplama yazısındaki yöntemi kullanabilirsiniz.

Pratik karar basittir: indirmeyi kapsam dışında bırakmak çoğu ev kurulumunda doğru seçimdir. Kurumsal bir ağda ise tersi istenebilir, çünkü oradaki amaç hız değil denetimdir; tüm dış trafiğin tek bir kapıdan geçmesi kayıt ve politika açısından tercih edilir.

SOCKS5 UDP aktarma gerçekte ne yapar, nerede durur?

SOCKS5, kendisinden önceki sürümden farklı olarak UDP taşımak üzere bir yöntem tanımlar. İşleyiş şöyledir: istemci proxy ile bir TCP denetim bağlantısı kurar ve UDP ASSOCIATE isteği gönderir; proxy yanıtında bir aktarma adresi ve port bildirir; istemci bundan sonra datagramlarını küçük bir başlıkla bu adrese gönderir ve proxy paketleri hedefe iletir. Denetim bağlantısı kapanırsa aktarma da sona erer.

Kâğıt üzerinde bu, oyun trafiği için umut verici görünür. Pratikte üç yerde durur. Birincisi sunucu tarafıdır: birçok proxy hizmeti UDP aktarmayı hiç açmaz, çünkü kaynak tüketimi ve kötüye kullanım riski TCP’den farklıdır. İkincisi istemci tarafıdır: oyun istemcilerinin ağ kodunda SOCKS5 UDP çağrısı bulunmaz, dolayısıyla destek olsa bile kullanılmaz. Üçüncüsü ara ağdır: aktarma için açılan UDP portu, yol üzerindeki bir güvenlik duvarında kapalı olabilir.

Bu üç engelden biri bile varsa, SOCKS5 tanımlamak yarış oturumunu proxy üzerinden geçirmez. Protokolün ayrıntısı ve sürümler arası farkı için SOCKS5 UDP desteği ve SOCKS4 ile SOCKS5 farkı yazılarına bakabilirsiniz.

Doğru beklenti şudur: SOCKS5 seçmek kapsamı genişletme ihtimalini açık tutar, garanti vermez. Kurulumdan sonra oyunun gerçekten bu yolu kullanıp kullanmadığını dolaylı olarak sınayın; menüler ile oturumun ayrı ayrı test edilmesi bunun en pratik yoludur.

Eş-eş oturumlar, NAT tipi ve delik açma davranışı

Çevrimiçi yarış oturumları her zaman merkezî bir sunucu üzerinden yürümez. Bazı yapılarda eşleştirme sunucusu yalnızca oyuncuları buluşturur, veri alışverişi ise oyuncular arasında doğrudan kurulur. Hangi modelin kullanıldığı sürüme ve moda göre değişir; resmi belgelerde bildirilmemişse dışarıdan kesinleştirilemez, bu yüzden kurulumu her iki ihtimale de dayanacak biçimde planlamak gerekir.

Doğrudan bağlantı kurulacaksa NAT devreye girer. Ev yönlendiriciniz iç ağdaki adresi dış adrese çevirir ve bu eşleme, siz dışarı bir paket gönderdiğinizde oluşur. Eşleştirme sunucusu iki tarafın dış adres ve portunu birbirine bildirir; iki taraf da aynı anda dışarı paket gönderdiğinde eşlemeler oluşur ve bağlantı kurulur. Bu davranışa delik açma denir ve yönlendiricinin eşleme kuralı öngörülebilirse çalışır.

Öngörülemediğinde iş zorlaşır. Her hedef için farklı bir dış port atayan katı bir NAT’ta ya da operatör düzeyinde paylaşımlı adres kullanılan CGNAT yapılarında eşleme tahmin edilemez; bu durumda oturum bir aktarma sunucusuna düşer ve yol uzar. Mobil çıkışların oyun senaryolarında zayıf kalmasının asıl nedeni de budur. NAT ile proxy arasındaki kavramsal farkı proxy ve NAT karşılaştırması açıklıyor.

Buradan çıkan sonuç net: araya bir proxy koymak NAT davranışını iyileştirmez. Aksine, UDP aktarma kullanılabildiği durumda bile paketler artık proxy’nin adresinden çıkar ve delik açma denklemi bir katman daha karmaşık hâle gelir. Bağlantı sorunları yaşıyorsanız önce yönlendirici tarafına bakın, proxy tarafına değil.

Çıkış türlerinin oyun senaryosundaki profili

Çıkış türü tartışması sosyal medya ve veri toplama işlerinden farklı sonuçlanır. Orada belirleyici olan adresin profili ve havuz çeşitliliğidir; burada belirleyici olan kararlılık ve öngörülebilirliktir. Aynı türün iki senaryoda zıt yönde puan alması bu yüzden normaldir.

Veri merkezi çıkışları kararlı hat ve yüksek bant genişliği sunar; indirme ve denetim senaryolarında en pratik seçenektir. ISP çıkışları sağlayıcı ağında barındığı için statik adres ihtiyacını karşılar ve kararlılığı korur. Residential çıkışlar gerçek abonelik hatlarıdır; bölgesel görünüm doğrulamasında değerlidir, ancak hızı ve sürekliliği sizin denetiminizde değildir. Mobil çıkışlar ise oyun trafiği için en zayıf tercihtir: paylaşımlı yapısı ve değişken gecikmesi yarış oturumunda doğrudan hissedilir.

Bir çıkışı işe almadan önce en az iki ölçüm yapın ve ölçümleri günün farklı saatlerinde tekrarlayın. Paylaşımlı havuzlarda yoğun saat farkı, tek seferlik denemenin gizlediği asıl değişkendir; ortalamadan çok bu dalgalanma rahatsız eder.

Seçimi tek bir cümleye indirgemek gerekirse: indirme ve denetim için veri merkezi, sabit adres için ISP, bölgesel doğrulama için residential, oyun oturumu için ise hiçbiri değil doğrudan bağlantı.

Ölçülebilir olan ve ölçülmeden doğrulanamayan

Proxy tartışmalarında en çok tekrarlanan iddia, bağlantının hızlanacağıdır. Ölçüm bunu genellikle desteklemez: araya konan durak yolu uzatır ve toplam gecikme çoğu kurulumda artar. Varsayılan rotanızın dolambaçlı olduğu nadir durumlarda tersi görülebilir, ancak bu bir kural değil istisnadır ve yalnızca karşılaştırmalı ölçümle anlaşılır.

Ölçebileceğiniz şeyler bellidir: hedefe olan gidiş-dönüş süresi, bu sürenin gün içindeki dalgalanması, indirme hızı ve bağlantının kurulma süresi. Ping testi ilk ikisi için yeterlidir; indirme tarafını dosya bazlı karşılaştırmayla ölçebilirsiniz. Yöntemin ayrıntısı proxy hızı nasıl test edilir yazısında anlatılıyor.

Ölçemeyeceğiniz şeyler de vardır ve bunları iddia hâline getirmeyin: eşleştirmenin sizi hangi oturuma koyacağı, karşı tarafın hattının kalitesi, aktarma sunucusuna düşülüp düşülmeyeceği. Bunlar sizin kontrolünüzde olmayan değişkenlerdir ve bir proxy tercihiyle yönetilmezler.

Ölçüm disiplini basittir: tek değişken değiştirin, aynı hedefe aynı yöntemle bakın, sonucu yazın. Üç ölçüm sonunda elinizde tahmin değil bir tablo olur ve karar da o tabloya dayanır.