Cet article présente en détail les principes de base de ** TCP **, des applications, de ** l'architecture **, etc., et explique comment utiliser ** TCP ** pour créer des serveurs hautes performances. ..

Ce blog est une traduction de la version anglaise. Vous pouvez vérifier l'original depuis ici. Certaines traductions automatiques sont utilisées. Nous vous serions reconnaissants de bien vouloir signaler toute erreur de traduction. *

Fonction TCP

TCP est un protocole orienté connexion qui fournit une communication fiable en duplex intégral aux processus utilisateur. De cette manière, vous pouvez garantir des paquets de données fiables et ordonnés et prendre en charge le contrôle du trafic. Voici pourquoi TCP devrait implémenter le comportement ci-dessus, en commençant par les aspects suivants:

Pourquoi la couche réseau IP ne peut pas garantir la fiabilité des paquets de données
Comment sécuriser un paquet de données accessible et ordonné par TCP 3, comment TCP prend en charge le contrôle du trafic 4, statut TCP et application

Couche réseau OSI

Pour comprendre pourquoi la couche réseau IP n'assure pas la fiabilité des paquets de données, examinons d'abord la couche réseau OSI. Dans les couches suivantes, TCP est situé dans la couche transport, assurant la fiabilité et la continuité du protocole. Étant donné que les paquets spécifiques transmis / reçus sont déterminés par la couche liaison et la couche physique située en dessous, le travail de TCP est également basé sur l'optimisation et l'amélioration de celui-ci.

La communication entre le client et le serveur utilise le protocole d'application. La communication au niveau de la couche de transport utilise TCP, TCP utilise l'IP de couche inférieure et IP communique en utilisant une certaine forme de couche de liaison de données.

On sait que les données du réseau seront éventuellement transmises sur plusieurs connexions de routeur. Le protocole Ethernet sous-jacent définit la manière dont les signaux électroniques forment des paquets de données, ce qui résout le problème de la communication point à point dans les réseaux locaux (LAN), mais pour plusieurs LAN. Il ne peut pas résoudre le problème de la communication mutuelle.

Le protocole IP utilisé au niveau de la couche réseau définit son propre ensemble de règles d'adresse, qui traite principalement des problèmes d'adressage et de routage pour trouver le meilleur itinéraire pour envoyer des informations en fonction de l'adresse IP de l'autre partie. Je vais le résoudre. Le LAN est connecté via un routeur et dirige les paquets à transférer vers une interface de routage spécifique basée sur le protocole IP. Cependant, le protocole IP ne garantit pas l'arrivée et l'exhaustivité des paquets, et certains paquets seront abandonnés pour garantir l'efficacité de la transmission des données, en particulier lorsque le réseau est encombré. Je vais.

Ceci est fait dans TCP pour garantir l'intégrité, l'ordre et la fiabilité des paquets de données.

Creuser profondément dans TCP

Configuration des paquets TCP

De nombreux réseaux ont une unité maximale de transmission (MTU), qui est la limite pour les trames de données au niveau de la couche liaison. Par exemple, le MTU sur Ethernet est de 1 500 octets. Les datagrammes IP sont envoyés via Ethernet. Si sa longueur est supérieure à la valeur MTU, la partition doit être envoyée de sorte que la longueur de chaque partition soit inférieure à la MTU.

Le paquet de données contient également des informations d'en-tête, y compris des informations d'en-tête IP et des informations d'en-tête Ethernet, en plus de son propre en-tête TCP. Les paquets IP nécessitent au moins 20 octets pour charger les paquets de données Ethernet. Par conséquent, la charge maximale des paquets de données IP est de 1480 octets.

Alors, quelle est la taille d'un paquet TCP?

Vous aurez besoin de la valeur de MSS pour le déterminer. MSS est un concept en TCP (situé dans le champ d'options de l'en-tête). MSS est la valeur maximale d'un segment de données qu'un paquet de données TCP peut envoyer à chaque fois. Si le paquet TCP est plus long que le MSS, il doit être envoyé segment par segment. Si MSS n'est pas configuré, la valeur par défaut est de 536 octets. Autrement dit, un paquet TCP est d'environ 500 octets.

Assurer la fiabilité

Comme mentionné ci-dessus, le routeur sous-jacent n'assure pas la fiabilité ou l'ordre des paquets lors de leur transfert.

Premièrement, pour garantir l'intégrité des paquets, TCP sous-ensembles des paquets plus volumineux que MSS basés sur MSS. Le MSS par défaut est de 563 octets, ce qui est plus petit que le MUT pour les paquets car il est partagé au niveau de la couche réseau.

Ensuite, SEQ et ACK sont ajoutés, et un mécanisme de retransmission de délai d'expiration est adopté pour assurer la fiabilité des paquets.

SEQ

Pour garantir l'ordre des paquets, TCP attribue un numéro de séquence (SEQ) à chaque paquet. Cela permet au récepteur de restaurer les paquets en séquence. De plus, si un paquet est perdu, vous pouvez savoir quel paquet a été perdu. En général, la SEQ du premier paquet est un nombre aléatoire et peut commencer à 1.

ACK

Maintenant que le SEQ a été attribué, comment vous assurez-vous de l'arrivée du colis?

Ceci est déterminé en fonction de ACK. Chaque fois qu'un paquet est reçu, le destinataire doit renvoyer un ACK afin que l'expéditeur puisse confirmer qu'il a été envoyé. De plus, le récepteur doit valider chaque paquet. Si une erreur est trouvée lors de la validation, l'ACK ne sera pas envoyé et déclenchera le renvoi du délai d'expiration de l'expéditeur.

ACK contient les informations suivantes:

--SEQ pour recevoir le prochain paquet

Capacité restante de la fenêtre du récepteur du récepteur

J'utilise WireShark pour capturer des paquets oschina et vérifier les données pour une poignée de main à trois.

Native IP: 192.168.1.103 oschinaIp: 116.211.174.177 Three-way handshake process: 1.me->osChina:syn=1 seq=x ack=0 2.osChina->me:syn=1 seq=y ack=x+1 3.me->osChina:seq=x+1 ack=y+1

1、me->osChina:syn=1 seq=0 ack=0

2、 osChina->me:syn=1 seq=0 ack=0+1

3、 me->osChina:seq=0+1 ack=0+1

Comparons les processus de trois parties.

** Renvoyer le délai d'expiration **

Nous savons que le réseau est très instable. Même si SEQ et ACK sont ajoutés au paquet de données pour garantir l'ordre, il n'y a aucune garantie que des problèmes tels que la perte de paquets et le délai d'expiration ne se produiront pas. Que faire si les données envoyées par l'expéditeur ou l'ACK renvoyé par le destinataire sont perdues ou expirées sur le réseau?

RTO, délai de retransmission. Une méthode d'évaluation est nécessaire pour déterminer si un paquet a expiré. RTT mesure le temps d'aller-retour d'une connexion donnée. À mesure que le trafic réseau change, le temps change en conséquence. TCP doit suivre ces changements et ajuster dynamiquement le RTO.

Si l'expéditeur ne reçoit pas un ACK pour le paquet dans un certain laps de temps, il est déterminé que le paquet a été perdu dans le réseau et le paquet est automatiquement retransmis. Ce mécanisme est appelé délai de retransmission.

Si dans ce délai l'expéditeur ne reçoit pas le message ACK en raison de la perte du message du destinataire, l'expéditeur renvoie le paquet au destinataire. Si l'expéditeur reçoit un message ACK pour ce paquet après le délai d'expiration, mais que l'expéditeur a déjà renvoyé ce paquet en raison d'un délai d'expiration, l'expéditeur ne traitera pas l'ACK à ce stade et le rejettera simplement. Après avoir reçu ce paquet, le récepteur renvoie à nouveau le message ACK.

Contrôle de la circulation

De ce qui précède, nous pouvons voir que TCP peut assurer la fiabilité des données, mais nous devons également tenir compte de l'efficacité. Il y a trois choses à considérer:

Prise en charge de l'envoi de paquets en vrac
Prend en charge le contrôle de la congestion en fonction des conditions du réseau
Fonction pour saisir l'état du récepteur et réduire la charge sur le récepteur

Sur la base des trois exigences ci-dessus, nous prenons les mesures suivantes.

Fenêtre coulissante

Il est trop inefficace d'envoyer et de vérifier les paquets TCP un par un. Même si la fiabilité est assurée, l'efficacité ne peut pas être assurée par l'envoi et la confirmation de chaque paquet. Dans un tel cas, vous avez besoin d'une méthode pour envoyer et vérifier tout à la fois, qui est la fenêtre coulissante.

Fenêtre d'envoi coulissante:

Dans la fenêtre d'envoi, de gauche à droite, les données avant cette fenêtre doivent être les données envoyées et confirmées par le destinataire, et les données entrant dans la fenêtre d'envoi sont les données que l'expéditeur peut envoyer et envoyer. Les données après la fenêtre sont les données qui ne peuvent pas être envoyées.

Deux solutions ont été proposées en cas de timeout ou de perte.

1, Go-Back-N. Tous les paquets avec une SEQ suivant la SEQ du paquet perdu seront retransmis. 2. Sélectionnez ARQ pour envoyer uniquement les paquets perdus et envoyer sans duplication (haute efficacité et empêcher l'envoi de paquets en double.

La fenêtre coulissante a également la capacité d'informer l'expéditeur de l'état de traitement du destinataire. En supposant que le cache du récepteur TCP est plein et ne peut plus traiter de données, mais que l'expéditeur ne le sait pas, dans ce cas, l'expéditeur peut indiquer à l'expéditeur la taille de la fenêtre glissante actuelle et pas plus. N'envoie pas de données. Dans ce cas, l'expéditeur n'enverra plus de données, à condition qu'il informe l'expéditeur de la taille actuelle de la fenêtre glissante à chaque fois qu'il envoie un paquet.

En outre, le destinataire envoie un ACK immédiatement après avoir reçu les données, mais déclare en même temps à l'expéditeur la taille de la fenêtre comme 0.
De plus, tant qu'il n'y a pas suffisamment d'espace libre dans le cache, ACK ne sera pas envoyé immédiatement lorsqu'un paquet arrive. Cela empêchera l'expéditeur de faire glisser la fenêtre. Mais il y a aussi des problèmes. Le délai d'envoi de l'ACK par le récepteur ne doit pas dépasser le délai d'expiration. S'il est trop long, l'expéditeur peut penser à tort que les données ont été perdues et les renvoyer.

Contrôle de la congestion

Je sais que la situation du réseau est instable. Dans les bons cas, vous pouvez envoyer plus de paquets. Dans le pire des cas, si le débit de transmission des paquets ne change pas, non seulement la charge sur le réseau augmentera, mais il y aura trop de paquets, des pertes se produiront, les retransmissions d'expiration augmenteront et l'efficacité de la communication diminuera certainement.

Sur cette base, les deux parties de la communication TCP détiennent une valeur appelée fenêtre de congestion (cwnd, fenêtre de congestion) qui dépend du taux de congestion dans le réseau, et la valeur de la fenêtre de transmission du côté de transmission est la taille de la fenêtre de congestion. C'est une valeur égale à. S'il n'y a pas de congestion dans le réseau, vous pouvez augmenter la valeur de la fenêtre de congestion afin que l'expéditeur puisse envoyer plus de données au réseau. Sinon, réduisez la valeur de la fenêtre de congestion pour ne pas augmenter le taux de congestion du réseau.

TCP dispose actuellement de quatre algorithmes principaux pour le contrôle de la congestion:

1, démarrage lent 2, éviter la congestion 3, retransmission rapide 4, récupération rapide

Je ne présenterai pas l'implémentation d'un algorithme spécifique. Une caractéristique à peu près implémentée consiste à trouver le bon débit de transmission à partir des conditions actuelles du réseau afin que le réseau ne soit pas surchargé. Par exemple, Démarrage lent signifie que la vitesse de transmission est lente au début et que le débit est ajusté en fonction de la perte de paquets qui se produit. S'il n'y a pas de perte de paquets, augmentez la vitesse de transmission. En cas de perte de paquets, la vitesse de transmission diminuera.

État TCP

Comme tout utilisateur TCP le sait, une prise de contact à trois se produit lorsque TCP établit une connexion et une prise de contact à quatre se produit lorsque la connexion est perdue. Alors quel est l'état?

Il n'y a aucune perte à se souvenir du chiffre ci-dessus. Organisons-nous en regardant la figure ci-dessous et voyons l'état de l'application spécifique.

Ainsi, si la connexion est établie avec succès, le statut sera ÉTABLI. Si l'état du côté de la réception est SYN_RECV, cela signifie que vous avez répondu au deuxième message de prise de contact et que vous attendez une reconfirmation du côté de l'envoi. Si votre réseau est soumis à un grand nombre d'attaques SYN, il existe de nombreux statuts SYN_RECV. Dans ce cas, l'identification de ces adresses IP et l'utilisation du filtrage par pare-feu peuvent résoudre un certain nombre de faux problèmes de connectivité.

Connexion perdue-TIME_WAIT

Sur le réseau, une partie est activement fermée, mais pas dans une poignée de main à quatre. Reste-t-il des canaux établis par TCP? Combien de temps sera-t-il fermé? L'état TCP à ce moment est TIME_WAIT. En réalité, on peut imaginer que cette situation se produit souvent. De nombreuses connexions fermées sont activement fermées plutôt que des communications d'établissement de liaison. S'il est fermé à ce moment, le canal TCP précédent peut-il être reconnecté? Ou dois-je me reconnecter?

Pour les deux implémentations TCP, vous devez choisir une valeur pour MSL. La valeur par défaut est de 2 minutes ou 30 secondes. La valeur par défaut de TIME_WAIT est le double de celle de MSL et dure entre 1 et 4 minutes. MSL est le temps le plus long pour un paquet de données IP de survivre dans le réseau.

Deux raisons pour lesquelles TIME_WAIT existe: 1. Parce qu'une connexion TCP full-duplex fiable a pris fin 2. Parce que les anciens paquets en double sont autorisés à disparaître dans le réseau

TCP doit empêcher la reproduction d'anciens paquets en double d'une connexion après la fermeture de la connexion, et est confondu avec l'incarnation de la même connexion. Si TIME_WAY est suffisamment long, soit deux fois la longueur du MSL, il suffit de lui permettre de survivre au maximum pendant le MSL avant que les paquets dans une direction ne soient abandonnés.

De l'état TIME_WAIT à l'état CLOSED, il y a un paramètre de délai d'expiration, qui est 2 * MSL (RFC793 définit MSL comme 2 minutes et Linux comme 30 secondes). Si ce délai est dépassé, le canal TCP actuel est défini comme fermé.

Alibaba Cloud est l'opérateur d'infrastructure cloud n ° 1 (Gartner 2019) dans la région Asie-Pacifique avec deux centres de données au Japon et plus de 60 zones de disponibilité dans le monde. Cliquez ici pour plus d'informations sur Alibaba Cloud. Page officielle d'Alibaba Cloud Japan *

[JAVA] TCP: principes de base et architecture d'application