HTTP et FTP

1. Surfer sur Internet

Définition du protocole HTTP
HTTP pipelining
Une autre définition d'HTTP

HTTP est un protocole d'Entrées/Sorties rapide, de taille modeste, capable d'interpréter les URL (uniform resource locator) et destiné aux environnements hypertexte/hypermédias. Il est sans état, à la différence de FTP, et dispose seulement de quelques commandes ou méthodes. HTTP utilise MIME, le rendant extensible pour les formats multimédias et différentes formules d'entrées/sorties.

HTTP est un protocole client/serveur qui utilise un modèle requête/réponse. Un client HTTP, ou agent d'utilisateur (souvent un navigateur Web), se connecte à un serveur HTTP, en utilisant une URL et lui adresse une requête relative à une ressource, telle qu'un document HTML.

Ce modèle requête/réponse utilise MIME pour encapsuler les données demandées. Le trafic de données entre un client et un serveur HTTP ressemble, sur le plan conceptuel, à un trafic e-mail. Il consiste en données (le corps du message) et en métadonnées (les en-tête de messages). HTTP transfère les
données au format MIME; les métadonnées incluent l'information nécessaire pour le transfert de ces données entre le serveur HTTP et le client. Cependant, HTTP suppose l'existence de connexions binaires, ce que ne peut faire MIME (en raison de sa limitation aux e-mails 7 bits).

Habituellement, des clients HTTP (les navigateurs Web) se trouvent en présence de serveurs HTTP (les serveurs Web). Il peut aussi y avoir des serveurs proxy/passerelle, qui agissent comme serveur vis-à-vis d'un client et comme client vis-à-vis d'un autre serveur, pour résoudre la requête originelle du
client à travers une passerelle (par exemple, le pare-feu entre l'intranet d'une entreprise et l'Internet).

Traditionnellement, les clients/serveurs HTTP parlent sur le port TCP/IP 80, le port TCP par défaut attribué à HTTP. Cependant, d'autres ports peuvent être utilisés si c’est précisé dans l'URL. En outre, HTTP n'implique pas nécessairement TCP/IP et peut être utilisé avec d'autres protocoles fiables.

Pour un navigateur Web, une page Web est composée de multiples objets, tels que le document HTML lui-même et les images multiples (GIF, JPEG, PNG et autres fichiers). La plupart des clients HTTP auront un thread (avec une connexion au serveur) pour lire le document HTML initial, et démarrer en environnement multi-threads (chacun avec sa connexion propre au serveur) la lecture des autres fichiers indispensables. La connexion est établie par le client pour la requête et terminée par le serveur au moyen de l'envoi de la réponse.

NB : thread = tâche => multi thread = multi tâches

Schéma client et serveur HTTP

1.1. Côté serveur

Lorsqu'une requête arrive sur le serveur, elle peut concerner :

Une page HTML statique. Tout son contenu est déjà défini en HTML et le serveur n'a qu'à l'envoyer, tel quel, au client.

Une page HTML dont certains éléments sont dynamiques, c'est-à-dire qu'ils sont construits à partir de sources d'informations diverses au moment de l'envoi au client. Ces méthodes ont pour but de produire deux fournitures d'informations typiquement impossibles à réaliser simplement avec des pages purement statiques :

Des informations qui sont le résultat d'un calcul à partir d'éléments que le client a transmis au serveur dans sa requête.
Des informations issues d'une base de données mise à jour par un moyen quelconque. Ces informations peuvent évoluer à tout instant et leur affichage via HTTP nécessite leur intégration en temps réel dans le document.
Les deux cas précédents en même temps.

Plusieurs possibilités existent pour réaliser de telles opérations :

Les CGI.
Des langages plus spécialisés comme PHP ou ASP.

Ces technologies sont dites "Server Side", c'est à dire que les traitements sur l'information sont effectués sur le serveur.

L'avantage du "server side" est que le code HTML reçu par le client est du HTML pur, ce qui veut dire qu'à priori, tout navigateur peut l'afficher correctement, sans trop de précautions particulières de la part de l'auteur du site.

L'inconvénient est que le serveur voit sa charge augmenter dans des proportions qui peuvent être considérables et qu'en cas de connexion lente, la navigation devient vite pénible, lorsqu'il y a beaucoup de traitement d'informations introduites par le client, comme des calculs exécutés à partir de données issues d'un formulaire.

1.2. Côté client

De ce côté là aussi, des traitements d'informations peuvent être utiles.

Contrôler par exemple la validité des informations saisies dans un formulaire, avant de les envoyer au serveur. Ca évite des allers-retours inutiles en cas de saisie erronée.

Effectuer un traitement local de certaines informations pour afficher un résultat. Un exemple serait d'inclure une calculette dans une page web, cette calculette travaillant uniquement chez le client, sans jamais rien envoyer au serveur.

Réaliser toutes sortes d'opérations susceptibles de rendre les pages visitées plus vivantes, en introduisant des animations, des menus déroulants et toutes sortes de choses propres à améliorer une page web.
Là encore, les données peuvent être traitées, de diverses manières :

Les JavaScripts. Ces petits applicatifs, transmis dans le document HTML, sont exécutés côté client par le navigateur. Malheureusement, chaque navigateur a une notion plus ou moins personnelle de l'interprétation de JavaScript et c'est un véritable casse-tête pour le concepteur que d'écrire des scripts qui fonctionnent sur la totalité des navigateur existants, même si un effort de standardisation a été entrepris sur les dernières versions.
Les VBScripts. C'est la même philosophie que pour le JavaScript, à part que c'est du Visual Basic,propriété de Microsoft, qui ne fonctionne donc que sur Internet Explorer. Si la solution est intéressante dans un Intranet, où l'on maîtrise l'installation des postes clients, elle devient inexploitable sur l'Internet.
Les composants ActiveX qui sont des exécutables compilés, qui ne peuvent s'exécuter eux aussi que dans Internet Explorer, c'est également une technologie propriétaire de Microsoft. Très intéressante sur le principe, elle n'est en pratique utilisable de façon acceptable que sur un intranet.
Les applets Java qui sont comparables aux composants ActiveX, mais qui ont des chances de s'exécuter correctement sur tout navigateur, si une machine virtuelle Java est installée. Ces deux technologies présentent malheureusement de gros risques de sécurité. NB : Java est un langage objet qui nécessite d'être compilé, interprété.
Les "plug-in". Ce sont des composants enfichables qui étendent les possibilités intrinsèques des navigateurs, comme l'affichage de documents "flash" par exemple.

Les avantages sont de deux sortes :

Tout traitement de données réalisé localement est rapide et sans surcharge pour le serveur.
Les effets d'animation, comme les menus déroulants ou les bandeaux défilant ne peuvent être que réalisés localement.

Les inconvénients viennent des incompatibilités entre navigateurs et des trous de sécurité introduits par des exécutables téléchargés sur le client, issus d'origines qui peuvent être malveillantes.

Pour palier à l'incompatibilité entre navigateurs, que faire? Utiliser VMware ou virutal box, pour tester les pages réalisées sous d'autres systèmes d'exploitation actuels ou anciens , et surtout sur d'autres navigateurs actuels ou anciens (ex InternetExplorer 6 sur Windows XP). Des sites internet permettent aussi de trouver des astuces : une feuille de style A chercher.

1.3. Les messages

Les messages HTTP sont normalement adressés par le client HTTP et reçoivent une réponse du serveur HTTP. Les messages de requête comportent une ligne requête qui affiche la requête; les messages de réponse contiennent une ligne de statut qui affiche la réponse, puis un corps de message (ou entité) qui affiche les données réelles.

1.4. Commandes

Grâce à l'add-on de firefox appelé firebug, et en cliquant sur réseau, nous voyons le dialogue entre le navigateur (le client) et le site (le serveur). On va remarquer qu'une requête ressemble à un mail, est structurée comme . On voit ainsi le moteur de l'http, la face cachée de l'http, cachée par les navigateurs.
On remarque qu'une seule page nécessite plusieurs requêtes pour "avoir" les textes, les images, les scripts. On voit ainsi la construction de la page et ses différents éléments. On peut voir les liens qui ne fonctionne plus puisque la reponse à la requête admet un code d'erreur, ex 204 No Content. On peut aussi obtenir le CSS d'une page, ou son code source. On voit aussi le temps nécessaire à l'ouverture de la page et des éléments. A approfondir.

En comparaison d'autres protocoles, HTTP a très peu de commandes (connues aussi sous l'appellation de méthodes). Seules trois de ces méthodes – GET, HEAD et POST – sont nécessairement implémentées. Quatre autres méthodes – PUT, DELETE, LINK et UNLINK – sont également définies,
mais elles ne sont pas aussi largement répandues.

1.4.1. GET

La commande GET récupère une ressource d'un serveur et l'envoie à un client. La syntaxe de cette commande est la suivante : GET <URL> HTTP/1.0

Par exemple, un client HTTP demanderait le fichier index.html du serveur www.cnam-champagne-ardenne.fr à l'aide d'une commande GET comme suit : GET www.cnam-champagne-ardenne.fr/index.html HTTP/1.0

En utilisant le champ d'en-tête If-Modified-Since, une commande GET "conditionnelle" peut être réalisée, une ressource n'étant récupérée que si elle a été modifiée après une date donnée.

1.4.2. HEAD

La commande HEAD ressemble beaucoup à la commande GET, mais elle ne retourne que des méta informations sur l'URL sans retourner le fichier lui-même: il n'y a aucune entité dans la réponse. Les clients devraient employer la commande HEAD au lieu de la commande GET quand ils sont désireux de
tester des modifications d'URL, ou tout simplement la disponibilité de celles-ci.

1.4.3. POST

Tandis que les commandes GET et HEAD obtiennent l'information du serveur, la commande POST est utilisée pour envoyer des données d'un client à un serveur. La plupart des documents du Web sont en lecture seule et les utilisateurs de navigateurs Web n'envoient généralement pas de fichiers à leur
serveur. En revanche, les utilisateurs remplissent très souvent des formulaires HTML (demandant, par exemple, l'envoi d'un catalogue imprimé); l'information du formulaire HTML est envoyée du client HTTP au serveur HTTP par la méthode POST.

1.4.4. PUT

La commande PUT est moins commune que la commande POST (et n'est pas aussi largement supportée). Elle envoie des données du client HTTP au serveur HTTP.

1.4.5. DELETE

La commande DELETE est utilisée par un client HTTP pour dire au serveur HTTP d'effacer une URL spécifique sur le serveur. Elle n'est pas largement supportée, à cause de l'anonymat des clients HTTP et de l'accès en lecture seule des documents du Web.

1.4.6. LINK

La commande LINK est utilisée pour relier une URL spécifique à d'autres ressources. Elle n'est pas très répandue.

1.4.7. UNLINK

La commande UNLINK s'emploie pour supprimer les liens d'une URL spécifique avec d'autres ressources. Elle n'est pas très répandue.

1.5. Codes de statut

Les codes HTTP

HTTP définit un jeu de codes de statut, que les clients et les serveurs doivent comprendre pour pouvoir transférer des messages.

Ces codes se répartissent dans les catégories énumérées au tableau suivant :

Catégories de codes de statut	Numéro de code	Description
Informational	100-199	Messages spécifiques à l'application.
Successful	200-299	La requête a été traitée avec succès.
Redirection	300-399	Le client demande d'initier l'action suivante pour traiter la requête. Souvent fait par le client à l'insu de l'utilisateur.
Client Error	400-499	Problèmes relatifs au client.
Server Error	500-599	Problèmes relatifs au serveur.

Chaque code de statut HTTP comprend une valeur numérique suivie d'une chaîne de texte, qui peut inclure des méta informations supplémentaires. Le tableau suivant énumère les codes de statut et leur description. Les codes de statut sont définis dans les spécifications HTTP; ils peuvent de même être définis par des applications.

Description du code de statut	Description
200 OK	Aucune erreur, la requête a réussi.
201 Created	La requête POST a été exécutée.
202 Accepted	La requête asynchrone a été reçue. La requête a été acceptée mais n'a pas nécessairement entraîné une action.
204 No Content	La requête a réussi, mais il n'y a rien à afficher pour le client; c'est une méta information utile pour des réponses qui n'ont pas à être soumises à l'utilisateur.
300 Multiple Choices	La ressource demandée est disponible depuis divers emplacements. La liste des choix est retournée dans la réponse. Le choix préféré du serveur est inclus dans le champ location de la réponse.
301 Moved Permanently	L'URL demandée a été définitivement déplacée à une nouvelle adresse (précisée dans le champ Location de la réponse); toutes les références subséquentes à cette ressource devraient employer la nouvelle URL.
302 Moved Temporarily	L'URL demandée a été temporairement déplacée à une nouvelle adresse (précisée dans le champ Location de la réponse); toutes les références subséquentes à cette ressource devront continuer à employer l'URL d'origine.
304 Not Modified	La requête conditionnelle GET a fonctionné; cependant, le document n'a pas été modifié depuis la date dans le champ If-Modified-Since.
400 Bad Request	La requête n'a pas été comprise; le client devrait envoyer une requête mise à jour.
401 Unauthorized	Si c'était une requête anonyme, elle doit être authentifiée; si c'était une requête authentifiée, elle est refusée.
403 Forbidden	Le serveur n'est pas disposé à accepter la requête; souvent dû à une autorisation invalide.
404 Not Found	Le serveur n'a pas trouvé l'URL spécifiée.
500 Internal Server Error	Une erreur inattendue du serveur est survenue.
501 Not Implemented	Le serveur ne supporte pas cette requête.
502 Bad Gateway	Le serveur proxy/passerelle a reçu une réponse invalide du serveur qu'il contactait.
503 Service Unavalaible	Le serveur est temporairement incapable ou non disposé à traiter la requête; c'est normalement dû à la maintenance ou à la surcharge du serveur.

1.6. Les champs d'en tête

Les messages HTTP disposent d'une variété de champs d'en-tête susceptible d'être utilisés dans des requêtes et réponses. Certains s'emploient spécifiquement pour des requêtes de clients, d'autres pour des réponses de serveur. Quelques-uns ne sont pas supportés par certains clients ou serveurs. Les
champs sont décrits dans les sections suivantes.

1.6.1. Accept

Le champ Accept énumère les types de médias utilisables dans les requêtes et les réponses. La plupart des clients indiquent que tous les types de médias sont acceptables en utilisant un astérisque(*) dans ce champ; ils passent les types de médias inconnus à l'utilisateur, lui demandant d'associer le type MIME pertinent.

1.6.2. Accept-Charset

Ce champ énumère les jeux de caractère – en dehors du jeu US-ASCII et ISO-8859-1 – que le client peut supporter.

1.6.3. Accept-Encoding

Ce champ s'apparente au champ Accept mais limite les valeurs de réponse acceptables de Content-Coding.

1.6.4. Accept-Language

Le champ Accept-Language est similaire au champ Accept mais limite le nombre de langues utilisables dans la réponse.

1.6.5. Allow

Le champ Allow énumère les commandes (GET, HEAD, etc.) supportées par le serveur (et permises ainsi par le client).

1.6.6. Authorization

Ce champ est requis pour les serveurs HTTP qui n'autorisent pas l'accès anonyme à certaines ressources. Il envoie les références d'utilisateurs avec la requête.

HTTP fournit un mécanisme simple d'authentification question- réponse, à employer quand l'accès anonyme n'est pas approprié. Il autorise aussi les mécanismes d'authentification multiples. Dans le mécanisme d'authentification HTTP de base, le nom de l'utilisateur et le mot de passe sont encryptés à
l'aide de l'encodage non sécurisé MIME base64. D'autres clients et serveurs HTTP supportent des méthodes plus sécurisées, telle que la méthode Microsoft Windows NTLM.

En conjonction avec une réponse "401 Unauthorized", le serveur inclut un champ d'en-tête WWW-Authenticate, décrivant les méthodes d'authentification qu'il supporte. Le client soumet alors à nouveau la requête, incluant un champ d'en-tête supplémentaire d'autorisation avec les références de l'utilisateur à l'intention d'un mécanisme d'authentification. Si le serveur n'accepte pas ces références, il répond par le code de statut "403 Forbidden".

1.6.7. Content-Encoding

Ce champ décrit le mécanisme d'encodage (compression, par exemple) des supports utilisés pour décoder les données.

1.6.8. Content-Language

Le champ Content-Language décrit la langue naturelle de l'audience visée.

1.6.9. Content-Length

Ce champ décrit la taille du corps de message envoyé. Pour la commande HEAD, il indique la taille des données si la commande GET a été utilisée.

1.6.10. Content-Type

Ce champ décrit le type de contenu du corps du message. Le champ Content-Type est normalement de type "texte/html" pour les documents HTML. Pour la commande HEAD, ce champ indique le type des données si la commande GET a été utilisée

1.6.11. Date

Ce champ indique la date et l'heure d'émission du message.

1.6.12. Expires

Le champ Expires donne la date et l'heure à l'issue desquelles les données devraient être considérées comme invalides. Bien que ce champ ne force pas le rafraîchissement des données, les clients HTTP ne doivent plus placer les données dans leur cache après cette date d'expiration. Un format de date à 0
(bien qu'invalide) indique que les données expirent aussitôt.

1.6.13. From

Ce champ donne l'adresse e-mail de l'utilisateur qui envoie une requête. Il est utilisé pour des raisons de suivi, dans le but d'authentifier l'utilisateur. Les clients HTTP automatiques, tels que les robots, doivent inclure l'adresse e-mail d'une personne responsable du pilotage du robot, pour le cas où il y
aurait des erreurs.

1.6.14. If-Modified-Since

Ce champ date/heure s'emploie comme modificateur avec la commande GET, pour n'obtenir la ressource que si elle a été modifiée depuis cette date; il est pratique en liaison avec les caches des clients. Si rien n'a changé, le code de statut "304 Not Modified" sera retourné.

1.6.15. Last-Modified

Ce champ note la date de dernière modification des données.

1.6.16. Link

Le champ Link fournit l'état des relations et des liens entre les données et une certaine autre ressource, une structure hiérarchique et des chemins de navigation.

1.6.17. Location

Ce champ définit l'URL exacte à laquelle est située la ressource, en cas de redirection automatique (codes de statut 300-399).

1.6.18. MIME-Version

Ce champ indique la version du protocole MIME utilisée.

1.6.19. Pragma

Le champ Pragma est un champ d'emploi général, utilisé pour la mise en œuvre de directives spécifiques. Un paramètre commun est "no-cache"; il indique que les données ne devraient pas être placées en antémémoire.

1.6.20. Referer

Ce champ permet au client de préciser la provenance de l'URL qui a servi de vecteur à la requête. Cela facilite la détermination des "liens arrière", qui sont utilisés pour dépister les liens brisés et déterminer l'origine des revenus publicitaires. Ces liens peuvent constituer par nature une information privée; de
fait, les clients HTTP devraient inclure dans l'interface utilisateur une option de désactivation de ce champ; malheureusement, les navigateurs les plus populaires du moment ne le font pas.

1.6.21. Retry-After

Ce champ précise une plage horaire dans laquelle les services seront indisponibles. Il est utilisé en relation avec le code de statut "503 Service Unavailable".

1.6.22. Server

Ce champ définit le nom et la version du serveur HTTP.

1.6.23. Title

Ce champ indique le titre descriptif de l'entité.

1.6.24. URI

Ce champ énumère certains des URI (Uniform Resource Identifiers : identifiant de ressources uniformes) que cette ressource peut rendre disponibles.

1.6.25. User-Agent

Ce champ définit le nom et la version du client HTTP (le navigateur, par exemple).

1.6.26. WWW-Authenticate

Ce champ s'emploie pour les accès personnalisés, utilisant un simple schéma d'authentification question/réponse. L'information sur les références n'est pas encryptée. Pour plus d'information, consultez la sous-section décrivant le champ Authorization, plus haut dans cette section.

2. HTTP 1.1

La version actuelle de HTTP est la version 1.1. Elle est supportée par tous les clients majeurs (navigateurs) et les serveurs Web. HTTP 1.1 est décrit dans le document RFC 2068. Les changements notables dans HTTP 1.1 (par rapport à HTTP 1.0) ont trait à l'amélioration des performances (voir
http://www.w3..org/Protocols/HTTP/Performance pour les détails complets sur l'amélioration des performances et les études de cas).
Les changements apportés à HTTP 1.1 sont les suivants:

Connexions permanentes. HTTP 1.1 paramètre un peu moins de connexions TCP que HTTP 1.0. HTTP 1.0 établit et supprime une connexion TCP pour chaque requête d'application HTML. HTTP 1.1 crée une connexion TCP permanente pour des requêtes multiples. Ce faisant, un TCP unique peut exécuter plusieurs requêtes. Les connexions permanentes fournissent de meilleures performances que l'extension HTTP de Netscape appelée "Keep Alive", parce qu'elles opèrent plus efficacement dans un environnement impliquant des serveurs proxy.
Compression. HTTP 1.1 supporte la compression/décompression de fichiers; ces derniers peuvent être transférés entre un client et un serveur dans un format compressé, ce qui réduit la charge du réseau.
Hébergement virtuel. HTTP 1.1 supporte un seul réseau Web (avec une adresse IP unique), mais le serveur serveur peut avoir plusieurs noms de domaines. Cette situation est fréquente, en particulier si l'on considère les prestataires de service Internet (ISP) qui hébergent de nombreux domaines.
HTTP 1.1 supporte de multiples langues.
HTTP permet les transferts de plages d'octets; cela signifie que l'on peut sélectionner des portions d'un document ou d'un fichier à transférer. C'est surtout utile quand une connexion TCP est abandonnée: il n'est plus nécessaire, à la reprise de la connexion, de reprendre le transfert depuis le début: celui-ci peut commencer à partir du dernier point de contrôle connu.

3. FTP

Description du protocole FTP
Définition du protocole FTP

En utilisant un logiciel FTP tel que Filezila, dans la première grande partie, sous hôte, identifiant, mot de passe et port, on peu tlire toutes les commandes et les réponses du serveur FTP. Comme pour le protocole HTTP, il existe une liste de commandes, de codes qui expriment les échanges entre le client et le serveur.
Question : comment faire fonctionner fileZila en mode passif? Et quel intérêt?

Le client ouvre une session FTP sur un serveur. Un serveur FTP requiert une identification du client. Il existe souvent un compte "anonyme", qui donne accès en lecture seule dans la partie publique du serveur, mais il existe également des parties privées où les clients disposant d'un compte pouvant
accéder en écriture sur certains répertoires de l'arborescence. C'est le cas, par exemple, pour les mises à jour de pages web personnelles.

Schéma client-serveur FTP

La première chose que l'on constate, c'est que, contrairement à d'autres protocoles comme HTTP,
nous allons ici utiliser deux canaux distincts :

L'un pour l'échange des commandes du protocole,
l'autre pour le transfert des données.

Le client FTP, par l'intermédiaire de l'interface utilisateur, va cacher les diverses commandes du protocole FTP par des manipulations plus conviviales, en proposant à l'utilisateur une vision des choses similaire à un gestionnaire de fichiers. Avec des cliques et des "glisser/déposer" l'utilisateur exploitera FTP sans en connaître les commandes.

3.1. Mode Actif

Le mode actif pose problème lorsque le client est derrière un firewall, car le serveur essayera de se connecter sur le port 1027, ce qui lui est interdit. Pour répondre à ce problème, le mode passif a été normalisé.

Schéma mode actif FTP

3.2. Mode PASSIF

Dans le cas du mode passif, que vous signalez au serveur grâce à la commande PASV, le serveur n’essayera pas de se connecter au client, il restera passif. C’est le client qui effectue toutes les tentatives de connexion. Un problème persiste cependant, si les deux machines, client et serveur, sont
derrière un firewall. Dans ce cas, il sera nécessaire de préciser au serveur les ports de communication qu’utilisera le logiciel pour accepter les connexions du client, et demander à l’administrateur du firewall d’adapter ses règles avec votre configuration.
Schéma mode passif FTP

3.3. le mode de transfert

Stream : les données sont transmises comme une séquence d'octets
Block : les données sont transmises par blocs de taille variable; chaque bloc commence par un descripteur suivi d'une valeur de 16 bits indiquant le nombre d'octets de donnée. Permet d'insérer des points de reprise pour relancer le transfert à partir d'un de ces points en cas de rupture de connexion.
Compressed : plusieurs octets consécutifs identiques peuvent être encodés sur 2 octets (facteur de répétition + valeur à répéter). Ce mode comporte toutes les possibilités du mode block.

3.4. la structure du fichier

File : pas de structure à proprement parler. Le fichier est une simple séquence d'octets. Pour du texte, les lignes sont délimitées par <CRLF>
Record : le fichier est composé d'une séquence d'enregistrements (généralement un par ligne)
Page : généralement quand le fichier est destiné à une imprimante.

3.5. le type de représentation de l'information

ASCII : représentation par défaut. Le transfert se fait dans une représentation normalisée NVT-ASCII (NVT= Network Virtual Terminal). Il y a conversion entre la représentation interne et la représentation NVT-ASCII s'il y a lieu.
EBCDIC : le transfert se fait en représentation EBCDIC 8 bits. Cette représentation n'est généralement employée que si la représentation interne sur les deux machines est aussi EBCDIC, pour éviter des conversions inutiles.
Image : les données sont considérées comme une suite de bits contigus transférés par groupes de 8 bits.
Local : les données sont transférées en bytes "logiques" de n bits (n étant fourni en paramètre).
pour les types ASCII et EBCDIC, 3 formats de contrôle de l'avancement vertical peuvent être spécifiés : Non Print (pas d'information sur l'avancement vertical), Telnet (des caractères de contrôle (<CR>, <LF>, <VT>, <FF>) permettent de contrôler l'avance verticale, quand le fichier est destiné à une imprimante), Carriage (convention du FORTRAN, selon laquelle le premier caractère de chaque ligne n'est pas imprimé, mais sert plutôt à contrôler l'avancement vertical).

La commande store demande au serveur DTP d'accepter les données envoyées sur le canal de données et de les stocker dans le fichier portant le nom passé en paramètre. Si le fichier n'existe pas, le serveur le crée, sinon il l'écrase. Le port de donnée est le port 20. cf http://www.commentcamarche.net/contents/internet/ftp.php3

Côté serveur, le port de contrôle par défaut est le port 21 et le port de transfert de données est le port 20. Côté utilisateur, tout se fait par défaut sur le même port, qui est déterminé lors de la connexion initiale.

La connexion est démarrée par l'utilisateur, sur le port de contrôle du serveur (port 21). A la suite d'une commande de transfert, le serveur établit une connexion sur le port de données du client en mode stream, la fin des données est indiquée par la fermeture de la connexion de données -> peu fiable puisqu'on ne peut pas différencier fin de transfert et rupture inopinée de connexion. Les modes block et compressed permettent une procédure de redémarrage à partir de points de reprise définis par l'envoyeur du fichier.

Le serveur répond à chaque commande par un code de 3 chiffres, suivi d'un texte destiné à un humain. Le premier chiffre indique la catégorie de la réponse (positive préliminaire, positive finale, positive intermédiaire, négative transitoire, négative permanente), le deuxième chiffre indique ce qui
est concerné par la réponse (syntaxe, information, connexions, système de fichiers) et le troisième chiffre donne la signification précise de la réponse. Après l'envoi d'une commande, le client doit toujours attendre un code réponse avant d'envoyer une autre commande ou des données.

Pour transférer entre deux serveurs, il faut :

mettre un des deux en mode passif, à l'aide de la commande PASV (qui retourne l'adresse IP et le numéro de port sur lequel ce serveur passif s'est mis en attente d'une connexion), puis lui envoyer une commande de réception de fichier STOR,
indiquer à l'autre serveur (actif) l'adresse IP et le numéro de port utilisé par le serveur passif, à l'aide de la commande PORT,
envoyer au serveur actif la commande de transfert RETR.

Si les serveurs ne sont pas correctement configurés, ce mécanisme peut servir à contourner des mesures de restriction d'accès, ou à envoyer de manière détournée des informations (courrier électronique ou message de forum de discussion) en rendant difficile la détermination de la source
d'information. En effet, la commande PORT permet d'indiquer sur quel port d'une machine à distance le transfert de fichier aura lieu. Si ce port est un des ports par défaut employé par un protocole Internet et que le fichier est conçu pour correspondre à des commandes dans ce protocole, le transfert
de fichier peut résulter en une opération toute autre qu'un simple transfert de fichier. Par exemple, si la commande PORT est utilisée pour diriger les données sur le port 25 d'un serveur SMTP, le transfert de fichier peut résulter en l'envoi d'un message de courrier électronique. Il existe des versions sécurisées de serveurs FTP qui empêchent dans une grande mesure ce genre d'utilisation détournée.