Transport de l'information avec TCP/IP

Philippe Latu
philippe.latu(at)linux-france.org
http://www.linux-france.org/prj/inetdoc/
Historique des versions $Revision: 1.3 $ Anne universitaire 2004-2005 $Date: 2004/09/20 20:26:19 $ PL

Table des matires

1. Copyright et Licence ....................................................................................................................... 1 1.1. Meta-information ................................................................................................................. 1 2. Les couches rseau & transport ........................................................................................................ 2 3. Le protocole IP de la couche rseau .................................................................................................. 2 4. Les protocoles TCP & UDP de la couche transport ............................................................................. 3 4.1. Le protocole TCP ................................................................................................................ 4 4.2. Le fonctionnement du protocole TCP ..................................................................................... 5 4.2.1. La segmentation des donnes ...................................................................................... 5 4.2.2. L'tablissement de la connexion .................................................................................. 5 4.2.3. Contrle de flux ........................................................................................................ 5 4.2.4. fentrage .................................................................................................................. 6 4.3. Le protocole UDP ................................................................................................................ 6

1. Copyright et Licence
Copyright (c) 2000,2005 Philippe Latu. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License".

Copyright (c) 2000,2005 Philippe Latu. Permission est accorde de copier, distribuer et/ou modifier ce document selon les termes de la Licence de Documentation Libre GNU (GNU Free Documentation License), version 1.1 ou toute version ultrieure publie par la Free Software Foundation ; sans Sections Invariables ; sans Texte de Premire de Couverture, et sans Texte de Quatrime de Couverture. Une copie de la prsente Licence est incluse dans la section intitule Licence de Documentation Libre GNU .

1.1. Meta-information
Cet article est crit avec DocBook1 XML sur un systme Debian GNU/Linux2. Il est disponible en version imprimable aux formats PDF et Postscript : transport.pdf3|transport.ps.gz4.

1 2

http://www.docbook.org http://www.debian.org 3 http://www.linux-france.org/prj/inetdoc/telechargement/transport.pdf 4 http://www.linux-france.org/prj/inetdoc/telechargement/transport.ps.gz

$Revision: 1.3 $

Transport de l'information avec TCP/IP

2. Les couches rseau & transport

Avec le succs des services Internet (noms de domaines, courrier, Web,forums, etc.) et l'echec des couches hautes du modle OSI5 , les couches rseau & transport du modle TCP/IP5 occupent une position charnire entre le traitement de l'information (les couches hautes ou services) et son transport (les couches basses). Baptiser une modlisation du nom de ses protocoles n'est pas trs acadmique. Le principe d'un modle est de dcrire ce qui doit tre fait et non comment ce doit tre fait. Or, par dfinition, un protocole dcrit comment une srie d'opration doit tre ralise. Cette transgression est justife par le fait que toute la philosophie du fonctionnement de l'Internet est rsume dans les 2 protocoles TCP & IP.

3. Le protocole IP de la couche rseau

En reprenant la dfinition militaire de l'ARPANET, le rseau Internet devait permettre de communiquer d'un point un autre quel que soit l'tat du rseau. Une partie de l'infrasctructure pouvait tre dtruite par une frappe nuclaire et les communications devaient tre maintenues dans n'importe quelles conditions. C'est ce mode de fonctionnement qui a conduit un inter-rseau en mode non connect sans aucune hirarchie. En effet, si le point de supervision d'un rseau hirarchis est touch, toute communication entre les niveaux infrieurs est perdue. Le fonctionnement du protocole IP a t dcrit dans le document : RFC 7916

Version : 4 bits Version du protocole IP code sur 4 bits : 0100 pour IPv4 et 0110 pour IPv6. Internet Header Length : 4 bits, IHL Longueur de l'en-tte en mots de 32 bits. Cette valeur est utilise pour distinguer la partie en-tte de la partie donnes du paquet. La reprsentation usuelle de l'en-tte se fait sur 32 bits de largeur. Comme les champs Options et Padding ne sont pas obligatoires, la valeur minimum du champ IHL est 5 (0101). Type Of Service : 8 bits, TOS Champ dcoup en 2 parties. Les 3 premiers bits sont appels precedence et les 5 derniers reprsententle type de service. La dfinition d'origine prvoyait 3 choix : low-delay, high-reliability et high-throughput. Ce marquage des paquets est utilisable pour dfinir des flux prioritaires. Voir Gestionnaires de mise en file d'attente simples, sans classes7. Sur l'Internet, les routeurs ne tiennent gnralement pas compte de ce champ. Total Length : 16 bits Longueur du datagramme : en-tte & donnes. La taille minimum est de 21 octets (en-tte + 1 octet de donne). Comme se champ est reprsent sur 16 bits, la taille maximum est de 2^16 - 1, soit 64 Ko. Identification : 16 bits Chaque paquet IP reoit un numro d'identification sa cration. Il est possible qu'un paquet soit dcoup en

5 6

Lire l'article Modlisations rseau [http://www.linux-france.org/prj/inetdoc/articles/modelisation/]. http://www.faqs.org/rfcs/rfc791.html 7 http://www.linux-france.org/prj/inetdoc/guides/lartc/lartc.qdisc.classless.html

$Revision: 1.3 $

Transport de l'information avec TCP/IP fragments avant d'atteindre sa destination finale. Chaque fragment appartient au mme paquet IP. Chaque fragment possde le mme numro d'identification. Flags : 3 bits Ce champ contient 3 indicateurs d'tat : Reserved flag : doit toujours tre 0. Don't Fragment (DF) : 0 si le paquet peut tre fragment ; 1 s'il ne doit pas tre fragment. More Fragments (MF) : 1 si d'autres fragments sont attendus ; 0 s'il n'y a pas/plus de fragments. Fragment Offset : 13 bits Position du fragment dans le datagramme courant. Cette position est compte en octets. Time To Live : 8 bits, TTL Ce compteur est dcrment chaque traverse de routeur. Si la valeur 0 est atteinte, le paquet est jet. Cela signifie qu'il ne peut tre dlivr sa destination finale. La valeur initiale du champ TTL dpend du systme d'exploitation utilis. Protocol : 8 bits Ce champ spcifie le protocole utilis dans les donnes du paquet IP. Par exemple, la valeur 1 indique que le protocole utilis est ICMP. On sait ainsi que ce paquet n'est pas destin une application. Les diffrentes valeurs de ce champs sont listes dans le fichier /etc/protocols sur les systmes GNU/Linux ou *BSD. Header Checksum : 16 bits A chaque cration ou modification d'un paquet, une somme de contrle (cyclic redundancy check) est calcule sur son en-tte. Lorsque le paquet arrive destination, cette somme est recalcule. Si le rsultat diffre, c'est que le paquet a t endommag lors de son trajet. Source Address : 32 bits Adresse IP de l'hte qui a mis le paquet. Voir Adressage IP8. Destination Address : 32 bits Adresse IP de l'hte qui doit recevoir le paquet. Voir Adressage IP9. Options and Padding Cette partie de l'en-tte est optionnelle. Ce champ est utilis pour fournir des instructions spcifiques de distribution du paquet qui ne sont pas couvertes par les autres champs de l'en-tte. La taille maximum de ces insturctions est limite 40 octets regroups en double-mots de 32 bits. Les bits de padding servent complter le dernier double-mot de 32 bits. Data C'est le dernier champ du paquet IP. Il contient les donnes du paquet. Celles ci peuvent dbuter par un en-tte de couche transport (4) qui donnera d'autres instructions l'application qui recevra les donnes. Le champ Data peut aussi contenir un message ICMP qui ne contient aucune donne utilisateur.

4. Les protocoles TCP & UDP de la couche transport

Relativement au protocole IP de la couche rseau, les protocoles de la couche transport ont un rle de fiabilisation des communications entre 2 extrmits. Avec la couche transport, on aborde le domaine des communications de bout en bout indpendantes de l'tat du sous-rseau. Les paquets peuvent tre arrivs destination par des chemins diffrents et dans le dsordre. Mme si l'appelation courante de la modlisation n'a retenu que TCP comme protocole de transport, il existe deux protocoles distincts suivant le type de rseau utilis. Le protocole TCP fonctionne en mode connect et assure un service fiable tandis que le protocole UDP assure un service de datagramme en mode non connect sans aucune garantie de fiabilit.

8 9

http://www.linux-france.org/prj/inetdoc/articles/adressage.ip/ http://www.linux-france.org/prj/inetdoc/articles/adressage.ip/

$Revision: 1.3 $

Transport de l'information avec TCP/IP

4.1. Le protocole TCP

Historiquement, c'est le premier protocole de transport dvelopp pour l'Internet. Les premires spcifications ARPANET prvoyaient un transport de l'information trs fiable indpendant du type et de l'tat du rseau. Le fonctionnement du protocole TCP a t dcrit dans le document : RFC 79310 TCP est un protocole de bout en bout orient connexion. Cette dfinition correspond celle de la couche transport du modle OSI. Voir Modlisations rseau11. Protocole de bout en bout. Les processus pairs des couches transport de 2 quipements connects dialoguent l'un avec l'autre sans rien connatre du rseau. C'est au niveau IP que l'on se proccupe de la fragmentation et du rassemblage des segments TCP. Protocole orient connexion. La fiabilit du transport TCP dpend de l'tablissement d'une connexion entre les processus pairs qui veulent dialoguer. L'tablissement d'une connexion est ralis par l'change d'informations telles que le numro de port, le numro de squence et la taille de fentre.

Source Port : 16 bits Numro du port source. Destination Port : 16 bits Numro du port destination. Sequence Number : 32 bits Si SYN = 0, le numro de squence est celui du premier octet de donnes de ce segment. Si SYN = 1, il s'agit du numro de squence initital ISN. le premier octet de donne est ISN+1. Acknowledgment Number : 32 bits Si le bit ACK = 1, ce champ contient le numro de squence attendu par l'metteur du segment. Data Offset : 4 bits Taille de l'en-tte TCP en mots de 32 bits. Reserved : 6 bits Champ rserv pour une utilisation ultrieure. Les 6 bits doivent tre 0. Control bits : 6 bits URG : Urgent Pointer field significant ACK : Acknowledgment field significant PSH : Push Function RST : Reset the connection SYN : Synchronize sequence numbers FIN : No more data from sender Window : 16 bits Nombre d'octets de donnes partir de celui indiqu par le champ Acknowledgment. Checksum : 16 bits
10 11

http://www.faqs.org/rfcs/rfc793.html http://www.linux-france.org/prj/inetdoc/articles/modelisation/

$Revision: 1.3 $

Transport de l'information avec TCP/IP Somme de contrle sur 16 bits de l'en-tte et des donnes. Urgent Pointer : 16 bits Ce champ est interprt uniquement si le bit de contrle URG est 1. Le pointeur donne le numro de squence de l'octet qui suit les donnes urgentes . Options : variable il existe 2 formats d'options : un seul octet de catgorie d'option ou un octet de catgorie d'option suivi d'un octet de longueur d'option et de l'octet des donnes de l'option.

4.2. Le fonctionnement du protocole TCP

D'aprs le format du message TCP, on peut rsumer le fonctionnement de la couche transport de la modlisation TCP/IP en quatre points. Le protocole TCP de la couche transport : segmente les donnes des applications, tablit une connexion de bout-en-bout, met les segments d'un hte l'autre, assure la fiabilit du transport des segments entre les htes connects.

4.2.1. La segmentation des donnes La fonction de transport est effectue segment par segment de faon autonome. Plusieurs applications peuvent mettre leurs segments successivement. Ces segments peuvent avoir un ou plusieurs destinataires.

4.2.2. L'tablissement de la connexion Les tapes de l'tablissement de la connexion sont :

4.2.3. Contrle de flux Un contrle de flux est ncessaire pour prvenir la congestion des transferts : Un serveur performant peut gnrer plus de trafic que le rseau ne peut en supporter. Un serveur peut tre sollicit par un nombre trs lev de clients.

$Revision: 1.3 $

Transport de l'information avec TCP/IP

4.2.4. fentrage Un dispositif de fentrage de l'acquittement a t implant pour prserver la bande passante. Si l'metteur devait attendre un acquittement aprs l'mission de chaque segment, la qualit de la transmission serait dgrade.

4.3. Le protocole UDP

Le protocole UDP est apparu avec le dveloppement des rseaux locaux dont la fiabilit permet de s'affranchir des fonctions de contrle. C'est un protocole minimum sans garantie de dlivrance des messages et sans squencement.

Source Port : 16 bits Numro du port source. Ce champ est optionnel. Destination Port : 16 bits Numro du port destination. Length : 16 bits Longueur en octets du datagramme UDP incluant l'en-tte et les donnes. Checksum : 16 bits Somme de contrle sur 16 bits de l'en-tte et des donnes.

$Revision: 1.3 $