Unggahan VPN lebih lambat daripada unduhan? Tentukan batas mana yang Anda kena

Sebagian besar jalur akses bersifat asimetris, jadi terowongan biasanya mengunggah lebih lambat daripada mengunduh, dan itulah jawaban yang diharapkan, bukan kerusakan. Pertanyaan yang menarik adalah apakah unggahan Anda dibatasi oleh jalur, oleh hal lain yang sudah memakainya, atau oleh aliran yang macet alih-alih berjalan stabil. Ketiganya menghasilkan keluhan yang sama dan membutuhkan pekerjaan berbeda.

Tiga batas yang tampak sama dari bilah kemajuan

Kapasitas adalah yang pertama, dan itu sifat produk akses, bukan terowongan. Uplink beberapa megabit normal pada fiber konsumen dan banyak paket seluler, dan biaya enkripsi kecil dibandingkan celah itu. Enkapsulasi juga menambah byte per paket, yang memangkas throughput berguna di kedua arah dan bukan hanya satu, sehingga tidak bisa menjelaskan asimetri besar sendirian.

Kontensi adalah yang kedua. Sinkronisasi cloud, pustaka foto, dan agen pembaruan mengunggah saat mesin tampak menganggur, dan perangkat kedua pada jalur yang sama melakukan hal yang sama. Antrean adalah yang ketiga: uplink yang jenuh mendorong lalu lintas interaktif di belakang data massal, sehingga panggilan terputus sementara transfernya sendiri melaporkan kemajuan yang sehat.

Ukur satu arah pada satu waktu

Gunakan perangkat, profil, dan tujuan yang sama, dan jangan pernah menjalankan kedua arah sekaligus kecuali kontensi justru yang ingin Anda amati. Jeda transfer opsional Anda sendiri sebelum pengujian pertama. Dua pengujian dengan satu bendera di antaranya menyelesaikan sebagian besarnya.

iperf3 mengirim dari klien secara bawaan, jadi pengujian biasa mengukur jalur unggah Anda; -R membalik arah dan mengukur unduhan. Jalankan dengan jarak beberapa menit dan catat kedua angka alih-alih merata-ratakan:

iperf3 -c speed.example.net -t 30 -P 4
iperf3 -c speed.example.net -t 30 -P 4 -R

Jika angka unggah hanya sebagian kecil dari angka unduhan dan tetap stabil antar pengujian, bentuknya cocok dengan jalur akses asimetris dan terowongan bukan penyebabnya. Jika unggahan berayun antar pengujian atau runtuh setelah sepuluh detik, teruskan membaca.

Tentukan dari mana unggahan berubah

Ubah satu variabel pada satu waktu dan perhatikan arah mana yang bergerak. Titik akhir VPN kedua yang mengunggah lebih baik menunjuk ke titik akhir itu atau rute ke sana. Unggahan lambat yang sama dari perangkat kedua pada jalur yang sama menunjuk ke jalur. Perangkat berbeda pada jalur berbeda yang juga lambat menunjuk ke kebijakan masuk tujuan, yang tidak bisa Anda perbaiki secara lokal.

Catat byte per detik dan waktu berlalu untuk beban kerja yang sama, bukan satu skor kecepatan. Klien cadangan dan uji kecepatan memakai tujuan dan konkurensi berbeda, jadi membandingkan angkanya tidak menjawab apa pun. Jika permintaan kecil baik-baik saja dan hanya transfer besar yang merangkak, batasnya mungkin bukan bandwidth sama sekali.

Untuk penggunaan sehari-hari, membatasi unggahan latar belakang atau menjadwalkannya di luar jam rapat sering lebih membantu daripada pengaturan terowongan apa pun. Nilailah perubahan itu dari beban kerja gabungan: cadangan yang selesai lebih lambat tetapi tidak lagi merusak panggilan biasanya adalah pertukaran yang lebih baik.

Saat macet mengalahkan lambat

Transfer yang membeku pada titik yang berulang lalu melanjutkan berperilaku seperti masalah MTU jalur, bukan batas laju. Terowongan mengurangi muatan berguna per paket, dan perangkat yang membuang pesan ICMP yang dihasilkan membiarkan pengirim menebak. Pola itu layak mendapat uji sendiri, karena perbaikannya berbeda dari menyetel laju. Angka rendah yang stabil menunjuk ke kapasitas, sedangkan ledakan yang diikuti keheningan menunjuk ke muatan yang tidak dapat dibawa jalur.

Uji jalur dengan muatan yang tidak boleh terfragmentasi, lalu bandingkan MTU antarmuka terowongan dengan nilai yang lolos:

ping -M do -s 1400 -c 3 203.0.113.10
ip link show dev tun0 | grep -o "mtu [0-9]*"

Jika probe besar menghilang sementara yang kecil berhasil, kencangkan TCP MSS pada terowongan alih-alih menurunkan MTU antarmuka untuk setiap protokol. Macet yang menetap setelah titik itu milik penyimpanan atau laju aplikasi penerima, bukan jalur jaringan.

Apa yang diubah, dan apa yang dibiarkan

Ubah hal-hal yang Anda kendalikan: jadwal transfer latar belakang, pilihan titik akhir, dan MSS untuk jalur yang macet. Jaga setiap perubahan dapat dibalik dan terbatas pada satu beban kerja. Biarkan hal-hal yang menurut pengukuran baik-baik saja, termasuk kecepatan unduh yang sudah cocok dengan jalur.

Tuliskan angka sebelum dan sesudah bersama profil, titik akhir, dan waktu, karena masalah unggah yang berpindah dengan titik akhir adalah pertanyaan perutean, dan yang berpindah dengan perangkat bersifat lokal. Catatan itulah yang mengubah keluhan kabur menjadi keputusan, dan biayanya dua pengujian perintah yang sama.