Explication de l’établissement d’une liaison triple via TCP/IP
Cet article décrit le processus de négociation tripdirectionnel TCP (Transmission Control Protocol) entre un client et un serveur lors du démarrage ou de la fin d’une connexion TCP.
S’applique à : Windows Server 2012 R2
Numéro de la base de connaissances d’origine : 172983
Résumé
Cet article est destiné aux publics qui connaissent le protocole TCP/IP (Transmission Control Protocol/Internet Protocol). Il décrit le processus d’établissement d’une liaison TCP triple entre un client et un serveur lors du démarrage ou de la fin d’une connexion TCP.
Plus d’informations
Le niveau TCP du protocole de transport TCP/IP est orienté connexion. Orienté connexion signifie que, avant qu’une donnée puisse être transmise, une connexion fiable doit être obtenue et reconnue. Les transmissions de données au niveau TCP, l’établissement de la connexion et l’arrêt de connexion conservent des paramètres de contrôle spécifiques qui régissent l’ensemble du processus. Les bits de contrôle sont répertoriés comme suit :
URG : Champ de pointeur urgent significatif
ACK : Champ d’accusé de réception significatif
PSH : Fonction Push
RST : Réinitialiser la connexion
SYN : Synchroniser les numéros de séquence
FIN : Plus de données de l’expéditeur
Il existe deux scénarios dans lesquels une négociation tripdirectionnelle aura lieu :
Établissement d’une connexion (ouverture active)
Fin d’une connexion (fermeture active)
L’exemple d’informations suivant a été obtenu à partir d’une capture du moniteur réseau. Le Moniteur réseau est un analyseur de protocole qui peut être obtenu à partir de Microsoft Systems Management Server.
Établissement d’une connexion
La séquence suivante montre le processus d’établissement d’une connexion TCP :
Cadre 1 :
Comme vous le voyez dans la première image, le client, NTW3, envoie un segment SYN (TCP ....S.). Il s’agit d’une demande adressée au serveur pour synchroniser les numéros de séquence. Il spécifie son numéro de séquence initial (ISN). Le isn est incrémenté de 1 (8221821+1=8221822) et est envoyé au serveur. Pour démarrer une connexion, le client et le serveur doivent synchroniser les numéros séquentiels de l’autre. Il existe également une option pour la taille maximale du segment (MSS) à définir, qui est définie par la longueur (len : 4). Cette option communique le MSS que l’expéditeur souhaite recevoir. Le champ Accusé de réception (ack : 0) est défini sur zéro, car il s’agit de la première partie de la négociation triple.
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 .........
Cadre 2 :
Comme vous le voyez dans la deuxième image, le serveur, BDC3, envoie un segment ACK et SYN (TCP .A..S.). Dans ce segment, le serveur accuse réception de la demande de synchronisation du client. Pendant ce temps, le serveur envoie également sa demande au client pour la synchronisation de ses numéros de séquence. Il y a une différence majeure dans ce segment. Le serveur transmet un numéro d’accusé de réception (8221823) au client. L’accusé de réception est simplement la preuve pour le client que l’ACK est spécifique au SYN initié par le client. Le processus d’accusé de réception de la demande du client permet au serveur d’incrémenter le numéro de séquence du client d’un et de l’utiliser comme numéro d’accusé de réception.
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.-......
Cadre 3 :
Comme vous le voyez dans la troisième image, le client envoie un segment ACK (TCP .A....). Dans ce segment, le client accuse réception de la demande de synchronisation du serveur. Le client utilise le même algorithme que celui implémenté par le serveur pour fournir un numéro d’accusé de réception. L’accusé de réception du client de la demande de synchronisation du serveur termine le processus d’établissement d’une connexion fiable et de l’établissement d’une liaison tridirectionnelle.
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....
Mettre fin à une connexion
Bien que l’établissement d’une liaison tridirectionnel ne nécessite que trois paquets à transmettre sur notre média en réseau, l’arrêt de cette connexion fiable doit transmettre quatre paquets. Étant donné qu’une connexion TCP est en duplex intégral (les données peuvent circuler dans chaque direction indépendamment de l’autre), chaque direction doit être arrêtée indépendamment.
Image 4 :
Dans cette session de frames, vous voyez le client envoyer une fin qui est accompagnée d’un ACK (TCP .A...F). Ce segment a deux fonctions de base. Tout d’abord, lorsque le paramètre FIN est défini, il informe le serveur qu’il n’a plus de données à envoyer. Deuxièmement, l’ACK est essentiel pour identifier la connexion spécifique qu’il a établie.
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..
Image 5 :
Dans ce cadre, vous ne voyez rien de spécial, à l’exception du serveur qui accuse réception de la fin transmise par le client.
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...........
Cadre 6 :
Après avoir reçu la fin de l’ordinateur client, le serveur est ACK. Même si TCP a établi des connexions entre les deux ordinateurs, les connexions restent indépendantes l’une de l’autre. Par conséquent, le serveur doit également transmettre une fin (TCP .A...F) au client.
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...........
Image 7 :
Le client répond au même format que le serveur, en ackisant la fin du serveur et en incrémentant le numéro séquentiel de 1.
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..
Le client ACKing la notification FIN du serveur identifie une fermeture normale d’une connexion TCP.
References
Obtenez RFC 793.
Les RFC peuvent être obtenues via Internet comme suit :
Des copies papier de tous les RFC sont disponibles à partir de la carte réseau, individuellement ou par abonnement (pour plus d’informations, contactez NIC@NIC.DDN.MIL). Les copies en ligne sont disponibles via FTP ou Kermit à partir de NIC.DDN.MIL en tant que rfc/rfc###.txt ou rfc/rfc####.PS (#### est le nombre RFC sans zéros non significatifs).
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour