Bisakah VPN Lebih Cepat daripada Koneksi Langsung?

Transfer yang merayap di koneksi kantor kadang selesai cepat lewat terowongan, dan enkapsulasi tambahan membuatnya tampak mustahil. Paradoks yang tampak ini berasal dari membandingkan hal yang salah. Terowongan menambah kerja, dan juga mengubah jalur jaringan mana yang diikuti lalu lintas, alamat mana yang dilihat tujuan, dan kadang server mana yang menjawab. Keputusan antara dua rute menuntut ketiga efek itu dipisahkan sebelum kesimpulan apa pun soal kecepatan.

Tiga Hal yang Dapat Diubah Terowongan

Yang pertama adalah transit. Perutean internet mengikuti kebijakan operator dan hubungan bisnis, bukan latensi terukur, jadi jalur lewat penyedia VPN dapat melintasi jaringan berbeda dari rute langsung. Itu bisa menghindari titik pertukaran yang padat atau mendarat di yang peeringnya lebih baik, dan sama mudahnya bisa lebih buruk.

Yang kedua adalah tujuan. Perubahan alamat keluar sering mengubah jawaban DNS, dan jaringan konten dapat memberi Anda cache atau wilayah lain. Sebagian perbaikan lalu menjadi milik server baru, bukan terowongan. Nama host yang sama dapat mendarat di server yang lebih dekat atau kurang dibebani tanpa ada yang berubah di klien.

Yang ketiga adalah perilaku transport. Enkapsulasi mengubah ukuran paket efektif, dan terowongan yang menghindari segmen tengah yang banyak kehilangan paket dapat membiarkan aliran TCP menumbuhkan jendelanya alih-alih mundur berulang kali. Tidak satu pun dari ini adalah mekanisme percepatan universal; masing-masing adalah kondisi yang harus diamati. Memisahkannya adalah yang mengubah keingintahuan menjadi fakta.

Apa yang Tidak Dapat Diubah

Tidak ada dalam terowongan yang menambah kapasitas pada tautan antara perangkat dan jaringan. Kanal Wi-Fi yang jenuh, mil terakhir yang padat, atau paket seluler yang dibatasi membatasi kedua jalur secara sama, dan uji kecepatan lewat terowongan tidak dapat melampaui batas itu. Tautan yang sama membawa paket yang dienkapsulasi, jadi enkapsulasi dapat menghabiskan kapasitas tetapi tidak pernah menciptakannya. Yang berubah adalah ke mana paket pergi setelah meninggalkan tautan itu. Itu sebabnya hasil terowongan yang cepat selalu punya penjelasan di hulu lompatan pertama.

Batas di sisi server sama tidak pedulinya. Jika host jauh melayani dengan lambat, jalur yang lebih baik hanya mengirimkan respons lambat itu lebih efisien, dan pengguna tetap menunggu. Sumber bersama yang dibebani tampak lambat di kedua jalur pada saat yang sama.

Bandingkan Jalur dengan Benar

Jaga aplikasi, arah, durasi, dan konkurensi tetap identik, dan ubah hanya jalurnya. Jalankan setiap uji lebih dari sekali, pada jam yang sama, dan catat alamat keluar serta jawaban resolver di samping throughput. Satu kali jalan adalah sampel, bukan pengukuran, dan satu unduhan cepat bisa jadi cache hit yang tidak mengatakan apa pun tentang rute. Tuliskan kondisinya sebelum hasil, karena angkanya sulit ditafsirkan sesudahnya.

mtr -rwc 50 -T -P 443 203.0.113.20
curl -o /dev/null -s -w '%{speed_download} %{time_connect}\n' https://example.com/file
dig +short cdn.example.com
traceroute -n -T -p 443 cdn.example.com

Jawaban resolver adalah detail yang paling sering dilewatkan perbandingan, dan itu menjelaskan “perbaikan” yang hilang saat server yang sama dipaksakan. Jika alamatnya berbeda antarjalan, uji itu membandingkan dua tujuan, bukan dua jalur. Laporkan latensi dan kehilangan di samping throughput, karena jalur yang lebih cepat secara keseluruhan tetapi menambah tunda pada setiap permintaan interaktif tidak lebih baik bagi beban kerja yang mengeluh. Waktu bolak-balik lebih penting daripada kecepatan massal untuk apa pun yang bertanya lalu menunggu.

Kapan Perbedaannya Layak Dipertahankan

Jika terowongan yang disetujui secara andal memperbaiki beban kerja tertentu, itu pilihan operasional yang sah: dokumentasikan beban kerja, pengukurannya, dan keluar yang dipakai. Catatan yang berguna menyebut satu host, alamat keluar yang dihasilkan terowongan, jawaban resolver, dan angka yang sama dari jalur langsung pada hari yang sama. Itu cukup bagi insinyur berikutnya untuk mengulang perbandingan alih-alih memperdebatkannya lagi. Itu tetap bukan bukti bahwa penyedia membatasi sesuatu, dan tidak berlaku untuk aplikasi lain atau jam lain.

Simpan catatan pengukuran bersama konfigurasi. Itu menjawab pertanyaan berikutnya apakah perbaikan masih ada, dan itulah satu-satunya cara mengetahui apakah jalur atau beban kerjanya berubah. Catatan tanpa tanggal sama sekali tidak dapat menjawab pertanyaan itu.