Aynı tüneldeki iki VPN hız testi neden uyuşmuyor
Yeni bir çıkış test sunucusunu değiştirir, yavaş başlangıç ise sonucu. Hedefi sabitleyin, akış sayısını eşitleyin ve işlemci maliyetini bağlantı kapasitesinden ayırın.
İki çalıştırma, tek tünel ve sayılar üç kat farklı. Tünel aralarında değişmedi. Değişen ölçüm: görünen konumunuza göre sunucu seçen bir test sitesi, boruyu bir yavaş başlangıcın mı yoksa altısının mı doldurduğunu belirleyen akış sayısı ve yol düzgün kullanılmaya başlamadan bitecek kadar kısa bir süre. Hız testleri yanlış değil, ama onlar insanların kendilerine sorduğu sorudan daha dar bir soruya yanıt veriyor.
Yeni çıkış adresi testin hedefini değiştirir
Çoğu test sitesi ölçüm sunucusunu otomatik seçer ve bunu kısmen bağlantınızın nereden geldiği görünüşüne bakarak yapar. Tüneli açın, görünen ülkeniz değişir, böylece seçilen sunucu değişir ve karşılaştırma artık iki farklı konağa giden iki farklı rotayı kapsar.
Sonuç hiç de bir VPN ölçümü değil. Seçmediğiniz bir sunucuya giden yolunuzun ölçümüdür ve iki çalıştırma arasındaki farka tünelin yaptığı herhangi bir şeyden çok o sunucunun eşlemesi egemen olabilir.
Başka bir şeyi değiştirmeden önce hedefi sabitleyin. Her güvenilir araç sunucuyu açıkça seçmenize izin verir ve vermediğinde sonuç sayfası genellikle kullanılanı adlandırır; bu da iki çalıştırmanın karşılaştırılamaz olduğunu fark etmeye yeter. Sitenin ne gördüğünü, seçimine güvenmeden önce doğrulayın:
curl -sS https://ipinfo.io/json | grep -E '"ip"|"org"|"country"'
Ülke çalıştırmalar arasında değiştiyse testin sonradan seçtiği her şey de değişti. Gözlenen çıkışı her sonucun yanına yazın, karışıklık büyük ölçüde kaybolur.
Yavaş başlangıç, kısa testlerin çoğu bittikten sonra biter
Bir TCP bağlantısı bağlantı hızıyla başlamaz. Küçük bir tıkanıklık penceresiyle başlar, her gidiş dönüşte kabaca ikiye katlar ve yolun kapasitesine ancak birkaç gidiş dönüşten sonra ulaşır. Yüksek gecikmeli bir yolda on saniyelik bir test, ömrünün önemli bir bölümünü o tırmanışta geçirebilir.
Bu yüzden daha yüksek gecikmeli bir tünel kısa bir testte hak ettiğinden kötü puan alır ve bu yüzden daha uzun bir çalıştırma herhangi bir yapılandırma değişikliği olmadan daha yüksek bir sayı bildirir. RFC 6349 aktarım çerçevesi bunu açıkça ele alır ve bu yüzden ciddi ölçümler kararlı duruma ulaşacak kadar uzun sürer. Uydu yolunda beş saniyelik bir çalıştırma yolu değil, hızlandırıcıyı ölçer.
Tek bir sayıya güvenmek yerine bağlantının evrelerine bakın. Curl her aşamayı ayrı bildirir, böylece zamanın el sıkışmaya, tırmanışa mı yoksa aktarıma mı gittiğini görürsünüz:
curl -sS -o /dev/null -w 'dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} total=%{time_total} bytes/s=%{speed_download}\n' \
https://mirror.example.net/testfile.bin
Aynı hedefe arka arkaya iki kez çalıştırın. İkinci çalıştırma çok daha hızlıysa yolu değil tırmanışı ölçüyordunuz ve yalnızca ilkini kullanan her karşılaştırma şüphelidir.
Bir akış ve altı akış farklı şeyleri ölçer
Tek bir TCP akışı havada tutabildiği pencereyle sınırlıdır; bu da kabaca gidiş dönüş süresinin hızla çarpımıdır. Uzun bir yolda bu çarpım bir akışın kullanacağını aşar, bu yüzden tek bir indirme var olan kapasiteyi düşük bildirir. Altı paralel akış bu boşluğu doldurur ve daha büyük bir sayı üretir.
iperf3 -c speed.example.net -t 20
iperf3 -c speed.example.net -t 20 -P 6
mtr -rwc 50 speed.example.net
Her iki sayı da doğru. Tek akış sayısı bir indirmenin ne yapacağını söyler, bir tarayıcı sekmesinin genelde aldığı budur. Paralel sayı yolun toplamda ne taşıyabileceğini söyler, bir torrent ya da çok parçalı indirme bunu kullanabilir. Birini ötekiymiş gibi anmak, sağlıklı bir tünelin sebepsiz değiştirilme yoludur.
Paralel bir sonucu tek akış sonucuyla karşılaştırmak, insanların VPN hızlarını yarıya indirdi sonucuna varmasının en yaygın yoludur. Yöntemi eşitleyin, sonra karşılaştırın. Üçüncü komuttaki iz eksik bağlamı ekler: yüksek titremeli bir yol her iki kipte de tutarsız sonuç verir ve hiçbir akış sayısı bunu düzeltmez.
Şifreleme işlemci zamanına, kapsülleme bayta mal olur
Bağlantı ne kadar hızlı olursa olsun her paket üzerinde iki mekanizma çalışır. Şifreleme bayt başına işlemci tüketir ve kapsülleme, bağlantının yine de taşımak zorunda olduğu başlık baytlarını ekler. İkisi de bir tavan olarak görünür ve belirtileri farklıdır.
İşlemci tavanı bir plato olarak görünür: kaç akış eklerseniz ekleyin aktarım artmayı bırakır ve bağlantı boştayken makinenin işlemcisi meşguldür. Küçük bir yönlendiricide ya da telefonda bu genellikle gerçek sınırdır ve bu yüzden hızlı bir hat yine de mütevazı bir tünel verebilir.
Bayt maliyeti daha küçük ama sabittir. Fazladan başlıklar paket başına daha az faydalı yük demektir ve sabit en büyük iletim birimi olan bir yolda büyük aktarımlarda yavaş ortalama yerine duraklama olarak görünen parçalanma ya da kara delik tetikleyebilirler.
| Observation | Likely mechanism | What to measure |
|---|---|---|
| Throughput flat as streams increase | CPU per packet on one core | Per-core utilisation during the test |
| Fast small transfers, stalled large ones | MTU and fragmentation | Payload size at which it breaks |
| Good average, unusable calls | Queueing delay behind a full buffer | Latency under load |
Bu üçü sık karıştırılır çünkü kullanıcılar hepsini VPN yavaş diye tanımlar. Yalnızca birincisi daha büyük bir makineye tepki verir, yalnızca ikincisi daha küçük bir MTU'ya, yalnızca üçüncüsü kuyruk yönetimine tepki verir.
Yöntemi kayda yazın
Saklamaya değer bir sonuç cihazı, erişim ağını, çıkışı, ölçüm sunucusunu, yönü, akış sayısını ve süreyi adlandırır. Bunlar olmadan iki sayı karşılaştırılamaz ve tek sayı içeren bir bilet aslında bir ruh halidir.
Kötü çalıştırmaları da saklayın. Bir çıkışın her seferinde duraklama yarattığı bir dizi ortalamadan çok daha bilgilendiricidir ve duraklamalar ortalamaların gizlediği şeydir.
Sonra gerçekten önemsediğiniz şeyi test edin. Amaç büyük bir indirmeyse dosyayı indirin. Amaç bir görüşmeyse boştaki aktarım yerine yük altındaki gecikmeyi ölçün, çünkü bir tünel hız testinde iyi puan alıp yine de her toplantıyı dinlenemez hale getirebilir.