LES APPLICATIONS TCP

Les applications TCP

On décrit ici de maniÈre succincte quelques applications majeures que l'on trouve sur Internet. Toutes ces applications sont baties sur le modÈle «client-serveur» à savoir qu'une des deux extrémités de la connexion (TCP UDP)/IP rend des services à l'autre extrémité.

Protocole de démarrage : BOOTP

BOOTP (Bootsrap Protocol) est un protocole de démarrage de terminaux X ou stations sans disque qui utilise UDP comme couche de transport et est généralement associé à TFTP ou NFS. Comme RARP, il sert principalement à fournir son adresse IP à une machine que l'on démarre sur un réseau. Cependant il est plus intéressant que RARP, car il se situe à un niveau supérieur, il est donc moins lié au type de matériel du réseau. De plus, il transmet plus d'information que RARP qui, lui, ne renvoie qu'une adresse IP.

Un autre protocole, DHCP (Dynamic Host Configuration Protocol) permet, lui, d'attribuer cette adresse IP dynamiquement, c'est-à-dire que l'adresse IP affectée à la machine qui démarre peut changer d'un démarrage à l'autre. BOOTP fait cela de maniÈre statique en utilisant un serveur (ou plusieurs) qui contient dans un fichier l'adresse IP à distribuer à chaque machine. Le fichier est maintenu à jour par l'administrateur du réseau et contient pour chaque machine plusieurs informations comme illustré ci-aprÈs pour le terminal X de l'auteur.

ba -- broadcast bootp reply for testing with bootpquery

bf -- bootfile (for tftp download)

ds -- domain name server IP address

gw -- gateway IP address

ha -- hardware address (link level address) (hex)

hd -- home directory for bootfile (chrooted to tftp home directory)

hn -- send nodename (boolean flag, no '=value' needed)

ht -- hardware type (ether) (must precede the ha tag)

ip -- X terminal IP address

sm -- network subnet mask

tc -- template for common defaults (should be the first option listed)

vm -- vendor magic cookie selector (should be rfc1048)

T144  remote config file name (file name must be enclosed in '')

# H104 (Vincent JOLY) prise I141 :

tx-pn

ht=Ethernet:

ha=0x08001103ec2c:

bf=/usr/tekxp/boot/os.350:

ip=193.49.162.63:

sm=255.255.255.0:

gw=193.49.162.220:

vm=rfc1048:

ds=

Le format du message BOOTP est donné dans la figure 2.31 :

Figure 2.31: Format de requÊte ou réponse BOOTP.

Le code vaut 1 pour une requÊte et 2 pour une réponse, le type de matériel vaut par exemple 1 pour un réseau Ethernet et dans ce cas le champ longueur de l'adresse physique vaut 6 (octets). Le champ compteur de saut vaut 0 en standard, mais si la demande transite par un routeur celui-ci l'incrémente de 1. L'identificateur de transaction est un entier de 32 bits fixé aléatoirement et qui sert à faire correspondre les réponses avec les requÊtes. Le nombre de secondes est fixé par le client et sert à un serveur secondaire de délai d'attente avant qu'il ne réponde au cas oÙ le serveur primaire serait en panne. Parmi les 4 adresses IP d'une requÊte, le client remplit celles qu'il connait et met les autres à 0 (généralement il n'en connait aucune). Dans sa réponse, le serveur indique l'adresse IP de la machine client dans le champ votre adresse IP et sa propre adresse dans le champ adresse IP du serveur. Il peut aussi donner son nom terminé par le caractÈre nul. Si un Proxy est utilisé, celui-ci indique son adresse dans le champ prévu. Le champ adresse matérielle du client sert à celui-ci pour y indiquer son adresse physique. Ainsi cette adresse sera plus facilement disponible pour le processus BOOTP serveur que celle placée dans la trame Ethernet. Le nom du fichier de boot est le nom du fichier transmis par le serveur au client pour que celui-ci puisse ensuite continuer son démarrage. La derniÈre partie du message est réservée à des caractéristiques particuliÈres données par chaque constructeur de matériel et permet d'ajouter des fonctionnalités supplémentaires.

Quand il émet une requÊte BOOTP, le client l'encapsule dans un datagramme UDP en fixant le port source à 68 et le port destination (celui du serveur) à 67. Dans la majorité des cas, il ne sait pas préciser la valeur de l'adresse IP de destination et la fixe donc égale à l'adresse de diffusion. Ainsi, la trame Ethernet correspondante sera diffusée à toutes les machines du réseau et grace au numéro de ports seuls le(s) serveur(s) BOOTP reçoit le message et le traite. Pour cela, il consulte la table de correspondance et retourne sa réponse en y fixant l'adresse IP du client, le nom du fichier à télécharger et l'adresse IP du serveur.

Il reste un problÈme à régler. Lors de l'émission du datagramme IP contenant la réponse, la couche de liens doit établir la correspondance adresse IP/adresse physique du client pour construire la trame physique à émettre. Or, cette correspondance ne peut Être connue dans la table ARP à cet instant puisque la machine client démarre. Et si le logiciel de liens émet une requÊte ARP la machine client ne sait pas répondre puisqu'elle ne peut pas reconnaitre son adresse IP qu'elle ne connait pas encore. Il existe deux solutions à ce problÈme. Soit, le module BOOTP, qui dispose de cette correspondance, enrichit la table ARP avant d'émettre. Soit, il n'en a pas les droits et alors il diffuse la réponse à toutes les machines du réseau, mais cette solution est à éviter.

Connexion à distance : Telnet et Rlogin

Telnet et Rlogin sont deux applications qui permettent à un utilisateur de se connecter à distance sur un ordinateur, pourvu que cet utilisateur y dispose d'un accÈs autorisé. Ces deux applications permettent toutes les deux de prendre le contrôle (du moins partiellement) d'un ordinateur distant, mais Rlogin ne permet de le faire qu'entre deux machines Unix, tandis qu'il existe des clients Telnet pour de nombreuses plateformes (Unix, Windows, MacOs, ). Telnet et Rlogin sont tous les deux batis sur TCP.

Le schéma de fonctionnement de Telnet est donné dans la figure 2.32.

Figure 2.32: Schéma de focntionnement de l'application Telnet.

Telnet définit une interface de communication, le terminal virtuel de réseau, pour que clients et serveurs n'aient pas à connaitre les détails d'implantation de chaque systÈme d'exploitation. De cette façon, les échanges se font dans un langage commun compris à la fois par le client et le serveur qui n'ont qu'à assurer une traduction de (ou vers) leur propre langage vers (depuis) ce langage cible.

SystÈme de fichiers en réseau : NFS.

NFS (Network File System) est un systÈme qui permet de rendre transparente l'utilisation de fichiers répartis sur différentes machines. Son architecture générale est donnée dans la figure 2.33.

Figure 2.33: Configuration client serveur de NFS.

NFS utilise principalement UDP, mais ses nouvelles implantations utilisent également TCP. Lorsqu'un processus utilisateur a besoin de lire, écrire ou accéder à un fichier le systÈme d'exploitation transmet la demande soit au systÈme de fichier local, soit au client NFS. Dans ce dernier cas, le client NFS envoie des requÊtes au serveur NFS de la machine distante. Ce serveur s'adresse à la routine locale d'accÈs au fichiers qui lui retourne le résultat retransmis vers le client par la connexion UDP (ou TCP) IP. Il ne s'agit pas ici de transférer un fichier d'une machine à l'autre mais simplement de le rendre disponible de maniÈre totalement transparente.

Transfert de fichier : TFTP et FTP

TFTP (Trivial File Transfert Protocol) et FTP (File Transfert Protocol) permettent tous les deux de transférer des fichiers d'une machine à une autre. Cependant TFTP, bati sur UDP, est beaucoup plus sommaire que FTP qui utilise TCP. L'utilisation de FTP depuis un poste client pour aller chercher ou déposer un fichier sur un serveur nécessite de la part de l'utilisateur de se connecter avec un nom et un mot de passe. Donc, si l'utilisateur n'est pas reconnu la connexion FTP ne sera pas établie. Dans le cas particulier d'un serveur ftp public, la connexion se fait avec le nom anonymous et il est conseillé de donner son adresse électronique comme mot de passe. Dans le cas de TFTP, aucune authentification préalable n'est nécessaire. C'est pourquoi, lorsqu'un serveur TFTP est installé sur une machine il n'offre des possibilités d'accÈs qu'à un nombre restreint de fichiers bien spécifiques. Ces fichiers sont généralement des fichiers de démarrage de terminaux X ou stations sans disque qui les récupérent aprÈs en avoir été informés par le protocole BOOTP.

Les différents messages TFTP sont donnés dans la figure 2.34 et se distinguent selon leur code d'opération.

Figure 2.34: Format des messages TFTP.

RRQ indique une requÊte de lecture de fichier (transmis au client) et WRQ une requÊte d'écriture de fichier (transmis au serveur). Ensuite, vient le nom du fichier terminé par un caractÈre nul. Le champ mode, terminé par un caractÈre nul également, est égal à netascii pour indiquer que le fichier est un fichier texte oÙ chaque ligne est terminée par CR LF. Ces deux caractÈres doivent peut-Être Être convertis dans la syntaxe utilisée par la machine locale pour marquer les fins de ligne des fichiers textes. Il est égal à octet dans le cas d'un fichier binaire à transférer tel quel.

DATA débute les paquets de données à transmettre. Un fichier de N octets sera découpé en N div 512 tels paquets contenant chacun 512 octets de données et un paquet contenant N mod 512 octets qui sera reconnu comme le paquet final puisqu'il contient moins de 512 octets. Le champ numéro de bloc sert à numéroter chaque paquet de données et est utilisé pour l'accusé de réception.

- ACK indique que le message acquitte le bloc de numéro spécifié dans le message. TFTP est obligé de s'assurer lui mÊme de la bonne transmission des données puisqu'il utilise UDP qui est un protocole non fiable. Le protocole d'acquittement est de type stop-and-wait car aprÈs avoir envoyé un paquet l'émetteur attend l'accusé de réception du récepteur avant d'envoyer le paquet suivant. Si l'émetteur ne reçoit pas d'acquittement avant l'expiration de son délai d'attente il réexpédie le paquet perdu. De mÊme, le récepteur qui ne reçoit plus de paquets aprÈs son délai d'attente renvoie à nouveau son acquittement. Seulement, si le ACK k est retardé mais non perdu, l'émetteur va retransmettre le paquet k que le récepteur va à nouveau acquitter. Donc, deux ACK k vont finalement parvenir à l'émetteur ce qui va déclencher de sa part l'envoi de deux paquets k+1, qui provoqueront deux ACK k+1 et donc l'envoi de deux paquest k+2, etc

- Les messages débutant par ERROR indiquent une erreur de transmission et transportent un code et un message d'erreur. Lorsque cela arrive, le transfert est immédiatement interrompu.

Lorsqu'il demande une connexion le client s'attribue un port éphémÈre UDP et envoie sa requÊte au serveur sur le port 69 prévu pour FTP. À ce moment-là, le serveur va s'attribuer un nouveau port éphémÈre qui devra Être détecté par le client et qui servira tout le temps de la connexion. Il ne conserve pas le port 69 tout au long de l'échange car cela l'obligerait soit à refuser d'autres connexions pendant ce temps, soit à les multiplexer ensemble ce qui alourdirait le protocole.

Quant à lui, FTP est défini au-dessus de TCP et utilisent deux connexions TCP IP pour fonctionner comme illustré dans la figure 2.35.

Figure 2.35: Transfert de fichier par FTP.

Tout d'abord on y voit que le client utilise FTP à travers une interface qui peut Être graphique (logiciels XFTP, WS-FTP, Fetch, ) ou texte (mode commandes d'unix par exemple). La connexion de contrôle est établie de façon normale en mode client serveur sur le port 21 du serveur et sur un port aléatoire du client pour tout ce qui est de type transfert interactif. Elle sert donc tout le temps de la session à transférer les commandes du client et presque toutes les réponses du serveur. La connexion de données sert à transférer les fichiers et les contenus de répertoires du serveur, c'est-à-dire tous les transferts de masse.

En effet, lorsque le client demande le contenu d'un répertoire la réponse peut Être trÈs longue et il est préférable de l'envoyer sur cette connexion plutôt que sur celle du transfert interactif.

À chaque fois qu'un fichier doit Être transféré, dans un sens ou dans l'autre, le client initie une connexion de données en s'attribuant un port et envoie au serveur une demande de connexion sur la connexion de contrôle. Le serveur se sert du numéro de port reçu pour établir la connexion de données entre son port 20 et ce port indiqué par le client.

Courrier électronique : smtp

Le courrier électronique au sein d'Internet est géré par le protocole SMTP (Simple Mail Transfer Protocol) bati sur TCP (port 25). Il permet d'échanger des messages entre un expéditeur et un (ou plusieurs) destinataire pourvu que leurs adresses soient connues. Une adresse de courrier électronique se présente sous la forme nom@domaine est doit Être composée de lettres (minuscules ou majuscules sont indifférenciées), de chiffres, de (souligné) et de . (point). Il est à noter qu'un mécanisme d'alias permet de définir des équivalences entre adresses, notamment de préciser quelle machine parmi toutes celles d'un mÊme domaine gÈre réellement le courrier de chaque utilisateur.

Une des caractéristiques principales du protocole SMTP est d'effectuer une remise différée du courrier qui assure que le service sera correctement rendu mÊme si le réseau ou l'ordinateur destinataire est momentanément en panne ou surchargé.

Figure 2.36: Schéma d'une messagerie SMTP.

Pour cela le systÈme de messagerie fonctionne de la maniÈre décrite en figure 2.36. Un courrier expédié par un utilisateur est d'abord copié dans une mémoire de spool accompagné des noms de l'expéditeur, du récepteur, de l'ordinateur destinataire et de l'heure de dépôt. Puis le systÈme de messagerie active en tache de fond le processus de transfert de courrier qui devient un client. Il associe le nom de l'ordinateur destinataire à une adresse IP et tente d'établir une connexion TCP avec le serveur SMTP de celui-ci. Si cela réussit, le processus de transfert envoie une copie du message au destinataire qui l'enregistre dans une zone de spool spécifique. Lorsque le client et le serveur se sont confirmés l'envoi et l'enregistrement complet du message le client supprime sa copie locale. Si le client n'arrive pas à établir une connexion TCP, ou si elle est rompue lors du transfert d'un message, il enregistre l'heure de cette tentative et réessaye quelque temps plus tard d'expédier le message. D'une maniÈre générale un systÈme de messagerie examine réguliÈrement sa zone de spool en envoi et tente d'expédier les messages (nouveau ou en attente à cause d'échec) qui s'y trouvent. Il finira par retourner à son expéditeur un message impossible à expédier aprÈs un délai important. Ce mode de fonctionnement (établir une connexion de bout en bout) assure qu'aucun message ne peut se perdre, soit il est délivré, soit son expéditeur est prévenu de l'échec.

Le tableau ci-dessous donne le détail d'une connexion TCP réussie qui envoie un message de l'utilisateur toto@expediteur.fr dont le courrier est géré par l'ordinateur exp.expediteur.fr vers l'utilisateur titi@destinataire.fr dont le courrier est géré par l'ordinateur dest.destinataire.fr. La premiÈre colonne décrit les étapes, la deuxiÈme (respectivement troisiÈme) colonne indique les commandes envoyées par l'expéditeur (respectivement destinataire) du courrier.

News : nntp

NNTP (Network News Transfert Protocol) est le protocole d'échange des news ou forums de discussions à travers Usenet (nom donné au réseau logique constitué des serveurs de news disséminés sur la planÈte). Comme illustré dans la figure 2.37, il assure l'échange des news entre les serveurs et également la communication entre serveur et postes clients aussi bien pour la lecture que pour l'écriture de messages.

Figure 2.37: Communication au sein de Usenet.

Ainsi, lorsqu'un utilisateur poste un article dans un groupe de news, il est dans un premier temps déposé sur le serveur de news auquel le poste client est relié. Puis, ce serveur va réexpédier cet article aux différents serveurs auxquels il est relié, qui eux-mÊmes procéderont de la sorte. Ainsi, en quelques heures un message posté à Angers peut se retrouver sur un serveur de news en Australie. Mais, ce processus de diffusion systématique, n'est pas assuré pour tous les groupes de news existant au niveau mondial, car chaque serveur de news n'assure le relais que de certains groupes. En effet, il n'est peut-Être pas trÈs utile de diffuser sur les serveurs de news japonais le groupe fr.petites-annonces.automobiles :-). De plus, tout serveur de news fixe pour chaque groupe la durée de conservation des messages sur ses disques durs.

De maniÈre plus technique, NNTP utilise TCP via le port 119, le client envoyant une commande ASCII à laquelle le serveur répond par un code numérique éventuellement suivi par des données. Ces données sont disposées sur plusieurs lignes terminées chacune par CR/LF et terminées par une ligne réduite à un point.

Tout d'abord il faut savoir qu'un serveur de news ne répond pas systématiquement à toutes les requÊtes des postes clients, mais uniquement à celles provenant de machines qu'il autorise, par exemple celles de son domaine. Ceci est illustré ci-aprÈs oÙ l'on voit que le serveur de news news.univ-angers.fr accepte la connexion depuis une machine située en Allemagne uniquement pour la lecture des news et accepte la lecture et l'écriture de message depuis une machine située sur son réseau.

[brehat.haiti.cs.uni-potsdam.de]telnet news.univ-angers.fr 119

Trying 193.49.144.4

Connected to news.univ-angers.fr.

Escape character is '^]'.

201 univ-angers.fr InterNetNews NNRP server INN 1.7.2 08-Dec-1997 ready (no posting).

[helios]telnet news.univ-angers.fr 119

Trying 193.49.144.4

Connected to news.univ-angers.fr.

Escape character is '^]'.

200 univ-angers.fr InterNetNews NNRP server INN 1.7.2 08-Dec-1997 ready (posting ok).

La liste des commandes connues d'un serveur de news peut-Être obtenue en l'interrogeant au moyen de la commande help, comme décrit ci aprÈs.

help

100 Legal commands

authinfo user Name|pass Password|generic <prog> <args>

article [MessageID|Number]

body [MessageID|Number]

date

group newsgroup

head [MessageID|Number]

help

ihave

last

list [active|active.times|newsgroups|distributions|distrib.pats|overview.fmt|subscriptions]

listgroup newsgroup

mode reader

newgroups yymmdd hhmmss ['GMT'] [<distributions>]

newnews newsgroups yymmdd hhmmss ['GMT'] [<distributions>]

next

post

slave

stat [MessageID|Number]

xgtitle [group_pattern]

xhdr header [range|MessageID]

xover [range]

xpat header range|MessageID pat [morepat]

xpath MessageID

Report problems to <newsmaster@univ-angers.fr@news.univ-angers.fr>

Quant aux codes de réponses du serveur de news, ils sont décrits dans la table 2.2.

Le rôle de quelques commandes de NNT est illustré ci-aprÈs en interrogeant le serveur news.univ-angers.fr

list retourne la liste des groupes de news, en indiquant leur nom, le numéro de l'article le plus récent, le numéro de l'article le plus ancien encore conservé, et la lettre y si le postage est libre ou m s'il est contrôlé par un modérateur.

list

215 Newsgroups in form 'group high low flags'.

control 0001251116 0001053999 y

junk 0000000486 0000000480 y

bionet.agroforestry 0000002281 0000002229 y

bionet.announce 0000000165 0000000116 m

group fixe un groupe courant et renvoie une estimation du nombre d'articles dans le forum, le numéro de l'article le plus ancien, celui de l'article le plus récent et le nom du groupe.

group fr.comp.os.linux

211 6543 27618 34211 fr.comp.os.linux

La différence 34211-27618=6593 est plus grande que 6543 car tous les messages ne sont pas forcément conservés aussi longtemps les uns que les autres.

Si le nom du groupe est erroné on obtient ceci :

group fr.comp.linux

411 No such group fr.comp.linux

head envoie les en-tÊtes d'un article dont le numéro est spécifié.

head

221 34205 <3634E2EC.9B76A7E8@cern.ch> head

Path: univ-angers.fr!enst!isdnet!newsgate.cistron.nl!het.net!news.belnet.be!

news-zh.switch.ch!news-ge.switch.ch!cern.ch!news

From: Nuno DOS SANTOS <Nuno.Dos.Santos@ces20s15ss15s12s9s3s4s5s

Newsgroups: fr.comp.os.linux

Subject: Instal carte de son

Date: Mon, 26 Oct 1998 22:00:28 +0100

Organization: CERN

Lines: 10

Message-ID: <3634E2EC.9B76A7E8@cern.ch>

NNTP-Posting-Host: pcst101.cern.ch

Mime-Version: 1.0

Content-Type: text/plain; charset=us-ascii

Content-Transfer-Encoding: 7bit

X-Trace: sunnews.cern.ch 909435628 12357 (None) 128.141.182.63

X-Complaints-To: news@sunnews.cern.ch

X-Mailer: Mozilla 4.05 [en] (Win95; I)

Xref: univ-angers.fr fr.comp.os.linux:34205

body retourne le corps de l'article dont le numéro est spécifié.

222 34205 <3634E2EC.9B76A7E8@cern.ch> body

Salut,

J'arrive pas a installer ma carte de son SB PCI awe64. Dans le HOW-TO ils

parlent toujours de make config, xconfig, etc., mais la commande make ne

passe pas. Il me donne l'erreur 'make:*** No rule to make target

'xconfig'. Stop.'. Le fichier sndstat est vide.

Vous pouvez m'aider? Une suggestion?

Merci

Le point final ne fait pas partie du message mais est envoyé par NNTP pour terminer sa réponse

World Wide Web : http

HTTP (HyperText Transfer Protocol) est le protocole de communication du web permettant d'échanger des documents hypertextes contenant des données sous la forme de texte, d'images fixes ou animées et de sons.

Tout client web communique avec le port 80 d'un serveur HTTP par l'intermédiaire d'une, ou plusieurs, connexions TCP simultanées, chacune des connexions TCP ouvertes servant à récupérer l'un des composants de la page web.

Trois types de requÊtes sont disponibles :

- GET url renvoie l'information spécifiée par l'url.

- HEAD url renvoie l'en-tÊte de l'information demandée et non pas le contenu du document.

- POST pour envoyer du courrier électronique, des messages de news, ou des formulaires interactifs remplis par l'utilisateur.

La requÊte du client se compose de lignes de texte ASCII terminées par les caractÈres CR/LF et organisées comme ci-aprÈs :

requÊte url-demandé HTTP-version

en-tÊtes (0 ou plus)

<ligne blanche>

corps de la requÊte (seulement pour une requÊte POST)

Une réponse du serveur web se présente comme suit :

HTTP-version code-réponse phrase-réponse

en-tÊtes (0 ou plus)

<ligne blanche>

corps de la réponse

Les en-tÊtes de requÊtes ou de réponses ont la forme :

nom-de-champ: valeur

et se classent ainsi :

en-tÊtes de requÊte : authorization date from if-modified-since location mime-version pragma referer user-agent

en-tÊtes de réponse : date location mime-version pragma server www.authenticate

en-tÊtes de corps dans les réponses HTTP ou les requÊts POST : allow content-encoding content-length content-type expires last-modified

Les codes de réponses sont des nombres de 3 chiffres rangés en 5 catégories comme décrits dans la table 2.3.

Ci -dessous est décrit un exemple de requÊte et réponse HTTP, aprÈs s'Être connecté à un serveur web, par exemple avec un client telnet :

helios|~>telnet www.yahoo.fr 80

Trying 195.67.49.47

Connected to www.yahoo.fr.

Escape character is '^]'.

get / http/1.0

HTTP/1.0 200 OK

Last-Modified: Mon, 26 Oct 1998 19:13:02 GMT

Content-Type: text/html

Content-Length: 13163

<head>

<title>Yahoo! France</title>

<base href='https://www.yahoo.fr/'>

</head>

<body>

</body>

</html>