Ich habe einige Verwirrung zwischen der Ethernet Maximum Transmission Unit (MTU) und der TCP Maximum Segment Size (MSS) festgestellt, die hoffentlich im Folgenden erklärt wird. Wenn Sie immer noch (oder schon wieder) verwirrt sind, zögern Sie nicht, einen Kommentar hinzuzufügen oder mir eine E-Mail mit der Bitte um Klärung zu schicken.
Zunächst unterscheidet STCP zwischen TCP-Segmenten, die an einen Host in einem lokalen Subnetz gesendet werden, und Segmenten, die an einen Host in einem entfernten Subnetz, d. h. über einen Router, gesendet werden. Segmente, die an einen Host in einem lokalen Subnetz gesendet werden, haben eine MSS, die mit der Ethernet-MTU zusammenhängt; genauer gesagt ist die MSS MTU - IP-Headergröße - TCP-Headergröße. In Versionen vor 17.1 (mehr über 17.1 in einer Minute) ist die MSS gleich 1500 - 20 - 20 oder 1460. Segmente, die an einen Host in einem entfernten Subnetz gesendet werden, verwenden eine MSS von 536. STCP verwendet aufgrund der Anforderungen in RFC 791 und RFC 879 die kleinere MSS für entfernte Segmente. In einem Artikel im eNewsletter für Kunden vom Juni 2004 Stratus habe ich erörtert, wie die MSS eingestellt (erhöht) werden kann und welche Probleme auftreten können. Eine Kopie des Artikels finden Sie hier. Obwohl der Artikel unter Verwendung von Beispielen aus der VOS-Version 14.7 geschrieben wurde, ist der Inhalt immer noch gültig (ab der OpenVOS-Version 17.1).
Mit der Version 17.1 von OpenVOS wurde die Unterstützung für Jumbo-Ethernet-Frames hinzugefügt. Jumbo-Frames erlauben mehr als 1500 Bytes in einem Ethernet-Frame, d.h. eine Erhöhung der Ethernet-MTU. Die Standard-MTU ist immer noch 1500, aber Sie können sie erhöhen, wenn die Schnittstelle mit dem Argument "-mtu" konfiguriert wird (Beispiel 1). Der maximale Wert des MTU-Arguments ist 16110, abhängig von Ihrer Hardware (siehe Tabelle 1).
ifconfig #sdlmux.m16.11-2 172.16.1.116 -netmask 255.255.255.0 -mtu 9200 -add
Adding interface %phx_vos#sdlmux.m16.11-2 with IP address 172.16.1.116
%phx_vos#sdlmux.m16.11-2: <UP, BROADCAST, RUNNING, NOFORWARDBROADCAST, KEEPALIVE
+, MTU:9200>
172.16.1.116 netmask 0xffffff00 broadcast 172.16.1.255
|
| Beispiel 1 - Einstellung der MTU bei der Konfiguration einer Schnittstelle |
| Adapter Typ | MTU |
| Integrierte Adapter in V100, V200, V400 | 1500 |
| Eingebettete Adapter in V150, V250, V300, V500 Integrierte Adapter in V2302, V2404, V4304, V4408, V6308, V6408 |
9200 |
| U571V Single-Port 10/100/1000 mbps Kupfer-Adapter | 1500 |
| U574V-LC Glasfaseradapter mit zwei Anschlüssen für 1000 Mbit/s U575V Kupferadapter mit zwei Anschlüssen 10/100/1000 Mbit/s U578V Quad-Port 10/100/1000 Mbit/s Kupfer-Adapter U582V Quad-Port 10/100/1000 Mbit/s Kupfer-Adapter U583V Quad-Port 1000 Mbit/s Glasfaser-Adapter |
9200 |
| U584V Dual-Port-Glasfaseradapter mit 10.000 Mbit/s | 16110 |
| U776V Quad-Port 1000 mbps Glasfaseradapter | 9200 |
| Tabelle 1 - MTU-Werte nach Hardwaretyp |
Nach der Einstellung einer größeren MTU können Sie sehen, dass STCP eine größere MSS für lokale Verbindungen ankündigt, 0x23c8 ist 9160 dezimal.
9:04:55.912 Xmit Ether Dst 00:16:97:c4:01:aa Src 00:00:a8:41:52:22 Type 0800
+(IP)
IP Ver/HL 45, ToS 0, Len 3c, ID 0, Flg/Frg 0, TTL 3c, Prtl 6
Cksum 23fc, Src ac100174, Dst ac10012c
TCP from 172.16.1.116.59410 to 172.16.1.44.9182
seq 3764213089, ack n.a., window 8192, 20 data bytes, flags Syn.
X/Off 0a, Flags 02, Cksum d329, Urg-> 0000
offset 0 . . . 4 . . . 8 . . . C . . . 0...4... 8...C...
0 2 4 23 c8 3 3 6 4 2 8 a 18 bf 3f d6 0 <<#H<<<< <<<<??V
10 0 0 0 0
|
Aber Fernverbindungen erhalten immer noch die kleinere MSS, 0x218 ist 536 dezimal.
9:20:34.051 Xmit Ether Dst 00:16:97:c4:01:aa Src 00:00:a8:41:52:22 Type 0800
+(IP)
IP Ver/HL 45, ToS 0, Len 3c, ID 0, Flg/Frg 0, TTL 3c, Prtl 6
Cksum 1086, Src ac100174, Dst c0a8000a
TCP from 172.16.1.116.49186 to 192.168.0.10.9182
seq 1916893234, ack n.a., window 8192, 20 data bytes, flags Syn.
X/Off 0a, Flags 02, Cksum de8e, Urg-> 0000
offset 0 . . . 4 . . . 8 . . . C . . . 0...4... 8...C...
0 2 4 2 18 3 3 6 4 2 8 a 0 1 69 a 0 <<<<<<<< <<< <i<
10 0 0 0 0
|
Sie können die Mindest-MSS für Remote-Verbindungen nicht über 1460 (1480 mit dem TCP-Header) erhöhen.
wie: set_stcp_param min_mss 9160
set_stcp_param: Das Argument liegt nicht innerhalb des zulässigen Bereichs. Fehler in
'param_value'. [500-1480] erlaubt
as:
|
Solange nicht beide Seiten einer Verbindung eine größere MSS ankündigen, gibt es keinen wirklichen Effekt. Ein Beispiel: Obwohl der FTP-Server mit einer MTU von 9200 konfiguriert ist und eine MSS von 9160 ankündigt, ist dies die maximale Anzahl von Bytes, die der Server in einem Segment senden wird, da der Client eine MSS von 1460 (0x5b4) ankündigt.
11:02:49.758 Xmit Ether Dst 00:00:a8:42:3b:6e Src 00:00:a8:41:52:22 Type 0800
+(IP)
IP Ver/HL 45, ToS 0, Len 3c, ID 5, Flg/Frg 0, TTL 3c, Prtl 6
Cksum 2401, Src ac100174, Dst ac100122
TCP from 172.16.1.116.ftp-data to 172.16.1.34.49343
seq 2092638702, ack n.a., window 8192, 20 data bytes, flags Syn.
X/Off 0a, Flags 02, Cksum 7c62, Urg-> 0000
offset 0 . . . 4 . . . 8 . . . C . . . 0...4... 8...C...
0 2 4 23 c8 3 3 6 4 2 8 a 0 19 5c b5 0 <<#H<<<< <<< <5
10 0 0 0 0
11:02:49.758 Rcvd Ether Dst 00:00:a8:41:52:22 Src 00:00:a8:42:3b:6e Type 0800
+(IP)
IP Ver/HL 45, ToS 0, Len 3c, ID 1bcb, Flg/Frg 0, TTL 3c, Prtl 6
Cksum 083b, Src ac100122, Dst ac100174
TCP from 172.16.1.34.49343 to 172.16.1.116.ftp-data
seq 3565222463, ack 2092638703, window 8192, 20 data bytes, flags Syn Ack.
X/Off 0a, Flags 12, Cksum fef7, Urg-> 0000
offset 0 . . . 4 . . . 8 . . . C . . . 0...4... 8...C...
0 2 4 5 b4 3 3 6 4 2 8 a 13 cc 99 0 0 <<<4<<<< <<<<L>
10 19 5c b5 0 <5
. . . .
11:02:50.620 Xmit Ether Dst 00:00:a8:42:3b:6e Src 00:00:a8:41:52:22 Type 0800
+(IP)
IP Ver/HL 45, ToS 0, Len 5dc, ID 8, Flg/Frg 0, TTL 3c, Prtl 6
Cksum 1e5e, Src ac100174, Dst ac100122
TCP from 172.16.1.116.ftp-data to 172.16.1.34.49343
seq 2092638703, ack 3565222464, window 128, 1460 data bytes, flags Push A
+ck.
X/Off 08, Flags 18, Cksum 7467, Urg-> 0000
offset 0 . . . 4 . . . 8 . . . C . . . 0...4... 8...C...
. . . .
|
Selbst wenn beide Seiten die größere MSS ankündigen, gibt es keine Garantie, dass jeder Frame die maximale Datenmenge enthält. Beispielsweise geben sowohl der Client als auch der Server eine MSS von 9160 an, aber die Segmente bestehen nur aus 8204 Byte, da dies die maximale Datenmenge ist, die die Anwendung senden kann.
11:33:40.492 Xmit Ether Dst 00:00:a8:43:ba:64 Src 00:00:a8:41:52:22 Type 0800
+(IP)
IP Ver/HL 45, ToS 0, Len 3c, ID 34, Flg/Frg 0, TTL 3c, Prtl 6
Cksum 231b, Src ac100174, Dst ac1001d9
TCP from 172.16.1.116.ftp-data to 172.16.1.217.49430
seq 851197707, ack n.a., window 8192, 20 data bytes, flags Syn.
X/Off 0a, Flags 02, Cksum d8f7, Urg-> 0000
offset 0 . . . 4 . . . 8 . . . C . . . 0...4... 8...C...
0 2 4 23 c8 3 3 6 4 2 8 a 0 20 9b 7d 0 <<#H<<<< <<< >}
10 0 0 0 0
11:33:40.493 Rcvd Ether Dst 00:00:a8:41:52:22 Src 00:00:a8:43:ba:64 Type 0800
+(IP)
IP Ver/HL 45, ToS 0, Len 3c, ID 33, Flg/Frg 0, TTL 3c, Prtl 6
Cksum 231c, Src ac1001d9, Dst ac100174
TCP from 172.16.1.217.49430 to 172.16.1.116.ftp-data
seq 3989207776, ack 851197708, window 8192, 20 data bytes, flags Syn Ack.
X/Off 0a, Flags 12, Cksum d75d, Urg-> 0000
offset 0 . . . 4 . . . 8 . . . C . . . 0...4... 8...C...
0 2 4 23 c8 3 3 6 4 2 8 a 0 e e1 8a 0 <<#H<<<< <<< <a>
10 20 9b 7d 0 >}
. . . .
11:33:40.504 Xmit Ether Dst 00:00:a8:43:ba:64 Src 00:00:a8:41:52:22 Type 0800
+(IP)
IP Ver/HL 45, ToS 0, Len 2034, ID 37, Flg/Frg 0, TTL 3c, Prtl 6
Cksum 0320, Src ac100174, Dst ac1001d9
TCP from 172.16.1.116.ftp-data to 172.16.1.217.49430
seq 851197708, ack 3989207777, window 128, 8204 data bytes, flags Ack.
X/Off 08, Flags 10, Cksum ee81, Urg-> 0000
offset 0 . . . 4 . . . 8 . . . C . . . 0...4... 8...C...
. . . .
|
Finally just setting a large MTU on your hosts is not enough; you also have to make sure that all network devices between the two hosts are configured to allow the larger frame size. If not then what you will find is that everything will work correctly when the host uses small (<= 1460) segments, but if it transmits a larger segment, that segment will be dropped by the network device and the connection will eventually fail with a timeout condition of some kind. Larger segments may be sent because the application sends it or because STCP combines smaller segments. This can make for random and very frustrating failures.
Unternehmen