EA SPORTS FC Proxy: Maç Trafiği Nereden Geçer, Kural Nereye Yazılır?

Futbol oyunlarında proxy tartışması neredeyse her zaman yanlış yerden başlar: kurulumdan değil, beklentiden. Oysa doğru sıra tersidir. Önce oyunun ağda kaç ayrı iş yaptığını, sonra bu işlerin hangi taşıma katmanını kullandığını, en sonda da yazacağınız kuralın bu katmanların kaçına dokunduğunu bilmeniz gerekir.

Seri boyunca değişmeyen bir ayrım var: hesap, mağaza ve indirme tarafı düz TCP üzerinde HTTPS konuşur; maçın kendisi ise gecikmeye duyarlı, küçük ve sık paketlerle çalışır ve bu paketler çoğunlukla UDP taşınır. Bir HTTP proxy’si CONNECT ile yalnızca TCP tüneli açabildiği için ikinci grup, siz ayar yapmış olsanız bile kuralın dışında kalır.

Bu sayfa bir vaat listesi değil, bir kapsam haritasıdır. Neyin çalışacağını, neyin çalışmayacağını ve bir şeyin çalışmadığını nasıl doğrulayacağınızı gösterir. Oyunun hizmet şartlarına uyum her durumda kullanıcının sorumluluğundadır.

Hesap trafiği ile maç trafiği aynı yoldan gitmez

Oyunu başlattığınızda kurulan ilk bağlantı hesap tarafıdır. İstemci kimlik uç noktasına bir TLS el sıkışması yapar, cihazda saklı bir oturum jetonuyla kendini tanıtır ve karşı tarafta görünen adres o an hangi hattan çıkıyorsanız onun adresidir. Proxy kullanıyorsanız görünen adres proxy sunucusunun adresi olur; jetonun kendisi değişmez, çünkü jeton cihazınızda durur.

İkinci akış mağaza, katalog ve hesap yönetimi istekleridir. Bunlar sıradan HTTPS çağrılarıdır ve bir tarayıcı isteğinden davranış olarak ayrılmazlar. Ultimate Team’in tarayıcı üzerinden kullanılan yardımcı uygulaması da bu sınıfa girer; tarayıcıya yazdığınız bir kural bu isteklere sorunsuz uygulanır.

Üçüncü akış maçın kendisidir ve karakteri tamamen farklıdır. Oyuncu girdisi, top pozisyonu ve senkronizasyon verisi saniyede çok sayıda küçük paketle taşınır. Burada önemli olan bant genişliği değil, paketin gidip dönme süresi ve düzenliliğidir. Bu nedenle bu trafik gecikmeye duyarlı taşıma tercih eder ve HTTP CONNECT tüneli gibi TCP tabanlı bir yapıya kendiliğinden girmez.

Pratikteki sonuç şudur: kuralı yazarsınız, giriş çalışır, mağaza açılır, indirme başlar — ama maç tarafında hiçbir şey değişmez. Bu bir arıza değil, kapsamın doğal sınırıdır.

Kural neyi kapsar, neyi kapsamaz?

Kapsamın sınırı protokol seçiminde belirlenir. HTTP proxy uygulama katmanında durur ve şifreli trafiği yalnızca bir TCP tüneli açarak taşır; UDP taşıyamaz. SOCKS5 ise taşıma katmanında çalışır ve UDP ASSOCIATE yöntemiyle UDP taşıyabilir. Ancak bu yeteneğin devreye girmesi için iki şart birden gerekir: proxy sunucusunun bu yöntemi sunması ve oyun istemcisinin onu kullanacak biçimde yazılmış olması.

İkinci şart sahada çoğu zaman karşılanmaz. Masaüstü ve konsol oyun istemcilerinin büyük bölümü kendi ağ yığınını kullanır, sistemdeki proxy tanımını hiç okumaz ve SOCKS5’in UDP yeteneğine dair bir ayar sunmaz. Yöntemin nasıl çalıştığı ve nerede tıkandığı SOCKS5 UDP desteği yazısında ayrıntılı anlatılıyor.

Konsol tarafında tablo biraz daha dar. Bazı konsolların ağ kurulum sihirbazında bir HTTP proxy alanı bulunur; bu alan sistemin web isteklerini ve mağaza taraflı trafiği kapsar, oyunun gerçek zamanlı paketlerini kapsamaz. Yani konsola proxy yazmak “tüm oyun trafiği proxy üzerinden geçiyor” anlamına gelmez.

Eş-eş bağlantı, NAT tipi ve delik açma denemeleri

Seride birebir çevrimiçi maçların bir bölümü tarihsel olarak eş-eş (peer-to-peer) bağlantıyla oynanmıştır; hangi modun bu yapıyı kullandığı sürümden sürüme ve moddan moda değişir. Eş-eş bir maçta veri merkezde duran bir sunucudan geçmez, iki istemci birbirine doğrudan konuşur. Bu, bağlantı kalitesini iki tarafın hattına ve NAT davranışına bağlar.

NAT, yerel ağınızdaki özel adresleri tek bir genel adrese çeviren mekanizmadır; proxy ile NAT arasındaki fark tam olarak burada belirginleşir: NAT otomatik bir adres çevirisi, proxy ise bilinçli bir yönlendirme kararıdır. Oyun ve konsol arayüzlerinde gördüğünüz “açık, orta, katı” gibi NAT tipi etiketleri, dışarıdan gelen bir bağlantının yerel oturumunuzla eşleşip eşleşemeyeceğini özetler.

Delik açma (hole punching) bu tabloyu çözmek için kullanılan standart yöntemdir: iki taraf da dışarı doğru birer UDP paketi gönderir, kendi NAT tablolarında geçici bir eşleme oluşur ve karşı tarafın yanıtı bu eşleme sayesinde içeri girebilir. Eşlemenin her hedef için yeniden kurulduğu simetrik NAT yapılarında ve operatörün birden çok aboneyi aynı genel adreste topladığı CGNAT hatlarında bu yöntem zorlaşır.

Proxy bu denklemi iyileştirmez. Bir TCP tüneli, istemcinin kendi UDP eşlemesini değiştirmez; araya konan ikinci bir katman teşhisi zorlaştırır. Bu sorunun doğru adresi ağ tarafıdır: yönlendiricide port yönlendirme veya UPnP davranışını gözden geçirmek, CGNAT arkasındaysanız sağlayıcınızla bunu konuşmak.

Aktarılan verinin ağırlığı nereye düşer?

Kotalı bir çıkış kullanıyorsanız maliyetiniz oynadığınız süreyle değil, indirdiğiniz paketlerle belirlenir. Sezon güncellemeleri, kadro ve içerik paketleri tek seferde yüksek hacim üretir; maç içi paketler ise küçük olduğu için aynı sürede çok daha az veri taşır. Bu yüzden “proxy üzerinden oynadım, kotam bitti” cümlesinin arkasında neredeyse her zaman bir güncelleme günü vardır.

Doğru planlama için önce sınıfları ayırın, sonra her sınıfın proxy kapsamına girip girmediğine karar verin. Aşağıdaki tablo bu ayrımı özetliyor; hesaplama yöntemi için bant genişliği hesaplama yazısına bakabilirsiniz.

Buradan çıkan pratik karar şudur: indirmeyi kapsam dışında bırakmak çoğu kurulumda hem daha ucuz hem daha hızlıdır. İstemciyi Steam üzerinden yönetiyorsanız indirme işini olağan hattınızda bırakıp yalnızca tarayıcı tarafını yönlendirmek, kapsamı daraltmanın en temiz yoludur.