Zunächst ein paar Hintergrundinformationen: TCP verfügt über ein Konzept namens maximale Segmentgröße (MSS). Dies ist das größte Segment (von Daten), das der TCP-Stack akzeptiert. Es wird der Gegenstelle im SYN-Segment mitgeteilt, wenn die Verbindung hergestellt wird. Die folgende Paketdekodierung zeigt das SYN-Segment mit der hervorgehobenen TCP MSS-Option. Alle TCP-Optionen haben das gleiche Format: 1 Byte für die Optionsnummer, in diesem Fall 2, 1 Byte für die Gesamtlänge der Option (4) und den Wert der Option, in diesem Fall 5b4 hex oder 1460 dezimal.
packet_monitor -interface #sdlmux.m16.11-3 -hex_dump -numeric -time_stamp -verbo +se -pkt_hdr -filter -host 10.64.77.50 dir icmp type + tcp hh:mm:ss.ttt dir len proto source destination src port ds +t port type 10:11:56.751 Xmit Ether Dst 00:23:54:52:18:6e Src 00:00:a8:43:52:22 Type 0800 +(IP) IP Ver/HL 45, ToS 0, Len 2c, ID be0b, Flg/Frg 0, TTL 3c, Prtl 6 Cksum dcdd, Src a404d80, Dst a404d32 TCP from 10.64.77.128.55911 to 10.64.77.50.telnet seq 1305537174, ack n.a., window 8192, 4 data bytes, flags Syn. X/Off 06, Flags 02, Cksum 815d, Urg-> 0000 offset 0 . . . 4 . . . 8 . . . C . . . 0...4...8...C... 0 2 4 5 b4 <<<4
Für eine Verbindung zu einem Host in einem lokalen Netz verwendet STCP einen Wert von 1460. Wenn man den gesamten Protokoll-Overhead hinzurechnet, erhält man einen Ethernet-Frame von 1518 Byte - die maximale Ethernet-Frame-Größe. Für Verbindungen zu Hosts in nicht-lokalen Segmenten verwendet STCP einen vom min_mss-Parameter abgeleiteten Wert. Die Verwendung des Standardwerts min_mss führt zu einem MSS-Wert von 536. Dieser Wert ist die Mindestgröße, die alle IP-basierten Netzwerkgeräte, d. h. Router, bereit sein müssen, ohne IP-Fragmentierung weiterzuleiten. Die Spezifikation, die 536 als Mindestgröße festlegt, wurde 1983 in RFC 879 - "The TCP Maximum Segment Size and related Topics" verfasst.
Heute ist es wahrscheinlich, dass alle Ihre Router eine größere Größe verarbeiten können. Sie können daher das STCP-Minimum von 536 auf etwas Größeres anheben. Wie viel größer, das ist die entscheidende Frage. Die Gefahr bei einer zu großen Größe ist die Fragmentierung. Das schlimmste, aber am einfachsten zu diagnostizierende Szenario ist, dass der Router das TCP-Segment verwirft, anstatt es zu fragmentieren. In diesem Fall können Sie zwar eine Verbindung aufbauen, aber bei der Datenübertragung schlägt die Verbindung fehl. Ein Trace auf dem sendenden Host zeigt mehrere erneute Übertragungen großer TCP-Segmente, bis die Verbindung abbricht. Der Trace kann auch ICMP-Meldungen (destination unreachable) von dem Router anzeigen, der das Segment verwirft. Wenn der Router das Segment fragmentiert, wird er dem Fragmentierungsprozess wahrscheinlich eine niedrige Priorität einräumen, was zu einer Verringerung des Durchsatzes führen kann. Außerdem steigt mit der Anzahl der Fragmente die Wahrscheinlichkeit, dass das Segment aufgrund von Beschädigung oder Überlastung verloren geht. Am einfachsten lässt sich dies feststellen, indem man einen packet_monitor-Trace auf dem Modul ausführt. Wenn die TCP-Segmente als Fragmente ankommen, wissen Sie, dass eine Fragmentierung stattgefunden hat.
Die folgenden drei Ethernet-Frames stellen ein in drei Teile fragmentiertes TCP-Segment dar. Sie können erkennen, dass der erste Frame ein Fragment ist, weil der Flg/Frg-Wert 2000 ist. Die 2 zeigt an, dass das Bit "More Fragments" gesetzt ist, und 000 ist der Fragment-Offset, in diesem Fall bedeutet 0, dass es sich um das erste Fragment handelt. Packet Monitor kennzeichnet die nächsten 2 Frames tatsächlich als Fragmente. Der Flg/Frg-Wert in Frame 2 ist 2048, wieder bedeutet die 2, dass das More Fragments-Bit gesetzt ist, und die 48 ist der Offset (in Vielfachen von 8 Bytes) der Daten im ursprünglichen IP-Datagramm. Der dritte Frame hat ein Flg/Frag von nur 90, oder genauer gesagt 0090. Da das Bit More Fragments 0 ist, wissen wir, dass dies das letzte Fragment ist. Wir wissen, dass alle diese Frames zusammengehören, weil sie alle denselben IP-ID-Wert haben, 2e87. Die Datenlänge im ersten Frame ist ein Hinweis auf den MSS-Wert, der gesetzt werden sollte, in diesem Fall 556.
15:52:27.081 Rcvd Ether Dst 00:00:a8:43:52:22 Src 00:12:3f:82:57:10 Type 0800 +(IP) IP Ver/HL 45, ToS 8, Len 254, ID 2e87, Flg/Frg 2000, TTL 3f, Prtl 6 Cksum 1422, Src c0a86432, Dst a404d80 TCP from 192.168.100.50.32781 to 10.64.77.128.ftp-data seq 568258166, ack 840605671, window 5440, 556 data bytes, flags Ack. X/Off 05, Flags 10, Cksum d149, Urg-> 0000 offset 0 . . . 4 . . . 8 . . . C . . . 0…4… 8…C… 0 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 * 5678901234567890 10 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 * 1234567890123456 20 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 * 7890123456789012 30 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 * 3456789012345678 40 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 * 9012345678901234 50 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 * 5678901234567890 60 d a 31 32 33 34 35 36 37 38 39 30 31 32 33 34 * <<12345678901234 70 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 * 5678901234567890
15:52:33.793 Rcvd Ether Dst 00:00:a8:43:52:22 Src 00:12:3f:82:57:10 Type 0800 +(IP) IP Ver/HL 45, ToS 8, Len 254, ID 2e87, Flg/Frg 2048, TTL 3f, Prtl 6 Cksum 13da, Src c0a86432, Dst a404d80 TCP from 192.168.100.50. to 10.64.77.128. *fragments*, 576 bytes data offset 0 . . . 4 . . . 8 . . . C . . . 0…4… 8…C… 0 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 * 1234567890123456 10 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 * 7890123456789012 20 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 * 3456789012345678 30 39 30 d a 31 32 33 34 35 36 37 38 39 30 31 32 * 90<<123456789012 40 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 * 3456789012345678 50 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 * 9012345678901234 60 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 * 5678901234567890 70 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 * 1234567890123456
15:52:33.793 Rcvd Ether Dst 00:00:a8:43:52:22 Src 00:12:3f:82:57:10 Type 0800 +(IP) IP Ver/HL 45, ToS 8, Len f8, ID 2e87, Flg/Frg 90, TTL 3f, Prtl 6 Cksum 34ee, Src c0a86432, Dst a404d80 TCP from 192.168.100.50. to 10.64.77.128. *fragments., 228 bytes data offset 0 . . . 4 . . . 8 . . . C . . . 0…4… 8…C… 0 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 * 5678901234567890 10 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 * 1234567890123456 20 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 * 7890123456789012 30 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 * 3456789012345678 40 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 * 9012345678901234 50 35 36 37 38 39 30 d a 31 32 33 34 35 36 37 38 * 567890<<12345678 60 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 * 9012345678901234 70 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 * 5678901234567890
Das Problem bei der Erhöhung des MSS-Wertes ist, dass er für alle TCP-Verbindungen erhöht wird. Sie können ihn nicht nur für ein oder einige wenige Ziele erhöhen. Daher müssen Sie diese Änderung sorgfältig testen, um ihre Auswirkungen auf alle Ihre Verbindungen zu messen.
Sie können den aktuellen MSS-Wert sehen und mit den folgenden beiden Befehlen ändern:
analyze_system -request_line 'list_stcp_params min_mss' -quitOpenVOS Release 17.0.1as, analyze_system Release 17.0.1asCurrent process is 357, ptep 8FA86000, Noah_Davids.SysAdmin
maximum tcp segment size [500-1480] (min_mss) 556
ready 10:52:07analyze_system -request_line 'set_stcp_param min_mss 1480' -quit OpenVOS Release 17.0.1as, analyze_system Release 17.0.1asCurrent process is 357, ptep 8FA86000, Noah_Davids.SysAdmin
Changing maximum tcp segment size (min_mss)from 556 to 1480ready 10:52:24
Der Name des Parameters, min_mss, impliziert, dass es sich um den MSS-Wert handelt, aber in Wirklichkeit handelt es sich um den MSS-Wert plus die TCP-Header-Länge von 20 Byte. Für das obige Beispiel würden Sie den min_mss-Wert auf 556+20 oder 576 setzen.
Wie viel mehr kann man also durch eine Erhöhung des MSS-Wertes erreichen? Wegen der weiten Verbreitung von VPN-Verbindungen, die Overhead-Bytes hinzufügen, empfehle ich nicht, den Höchstwert von 1480 (tatsächliche TCP-MSS von 1460) einzustellen. Ich schlage einen etwas kleineren Wert vor, beispielsweise 1220 (tatsächliche MSS 1200) Bytes. Angenommen, Sie senden 10 Megabyte Daten mit 536-Byte-Segmenten, dann werden 18657 Frames benötigt. Die Gesamtzahl der Bytes - einschließlich des Overheads (8-Byte-Ethernet-Präambel + 14-Byte-Ethernet-Header + 20-Byte-IP-Header + 20-Byte-TCP-Header + 4-Byte-Ethernet-Trailer + effektiv 12 Bytes für die Ethernet-Inter-Frame-Lücke) beträgt 11.455.246 Bytes. Bei Verwendung von 1200-Byte-Segmenten werden 8334 Rahmen mit einer Gesamtzahl von 10.650.052 Bytes oder etwas mehr als 9 % weniger benötigt. Beachten Sie jedoch, dass der MSS-Wert eine Ankündigung des größten akzeptierten Segments ist; es ist nicht erforderlich, dass der sendende Host tatsächlich so große Segmente sendet. Unter der Annahme, dass dies der Fall ist und es keine anderen Engpässe gibt, hat sich der Durchsatz um 9 % erhöht.
Können wir auf der UDP-Seite etwas tun?
Bei UDP gibt es kein Konzept für die maximale Segmentgröße, so dass es keinen Parameter gibt, um diese einzustellen.