Explication de l’établissement d’une connexion tridirectionnelle via TCP/IP


Résumé


Cet article est destiné aux personnes qui connaissent le protocole TCP/IP (Transmission Control Protocol/Internet Protocol) et traite du processus de connexion TCP à trois directions qui intervient entre un client et un serveur lors du lancement ou de la fermeture d’une connexion TCP. Pour plus d’informations sur TCP/IP, consultez le livre blanc suivant disponible sur le serveur FTP anonyme Microsoft :
Nom de fichier : Tcpipimp2. doc emplacement : ftp://ftp.Microsoft.com/bussys/winnt/winnt-docs/Papers/ "Microsoft Windows NT 3.5/3.51/4.0 : détails de l’implémentation TCP/IP, pile et services du protocole TCP/IP, version 2,0"

Informations supplémentaires


Le niveau du protocole TCP (Transmission Control Protocol) du protocole de transport TCP/IP est orienté connexion. Le mode de connexion signifie que, avant que toutes les données puissent être transmises, une connexion fiable doit être obtenue et acceptée. Le niveau de transmission des données de 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 le processus complet. Les bits de contrôle apparaissent comme suit :
URG : le champ de pointeur urgent a reçu un accusé de réception significatif : champ d’accusé de réception important PSH : fonction de transmission de données
Il existe deux scénarios dans lesquels une connexion à trois directions aura lieu :
  • Établissement d’une connexion (une ouverture active)
  • Arrêt d’une connexion (une fermeture en cours)
Les informations d’exemple suivantes ont été obtenues à partir d’une capture du moniteur réseau. Network Monitor est un analyseur de protocoles qui peut être obtenu à partir de Microsoft Systems Management Server.

Établissement d’une connexion

La séquence suivante montre le processus d’une connexion TCP établie : Frame 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 du serveur permettant de synchroniser les numéros de séquence. Il spécifie son numéro de séquence initial (ISN), qui est incrémenté par 1, 8221821 + 1 = 8221822, et qui est envoyé au serveur. Pour initialiser une connexion, le client et le serveur doivent synchroniser les numéros de séquence de chacun d’eux. Il existe également une option permettant de définir la taille de segment maximale (MSS), définie par la longueur (Len : 4). Cette option indique la taille de segment maximale qu’il 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 connexion à trois directions.
1    2.0785 NTW3 --> BDC3 TCP ....S., len: 4, seq: 8221822-8221825, ack: 0,win: 8192, src: 1037  dst:  139 (NBT Session)  NTW3 -->  BDC3 IPTCP: ....S., len: 4, seq: 8221822-8221825, ack: 0, win: 8192, src: 1037dst:  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 Padding00000:  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...k00020:  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 : dans le second Frame, le serveur, BDC3, envoie un ACK et un SYN sur ce segment (TCP. A.. S.). Dans ce segment, le serveur accuse réception de la demande de synchronisation du client. En même temps, le serveur envoie également sa demande au client pour la synchronisation de ses numéros de séquence. Ce segment présente une différence majeure. Le serveur transmet un numéro de réception (8221823) au client. L’accusé de réception est uniquement une preuve au client que le ACK est spécifique au SYN démarré par le client. Le processus de confirmation de la demande du client permet au serveur d’incrémenter son numéro de séquence d’un client et de l’utiliser comme numéro 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  IPTCP: .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 Padding00000:  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...k00020:  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 : dans le troisième cadre, le client envoie un ACK sur ce segment (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 le serveur implémenté pour fournir un numéro d’accusé de réception. L’accusé de réception du client de la demande de synchronisation du serveur est terminé le processus d’établissement d’une connexion fiable, par conséquent le protocole de connexion à trois directions.
3   2.787 NTW3 --> BDC3  TCP .A...., len: 0, seq: 8221823-8221823, ack:1109646, win: 8760, src: 1037  dst:  139 (NBT Session)  NTW3 --> BDC3  IPTCP: .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 Padding00000:  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...k00020:  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.... 

Arrêt d’une connexion

Même si la connexion à trois directions nécessite uniquement la transmission de trois paquets sur le média en réseau, la résiliation de cette connexion fiable nécessite la transmission de quatre paquets. Dans la mesure où une connexion TCP est en duplex intégral (autrement dit, les données peuvent être acheminées dans chaque direction indépendamment de l’autre), chaque direction doit être arrêtée de manière indépendante. Image 4 : dans cette session de trames, vous pouvez voir le client envoyant une FIN accompagnée d’un ACK (TCP). A... F). Ce segment comporte deux fonctions de base. Tout d’abord, lorsque le paramètre FIN est défini, il indique au serveur qu’il n’y 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 --> BDC3IPTCP: .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.. 
Cadre 5 : dans ce cadre, vous ne verrez rien de particulier, à l’exception du serveur qui accuse réception de la FIN de la transmission du client.
5    16.0281 BDC3 --> NTW3 TCP .A...., len:    0, seq: 1109646-1109646,ack: 8221824, win:28672, src: 139  dst: 2337 (NBT Session) BDC3 -->  NTW3IPTCP: .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 Padding00000:  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 l’ailette de l’ordinateur client, le serveur est ACK. Même si le protocole TCP a établi des connexions entre les deux ordinateurs, les connexions restent indépendantes les unes des autres. 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   IPTCP: .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 Padding00000:  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 ACKingant la FIN du serveur et en incrémentant le numéro de séquence 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 IPTCP: .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 de FIN du serveur détermine une fin harmonieuse de connexion TCP.

Références


Pour plus d’informations sur ICMP :
Reportez-vous à l’article suivant de la base de connaissances Microsoft : notions de base du protocole ICMP (Internet Control Message Protocol)170292
- ou -
Obtenez le RFC 793.
Les RFC peuvent être obtenus par le biais d’Internet comme suit : des copies de papier de toutes les RFC sont disponibles par le biais de la carte réseau (ou par abonnement) (pour plus d’informations, contactez NIC@NIC. DDN.MIL). Les copies en ligne sont disponibles via FTP ou Kermit à partir de la carte réseau. DDN.MIL comme RFC/RFC # # # #. txt ou RFC/RFC # # # #. PS (# # # #) est le numéro RFC sans zéro non significatifs.