Bonjour, tout le monde ~ Je suis votre vieil ami : Protégez Xiao Zhou ღ
Ce numéro vous apporte l'un des mécanismes du protocole de contrôle de transmission TCP en programmation réseau pour assurer une transmission de données fiable - la gestion des connexions Pour ouvrir une connexion, comment effectuer des opérations de "handshake" et de "waving", cet article l'analysera pour vous ~~
Ce problème est inclus dans la colonne du blogueur : JavaEE_Protect Xiao Zhouღ's Blog-CSDN Blog
Convient aux débutants en programmation, les amis intéressés peuvent s'abonner pour voir d'autres "JavaEE Basics".
Restez à l'écoute pour plus de faits saillants : Protégez Xiaozhou ღ *★,°*:.☆(￣▽￣)/$:*.°★*'
1. Bilan de la période précédente
1.1 Structure des messages TCP
Efforcez-vous de faire une analyse simple du message TCP :
Numéro de série et numéro de confirmation : chacun occupe 32 bits binaires pour une transmission fiable des données. Chaque octet du flux d'octets transmis sera numéroté dans l'ordre pour garantir que l'ordre de transmission des données est le même que l'ordre de réception. Le numéro de séquence représente le numéro de séquence du paquet de données actuellement envoyé, et le numéro de confirmation représente le numéro de séquence du prochain paquet de données que l'on s'attend à recevoir. L'importance du numéro de série et du numéro de confirmation est de s'assurer que l'ordre de transmission des données est le même que l'ordre de réception.
Bits d'indicateur : y compris ACK, SYN, FIN, RST, PSH et URG occupant chacun un bit binaire.
Il est défini sur 0 par défaut, s'il est défini sur 1, cela signifie vrai.
ACK : utilisé pour confirmer la réception des paquets de données ;
SYN : détermine si les parties de communication ont établi une connexion ;
FIN : utilisé pour fermer la connexion ; 0
RST : utilisé pour réinitialiser la connexion ;
PSH : utilisé pour inviter le récepteur à transmettre immédiatement les données à l'application au lieu d'entrer dans le tampon de réception ;
URG : Utilisé pour indiquer qu'il y a des données urgentes dans le paquet TCP.
1.2 Accusé de réception et retransmission de temporisation
Réponse d'accusé de réception :
Lorsque le destinataire reçoit les données envoyées par l'expéditeur, il donnera à l'expéditeur un retour de champ avec un en-tête TCP, où ACK = 1 (un bit binaire), indiquant que j'ai reçu les données.
Pour le mécanisme ci-dessus, il existe trois situations :
1. Les données sont directement perdues pendant le processus de transmission et le récepteur ne peut pas donner de retour si les données ne sont pas reçues.
2. Après avoir reçu les données, le récepteur donne un retour à l'expéditeur, mais le message de retour est perdu pendant la transmission.
3. Lorsque l'expéditeur ne reçoit pas de retour pendant un certain temps, il déclenchera une retransmission de temporisation, puis les données retransmises seront perdues
Délai de retransmission :
Si l'expéditeur n'attend pas l'accusé de réception du destinataire dans un certain laps de temps, il retransmettra le " ."donnéespaquet de
Comment rétablir la connexion et mettre fin à la communication réseau voici le sujet de cet article ~~
Pour un contenu spécifique, vous pouvez lire le blog précédent du blogueur : [Protocole TCP] Format de message, mécanisme de transmission fiable des données (1)_Protecting Xiao Zhouღ’s Blog-CSDN Blog
2. Gestion des connexions
Protocole de couche de transport TCP, fonction de protocole : pour assurer la fiabilité de la transmission de données entre les deux parties en communication.
Le facteur important de garantie est le mécanisme de réponse d'accusé de réception et de retransmission du délai d'attente. Le récepteur donnera un retour à l'expéditeur après avoir reçu les données. Ce retour est un champ avec un en-tête TCP fixe. L'en-tête TCP contient des informations de bit d'indicateur, et chaque indicateur bit uniquement Occupe un bit binaire, donc selon le bit drapeau de l'en-tête TCP, on peut juger d'un état du " paquet TCP " courant
La connexion entre les deux parties dans la communication du protocole TCP est établie par une poignée de main à trois voies.
2.1 Poignée de main à trois
La poignée de main (handshake) fait référence à la communication entre les deux parties, l'interaction réseau, entre l'expéditeur et le destinataire, à travers trois interactions, une relation de connexion est établie. La relation de connexion fait référence à : les deux parties dans la communication ont enregistré les informations de l'autre ~
Pourquoi mentionner le client et le serveur, car dans notre communication quotidienne, les deux parties à la communication n'établissent pas directement une connexion, mais établissent d'abord une connexion avec le serveur, et les informations sont "transférées" via le serveur.
La "volonté" d'établir une connexion doit être initiée par le client
Le client envoie un paquet SYN au serveur , indiquant une demande d'établissement de connexion.
Après avoir reçu le paquet SYN , le serveur répond par un paquet SYN+ACK , indiquant qu'il accepte d'établir une connexion.
Une fois que le client a reçu le paquet SYN+ACK , il répond avec un paquet ACK , indiquant que la connexion est établie avec succès.
SYN : (un bit binaire) défini sur 1 signifie qu'une partie souhaite demander une connexion à l'autre partie. Indique que le datagramme TCP actuel est un message synchrone.
ACK : un bit binaire), le réglage 1 signifie donner un retour et confirmer la réception des données. Indique que le datagramme TCP actuel est un message de réponse.
Schéma de principe d'établissement d'une connexion entre les deux parties communicantes :
Le blogueur l'a utilisé ici et a simulé la scène d'un appel pour "établir une connexion". Peut-être qu'il y a un certain laps de temps avant un tel appel, mais le but principal est de vérifier si les capacités d'envoi et de réception des deux les parties communicantes sont normales La normalité du processus d'interaction est confirmée, ce qui est également la base d'une transmission de données fiable ultérieure.
Pourquoi y a-t-il une poignée de main à trois, peut-elle être faite deux fois, peut-elle être faite quatre fois ?
Tout d'abord, deux poignées de main ne peuvent que confirmer que la fonction d'envoi et de réception d'une partie est normale.
Pour plusieurs poignées de main, diviser l'AYN et l'ACK au milieu et les envoyer séparément peut également atteindre l'objectif de vérification, mais c'est complètement inutile, car un segment de données TCP doit être encapsulé et divisé couche par couche (TCP / IP Five- modèle de communication de couche), envoi en deux fois, l'efficacité est très faible.
2.3. Quatre vagues
Agiter quatre fois signifie que les deux parties en communication sont déconnectées, ce qui est aussi un joli nom.
La "volonté" de se déconnecter peut être initiée à la fois par le client et par le serveur.
Le client envoie un paquet FIN au serveur , indiquant qu'il veut se déconnecter.
Après avoir reçu le paquet FIN, le serveur répond par un paquet ACK , indiquant que la demande de déconnexion a été reçue.
Le serveur envoie alors un paquet FIN , acceptant de se déconnecter.
Une fois que le client a reçu le paquet FIN, il répond par un paquet ACK , indiquant que la demande de déconnexion a été reçue.
FIN : (un bit binaire) défini sur 1 signifie qu'une partie souhaite demander à l'autre partie de se déconnecter . Indique que le datagramme TCP actuel est un message de fin.
Schéma de principe de déconnexion entre les deux parties communicantes :
Grâce au processus ci-dessus, ce qui se déconnecte, c'est que les deux parties communicantes envoient chacune un FIN (message de fin) à l'autre partie, puis envoient chacune un ACK (message de réponse) à celle-ci.
Après avoir appris la "prise de contact à trois", nous constaterons qu'il y a une opération SYN + ACK, demande de connexion + réponse de confirmation, et les deux bits d'indicateur peuvent être renvoyés dans le même datagramme TCP, il y a donc trois
Mais en cas de déconnexion, FIN et ACK sont transmis séparément, la déconnexion nécessite donc quatre .
La raison en est que SYN + ACK sont tous deux complétés par le noyau du système d'exploitation et peuvent être déclenchés en même temps.
TCP appartient au protocole de la couche transport. En tant que développeur de programmes, l'accent est mis sur le développement de la couche application, mais ils choisissent d'utiliser l'interface Socket (API) basée sur le protocole TCP pour le développement. Couche transport-couche réseau-couche liaison de données-couche physique, ces 4 couches ont en fait été encapsulées par le système d'exploitation, et elles sont appelées couche par couche, donc la couche application utilise directement l'interface fournie par le protocole de la couche transport, donc là n'est pas nécessaire de prêter trop d'attention aux autres implémentations internes.
Agiter quatre fois :
ACK et FIN sont déclenchés par différentes machines, et ACK est complété par le noyau du système, donc après avoir reçu la demande de déconnexion FIN, l'expéditeur recevra une réponse de confirmation la première fois.
FIN - La déconnexion est contrôlée par le code d'application. En programmation réseau Java, FIN est déclenché lorsque la méthode close() dans Socket (interface) est appelée - envoie un datagramme TCP et FIN est défini sur 1 le message de fin.
Par exemple : le serveur constate que le client a envoyé un message de fin, il appelle donc la méthode close() par lui-même, déclenchant ainsi le deuxième message de fin. Bien sûr, ce qu'il faut utiliser pour appeler la méthode close() dépend de la façon dont le programme est écrit.
À propos de la situation où le programme n'appelle pas close() pour déclencher le message de fin
Par exemple : dans le programme côté client, aucun close() n'est écrit. Dans ce cas, le serveur envoie une requête de fin FIN au client — le serveur ne peut pas recevoir le message de fin renvoyé par le service client. . Est-il impossible de déconnecter la connexion, non non non
Si le programme du client se termine - le processus se termine - l'application se termine - comme qq se termine en cours d'exécution, il déclenchera automatiquement "close()", et la ressource se terminera avec la fin du processus, et le système contrôlera la récupération, cela déclenchera donc les arts du rapport de fin FIN. À ce stade, l'application qq du client est en cours d'exécution, mais la connexion TCP est toujours là (maintenue par le noyau du système d'exploitation), jusqu'à ce qu'elle finisse d'agiter quatre fois avec le serveur qq ~ et vice versa.
Il convient de noter que le protocole TCP est en duplex intégral, c'est-à-dire que le client et le serveur peuvent envoyer et recevoir des données en même temps. Par conséquent, lors de la déconnexion, vous devez faire signe quatre fois, et le noyau du système d'exploitation maintient le processus de vague pour s'assurer que les deux parties se sont déconnectées.
Eh bien, ici, le blogueur de la "prise de contact à trois voies et de la vague à quatre voies" de la gestion des connexions [protocole TCP] dans la programmation réseau a terminé le partage, j'espère que cela pourra être utile à tout le monde, et j'accueille les critiques et les corrections s'il y en a quelque chose de mal.
Merci à tous ceux qui ont lu cet article, et d'autres événements passionnants sont à venir : Protect Xiaozhou ღ *★,°*:.☆(￣▽￣)/$:*.°★*
Quand je t'ai rencontré, toutes les étoiles sont tombées sur ma tête 
...