Erläuterung des Drei-Wege-Handshakes über TCP/IP
In diesem Artikel wird der dreiseitige TCP-Handshakeprozess (Transmission Control Protocol) zwischen einem Client und einem Server beim Starten oder Beenden einer TCP-Verbindung erläutert.
Gilt für: Windows Server 2012 R2
Ursprüngliche KB-Nummer: 172983
Zusammenfassung
Dieser Artikel richtet sich an Zielgruppen, die mit TCP/IP (Transmission Control Protocol/Internet Protocol) vertraut sind. Es wird der Prozess des TCP-Drei-Wege-Handshakes zwischen einem Client und server beim Starten oder Beenden einer TCP-Verbindung erläutert.
Weitere Informationen
Die TCP-Ebene des TCP/IP-Transportprotokolls ist verbindungsorientiert. Verbindungsorientiert bedeutet, dass vor der Übertragung von Daten eine zuverlässige Verbindung hergestellt und bestätigt werden muss. Datenübertragungen auf TCP-Ebene, Verbindungsaufbau und Verbindungsbeendigung behalten bestimmte Steuerungsparameter bei, die den gesamten Prozess steuern. Die Steuerbits werden wie folgt aufgelistet:
URG: Dringendes Zeigerfeld signifikant
ACK: Bestätigungsfeld signifikant
PSH: Push-Funktion
RST: Zurücksetzen der Verbindung
SYN: Synchronisieren von Sequenznummern
FIN: Keine Weiteren Daten vom Absender
Es gibt zwei Szenarien, in denen ein Drei-Wege-Handshake stattfindet:
Herstellen einer Verbindung (aktiv geöffnet)
Beenden einer Verbindung (aktives Schließen)
Die folgenden Beispielinformationen wurden aus einer Netzwerkmonitorerfassung abgerufen. Network Monitor ist ein Protokollanalysetool, das von Microsoft Systems Management Server abgerufen werden kann.
Herstellen einer Verbindung
Die folgende Sequenz zeigt den Prozess, bei dem eine TCP-Verbindung hergestellt wird:
Frame 1:
Wie Sie im ersten Frame sehen, sendet der Client NTW3 ein SYN-Segment (TCP ....S.). Es handelt sich um eine Anforderung an den Server, die Sequenznummern zu synchronisieren. Es gibt seine anfängliche Sequenznummer (ISN) an. Die ISN wird um 1 erhöht (8221821+1=8221822) und an den Server gesendet. Um eine Verbindung zu starten, müssen Client und Server die Sequenznummern der jeweils anderen Synchronisieren. Es gibt auch eine Option zum Festlegen der maximalen Segmentgröße (Maximum Segment Size, MSS), die durch die Länge (len: 4) definiert wird. Diese Option kommuniziert den MSS, den der Absender empfangen möchte. Das Bestätigungsfeld (ack: 0) ist auf 0 festgelegt, da es der erste Teil des Drei-Wege-Handshakes ist.
1 2.0785 NTW3 --> BDC3 TCP ....S., len: 4, seq: 8221822-8221825, ack: 0,
win: 8192, src: 1037 dst: 139 (NBT Session) NTW3 --> BDC3 IP
TCP: ....S., len: 4, seq: 8221822-8221825, ack: 0, win: 8192, src: 1037
dst: 139 (NBT Session)
TCP: Source Port = 0x040D
TCP: Destination Port = NETBIOS Session Service
TCP: Sequence Number = 8221822 (0x7D747E)
TCP: Acknowledgement Number = 0 (0x0)
TCP: Data Offset = 24 (0x18)
TCP: Reserved = 0 (0x0000)
TCP: Flags = 0x02 : ....S.
TCP: ..0..... = No urgent data
TCP: ...0.... = Acknowledgement field not significant
TCP: ....0... = No Push function
TCP: .....0.. = No Reset
TCP: ......1. = Synchronize sequence numbers
TCP: .......0 = No Fin
TCP: Window = 8192 (0x2000)
TCP: Checksum = 0xF213
TCP: Urgent Pointer = 0 (0x0)
TCP: Options
TCP: Option Kind (Maximum Segment Size) = 2 (0x2)
TCP: Option Length = 4 (0x4)
TCP: Option Value = 1460 (0x5B4)
TCP: Frame Padding
00000: 02 60 8C 9E 18 8B 02 60 8C 3B 85 C1 08 00 45 00 .`.....`.;....E.
00010: 00 2C 0D 01 40 00 80 06 E1 4B 83 6B 02 D6 83 6B .,..@....K.k...k
00020: 02 D3 04 0D 00 8B 00 7D 74 7E 00 00 00 00 60 02 .......}t~....`.
00030: 20 00 F2 13 00 00 02 04 05 B4 20 20 .........
Frame 2:
Wie Sie im zweiten Frame sehen, sendet der Server BDC3 ein ACK- und SYN-Segment (TCP .A..S.). In diesem Segment bestätigt der Server die Anforderung des Clients für die Synchronisierung. In der Zwischenzeit sendet der Server auch seine Anforderung zur Synchronisierung seiner Sequenznummern an den Client. Es gibt einen großen Unterschied in diesem Segment. Der Server überträgt eine Bestätigungsnummer (8221823) an den Client. Die Bestätigung ist nur der Beweis für den Client, dass der ACK spezifisch für das VOM Client initiierte SYN ist. Der Prozess der Bestätigung der Clientanforderung ermöglicht es dem Server, die Sequenznummer des Clients um eins zu erhöhen und als Bestätigungsnummer zu verwenden.
2 2.0786 BDC3 --> NTW3 TCP .A..S., len: 4, seq: 1109645-1109648, ack:
8221823, win: 8760, src: 139 (NBT Session) dst: 1037 BDC3 --> NTW3 IP
TCP: .A..S., len: 4, seq: 1109645-1109648, ack: 8221823, win: 8760,
src: 139 (NBT Session) dst: 1037
TCP: Source Port = NETBIOS Session Service
TCP: Destination Port = 0x040D
TCP: Sequence Number = 1109645 (0x10EE8D)
TCP: Acknowledgement Number = 8221823 (0x7D747F)
TCP: Data Offset = 24 (0x18)
TCP: Reserved = 0 (0x0000)
TCP: Flags = 0x12 : .A..S.
TCP: ..0..... = No urgent data
TCP: ...1.... = Acknowledgement field significant
TCP: ....0... = No Push function
TCP: .....0.. = No Reset
TCP: ......1. = Synchronize sequence numbers
TCP: .......0 = No Fin
TCP: Window = 8760 (0x2238)
TCP: Checksum = 0x012D
TCP: Urgent Pointer = 0 (0x0)
TCP: Options
TCP: Option Kind (Maximum Segment Size) = 2 (0x2)
TCP: Option Length = 4 (0x4)
TCP: Option Value = 1460 (0x5B4)
TCP: Frame Padding
00000: 02 60 8C 3B 85 C1 02 60 8C 9E 18 8B 08 00 45 00 .`.;...`......E.
00010: 00 2C 5B 00 40 00 80 06 93 4C 83 6B 02 D3 83 6B .,[.@....L.k...k
00020: 02 D6 00 8B 04 0D 00 10 EE 8D 00 7D 74 7F 60 12 ...........}t`.
00030: 22 38 01 2D 00 00 02 04 05 B4 20 20 "8.-......
Frame 3:
Wie Sie im dritten Frame sehen, sendet der Client ein ACK-Segment (TCP .A....). In diesem Segment bestätigt der Client die Anforderung vom Server für die Synchronisierung. Der Client verwendet denselben Algorithmus, den der Server bei der Bereitstellung einer Bestätigungsnummer implementiert hat. Die Bestätigung der Serveranforderung für die Synchronisierung durch den Client schließt den Prozess zum Herstellen einer zuverlässigen Verbindung und des Drei-Wege-Handshakes ab.
3 2.787 NTW3 --> BDC3 TCP .A...., len: 0, seq: 8221823-8221823, ack:
1109646, win: 8760, src: 1037 dst: 139 (NBT Session) NTW3 --> BDC3 IP
TCP: .A...., len: 0, seq: 8221823-8221823, ack: 1109646, win: 8760,
src: 1037 dst: 139 (NBT Session)
TCP: Source Port = 0x040D
TCP: Destination Port = NETBIOS Session Service
TCP: Sequence Number = 8221823 (0x7D747F)
TCP: Acknowledgement Number = 1109646 (0x10EE8E)
TCP: Data Offset = 20 (0x14)
TCP: Reserved = 0 (0x0000)
TCP: Flags = 0x10 : .A....
TCP: ..0..... = No urgent data
TCP: ...1.... = Acknowledgement field significant
TCP: ....0... = No Push function
TCP: .....0.. = No Reset
TCP: ......0. = No Synchronize
TCP: .......0 = No Fin
TCP: Window = 8760 (0x2238)
TCP: Checksum = 0x18EA
TCP: Urgent Pointer = 0 (0x0)
TCP: Frame Padding
00000: 02 60 8C 9E 18 8B 02 60 8C 3B 85 C1 08 00 45 00 .`.....`.;....E.
00010: 00 28 0E 01 40 00 80 06 E0 4F 83 6B 02 D6 83 6B .(..@....O.k...k
00020: 02 D3 04 0D 00 8B 00 7D 74 7F 00 10 EE 8E 50 10 .......}t....P.
00030: 22 38 18 EA 00 00 20 20 20 20 20 20 "8....
Beenden einer Verbindung
Obwohl der Drei-Wege-Handshake erfordert, dass nur drei Pakete über unsere Netzwerkmedien übertragen werden, muss die Beendigung dieser zuverlässigen Verbindung vier Pakete übertragen. Da eine TCP-Verbindung vollduplex ist (Daten können in jede Richtung unabhängig von der anderen fließen), muss jede Richtung unabhängig voneinander beendet werden.
Frame 4:
In dieser Sitzung von Frames sehen Sie, wie der Client ein FIN sendet, das von einem ACK (TCP .A...F) begleitet wird. Dieses Segment verfügt über zwei grundlegende Funktionen. Wenn der FIN-Parameter festgelegt ist, wird der Server zunächst darüber informiert, dass keine weiteren Daten zum Senden vorhanden sind. Zweitens ist die ACK für die Identifizierung der spezifischen Verbindung, die sie hergestellt haben, von entscheidender Bedeutung.
4 16.0279 NTW3 --> BDC3 TCP .A...F, len: 0, seq: 8221823-8221823,
ack:3462835714, win: 8760, src: 2337 dst: 139 (NBT Session) NTW3 --> BDC3
IP
TCP: .A...F, len: 0, seq: 8221823-8221823, ack: 1109646, win: 8760, src:
1037 dst: 139 (NBT Session)
TCP: Source Port = 0x040D
TCP: Destination Port = NETBIOS Session Service
TCP: Sequence Number = 8221823 (0x7D747F)
TCP: Acknowledgement Number = 1109646 (0x10EE8E)
TCP: Data Offset = 20 (0x14)
TCP: Reserved = 0 (0x0000)
TCP: Flags = 0x11 : .A...F
TCP: ..0..... = No urgent data
TCP: ...1.... = Acknowledgement field significant
TCP: ....0... = No Push function
TCP: .....0.. = No Reset
TCP: ......0. = No Synchronize
TCP: .......1 = No more data from sender
TCP: Window = 8760 (0x2238)
TCP: Checksum = 0x236C
TCP: Urgent Pointer = 0 (0x0)
00000: 00 20 AF 47 93 58 00 A0 C9 22 F5 39 08 00 45 00 . .G.X...".9..E.
00010: 00 28 9B F5 40 00 80 06 21 4A C0 5E DE 7B C0 5E .(..@...!J.^.{.^
00020: DE 57 09 21 05 48 0B 20 96 AC CE 66 AE 02 50 11 .W.!.H. ...f..P.
00030: 22 38 23 6C 00 00 "8#l..
Frame 5:
In diesem Rahmen sehen Sie nichts Besonderes außer dem Server, der die vom Client übertragene FIN bestätigt.
5 16.0281 BDC3 --> NTW3 TCP .A...., len: 0, seq: 1109646-1109646,
ack: 8221824, win:28672, src: 139 dst: 2337 (NBT Session) BDC3 --> NTW3
IP
TCP: .A...., len: 0, seq: 1109646-1109646, ack: 8221824, win:28672, src:
139 dst: 2337 (NBT Session)
TCP: Source Port = 0x040D
TCP: Destination Port = NETBIOS Session Service
TCP: Sequence Number = 1109646 (0x10EE8E)
TCP: Acknowledgement Number = 8221824 (0x7D7480)
TCP: Data Offset = 20 (0x14)
TCP: Reserved = 0 (0x0000)
TCP: Flags = 0x10 : .A....
TCP: ..0..... = No urgent data
TCP: ...1.... = Acknowledgement field significant
TCP: ....0... = No Push function
TCP: .....0.. = No Reset
TCP: ......0. = No Synchronize
TCP: .......0 = No Fin
TCP: Window = 28672 (0x7000)
TCP: Checksum = 0xD5A3
TCP: Urgent Pointer = 0 (0x0)
TCP: Frame Padding
00000: 00 A0 C9 22 F5 39 08 00 02 03 BA 84 08 00 45 00 ...".9........E.
00010: 00 28 D2 82 00 00 3F 06 6B BD C0 5E DE 57 C0 5E .(....?.k..^.W.^
00020: DE 7B 05 48 09 21 CE 66 AE 02 0B 20 96 AD 50 10 .{.H.!.f... ..P.
00030: 70 00 D5 A3 00 00 90 00 01 00 86 00 p...........
Frame 6:
Nachdem der Fin vom Clientcomputer empfangen wurde, wird der Server ACK. Obwohl TCP Verbindungen zwischen den beiden Computern hergestellt hat, sind die Verbindungen immer noch unabhängig voneinander. Der Server muss also auch eine FIN (TCP .A...F) an den Client übertragen.
6 17.0085 BDC3 --> NTW3 TCP .A...F, len: 0, seq: 1109646-1109646, ack:
8221824, win:28672, src: 139 dst: 2337 (NBT Session) BDC3 --> NTW3 IP
TCP: .A...F, len: 0, seq: 1109646-1109646, ack: 8221824, win:28672, src:
139 dst: 2337 (NBT Session)
TCP: Source Port = 0x0548
TCP: Destination Port = 0x0921
TCP: Sequence Number = 1109646 (0x10EE8E)
TCP: Acknowledgement Number = 8221824 (0x7D7480)
TCP: Data Offset = 20 (0x14)
TCP: Reserved = 0 (0x0000)
TCP: Flags = 0x11 : .A...F
TCP: ..0..... = No urgent data
TCP: ...1.... = Acknowledgement field significant
TCP: ....0... = No Push function
TCP: .....0.. = No Reset
TCP: ......0. = No Synchronize
TCP: .......1 = No more data from sender
TCP: Window = 28672 (0x7000)
TCP: Checksum = 0xD5A2
TCP: Urgent Pointer = 0 (0x0)
TCP: Frame Padding
00000: 00 A0 C9 22 F5 39 08 00 02 03 BA 84 08 00 45 00 ...".9........E.
00010: 00 28 D2 94 00 00 3F 06 6B AB C0 5E DE 57 C0 5E .(....?.k..^.W.^
00020: DE 7B 05 48 09 21 CE 66 AE 02 0B 20 96 AD 50 11 .{.H.!.f... ..P.
00030: 70 00 D5 A2 00 00 02 04 05 B4 86 00 p...........
Frame 7:
Der Client antwortet im gleichen Format wie der Server, indem er die FIN des Servers ackkingt und die Sequenznummer um 1 erhöht.
7 17.0085 NTW3 --> BDC3 TCP .A...., len: 0, seq: 8221824-8221824, ack:
1109647, win: 8760, src: 2337 dst: 139 (NBT Session) NTW3 --> BDC3 IP
TCP: .A...., len: 0, seq: 8221824-8221824, ack: 1109647, win: 8760, src:
2337 dst: 139 (NBT Session)
TCP: Source Port = 0x0921
TCP: Destination Port = 0x0548
TCP: Sequence Number = 8221824 (0x7D7480)
TCP: Acknowledgement Number = 1109647 (0x10EE8F)
TCP: Data Offset = 20 (0x14)
TCP: Reserved = 0 (0x0000)
TCP: Flags = 0x10 : .A....
TCP: ..0..... = No urgent data
TCP: ...1.... = Acknowledgement field significant
TCP: ....0... = No Push function
TCP: .....0.. = No Reset
TCP: ......0. = No Synchronize
TCP: .......0 = No Fin
TCP: Window = 8760 (0x2238)
TCP: Checksum = 0x236B
TCP: Urgent Pointer = 0 (0x0)
00000: 00 20 AF 47 93 58 00 A0 C9 22 F5 39 08 00 45 00 . .G.X...".9..E.
00010: 00 28 BA F5 40 00 80 06 02 4A C0 5E DE 7B C0 5E .(..@....J.^.{.^
00020: DE 57 09 21 05 48 0B 20 96 AD CE 66 AE 03 50 10 .W.!.H. ...f..P.
00030: 22 38 23 6B 00 00 "8#k..
Die Client-ACKing der FIN-Benachrichtigung vom Server identifiziert eine ordnungsgemäße Schließung einer TCP-Verbindung.
References
Abrufen von RFC 793.
RFCs können wie folgt über das Internet bezogen werden:
Papierkopien aller RFCs sind bei der NIC erhältlich, entweder einzeln oder auf Abonnementbasis (für weitere Informationen wenden Sie sich an NIC@NIC.DDN.MIL). Onlinekopien sind über FTP oder Kermit aus NIC.DDN.MIL als rfc/rfc####.txt oder rfc/rfc####.PS verfügbar (#### ist die RFC-Nummer ohne führende Nullen).
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für