Proxy Gecikme Ölçümü: Latency Testi Nasıl Yapılır?

Gecikmenin dört bileşeni: DNS, TCP, TLS ve ilk bayt

Proxy üzerinden giden bir HTTPS isteği dört ardışık beklemeden oluşur. Birincisi DNS çözümlemesi: istemci proxy sunucusunun adını IP’ye çevirir; IP ile bağlanıyorsanız bu süre sıfıra yakındır. İkincisi TCP bağlantısı: istemci ile proxy arasındaki üçlü el sıkışma, yani sizinle proxy sunucusu arasındaki fiziksel mesafenin bedeli. Üçüncüsü TLS el sıkışması: HTTPS hedeflerde şifreli kanal proxy üzerinden hedefe kadar kurulur; bu adım proxy ile hedef arasındaki mesafeyi de içerir. Dördüncüsü ilk bayt (TTFB): hedef sunucunun isteği işleyip ilk yanıt baytını göndermesi.

Bu ayrım önemlidir, çünkü dört bileşenden yalnızca ikisi proxy seçiminizle değişir. TCP süresi sizin ile proxy lokasyonu arasındaki mesafeye bağlıdır; TLS süresi proxy ile hedef arasındaki mesafeye. DNS süresi istemci tarafındadır, ilk bayt süresi ise hedef sunucunun kendi hızıdır. Toplam süreyi tek sayı olarak ölçmek, hangi bileşenin büyüdüğünü gizler.

Datacenter proxy’lerde TCP ve TLS bileşenleri genellikle öngörülebilirdir, çünkü çıkış sunucu hattındadır ve bant genişliği sabittir. Değişkenlik daha çok lokasyon seçiminden gelir: Frankfurt’taki bir hedefe Almanya çıkışlı proxy ile Kanada çıkışlı proxy arasındaki fark, TLS bileşeninde doğrudan görünür.

Ölçüm aracı: curl ile beş zaman damgası

curl, her isteğin zaman damgalarını -w (write-out) seçeneğiyle verir. Kullanılacak beş değişken şunlardır: time_namelookup (DNS bitti), time_connect (TCP bitti), time_appconnect (TLS bitti), time_starttransfer (ilk bayt geldi) ve time_total (yanıt tamamlandı). Her değer isteğin başından itibaren saniye cinsinden kümülatiftir; bileşen süresi, ardışık iki değerin farkıdır.

Komutun iskeleti şöyledir: curl -x http://kullanici:sifre@proxy-host:port -o /dev/null -s -w "dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n" https://hedef.site/. -o /dev/null gövdeyi atar, -s ilerleme çubuğunu kapatır. SOCKS5 kullanıyorsanız -x socks5h://... yazın; h harfi DNS çözümlemesini proxy tarafına taşır ve dns bileşenini istemci tarafından kaldırır.

Aynı komutu proxy olmadan, -x parametresini kaldırarak da çalıştırın. Bu sizin referans ölçümünüzdür: proxy’nin eklediği gerçek maliyet, iki ölçüm arasındaki farktır. Referans ölçümü olmadan “proxy yavaş” demek mümkün değildir, çünkü hedefin kendisi yavaş olabilir.

Windows PowerShell’de curl adı farklı bir komuta takma ad olarak tanımlıdır; curl.exe yazarak gerçek curl’ü çağırın ve tırnak içindeki yüzde işaretlerini olduğu gibi bırakın.

Güvenilir ölçüm için yedi kural

Bir: Isınma isteğini sayma. İlk istek DNS önbelleği boşken ve bağlantı havuzu kurulmamışken gider; her zaman daha yavaştır. İlk ölçümü atın.

İki: En az on tekrar yapın ve medyanı alın. Ortalama tek bir yavaş isteğe göre savrulur; medyan tipik deneyimi gösterir. Onuncu ile doksanıncı yüzdelik arasındaki fark da ayrı bir bilgidir: geniş aralık, kararsız bir yol anlamına gelir.

Üç: Aynı hedefi, aynı yolu ve aynı istek türünü kullanın. Ana sayfa ile API ucu farklı sürelerde yanıt verir; karşılaştırdığınız iki proxy’yi aynı URL ile test edin.

Dört: Aynı saat diliminde ölçün. Hedef sunucunun yükü ve ara ağların yoğunluğu gün içinde değişir. Sabah ölçülen proxy A ile akşam ölçülen proxy B kıyaslanamaz.

Beş: Rotating üründe oturumu sabitleyin ya da çıkış IP’sini kaydedin. Her istekte farklı çıkış sunucusundan geçiyorsanız ölçtüğünüz şey tek bir proxy değil, havuzun dağılımıdır. Bu da değerli bir bilgidir, ama ne ölçtüğünüzü bilmeniz gerekir.

Altı: Gövdeyi indirmeyin. time_total sayfanın boyutuna bağlıdır ve gecikmeyle ilgisi yoktur; karşılaştırmada time_starttransfer esas alınır. HEAD isteği (-I) bazı hedeflerde farklı işlendiği için GET ile -o /dev/null daha güvenilirdir.

Yedi: Sonuçları kaydedin. Tarih, saat, proxy lokasyonu, hedef, on tekrarın medyanı ve doksanıncı yüzdeliği tek satırda tutulursa bir ay sonra aynı testi tekrarlayıp bozulmayı görebilirsiniz.

Örnek: üç lokasyon, bir hedef, on tekrar

Varsayımlar: hedef Frankfurt’ta barındırılan bir e-ticaret sitesi, istemci İstanbul’da, test edilen üç static IPv4 datacenter çıkışı Almanya, Hollanda ve ABD. Her lokasyon için on istek gönderilip medyan alınıyor. Aşağıdaki sayılar yöntemi göstermek için seçilmiş varsayımsal değerlerdir, ölçüm sonucu değildir.

Almanya çıkışı: tcp 45 ms, tls 60 ms, sunucu 120 ms. Hollanda çıkışı: tcp 50 ms, tls 70 ms, sunucu 120 ms. ABD çıkışı: tcp 150 ms, tls 240 ms, sunucu 120 ms. Proxy’siz referans: tcp 55 ms, tls 85 ms, sunucu 120 ms.

Okuma şöyle yapılır. Sunucu süresi üç lokasyonda da aynı; bu bileşen hedefe aittir ve proxy ile değişmez. Almanya ve Hollanda referanstan bile hızlı görünüyor, çünkü datacenter çıkışı hedefe İstanbul’daki istemciden daha yakın ve TLS el sıkışması kısa mesafede tamamlanıyor. ABD çıkışında TLS süresi dört kat; bu, hedef ile proxy arasındaki okyanus aşırı mesafenin bedelidir ve hiçbir ayar bunu kapatmaz.

Karar: hedef Avrupa’daysa Avrupa çıkışı. Almanya ile Hollanda arasındaki 15 milisaniyelik fark, tekrarlar arasındaki doğal dalgalanmanın içindedir; iki lokasyon da uygundur ve seçim fiyat ya da subnet çeşitliliğine göre yapılabilir. ABD çıkışı yalnızca hedef ABD trafiği bekliyorsa ya da yerel fiyat ve içerik ABD’den görülmek isteniyorsa anlamlıdır; o zaman gecikme bilinçli olarak ödenen bir bedeldir.

Sonuçları yorumlama: hangi bileşen yüksekse ne yapılır

DNS yüksek (100 ms üzeri): İstemci tarafındaki çözümleyici yavaş. Proxy’ye alan adı yerine IP ile bağlanın ya da SOCKS5 ile socks5h şemasını kullanıp çözümlemeyi proxy tarafına bırakın. Proxy ürünü değiştirmek bunu düzeltmez.

TCP yüksek, TLS normal: Siz ile proxy sunucusu arası uzak. Kendi konumunuza yakın bir proxy lokasyonu seçin. Hedefe yakınlık ikinci planda kalır, çünkü TCP el sıkışması her yeni bağlantıda tekrar ödenir; bağlantı havuzu (keep-alive) kullanan istemciler bu maliyeti seyrekleştirir.

TLS yüksek, TCP normal: Proxy ile hedef arası uzak. Hedefe yakın bir çıkış lokasyonu seçin. Statik ürünlerde bu, paketin ülkesini değiştirmek demektir; rotating IPv4’te ülke parametresini hedefe göre ayarlamak yeterlidir.

Sunucu süresi yüksek, diğerleri normal: Hedef yavaş. Proxy’nin yapabileceği bir şey yoktur. İstek sayısını azaltmak, koşullu istek kullanmak ya da yoğun olmayan saatlere kaymak çözümdür.

Tekrarlar arası aralık geniş (medyan 80 ms, doksanıncı yüzdelik 600 ms): Yol kararsız ya da rotating havuzda farklı çıkışlar karışıyor. Static üründe sağlayıcıya ölçüm kaydıyla başvurun; rotating üründe oturumu sabitleyip tek çıkışı yeniden ölçün.

Her bileşen referanstan yüksek ama orantılı: Proxy katmanının kendi işleme maliyeti. Datacenter proxy’de bu pay küçüktür; belirgin biçimde büyükse proxy sunucusunun yükü ya da kimlik doğrulama adımı sorgulanır. Zaman aşımı ve bağlantı hataları ayrı bir konudur ve proxy hataları rehberinde anlatılıyor.

DatacenterProxy lokasyonları ve gecikme kararı

Katalogdaki static IPv4 datacenter paketleri beş ülkede sunulur: ABD, Birleşik Krallık, Hollanda, Almanya ve Kanada. Rotating IPv4 datacenter 180’den fazla lokasyonu kapsar ve çıkış ülkesi istek bazında seçilir. Static IPv6 datacenter 19 ülkede, rotating IPv6 datacenter 9 ülkede paket sunar. Lokasyon listesi ürün sayfalarında güncel tutulur; buradaki sayılar bu rehberin yazıldığı tarihteki kataloğu yansıtır.

Gecikme kararı için pratik sıra şudur: önce hedefin barındırıldığı bölgeyi öğrenin (hedefin IP’sini sorgulayarak), sonra o bölgeye en yakın katalog ülkesini seçin, ardından yukarıdaki yöntemle on tekrarlı ölçüm yapıp medyanı kaydedin. Static paket almadan önce aynı ülkedeki rotating çıkışla ölçüm yapmak, ülkenin uygun olup olmadığını düşük maliyetle gösterir.

Lokasyon kararına gecikmenin yanında hedefin hangi ülke trafiğini beklediği ve yerel içerik gereksinimleri de girer. Bu başlıklar proxy lokasyonu seçimi rehberinde ayrıca anlatılıyor. Hız ve güvenilirlik ölçütlerinin tamamı için hızlı ve güvenilir datacenter proxy seçimi rehberine bakın.