next up previous contents Next: L'en-tête TCP. Up: Linux Base d'administration pour Previous:  tcpdump.   Table des matières  


27. TCP et UDP.

Au cours du chapitre précédent, nous avons abordé la communication entre machines en nous intéressant à la couche IP. Ce protocole effectue peu de contrôles et ne permet pas de corriger des erreurs associées au transport de données. En particulier, il ne vérifie pas le bon acheminement des paquets. Aussi, lorsque deux applications fonctionnent de part et d'autre de l'Océan Atlantique (par exemple), le fait d'être capable d'envoyer un paquet qui peut (ou peut ne pas) atteindre le côté opposé ne suffit-il pas. Nous avons besoin de communications fiables donc d'un protocole supplémentaire.

Idéalement, un programme utilisateur établit un lien sur une machine distante et lui transmet des octets tout en étant sûr que ceux-ci atteignent leur destination ``point-à-point'' (et ce, de part et d'autre de la ligne de communication). Une telle opération est appelée communication à flux fiable.

Vous pourriez imaginer envoyer des paquets séparés et attendre que pour chaque paquet, le machine distante confirme leur réception. Cette approche est inefficace car les paquets mettent un temps assez long pour atteindre leur destination; il en va de même pour la confirmation de la réception associée à chaque paquet. L'idée est plutôt d'envoyer autant de paquets que possible en une fois et de disposer d'un moyen de négocier avec la machine distante de manière à renvoyer les paquets qui n'auraient pas été reçus. C'est précisément ce que fait TCP (Transmission Control Protocol) en envoyant des paquets de données en un coup et en analysant les paquets de contrôle (acknowledgment packets) de sorte à indiquer les parties du flux de données qui ont été correctement reçues sur la machine de destination.

Nous voyons donc que TCP est mis en oeuvre à un niveau supérieur à IP. Ainsi, la communication sur l'internet est-elle souvent appelée ``communication par TCP/IP''.

La communication TCP se fait en trois étapes: la négociation, le transfert et la déconnexion (detachment) [Ceci est la terminologie de l'auteur du texte original en anglais. Il s'agit d'une représentation quelque peu schématique].

Négociation
L'application cliente (disons votre navigateur) initie tout d'abord la connexion en utilisant la fonction C connect() (voir connect(2)). Ceci force le noyau à envoyer un paquet SYN (de SYNchronisation) au serveur TCP distant (dans le cas présent, un serveur web). Le serveur web répond en envoyant un paquet SYN-ACK (ACKnowlegde: pour accusé de réception). Finalement, le client répond avec un dernier paquet SYN. Cette négociation se fait de manière transparente pour l'utilisateur.

Transfert
L'application emploie les appels de fonction C send () et recv () (voir send(2) et recv(2)) pour envoyer et recevoir un flux de données réelles. Le flux est morcelé en paquets et ceux-ci sont envoyés individuellement à l'application distante. Dans le cas du serveur web, les premiers octets envoyés devraient être GET /index.html HTTP/1.0<CR><NL><CR><NL>. De l'autre côté de la communication, les paquets de réponse (appelés ACK) sont retournés aussitôt que les données arrivent, ce qui permet d'indiquer quelles parties du flux manquent et de demander une nouvelle transmission. La communication se passe dans les deux sens en full-duplex (le flux se produit simultanément dans les deux directions, comme dans le cas des communications téléphoniques): les données et les paquets ACK se croisent.

Déconnexion
L'application utilise les fonctions C shutdown () et close () (voir shutdown () et close(2)) afin de clore la connexion. Un paquet FIN est transmis et la communication TCP cesse.



Sections
next up previous contents Next: L'en-tête TCP. Up: Linux Base d'administration pour Previous:  tcpdump.   Table des matières  
1-01-2006