Discussion:File Transfer Protocol

Oops, oublié le commentaire: 16:46 jan 22, 2003 . . Ryo => correction de quelques accents manquants & ajout de FileZilla

PUT et GET ?

Bonjour à tous,

Dans la RFC, il n'est pas fait mention des commandes 'PUT', 'GET' (et certaines autres non plus). Les commandes officielles sont STOR (pour PUT) et RETR (pour GET). Il serait peut-être intéressant de le signaler dans le document qui dans sa forme actuelle laisse croire que les commandes principales sont celles respectant la RFC-959, alors que 'PUT' et 'GET' ressemblent plutôt à des alias pratiques sur les commandes STOR et RETR.

Qu'en pensez-vous ?

Suis entrain de implémenter un client et un serveur ftp et je trouve que les explications sur TFTP sont plus claire dans wikipedia. Je explique pour le transfert de fichier diviser en blocks et synchroniser le client et les serveur utilisant un ack à chaque fois que le client a fini de écrire le block il envoi un ack au serveur. Je trouve que ça serais bien que quelqu'un éclaircisse ça dans la page.

Compréhension

Dans Vue d'ensemble :

Pour accéder à un serveur FTP, on le mode actif, tandis que les données sont échangées

Pour un lecteur béotien (ou pour n'importe quel lecteur), merci d'ajouter un verbe après le 'on' pour une meilleure compréhension. Merci.jpm2112 16 octobre 2005 à 18:07 (CEST)

Erreur ?

Dans la description des différentes couches du réseau, le ftp est mis en 7. Alors que d'après mes souvenirs, le modèle TCP/IP est un modèle simplifié du modèle OSI et il n'y a qu'une couche application derriere la couche TCP. C'est d'ailleurs ce qui est montré dans la version anglaise. Mais je n'ai pas spécialement envie d'écrire des conneries, donc est ce qu'il y en a d'autre qui peuvent confirmer ?

wget est un client ftp ? c'est pas http ? Alainbb

En théorie, oui... mais en pratique...

En théorie, le protocol FTP est formellement défini. Mais en pratique, je n'ai jamais vu un seul serveur FTP respecter le protocol FTP. Je peux en parler pour avoir programmé un client FTP. C'est d'ailleurs à un tel degré que c'en est un cas unique à ma connaissance : une norme dont on parle comme si on ignorait complétement qu'elle n'est absolument pas appliquée, alors que du coté applicatif on ne peut pas ignorer qu'elle n'est pas appliquée (sans jeux de mot). Heureusement qu'on ne se moque pas de toutes les normes de la même manière qu'on s'est moqué de celle-ci. Là où je veux en venir maintenant, c'est qu'il serait peut-être interessant de parler aussi du protocol réel, celui qui est utilisé en pratique, qui n'a rien à voir avec le protocol officiel, qui s'est imposé par les faits, qui est devenu une norme de fait, et qui n'est pourtant formalisé par aucune RFC. De toute façon il me semble illusoire qu'un retour à l'ordre ai lieu un jour, parce qu'il produirait trop de désordre pour être sérieusement envisageable : raison de plus pour affronter la réalité et parler de cette norme de faits.

Qu'en pensez-vous ?

--Hibou57 29 décembre 2006 à 14:39 (CET)

On en pense que le protocole est un sommet de crétinerie, notamment au niveau de la sécurité. C'est un des rares protocoles qui est non-sûr sur une couche réseau sure. Un protocole où soit le client soit le serveur est vulnérable à un vol du fichier ou une corruption du fichier, selon le sens du transfert.

L'idée de standardiser un port ftp-data, par exemple, est une invention totalement inepte, motivée juste par le fait que les 'admin' veulent pouvoir bricoler un pare-feu idiot (pléonasme).

Quand au transfert direct entre serveurs, avec un flux de données brut sans format spécifique, c'est quand même une invitation à l'usurpation d'identité assez hallucinante. (Mais à quoi ils pensaient ?)

En plus quel intérêt franchement de séparer control et data ? Si c'est juste pour démontrer que le NAT est une aberration contraire à l'esprit d'IP, merci, c'est assez évident en soit.

Bref je ne comprends pas que ce protocole préhistorique soit encore utilisé. Mais s'il l'est ce n'est certainement pour tous ses gadgets débiles.

--Wcorrector (d) 25 novembre 2007 à 00:25 (CET)

Pffffou ! Que de bile déversée par Wcorrector en seulement quelques lignes !

Les prémices du protocole FTP datent ne l'oublions pas de 1971 tel que décrits dans le RFC 114, une époque où le réseau ARPNET comptait sans doute guère plus de 100 serveurs. Petit flash-back :

• à l'époque personne ne pensait un jour se faire voler/corrompre un fichier ;
• les firewalls n'existaient pas d'ailleurs leur concept pas encore non plus ;
• l'usurpation d'identité encore moins ;
• la séparation entre contrôle et données est naturellement venue d'un besoin humain d'interrompre un transfert qui semble prendre plus de temps que prévu ;
• et tout cela fonctionnait bien avant que le NAT ne soit inventé seulement pour tenter de faire survire IPv4 alors que ce protocole est depuis devenu "préhistorique" (sic).

FTP survit encore sans doute parce que des centaines (n’est-ce pas plutôt des milliers ?) de librairies/modules implémentant ce protocole pour un usage ou un autre existent encore et fonctionnent toujours parfaitement. Quoi qu’en ait écrit Hibou57 l’an dernier il n’est pas toujours nécessaire d’implémenter l’ensemble des spécifications d’un protocole pour pouvoir s’en servir.

Sans être un fervent de FTP (c'est moyennement capricieux à mettre en oeuvre), je reconnais que je connais peu de protocoles informatiques ayant survécu aussi longtemps (plus de 35 ans) avec si peu d'altérations : le besoin de transférer des fichiers n’a finalement jamais remis en cause ce fondement.

--Bub's (d) 29 novembre 2007 à 02:19 (CET)

Actif / Passif

La description des deux modes passif/actif n'ont ils pas étés inversés ?

217.112.48.155 28 novembre 2008 à 09:47 (CET)

Bonjour,

Ben non, en mode actif c'est bien le serveur auprès duquel le client s'est authentifié qui initie la connexion de données, voir à ce sujet le RFC 959 p. 6 la définition de « server-DTP. »

Bonne continuation. Bub's [di·co] 29 novembre 2008 à 01:06 (CET)

Range de ports tcp

Sur l'image "Connexion Data en mode actif" il est indiqué un range de 1024-65635 ça devrait être 1024-65535

Suppression

J'enlève la note Ce protocole peut fonctionner avec IPv4 et IPv6., ils ne sont pas sur les mêmes couches du modèle OSI donc complètement dissociable. C'est comme si je disais que IP est utilisable sur Ethernet et Wi-Fi, c'est évident. -Nmd (d) 29 décembre 2009 à 12:11 (CET)

Non, car les adresses IP sont transmises explicitement par le protocole pour établir la session data (commande PORT ou PASV), ce n'est donc pas évident. — mro ^[d] 29 décembre 2009 à 13:22 (CET)

Bah donc, il faudrait changer la phrase pour ne citer qu'il ne marche qu'exclusivement avec eux. non ?-Nmd (d) 29 décembre 2009 à 14:09 (CET)

Fusion File Transfer Protocol et File eXchange Protocol

Le FXP est variante du FTP et le peu d'informations contenu dans celui-ci poussent à ne faire qu'un. -Nmd ^(d) 22 janvier 2010 à 14:17 (CET)

Pour Zeugma fr (d) 22 février 2010 à 18:32 (CET)

Jerome66 14 avril 2010 à 09:02 (CEST)

Commentaire du lecteur : mauvais schémas : Établissement des connexions

193.57.67.241 a publié ce commentaire le 20 décembre 2013 (voir tous les retours).

mauvais schémas : port 65635 impossible, c'est 65535

Vous avez raison, les 2 schémas sont partiellement faux, le n° de port max est 2^16-1, soit 65535. Il faudrait modifier les dessins "Mode actif" et "Mode passif". Abaca (discuter) 27 janvier 2014 à 22:31 (CET)

Abaca (discuter) 27 janvier 2014 à 22:31 (CET)