Annuaire d'articles
1. Poignée de main à trois
SYN : il s'agit d'un message de demande de connexion (prise de contact à trois) et l'en-tête TCP est envoyé
L’essence de la poignée de main à trois est d’établir un lien. Qu’est-ce qu’un lien ?
Il y aura plusieurs liens établis dans le système d'exploitation. Le système d'exploitation doit gérer ces liens établis. L'
essence de la gestion est d'abord de décrire
la structure de données maintenue dans l'organisation. Afin de gérer la maintenance des connexions dans le système d'exploitation,
le La structure struct tcp_link est d'abord utilisée.body, qui contient divers champs liés,
puis utilise des listes chaînées pour les organiser
Il y a un coût pour créer et maintenir un lien
1. Consommation d'espace mémoire (si vous souhaitez créer un lien, vous devez créer un objet lien, vous avez donc besoin d'un objet lien nouveau/nalloc)
2. Consommation des ressources CPU ( minuterie de maintenance pour assurer le redémarrage de la transmission après expiration du délai, etc.)
processus général
Tant que le client envoie SYN, l'état du client passe à SYN_SENT, appelé transmission synchrone.
Tant que le serveur reçoit SYN, l'état du serveur passe à SYN_RCVD
. Le serveur répond alors par SYN+ACK. Après la réponse,
le Le client reçoit un ACK. Et lorsque l'ACK est envoyé, la négociation à trois du client est terminée.
La prise de contact à trois côté serveur n'est terminée que lorsque le côté serveur reçoit l'ACK.
Problème de perte de message lors d'une négociation à trois
Si le premier message est perdu, c'est-à-dire que le SYN est perdu,
le serveur ne sera en aucun cas affecté car il n'a jamais reçu de message.
Si le deuxième message est perdu, c'est-à-dire SYN+ACK,
le processus de négociation à trois entre les deux parties échouera car la connexion entre les deux parties n'a pas été établie.
Si le troisième message est perdu, c'est-à-dire que l'ACK est perdu.
Pour le client, il lui suffit d'envoyer l'ACK et la négociation à trois est considérée comme terminée.
Pour le serveur, la négociation à trois est considérée comme terminée uniquement lorsque le message ACK est reçu.
Par conséquent, lorsque le message ACK est perdu, le client pense qu'il est terminé, mais le serveur pense qu'il n'est pas terminé.À
ce moment-là, le client pense qu'il est établi, il enverra donc un message directement au serveur.Si
le serveur n'est pas établi, le serveur se reconnecte immédiatement . Set, en réponse à RST,
le client fermera la connexion puis rétablira la connexion.
Pourquoi la poignée de main bidirectionnelle n'est-elle pas autorisée ?
La poignée de main bidirectionnelle n'est pas possible car il est très facile d'être attaqué.
Il est très facile pour une machine de vous envoyer en permanence une quantité massive de SYN. Une fois que le serveur a reçu le SYN, il enverra directement un ACK, que le client l'ait reçu ou non. Le serveur a déjà considéré que l'établissement est terminé
. Il y
a un coût pour maintenir la connexion. Si la machine envoie un grand nombre de SYN
au serveur pour une maintenance immédiate, la mémoire sera consommé immédiatement. Une grande quantité de mémoire sera consommée et le serveur pourrait ne pas être en mesure de fournir des services aux utilisateurs normaux.
Pourquoi trois poignées de main ?
1. Il n'y a pas de failles de conception évidentes : dès qu'une exception se produit lors de l'établissement d'une connexion, le coût est greffé sur le client, tandis que le coût côté serveur est inférieur.
2. Vérifiez la fluidité du canal de communication entre les deux parties.
La poignée de main à trois voies est le coût minimum pour vérifier la fluidité du canal de communication full-duplex.
Lors de la première poignée de main, il peut être prouvé que le client peut envoyer des messages.
Lors de la deuxième poignée de main, il peut être prouvé que le client peut recevoir des messages.
Lors de la première poignée de main, cela prouve que le serveur peut recevoir le message.
Lors de la troisième poignée de main, cela prouve que le serveur peut envoyer le message
(seulement lorsque le client reçoit le message et répond, peut-il prouver que le serveur a envoyé le message)
2. Faites signe quatre fois
Lors de la déconnexion, le client peut vouloir se déconnecter, mais le serveur peut ne pas
vouloir se déconnecter.
Pour déconnecter, il faut obtenir le consentement des deux parties, et non d'un seul, car le statut des deux parties est égal.
On agite quatre fois pour déconnecter les deux parties au moindre coût.
processus général
FIN : Il s’agit d’un message de demande de déconnexion
La première vague :
après l'envoi du message FIN, l'état du client est FIN_WAIT 1.
Le serveur reçoit le message FIN, et l'état du serveur est CLOSE_WAIT
La deuxième vague :
lorsque le client reçoit le message ACK en réponse du serveur, l'état du client est FIN_WAIT 2
Troisième vague :
si le serveur souhaite également se déconnecter, il envoie un message FIN au client, puis le serveur entre dans l' état LAST_ACK .
La quatrième vague :
après avoir reçu le message FIN du serveur, le client enverra une réponse ACK au serveur.
Puisque le client s'arrête activement, le client entre alors dans l'état TIME_WAIT , et après que le serveur ait reçu la réponse ACK du client , le serveur passe à l' état CLOSE
Le client entre dans l'état TIME_WAIT et doit attendre 2MSL avant d'entrer dans l'état CLOSE .
Après l'envoi du dernier message ACK, le client considère que quatre vagues ont été complétées. Lorsque
le serveur reçoit le message ACK, le serveur considère que quatre vagues ont été complétées.
La partie qui se déconnecte activement enverra définitivement le dernier message ACK.
Pourquoi attendre 2MSL
Le protocole TCP stipule que la partie qui ferme activement la connexion doit entrer dans l'état final TIME_WAIT et attendre 2 MSL.
MSL indique la durée maximale pendant laquelle un message existe sur le réseau.
TCP stipule qu'il doit généralement attendre 2 fois MSL.
Le maximum le temps de survie d'un message envoyé est de 1 MSL, l'autre partie doit répondre dans le futur et le temps de réponse est également un MSL
Attendez 2MSL
pour vous assurer que tous les segments de message non reçus ou en retard dans les deux sens de transmission ont disparu.
Si vous n'attendez pas 2MSL
, la connexion vient peut-être d'être déconnectée et il y aura des messages résiduels sur le réseau avant la déconnexion de la connexion. Une fois la connexion déconnectée, le serveur sera reconnecté immédiatement. Lorsque la connexion est établie
, Il y aura des messages résiduels historiques. Le fichier existe, cela affectera les données de réception normales correspondant au récepteur.
Par conséquent, essayez de vous assurer que les messages historiques se dissipent et n’affectent pas la prochaine communication normale.
3. Contrôle du flux
Lorsque le client et le serveur communiquent, ils ont leurs propres tampons d'envoi et de réception.
Lorsque le client envoie des données, il envoie les données dans le tampon d'envoi du client au tampon de réception du serveur.
Lorsque le serveur envoie des données, il envoie les données dans le tampon de réception du serveur. tampon d’envoi. Les données de la zone sont envoyées au tampon de réception du client.
Dans la réponse de confirmation, la taille de la fenêtre de 16 bits peut être transportée pour indiquer la taille de l'espace restant dans le tampon de réception, c'est-à-dire la capacité de transport. En tant que destinataire, connaître la capacité de transport
de la réception des données peut permettre à l'expéditeur de envoyer des données plus lentement lors de l'envoi de données. , ce qui entraîne la possibilité de recevoir
cette opération est appelée contrôle de flux
Si l'extrémité réceptrice constate que sa mémoire tampon est presque pleine, elle définira la taille de la fenêtre sur une valeur plus petite et en informera l'extrémité émettrice. Si l'extrémité
émettrice reçoit cette fenêtre, elle ralentira sa vitesse d'envoi.
Si le tampon à l'extrémité réceptrice est plein, la fenêtre sera mise à 0. À ce moment, l'expéditeur n'enverra plus de données, mais il doit envoyer régulièrement un segment de données de détection de fenêtre afin que l'extrémité réceptrice puisse le dire à l'expéditeur. la taille de la fenêtre.
4. Fenêtre coulissante
consensus
Pour chaque segment de données envoyé, une réponse de confirmation ACK doit être donnée. Après avoir reçu l'ACK, le segment de données suivant est envoyé.
Cependant, l'efficacité de l'envoi et de la réception est très faible.
L'accès simultané est très efficace, mais il a également une limite supérieure sur les capacités de réception
. L'expéditeur doit envoyer simultanément en partant du principe que l'autre partie peut l'accepter.
La quantité maximale de données que l'expéditeur peut envoyer simultanément à l'autre partie est déterminée par la taille de la fenêtre de l'autre partie.
Cas général des fenêtres coulissantes
La capacité de réception du destinataire étant limitée,
la vitesse d'envoi de l'expéditeur est affectée par l'espace restant dans le tampon de réception de l'autre partie.
La fenêtre glissante fait partie du tampon d'envoi.Cette
partie des données dans la fenêtre glissante : vous n'avez pas besoin de recevoir de réponse pour le moment, vous pouvez l'envoyer directement.
En raison de l'existence de la fenêtre coulissante, le tampon d'envoi est divisé en trois parties :
le côté gauche est appelé déjà envoyé et confirmé
et peut être écrasé, c'est-à-dire les données invalides.
Le côté droit est appelé la fenêtre coulissante de la zone de données non envoyées
: elle peut être envoyée directement, mais aucune réponse n'a été reçue.
La taille de la fenêtre coulissante est liée à la capacité de réception de l'autre partie.
Comprendre les fenêtres coulissantes
Considérez le tampon d'envoi comme un tableau de type char.
Comme le type char n'occupe qu'un octet et reflète le flux d'octets,
le tableau est appelé sendbuffer.
L'essence de la fenêtre glissante est une fenêtre d'intervalle maintenue par deux indices de tableau (début et fin).Le
glissement signifie que les indices de début et de fin sont déplacés ++
Cas particulier des fenêtres coulissantes
Cas 1 - La fenêtre coulissante peut-elle coulisser uniquement vers la droite ? Puis-je balayer vers la gauche ?
Vous ne pouvez pas glisser vers la gauche car la zone de gauche contient des données qui ont été envoyées et reçues une confirmation, ce qui n'a aucun sens, vous ne pouvez
donc glisser que vers la droite.
Cas 2 – La fenêtre coulissante peut-elle devenir plus grande ou plus petite ? Peut-il devenir 0 ? Qu'est-ce que cela signifie après être passé à 0 ?
Il peut devenir plus grand/plus petit. La fenêtre glissante plus grande ou plus petite dépend de la capacité de réception de l'autre partie. La fenêtre glissante
devient plus grande, c'est-à-dire que l'indice de fin augmente.
La fenêtre glissante devient plus petite, c'est-à-dire que l'indice de fin ne ne bouge pas et l'indice de début se déplace vers la droite.
La taille de la fenêtre coulissante est donc flottante et non fixe.
La couche d'application supérieure du récepteur ne récupère jamais les données, ce qui fera que l'espace restant du tampon de réception deviendra de plus en plus petit jusqu'à ce qu'il atteigne 0. Cela amènera l'expéditeur à
envoyer de moins en moins de données jusqu'à ce qu'il atteigne 0. Autrement dit, la fenêtre glissante de 0 signifie que l'autre partie ne peut pas recevoir
le début et la fin pointant vers le même
Cas 3 : Il y a plusieurs messages dans la fenêtre coulissante qui peuvent être envoyés directement. Que se passe-t-il si le premier est perdu ?
S'il y a des messages 1000 2000 3000 4000
et si le premier message 1000 est perdu, il y a deux situations
Cas 1 : Le message est reçu, mais la réponse d'accusé de réception (ACK) est perdue.
D'après le numéro de séquence d'accusé de réception, lorsque la réponse d'accusé de réception 2001 correspondant au message 2000 est reçue, le message correspondant 1000 est connu, et le récepteur doit avoir reçu il.
Scénario 2 : Les données du premier message 1000 sont perdues
À ce stade, comme le premier message est perdu, c'est-à-dire que les données comprises entre 1001 et 2000 sont perdues, le numéro de séquence de confirmation ne peut pas renvoyer 2001 et 3001 car 2001 signifie que tous les numéros de séquence
avant 2000 ont été reçus, et 1000 n'a pas été reçu,
donc seul le numéro de séquence de confirmation 1001 peut être renvoyé, ce qui signifie que les numéros de séquence avant 1000 ont été reçus,
donc de nombreux numéros de séquence ACK en double seront reçus, et TCP reconnaîtra que le paquet a été perdu et le retransmettra. après un temps mort.
Pour prendre en charge la retransmission, les données doivent être temporairement enregistrées et enregistrées dans une fenêtre coulissante.