NISSR
Quelques protocoles de transfert de fichier
Le protocole http
Le protocole HTTP (Hyper Text Transfer Protocol) est un protocole de type client/serveur conçu pour transférer les données des sites web. Une connexion TCP est d’abord initiée par le client afin de pouvoir transmettre une requête, puis la réponse du serveur revient par le chemin inverse. La version 1.1 permet, entre autres, de réutiliser la connexion ouverte afin d’envoyer plusieurs requêtes de manière séquentielle sans avoir à payer à nouveau le coût d’établissement d’une nouvelle connexion. Un autre aspect intéressant est le support de l’extension byte-range qui permet de récupérer une partie d’un fichier (pour terminer un téléchargement ou bien pour récupérer des morceaux d’un fichier répliqué sur plusieurs sites) [20]. Il supporte la structure page et le mode de transfert flux.
Le protocole FTP
Le protocole FTP (File Transfer Protocol) [20] est un protocole développé, comme son nom l’indique, pour effectuer des transferts de fichiers, et ce, entre un client et un serveur. FTP s’appuie sur le protocole TCP et lors d’un transfert de fichier, deux connexions sont créées. La première est une connexion de contrôle, créée à l’initiative du client vers le port du service FTP (usuellement port 21). La seconde (port 20 par défaut) peut être créée, soit à l’initiative du serveur (mode actif). Ce qui peut poser des problèmes avec certains systèmes pare-feu. Soit à l’initiative du client (mode passif). Entre plusieurs transferts consécutifs de fichiers, la connexion de contrôle est conservée. FTP permet aussi de gérer des transferts à l’initiative d’un client tiers, c’est-à-dire entre deux serveurs en utilisant des requêtes permettant de préciser la destination (requêtes PORT et PASSIVE). Avec les adresses de deux machines différentes, les transferts et les ports qui vont bien, le transfert peut donc être effectué. Cette opération peut devoir être autorisée explicitement sur les serveurs qui doivent accepter une connexion venant d’une machine différente de celle qui a demandé contrôle.
Dans sa version de base, le protocole est considéré comme peu sûr car d’une part le canal de contrôle est dérivé du protocole telnet et d’autre part, le « vol de connexion» est relativement aisé si le serveur n’effectue pas de vérifications suffisamment poussées sur les sources et les destinations du transfert. De plus, cette mauvaise réputation est entachée par le fait que de nombreux trous de sécurités critiques permettant d’obtenir aisément les privilèges d’administrateur aient été découverts dans de nombreuses implantations de ce protocole [14].
Le protocole FTP supporte les modes de transfert flux, bloc et compressé. Il supporte les structures fichier, enregistrement et page. Dans le mode bloc l’en-tête de consiste en trois octets. Sur ces 24 bits d’information d’en-tête, les 16 bits de poids faible représentent le compte d’octets, les 8 bits de poids fort donnent le code de description selon les définitions ci-dessous.
Figure 6. Entête de bloc FTP
Le descripteur est formé de bits indicateurs. Quatre codes sont actuellement reconnus, dont le nombre représente la valeur décimale du masque :
• 128 : le bloc est le dernier d’un enregistrement (EOR en fin de bloc),
• 64 : le bloc est le dernier de la transmission (EOF en fin de bloc),
• 32 : Erreurs probables dans les données de ce bloc,
• 16 : Le bloc de données est le premier d’une reprise.
Le protocole Gridftp
Ce protocole de est une extension du protocole FTP conçu pour les grilles de calcul [4]. Il fournit un ensemble de fonctionnalités permettant d’utiliser les différents systèmes stockage au cours d’utilisation. Le choix d’étendre le protocole FTP s’explique par le fait que c’est le protocole le plus utilisé pour le transfert de données dans l’Internet, et en plus des autres protocoles il reste le plus proche pour satisfaire les besoins de la grille.
Gridftp comprend les fonctionnalités suivantes :
• le service de sécurité GSI,
• le contrôle des données par third-party : un client peut initier un transfert de fichiers entre deux serveurs,
• le transfert de données en mode stripé : la distribution d’un fichier sur plusieurs hôtes,
• le transfert de données parallèle : envoi d’un fichier à travers plusieurs ports de données,
• la négociation de la taille des buffers TCP,
• la reprise après panne,
• l’instrumentation de code.
Les extensions consistent en des commandes et un nouveau mode de transfert. Parmi les commandes nous pouvons citer la commande SPAS, SPOR, ERET, ESTO, SBUF.
A La commande de Striped Passive (SPAS)
Cette commande est analogue à la commande PASV (mode passif de FTP). Cette commande demande au serveur de se mettre à l’écoute d’un port de données e t d’attendre un ou plusieurs canaux de données plutôt que de prendre l’initiative d’en établir une sur réception d’une commande de transfert. La réponse à cette commande précise les adresses et les ports sur lesquels le serveur s’est mis en écoute.
La commande Striped Dates Port (SPOR)
Cette commande est analogue à la commande POR (indique le port de données dans FTP) doit être utilisée pour permettre le third-party transfert.
La commande Extended Retrieve (ERET)
Analogue à la commande RETR (commande pour transmettre les données dans FTP) mais il autorise les modifications des données à manipuler avant d’être transmise.
La commande Extended Retrieve STORE (ESTO)
Analogue à la commande STORE (commande pour stocker les données dans FTP) mais il autorise les modifications des données à manipuler avant d’être transmise.
La commande Set Buffer Size (SBUF)
Cette extension ajoute la possibilité au client de définir la taille du buffer TCP c’est-à-dire celle des buffers d’émission et de réception TCP pour les connexions de données.
Le mode Extended Block Mode
Les mode de transfert parallèle et strippé décrits ci dessus exigent un mode de transfert spécifique pour la délivrance des données de façon séquentielle et partielle à travers les ports de connexion. Le mode E-Block étend le mode bloc du protocole FTP pour permettre le transfert de larges volumes de données dépassant les limites de FTP. La structure de l’entête du bloc E-Block est : Descripteur Champ de comptage Offset
Le descripteur est formé de bits indicateurs. Six codes sont actuellement reconnus:
• 128 : le bloc est le dernier d’un enregistrement (EOR bloc),
• 64 : le bloc est le dernier de la transmission (EOF bloc),
• 32 : erreur probable dans les données de ce bloc,
• 16 : le bloc de données est le premier d’une reprise,
• 8 : le bloc est End of Data Count (EODC pour cette connexion),
• 4 :l’émetteur va fermer le canal de données.
Certains mécanismes sont ajoutés au canal de données du mode bloc afin de gérer correctement la fin du fichier en présence d’un nombre inconnu de flux.
• Quand il n y a plus de données à envoyer dans un canal de données, l’émetteur marque le dernier bloc ou envoie un bloc vide. Il va marquer le dernier bloc avec le code 8 pour signifier que c’est le dernier du canal des données.
• Après réception du message EODC le canal de donnée peut être utilisé pour d’autres transferts. Pour signifier que le canal de données est fermé après le dernier bloc un code 4 est envoyé dans le dernier message (bloc) envoyé.
• L’émetteur communique un EOF à tous les serveurs concernant le transfert. En plus des champs décrits ci-dessous l’entête du bloc EODC comporte un champ appelé EOD count excepted. Ce champ de 64 bits représente le nombre de blocs envoyés dans un canal. Le numéro est utilisé par les récepteurs pour déterminer qu’il a reçu toutes les données. Lorsque le nombre de messages EOD (fin d’un bloc de données) reçus et le nombre EOD count excepted sont égaux, alors la fin du fichier est bien reçue.
Télécharger le document complet
