Dans la conception de protocole, pourquoi utiliseriez-vous jamais 2 ports?

Question

Lorsqu'un serveur TCP est accepté par un socket sur un port, un nouveau socket est utilisé avec ce client.
Le socket acceptant reste valide pour ce port et peut accepter d'autres clients sur ce port.

Pourquoi la spécification FTP originale RFC 959 a-t-elle décidé de créer un port de contrôle et un port de données?

Y aurait-il une raison de faire cela dans un protocole personnalisé similaire?

Il me semble que cela aurait pu être facilement spécifié sur un seul port.

Étant donné tous les problèmes de pare-feu et de NATS avec FTP, il semble qu’un port unique aurait été beaucoup mieux.

Pour une implémentation de protocole générale, la seule raison pour laquelle je pourrais penser que vous souhaitiez le faire est que vous pouvez servir les fichiers à partir d'un hôte différent de celui auquel les commandes sont destinées.

Answer 1

La raison initiale était que vous puissiez:

• Continuez à envoyer et recevoir des instructions de contrôle sur la connexion de contrôle pendant le transfert de données.
• Activer plusieurs connexions de données en même temps.
• Le serveur décide quand il est prêt à vous envoyer des données.

Certes, ils auraient pu obtenir le même résultat en spécifiant un protocole de multiplexage complexe intégré au protocole FTP, mais comme le NAT n’était pas un problème, ils ont choisi d’utiliser les ports TCP existants.

Voici un exemple:

Alice veut deux fichiers de Bob. Alice se connecte au port 21 de Bob et demande les fichiers. Bob ouvre les connexions au port 20 d'Alice lorsqu'il est prêt et envoie les fichiers à cet emplacement. Pendant ce temps, Charles a besoin d’un fichier sur le serveur d’Alice. Charles se connecte à 21 sur Alice et demande le fichier. Alice se connecte au port 20 sur Charles lorsque celui-ci est prêt et envoie les fichiers.

Comme vous pouvez le constater, le port 21 est réservé aux clients se connectant à des serveurs et le port 20 à des serveurs se connectant à des clients, mais ces clients pouvaient toujours servir des fichiers sur 21.

Les deux ports ont un objectif totalement différent et, dans un souci de simplicité, ils ont choisi d'utiliser deux ports différents au lieu de mettre en œuvre un protocole de négociation.

Answer 2

Parce que FTP permet un contrôle et des données séparés. IIRC, tel que conçu à l’origine, vous pouvez avoir 3 hôtes: l’hôte A peut demander à l’hôte B d’envoyer des données à l’hôte C.

Answer 3

FTP a été conçu à une époque où la stupidité d’un pare-feu moderne était inconcevable. Les ports TCP sont destinés à cette fonctionnalité; multiplexer plusieurs connexions sur une même adresse IP. Ce ne sont PAS un substitut des listes de contrôle d'accès. Ils sont NOT destinés à étendre l’adresse IPv4 aux adresses 48 bits.

Tout nouveau protocole non IPv6 devra traiter le désordre actuel, il devrait donc s'en tenir à une petite plage de ports contigus.

Answer 4

FTP a une très longue histoire, il est l’un des premiers protocoles ARPANET au début des années 70 (par exemple, voir RFC114 de 1971 ). Les décisions de conception qui peuvent sembler étranges ont maintenant plus de sens. Les connexions étaient beaucoup plus lentes et la commande de connexion "hors bande" était activée. Cela semblait probablement aller de soi avec la technologie de réseau disponible.

La RFC959 actuelle contient une bonne section sur l'historique, qui renvoie aux RFC antérieures, si vous avez envie de faire un peu d'archéologie ...

Answer 5

Comme beaucoup de protocoles filaires plus anciens, le protocole FTP est adapté à une utilisation humaine. C’est-à-dire qu’il est assez facile d’utiliser FTP à partir d’une session de terminal. Les concepteurs de FTP prévoyaient que les utilisateurs souhaiteraient peut-être continuer à travailler avec l'hôte distant pendant le transfert des données. Cela aurait été difficile si la commande et les données passaient sur le même canal.

Answer 6

L'IETF a interdit la pratique d'attribuer plus d'un port à de nouveaux protocoles afin que cela ne se produise plus.

Les protocoles IP plus récents, tels que SCTP, sont conçus pour résoudre certains des inconvénients du protocole TCP pouvant conduire à l’utilisation de plusieurs ports. Le blocage "en tête de ligne" des protocoles TCP vous empêche d’avoir plusieurs requêtes / flux distincts en vol, ce qui peut poser problème pour certaines applications temps réel.

Answer 7

IIRC, le problème n’était pas que FTP utilise deux ports (c’est-à-dire plus d’un). Le problème est que la connexion de contrôle est initiée par le client et que le canal de données a été initié par le serveur. La différence la plus importante entre FTP et HTTP réside dans le fait que, dans HTTP, le client extrait les données et dans FTP, le serveur les envoie. Le problème de NAT est lié au fait que le serveur envoie des données via un pare-feu qui ne sait pas attendre la connexion.

L’utilisation par FTP de ports séparés pour le contrôle et les données est plutôt élégante, à mon humble avis. Pensez à tous les maux de tête liés au multiplexage du contrôle et des données dans HTTP: pensez aux en-têtes de suivi, aux règles relatives aux demandes en pipeline, aux connexions conservées, et à ce qui ne l'est pas. Une grande partie de cela est évitée en séparant explicitement contrôle et données, sans mentionner qu'il est possible de faire des choses intéressantes comme chiffrer l'un et pas l'autre ou faire en sorte que le canal de contrôle ait une QoS supérieure à celle des données.

Answer 8

Vous devriez jeter un coup d’œil sur le protocole RTSP + RTP. Sa conception est similaire: chaque flux peut être envoyé sur un port différent, et les statistiques sur la gigue, la réorganisation, etc. sont envoyées sur un autre port.

De plus, il n’ya pas de connexion puisque c’est UDP. Cependant, il a été développé quand un pare-feu était déjà banal (désolé pour mon anglais), alors un mode a été développé où toute cette connexion peut être intégrée dans une connexion TCP avec une syntaxe HTTP.

Devinez quoi? Le protocole multi-ports est beaucoup plus simple à mettre en œuvre (IMO) que celui multiplexé par HTTP et il a beaucoup plus de fonctionnalités. Si le problème de pare-feu ne vous concerne pas, pourquoi choisir un schéma de multiplexage complexe alors qu’il en existe déjà un (port TCP)?

Answer 9

FTP est un ancien protocole. C'est vraiment la seule raison. Les concepteurs pensaient que la quantité de données circulant sur le port de données leur permettrait d'éviter d'envoyer des commandes de contrôle en temps voulu. Ils l'ont donc fait en tant que deux ports. Les pare-feu, et particulièrement les NAT, sont arrivés beaucoup plus tard.

Answer 10

Je pense qu’ils ont agi de la sorte, tant qu’un transfert était en cours, vous pouviez continuer à travailler avec le serveur et commencer facilement de nouveaux transferts (si votre client pouvait le prendre en charge).

Notez que le mode passif résout presque tous les problèmes de pare-feu / NAT.

Answer 11

À mon avis, c’est un mauvais choix de conception au départ. Dans les temps anciens où il a été inventé, le pare-feu et le NAT n'existaient pas ... De nos jours, la vraie question est davantage de savoir "pourquoi les gens veulent toujours utiliser FTP". ? Tout ce que FTP fait peut être fait mieux avec HTTP.