Mir ist aufgefallen, dass es einige Verwirrung zwischen der Ethernet-Maximum Transmission Unit (MTU) und der TCP-Maximum Segment Size (MSS) gibt; hoffentlich wird dies im Folgenden klarer. Falls Sie immer noch (oder jetzt) verwirrt sind, zögern Sie nicht, einen Kommentar zu hinterlassen oder mir eine E-Mail zu schicken, um weitere Erläuterungen zu erhalten.
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 gesendet werden, d. h. über einen Router. Segmente, die an einen Host in einem lokalen Subnetz gesendet werden, haben eine MSS, die sich nach der Ethernet-MTU richtet; genauer gesagt entspricht die MSS der MTU minus der IP-Header-Größe minus der TCP-Header-Größe. In Versionen vor 17.1 (mehr zu 17.1 gleich) ergibt sich daraus ein MSS von 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. Ich habe in einem Artikel im Stratus eNewsletter vom Juni 2004 erläutert, wie man die MSS optimiert (erhöht) und welche potenziellen Probleme dabei auftreten können. Eine Kopie des Artikels finden Sie hier. Der Artikel wurde zwar anhand von Beispielen aus VOS Release 14.7 verfasst, der Inhalt ist jedoch nach wie vor gültig (Stand: OpenVOS Release 17.1).
Mit der Version 17.1 von OpenVOS wurde die Unterstützung für Jumbo-Ethernet-Frames hinzugefügt. Jumbo-Frames ermöglichen mehr als 1500 Byte im Ethernet-Frame, d. h. eine Erhöhung der Ethernet-MTU. Die Standard-MTU beträgt weiterhin 1500, kann jedoch bei der Konfiguration der Schnittstelle mithilfe des Arguments „–mtu“ erhöht werden (Beispiel 1). Der Maximalwert des MTU-Arguments beträgt je nach Hardware 16110 (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 – Festlegen der MTU bei der Konfiguration einer Schnittstelle |
| Adaptertyp | MTU |
| Integrierte Adapter in V100, V200, V400 | 1500 |
| Integrierte Adapter in den Modellen V150, V250, V300, V500 Integrierte Adapter in den Modellen V2302, V2404, V4304, V4408, V6308, V6408 |
9200 |
| U571V Ein-Port-Kupferadapter mit 10/100/1000 Mbit/s | 1500 |
| U574V-LC Dual-Port-Glasfaseradapter mit 1000 Mbit/s U575V Dual-Port-Kupferadapter mit 10/100/1000 Mbit/s U578V Vierfach-Port-Kupferadapter mit 10/100/1000 Mbit/s U582V Vierfach-Port-Kupferadapter mit 10/100/1000 Mbit/s U583V Vierfach-Port-Glasfaseradapter mit 1000 Mbit/s |
9200 |
| U584V Dual-Port-Glasfaseradapter mit 10.000 Mbit/s | 16110 |
| U776V Vierfach-Glasfaseradapter mit 1000 Mbit/s | 9200 |
| Tabelle 1 – MTU-Werte nach Hardwaretyp |
Nachdem Sie eine größere MTU eingestellt haben, können Sie feststellen, dass STCP für lokale Verbindungen eine größere MSS ankündigt; 0x23c8 entspricht 9160 im Dezimalsystem.
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
|
Bei Fernverbindungen wird jedoch weiterhin der kleinere MSS verwendet; 0x218 entspricht 536 im Dezimalsystem.
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
|
Der minimale MSS-Wert für Remote-Verbindungen kann nicht über 1460 (1480 einschließlich TCP-Header) hinaus erhöht werden.
als: set_stcp_param min_mss 9160
set_stcp_param: Das Argument liegt nicht im zulässigen Bereich. Fehler bei
'param_value'. [500–1480] zulässig
als:
|
Sofern nicht beide Seiten einer Verbindung eine größere MSS angeben, hat dies keine wirklichen Auswirkungen. Auch wenn der FTP-Server beispielsweise mit einer MTU von 9200 konfiguriert ist und eine MSS von 9160 angibt, ist die maximale Anzahl an Bytes, die der Server in einem Segment sendet, die vom Client angegebene MSS von 1460 (0x5b4).
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 einen höheren MSS angeben, gibt es keine Garantie dafür, dass jedes Frame die maximale Datenmenge enthält. Beispielsweise geben sowohl Client als auch Server einen MSS von 9160 an, doch die Segmente sind nur 8204 Byte groß, da dies die maximale Datenmenge ist, für deren Versand die Anwendung ausgelegt ist.
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.