2024-07-12
한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina
Le protocole TCP présente les caractéristiques de connexion, de transmission fiable, orienté flux d'octets, duplex intégral, etc. La transmission fiable en est l'élément central.
Figure 1
La figure ci-dessus est la structure de l'en-tête TCP.
(1) Le port source et le port de destination n'ont pas besoin d'être trop introduits. Ce sont les programmes utilisés pour indiquer l'extrémité émettrice et l'extrémité réceptrice.
(2) Le numéro de séquence et le numéro de séquence de confirmation sont utilisés pour le mécanisme de réponse de confirmation dans TCP introduit plus tard.
(3) Les 4 bits dans la partie décalage des données sont en fait utilisés pour indiquer la longueur de l'en-tête TCP ici. En raison des 4 bits, le nombre maximum représenté est de 15, mais comme l'unité est de 4 octets, la longueur maximale du. L'en-tête TCP fait 60 octets.
(4) Nous savons tous que la longueur maximale des paquets de données UDP est de 64 Ko, ce qui est très limité, donc afin d'éviter cette situation, 6 bits réservés sont fournis dans l'en-tête TCP, qui peuvent être utilisés si la fonction TCP est étendue plus tard. Représenté en utilisant des bits réservés.
(5) L'identifiant anglais sur 6 octets est lié au mécanisme TCP introduit ultérieurement et ne sera pas présenté ici.
(6) La somme de contrôle a la même fonction que la somme de contrôle dans UDP et est également utilisée pour vérifier si les données ont changé pendant le processus de transmission.
(7) La fenêtre sera discutée plus tard lorsque le mécanisme sera introduit.
(8) Le pointeur d'urgence sera présenté ultérieurement.
(9) Parmi les options figurent certaines options facultatives/facultatives.
Le protocole TCP doit résoudre un problème très important : la transmission fiable. La transmission dite fiable ne signifie pas que l'expéditeur peut envoyer les données au destinataire à 100 %, mais il fera de son mieux pour faire savoir à l'expéditeur si le destinataire le sait.
Figure 2
Comme le montre la figure 2, chaque fois que vous envoyez un message à la déesse, la déesse vous renvoie un message. C'est également le cas dans TCP. Le client envoie un paquet de données. renvoie un paquet de données de réponse À ce moment, les données de réponse L'indicateur ACK du paquet de la figure 1 sera défini sur 1.
image 3
Comme le montre la figure 3, lorsque nous envoyons plusieurs messages à la déesse, parce que la déesse répond aux messages à des vitesses différentes, il est facile pour nous de nous tromper. Nous penserons que la déesse accepte d'être ma petite amie. La déesse dit de se perdre. C'est Internet. Le problème du dernier arrivé, premier servi existe objectivement en Chine. Évidemment, en envoyant plusieurs paquets de données au client et en répondant à plusieurs paquets de données de réponse, nous devons également distinguer quelle réponse correspond à quel paquet de données a été envoyé. Ce problème peut être résolu en utilisant le numéro de séquence et le numéro de séquence de confirmation de la figure 1. .
Chaque paquet de données envoyé a un numéro de séquence, mais il n'y a pas de numéro de séquence de confirmation, ou le champ du numéro de séquence de confirmation n'est pas valide. L'ACK du paquet de données qui y répond est 1. À ce moment, le champ du numéro de séquence de confirmation est valide. et le numéro de séquence du paquet de données envoyé et la réponse. Les numéros de séquence de confirmation des paquets de données correspondent, de sorte qu'il soit possible de distinguer qui a répondu à qui, et le problème du dernier arrivé, premier servi mentionné ci-dessus dans le réseau peut être résolu. .
Le numéro de séquence du paquet de données TCP réel est numéroté en fonction des octets. Chaque octet se verra attribuer un numéro de séquence. La valeur du numéro de séquence dans l'en-tête TCP est le numéro du premier octet de la charge utile, par exemple, le numéro. du premier octet de la partie charge utile. Un numéro d'octet est 1 et la longueur de la charge utile est de 1 000 octets, alors le numéro de séquence d'accusé de réception dans l'en-tête du paquet de données de réponse est 1 001. En effet, le numéro de séquence d'accusé de réception du paquet de données est 1 000. Le paquet de données de réponse correspondant au paquet de données est défini sur Le numéro du dernier octet de la charge utile est augmenté de 1. En fait, cela est plus facile à comprendre. Renvoyer 1001 signifie que la charge utile de 1000 octets envoyée a été reçue et que le paquet de données de réponse correspondant au paquet de données est défini sur Le numéro du dernier octet de la charge utile est augmenté de 1. En fait, cela est plus facile à comprendre. les données après 1001 sont demandées, comme le montre la figure 4.
Figure 4
Pour les paquets de données ultérieurs envoyés, le numéro de séquence est incrémenté, mais il convient de noter que même s'il est incrémenté, le numéro de séquence ne commence pas à 0 ou 1.
Une transmission fiable peut être obtenue principalement en s'appuyant sur le mécanisme de « réponse de confirmation ». Il peut indiquer à l'expéditeur, via le message de réponse, si tout se passe bien et si une perte de paquets se produit. Que faut-il faire en cas de perte de paquets (les données sont perdues pendant le processus de transmission et ne peuvent pas atteindre l'extrémité opposée, un événement aléatoire objectif) ?
La retransmission hors délai est utilisée pour traiter les problèmes de perte de paquets sur le réseau.
Il y a principalement deux situations ici :
(1) Les paquets de données transmis sont perdus
À ce stade, B n'enverra pas de paquet de réponse s'il ne reçoit pas le paquet de données de A. Lorsque l'événement attendu par A dépasse un certain seuil, il déterminera qu'un problème de perte de paquet s'est produit et retransmettra le paquet de données.
(2) Le paquet de données de réponse est perdu
Lorsque A ne reçoit pas le paquet de données de réponse, il retransmet quand même un paquet de données, mais à ce moment-là, B a reçu un paquet de données. Avec la retransmission du paquet de données, il recevra deux paquets de données identiques. , en particulier pour des questions telles que les transferts, où des transferts répétés se produiront.
Pour les problèmes ci-dessus, le récepteur TCP dédupliquera les données reçues en fonction du numéro de séquence. La couche TCP ne se soucie pas du problème de duplication. L'essentiel est que la couche application ne peut pas lire les données en double, quel que soit le nombre de retransmissions, il faut s'assurer qu'une seule copie des données est lue par la couche application.
Dans le noyau du système d'exploitation récepteur, il existe une structure de données - le tampon de réception. Cette structure de données est similaire à la file d'attente de blocage prioritaire. Lorsque B reçoit le paquet de données et passe par les couches jusqu'à la couche de transport. file d'attente de blocage pour mettre les données. Entrez-les et la file d'attente déterminera si les données existent en fonction du numéro de séquence du paquet de données. Si elles existent (l'existence signifie que le même paquet de données a été reçu et lu une fois par le. couche d'application), il sera directement supprimé. Un autre point du tampon de réception est qu'il peut résoudre le problème du dernier arrivé, premier servi dans le réseau. Les données envoyées seront triées en fonction du numéro de séquence, puis consommées par le programme de la couche application dans l'ordre.
Comme le montre la figure ci-dessus, les données arrivant dans le tampon de réception seront triées selon le numéro de séquence. Cela résout non seulement le problème du dernier envoyé, premier arrivé, mais résout également le problème de la réception de paquets de données en double. cette fois, si le paquet de données retransmis est reçu avec le numéro de séquence 500, il sera directement rejeté, car le numéro de séquence minimum du tampon de réception est 1000, ce qui signifie que 500 a déjà été lu par le programme d'application.
La perte de paquets en elle-même est un événement peu probable. Lorsque le nombre de pertes de paquets augmente, le réseau devient un gros problème. À mesure que le nombre de retransmissions augmente, l'intervalle de temps entre les retransmissions continue de s'allonger, car un plus grand nombre de retransmissions indique qu'il y a un problème avec le réseau et des retransmissions fréquentes consommeront des ressources. Lorsque le nombre de retransmissions atteint un seuil, un message de réinitialisation sera envoyé avec le bit d'indicateur RST défini sur 1 pour effacer l'état intermédiaire des deux extrémités. Si le message de réinitialisation ne reçoit pas de réponse, la connexion aux deux extrémités sera supprimée.
La retransmission après expiration du délai est un complément à la réponse d'accusé de réception.
Figure 5
L'établissement d'une connexion signifie que les deux parties communicantes enregistrent les informations de l'autre extrémité. L'achèvement spécifique nécessite trois interactions réseau, comme le montre la figure 5.
La première fois, la poignée de main à trois doit être initiée par le client. Celui qui initie la poignée de main à trois est le client. Le processus spécifique est illustré à la figure 5. Tout d'abord, le client envoie un paquet SYN, c'est-à-dire que l'indicateur SYN dans l'en-tête est défini sur 1. Ensuite, le serveur renvoie un paquet de réponse. Les indicateurs ACK et SYN du paquet de réponse sont. tous deux définis sur 1, car ACK et SYN Les paquets de données avec des bits d'indicateur sont envoyés par le noyau du système d'exploitation en même temps, ils peuvent donc être envoyés ensemble pour améliorer les performances. Enfin, le client envoie un paquet de réponse au serveur et la négociation à trois est terminée. Les paquets de données transmis au cours de ce processus ne contiennent pas de données commerciales.
La signification de la poignée de main à trois :
(1) Jeter des pierres pour demander son chemin
Confirmez si le lien de communication est fluide
(2) Négocier certains paramètres importants
Par exemple, le numéro de séquence du paquet de données transmis
(3) Confirmer les capacités de réception et d'envoi des deux parties
Pourquoi trois poignées de main ? Est-ce que quatre ou deux poignées de main sont acceptables ?
Bien que la négociation à quatre voies n'affecte pas les fonctions normales, elle réduira les performances. La négociation à quatre voies ne peut pas confirmer pleinement les capacités de réception et d'envoi du serveur.
De plus, deux états plus importants sont impliqués ici. Le premier est l'état d'écoute, ce qui signifie que le serveur a lié le port à ce moment-là et attend que le client envoie un paquet SYN. L'autre est établi, qui est. facile à comprendre et signifie que la négociation à trois est terminée. L'état après l'établissement de la connexion.
Contrairement à la négociation à trois, qui ne peut être initiée que par le client en premier, le serveur et le client peuvent tous deux lancer la négociation à quatre.
Figure 6
Le processus spécifique consistant à agiter quatre fois est illustré dans la figure 6. Lorsque la méthode socket.close() est appelée dans le code client ou lorsque le processus se termine, un message de fin FIN sera envoyé au serveur. Le serveur enverra immédiatement un. Le message ACK est renvoyé, mais il devra attendre le code du serveur. Ce n'est qu'après avoir appelé un code tel que socket.close() que le message de fin FIN peut être envoyé au client. Après cela, le client envoie un message ACK au serveur et. le processus est complété en agitant quatre fois.
L'ACK et le FIN au milieu ici ne peuvent pas être combinés, car l'ACK est envoyé par le noyau du système, il sera donc envoyé immédiatement lorsque le serveur recevra le message FIN, mais le message FIN devra attendre le code côté serveur. exécute le socket. Il peut être envoyé après close(), et il y a un décalage horaire entre les deux. Mais il existe un moyen de combiner les deux. Dans des circonstances particulières, l'ACK peut être envoyé en différé, de sorte qu'il puisse être envoyé avec le FIN.
De plus, il existe deux états impliqués dans les quatre processus d'onde. Le premier est l'état close_wait. Cet état est l'état dans lequel se trouve le destinataire après avoir reçu le message FIN de l'expéditeur. L'autre état est time_wait. Cet état est celui de l'envoi d'un état. que la partie doit attendre après avoir reçu le FIN envoyé par le récepteur, puis envoyé un ACK au récepteur. La connexion ne peut pas être déconnectée immédiatement car il est nécessaire d'éviter que le dernier ACK envoyé par l'expéditeur au récepteur ne soit perdu et. le récepteur retransmettant le FIN. Pour garantir que l'expéditeur peut toujours recevoir ce FIN, le temps dans cet état est généralement de 2 MSI (MSI : le temps maximum de transmission des données aux deux extrémités), qui est généralement de 2 minutes.
Si un grand nombre de close_wait est trouvé sur le récepteur, cela signifie que la méthode close() a été oubliée. Si un grand nombre de time_wait est trouvé sur le serveur, cela signifie que le serveur a déclenché un grand nombre de déconnexions TCP actives. opérations.
TCP doit garantir une transmission fiable, mais en même temps, il souhaite également effectuer la transmission des données aussi efficacement que possible. La fenêtre glissante est un mécanisme permettant d'améliorer l'efficacité. C'est en fait une façon de compenser, car pour garantir la fiabilité, TCP sacrifie beaucoup de performances. Quelle que soit la façon dont vous faites glisser la fenêtre, la vitesse de transmission des données ne peut pas être plus rapide que celle d'UDP.
Figure 7
Comme le montre la figure 7, il s'agit du processus de transmission de données, mais le processus d'envoi d'un paquet de données et de réception d'un paquet de données de réponse est encore relativement lent.
Figure 8
Comme le montre la figure 8, cela se produit après l'introduction du mécanisme de fenêtre glissante. Au lieu d'envoyer un seul paquet de données mais plusieurs paquets de données à la fois, le temps d'attente des paquets de données de réponse renvoyés se chevauche. Sans attendre ACK, la quantité de données envoyées par lots correspond à la taille de la fenêtre.
Figure 9
Le processus de fenêtre glissante est illustré à la figure 9. Supposons que la taille de la fenêtre soit de 4 groupes. Lorsqu'un groupe reçoit un ACK, de nouvelles données seront envoyées pour le compléter, ce qui équivaut à un processus glissant. Si l'expéditeur reçoit l'ACK de 3001, cela signifie que les données de 1001 à 3001 ont été reçues, la fenêtre peut donc se déplacer de deux espaces vers la droite.
Que faire si une perte de paquets se produit dans la fenêtre glissante ? Il existe deux situations :
(1) Le paquet de données envoyé est perdu
Si un certain groupe de datagrammes envoyés est perdu, même si vous envoyez plusieurs groupes de données au destinataire par lots, le numéro de séquence de confirmation de l'ACK reçu est toujours celui du groupe perdu jusqu'à ce que l'expéditeur retransmette le datagramme. Par exemple, les datagrammes 1001 à 2000 dans l'image ci-dessus sont perdus Même si plusieurs ensembles de données sont transmis ultérieurement, l'ACK de 1001 sera renvoyé jusqu'à ce que l'expéditeur le retransmet et que le destinataire le reçoive, puis réponde avec l'ACK de 7001. .
(2) La réponse ACK est perdue
Si l'ACK de réponse est perdu, vous n'avez pas à vous en soucier, car vous pouvez simplement attendre que l'ACK d'autres groupes de données soit renvoyé. Par exemple, si l'ACK de 1001 dans l'image ci-dessus est perdu, il sera perdu. n'a pas d'importance. L'expéditeur du prochain ACK de 2001 l'a reçu. Les données précédentes ont été reçues, et il en va de même si l'ACK des données suivantes est perdu.
Le traitement mentionné ci-dessus de la perte de paquets est toujours très efficace. Si le paquet de données est perdu, comblez simplement le vide et retransmettez les données. Si l'ACK est perdu, ignorez-le. Une telle opération est appelée retransmission rapide.
La retransmission hors délai et la retransmission rapide sont différentes stratégies adoptées dans différents environnements. Si votre TCP transmet peu de données et peu fréquemment, la retransmission hors délai sera déclenchée. Si votre TCP doit transmettre une grande quantité de données dans un court laps de temps, la fenêtre glissante sera déclenchée. être déclenché. Retransmission rapide, la retransmission rapide équivaut à la variante de retransmission timeout sous la fenêtre coulissante.
Comme mentionné précédemment à propos de la fenêtre coulissante, la taille de la fenêtre est variable. Vous pouvez contrôler la vitesse d'envoi de l'expéditeur en modifiant la taille de la fenêtre, plus la quantité de données envoyées par unité de temps est élevée et plus l'efficacité est élevée. Plus la fenêtre est petite, plus il y a de données envoyées par unité de temps. Moins il y a de données, moins elles sont efficaces. Normalement, bien sûr, nous espérons que l'efficacité soit aussi élevée que possible, mais la condition préalable à une efficacité élevée est d'assurer la fiabilité. Si l'expéditeur envoie trop vite et que le destinataire ne peut pas le gérer, une perte de paquets peut se produire. is Le destinataire indique à l'expéditeur que la vitesse d'envoi est trop rapide. Il s'agit d'un "contrôle de flux".
Comme le montre la figure ci-dessus, comme mentionné précédemment, il existe un tampon de réception de structure de données dans le noyau, et le récepteur renverra la taille de l'espace libre dans le tampon de réception comme taille de fenêtre. L'en-tête TCP précédent comporte un champ de taille de fenêtre de 16 bits qui utilise ACK pour enregistrer et renvoyer ces informations. Le champ de taille de fenêtre ne prendra effet que dans ACK.
Comme le montre la figure ci-dessus, ACK renverra la taille de la fenêtre pour atteindre l'objectif de contrôle de flux. Lorsque la taille de la fenêtre revient à 0, l'expéditeur enverra périodiquement des messages de sonde qui ne contiennent pas de données commerciales pour déclencher ACK afin de connaître la taille de la fenêtre. état du tampon. Y a-t-il de l'espace libre.
Le contrôle de la congestion est très similaire au contrôle des flux, les deux mécanismes sont associés à des fenêtres coulissantes.
Comme le montre la figure ci-dessus, les liens du réseau sont très complexes et tout nœud sur le lien peut limiter la vitesse de l'expéditeur. L'idée du contrôle de la congestion est de la traiter dans son ensemble quelle que soit la complexité de votre structure intermédiaire, puis de trouver la taille de fenêtre la plus appropriée grâce à des expérimentations.
La figure ci-dessus est un processus de contrôle de la congestion. Essayez-le d'abord avec une taille de fenêtre relativement petite (démarrage lent), car vous ne connaissez pas la situation de congestion du réseau. Après cela, la taille de la fenêtre augmentera de façon exponentielle, et quand elle atteindra. À partir d'un certain seuil, elle commencera à croître linéairement, puis lorsque la fenêtre s'agrandit dans une certaine mesure, une perte de paquets se produit. À ce moment-là, la fenêtre est immédiatement réduite. Il existe deux façons de réduire la taille :
(1) Rétrécissez directement vers le bas, revenez au début du démarrage lent, puis répétez le processus précédent (déjà abandonné)
(2) Rétrécir de moitié puis croître de manière linéaire (la méthode actuellement utilisée)
Le contrôle de la congestion consiste à utiliser des expériences pour trouver une taille de fenêtre appropriée. S'il y a beaucoup de perte de paquets, réduisez la taille de la fenêtre. S'il n'y a pas de perte de paquets, augmentez la taille de la fenêtre.
Une réponse retardée, comme son nom l'indique, signifie attendre un certain temps avant de renvoyer un ACK. Cela implique également le problème de la taille de la fenêtre, car la réponse retardée d'ACK donnera au récepteur plus de temps pour consommer les données dans le tampon de réception, augmentant ainsi. la taille du tampon libre, la taille de la fenêtre renvoyée par ACK augmente et l'expéditeur peut envoyer plus de données par lots.
Il existe deux méthodes de réponse différée :
(1) Préciser le délai en fonction d'un certain temps
(2) Selon la quantité de données reçues
Les deux stratégies ci-dessus sont utilisées en combinaison.
Les réponses de ferroutage sont en fait apparues auparavant, en tant que mécanisme utilisé pour améliorer l'efficacité de la transmission. C'est le cas où ACK et SYN sont renvoyés en utilisant le même paquet de données lors de la négociation à trois. Il existe également une situation similaire à celle de Four Waves. Étant donné que ACK et FIN sont envoyés à des moments différents, les réponses superposées ne peuvent pas être effectuées. Cependant, avec la réponse retardée, ACK n'a pas besoin d'être envoyé aussi rapidement à l'expéditeur. peuvent être combinées avec les deux FIN. Les transmissions secondaires sont regroupées en une seule transmission en se superposant aux réponses.
L'orientation flux d'octets est un mécanisme de TCP. Un problème auquel il faut prêter attention ici est le problème de persistance des paquets. Ce problème est dû à l'incapacité de distinguer les limites entre les différents paquets de données de la couche application en raison des caractéristiques. flux d'octets, le serveur peut lire plusieurs octets et lire un octet, ce qui peut facilement provoquer ce problème.
Il existe deux solutions au problème du sac collant ci-dessus :
(1) Utiliser des séparateurs
N'importe quel symbole peut être utilisé tant qu'il n'existe pas dans le paquet de requête
(2) Convenez de la longueur du paquet de données
Cependant, dans la plupart des cas, les programmeurs Java n'utilisent pas directement TCP, mais utilisent des protocoles prêts à l'emploi tels que http ou implémentent une communication réseau basée sur des outils tels que protobuffer ou dubbo. Ces méthodes ont résolu le problème des paquets collants en interne. Perdu.
(1) Aux deux extrémités de la communication, le processus à une extrémité s'est écrasé.
Le système d'exploitation effectue quatre vagues et agite le PCB.
(2) Un certain hôte est arrêté (processus normal)
La première possibilité est que le système d'exploitation ait effectué quatre vagues. La deuxième possibilité est que le destinataire n'ait pas de réponse ACK après l'envoi du FIN, il retransmet ensuite unilatéralement la connexion. Quant à l'expéditeur, il est également le destinataire. qui s'arrête, puisqu'ils sont tous arrêtés. Les informations stockées (mémoire) ont naturellement disparu.
(3) L'alimentation électrique d'un certain hôte est coupée.
Lorsque l'hôte hors tension est un serveur, le paquet de données envoyé par le client sera retransmis sans ACK. Si aucun résultat n'est obtenu après plusieurs retransmissions, la connexion sera supprimée.
Lorsque l'hôte hors tension est un client et que le serveur n'a pas reçu de paquet de données depuis longtemps, il enverra périodiquement un paquet de battements de cœur sans charge utile, juste pour déclencher un ACK. Si le client est normal, il reviendra. un ACK, sinon il ne le recevra pas. Si aucune réponse n'est reçue du client après avoir été envoyé plusieurs fois de suite mais qu'il n'y a pas de réponse, on peut considérer que le client est en panne et les informations de connexion sont supprimées.
De plus, bien que TCP implémente des paquets de pulsation, le cycle est long. Il faut souvent quelques minutes pour découvrir que le client est en panne grâce à ce paquet de pulsation. Dans le développement réel, les paquets Heartbeat au niveau de la couche application seront implémentés, avec une fréquence plus élevée et une période plus courte (les paquets Heartbeat de deuxième niveau/milliseconde sont envoyés A->B envoie un ping et B->A répond avec un pong). Une fois certain. Si l'appareil se bloque, vous pouvez rapidement trouver le problème.
(4) Le câble réseau est déconnecté
Il s'agit essentiellement du troisième cas. Si l'expéditeur ne reçoit pas l'ACK, il expirera et retransmettra, puis enverra RST, puis supprimera unilatéralement la connexion. Si le destinataire ne reçoit pas le paquet de données, il enverra un paquet de battements de cœur. S'il ne reçoit pas l'ACK, il enverra simplement un paquet de battements de cœur pour supprimer les informations.
Il y a deux bits d'indicateur dans la structure d'en-tête TCP qui ne sont pas mentionnés, à savoir PSH et URG qui exhorte l'autre partie à renvoyer une réponse dès que possible. L'URG est associé au champ de pointeur d'urgence de l'en-tête du paquet TCP et utilisé ensemble pour contrôler la transmission de données TCP hors bande.
La transmission de données hors bande signifie qu'en plus des données commerciales, certains paquets de données spéciaux sont utilisés pour contrôler le mécanisme de fonctionnement de TCP lui-même.
Il se consacre à la recherche technologique depuis plus de 30 ans et maîtrise divers langages tels que java, linux, javascript, php, css, etc. Il a apporté de nombreuses contributions dans le domaine de l'open source. station de documentation pour les développeurs pour partager certains problèmes de développement technologique pour référence future.
