Zum Hauptinhalt springen
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' -quit
OpenVOS Release 17.0.1as, analyze_system Release 17.0.1as
Current process is 357, ptep 8FA86000, Noah_Davids.SysAdmin

maximum tcp segment size [500-1480] (min_mss) 556

ready 10:52:07
analyze_system -request_line 'set_stcp_param min_mss 1480' -quit 
OpenVOS Release 17.0.1as, analyze_system Release 17.0.1as
Current process is 357, ptep 8FA86000, Noah_Davids.SysAdmin

Changing maximum tcp segment size (min_mss)
from 556 to 1480
ready 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.

2 Kommentare

  • Ashutosh Warikoo sagt:

    Können wir auf der UDP-Seite etwas tun?

  • Noah Davids sagt:

    Bei UDP gibt es kein Konzept für die maximale Segmentgröße, so dass es keinen Parameter gibt, um diese einzustellen.

© 2024 Stratus Technologies.