Apakah MTU VPN yang lebih kecil lebih cepat? Bandingkan bukti sebenarnya
MTU yang lebih rendah dapat menghindari batas jalur dan tetap memakan throughput. Bandingkan kendala sebenarnya, biaya header, dan beban kerja sebelum mempertahankan perubahan.
Tunnel menjatuhkan transfer besar tetapi meloloskan ping, jadi sarannya datang cepat: turunkan MTU. Perbaikan itu terkadang berhasil, lalu diterapkan ke setiap profil di setiap jaringan. Di titik itulah perbaikan yang tertarget menjadi pajak kinerja permanen. Perbandingan yang harus dibuat adalah antara batas nyata jalur dan biaya mengecilkan setiap paket di bawahnya.
Apa yang sebenarnya menyusut saat Anda menurunkan MTU
Setiap paket membawa header sebelum membawa data Anda. Pada jalur Ethernet 1500 byte, IPv4 dan TCP memakan 40 byte dan menyisakan 1460 untuk muatan; enkapsulasi menambahkan header IP, UDP, dan tunnel luar di atasnya, sehingga anggaran muatan dalam turun lagi. Menurunkan MTU antarmuka mengecilkan anggaran itu dengan sengaja.
Biayanya sebanding dengan jumlah paket, bukan jumlah byte. File yang sama dipecah menjadi lebih banyak paket membutuhkan lebih banyak interupsi, lebih banyak keputusan perutean, dan lebih banyak pemrosesan per paket di setiap perangkat di sepanjang jalur. Pada router yang sudah dekat dengan batas paket per detiknya, itu adalah perlambatan nyata, bukan kesalahan pembulatan. Biaya itu muncul bahkan ketika transfernya sendiri berhasil.
Itulah sebabnya MTU yang lebih kecil adalah jalan memutar dari suatu kendala, bukan optimasi umum. Ia membeli keandalan terhadap jalur yang tidak dapat membawa frame lebih besar, dan ia membebankan biaya tambahan pada setiap paket yang tidak memerlukan pengecilan.
Kapan MTU yang lebih kecil adalah perbaikan yang tepat
Gejala klasiknya spesifik: jabat tangan TCP selesai, respons kecil tiba, dan unduhan besar macet atau tereset. Ping dengan bit jangan-fragmentasi pada 1472 byte gagal sementara ping 1400 byte berhasil, yang menunjuk pada jalur yang tidak dapat membawa paket berukuran penuh dan tidak mengirimkan pesan ICMP yang akan memberi tahu pengirim untuk mengecilkan.
Penemuan MTU jalur bergantung pada pesan ICMP kebutuhan fragmentasi tersebut. Ketika firewall membuangnya, pengirim terus mengulang paket besar dan koneksi tampak menggantung. Menurunkan MTU di sisi tunnel menghindari pengulangan, dan itu perbaikan yang sah untuk jaringan tersebut.
Teknologi akses juga memberlakukan batasnya sendiri: PPPoE biasanya membatasi pada 1492, beberapa jalur seluler dan DSL lebih rendah, dan tunnel bertingkat mengurangi biaya tambahan dua kali. Ukur jalur sebenarnya alih-alih menyalin angka dari panduan, dan ingat bahwa IPv6 memerlukan setidaknya 1280 byte MTU pada setiap tautan yang membawanya, seperti yang ditetapkan RFC 8200.
Bandingkan ketiga kendali sebelum mengubah satu
MTU, MSS, dan fragmentasi adalah kendali berbeda pada lapisan berbeda, dan mengubah yang salah membiarkan gejalanya tetap ada.
| Control | Layer | What it changes | Where it misleads |
|---|---|---|---|
| Interface MTU | IP link | Largest frame the interface will send | Penalizes every protocol, not just the one that failed |
| TCP MSS clamp | TCP | Segment size advertised in the handshake | Leaves UDP and QUIC untouched |
| DF and fragmentation | IP | Whether a router may split a packet | Can break path MTU discovery and security assumptions |
| Tunnel overhead | Encapsulation | Inner MTU after outer headers | Mismatch shows up only for large inner packets |
Membatasi MSS sering kali merupakan perbaikan paling tidak invasif karena hanya memengaruhi TCP dan membiarkan antarmuka bebas untuk lalu lintas lain. MTU antarmuka yang lebih rendah lebih luas dan lebih mudah dipikirkan, itulah sebabnya umum pada router konsumen, tetapi ia membebankan masalah satu protokol kepada setiap protokol.
Menonaktifkan perilaku jangan-fragmentasi menyembunyikan gejala dengan mengizinkan fragmentasi, dan biasanya memperburuk latensi sambil merusak umpan balik yang akan menemukan ukuran yang benar. Hindari itu sebagai perbaikan permanen.
Ukur komprominya, bukan satu angka
Temukan batas jalur dengan probe jangan-fragmentasi, mulai dari tinggi dan turun hingga balasannya tiba:
ping -M do -s 1472 203.0.113.10
ping -M do -s 1400 203.0.113.10
tracepath 203.0.113.10Lalu bandingkan tugas sebenarnya pada kedua pengaturan: transfer file yang sama, titik akhir yang sama, dan jaringan yang sama. Catat waktu penyelesaian dan pengiriman ulang, misalnya dengan nstat -az TcpRetransSegs, dan pantau CPU perangkat jika tunnel berakhir di router kecil. Uji throughput sintetis yang singkat dapat melewatkan kemacetan yang baru muncul setelah beberapa megabyte.
Penghitung paket akan naik setelah pengurangan karena transfer yang sama kini memakai lebih banyak paket. Itu wajar dan bukan bukti throughput yang lebih tinggi. Bandingkan data aplikasi yang selesai, jumlah pengiriman ulang, dan responsivitas, bukan hanya laju paket.
Terapkan perubahan secara bertahap dan jaga cakupannya
Catat nilai aslinya, ubah satu kendali, dan ulangi pengukuran sebelum menjadikannya permanen. Jika buktinya tidak menunjukkan manfaat, kembalikan nilai sebelumnya dengan perintah antarmuka yang sama yang Anda pakai untuk mengaturnya:
ip link set dev wg0 mtu 1420
ip link set dev wg0 mtu 1500Batasi hasilnya pada jaringan yang membutuhkannya. Profil yang harus bekerja di Wi-Fi hotel, hotspot seluler, dan LAN kantor tidak boleh mewarisi nilai terendah yang dibutuhkan salah satunya, kecuali klien tidak dapat mendeteksi jalurnya.
Nilai yang tepat adalah MTU terbesar yang bertahan di jalur, bukan yang terkecil yang membuat gejalanya hilang. Dokumentasikan jalur, hasil probe, dan pengembaliannya, lalu tinjau pengaturan saat jaringan akses berubah.