Lakukan Path MTU Discovery tanpa bergantung pada kesalahan ICMP, yang sering kali tidak terkirim.
Program ini melakukan Penemuan MTU Jalur Lapisan Paket seperti yang dijelaskan dalam RFC 4821, yang merupakan cara yang lebih andal untuk mendeteksi ukuran MTU di hadapan lubang hitam ICMP.
Meskipun koneksi TCP secara otomatis menyesuaikan ukuran MTU dari waktu ke waktu tergantung pada berbagai indikator (kinerja jaringan, kehilangan paket, pesan kesalahan ICMP, ...), hal ini tidak berlaku untuk protokol tanpa koneksi.
Ketika kinerja sangat penting, throughput , fragmentasi paket , dan keandalan rute adalah tiga indikator utama yang harus dianalisis guna mengoptimalkan kinerja aliran. Karena keandalan rute tidak selalu bergantung pada kita, kita harus berusaha memaksimalkan throughput sambil TIDAK melakukan fragmentasi paket , yang dapat menurunkan kinerja secara parah [1] .
Proposal asli untuk Path MTU Discovery mengandalkan paket ICMP Fragmentation Needed
untuk dikirimkan ketika paket IPv4 dengan kumpulan bidang Jangan Fragmen terlalu besar untuk disebarkan. Sayangnya, beberapa router tidak menghasilkan kesalahan semacam ini tetapi memilih untuk mengabaikan paket besar secara diam-diam. Klien tidak memiliki cara untuk menentukan penyebab hilangnya paket.
Karena semua host diberi mandat untuk mendukung query ICMP_ECHO, kita dapat memanfaatkan fakta bahwa pesan ICMP menerima sejumlah data dan mengirimkan paket dengan ukuran berbeda ke server kita. Jika kita mengaktifkan kolom Jangan Fragmen di paket IPv4 dan mendengarkan respons, secara de facto kita menunggu ACK (dalam bentuk paket ICMP_ECHOREPLY) yang mengonfirmasi bahwa ukuran MTU ini valid.
Sekarang kita hanya perlu melakukan pencarian biner berdasarkan ukuran paket untuk menemukan ukuran MTU maksimum yang didukung oleh rute ini.
Saat dalam mode ICMP, beberapa permintaan ICMP_ECHO dengan ukuran berbeda dihasilkan.
ICMP Fragmentation Needed
), ukuran MTU tersebut dinyatakan tidak valid dan ambang batas diturunkan.Satu-satunya persyaratan mode ICMP adalah host harus mampu membalas pesan ping.
Algoritme yang sama berlaku untuk paket UDP, namun Anda perlu menjalankan server ( udp_server.py ) di host penerima untuk mengirim kembali pesan pengakuan.
Program ini seharusnya berjalan dengan baik di sebagian besar distribusi Linux dan OSX.
gcc -Wall -Wextra mtu_discovery.c mtu.c -o plpmtu
Seharusnya tidak melaporkan peringatan/kesalahan. Jika ya, silakan buka terbitan.
Jika Anda ingin menjalankan dalam mode ICMP ketik:
sudo ./plpmtu -p icmp -s <server-ipaddr>
Jika Anda ingin menjalankan mode UDP :
sudo ./plpmtu -p udp -s <server-ipaddr:port>
Hak admin diperlukan untuk menggunakan soket mentah.
Penentu | Keterangan |
---|---|
-p {icmp/udp} | Pilih mode mana yang akan dioperasikan. |
-s <tambahan[:pelabuhan]> | Tentukan alamat server. Jika berjalan dalam mode UDP, Anda juga harus menentukan port tujuan dengan menambahkan ':port' (misal -s 8.8.8.8:12345 ) |
-l <tambahan:pelabuhan> | Opsional. Pilih alamat mana yang akan diikat(); digunakan dalam mode UDP; mungkin dihapus. |
-t <batas waktu> | Opsional. Pilih waktu maksimum untuk menunggu respon dari server, defaultnya adalah 1 detik; waktu dinyatakan dalam milidetik. |
-r <permintaan maksimal> | Opsional. Pilih jumlah maksimum upaya gagal yang diperlukan untuk menyatakan ukuran MTU tidak valid, defaultnya adalah 3 upaya. |
sudo ./plpmtu -p icmp -s 184.12.26.131
Lakukan penemuan MTU (mode ICMP) dengan 184.12.26.131.
sudo ./plpmtu -p udp -s 184.12.26.131:24000 -t 1500 -r 5
Lakukan penemuan MTU (mode UDP) dengan 184.12.26.131 pada port 24000. Jika respon tidak diterima dalam waktu 1,5 detik selama 5 kali berturut-turut, kurangi ambang batas MTU.