Introduction graphique aux protocoles TCP, UDP et IP en Java

Cet article présente principalement en détail les informations pertinentes sur l'analyse des protocoles TCP, UDP et IP. Il a une certaine valeur de référence. Les amis intéressés peuvent s'y référer

Au début d'Internet, l'hôte. L'interconnexion entre eux utilise le protocole NCP. Ce protocole lui-même présente de nombreux défauts, tels que : il ne peut pas interconnecter différents hôtes, il ne peut pas interconnecter différents systèmes d'exploitation et il n'a pas de fonction de correction d'erreurs. Afin de remédier à cette lacune, Daniel a imaginé le protocole TCP/IP. Presque tous les systèmes d'exploitation implémentent désormais la pile de protocoles TCP/IP.

La pile de protocoles TCP/IP est principalement divisée en quatre couches : couche application, couche transport, couche réseau et couche liaison de données. Chaque couche a un protocole correspondant, comme indiqué ci-dessous

<.>

Le soi-disant protocole est un format de transmission de données entre les deux parties. Il existe de nombreux protocoles utilisés sur le réseau et, heureusement, chaque protocole possède un document RFC. Ici, nous effectuons uniquement une analyse des en-têtes des protocoles IP, TCP et UDP.

Tout d'abord, examinons le format d'un paquet Ethernet dans le réseau :

Dans le système d'exploitation Linux, Lorsque nous voulons envoyer des données, il nous suffit de préparer les données dans la couche supérieure, puis de les soumettre à la pile de protocoles du noyau, et la pile de protocoles du noyau ajoute automatiquement l'en-tête de protocole correspondant. Jetons un coup d'œil au contenu spécifique de l'en-tête de protocole ajouté à chaque couche.

1. Protocole TCP

Le protocole TCP est orienté connexion et garantit une grande fiabilité (pas de perte de données, pas de désordre de données, pas d'erreur de données ), pas d'arrivée de données en double) protocole de couche transport.

1.Analyse de l'en-tête TCP

Analysons d'abord le format de l'en-tête TCP et la signification de chaque champ :

(1) Numéro de port [16 bits]

Nous savons que le réseau met en œuvre une communication inter-processus entre différents hôtes. Dans un système d'exploitation, il existe de nombreux processus. Lorsque les données arrivent, quel processus doit leur être soumis pour traitement. Cela nécessite l'utilisation de numéros de port. Dans l'en-tête TCP, il y a le numéro de port source (Source Port) et le numéro de port de destination (Destination Port). Le numéro de port source identifie le processus de l'hôte expéditeur et le numéro de port de destination identifie le processus de l'hôte récepteur.

(2) Numéro de séquence [32 bits]

Le numéro de séquence est divisé en numéro de séquence d'envoi (numéro de séquence) et numéro de séquence de confirmation (numéro d'accusé de réception).

Numéro de séquence d'envoi : utilisé pour identifier le flux d'octets de données envoyé de la source TCP à la destination TCP. Il représente le numéro de séquence du premier octet de données de ce segment de message. Si vous considérez un flux d'octets comme un flux unidirectionnel entre deux applications, TCP compte chaque octet avec un numéro de séquence. Le numéro de série est un numéro non signé de 32 bits. Le numéro de série commence à 0 après avoir atteint 2 32-1. Lorsqu'une nouvelle connexion est établie, le flag SYN passe à 1 et le champ numéro de séquence contient le numéro de séquence initial ISN (Initial Sequence Number) sélectionné par cet hôte pour la connexion.

Numéro de séquence de confirmation : contient le prochain numéro de séquence que l'expéditeur de la confirmation s'attend à recevoir. Par conséquent, le numéro de séquence de confirmation doit être le numéro de séquence du dernier octet de données reçu avec succès plus 1. Le champ du numéro de séquence de confirmation n’est valide que lorsque l’indicateur ACK est 1. TCP fournit des services full-duplex à la couche application, ce qui signifie que les données peuvent être transmises indépendamment dans les deux sens. Par conséquent, chaque extrémité de la connexion doit conserver le numéro de séquence des données transmises dans chaque direction.

(3) Décalage [4 bits]

Le décalage ici fait en fait référence à la longueur de l'en-tête TCP, qui est utilisé pour indiquer la longueur du 32 bits mot dans le numéro d'en-tête TCP, grâce auquel vous pouvez savoir où commencent les données utilisateur d'un paquet TCP. Ce champ occupe 4 bits. Si la valeur de 4 bits est 0101, cela signifie que la longueur de l'en-tête TCP est de 5 * 4 = 20 octets. La longueur maximale de l'en-tête TCP est donc de 15 * 4 = 60 octets. Cependant, il n'y a pas de champs facultatifs et la longueur normale est de 20 octets.

(4)Réservé [6bit]

n'est actuellement pas utilisé, sa valeur est 0

(5) Indicateur [6bit]

Il y a 6 bits d'indicateur dans l'en-tête TCP. Plusieurs d’entre eux peuvent être réglés sur 1 en même temps.

URG Le pointeur urgent est valide

ACK Confirme que le numéro de séquence est valide

PSH Indique que le récepteur doit transmettre ce segment à la couche application dès que possible sans Attendre que le tampon soit rempli

RST signifie généralement déconnecter une connexion

Par exemple : un client TCP initie une connexion vers un serveur qui n'a pas de port d'écoute, et Wirshark capture le paquet comme suit

Vous pouvez voir que l'hôte : 192.168.63.134 lance une demande de connexion à l'hôte : 192.168.63.132, mais l'hôte : 192.168.63.132 est pas du côté du serveur qui écoute le port correspondant. Ceci lorsque

hôte : 192.168.63.132 envoie un paquet TCP avec RST configuré pour se déconnecter.

SYN Le numéro de séquence de synchronisation est utilisé pour initier une connexion

FIN L'expéditeur termine la tâche d'envoi (c'est-à-dire déconnecte la connexion)

(6)Taille de la fenêtre (fenêtre) [16bit]

La taille de la fenêtre, indiquant le nombre maximum d'octets que la méthode source peut accepter. .

(7) Somme de contrôle [16 bits]

La somme de contrôle couvre l'intégralité du segment du message TCP : en-tête TCP et données TCP. Il s'agit d'un champ obligatoire qui doit être calculé et stocké par l'expéditeur et vérifié par le destinataire.

(8) Pointeur d'urgence [16bit]

Le pointeur d'urgence n'est valide que lorsque le drapeau URG est réglé sur 1. Le pointeur urgent est un décalage positif, ajouté à la valeur dans le champ du numéro de séquence, pour représenter le numéro de séquence du dernier octet de données urgentes. Le mode d'urgence de TCP permet à l'expéditeur d'envoyer des données urgentes à l'autre extrémité.

(9) L'option TCP

est facultative, nous y jetterons un oeil lors de la capture des paquets plus tard

2 . Détails clés

(1) Prise de contact à trois pour établir la connexion

a L'extrémité requérante (généralement appelée le client) envoie un segment SYN à. indiquez le client Le port du serveur auquel vous souhaitez vous connecter et le numéro de séquence initial (ISN, dans ce cas 1415531521). Ce segment SYN est le segment de message 1.
b. Le serveur renvoie un segment SYN (segment 2) contenant le numéro de séquence initial du serveur en réponse. En même temps, le numéro de séquence de confirmation est défini sur l'ISN du client plus 1 pour confirmer le segment de message SYN du client. Un SYN occupera un numéro de séquence
c. Le client doit définir le numéro de séquence de confirmation à l'ISN du serveur plus 1 pour confirmer le segment SYN du serveur (segment 3)
Ces trois segments complètent la connexion d'établissement. Ce processus est également appelé poignée de main à trois

Utilisez Wirshark pour capturer les paquets comme suit :

Vous pouvez voir que la poignée de main à trois détermine le numéro de séquence des paquets entre les deux parties, la taille maximale des données reçues (fenêtre) et le MSS (taille maximale du segment).
MSS = MTU - En-tête IP - En-tête TCP. Nous en parlerons lors de l'analyse de l'en-tête IP. Elle fait généralement 1500 octets. L'en-tête IP et l'en-tête TCP font 20 octets avec des options facultatives. Dans ce cas MSS=1500 - 20 -20 = 1460.

MSS limite la taille des données transportées par les paquets TCP. Cela signifie que lorsque la couche application soumet des données à la couche transport pour transmission via le protocole TCP, si les données de la couche application > MSS, elle doit le faire. être segmenté, divisé en plusieurs segments et envoyé un par un.

Par exemple : la couche application soumet 4096 octets de données à la couche transport à la fois, l'effet de capture de paquets via Wirshark est le suivant :

Les trois premières fois sont le processus de prise de contact à trois, et les trois fois suivantes sont le processus de transmission des données. Puisque la taille des données est de 4 096 octets, la transmission prend trois fois (1 448). + 1448 + 1200). Les personnes prudentes se demanderont pourquoi la taille maximale des données transmises à chaque fois n'est pas de 1 460 octets ? Parce que TCP comporte ici des options facultatives, la longueur de l'en-tête TCP = 20 + 12 (taille de l'option facultative) = 32 octets. Les données maximales pouvant être transmises de cette manière sont : 1 500 - 20 - 32 = 1 448 octets.

(2) Faites quatre vagues pour vous déconnecter

a. La communication réseau actuelle est basée sur les sockets. Lorsque le client ferme son propre socket, la pile de protocoles du noyau s'active automatiquement. envoyer un paquet avec FIN défini au serveur, demandant la déconnexion. Nous appelons en premier la partie qui initie la demande de déconnexion la partie active de déconnexion.

b. Une fois que le serveur a reçu la demande de déconnexion FIN du client, la pile de protocoles du noyau enverra immédiatement un paquet ACK en réponse, indiquant que la demande du client a été reçue
c. pendant un certain temps, il s'éteint lui-même. À ce stade, la pile de protocoles du noyau enverra un paquet FIN au client, demandant la déconnexion
d Une fois que le client aura reçu la demande de déconnexion FIN du serveur, il enverra un ACK en réponse, indiquant la demande de. le serveur a été reçu

Utilisez wirshar pour capturer le paquet et l'analyser comme suit :

(3) Garantie de fiabilité TCP

TCP utilise une technologie appelée « accusé de réception positif avec retransmission » comme base pour fournir des services de transmission de données fiables. Cette technologie nécessite que le récepteur renvoie les informations de confirmation ACK à la station source après avoir reçu les données. L'expéditeur conserve une trace de chaque paquet envoyé et attend la confirmation avant d'envoyer le paquet suivant. L'expéditeur démarre également un temporisateur lors de l'envoi du paquet et renvoie le paquet qui vient d'être envoyé lorsque le temporisateur expire mais que les informations d'accusé de réception ne sont pas arrivées. La figure 3-5 montre la situation de transmission de données du protocole d'accusé de réception positif avec fonction de retransmission, et la figure 3-6 montre le délai d'attente et la retransmission provoqués par la perte de paquets. Afin d'éviter les accusés de réception tardifs et les accusés de réception en double dus aux retards du réseau, le protocole stipule que les informations d'accusé de réception contiennent un numéro de séquence de paquet afin que le récepteur puisse associer correctement le paquet à l'accusé de réception.

Comme le montre la figure 3-5, bien que le réseau ait la capacité d'effectuer une communication bidirectionnelle en même temps, puisque l'envoi du prochain paquet doit être reporté avant de recevoir les informations de confirmation du paquet précédent, le simple protocole de confirmation positive. Une grande partie de la précieuse bande passante du réseau est gaspillée. À cette fin, TCP utilise un mécanisme de fenêtre glissante pour améliorer le débit du réseau tout en résolvant le contrôle de flux de bout en bout.

(4) Technologie de fenêtre coulissante

La technologie de fenêtre coulissante est un simple mécanisme de confirmation positive avec retransmission Un mécanisme plus complexe variante qui permet à l'expéditeur d'envoyer plusieurs paquets avant d'attendre un accusé de réception. Comme le montre la figure 3-7, l'expéditeur souhaite envoyer une séquence de paquets. Le protocole de fenêtre glissante place une fenêtre de longueur fixe dans la séquence de paquets, puis envoie tous les paquets dans la fenêtre lorsque l'expéditeur reçoit le message d'un paquet ; les informations de confirmation sont reçues, elles peuvent reculer et envoyer le paquet suivant ; à mesure que les confirmations continuent d'arriver, la fenêtre continue de reculer.

2. Protocole UDP

Le protocole UDP est également un protocole de connexion de couche transport. , des protocoles de couche transport qui ne garantissent pas la fiabilité. Son en-tête de protocole est relativement simple, comme suit :

Le numéro de port ici n'est pas expliqué, il a la même signification que le numéro de port TCP.

Length occupe 2 octets et identifie la longueur de l'en-tête UDP. Somme de contrôle : somme de contrôle, y compris l'en-tête UDP et les parties de données.

3. Protocole IP

IP est le protocole principal de la famille des protocoles TCP/IP. Toutes les données TCP, UDP, ICMP et IGMP sont transmises au format datagramme IP. Ses caractéristiques sont les suivantes :
Peu fiable (peu fiable) signifie qu'il ne peut pas garantir que le datagramme IP puisse atteindre avec succès la destination. IP ne fournit que les meilleurs services de transmission. Si une erreur se produit, par exemple si un routeur manque temporairement de mémoire tampon, IP dispose d'un algorithme de gestion des erreurs simple : supprimez le datagramme, puis envoyez un message ICMP à la source. Toute fiabilité requise doit être fournie par les couches supérieures (telles que TCP).

Le terme sans connexion signifie qu'IP ne conserve aucune information d'état sur les datagrammes ultérieurs. Chaque datagramme est traité indépendamment les uns des autres. Cela signifie également que les datagrammes IP peuvent être reçus dans le désordre dans l'ordre dans lequel ils ont été envoyés. Si une source envoie deux datagrammes consécutifs (d'abord A, puis B) au même récepteur, chaque datagramme est acheminé indépendamment, en empruntant éventuellement un itinéraire différent, de sorte que B peut arriver avant l'arrivée de A.

1. Format d'en-tête IP

(1) La version occupe 4 chiffres et fait référence au Version du protocole IP. Les versions du protocole IP utilisées par les deux parties communicantes doivent être cohérentes. Le numéro de version du protocole IP actuellement largement utilisé est 4 (IPv4). Concernant IPv6, il est encore au stade de projet.

(2) La longueur de l'en-tête occupe 4 chiffres et la valeur décimale maximale représentable est de 15. Veuillez noter que l'unité du nombre représenté par ce champ est une longueur de mot de 32 bits (une longueur de mot de 32 bits est de 4 octets). Par conséquent, lorsque la longueur de l'en-tête IP est de 1 111 (c'est-à-dire 15 en décimal), l'en-tête est défini sur 32 bits. la longueur atteint 60 octets. Lorsque la longueur de l'en-tête du paquet IP n'est pas un multiple entier de 4 octets, il doit être rempli avec le dernier champ de remplissage. Par conséquent, la partie données commence toujours par un multiple entier de 4 octets, ce qui est plus pratique lors de la mise en œuvre du protocole IP. L’inconvénient de limiter la longueur de l’en-tête à 60 octets est que cela peut ne pas être suffisant dans certains cas. Mais cela est fait dans l’espoir que les utilisateurs minimisent les frais généraux. La longueur d'en-tête la plus couramment utilisée est de 20 octets (c'est-à-dire que la longueur d'en-tête est 0101) et aucune option n'est utilisée pour le moment.

(3) Services différenciés : 8 bits sont utilisés pour obtenir de meilleurs services. Ce champ était appelé type de service dans l’ancienne norme, mais n’a jamais été utilisé en pratique. En 1998, l'IETF a renommé ce domaine DS (Differentiated Services). Ce champ ne prend effet que lors de l'utilisation de services différenciés.

(4) Longueur totale La longueur totale fait référence à la longueur de l'en-tête et des données, en octets. Le champ de longueur totale est de 16 bits, donc la longueur maximale du datagramme est de 216-1 = 65 535 octets.

Chaque couche de liaison de données située sous la couche IP possède son propre format de trame, qui inclut la longueur maximale du champ de données dans le format de trame, appelée unité de transfert maximale (MTU). Lorsqu'un datagramme est encapsulé dans une trame de couche liaison, la longueur totale du datagramme (c'est-à-dire l'en-tête plus la partie données) ne doit pas dépasser la valeur MTU de la couche liaison de données sous-jacente.

(5) L'identification (identification) occupe 16 chiffres. Le logiciel IP maintient un compteur en mémoire. Chaque fois qu'un datagramme est généré, le compteur est incrémenté de 1 et cette valeur est affectée au champ d'identification. Mais cette « identification » n’est pas un numéro de séquence, car IP est un service sans connexion, et il n’y a aucun problème de réception des datagrammes dans l’ordre. Lorsqu'un datagramme doit être fragmenté car sa longueur dépasse le MTU du réseau, la valeur de ce champ d'identification est copiée dans le champ d'identification de tous les datagrammes. La même valeur de champ d'identification permet à chaque fragment de datagramme fragmenté d'être correctement réassemblé dans le datagramme d'origine.

(6) Flag (drapeau) occupe 3 chiffres, mais actuellement seuls 2 chiffres ont un sens.

●Le bit le plus bas dans le champ du drapeau est enregistré comme MF (More Fragment). MF=1 signifie qu'il y aura des datagrammes "fragmentés" plus tard. MF=0 signifie qu'il s'agit du dernier de plusieurs fragments de datagramme

● Le bit au milieu du champ du drapeau est enregistré comme DF (Don't Fragment), ce qui signifie "ne peut pas être fragmenté". La fragmentation n'est autorisée que lorsque DF=0.

(7) le décalage de tranche occupe 13 bits. Le décalage de tranche souligne : après la fragmentation d'un paquet plus long, la position relative d'une certaine tranche dans le paquet d'origine. C'est-à-dire l'endroit où commence la tranche par rapport au point de départ du champ de données utilisateur. Le décalage de tranche est exprimé en unités de décalage de 8 octets. Cela signifie que la longueur de chaque fragment doit être un multiple entier de 8 octets (64 bits).

(8) Time to Live occupe 8 bits. L'abréviation anglaise couramment utilisée du champ time to live est TTL (Time To Live), qui indique la durée de vie du datagramme dans le réseau. Ce champ est défini par l'origine du datagramme. Son objectif est d'empêcher que des datagrammes non distribuables circulent indéfiniment sur Internet, consommant ainsi en vain les ressources du réseau. La conception originale consistait à utiliser les secondes comme unité de TTL. Chaque fois qu'il passe par un routeur, le TTL est soustrait de la période de temps consommée par le datagramme dans le routeur. Si le datagramme prend moins d'1 seconde au niveau du routeur, la valeur TTL est décrémentée de 1. Lorsque la valeur TTL est 0, le datagramme est ignoré.

(9) Protocole Occupe 8 bits. Le champ protocole indique quel protocole est utilisé pour les données transportées dans ce datagramme, afin que la couche IP de l'hôte de destination sache quel processus de traitement la partie données doit être transmise. .

(10) La première somme de contrôle occupe 16 places. Ce champ vérifie uniquement l'en-tête du datagramme, mais pas la partie données. En effet, chaque fois qu'un datagramme passe par un routeur, celui-ci doit recalculer la somme de contrôle de l'en-tête (certains champs, tels que la durée de vie, les indicateurs, les décalages de fragments, etc., peuvent changer). Ne pas vérifier certaines parties des données réduit l’effort de calcul.

(11) L’adresse IP source occupe 32 bits.

(12) L'adresse IP de destination occupe 32 bits.

2. Explication de la fragmentation

La fragmentation signifie que lorsque les données à transmettre sont supérieures à l'unité de transmission maximale (MTU), elles sont nécessaire Divisez-le en plusieurs paquets et envoyez-les à l'autre partie un par un. Quand on parle de TCP, lorsqu'il s'agit de MSS, beaucoup de gens ne parviennent pas à les distinguer. A travers l'image ci-dessous, je pense qu'on peut tout à fait les distinguer.

Personnellement, je pense que si les données sont transmises via le protocole TCP, la fragmentation n'est certainement pas nécessaire lorsqu'elles atteignent la couche IP. La fragmentation n'est requise que lors de la transmission de données volumineuses via le protocole UDP.
Par exemple : utilisez le protocole UDP pour transmettre 10 240 octets de données

Vous pouvez le voir, mais lorsque les données sont soumises à la couche réseau, car les données dépassent le maximum. L'unité de transmission est fragmentée. Divisez-le en plusieurs paquets et envoyez-les à l'autre partie via le protocole IP. L'octet maximum de chaque paquet est MTU - en-tête IP = 1 500 - 20 = 1 480.

4. En-tête Ethernet

Il se compose de trois parties : source Adresse MAC | Adresse MAC de destination | Le protocole utilisé.

Ainsi en Ethernet, les formats des paquets de données sont les suivants :

Le protocole ARP obtient l'adresse MAC correspondante via l'adresse IP, appelée protocole de résolution d'adresse

Le protocole RARP obtient l'adresse IP correspondante via l'adresse MAC, appelée protocole de résolution d'adresse inversée

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!