Erklärung des Dreiwege-Handshakes über TCP/IP

SPRACHE AUSWÄHLEN SPRACHE AUSWÄHLEN
Artikel-ID: 172983 - Produkte anzeigen, auf die sich dieser Artikel bezieht
Dieser Artikel wurde zuvor veröffentlicht unter D172983
Alles erweitern | Alles schließen

Auf dieser Seite

Zusammenfassung

Dieser Artikel richtet sich an Benutzer, die mit TCP/IP (Transmission Control Protocol/Internet Protocol) vertraut sind, und beschreibt den Prozess des TCP-Dreiwege-Handshakes, der zwischen einem Client und einem Server beim Herstellen oder Beenden einer TCP-Verbindung stattfindet.

Weitere Informationen zu TCP/IP finden Sie in folgendem Whitepaper, das auf dem anonymen FTP-Server von Microsoft verfügbar ist:
Dateiname: Tcpipimp2.doc
Ort: ftp://ftp.microsoft.com/bussys/winnt/winnt-docs/papers/ "Microsoft Windows NT 3.5/3.51/4.0: TCP/IP Implementation Details TCP/IP Protocol Stack and Services, Version 2.0"

Weitere Informationen

Die TCP-Ebene des TCP/IP-Transportprotokolls ist verbindungsorientiert. Dies bedeutet, dass vor der Übertragung von Daten eine zuverlässige Verbindung hergestellt und bestätigt worden sein muss. Die Datenübertragung, die Verbindungsherstellung und die Verbindungstrennung auf TCP-Ebene weisen spezielle Steuerparameter auf, denen der gesamte Prozess unterworfen ist. Diese Steuerbits sind im Folgenden aufgelistet:
URG: Dringlichkeitszeiger-Feld signifikant
ACK: Bestätigungs-Feld signifikant
PSH: Push-Funktion
RST: Verbindung zurücksetzen
SYN: Sequenznummern synchronisieren
FIN: Keine Daten mehr vom Absender
Es gibt zwei Szenarios, in denen ein Dreiwege-Handshake stattfindet:
  • Herstellen einer Verbindung (ein "Aktiv geöffnet")
  • Beenden einer Verbindung (ein "Aktiv geschlossen")
Die folgenden Beispielinformationen sind einer Netzwerkmonitor-Aufzeichnung entnommen. Netzwerkmonitor ist ein Protokoll-Analyseprogramm, das in Microsoft Systems Management Server enthalten ist.

Herstellen einer Verbindung

Die folgende Sequenz zeigt den Prozess der Herstellung einer TCP-Verbindung:

Rahmen 1:

Wie im ersten Rahmen zu sehen, sendet der Client, NTW3, ein SYN-Segment (TCP ....S.). Dies ist eine Anforderung an den Server, die Sequenznummern zu synchronisieren. Der Client gibt seine einleitende Sequenznummer (ISN) an, die um 1 erhöht (8221821+1=8221822) und an den Server gesendet wird. Um eine Verbindung einzuleiten, müssen der Client und der Server ihre Sequenznummern gegenseitig synchronisieren. Es gibt ebenfalls eine Option für die Einstellung der maximalen Segmentgröße (MSS), die durch die Länge (len: 4) definiert wird. Mit dieser Option wird die maximale Segmentgröße übermittelt, die der Sender empfangen will. Das Bestätigungs-Feld (ack: 0) wird auf 0 gesetzt, weil dies der erste Teil des Dreiwege-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                .........
				
Rahmen 2:

Im zweiten Rahmen sendet der Server, BDC3, ein ACK und ein SYN auf diesem Segment (TCP .A..S.). In diesem Segment bestätigt der Server die Synchronisierungsanforderung des Clients. Zur gleichen Zeit sendet der Server ebenfalls eine Anforderung an den Client, seine Sequenznummern zu synchronisieren. Es gibt einen wichtigen Unterschied in diesem Segment. Der Server sendet eine Bestätigungsnummer (8221823) an den Client. Die Bestätigung dient als Beweis für den Client, dass das ACK sich auf das vom Client eingeleitete SYN bezieht. Der Prozess der Bestätigung der Clientanforderung ermöglicht dem Server, die Sequenznummer des Clients um 1 zu erhöhen und als seine 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.-......
				
Rahmen 3:

Im dritten Rahmen sendet der Client ein ACK auf diesem Segment (TCP .A....). In diesem Segment bestätigt der Client die Synchronisierungsanforderung des Servers. Der Client verwendet den gleichen Algorithmus, den der Server beim Bereitstellen einer Bestätigungsnummer implementiert hat. Durch die Bestätigung der Synchronisierungsanforderung des Servers durch den Client wird der Prozess der Herstellung einer zuverlässigen Verbindung und damit der Dreiwege-Handshake abgeschlossen.
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

Während für den Dreiwege-Handshake nur drei Pakete über das Netzwerkmedium zu übertragen sind, müssen für die Beendigung dieser zuverlässigen Verbindung vier Pakete übertragen werden. Da es sich bei einer TCP-Verbindung um eine Vollduplex-Verbindung (Daten können unabhängig voneinander in beide Richtungen fließen) handelt, muss jede Richtung separat beendet werden.

Rahmen 4:

In dieser Rahmensitzung sendet der Client ein FIN, das von einem ACK begleitet wird (TCP .A...F). Dieses Segment erfüllt zwei grundlegende Funktionen. Zum einen informiert es den Server durch das Senden des Parameters FIN, dass keine Daten mehr zu senden sind, zum anderen dient das ACK zur Identifizierung der von Client und Server hergestellten speziellen Verbindung.
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..
				
Rahmen 5:

In diesem Rahmen passiert nichts besonderes, außer dass der Server das vom Client übermittelte 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...........
				
Rahmen 6:

Nach dem Empfang des FIN vom Clientcomputer sendet der Server die Bestätigung (ACK). Obwohl die Verbindungen zwischen den beiden Computern beide über TCP eingerichtet wurden, sind die Verbindungen dennoch unabhängig voneinander. Daher muss der Server ebenfalls ein FIN (TCP .A...F) an den Client senden.
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...........
				
Rahmen 7:

Der Client antwortet im gleichen Format wie der Server, indem er das FIN des Servers durch ein ACK bestätigt 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..
				
Der Client, der die FIN-Benachrichtigung des Servers durch ACK bestätigt, identifiziert eine erfolgreiche Schließung einer TCP-Verbindung.

Informationsquellen

Weitere Informationen zu ICMP:
Lesen Sie den folgenden Artikel der Microsoft Knowledge Base:
170292 Grundlagen zu ICMP (Internet Control Message Protocol)
-oder-
Beziehen Sie RFC 793.
RFCs können wie folgt über das Internet bezogen werden:

Hardcopyexemplare aller RFCs können entweder einzeln oder im Abonnement von NIC bezogen werden (wenden Sie sich an NIC@NIC.DDN.MIL, um weitere Informationen zu erhalten). Onlineexemplare sind über FTP oder Kermit von NIC.DDN.MIL als rfc/rfc####.txt oder rfc/rfc####.PS (wobei #### die RFC-Nummer ohne vorangestellte Nullen ist) erhältlich.
Hinweis Dies ist ein Artikel, der im Schnellverfahren direkt von der Microsoft-Supportorganisation erstellt wurde. Die hierin enthaltenen Informationen werden als Reaktion auf neue Probleme wie besehen bereitgestellt. Da dieser Artikel im Schnellverfahren erstellt wurde, kann er Tippfehler enthalten und zu einem späteren Zeitpunkt ohne vorherige Ankündigung überarbeitet werden. Weitere zu berücksichtigende Informationen finden Sie in den Nutzungsbedingungen.

Eigenschaften

Artikel-ID: 172983 - Geändert am: Mittwoch, 18. Mai 2011 - Version: 3.0
Die Informationen in diesem Artikel beziehen sich auf:
  • Windows Server 2008 Standard
  • Windows Server 2008 Enterprise
  • Windows Server 2008 Datacenter
  • Windows Server 2008 for Itanium-Based Systems
  • Microsoft Windows Server 2003, Datacenter Edition (32-bit x86)
  • Microsoft Windows Server 2003, Enterprise Edition (32-bit x86)
  • Microsoft Windows Server 2003, Standard Edition (32-bit x86)
  • Microsoft Windows XP Professional
  • Microsoft Windows XP Home Edition
  • Microsoft Windows XP Tablet PC Edition
  • Microsoft Windows XP Media Center Edition 2005 Update Rollup 2
  • Microsoft Windows 2000 Advanced Server
  • Microsoft Windows 2000 Professional Edition
  • Microsoft Windows 2000 Server
  • Windows Vista Business
  • Windows Vista Business 64-bit edition
  • Windows Vista Enterprise
  • Windows Vista Enterprise 64-bit edition
  • Windows Vista Home Basic
  • Windows Vista Home Basic 64-bit edition
  • Windows Vista Home Premium
  • Windows Vista Home Premium 64-bit edition
  • Windows Vista Ultimate
  • Windows Server 2008 R2 Datacenter
  • Windows Server 2008 R2 Enterprise
  • Windows Server 2008 R2 Standard
  • Windows Web Server 2008 R2
  • Windows 7 Enterprise
  • Windows 7 Home Basic
  • Windows 7 Home Premium
  • Windows 7 Professional
  • Windows 7 Ultimate
Keywords: 
kbinfo kbnetwork KB172983
Microsoft stellt Ihnen die in der Knowledge Base angebotenen Artikel und Informationen als Service-Leistung zur Verfügung. Microsoft übernimmt keinerlei Gewährleistung dafür, dass die angebotenen Artikel und Informationen auch in Ihrer Einsatzumgebung die erwünschten Ergebnisse erzielen. Die Entscheidung darüber, ob und in welcher Form Sie die angebotenen Artikel und Informationen nutzen, liegt daher allein bei Ihnen. Mit Ausnahme der gesetzlichen Haftung für Vorsatz ist jede Haftung von Microsoft im Zusammenhang mit Ihrer Nutzung dieser Artikel oder Informationen ausgeschlossen.

Ihr Feedback an uns

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com