La question est dans le titre. La raison pour laquelle je me pose cette question est parce que je code un service tcp et j'aimerais explorer certaines des raisons car elles pourraient éclairer mon travail.
Réponses
Trop de publicités?
Je m'attends à ce que l'utilisation d'un port différent simplifie la gestion de la connexion de données séparée attendue, qui sera dans un format différent de la connexion de contrôle. Je pense que cela permettrait au destinataire de simplement commencer le traitement des données sans avoir à vérifier s'il s'agissait d'une initiation de connexion comme il serait nécessaire de le faire s'il utilisait le port 21.
Cela permettrait à l'exemple du dernier point d'une imprimante à ligne de commencer à recevoir du texte à imprimer. Cependant, je ne suis pas sûr de savoir comment cela a été effectivement utilisé à l'époque (un programme sur le terminal redirigerait le port 20 vers leur imprimante à ligne parce qu'il pourrait déjà y avoir un démon FTP en écoute sur le 21?)
Quant à la raison d'une autre connexion, il y a trois raisons principales :
- Permettre l'utilisation du mode/taille de byte le plus efficace pour le transfert (https://www.rfc-editor.org/rfc/rfc310)
L'efficacité du transfert est un facteur important qui affecte l'utilité de FTP. Le transfert de fichiers peut être très coûteux (en termes de temps CPU) et lent (en temps réel) si une stratégie de transfert inappropriée est utilisée (par exemple, une taille de byte inappropriée). Tout devrait être fait pour optimiser le transfert de données. Une bonne stratégie pourrait être de permettre le transfert de fichiers sur une connexion séparée ou de fermer et rouvrir les connexions (en utilisant peut-être une taille de byte différente).
- Simplification de la gestion de la connexion de routine (https://www.rfc-editor.org/rfc/rfc114#ref-4)
[4] Nous avons envisagé l'utilisation de deux liens full-duplex, l'un pour les informations de contrôle, l'autre pour les données. L'utilisation d'un lien de contrôle séparé entre les processus coopérants simplifierait les abandons, les récupérations d'erreurs et la synchronisation.
- Capacité à envoyer la sortie à un autre périphérique (https://www.rfc-editor.org/rfc/rfc310)
Il serait souhaitable de modifier FTP pour permettre l'envoi de données à un socket spécifié dans un mode et un type spécifiés. Les utilisateurs du TIP trouveraient alors pratique d'obtenir la liste de leurs fichiers sur une imprimante à ligne à haute vitesse, d'entrer leurs fichiers à partir d'un lecteur de carte et de sauvegarder sur des cartes ou des bandes magnétiques.
David Spillett
Points
22424
Craig
Points
560
La sur-ingénierie n'est pas le cas. Il a été conçu de cette manière, de sorte que différents modes de fonctionnement sont autorisés. Le FTP actif est de nos jours rarement utilisé, car dans ce mode, le serveur se connecte de nouveau au client. Mais à l'époque - dans les années 80 - cela fonctionnait assez bien.
Le FTP passif est très utile derrière les pare-feu de nos jours, dans ce mode le client se connecte aux ports ouverts par le serveur; les clients ne sont généralement plus accessibles directement car ils ont un pare-feu/NAT/appareil devant eux. Ce mode a donc également du sens.
L'article de Wikipédia comporte des informations détaillées et intéressantes : http://fr.wikipedia.org/wiki/FTP
singingfish
Points
2653
FTP utilise un port pour la transmission de données (20) et un autre pour envoyer les commandes (21), GET, DIR, PUT, etc...
Une explication plus détaillée peut être trouvée ici: http://slacksite.com/other/ftp.html
HTH!
