1. Pourquoi la négociation à trois voies TCP nécessite-t-elle trois fois ? Rien de plus que trois ?
Le processus est le suivant :
Expliquons d’abord la signification de chacun des signes ci-dessus.
Séquence du numéro de séquence : 4 octets, utilisé pour marquer l'ordre des segments de données. TCP code tous les octets de données envoyés dans la connexion avec un numéro de série. Le numéro du premier octet est généré localement de manière aléatoire ; numérotez les octets. Après avoir ajouté le numéro de séquence, à chaque segment de message est attribué un numéro de séquence, le numéro de séquence seq étant le numéro de données du premier octet de ce segment de message.
Accusé de réception du numéro de confirmation : occupe 4 octets, dans l'attente de recevoir le numéro de séquence du premier octet de données du prochain segment de message de l'autre partie ; le numéro de séquence indique le numéro du premier octet de données transporté dans le segment de message ; et le numéro de confirmation fait référence to est le numéro du prochain octet qui devrait être reçu ; par conséquent, le numéro + 1 du dernier octet du segment de message actuel est le numéro de confirmation.
Confirmation ACK : occupe 1 bit. Le champ du numéro de confirmation n'est valide que lorsque ACK=1. Lorsque ACK=0, le numéro de confirmation n'est pas valide
Synchronisation SYN : utilisé pour synchroniser le numéro de séquence lorsque la connexion est établie. Lorsque SYN=1 et ACK=0, cela signifie : Il s'agit d'un segment de demande de connexion. Si la connexion est convenue, SYN=1 et ACK=1 sont définis dans le segment du message de réponse. Par conséquent, SYN=1 indique qu'il s'agit d'une demande de connexion ou d'un message d'acceptation de connexion. L'indicateur SYN est défini sur 1 uniquement lorsqu'une connexion TCP est établie. Une fois la négociation terminée, l'indicateur SYN est défini sur 0.
Terminer FIN : utilisé pour libérer une connexion. FIN=1 signifie : les données de l'expéditeur de ce segment ont été envoyées et la connexion de transport doit être libérée.
Les mots majuscules ACK, SYN et FIN représentent des bits d'indicateur et leurs valeurs sont 1 ou 0 ; les mots minuscules ack et seq représentent des numéros de série.
Poignée de main à trois pour éviter les connexions historiques
Lorsque le client envoie continuellement plusieurs messages SYN pour établir une connexion et que le réseau est ensuite encombré, le client peut recevoir des accusés de réception incorrects.
Le processus spécifique est le suivant :
Le client a d'abord envoyé le message SYN (seq = 90), mais celui-ci a été bloqué par le réseau et le serveur ne l'a pas reçu. Le client a ensuite renvoyé le message SYN (seq = 100). Attention à ne pas retransmettre le SYN. Le Le numéro de série du SYN transmis est le même.
Si l'ancien message SYN arrive au serveur avant le dernier message SYN, alors le serveur renverra un message SYN + ACK au client. Le numéro de confirmation de ce message est 91 (90+1).
Une fois que le client l'a reçu, le numéro de confirmation qu'il s'attend à recevoir doit être 100+1 au lieu de 90+1, il renverra donc le message RST.
Une fois que le serveur a reçu le message RST, il mettra fin à la connexion. Une fois le dernier SYN arrivé sur le serveur, le client et le serveur peuvent normalement terminer la négociation à trois.
L'ancien message SYN mentionné ci-dessus est appelé connexion historique.La principale raison pour laquelle TCP utilise une négociation à trois pour établir une connexion est d'empêcher la connexion historique d'initialiser la connexion.
En termes simples, la principale raison de la prise de contact à trois est d'éviter toute confusion due aux anciennes initialisations de connexion répétées.
2. S'il s'agit d'une connexion bidirectionnelle, la connexion historique ne peut pas être bloquée, alors pourquoi la négociation bidirectionnelle TCP ne peut-elle pas empêcher la connexion historique ?
Parce que dans le cas de deux poignées de main, l'initiateur passif n'a pas d'état intermédiaire pour que l'initiateur actif empêche les connexions historiques, de sorte que l'initiateur passif peut établir une connexion historique, entraînant un gaspillage de ressources.
Dans le cas de deux poignées de main, l'initiateur passif entre dans l'état ESTABLISHED après avoir reçu le message SYN, ce qui signifie qu'il peut envoyer des données à l'autre partie à ce moment-là, mais l'initiateur actif n'est pas encore entré dans l'état ESTABLISHED. time Pour les connexions historiques, l'initiateur actif détermine qu'il s'agit d'une connexion historique, puis renvoie un message RST pour déconnecter la connexion. L'initiateur passif entre dans l'état ESTABLISHED lors de la première prise de contact, afin de pouvoir envoyer des données. Mais ce n'est pas le cas. Je ne sais pas qu'il s'agit d'une connexion historique, il ne se déconnectera qu'après avoir reçu le message RST.
La poignée de main bidirectionnelle ne parvient pas à bloquer les connexions historiques
Dans le scénario ci-dessus, l'initiateur passif n'a pas bloqué la connexion historique avant d'envoyer des données à l'initiateur actif, ce qui a amené l'initiateur passif à établir une connexion historique et à envoyer des données en vain, ce qui a fait perdre du temps à l'initiateur passif.
Par conséquent, pour résoudre ce phénomène, il est préférable de bloquer les connexions historiques avant que l'initiateur passif n'envoie de données, c'est-à-dire avant d'établir une connexion, afin de ne pas gaspiller de ressources. Pour réaliser cette fonction, une poignée de main à trois est nécessaire.
Lorsque le client est dans l'état SYN_SENT et reçoit un message syn+ack avec un numéro de confirmation incorrect, il renvoie un message RST.
3. Dans la négociation à trois voies TCP, que se passera-t-il si le numéro de confirmation d'accusé de réception reçu par le client lors de la deuxième négociation n'est pas celui attendu ? Doit-il être rejeté directement ou renvoyer le message RST ?
Renvoie le message RST.
4. Dans quelles circonstances un accusé de réception incorrect (accusé de réception lors de la deuxième poignée de main) sera-t-il reçu ?
Lorsque le client initie plusieurs messages SYN et que le réseau est encombré, les anciens messages SYN arrivent au serveur plus tôt que les nouveaux messages SYN. À ce moment, le serveur répondra en fonction des anciens messages SYN reçus. Message +ack et le numéro de confirmation de ce message n'est pas celui que le client s'attend à recevoir, le client répondra donc avec un message RST.
5. Faites signe quatre fois
Le client envoie un paquet FIN pour demander au serveur s'il peut être déconnecté. Le client entre dans l'état FIN_WAIT_1. Le serveur
reçoit le paquet envoyé par le client et renvoie un paquet ACK. Le serveur entre dans l'état CLOSE_WAIT.
Lorsque le serveur est prêt pour se déconnecter, il envoie un paquet FIN au client. À la fin, le serveur entre dans l'état LAST_ACK.
Le client renvoie un paquet ACK après avoir reçu le paquet envoyé par le serveur. Le client entre dans l'état TIME_WAIT. Le serveur entre dans l'état CLOSED après réception du package. Etat du client
: FIN_WAIT_1 FIN_WAIT_2 TIME_WAIT
Etat du serveur : CLOSE_WAIT LAST_ACKC LOSED
6. Pourquoi A doit-il attendre 2MSL (durée de vie maximale du message) dans l'état TIME-WAIT ?
Tout d'abord, assurez-vous que le dernier segment ACK envoyé par A peut atteindre B et assurez-vous que A et B entrent normalement dans l'état FERMÉ.
Ce segment de message ACK peut être perdu, de sorte que B dans l'état LAST-ACK ne peut pas recevoir la confirmation du segment de message FIN+ACK envoyé. B expire et retransmet le segment de message FIN+ACK, et A peut recevoir le segment de message FIN+ACK. segment de message dans 2MSL. Après avoir reçu le segment de message FIN+ACK retransmis, A retransmet la confirmation et redémarre le compteur 2MSL. Après le temps 2MSL, A et B entrent dans l'état CLOSE. Si A reçoit le message FIN+ACK de B dans le TIME-WAIT Après le segment, le segment d'accusé de réception est envoyé à B sans confirmer si B l'a reçu et entre immédiatement dans l'état FERMÉ. Si B ne reçoit pas normalement le segment d'accusé de réception de A, B ne peut pas entrer normalement dans l'état FERMÉ.
Deuxièmement, empêchez l'apparition d'un « segment de demande de connexion invalide » dans cette connexion.
Après que A ait envoyé le dernier segment de message ACK et passé par 2MSL, tous les segments de message générés pendant la durée de cette connexion disparaîtront, garantissant qu'aucun segment de message de demande restant de l'ancienne connexion n'apparaîtra dans la prochaine nouvelle connexion.