iRacing ve Proxy: Ölçüm, Kayıp Teşhisi ve Taşıma Sınırları

iRacing bir oyun kadar bir servistir: üyelik, içerik kütüphanesi, planlanmış oturumlar ve sonuç kayıtları aynı çatı altında çalışır. Bu yapı ağ tarafında da karşılık bulur; tarayıcıdan yönettiğiniz işler ile simülatörün yarış sırasında ürettiği akış bambaşka gereksinimlere sahiptir.

Bir proxy çıkışı bu katmanların hepsine aynı biçimde dokunmaz. Web tarafındaki istekler kolayca tünele girer; içerik indirme girebilir ama genellikle girmemesi daha iyidir; oturum akışı ise çoğu kurulumda tünelin dışında kalır. Aşağıdaki bölümler bu üç davranışı ayrı ayrı ele alıyor ve her birinde neyi ölçmeniz gerektiğini gösteriyor.

Metin boyunca tek bir ilke geçerli: ölçülmeyen şey tartışılmaz. “Bağlantı kötü hissettiriyor” cümlesi bir teşhis değildir; hangi hedefe, hangi saatte, hangi çıkıştan ölçtüğünüzü yazmadan önce ve sonrayı karşılaştıramazsınız.

Servis trafiği hangi katmanlara ayrılıyor?

En üstte tarayıcıdan yürüttüğünüz işler vardır: üyelik yönetimi, içerik satın alma, oturum takvimi ve sonuç sayfaları. Bunların tamamı şifreli HTTP akışlarıdır, gecikmeye toleranslıdır ve bir proxy üzerinden sorunsuz taşınır. Bu katmanda proxy kullanmanın karşılığı hız değil, çıkış adresinizin nereden göründüğüdür.

İkinci katman istemci güncellemesi ve içerik indirmedir. Yeni araç ve pist dosyaları ile sürüm güncellemeleri buradan iner ve aktarılan verinin büyük bölümünü oluşturur. Kotalı bir çıkış kullanıyorsanız bu katmanı tünelin dışında bırakmak neredeyse her zaman daha iyidir; hem bütçe hem de indirme süresi açısından.

Üçüncü katman oturum eşleştirme ve girişidir: hangi sunucunun size atandığı, oturuma kabul, kayıt ve sonuç bildirimi gibi kısa istekler. Dördüncü katman yarış sırasındaki durum akışıdır; araç konumu ve girdi bilgisi sürekli, küçük ve zamana duyarlı paketlerle taşınır. Beşinci katman ise sesli iletişim ve yan araçlardır — oyunun parçası değildir ama aynı hattı paylaşır.

Bu ayrımı akılda tutmak teşhis süresini kısaltır. Bir sorun yaşadığınızda önce hangi katmanda olduğunuzu belirleyin: web sayfası mı açılmıyor, indirme mi takılıyor, oturuma mı katılamıyorsunuz, yoksa oturum içinde mi kopma yaşıyorsunuz? Dördü dört farklı nedene işaret eder.

Ek durak gecikmeye ne yapar, istisna nerede doğar?

Proxy üzerinden giden bir istek iki bacaklı yol izler: siz ile proxy arasındaki mesafe, ardından proxy ile hedef arasındaki mesafe. Toplam süre bu iki bacağın toplamına, üstüne de proxy sunucusunun o anki yüküne eşittir. Üç bileşenin hiçbiri sıfır olmadığı için sonuç çoğu kurulumda doğrudan bağlantıdan yüksek çıkar. Bunu bir kusur olarak değil, kullandığınız yöntemin doğal bedeli olarak okumak gerekir; gecikmenin hangi parçalardan oluştuğu proxy latency yazısında ayrıntılandırılıyor.

İstisna gerçekten vardır ama dar bir koşula bağlıdır: varsayılan rotanız hedefe gereksiz yere uzun bir yoldan gidiyorsa ve proxy sağlayıcısının omurgası daha doğrudan bir yol kullanıyorsa, iki bacaklı yol tek bacaklı dolambaçtan kısa olabilir. Bu bir kural değildir, ölçülmeden varsayılamaz ve aynı hat üzerinde zaman içinde değişebilir. Konunun ayrıntılı tartışması oyunda proxy ve ping yazısında.

Ölçümü kurarken üç şeye dikkat edin. Birincisi, karşılaştırmayı aynı hedefe yapın; iki farklı hedefe yapılan ölçüm hiçbir şey söylemez. İkincisi, seriyi tek atışla değil zamana yayarak alın; tek bir sonuç, o saniyenin fotoğrafıdır. Üçüncüsü, ortalamanın yanında dağılıma bakın: en kötü yüzde birlik dilim, ortalamadan daha çok şey anlatır. Yöntem için proxy hızı nasıl test edilir ve ping testi aracı birlikte kullanılabilir.

Paket kaybını doğru okumak: hangi araç neyi söyler?

Paket kaybı, gecikmeden daha sinsi bir sorundur çünkü ortalama değerlerde görünmez. Saniyede onlarca küçük güncelleme taşıyan bir akışta binde birkaç kayıp bile görünür sıçramalar üretir, oysa aynı hat bir web sayfasını kusursuz açar. Bu yüzden “internetim iyi, hız testi yüksek çıkıyor” cümlesi kayıp teşhisinde işe yaramaz: hız testi kapasiteyi ölçer, sürekliliği değil.

Ara durak kaybı özellikle yanlış anlaşılır. Rota üzerindeki yönlendiriciler kendilerine yönelen kontrol mesajlarını düşük öncelikli işler ve gerektiğinde sınırlar; bu yüzden ortadaki bir durakta yüksek kayıp görünürken uçtan uca ölçüm tertemiz çıkabilir. Karar verirken yalnızca son durağın, yani gerçek hedefin sonucuna bakın. Ortadaki renkli satırlar teşhis değil, gürültüdür.

Proxy’li ve proxy’siz iki seriyi yan yana alın ve aynı saat aralığında karşılaştırın. Fark kaybın kendisinde değil de yalnızca gecikmedeyse, sorununuz taşıma değil mesafedir. Kayıp yalnızca tünel açıkken beliriyorsa çıkışın kapasitesini veya eşzamanlı bağlantı tavanını sorgulayın; bu tavanın nasıl davrandığı eşzamanlı bağlantı limiti yazısında anlatılıyor.

SOCKS5’in UDP aktarımı nereye kadar taşır?

SOCKS5 protokolü, taşıma katmanında duran ve içeriği yorumlamayan bir aracıdır. UDP tarafı için tanımlı bir yöntemi vardır: istemci denetim bağlantısı üzerinden bir aktarım isteği gönderir, sunucu geriye kendi tarafında dinlediği bir aktarım adresi döner ve istemci bundan sonra UDP verisini küçük bir başlıkla sararak o adrese gönderir. Yöntem kâğıt üzerinde temizdir; işleyişin ayrıntısı SOCKS5 UDP desteği yazısında adım adım anlatılıyor.

Pratikteki sınır üç yerden gelir. Birincisi sağlayıcıdır: birçok proxy hizmeti kaynak tüketimi ve kötüye kullanım nedeniyle UDP aktarımını kapalı tutar, yalnızca TCP bağlantılarına izin verir. İkincisi istemcidir: bir uygulamanın SOCKS5 alanına adres yazabiliyor olması, o uygulamanın UDP’sini de aracıya devredeceği anlamına gelmez; çoğu istemci kendi soketini doğrudan açar. Üçüncüsü ağdır: aradaki güvenlik duvarları aktarım adresine giden UDP’yi kesebilir.

Bir noktayı da not edin: alan adı çözümlemesi bu tabloyu değiştirir. Adresin sizin tarafınızda mı yoksa aracı tarafında mı çözüldüğü, hangi sunucuya yöneleceğinizi etkileyebilir; iki davranışın farkı SOCKS5’te DNS nerede çözülür yazısında ele alınıyor. Yanlış tarafta çözülen bir ad, size yakın seçilmiş bir uç ile uzaktan çıkan bir tünelin uyumsuz eşleşmesine yol açar.

Sonuç olarak UDP aktarımı bir imkândır, varsayılan değildir. Kurulumunuzun bunu gerçekten kullanıp kullanmadığını varsayımla değil gözlemle doğrulayın: tünel açıkken oturumun davranışında bir değişiklik yoksa, büyük olasılıkla o akış zaten tünelin dışından geçiyordur.