TCP MSS minimal di Linux


9

TCP MSS di Linux minimal harus 88 (termasuk / net / tcp.h):

/* Minimal accepted MSS. It is (60+60+8) - (20+20). */
#define TCP_MIN_MSS             88U

Pertanyaan saya adalah: dari mana mereka datang dengan "60 + 60 + 8" dan mengapa? Saya mendapatkan bahwa 20 + 20 berasal dari header IP + header TCP.

EDIT: Setelah melihat lebih dekat pada header, rumusnya terlihat seperti ini:

(MAX_IP_HDR + MAX_TCP_HDR + MIN_IP_FRAG) - (MIN_IP_HDR + MIN_TCP_HDR)

Pertanyaannya masih ada: mengapa ? Mengapa kernel Linux menggunakan rumus ini, sehingga melarang (aliran paksa) segmen TCP, katakanlah, 20 byte? Pikirkan iperf di sini.

EDIT2: Ini kasus penggunaan saya. Dengan memaksa MSS rendah pada soket / koneksi, semua paket yang dikirim oleh stack akan memiliki ukuran kecil. Saya ingin menetapkan MSS rendah ketika bekerja dengan iperf untuk paket / pengujian kedua. Saya tidak bisa mendapatkan paket IP yang lebih kecil dari 128 byte (frame Ethernet 142 byte) pada kabel karena batas bawah ini untuk MSS! Saya ingin mendapatkan sedekat mungkin dengan ukuran frame Ethernet 64 byte seperti RFC 2544. Secara teoritis ini harus dimungkinkan: 18 + 20 + 20 <64.


Bagaimana ini melarang segmen TCP dari 20 byte?
David Schwartz

MSS adalah singkatan dari Maximum Segment Size, itu batas atas (tidak lebih rendah) untuk ukuran segmen dalam koneksi tertentu. TCP_MIN_MSS menentukan batas bawah untuk batas ini. Jadi, itu tidak melarang segmen dengan cara apa pun dengan kurang dari 88 byte, itu hanya menyatakan bahwa MSS untuk koneksi apa pun harus> = 88 byte.
gelraen

Tentu saja! Maaf karena tidak cukup jelas. Silakan lihat hasil edit terbaru.
Mircea Gherzan

Mengapa Anda membiarkan hadiah itu kedaluwarsa? Jawaban David membersihkan semuanya untuk kepuasan saya setidaknya. Perbedaan antara jawabannya dan jawaban saya adalah bahwa kita berbicara tentang perbedaan minimal. Untuk apa nilainya, ada minimum ketiga, yaitu 41, atau 20 + 20 + 1 byte data TCP. Jadi ukuran paket minimum bergantung pada alasan Anda bertanya. Saya berharap 68 adalah jawaban yang benar dalam kasus-kasus di mana kernel digunakan TCP_MIN_MSS.
Warren Young

Saya masih belum puas dengan jawabannya. Saya masih gagal melihat alasan mengapa kernel tidak membiarkan saya memaksakan MSS kecil arbirary ke suatu aplikasi. Saya ingin memiliki (aliran konstan TCP-loaded) paket IP 41 byte, tetapi saya tidak bisa, karena TCP_MIN_MSS. Kenapa tidak bisa 1? RFC apa yang akan pecah? Teori / masalah praktis apa yang akan ditimbulkannya? Apakah Anda yakin itu "di luar spesifikasi"? "Minima berbeda"? Hanya ada satu minimum minat di sini: MSS terkecil yang diizinkan oleh kernel.
Mircea Gherzan

Jawaban:


5

Diperlukan implementasi untuk mendukung header TCP dan IP berukuran maksimum, yang masing-masing adalah 60 byte.

Suatu implementasi harus mendukung datagram 576-byte, yang bahkan dengan header-maksimum berarti lebih dari 8 byte data dalam datagram. Untuk mengirim datagram dengan lebih dari 8 byte data, fragmentasi IP harus memasukkan setidaknya 8 byte data di setidaknya satu paket yang mewakili fragmen datagram. Jadi implementasi harus mendukung setidaknya 8 byte data dalam satu paket.

Menyatukan ini, implementasi harus mendukung paket 60 + 60 + 8 byte.

Ketika kami mengirim paket yang merupakan bagian dari aliran TCP, mereka memiliki header IP 20-byte (opsi plus) dan header TCP 20-byte (opsi plus). Yang tersisa minimal (60 + 60 + 8) - (20 + 20) byte tersisa untuk data dan opsi. Karenanya ini adalah maksimum yang dapat kita asumsikan dengan aman dari TCP MSS implementasi.


1
MSS tidak menyertakan tajuk meskipun (itu hanya payload), dan 60pertunjukannya muncul dua kali
Michael Mrozek

Implementasi harus dapat mendukung paket dengan header berukuran maksimum, tetapi kami tidak mengirim header berukuran maksimum. Karena itu perbedaan antara maksimum dan apa yang sebenarnya kami kirim tersedia untuk data dan harus ditambahkan ke SPM.
David Schwartz

OK, jadi Anda sudah menjelaskan 8 byte. Saya tidak tahu apa yang Anda maksud dengan tajuk "TCP / IP". Saya tahu header IP dan TCP. Dan, seperti yang ditunjukkan Michael 60 muncul dua kali. Dan RFC hanya membahas "MSS efektif" dan bukan yang minimal.
Mircea Gherzan

60 muncul dua kali, satu kali untuk header IP dan satu lagi untuk header TCP.
David Schwartz

68 hanya tentang fragmentasi. "60 + 60 + 8" mungkin terfragmentasi, lalu mengapa peduli dengan fragmentasi? Bahkan "68 + 20" mungkin terfragmentasi. Dan mengapa "harus" pihak lain "menerima" "60 + 60 + 8"? "Terima" seperti pada "tanpa fragmentasi"? Intinya: mengapa saya tidak diizinkan mengirim "20 + 20" + 10 byte data?
Mircea Gherzan

3

Saya tidak tahu dari mana nomor itu berasal, tetapi saya dapat memberitahu Anda bahwa nomor itu di luar spesifikasi. MTU minimum yang didukung untuk jaringan IP adalah 576 byte, yaitu 512 byte data ditambah hingga 64 byte untuk header IP + TCP dan opsi TCP. Nilai itu dipilih untuk memberikan overhead rendah yang layak dalam kasus khas.

Pembacaan saya terhadap kode kernel menunjukkan bahwa nilai yang Anda tampilkan tidak sembarang. Ada praktik yang lebih tua untuk hanya menggunakan konstanta mentah di tempat TCP_MIN_MSS. Oleh karena itu, saya berasumsi ada beberapa jaringan IP-over-Foo yang aneh yang ditemukan oleh para pengembang kernel yang membuat mereka memutuskan mereka dapat meningkatkan nilai sesuai dengan yang Anda lihat.

Apa tipe jaringan yang tidak standar itu, saya tidak bisa mengatakannya.


576 adalah MTU untuk datagram . Dalam hal ini, itu adalah batas paket yang penting, bukan batas datagram karena paket TCP mengatur bit DF.
David Schwartz

Minimum MTU yang ditetapkan untuk datagram IP, dan paket TCP juga merupakan datagram IP.
gelraen

Benar, tetapi batasan TCP ini adalah untuk paket, bukan datagram, karena datagram TCP tidak pernah (biasanya) fragmen. Satu-satunya arti di mana aturan datagram 576-byte penting adalah bahwa itu berarti implementasi harus mampu mendukung setidaknya 8 byte data dalam sebuah paket (maka 8 dalam rumus). Kalau tidak, tidak mungkin untuk memecah datagram 576-byte.
David Schwartz
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.