Mengapa unduhan lebih cepat lewat VPN daripada langsung

Anda memulai unduhan besar, detik-detik pertama terlihat normal, lalu lajunya menetap di sekitar separuh dari yang seharusnya diberikan jalur tersebut. Anda menghubungkan terowongan, mengulangi unduhan yang sama, dan laju itu bertahan lebih tinggi sepanjang berkas. Itu pengukuran nyata sekaligus kesimpulan yang menyesatkan, karena terowongan tidak membuat jalurnya lebih cepat. Ia hanya memindahkan lalu lintas Anda dari port yang dibatasi oleh sesuatu di sepanjang jalur.

Bentuk kurvanya yang membocorkan

Amati transfernya, bukan angka akhirnya. Jalur yang dibatasi biasanya mulai dekat laju jalur, menghabiskan jatah semburannya lalu menetap di batas, jadi rata-ratanya bergantung pada berapa lama Anda mengamati. Terowongan yang benar-benar memperbaiki jalur akan menunjukkan laju lebih baik sejak detik pertama dan mempertahankannya. Dataran itu adalah sidik jari, dan mudah terlewat jika Anda hanya mencatat puncaknya.

Dua kali jalan pada berkas yang sama, satu langsung dan satu melalui terowongan, cukup untuk melihat apakah ada dataran.

Perhatikan kapan dataran dimulai, berapa lama bertahan dan laju apa yang dijaga. Ketiga nilai itu memisahkan pembatas dari jalur yang padat, karena kepadatan membiarkan laju berkelana sementara pembatas memakunya pada satu angka. Jika jalan langsung memburuk perlahan dan jalan melalui terowongan tetap stabil, Anda sedang melihat kebijakan, bukan fisika.

Tiga perbandingan, satu variabel masing-masing

Ubah satu hal per jalan atau Anda tidak belajar apa pun. Ambil berkas yang sama lewat jalur web biasa, lalu lewat alat transfer yang memakai port lain, dari host dengan kapasitas setara dan pada jam yang sama. Pertahankan mesin klien tetap sama, karena laptop yang berpindah antarjaringan menambah variabel yang tidak bisa Anda kendalikan.

curl -o /dev/null -w '%{speed_download}' https://files.example/big.iso
scp [email protected]:/exports/big.iso /dev/null

Gunakan berkas yang sudah dikompresi, seperti citra disk, supaya kompresi transport tidak bisa menjelaskan perbedaannya. Lalu, jika Anda mengendalikan server, pindahkan pendengarnya ke port yang Anda curigai dibatasi, perbarui profil klien, dan ulangi. Jika terowongan kini turun ke laju yang dibatasi, batasnya mengikuti port dan bukan terowongan, dan pertanyaannya terjawab. Jalankan setiap perbandingan dua kali dan simpan angka dataran, bukan puncaknya.

Catat juga jamnya, karena pembatas bisa berbasis waktu dan uji sore bisa berbeda dengan uji pagi. Dua kali jalan pada jam yang sama lebih bernilai daripada sepuluh yang tersebar sepanjang hari.

Apa yang tidak bisa didukung pengukuran ini

Ini tidak menunjukkan bahwa terowongan lebih cepat secara umum, bahwa ia memampatkan sesuatu, atau bahwa port lain tidak dibatasi. Ini menggambarkan satu transfer pada satu jalur selama satu jam. Batas bisa per sesi, per pelanggan atau berbasis waktu, dan operator bisa mengubahnya tanpa mengumumkannya.

Ini juga tidak menunjukkan bahwa jalur langsung rusak. Jalur yang dibatasi bekerja persis seperti yang dimaksudkan, hanya saja dibatasi oleh kebijakan.

Perbedaan itu penting saat Anda menuliskannya. Kerusakan mengundang tiket perbaikan, sedangkan kebijakan mengundang pertanyaan tentang kontrak atau keputusan untuk menghindarinya. Menyebut batas sebagai kerusakan menghasilkan percakapan dukungan yang dimulai dari premis yang salah. Menyebutnya kebijakan memungkinkan Anda mengajukan pertanyaan spesifik yang punya jawaban spesifik.

Ubah temuan menjadi permintaan dukungan

Gunakan angkanya dan tinggalkan kesimpulannya. Permintaan yang menyatakan bahwa transfer besar lewat port 80 bertahan di sekitar separuh laju yang diharapkan selama jam-jam ini, dengan angka dataran terlampir, bisa ditindaklanjuti. Permintaan yang menyatakan VPN lebih cepat tidak, karena terbaca sebagai klaim tentang terowongan alih-alih pengamatan tentang jalur. Lampirkan kedua jalan dan cap waktunya, lalu biarkan operator menjelaskan kebijakannya.

Jangan dorong setiap aplikasi ke terowongan hanya untuk mengejar angka itu.

Terowongan tetap memakan satu lompatan tambahan, enkripsi dan serangkaian mode kegagalan baru, sementara port yang dibatasi tetap terbatas untuk apa pun lainnya yang memakainya. Saat transfer besar harus selesai dengan andal, simpan catatan Anda sendiri tentang port mana yang membawa batas itu. Memindahkan pendengar ke port 80 juga bertabrakan dengan server web mana pun yang sudah terikat ke sana, dan itu menghasilkan gangguan baru alih-alih perbaikan.