Rise of Kingdoms İçin Proxy: Ölçüm, Gecikme ve Sınırlar

Bu oyunun ağ profili ilginç bir orta noktada durur. Harita üzerinde sürekli hareket eden birlikler ve canlı olaylar vardır, ama bunların hiçbiri nişancı oyunlarındaki gibi kare kare senkronizasyon gerektirmez. Bir yürüyüş emri verildiğinde istemci sunucuya bir niyet bildirir, sunucu sonucu döndürür ve arayüz bu sonucu canlandırır. Aradaki birkaç on milisaniye oynanışın adaletini değiştirmez.

Buna karşılık bağlantı kalitesi hissedilir. Kopan bir bağlantı, ittifak sohbetinin durması ya da bir olay ekranının yüklenmemesi doğrudan oyun deneyimine yansır. Sorun burada başlar: kullanıcı “kötü bağlantı” der, ama kötü olanın ne olduğunu söyleyecek bir ölçüm yoktur. Gecikme mi yüksek, kayıp mı var, yoksa yalnızca tek bir uç nokta mı yanıt vermiyor?

Aşağıdaki bölümler bu soruyu sırayla ele alıyor. Önce hangi trafiğin bir tünelden geçebileceği, sonra ölçümün nasıl yapılacağı, ardından sonucun nasıl okunacağı ve en sonunda proxy kararının hangi durumlarda gerçekten anlamlı olduğu.

Tünel neyi taşır, neyi taşıyamaz?

Bir HTTP proxy’nin açtığı CONNECT tüneli TCP taşır. Hesap girişi, harita durumu çağrıları, ittifak listeleri, olay ekranları ve mağaza sayfaları bu sınıfa girer; hepsi şifreli birer TCP oturumudur ve tünelden sorunsuz geçer. Bu, oyunun gördüğünüz ekranlarının büyük bölümü demektir.

Tünelin dışında kalanlar ise UDP taşıyan akışlardır. Sesli sohbet, bazı gerçek zamanlı bildirim kanalları ve HTTP/3 kullanan içerik istekleri bu gruptadır. SOCKS5’in UDP ASSOCIATE yöntemi teorik olarak bunları taşıyabilir, ama üç koşulun aynı anda sağlanması gerekir: proxy sunucusu yöntemi açmış olmalı, istemci SOCKS5 konuşabilmeli ve aradaki ağ bu ilişkilendirmeye izin vermelidir. Mobil oyun istemcilerinde üçünün birden sağlandığı kurulum yaygın değildir.

Bu ayrımın teşhis açısından değeri büyüktür. Yalnızca UDP taşıyan bir işlev bozuluyorsa sorun proxy kapsamının dışındadır ve orada proxy ayarı değiştirmek hiçbir şeyi değiştirmez. Tersine, giriş ve menü ekranları takılıyorsa sorun TCP tarafındadır ve kural doğrudan ilgilidir. Protokol seçiminin genel çerçevesi için proxy protokolü seçim rehberi iyi bir başlangıçtır.

Üçüncü bir ayrıntı alan adı çözümünün nerede yapıldığıdır. HTTP proxy kullanırken istemci hedefi CONNECT sunucu.example:443 biçiminde bildirir ve çözümü proxy üstlenir. SOCKS5 ise hedefi hem düz IP hem de alan adı biçiminde kabul eder; hangisinin gönderileceğine istemcinin kendi ayarı karar verdiğinden, çözümün nerede yapıldığı protokolün değil yapılandırmanın sonucudur. Çözüm sizin ağınızda yapıldığında hedef alan adları yerel sunucunuza görünür; ayrıca size yakın bir içerik düğümü seçilirken bağlantı başka bir ülkeden kurulur ve yol gereksiz yere uzar. Ölçüm yaparken bu ayrımı bilmek, aynı çıkışın neden iki farklı istemcide farklı sonuç verdiğini açıklar.

Paket kaybını hangi araçla ölçmeli?

En yaygın hata, tek bir ölçüm aracına bakıp karar vermektir. Üç farklı araç üç farklı soruya cevap verir ve birbirinin yerine geçmez. Basit bir yankı testi, bir adresin size ne kadar sürede yanıt verdiğini ve kaç paketin kaybolduğunu söyler. Rota izleme aracı, paketlerin hangi düğümlerden geçtiğini gösterir. Sürekli çalışan bir izleme aracı ise sorunun zamana bağlı olup olmadığını ortaya çıkarır.

Ölçümün üç kuralı vardır. Birincisi süre: on paketlik bir test, dakikalar boyunca aralıklı yaşanan bir sorunu yakalayamaz; en az birkaç yüz paket üzerinden ölçün. İkincisi tekrar: aynı testi günün farklı saatlerinde yapın, çünkü paylaşımlı hatlarda akşam saatleri ile sabah saatleri arasında gerçek bir fark vardır. Üçüncüsü karşılaştırma: proxy açıkken ve kapalıyken aynı testi yapmadan ek durağın etkisini bilemezsiniz.

Kendi çıkışınızı sınamak için ping testi ve proxy kontrol aracı hızlı bir ilk bakış verir; bunlar oyunun sunucusunu değil, kullandığınız çıkışın erişilebilirliğini ve tepkisini ölçer. Yöntemin daha geniş anlatımı proxy hızı nasıl test edilir yazısındadır.

Ölçüm sonucunu doğru okumak

Rota izleme çıktısında ara düğümlerden birinin yanıt vermemesi, orada kayıp olduğu anlamına gelmez. Birçok ağ ekipmanı kendisine yönelen kontrol paketlerini düşük öncelikli sayar ya da hiç yanıtlamaz; buna karşılık üzerinden geçen trafiği eksiksiz iletir. Okumanın kuralı basittir: ara satırlardaki yüzdeler değil, son satırdaki sonuç anlamlıdır. Uç noktada kayıp yoksa aradaki yıldızlar genellikle gürültüdür.

İkinci yaygın yanılgı, kablosuz bağlantıyı denklemin dışında bırakmaktır. Kayıpların önemli bir bölümü ev içindeki kablosuz bağlantıda, komşu ağlarla aynı kanalı paylaşmaktan ya da cihazın yönlendiriciye uzak olmasından doğar. Bunu ayırmak için ölçümü bir kez kablolu bağlantıda tekrarlayın; kayıp kayboluyorsa aradığınız şey proxy değil, kablosuz ağ düzenlemesidir.

Üçüncüsü, kaybın nerede oluştuğunu bilmeden çözüm seçmektir. Erişim hattınızda oluşan bir kaybı proxy ortadan kaldırmaz; trafiği yine aynı hattan geçirirsiniz, üstelik bir durak daha eklemiş olursunuz. Proxy’nin anlamlı olabileceği tek kayıp türü, yalnızca belirli bir güzergâhta oluşan ve farklı bir çıkış kullanıldığında o güzergâhtan kaçınılabilen kayıptır. Bunu da ancak karşılaştırmalı ölçüm gösterir.

Gecikme ve kayıp kavramlarının birbirine karışmaması için proxy latency nedir yazısı iki ölçüyü ayrı ayrı tanımlıyor. Mobil hatlarda değişkenliğin neden daha yüksek olduğu ise mobil proxy hızı ve gecikmesi yazısında ele alınıyor.

Ek durağın toplam süreye katkısı

Bir isteğin toplam süresi tek bir parçadan oluşmaz. Cihazınızdan yönlendiriciye kadar olan yerel bölüm, erişim hattınızın taşıdığı bölüm, omurgadaki taşıma ve sunucunun isteği işleme süresi üst üste binerek toplamı oluşturur. Proxy kullandığınızda bu zincire iki yeni parça eklenir: sizinle proxy arasındaki mesafe ve proxy ile hedef arasındaki mesafe.

Bunun doğal sonucu, toplam sürenin çoğu kurulumda uzamasıdır. Proxy pingi düşürmez; aksine ek bir durak ekler. Bu cümleyi tersine çeviren pazarlama anlatımları teknik olarak doğru değildir. Tek istisna, varsayılan rotanızın gereksiz uzun olduğu ve proxy’nin hedefe daha doğrudan bağlanan bir omurgada bulunduğu durumdur; bu bir kural değil, ölçülmeden varsayılamayacak bir istisnadır. Konunun tartışması proxy oyun pingini düşürür mü yazısında.

Pratik karar şudur: eğer amacınız tepki süresini iyileştirmekse proxy yanlış araçtır ve önce kendi hattınızdaki değişkenleri düzeltmek gerekir. Eğer amacınız sabit bir adresten çıkmak, kurumsal bir ağdan geçmek ya da bir içeriğin başka bir bölgede nasıl göründüğünü doğrulamaksa proxy doğru araçtır ve eklediği gecikmeyi kabul edilebilir bir maliyet olarak hesaba katarsınız.

Eşzamanlı bağlantı sayısı da toplam deneyimi etkileyen ayrı bir değişkendir. Aynı çıkıştan birden fazla cihaz ya da birden fazla uygulama geçiyorsa tavan beklenenden çabuk dolar ve sonuç kullanıcıya “yavaşlama” olarak görünür; ayrıntısı eşzamanlı bağlantı limiti yazısında.