Freigeben über


Erläuterung des dreiseitigen Handshakes über TCP/IP

In diesem Artikel wird der Drei-Wege-Handshake-Prozess (Transmission Control Protocol, TCP) zwischen einem Client und einem Server beim Starten oder Beenden einer TCP-Verbindung erläutert.

Ursprüngliche KB-Nummer: 172983

Übersicht

Dieser Artikel richtet sich an Zielgruppen, die mit dem Transmission Control Protocol/Internet Protocol (TCP/IP) vertraut sind. Es wird der Prozess des dreiseitigen TCP-Handshakes zwischen einem Client und einem 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 eingeholt und bestätigt werden muss. Tcp-Level-Datenübertragungen, Verbindungseinrichtung und Verbindungsbeendigung verwalten bestimmte Kontrollparameter, die den gesamten Prozess steuern. Die Steuerelementbits werden wie folgt aufgeführt:

URG: Dringendes Zeigerfeld signifikant
ACK: Bestätigungsfeld signifikant
PSH: Push-Funktion
RST: Zurücksetzen der Verbindung
SYN: Sequenznummern synchronisieren
FIN: Keine weiteren Daten vom Absender

Es gibt zwei Szenarien, in denen ein dreiseitiger Handshake stattfindet:

  • Herstellen einer Verbindung (aktiv geöffnet)

  • Beenden einer Verbindung (aktives Schließen)

Die folgenden Beispielinformationen wurden aus einer Netzwerküberwachungserfassung abgerufen. Der Netzwerkmonitor ist ein Protokollanalysator, der von Microsoft Systems Management Server abgerufen werden kann.

Herstellen einer Verbindung

Die folgende Sequenz zeigt den Prozess einer TCP-Verbindung, die eingerichtet wird:

Frame 1:

Wie Sie im ersten Frame sehen, sendet der Client NTW3 ein SYN-Segment (TCP ....S.). Es ist eine Anforderung an den Server, die Sequenznummern zu synchronisieren. Es gibt seine ursprüngliche Sequenznummer (ISN) an. Der ISN wird um 1 (8221821+1=8221822) erhöht und an den Server gesendet. Um eine Verbindung zu starten, muss der Client und der Server die Sequenznummern der anderen synchronisieren. Es gibt auch eine Option für die festzulegende maximale Segmentgröße (MSS), die durch die Länge (Länge: 4) definiert wird. Diese Option kommuniziert den MSS, den der Absender empfangen möchte. Das Bestätigungsfeld (ack: 0) ist auf Null festgelegt, da es sich um den ersten Teil des dreiseitigen Handshakes handelt.


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 zur Synchronisierung. Unterdessen sendet der Server auch seine Anforderung an den Client zur Synchronisierung seiner Sequenznummern. In diesem Segment gibt es einen wesentlichen Unterschied. Der Server überträgt eine Bestätigungsnummer (8221823) an den Client. Die Bestätigung ist nur der Beweis für den Client, dass die ACK für die SYN spezifisch ist, die der Client initiiert hat. Der Prozess der Bestätigung der Clientanforderung ermöglicht es dem Server, die Sequenznummer des Clients um eine 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 des Clients für die Synchronisierungsanforderung des Servers schließt den Prozess der Einrichtung einer zuverlässigen Verbindung und den dreiseitigen Handshake 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 nur drei Pakete über unsere vernetzten Medien übertragen werden muss, muss die Beendigung dieser zuverlässigen Verbindung vier Pakete übertragen werden. Da eine TCP-Verbindung vollduplex ist (Daten können unabhängig von der anderen Richtung fließen), muss jede Richtung unabhängig voneinander beendet werden.

Frame 4:

In dieser Framessitzung sehen Sie, dass der Client eine FIN sendet, die von einer ACK (TCP .A...FACK) begleitet wird. Dieses Segment verfügt über zwei grundlegende Funktionen. Wenn der FIN-Parameter festgelegt ist, informiert er zuerst den Server darüber, dass er keine weiteren Zusendungsdaten enthält. Zweitens ist die ACK wichtig, um die spezifische Verbindung zu identifizieren, die sie eingerichtet haben.


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 Frame wird nichts Besonderes angezeigt, außer dass der Server die FIN bestätigt, die vom Client übertragen wurde.


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 die 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 acKing der FIN des Servers und die Sequenznummer um 1 erhöht wird.


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..

Der Client ACKing der FIN-Benachrichtigung vom Server identifiziert eine ordnungsgemäße Schließung einer TCP-Verbindung.

References

Beziehen Sie RFC 793.

RfCs können über das Internet wie folgt bezogen werden:

Papierkopien aller RFCs sind entweder einzeln oder auf Abonnementbasis erhältlich (für weitere Informationen).NIC@NIC.DDN.MIL Onlinekopien sind über FTP oder Kermit von NIC.DDN.MIL als rfc/rfc####.txt oder rfc/rfc####.PS verfügbar (#### ist die RFC-Nummer ohne führende Nullen).