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

1 - Définition du protocole

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.

2 - Structure de l'entête

Voici la structure de l'entête TCP basé sur 20 octets.

TCPIP IPV6 VOIP VPN IP IPV4

Voici le complément de l'entête TCP qui est optionnelle basé sur 4 octets.

TCPIP IPV6 VOIP VPN IP IPV4

3 - Mode de transfert

Voici les différents types de communication basés sur le mode connecté de TCP :

3.1 - Ouverture de session

==> SYN=1 - ACK=0 - SeqNum=100 - AckNum=xxx
<== SYN=1 - ACK=1 - SeqNum=300 - AckNum=101
==> SYN=0 - ACK=1 - SeqNum=101 - AckNum=301

3.2 - Transfert des données

==> 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

3.3 - Fermeture de session

<== ACK=1 - FIN=1 - SeqNum=321 - AckNum=136
==> ACK=1 - FIN=0 - SeqNum=136 - AckNum=321

3.4 - Fermeture brutale de connexion

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

4 - La fenêtre coulissante

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.

5 - Définition des différents champs

5.1 - Port source

Le champ Port source est codé sur 16 bits et correspond au port relatif à l'application en cours sur la machine source.

5.2 - Port destination

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.

5.3 - Numéro de séquence

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.

5.4 - Numéro de l'accusé de réception

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

5.5 - Offset

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.

5.6 - Réservé

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é.

5.7 - Flags

- 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.

5.8 - Fenêtre

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.

5.9 - Checksum

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.

TCPIP IPV6 VOIP VPN IP IPV4

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);
    }

5.10 - Pointeur de donnée urgente

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.

5.11 - Options

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.

5.12 - Bourrage

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.

6 - Discussion autour de la documentation

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".

7 - Suivi du document

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.

 



mot clé : accuse garantie bourrage tous sur tcp mode connecte ack reponse tcp requete tcp frame tcp protocol tcp fenetre synack control entete tcp donnee adresse tcp vpn resolution tcp transfert des donnees decouverte tcp liaison tcp tout sur tcp voip comprendre tcp datagramme transfert Port reserve fermeture de session fiable negociation tcp datatgrame tcp ouverture de session rst ip numéro de sequence source syn fermeture brutale de connexion tcpip pointeur fin numero rfc 793 champs urgente destination ipv4 flags la fenetre coulissante mode ipv6 trame tcp definition protocole tcp reception offset options datagramme tcp sliding window connaitre tcp couche 4

Copyright © 2011-2015 FrameIP TcpIP. Tous droits réservés. Les marques et marques commerciales mentionnées appartiennent à leurs propriétaires respectifs. L'utilisation de ce site Web TcpIP implique l'acceptation des conditions d'utilisation et du règlement sur le respect de la vie privée.
Sécurité entreprise Téléphonie entreprise Expert de votre Infrastructure Test ADSL Serinya Operateur Telecom