TCP, c'est-à-dire le protocole de contrôle de transmission, le protocole de contrôle de transmission. Comme son nom l'indique, il est nécessaire d'avoir un contrôle détaillé sur la transmission des données.

Format de segment de protocole TCP

Numéro de port source/destination : indique de quel processus proviennent les données et à quel processus elles sont destinées ;
Numéro de série 32 bits/numéro de confirmation 32 bits : description détaillée plus loin ;
Longueur d'en-tête TCP 4 bits : indique le nombre de bits 32 bits (combien de 4 octets) de l'en-tête TCP ; la longueur maximale de l'en-tête TCP est donc de 15 * 4 = 60
6 bits drapeaux :

URG : si le pointeur urgent est valide
ACK : Si le numéro de confirmation est valide
PSH : invite l'application finale réceptrice à lire immédiatement les données du tampon TCP
RST : l'autre partie demande à rétablir la connexion ; nous appelons le segment portant le drapeau RST un segment de réinitialisation
SYN : demande d'établissement de connexion ; nous appelons l'identifiant SYN un segment de synchronisation
FIN : notifie à l'autre partie que l'extrémité locale est sur le point d'être fermée. Nous appelons le segment d'extrémité portant le drapeau FIN

Taille de fenêtre 16 bits : plus à ce sujet plus tard
Somme de contrôle 16 bits : bourrage à l'envoi, contrôle CRC. Si la vérification de l'extrémité de réception échoue, on considère qu'il y a un problème avec les données. La somme de contrôle comprend ici non seulement l'en-tête TCP, mais également la partie données TCP.
Pointeur urgent 16 bits : identifie quelle partie des données est une donnée urgente ;
Option d'en-tête de 40 octets : temporairement ignorée ;

Principe TCP

Le mécanisme de contrôle fourni par TCP pour la transmission de données se reflète principalement dans deux aspects : la sécurité et l'efficacité.

Ces mécanismes sont similaires au principe de conception du multi-threading : sous le principe d'assurer la sécurité de la transmission des données, améliorez autant que possible l'efficacité de la transmission.

Mécanisme de réponse d'accusé de réception (mécanisme de sécurité)

TCP numérote chaque octet de données. est le numéro de série.

Chaque ACK a un numéro de séquence de confirmation correspondant, ce qui signifie dire à l'expéditeur quelles données j'ai reçues ; où commencerez-vous à envoyer la prochaine fois.

Mécanisme de retransmission de temporisation (mécanisme de sécurité)

Une fois que l'hôte A a envoyé des données à B, les données peuvent ne pas atteindre l'hôte B en raison de la congestion du réseau et d'autres raisons ;
Si l'hôte A ne reçoit pas d'accusé de réception de B dans un intervalle de temps spécifique, il renverra ;

Cependant, l'hôte A n'a pas reçu l'accusé de réception de B, cela peut également être dû au fait que l'ACK a été perdu ;

Ainsi, l'hôte B recevra beaucoup de données en double. Ensuite, le protocole TCP doit être capable d'identifier ces paquets comme des paquets en double et d'éliminer les doublons.

À ce stade, nous pouvons utiliser le numéro de série mentionné ci-dessus pour obtenir facilement l'effet de déduplication.

Alors, comment déterminer si le délai d'attente?

Idéalement, trouvez un délai minimum pour vous assurer que "la réponse de confirmation doit être retournée dans ce délai".
Cependant, la durée de cette période varie selon les différents environnements réseau.
Si le délai d'attente est trop long, cela affectera l'efficacité globale de la retransmission ;
Si le délai d'attente est trop court, des paquets répétés peuvent être envoyés fréquemment ;

Afin d'assurer une communication performante dans n'importe quel environnement, TCP calcule dynamiquement le délai d'expiration maximal.

Sous Linux (il en va de même pour BSD Unix et Windows), le délai d'attente est contrôlé avec une unité de 500 ms, et le délai d'attente pour chaque retransmission de délai d'attente est un multiple entier de 500 ms.
S'il n'y a toujours pas de réponse après une retransmission, attendez 2*500 ms avant de retransmettre.
S'il n'y a toujours pas de réponse, attendez 4*500ms pour la retransmission. Et ainsi de suite, augmentant de façon exponentielle.
Après avoir accumulé un certain nombre de retransmissions, TCP considère que le réseau ou l'hôte pair est anormal, et ferme de force la connexion.

Mécanisme de gestion des connexions (mécanisme de sécurité)

Dans des circonstances normales, TCP doit passer par trois poignées de main pour établir une connexion et quatre fois pour se déconnecter.

Transition d'état du serveur :

[CLOSED -> LISTEN] Le serveur entre dans l'état LISTEN après avoir appelé listen, attendant que le client se connecte ;
[LISTEN -> SYN_RCVD] Une fois la demande de connexion (segment de synchronisation) surveillée, la connexion est placée dans la file d'attente du noyau et un message de confirmation SYN est envoyé au client.
[SYN_RCVD -> ESTABLISHED] Une fois que le serveur reçoit le message de confirmation du client, il entre dans l'état ESTABLISHED et peut lire et écrire des données.
[ESTABLISHED -> CLOSE_WAIT] Lorsque le client ferme activement la connexion (appel de fermeture), le serveur recevra le segment de fin, et le serveur renverra le segment de confirmation et entrera CLOSE_WAIT ;
[CLOSE_WAIT -> LAST_ACK] Après avoir entré CLOSE_WAIT, cela signifie que le serveur est prêt à fermer la connexion (les données précédentes doivent être traitées); lorsque le serveur appelle réellement close pour fermer la connexion, il enverra un FIN au client , et à ce moment le serveur entre dans l'état LAST_ACK, attendant la dernière arrivée ACK (cet ACK est la confirmation du client de la réception de FIN)
[LAST_ACK -> CLOSED] Le serveur a reçu l'ACK pour FIN et ferme complètement la connexion.

Transition de l'état du client :

[CLOSED -> SYN_SENT] Le client appelle connect pour envoyer un segment de synchronisation ;
[SYN_SENT -> ESTABLISHED] Si l'appel de connexion réussit, il entrera dans l'état ESTABLISHED et commencera à lire et à écrire des données ;
[ESTABLISHED -> FIN_WAIT_1] Lorsque le client appelle activement close, il envoie un segment de fin au serveur et entre FIN_WAIT_1 en même temps ;
[FIN_WAIT_1 -> FIN_WAIT_2] Après avoir reçu la confirmation du serveur du segment final, le client entre FIN_WAIT_2 et commence à attendre le segment final du serveur ;
[FIN_WAIT_2 -> TIME_WAIT] Le client reçoit le segment de fin du serveur, entre TIME_WAIT et envoie LAST_ACK ;
[TIME_WAIT -> CLOSED] Le client attendra un temps de 2MSL (Max Segment Life, durée de vie maximale du message) avant d'entrer dans l'état CLOSED.

La figure suivante est un résumé des transitions d'état TCP :

La ligne pointillée plus épaisse indique le changement d'état du serveur ;
La ligne pleine plus épaisse indique le changement d'état du client ;
CLOSED est un point de départ hypothétique, pas un état réel ;

À propos de "semi-fermé", exemple de rupture entre copain et copine

TEMPS D'ATTENTE

MSL est la durée de vie maximale d'un message TCP, donc si TIME_WAIT persiste pour 2MSL, il peut garantir que les segments de message non reçus ou en retard dans les deux sens de transmission ont disparu (sinon le serveur redémarre immédiatement et peut recevoir des messages de données tardives du précédent processus, mais ces données sont susceptibles d'être erronées) ;
Dans le même temps, il est également théoriquement garanti que le dernier message arrive de manière fiable (en supposant que le dernier ACK est perdu, le serveur renverra un FIN. À ce moment, bien que le processus client soit parti, la connexion TCP est toujours là , et le LAST_ACK peut toujours être renvoyé);

CLOSE_WAIT

D'une manière générale, pour un grand nombre d'états CLOSE_WAIT sur le serveur, la raison est que le serveur n'a pas fermé correctement le socket, ce qui a entraîné la non-exécution correcte de quatre mains agitées. C'est un bogue. Ajoutez simplement la fermeture correspondante pour résoudre le problème.

Fenêtre coulissante (mécanisme d'efficacité)

Nous venons de parler de la stratégie de réponse d'accusé de réception. Pour chaque segment de données envoyé, une réponse de confirmation ACK doit être donnée. Après réception de l'ACK, le segment de données suivant est envoyé. Cela a un inconvénient relativement important, c'est-à-dire des performances médiocres. Surtout lorsque le temps d'aller-retour des données est long.

Étant donné que les performances de cette méthode d'envoi et de réception sont faibles, nous pouvons grandement améliorer les performances en envoyant plusieurs éléments de données à la fois (en fait, le temps d'attente de plusieurs segments se chevauche).

La taille de la fenêtre fait référence à la valeur maximale qui peut continuer à envoyer des données sans attendre un accusé de réception. La taille de la fenêtre dans la figure ci-dessus est de 4000 octets (quatre segments).
Lors de l'envoi des quatre premiers segments, vous n'avez pas besoin d'attendre un ACK, envoyez-le simplement directement ;
Après réception du premier ACK, la fenêtre glissante recule et continue à envoyer les données du cinquième segment, et ainsi de suite ;
Afin de maintenir cette fenêtre glissante, le noyau du système d'exploitation doit créer un tampon d'envoi pour enregistrer les données actuellement sans réponse ; seules les données qui ont reçu une réponse peuvent être supprimées du tampon ;
Plus la fenêtre est grande, plus le débit du réseau est élevé ;

Donc s'il y a une perte de paquet, comment retransmettre ? Deux situations sont évoquées ici.

Situation 1 : Le paquet de données est arrivé, mais l'ACK est perdu.

Dans ce cas, peu importe si une partie de l'ACK est perdue, car cela peut être confirmé par l'ACK suivant ;

Cas 2 : Le paquet de données est directement perdu.

Lorsqu'un certain segment est perdu, l'expéditeur recevra toujours ACK comme 1001, tout comme rappelant à l'expéditeur "Je veux 1001" ;
Si l'hôte expéditeur reçoit la même réponse "1001" trois fois de suite, il renverra les données correspondantes 1001 - 2000 ;
À ce moment, après que l'extrémité réceptrice ait reçu 1001, l'ACK renvoyé est à nouveau 7001 (parce que 2001 - 7000). L'extrémité réceptrice l'a déjà reçu auparavant et il est placé dans le tampon de réception du noyau du système d'exploitation de l'extrémité réceptrice. ;

Ce mécanisme est appelé "commande de retransmission à grande vitesse" (également appelée "retransmission rapide").

Contrôle de flux (mécanisme de sécurité)

La vitesse à laquelle l'extrémité réceptrice peut traiter les données est limitée. Si l'extrémité émettrice envoie trop vite, la mémoire tampon de l'extrémité réceptrice est remplie. Si l'extrémité émettrice continue d'envoyer à ce moment, cela entraînera une perte de paquets, ce qui entraînera une série de réactions en chaîne telles que la perte de paquets et la retransmission.

Par conséquent, TCP prend en charge la détermination de la vitesse d'envoi de l'extrémité émettrice en fonction de la capacité de traitement de l'extrémité réceptrice. Ce mécanisme est appelé contrôle de flux (Flow Control) ;

L'extrémité réceptrice met la taille de la mémoire tampon qu'elle peut recevoir dans le champ "taille de la fenêtre" de l'en-tête TCP, et notifie l'extrémité émettrice via l'extrémité ACK ;
Plus le champ de taille de fenêtre est grand, plus le débit du réseau est élevé ;
Une fois que l'extrémité réceptrice constate que sa mémoire tampon est presque pleine, elle définit la taille de la fenêtre sur une valeur plus petite et notifie l'extrémité émettrice ;
Après que l'expéditeur ait reçu cette fenêtre, il ralentira sa vitesse d'envoi ;
Si le tampon du destinataire est plein, la fenêtre sera définie sur 0 ; à ce moment, l'expéditeur n'enverra plus de données, mais il doit envoyer périodiquement un segment de données de détection de fenêtre, afin que le destinataire puisse indiquer à l'expéditeur la taille de la fenêtre .

Comment l'extrémité réceptrice indique-t-elle à l'extrémité émettrice la taille de la fenêtre ? Rappelez-vous que dans notre en-tête TCP, il y a un champ de fenêtre de 16 bits , qui stocke les informations de taille de fenêtre ;

Voici donc la question, le nombre à 16 chiffres peut représenter un maximum de 65535, alors la fenêtre TCP maximale est-elle de 65535 octets ?

En fait, l'option d'en-tête TCP 40 octets inclut également un facteur d'expansion de fenêtre M, et la taille de fenêtre réelle est la valeur du champ de fenêtre décalée vers la gauche de M bits ;

Contrôle de la congestion (mécanisme de sécurité)

Bien que TCP ait le grand tueur de la fenêtre coulissante, il peut envoyer une grande quantité de données de manière efficace et fiable. Mais cela peut toujours causer des problèmes si vous envoyez beaucoup de données au stade initial.

Étant donné qu'il existe de nombreux ordinateurs sur le réseau, l'état actuel du réseau peut être relativement encombré. L'envoi imprudent d'une grande quantité de données sans connaître l'état actuel du réseau risque d'aggraver les choses.

TCP introduit un mécanisme de démarrage lent , qui envoie d'abord une petite quantité de données, explore le chemin, découvre l'état de congestion actuel du réseau, puis décide à quelle vitesse transmettre les données ;

Un concept est introduit ici comme la fenêtre de congestion
Lorsque l'envoi commence, définissez la taille de la fenêtre de congestion sur 1 ;
Chaque fois qu'une réponse ACK est reçue, la fenêtre de congestion est incrémentée de 1 ;
Chaque fois qu'un paquet de données est envoyé, comparez la fenêtre de congestion avec la taille de fenêtre renvoyée par l'hôte récepteur et prenez la plus petite valeur comme fenêtre d'envoi réelle ;

Le taux de croissance de la fenêtre de congestion comme ci-dessus est exponentiel. « Démarrage lent » signifie simplement une croissance lente au début, mais très rapide.

Pour ne pas croître aussi vite, la fenêtre de congestion ne peut pas simplement être doublée.
Un seuil appelé démarrage lent est introduit ici
Lorsque la fenêtre de congestion dépasse ce seuil, elle ne croît plus de façon exponentielle, mais croît de façon linéaire

Lorsque TCP commence à démarrer, le seuil de démarrage lent est égal à la valeur maximale de la fenêtre ;
A chaque retransmission de temporisation, le seuil de démarrage lent deviendra la moitié de la valeur d'origine, et la fenêtre de congestion sera remise à 1 ;

Une petite quantité de perte de paquets, nous déclenchons juste une retransmission de délai d'attente ; une grande quantité de perte de paquets, nous pensons que le réseau est encombré ;

Lorsque la communication TCP démarre, le débit du réseau augmente progressivement ; à mesure que le réseau devient congestionné, le débit diminue immédiatement ;

Le contrôle de la congestion, en dernière analyse, est un compromis selon lequel le protocole TCP veut transmettre les données à l'autre partie le plus rapidement possible, mais évite également de causer trop de pression sur le réseau.

Le processus de contrôle de la congestion TCP est comme le sentiment d'amour passionné

Réponse différée (mécanisme d'efficacité)

Si l'hôte recevant les données renvoie immédiatement une réponse ACK, la fenêtre renvoyée à ce moment peut être relativement petite.

Supposons que le tampon de fin de réception est de 1M. 500 000 données reçues à la fois ; si vous répondez immédiatement, la fenêtre renvoyée est de 500 000 ;
Mais en fait, la vitesse de traitement de l'extrémité de traitement peut être très rapide et 500 000 données seront consommées à partir du tampon en 10 ms ;
Dans ce cas, le traitement à la réception est loin d'atteindre sa limite, même si la fenêtre est agrandie, il peut encore le gérer ;
Si l'extrémité de réception attend un certain temps avant de répondre, par exemple, attend 200 ms avant de répondre, la taille de la fenêtre renvoyée à ce moment est de 1 M ;
Il est important de se rappeler que plus la fenêtre est grande, plus le débit du réseau est élevé et plus le transfert est efficace. Notre objectif est de maximiser l'efficacité de la transmission tout en veillant à ce que le réseau ne soit pas encombré ;

Ainsi, tous les paquets peuvent-ils être retardés en réponse ? Certainement pas;

Limite de quantité : répondez tous les N paquets ;
Limite de temps : répondez une fois lorsque le délai maximal est dépassé ;

Le nombre spécifique et le délai d'attente varient en fonction du système d'exploitation ; généralement, N est égal à 2 et le délai d'attente est de 200 ms ;

Superposition (mécanisme d'efficacité)

Sur la base de la réponse retardée, nous avons constaté que dans de nombreux cas, le serveur client "envoie et reçoit" également au niveau de la couche application. Cela signifie que le client a dit "Comment allez-vous" au serveur, et le serveur renverra un "Très bien, merci" au client ;

Ensuite, à ce moment, l'ACK peut faire du stop et le renvoyer au client avec la réponse du serveur "Bien, merci"

Autres fonctionnalités : orienté flux d'octets, tampons, limites de taille

Créez une socket TCP, et créez en même temps un buffer d'envoi et un buffer de réception dans le noyau ;

Lors de l'appel à write, les données seront d'abord écrites dans le tampon d'envoi ;
Si le nombre d'octets envoyés est trop long, il sera divisé en plusieurs paquets TCP et envoyé ;
Si le nombre d'octets envoyés est trop court, il attendra dans le tampon jusqu'à ce que le tampon ait presque la même longueur, ou l'enverra à d'autres moments appropriés ;
Lors de la réception de données, les données arrivent également dans le tampon de réception du noyau à partir du pilote de la carte réseau ;
Ensuite, l'application peut appeler read pour obtenir des données du tampon de réception ;
D'autre part, une connexion TCP possède à la fois un tampon d'envoi et un tampon de réception, donc pour cette connexion, les données peuvent être lues ou écrites. Ce concept est appelé duplex intégral

En raison de l'existence du tampon, la lecture et l'écriture du programme TCP n'ont pas besoin de correspondre une par une, par exemple :

Lors de l'écriture de 100 octets de données, vous pouvez appeler write une fois pour écrire 100 octets, ou vous pouvez appeler write 100 fois pour écrire un octet à la fois ;
Lors de la lecture de 100 octets de données, il n'est pas nécessaire de se demander comment les écrire. Vous pouvez lire 100 octets à la fois ou vous pouvez lire un octet à la fois et répéter 100 fois.

problème de sac collant

Tout d'abord, il doit être clair que le "package" dans le problème du sticky package fait référence au package de données de la couche application.
Dans l'en-tête de protocole de TCP, il n'y a pas de champ tel que "longueur de paquet" comme UDP, mais il y a un champ tel que le numéro de séquence.
Du point de vue de la couche de transport, TCP vient un par un. Mettez-les dans le tampon selon le numéro de séquence.
Du point de vue de la couche d'application, ce que vous voyez n'est qu'une série de données d'octets continues.
Ensuite, le programme d'application voit une telle série de données d'octets et ne sait pas quelle partie commencer à partir de quelle partie, il s'agit d'un paquet de données de couche application complet.

Alors comment éviter le problème du sac collant ? Au final, c'est une phrase pour clarifier la frontière entre les deux forfaits .

Pour un paquet de longueur fixe, assurez-vous qu'il est lu à une taille fixe à chaque fois ; par exemple, la structure de requête ci-dessus est de taille fixe, elle peut donc être lue depuis le début du tampon en fonction de sizeof (Request) ;
Pour les paquets de longueur variable, vous pouvez spécifier un champ pour la longueur totale du paquet dans l'en-tête du paquet, afin de connaître la position finale du paquet ;
Pour les paquets de longueur variable, vous pouvez également utiliser un séparateur clair entre les paquets (le protocole de la couche application est déterminé par le programmeur lui-même, tant que le séparateur n'entre pas en conflit avec le texte) ;

Réflexion : Pour le protocole UDP, y a-t-il aussi un "problème de sticky packet" ?

Pour UDP, si la couche supérieure n'a pas livré de données, la longueur du paquet UDP est toujours là. Dans le même temps, UDP fournit les données une par une à la couche application. Il existe des limites de données très claires.
Du point de vue de la couche application, lors de l'utilisation d'UDP, un message UDP complet est reçu ou non. Il n'y aura pas de situation "demi".

Exception TCP

Arrêt du processus : l'arrêt du processus libère le descripteur de fichier et FIN peut toujours être envoyé. Ce n'est pas différent d'un arrêt normal.

Redémarrage de la machine : identique à l'arrêt du processus.

La machine est éteinte/le câble réseau est déconnecté : l'extrémité réceptrice pense que la connexion est toujours là, une fois que l'extrémité réceptrice a une opération d'écriture, et que l'extrémité réceptrice constate que la connexion n'est plus là, elle se réinitialisera. Même s'il n'y a pas d'opération d'écriture, TCP lui-même a un temporisateur de maintien en vie intégré, qui demandera périodiquement si l'autre partie est toujours là. Si l'autre partie n'est pas là, la connexion sera également libérée.

De plus, certains protocoles de la couche application disposent également de tels mécanismes de détection. Par exemple, dans la longue connexion HTTP, le statut de l'autre partie sera également vérifié périodiquement. Par exemple, QQ essaiera de se reconnecter périodiquement après la déconnexion de QQ.

Résumé TCP

Pourquoi TCP est-il si compliqué ? Parce qu'il faut assurer la fiabilité et en même temps améliorer au maximum les performances.

fiabilité:

somme de contrôle
Numéro de série (arrive séquentiellement)
réponse de confirmation
délai d'attente renvoyé
gestion des connexions
contrôle de flux
contrôle de la congestion

Améliorer les performances:

fenêtre coulissante
retransmission rapide
réponse retardée
se greffer

autre:

Temporisateurs (temporisateur de retransmission de temporisation, temporisateur de maintien en vie, temporisateur TIME_WAIT, etc.)

Basé sur le protocole de couche d'application TCP

HTTP
HTTPS
SSH
Telnet
FTP
SMTP

Bien entendu, il inclut également le protocole de couche application personnalisé lorsque vous écrivez votre propre programme TCP ;

Protocole UDP

Format de fin de protocole UDP

Longueur UDP 16 bits, indiquant la longueur maximale du datagramme entier (en-tête UDP + données UDP) ;
Si la somme de contrôle est erronée, elle sera directement rejetée ;

Caractéristiques d'UDP

Le processus de transmission UDP est similaire à l'envoi d'une lettre.

pas de connection

Si vous connaissez l'adresse IP et le numéro de port du pair, vous pouvez transmettre directement sans établir de connexion ;

Non fiable

Sans aucun mécanisme de sécurité, après que l'expéditeur a envoyé le datagramme, si le segment ne peut pas être envoyé à l'autre partie en raison d'une défaillance du réseau, la couche de protocole UDP ne renverra aucun message d'erreur à la couche application ;

Orienté datagramme

La couche application envoie à l'UDP la longueur du message, et l'UDP l'envoie tel quel, sans division ni fusion ;

Transférer 100 octets de données avec UDP :

Si l'extrémité émettrice envoie 100 octets à la fois, l'extrémité réceptrice doit également recevoir 100 octets à la fois ; au lieu de recevoir 10 fois dans une boucle, 10 octets sont reçus à chaque fois.

zone tampon

UDP n'a qu'un tampon de réception et pas de tampon d'envoi :

UDP n'a pas de tampon d'envoi réel . Les données envoyées seront directement transmises au noyau, et le noyau transmettra les données au protocole de couche réseau pour les actions de transmission ultérieures ;
UDP a un tampon de réception, mais ce tampon de réception ne peut pas garantir que l'ordre des messages UDP reçus est cohérent avec l'ordre d'envoi des messages UDP ; si le tampon est plein, les données UDP arrivantes seront rejetées ;

Les sockets UDP peuvent à la fois lire et écrire.Ce concept est appelé full duplex .

taille limitée

Il y a une longueur maximale de 16 bits dans l'en-tête du protocole UDP. C'est-à-dire que la longueur maximale des données pouvant être transmises par un UDP est de 64 Ko (y compris l'en-tête UDP).

Protocole de couche application basé sur UDP

NFS : système de fichiers réseau
TFTP : protocole de transfert de fichiers trivial
DHCP : protocole de configuration dynamique de l'hôte
BOOTP : protocole de démarrage (pour le démarrage d'un périphérique sans disque)
DNS : protocole de résolution de nom de domaine

Bien sûr, il inclut également le protocole de couche d'application personnalisé lorsque vous écrivez vous-même le programme UDP.

Comparaison TCP/UDP

Nous avons dit que TCP est une connexion fiable, alors TCP est-il nécessairement meilleur que UDP ? Les avantages et les inconvénients entre TCP et UDP ne peuvent pas être comparés simplement et absolument

Lorsque TCP est utilisé pour une transmission fiable, il est appliqué à des scénarios tels que le transfert de fichiers et la mise à jour d'état importante ;
UDP est utilisé dans les domaines de communication qui nécessitent une transmission à grande vitesse et des performances en temps réel, par exemple, QQ précoce, transmission vidéo, etc. De plus, UDP peut être utilisé pour la diffusion ;

En dernière analyse, TCP et UDP sont tous deux des outils pour les programmeurs. Quand les utiliser et comment les utiliser doivent être déterminés en fonction de scénarios de demande spécifiques.

Protocoles de clé de couche réseau

Déterminez un chemin approprié dans un environnement réseau complexe.

protocole IP

Le format de l'en-tête de protocole est le suivant :

Numéro de version à 4 chiffres (version) : Spécifie la version du protocole IP, qui est 4 pour IPv4.
Longueur d'en-tête de 4 bits (longueur d'en-tête): la longueur de l'en-tête IP est de 32 bits, c'est-à-dire le nombre d'octets de longueur * 4. 4 bits signifie que le nombre maximum est de 15, donc la longueur maximum de l'en-tête IP est de 60 octets.
Type de service 8 bits (type de service) : champ de priorité 3 bits (obsolète), champ TOS 4 bits et champ réservé 1 bit (doit être défini sur 0). Le TOS 4 bits représente respectivement : un délai minimum, un débit maximum, une fiabilité maximale et un coût minimum. Ces quatre sont en conflit les uns avec les autres, et un seul peut être choisi. Pour des applications comme ssh/telnet, la latence minimale est plus importante ; pour des programmes comme ftp, le débit maximal est plus important.
Longueur totale de 16 bits (longueur totale) : combien d'octets sont occupés par le datagramme IP dans son ensemble.
Identification 16 bits (id) : identifie de manière unique le message envoyé par l'hôte. Si le paquet IP est fragmenté au niveau de la couche liaison de données, l'identifiant de chaque fragment est le même.
Champ d'indicateur de 3 bits : le premier bit est réservé (réservé signifie qu'il n'est pas utilisé maintenant, mais il peut être utilisé à l'avenir si je ne l'ai pas encore compris). Si le deuxième bit est 1, la fragmentation est interdite.A ce moment, si la longueur du paquet dépasse le MTU, le module IP rejettera le paquet. Le troisième bit signifie "plus de fragments". S'il est fragmenté, le dernier fragment est défini sur 0 et les autres sur 1. Similaire à une balise fermante.
Décalage de fragment de 13 bits (décalage de framegament) : C'est le décalage du fragment par rapport au début du paquet IP d'origine. En fait, il indique où se trouve le fragment courant dans le message d'origine. Le nombre réel d'octets décalés est obtenu par cette valeur * 8. Ainsi, à l'exception du dernier message, la longueur des autres messages doit être un entier multiple de 8 (sinon les messages ne sont pas continus).
Temps de vie 8 bits (Time To Live, TTL) : le nombre maximum de sauts pour qu'un datagramme atteigne sa destination. Habituellement 64. Chaque fois qu'une route est passée, TTL -= 1, jusqu'à ce qu'elle atteigne 0, elle est ignorée. Ce champ est principalement utilisé pour éviter les boucles de routage. Protocole 8 bits : Indique le type de protocole de couche supérieure.
Somme de contrôle d'en-tête 16 bits : utilisez le CRC pour vérifier si l'en-tête est endommagé.
Adresse source 32 bits et adresse destination 32 bits : indiquez l'expéditeur et le destinataire.

Protocoles clés de la couche transport et de la couche réseau des principes de réseau

Protocoles de clé de couche de transport

Protocole TCP