|
Entête TCP
Par _SebF
1 -
Définition du
protocole
2 -
Structure de l'entête
3 -
Mode de transfert
3.1 - Ouverture de session
3.2 -
Transfert des données
3.3 - Fermeture de session
3.4 -
Fermeture brutale de
connexion
4 -
La fenêtre coulissante
5 -
Définition des différents
champs
5.1 -
Port source
5.2 -
Port destination
5.3 -
Numéro de séquence
5.4 -
Numéro de l'accusé de réception
5.5 -
Offset
5.6 -
Réservé
5.7 -
Flags
5.8 -
Fenêtre
5.9 -
Checksum
5.10 -
Pointeur de donnée urgente
5.11 -
Options
5.12 -
Bourrage
6 - Discussion autour de la
documentation
7 -
Suivi du document
Le protocole TCP est basé en couche 4. Il ouvre une session et effectue lui-même
le control d'erreur. Il est alors appelé "mode connecté". Vous trouverez tous les détails du protocole TCP dans la
Rfc 793.
Voici la structure de l'entête TCP basé sur 20 octets.
Voici le complément de l'entête TCP qui est optionnelle basé sur 4 octets.
Voici les différents types de communication basés sur le mode connecté de TCP :
==> SYN=1 - ACK=0 - SeqNum=100 - AckNum=xxx
<== SYN=1 - ACK=1 - SeqNum=300 - AckNum=101
==> SYN=0 - ACK=1 - SeqNum=101 - AckNum=301
==> ACK=1 - SeqNum=101 - AckNum=301
- Data=30 octets
<== ACK=1 - SeqNum=301
- AckNum=131 - Data=10 octets
==> ACK=1
- SeqNum=131 - AckNum=311 - Data=5 octets
<== ACK=1 - SeqNum=311 - AckNum=136 - Data=10 octets
<== ACK=1 - FIN=1 - SeqNum=321 - AckNum=136
==> ACK=1 - FIN=0 - SeqNum=136 - AckNum=321
1ère cas possible :
==> ACK=1 - RST=0 - SeqNum=200 - AckNum=400
<== ACK=0 - RST=1 - SeqNum=400 - ACKNum=xxx
2nd cas possible :
<== ACK=0 - RST=0 - SeqNum=200 - Data=30 octets
==> ACK=0 - RST=1 - SeqNum=230 - Data=xxx
La fenêtre coulissante, plus connue sous le nom de
"Sliding Windows" est employée
pour transférer des données entre les hôtes. La fenêtre définit le volume de
données susceptibles d'être passées via une connexion TCP, avant que le récepteur
n'envoie un accusé de réception. Chaque ordinateur comporte une fenêtre
d'émission et une fenêtre de réception qu'il utilise pour buffériser les données
en continu, sans devoir attendre un accusé de réception pour chaque paquet. Cela
permet au récepteur de recevoir les paquets dans le désordre et de profiter des
délais d'attente pour réorganiser les paquets. La fenêtre émettrice contrôle les
données émises, si elle ne reçoit pas d'accusé de réception au bout d'un
certain temps, elle retransmet le paquet.
Considérations sur le débit :
TCP a été conçu pour offrir des
performances optimales en présence de conditions de liaison variées et les
systèmes d'exploitations comportent des améliorations telles que celles prenant
en charge la RFC 1323. Le débit réel d'une
liaison dépend d'un certain nombre de variables, mais les facteurs les plus
importants sont les suivants :
-
Vitesse de la liaison (bits par
seconde pouvant être transmis)
-
Retard de propagation
-
Dimension de la fenêtre (quantité de
données n'ayant pas fait l'objet d'un accusé de réception et qui peuvent
être en attente sur une connexion TCP)
-
Fiabilité de la liaison
-
Encombrement du réseau et des
périphériques intermédiaires
-
MTU du parcours
Voici quelques considérations
fondamentales sur le calcul du débit TCP :
La capacité d'un canal de communication est égale à la bande passante multipliée
par le temps de transmission aller-retour. Elle est connue sous le nom de
produit bande passante-retard. Si la liaison est fiable, pour obtenir des
performances optimales, la dimension de la fenêtre doit être supérieure ou égale
à la capacité du canal de communication, de manière à permettre à la pile
d'envoi de le remplir. La plus grande dimension de fenêtre pouvant être
spécifiée, en raison du champ de 16 bits de l'en-tête TCP, est de 65535. Des
fenêtres plus larges peuvent toutefois être négociées grâce au redimensionnement
des fenêtres.
Le débit ne peut jamais excéder la
taille de la fenêtre divisée par le temps de transmission aller-retour. Si la
liaison n'est pas fiable ou est encombrée et que des paquets sont perdus,
l'utilisation fenêtre de taille supérieure ne garantit pas nécessairement un
meilleur débit. Windows 2000 prend en charge non seulement le dimensionnement
des fenêtres, mais également les accusés de réception sélectifs (SACK, décrits
dans la RFC 2018) pour améliorer les performances au sein d'environnements qui
présentent des pertes de paquets. Il prend également en charge l'horodatage
(décrit dans la RFC 1323) pour une meilleure évaluation RTT.
Le retard de propagation dépend de la
vitesse de la lumière, des latences de l'équipement de transmission, etc. Le
retard de transmission dépend donc de la vitesse du support.
Pour un parcours spécifique, le retard
de propagation est fixe, mais le retard de transmission dépend de la taille du
paquet. À des vitesses réduites, le retard de transmission constitue un facteur
limitatif. À des vitesses élevées, le retard de propagation peut devenir un
facteur de limitation.
En résumé, les piles TCP/IP peuvent
s'adapter à la plupart des conditions de réseau et fournir dynamiquement le
meilleur débit et la meilleure fiabilité possibles pour chaque connexion. Les
essais de mise au point manuelle sont souvent contre-productifs, sauf lorsqu'un
ingénieur réseau qualifié procède préalablement à une étude précise du flux de
données.
Le champ Port source est codé sur 16 bits et correspond au port relatif à l'application en
cours sur la machine source.
Le champ
Port destination est codé sur 16 bits et correspond au port relatif à l'application en
cours sur la machine de destination.
Vous trouverez
la liste des
ports TCP officialisées par l'IANA,
organisation gérant mondialement les adressage IP.
Le
champ Numéro de séquence est codé sur 32 bits et correspond au numéro du paquet. Cette valeur permet de situer à quel endroit du flux de
données le paquet, qui est arrivé, doit se situer par rapport aux autres paquets.
Le champ Numéro de séquence est codé sur 32 bits et définit un
acquittement pour les paquets reçus. Cette valeur signale le prochain numéro de
paquet attendu. Par exemple, si il vaut
1500, cela signifie que tous les Datagrammes <1500 ont été reçus
Le champ Offset est codé sur 4 bits et définit le nombre de mots de 32 bits
dans l'entête TCP. Ce champ indique donc où les données commencent.
Le champ Réservé est
codé sur 6 bits et il servira pour des besoins futurs. Ce champ doit
être marqué à 0. Au jour d'aujourd'hui, on peut considérer que les besoins
futurs se transforment en un champ non utilisé.
-
Le champ URG est codé sur 1 bit et indique que le champ
Pointeur de donnée
urgente est utilisé.
- Le champ ACK est codé sur 1 bit et indique que le numéro
de séquence pour les acquittements est valide.
- Le champ PSH est codé sur 1 bit
et indique au récepteur de délivrer les données à l'application et de ne
pas attendre le remplissage des tampons.
- Le champ RST est codé sur 1 bit et demande la réinitialisation de la connexion.
- Le champ SYN
est codé sur 1 bit et indique la synchronisation des numéros de séquence.
- Le champ FIN
est codé sur 1 bit et indique fin de transmission.
Le champ Fenêtre
"Windows" est codé sur 16 bits et correspond au nombre d'octets à partir de la position marquée dans l'accusé de
réception que le récepteur est capable de recevoir. Le
destinataire ne doit donc pas envoyer les paquets après
Numéro de séquence + Window.
Le champ Checksum est codé sur 16 bits et représente la validité du paquet
de la couche 4 TCP.
Le Checksum est constitué en calculant le complément à 1 sur 16 bits de la somme
des compléments à 1 des octets de l'en-tête et des données pris deux par deux
(mots de 16 bits). Si le message entier contient un nombre impair d'octets, un 0
est ajouté à la fin du message pour terminer le calcul du Checksum. Cet octet
supplémentaire n'est pas transmis. Lors du calcul du Checksum, les positions des
bits attribués à celui-ci sont marquées à 0.
Le Checksum couvre de plus, une pseudo en-tête de 96 bits préfixée à l'en-tête TCP. Cette pseudo en-tête comporte les adresses Internet sources et
destinataires, le
type de protocole et la longueur du message TCP
(incluant la data). Ceci protège
TCP contre les erreurs de routage.
La longueur TCP compte le nombre d'octets de l'en-tête TCP et des données du
message, en excluant les 12 octets de la pseudo en-tête.
Voici un exemple de fonction permettant le calcul du checksum TCP. Elle est
identique à celle de UDP.
|
struct pseudo_entete
{
unsigned long ip_source;
// Adresse ip source
unsigned long ip_destination;
// Adresse ip destination
char mbz;
// Champs à 0
char type;
// Type de protocole (6->TCP et 17->UDP)
unsigned short length;
// htons( Taille de l'entete Pseudo + Entete TCP
ou UDP + Data )
};
unsigned short calcul_du_checksum(bool
liberation, unsigned short *data,
int taille)
{
unsigned long checksum=0;
//
********************************************************
// Complément à 1 de la somme des complément à 1 sur 16 bits
// ********************************************************
while(taille>1)
{
if (liberation==TRUE)
liberation_du_jeton(); // Rend la main à la fenêtre
principale
checksum=checksum+*data++;
taille=taille-sizeof(unsigned
short);
}
if(taille)
checksum=checksum+*(unsigned
char*)data;
checksum=(checksum>>16)+(checksum&0xffff);
checksum=checksum+(checksum>>16);
return (unsigned
short)(~checksum);
}
unsigned short calcul_du_checksum_tcp(bool
liberation, unsigned long ip_source_tampon,
unsigned long ip_destination_tampon,
struct tcp tcp_tampon, char data_tampon[65535])
{
struct pseudo_entete pseudo_tcp;
char tampon[65535];
unsigned short checksum;
//
********************************************************
// Initialisation du checksum
// ********************************************************
tcp_tampon.checksum=0; // Doit être à 0
pour le calcul
//
********************************************************
// Le calcul du Checksum TCP (Idem à UDP)
// ********************************************************
// Le calcul passe par une pseudo entete TCP + l'entete TCP +
les Data
pseudo_tcp.ip_source=ip_source_tampon;
pseudo_tcp.ip_destination=ip_destination_tampon;
pseudo_tcp.mbz=0;
pseudo_tcp.type=IPPROTO_TCP;
pseudo_tcp.length=htons((unsigned short)(sizeof(struct
tcp)+strlen(data_tampon)));
memcpy(tampon,&pseudo_tcp,sizeof(pseudo_tcp));
memcpy(tampon+sizeof(pseudo_tcp),&tcp_tampon,sizeof(struct
tcp));
memcpy(tampon+sizeof(pseudo_tcp)+sizeof(struct
tcp),data_tampon,strlen(data_tampon));
checksum=calcul_du_checksum(liberation,(unsigned
short*)tampon,sizeof(pseudo_tcp)+sizeof(struct
tcp)+strlen(data_tampon));
return(checksum);
} |
Le champ Pointeur de donnée urgente est codé sur 16 bits et communique la position d'une donnée urgente en
donnant son décalage par rapport au
numéro de séquence. Le pointeur doit pointer
sur l'octet suivant la donnée urgente. Ce champ n'est interprété que lorsque le
Flag URG
est marqué à 1. Dès que cet octet est reçu, la pile TCP doit envoyer les données à
l'application.
Les champs d'options peuvent occuper un espace de taille variable à la fin de
l'en-tête TCP. Ils formeront toujours un multiple de 8 bits. Toutes les options
sont prises en compte par le
Checksum. Un paramètre d'option commence toujours
sur un nouvel octet. Il est défini deux formats types pour les options:
- Cas 1
- Option mono-octet.
- Cas 2 - Octet de type d'option, octet de longueur d'option, octet de valeur
d'option.
La longueur d'option prend en compte l'octet de type, l'octet de longueur
lui-même et tous les octets de valeur et est exprimée en octet.
La liste
d'option peut être plus courte que ce que l'offset de données pourrait le faire
supposer. Un octet de remplissage "Bourrage" devra être dans ce cas rajouté
après le code de fin d'options.
Le champ
Bourrage est de taille variable comprise entre 0 et 7 bits. Il permet de combler
le champ option afin d'obtenir une entête TCP multiple de 32 bits. La valeur des
bits de bourrage est 0.
Vous pouvez poser toutes vos questions,
vos remarques et vos expériences à propos de l'entête TCP. Pour cela,
rendez-vous sur le
Forum
"TCP-IP".
Le 21 décembre 2007, par _SebF, ajout du
paragraphe "Considérations sur le débit" dans le chapitre 4 "La
fenêtre coulissante"
Le 12 mars 2004, par _SebF, ajout de la référence aux
port TCP assignés par l'Iana.
Le 15 novembre 2003, par _SebF, ajout du schéma de la pseudo entête.
Le 29 septembre 2003, par _SebF, création du document.
|