Ab OpenVOS 17.1 unterstützt STCP die TCP-Optionen „Time Stamp“, „Selective Acknowledgment“ und „Window Scaling“. Dies ermöglicht einen effizienteren Datenfluss, wenn TCP-Segmente verloren gehen oder wenn Daten über eine Verbindung mit hoher Bandbreite und hoher Latenz übertragen werden (eine Verbindung über eine Leitung, bei der die Mindestbandbreite * Gesamtlatenz > 65536 ist). Die Auswirkungen dieser Änderungen sind für Anwendungen transparent, doch gibt es einige Punkte, die Sie bei der Verwendung von packet_monitor beachten sollten.
Erstens: Wenn STCP eine Verbindungsanfrage sendet, enthält das TCP-(SYN-)Segment nun 16 zusätzliche Bytes.
17:41:26.533 Xmit Ether Dst 00:23:54:52:18:6e Src 00:00:a8:41:34:56 Type 0800
+(IP)
IP Ver/HL 45, ToS 0, Len 3c, ID a789, Flg/Frg 0, TTL 3c, Prtl 6
Cksum f2f6, Src a4984dd9, Dst a4984d32
TCP from 164.152.77.217.55423 to 164.152.77.50.7777
seq 3825990103, ack n.a., window 8192, 20 data bytes, flags Syn.
X/Off 0a, Flags 02, Cksum b717, Urg-> 0000
offset 0 . . . 4 . . . 8 . . . C . . . 0...4... 8...C...
0 2 4 5 b4 3 3 6 4 2 8 a 32 2d bc 85 0 <<<4<<<< <<<2-<>
10 0 0 0 0
|
| 2 4 5 b4 | Option 2 (Mindestsegmentgröße), Gesamtlänge der Option 4 Bytes, Wert 05 b4 (1460 dezimal) (diese Bytes sind nicht neu) |
| 3 3 6 | Option 3 (Fenselskala), Gesamtlänge von Option 3 Bytes, Wert 6 |
| 4 2 | Option 4 (selektive Bestätigung unterstützt), Gesamtlänge 2 Byte |
| 8 a 32 2d v. Chr. 85 0 0 0 0 | Option 8 (Zeitstempel), Gesamtlänge 10 Byte, Sendezeit 32 2d bc 85, Empfangszeit 0 0 0 0 |
| 0 | Option 0 (Ende der Optionen) |
Zweitens hängen die in einem Verbindungsantwort-Segment (SYN/ACK) gesendeten Optionen davon ab, was das SYN-Segment des Remote-Hosts enthält. STCP fügt die Option für die selektive Bestätigung nur dann in seine Antwort ein, wenn diese in der Verbindungsanfrage enthalten ist. Die Antwort enthält die Optionen „Window Scale“ und „Time Stamp“ nur dann, wenn die Verbindungsanfrage ebenfalls beide Optionen enthält.
14:31:32.145 Rcvd Ether Dst 00:00:a8:42:34:56 Src 00:00:a8:42:52:22 Type 0800
+(IP)
IP Ver/HL 45, ToS 0, Len 3c, ID 44c, Flg/Frg 0, TTL 3c, Prtl 6
Cksum 95e6, Src a4984d80, Dst a4984dd9
TCP from 164.152.77.128.65007 to 164.152.77.217.7777
seq 3289184624, ack n.a., window 8192, 20 data bytes, flags Syn.
X/Off 0a, Flags 02, Cksum 91e8, Urg-> 0000
offset 0 . . . 4 . . . 8 . . . C . . . 0...4... 8...C...
0 2 4 5 b4 3 3 6 4 2 8 a 30 b8 95 1a 0 <<<4<<<< <<<08><
10 0 0 0 0 <<<<
14:31:32.146 Xmit Ether Dst 00:00:a8:42:52:22 Src 00:00:a8:42:34:56 Type 0800
+(IP)
IP Ver/HL 45, ToS 0, Len 3c, ID 0, Flg/Frg 0, TTL 3c, Prtl 6
Cksum 9a32, Src a4984dd9, Dst a4984d80
TCP from 164.152.77.217.7777 to 164.152.77.128.65007
seq 3172667591, ack 3289184625, window 8192, 20 data bytes, flags Syn Ack.
X/Off 0a, Flags 12, Cksum 6b81, Urg-> 0000
offset 0 . . . 4 . . . 8 . . . C . . . 0...4... 8...C...
0 2 4 5 b4 3 3 6 4 2 8 a 1 35 72 23 30 <<<4<<<< <<<<5r#0
10 b8 95 1a 0 8><<
|
Standardmäßig enthalten Windows-Hosts nur die maximale Segmentgröße, Fenstergröße und unterstützte selektive Bestätigung . Ohne die Zeitstempel-Option in der Verbindungsanfrage enthält die Antwort von STCP weder die Zeitstempel- noch die Fensterskalierungsoptionen. Beachten Sie, dass die in den Windows-Optionen enthaltenen „1“ die NO-OP und dienen dazu, die Anzahl der Optionsbytes auf ein ganzzahliges Vielfaches von 4 zu bringen. Das Vielfache Endes der Optionen (Nullen) am Ende der Optionen in der Antwort von STCP dienen demselben Zweck.
14:54:02.635 Rcvd Ether Dst 00:00:a8:41:34:56 Src 00:23:54:52:18:6e Type 0800
+(IP)
IP Ver/HL 45, ToS 0, Len 34, ID a4f, Flg/Frg 4000, TTL 80, Prtl 6
Cksum 0c39, Src a4984d32, Dst a4984dd9
TCP from 164.152.77.50.13478 to 164.152.77.217.7777
seq 3499417963, ack n.a., window 8192, 12 data bytes, flags Syn.
X/Off 08, Flags 02, Cksum 65c8, Urg-> 0000
offset 0 . . . 4 . . . 8 . . . C . . . 0...4... 8...C...
0 2 4 5 b8 1 3 3 8 1 1 4 2 <<<8<<<< <<<<
14:54:02.636 Xmit Ether Dst 00:23:54:52:18:6e Src 00:00:a8:41:34:56 Type 0800
+(IP)
IP Ver/HL 45, ToS 0, Len 30, ID b3d5, Flg/Frg 0, TTL 3c, Prtl 6
Cksum e6b6, Src a4984dd9, Dst a4984d32
TCP from 164.152.77.217.7777 to 164.152.77.50.13478
seq 3986949958, ack 3499417964, window 8192, 8 data bytes, flags Syn Ack.
X/Off 07, Flags 12, Cksum 85e0, Urg-> 0000
offset 0 . . . 4 . . . 8 . . . C . . . 0...4... 8...C...
0 2 4 5 b4 4 2 0 0 <<<4<<
|
Verwirrend wird es, nachdem die Verbindung hergestellt wurde. Das folgende Paket enthält nur 1 Byte an Daten, obwohl die Datenbyte 13 anzeigt. Die ersten 12 Bytes sind zwei NO-OP-Optionen, gefolgt von einer Zeitstempel-Option. Das Datenbyte ist das 0x am Ende.
15:02:36.545 Rcvd Ether Dst 00:00:a8:41:34:56 Src 00:00:a8:42:52:22 Type 0800
+(IP)
IP Ver/HL 45, ToS 0, Len 35, ID 447, Flg/Frg 0, TTL 3c, Prtl 6
Cksum 95f2, Src a4984d80, Dst a4984dd9
TCP from 164.152.77.128.60312 to 164.152.77.217.7777
seq 2814493687, ack 4102208833, window 128, 13 data bytes, flags Push Ack
+.
X/Off 08, Flags 18, Cksum c9d0, Urg-> 0000
offset 0 . . . 4 . . . 8 . . . C . . . 0...4... 8...C...
0 1 1 8 a 2a 28 5d 8f 38 9f e0 a 0 <<<<*(]> 8>`<
|
Wie kann ich Optionen und Daten unterscheiden? Die X/Off ist die Anzahl der 32-Bit-Wörter im TCP-Header. Wenn keine Optionen vorhanden sind, beträgt dieser Wert 5; ein Wert von 8 bedeutet also, dass drei 32-Bit-Wörter oder 12 weitere Bytes hinzugefügt wurden.
Das nächste Paket ist lediglich eine Bestätigung und enthält keine Daten. Beachten Sie, dass der Offset erneut 8 beträgt, sodass die Option 12 Byte umfasst und die Datenlänge ebenfalls 12 beträgt.
15:02:39.758 Xmit Ether Dst 00:00:a8:42:52:22 Src 00:00:a8:41:34:56 Type 0800
+(IP)
IP Ver/HL 45, ToS 0, Len 34, ID 48a, Flg/Frg 0, TTL 3c, Prtl 6
Cksum 95b0, Src a4984dd9, Dst a4984d80
TCP from 164.152.77.217.7777 to 164.152.77.128.60312
seq 4102208833, ack 2814493688, window 128, 12 data bytes, flags Ack.
X/Off 08, Flags 10, Cksum a751, Urg-> 0000
offset 0 . . . 4 . . . 8 . . . C . . . 0...4... 8...C...
0 1 1 8 a 38 a0 2 91 2a 28 5d 8f <<<<8 <> *(]>
|
Das folgende Paket ist ein Beispiel für ein Segment, das eine selektiven Bestätigungsoption mit 3 Blöcken von Bestätigungsnummern enthält. Beachten Sie die X/Off -Wert von 0f, der auf zusätzliche 40 Bytes ((15 – 5) * 4) im TCP-Header hinweist, die packet_monitor als Datenbytes.
9:52:39.491 Rcvd Ether Dst 00:00:a8:41:34:56 Src 00:04:96:52:21:6f Type 0800
+ (IP)
IP Ver/HL 45, ToS 60, Len 50, ID 59, Flg/Frg 0, TTL 35, Prtl 6
Cksum 4355, Src 866fc8b9, Dst a4984dd9
TCP from 134.111.200.185.ftp-data to 164.152.77.217.53828
seq 1652086450, ack 3779437719, window 4096, 40 data bytes, flags Ack.
X/Off 0f, Flags 10, Cksum c834, Urg-> 0000
offset 0 . . . 4 . . . 8 . . . C . . . 0...4... 8...C...
0 1 1 8 a 2 9e 86 bd 3c 4b dd 57 1 1 5 1a <<<<<<<< >K<W<<<<
10 e1 45 f6 77 e1 45 f8 83 e1 45 f2 5f e1 45 f4 6b <E<w<E<< <E<_<E<k
20 e1 45 c9 6f e1 45 cb 7b <E<o<E<{
|
Die Bestätigungsnummer im TCP-Header entspricht dem rechtesten edge fortlaufend empfangenen Bytes. Die Datenblöcke bei der Option „Selektive Bestätigung“ kennzeichnen Datenblöcke, die bereits empfangen wurden. Die Lücken zwischen den Blöcken stehen für Bytes, die noch nicht empfangen wurden.
Das Ganze wäre viel einfacher, wenn `packet_monitor` die Optionen korrekt melden würde, anstatt sie als Daten auszugeben. Der Fehler „stcp-2963“ wurde hinzugefügt, um `packet_monitor` dazu zu bringen, genau das zu tun. Der Fehler soll in einer zukünftigen Version behoben werden; bis dahin müssen Sie auf den Wert von X/Off achten.
Die Option „Window Scale“ ist möglicherweise am verwirrendsten. Das folgende Paket zeigt ein Empfangsfenster von nur 4096 Byte.
9:52:38.975 Rcvd Ether Dst 00:00:a8:41:34:56 Src 00:04:96:52:21:6f Type 0800
+ (IP)
IP Ver/HL 45, ToS 60, Len 34, ID 8, Flg/Frg 0, TTL 35, Prtl 6
Cksum 43c2, Src 866fc8b9, Dst a4984dd9
TCP from 134.111.200.185.ftp-data to 164.152.77.217.53828
seq 1652086450, ack 3779392131, window 4096, 12 data bytes, flags Ack.
X/Off 08, Flags 10, Cksum a3cf, Urg-> 0000
offset 0 . . . 4 . . . 8 . . . C . . . 0...4... 8...C...
0 1 1 8 a 2 9e 86 39 3c 4b dc e3 <<<<<>><K<<<
|
Dies ist ein extrem kleines Fenster, doch die Größe täuscht, da die Fensterskalierung aktiv ist. Woran erkennt man das? Man kann dies nur feststellen, wenn man den Aufbau der ursprünglichen Verbindung beobachtet hat. Im folgenden Fall ist zu sehen, dass sowohl das SYN- als auch das SYN-ACK-Segment die Option „Window Scaling“ enthalten, und in beiden Fällen beträgt der Skalierungswert 6, sodass die Fenstergröße von 4096 (2^12) im obigen Segment um 6 Bits verschoben wird, was das tatsächliche Fenster von 262144 (2^18 oder 256K) Bytes ergibt.
9:52:38.818 Rcvd Ether Dst 00:00:a8:41:34:56 Src 00:04:96:52:21:6f Type 0800
+ (IP)
IP Ver/HL 45, ToS 60, Len 3c, ID 5, Flg/Frg 0, TTL 35, Prtl 6
Cksum 43bd, Src 866fc8b9, Dst a4984dd9
TCP from 134.111.200.185.ftp-data to 164.152.77.217.53828
seq 1652086449, ack n.a., window 8192, 20 data bytes, flags Syn.
X/Off 0a, Flags 02, Cksum 29fd, Urg-> 0000
offset 0 . . . 4 . . . 8 . . . C . . . 0...4... 8...C...
0 2 4 2 18 3 3 6 4 2 8 a 2 9e 86 11 0 <<<<<<<< <<<<>><
10 0 0 0 0
9:52:38.819 Xmit Ether Dst 00:13:d4:59:7a:da Src 00:00:a8:41:34:56 Type 0800
+ (IP)
IP Ver/HL 45, ToS 0, Len 3c, ID a, Flg/Frg 0, TTL 3c, Prtl 6
Cksum 3d18, Src a4984dd9, Dst 866fc8b9
TCP from 164.152.77.217.53828 to 134.111.200.185.ftp-data
seq 3779391082, ack 1652086450, window 8192, 20 data bytes, flags Syn Ack
+.
X/Off 0a, Flags 12, Cksum 3b87, Urg-> 0000
offset 0 . . . 4 . . . 8 . . . C . . . 0...4... 8...C...
0 2 4 5 b4 3 3 6 4 2 8 a 3c 4b dc cf 2 <<<<<<<< <<<<<K<
10 9e 86 11 0 >><
|
Diese Optionen werden durch STCP-Parameter gesteuert.
als: list_stcp_params
STCP-Parameter:
. . . .
kleinste maximale IP-Segmentgröße [500–1480] (min_mss) 576
. . . .
maximale Sendewindowgröße [4096–1073725440] (max_send_ws) 1073725440
maximale Anzahl großer Fenster [>=0] (max_huge_windows) 0
aktuelle Anzahl großer Fenster 0
maximale Anzahl 256k-Fenster [>=0] (max_256k_windows) 25
aktuelle Anzahl 256k-Fenster 0
. . . . .
TCP RFC-1323-Richtlinie [deaktivieren/zulassen/anfordern] (tcp_rfc_1323_policy) anfordern
TCP-Fenster-Skalierung [0–14] (tcp_window_scale) 6
TCP-SACK-Richtlinie [deaktivieren/zulassen/anfordern] (tcp_SACK_policy) anfordern
als:
|
Die tcp_rfc_1323_policy gibt an, ob Zeitstempel verwendet werden. Die möglichen Werte sind disable/allow/request. Der Standardwert request bedeutet, dass die Option Teil eines Verbindungsanforderungssegments ist und, falls in einer empfangenen Verbindungsanforderung angefordert, Teil des Antwortsegments sein wird. Der Wert „allow“ bedeutet, dass die Option nicht Teil eines Verbindungsanforderungssegments ist, aber Teil einer Antwort sein kann, wenn die empfangene Verbindungsanforderung sie enthält. Der Wert „disable“ bedeutet, dass die Option in keinem der beiden Segmenttypen enthalten ist. Die Einstellung auf „disable“ bedeutet außerdem, dass die Option „window scale“ nicht Teil des Segments ist.
Die Die Option steuert den Skalierungsparameter. Ein Wert von Null teilt dem Remote-Host mit, dass die Fensterskalierung zwar unterstützt wird, das STCP-Fenster jedoch nicht skaliert werden soll.
15:48:43.409 Rcvd IP Ver/HL 45, ToS 0, Len 3c, ID 450, Flg/Frg 0, TTL 3
+c, Prtl 6
Cksum 95e2, Src a4984d80, Dst a4984dd9
TCP from 164.152.77.128.65410 to 164.152.77.217.7777
seq 1987362195, ack n.a., window 8192, 20 data bytes, flags Syn.
X/Off 0a, Flags 02, Cksum b8b3, Urg-> 0000
offset 0 . . . 4 . . . 8 . . . C . . . 0...4... 8...C...
0 2 4 5 b4 3 3 6 4 2 8 a 30 ca ac 69 0 <<<4<<<< <<<0J,i
10 0 0 0 0
15:48:48.575 Xmit IP Ver/HL 45, ToS 0, Len 3c, ID 2, Flg/Frg 0, TTL 3
+c, Prtl 6
Cksum 9a30, Src a4984dd9, Dst a4984d80
TCP from 164.152.77.217.7777 to 164.152.77.128.65410
seq 3853608469, ack 1987362196, window 8192, 20 data bytes, flags Syn Ack.
X/Off 0a, Flags 12, Cksum c550, Urg-> 0000
offset 0 . . . 4 . . . 8 . . . C . . . 0...4... 8...C...
0 2 4 5 b4 3 3 0 4 2 8 a 1 47 89 66 30 <<<4<< < <<<<G>f0
10 ca ac 69 0 J,i
|
Die tcp_sack_policy steuert die Option für selektive Bestätigungen. Die Werte können „disable“, „allow“ und „request“ lauten und haben genau dieselbe Bedeutung wie bei der Option „tcp_rfc_1323_policy“.
Dank der Unterstützung für die Fensterskalierung sind nun Fenster möglich, die größer sind als das bisherige Maximum von 64 KB; daher wurden zwei neue Fenstergrößenpools eingerichtet. Diese spiegeln sich in den Pools „max_256k_windows“ und „max_huge_windows“ wider. Sie können die maximale Anzahl an Sockets, die ein 256-KB-Fenster oder ein noch größeres Fenster anbieten können, anpassen, indem Sie die Werte für „max_256k_windows“ oder „max_huge_windows“ festlegen.
Der Parameter `max_send_ws` spiegelt wider, dass das maximal mögliche Empfangsfenster des Remote-Hosts nun 2^30 beträgt (1073725440 entspricht tatsächlich 2^30 – 2^14). Für einen bestimmten Socket entspricht die tatsächliche maximale Größe des Sendefensters dem kleineren Wert aus dem Parameter `max_send_ws` und der vom Remote-Host gemeldeten Größe des Empfangsfensters.