Mengapa dua uji kecepatan VPN pada terowongan yang sama tidak sepakat

Dua kali jalan, satu terowongan, dan angkanya berbeda tiga kali lipat. Terowongannya tidak berubah di antara keduanya. Yang berubah adalah pengukurannya: situs uji yang memilih server berdasarkan lokasi tampak Anda, jumlah aliran yang menentukan apakah satu awal lambat atau enam yang mengisi pipa, dan durasi yang cukup singkat untuk berakhir sebelum jalur bahkan dipakai dengan benar. Uji kecepatan tidak salah, tetapi mereka menjawab pertanyaan yang lebih sempit daripada yang orang ajukan kepada mereka.

Alamat exit baru mengubah tujuan uji

Sebagian besar situs uji memilih server pengukuran secara otomatis, dan mereka memilihnya sebagian dengan melihat dari mana koneksi Anda tampak berasal. Nyalakan terowongan dan negara tampak Anda berubah, jadi server yang dipilih berubah, dan perbandingannya kini mencakup dua rute berbeda ke dua host berbeda.

Hasilnya sama sekali bukan pengukuran VPN. Itu pengukuran jalur Anda ke server yang tidak Anda pilih, dan selisih antara kedua jalan itu bisa didominasi oleh peering server tersebut, bukan oleh apa pun yang dilakukan terowongan.

Kunci tujuan sebelum mengubah hal lain. Setiap alat yang kredibel memungkinkan Anda memilih server secara eksplisit, dan bila tidak, halaman hasil biasanya menyebut server yang dipakai, yang cukup untuk melihat bahwa kedua jalan itu tidak sebanding. Pastikan apa yang dilihat situs itu sebelum Anda memercayai pilihannya:

curl -sS https://ipinfo.io/json | grep -E '"ip"|"org"|"country"'

Kalau negaranya berubah antara kedua jalan, semua yang dipilih uji setelahnya juga berubah. Tuliskan exit yang teramati di samping tiap hasil dan kebingungannya sebagian besar hilang.

Awal yang lambat selesai setelah sebagian besar uji pendek berakhir

Koneksi TCP tidak mulai pada laju tautan. Ia mulai dengan jendela kemacetan kecil, menggandakannya kira-kira setiap perjalanan pulang-pergi, dan baru mencapai kapasitas jalur setelah beberapa perjalanan. Uji sepuluh detik pada jalur berlaten tinggi bisa menghabiskan sebagian besar umurnya di tanjakan itu.

Itu sebabnya terowongan yang latensinya lebih tinggi bernilai lebih buruk pada uji pendek daripada yang pantas didapatnya, dan itu sebabnya jalan yang lebih lama sering melaporkan angka lebih tinggi tanpa perubahan konfigurasi apa pun. kerangka throughput RFC 6349 menangani hal ini secara eksplisit, dan itu sebabnya pengukuran serius berjalan cukup lama untuk mencapai kondisi tunak. Jalan lima detik pada jalur satelit mengukur pemercepat, bukan jalannya.

Lihat fase koneksinya daripada memercayai satu angka. Curl melaporkan tiap tahap secara terpisah, jadi Anda bisa melihat apakah waktunya masuk ke jabat tangan, ke tanjakan, atau ke transfer:

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

Jalankan dua kali berturut-turut ke tujuan yang sama. Kalau jalan kedua jauh lebih cepat, Anda mengukur tanjakan, bukan jalurnya, dan perbandingan apa pun yang hanya memakai jalan pertama patut dicurigai.

Satu aliran dan enam aliran mengukur hal yang berbeda

Satu aliran TCP dibatasi oleh jendela yang bisa dijaga tetap di udara, yaitu kira-kira waktu pulang-pergi dikali laju. Pada jalur panjang hasil kali itu melebihi apa yang akan dipakai satu aliran, jadi satu unduhan melaporkan lebih rendah daripada kapasitas yang ada. Enam aliran paralel mengisi celah itu dan menghasilkan angka lebih besar.

iperf3 -c speed.example.net -t 20
iperf3 -c speed.example.net -t 20 -P 6
mtr -rwc 50 speed.example.net

Kedua angka itu benar. Angka satu aliran memberi tahu apa yang akan dilakukan satu unduhan, yang biasanya didapat satu tab peramban. Angka paralel memberi tahu apa yang bisa dibawa jalur secara keseluruhan, yang bisa dimanfaatkan torrent atau unduhan banyak bagian. Mengutip yang satu seolah-olah yang lain adalah cara terowongan yang sehat diganti tanpa alasan.

Membandingkan hasil paralel dengan hasil satu aliran adalah cara paling umum orang menyimpulkan bahwa VPN memangkas kecepatan mereka jadi separuh. Samakan metodenya, baru bandingkan. Jejak pada perintah ketiga menambahkan konteks yang hilang: jalur dengan jitter tinggi akan memberi hasil tidak konsisten pada kedua mode, dan tidak ada jumlah aliran yang memperbaikinya.

Enkripsi memakan waktu prosesor, enkapsulasi memakan byte

Dua mekanisme berjalan pada setiap paket secepat apa pun tautannya. Enkripsi memakai CPU per byte, dan enkapsulasi menambah byte tajuk yang tetap harus dibawa tautan. Keduanya muncul sebagai langit-langit, dan gejalanya berbeda.

Langit-langit CPU muncul sebagai dataran: throughput berhenti naik berapa pun aliran yang Anda tambahkan, dan prosesor mesin sibuk sedangkan tautannya tidak. Pada router kecil atau ponsel itu sering menjadi batas sebenarnya, dan itu sebabnya jalur cepat masih bisa memberi terowongan yang sederhana.

Biaya byte lebih kecil tetapi tetap. Tajuk tambahan berarti lebih sedikit muatan per paket, dan pada jalur dengan unit transmisi maksimum tetap tajuk itu juga bisa memicu fragmentasi atau lubang hitam yang tampak sebagai macet pada transfer besar, bukan sebagai rata-rata yang lambat.

Ketiganya sering tertukar karena pengguna menyebut semuanya sebagai «VPN-nya lambat». Hanya yang pertama menanggapi mesin lebih besar, hanya yang kedua menanggapi MTU lebih kecil, dan hanya yang ketiga menanggapi manajemen antrean.

Tuliskan metodenya dalam catatan

Hasil yang layak disimpan menyebut perangkat, jaringan akses, exit, server pengukuran, arah, jumlah aliran, dan durasi. Tanpa itu, dua angka tidak bisa dibandingkan, dan tiket yang berisi satu angka sebenarnya hanya suasana hati.

Simpan juga jalan yang buruk. Rangkaian yang setiap kali menghasilkan macet dari satu exit jauh lebih informatif daripada rata-rata, dan macet justru hal yang disembunyikan rata-rata.

Lalu ujilah hal yang benar-benar Anda pedulikan. Kalau tujuannya unduhan besar, unduh berkasnya. Kalau tujuannya panggilan, ukur latensi di bawah beban, bukan throughput saat menganggur, karena terowongan bisa bernilai baik pada uji kecepatan dan tetap membuat setiap rapat tak terdengar.