Black Desert Online Proxy Kurulumu ve Ağ Davranışı

Black Desert Online tarafında proxy sorusu genellikle iki ayrı ihtiyaçtan doğar: kurumsal ya da kısıtlı bir ağdan çıkarken tutarlı bir adres kullanmak ve bağlantı sorunlarının rota kaynaklı olup olmadığını ikinci bir yoldan sınamak. İkisi de meşrudur, ikisi de aynı teknik gerçeğe çarpar: yönlendirmenin kapsamı.

BDO istemcisi kendi başlatıcısıyla gelir ve dosya denetimi, onarım ile indirme işlerini oyun çalışmadan önce yapar. Bu yüzden “oyunu proxy’ye aldım” demek, çoğu zaman yalnızca bir bileşeni aldım demektir. Kurulumun kalitesi, hangi süreçlerin hangi yoldan çıktığını bilmenizle ölçülür.

Metin boyunca BDO kısaltmasını oyunun tam adıyla birlikte kullanıyoruz; anlatılanlar istemcinin genel ağ davranışına dayanır, sürüm ve bölgeye göre ayrıntılar değişebilir.

İstemcinin açılıştan oyuna kadar geçtiği duraklar

Başlatıcı açıldığında yaptığı ilk iş küçük boyutlu bir sürüm denetimidir. Elinizdeki dosya listesi uzak taraftaki listeyle karşılaştırılır ve fark varsa indirme planı çıkarılır. Bu aşamanın ağ yükü önemsizdir ama gecikmeye duyarlıdır: yavaş bir çıkış burada başlatıcının uzun süre “kontrol ediliyor” durumunda kalmasına yol açar.

İkinci durak indirmedir ve hacmin neredeyse tamamı buradadır. Yama paketleri bir içerik dağıtım ağından çekilir, çok sayıda paralel bağlantı açılır ve hat doldurulmaya çalışılır. Paylaşımlı bir çıkış kullanıyorsanız darboğaz burada ortaya çıkar; ayrıca eşzamanlı bağlantı sınırı olan bir pakette indirici beklenenden yavaş çalışır.

Üçüncü durak giriştir. Kimlik doğrulama isteği yayıncının hesap servisine gider ve kayda geçen adres çıkış adresinizdir. Aynı anda oturum jetonu üretilir; bu jeton IP’ye değil oturuma bağlıdır, yani sonradan adres değişse bile oturumun kimliği aynı kalır.

Dördüncü durak dünya sunucusuyla kurulan sürekli oturumdur. Aktarılan hacim küçüktür, süreklilik ise kritiktir. Hedef odaklı olmayan, oyuncunun nişan ve zamanlama yaptığı bir dövüş sisteminde yarım saniyelik bir duraksama doğrudan oynanışa yansır; bu yüzden çıkış seçiminde ortalama hız değil, kararlılık önemlidir.

UDP aktarma: SOCKS5 ne vaat eder, koşulları nedir?

Proxy protokolleri arasındaki en pratik ayrım taşıma katmanında ortaya çıkar. HTTP proxy, şifreli hedeflere yalnızca TCP taşıyan bir tünel kurabilir; UDP akışları bu tünele hiç girmez. SOCKS5 ise UDP ASSOCIATE komutuyla proxy üzerinde bir aktarma noktası açılmasını ister, ardından datagramlar küçük bir başlıkla sarılarak bu nokta üzerinden gider gelir.

Vaat açık olsa da koşullar zorludur. Aktarmanın çalışması için sağlayıcının UDP’yi açık tutması gerekir ve pek çok sağlayıcı bunu kapalı sunar. Uygulama tarafında da istemcinin SOCKS5 konuşup aktarma istemesi gerekir; oyun istemcilerinin çoğu böyle bir yetenek taşımaz. Son olarak aktarma ayakta kalırken kontrol amaçlı TCP bağlantısının kopmaması gerekir, çünkü o bağlantı düştüğünde UDP yolu da kapanır.

Bir de sessiz bir tuzak vardır: sarmalama her datagrama birkaç bayt ekler. Zaten MTU sınırına yakın çalışan bir akışta bu ek, paketin parçalanmasına ve parçalardan biri kaybolduğunda tamamının işe yaramaz hâle gelmesine yol açar. Sonuçta ölçümde “bağlantı var” görünürken oyunda düzensiz takılmalar yaşanır.

Doğru yaklaşım, protokolün yeteneğini sağlayıcı belgesine bakarak değil, açıkça sorarak teyit etmektir. Ayrıntı için SOCKS5 proxy sayfasına ve UDP desteğinin nasıl çalıştığını anlatan yazıya bakın; yanıt olumsuzsa oyun oturumunu TCP üzerinden taşıyan bir kurulumla yetinmek, çalışmayacak bir yapılandırmayla uğraşmaktan daha hızlıdır.

Yamalar neden büyük ve indirme hızını asıl ne belirler?

BDO istemcisi yüksek çözünürlüklü varlıklar, geniş bir dünya haritası ve sürekli eklenen içerik nedeniyle onlarca gigabayta ulaşan bir kurulum boyutuna sahiptir. Güncellemeler de buna bağlı olarak küçük yamalar değil, bazen gigabayt ölçeğinde paketler hâlinde gelir. Bu tablo proxy kararını doğrudan etkiler: ölçülü bir çıkış üzerinden yapılan tek bir büyük indirme aylık paketin önemli bir kısmını tüketebilir.

İndirme hızını belirleyen etken çoğu kullanıcının sandığından farklıdır. İçerik dağıtım ağları, size hangi düğümü vereceğine karar verirken isteği yapan tarafın değil, alan adını çözen tarafın konumuna bakar. Proxy üzerinden çalışırken alan adının nerede çözüldüğü bu yüzden kritik hâle gelir: çözümü kendi ağınız yaparsa size yakın bir düğüm döner ama bağlantı proxy’nin ülkesinden kurulur ve rota gereksiz yere uzar.

SOCKS5 kullanırken bu davranış istemciye bağlıdır; adres çözümünü proxy’ye bırakan kip ile yerel çözüm yapan kip farklı sonuç üretir. HTTP proxy’de ise istemci hedefi düz metin olarak bildirir ve çözümü proxy yapar, dolayısıyla dönen düğüm proxy’ye yakın olur. İkisi de “yanlış” değildir; yanlış olan hangisinin çalıştığını bilmemektir.

Mekanizmanın ayrıntısı için SOCKS5’te DNS nerede çözülür yazısı ve dağıtım platformu tarafındaki ayarlar için Steam proxy ayarları yazısı işe yarar.

İndirme ve kota planı: dört adımda karar

Kurulumu planlamadan başlatmak, sonradan düzeltilmesi en pahalı hatadır. Önce elinizdeki paketin ne kadar veri içerdiğini ve bunun ne kadarını oyun dışı işler için ayırmanız gerektiğini yazın. Ardından çıkış lokasyonunu, indirme kaynağına değil oyun sunucusuna göre seçin; indirme tek seferlik, oyun oturumu ise süreklidir.

Üçüncü adım kapsam ayrımıdır. Başlatıcıyı ve indiriciyi ölçülü çıkışın dışında bırakmak, oyun oturumunu ise proxy üzerinden geçirmek çoğu kurulumda hem daha ucuz hem daha hızlı sonuç verir. Bunu sistem geneli bir ayarla yapamazsınız; uygulama bazlı kural ya da ayrı bir ağ profili gerekir.

Dördüncü adım doğrulamadır ve atlanmaması gereken tek adımdır. Çıkışın gerçekten değiştiğini IP adresim aracıyla görün, proxy’nin ayakta olduğunu proxy kontrol aracıyla sınayın, alan adı çözümünüzün yerel ağınıza sızmadığını DNS leak testiyle kontrol edin. Doğrulamayı indirme sırasında değil, indirme öncesinde yapın.