En el diseño del protocolo, ¿por qué alguna vez usaría 2 puertos?

Question

Cuando un servidor TCP acepta un socket en un puerto, obtiene un nuevo socket para trabajar con ese cliente.
El socket aceptante sigue siendo válido para ese puerto y puede aceptar más clientes en ese puerto.

¿Por qué la especificación FTP original RFC 959 decidió crear un puerto de control y un puerto de datos?

¿Habría alguna razón para hacer esto en un protocolo personalizado similar?

Me parece que esto podría haberse especificado fácilmente en un solo puerto.

Teniendo en cuenta todos los problemas con los firewalls y los NATS con FTP, parece que un solo puerto hubiera sido mucho mejor.

Para una implementación de protocolo general, la única razón por la que podría pensar que desea hacer esto es para poder servir los archivos desde un host diferente del que los comandos van a utilizar.

Answer 1

La razón detrás de esto era inicial de modo que usted podría:

• seguir enviando y recibiendo instrucción de control de la conexión de control mientras se está transfiriendo datos.
• Tiene más de una conexión de datos activa al mismo tiempo.
• El servidor decide cuándo está listo para enviarle datos.

Es cierto que se podría haber logrado el mismo resultado mediante la especificación de un protocolo de multiplexación complicada integrado con el protocolo FTP, pero dado que en ese momento era un NAT no tema, se optó por utilizar lo que ya existía, los puertos TCP.

Aquí se muestra un ejemplo:

Alice quiere dos archivos de Bob. Alice se conecta al puerto de Bob 21 y pregunta por los archivos. Bob abre las conexiones al puerto 20 de Alice cuando está listo y envía los archivos allí. Mientras tanto, Charles necesita un archivo en el servidor de Alice. Charles se conecta con 21 en Alice y le pide el archivo. Alice se conecta al puerto 20 en Charles cuando está listo, y envía los archivos.

Como se puede ver, el puerto 21 es para el cliente que se conecta a los servidores y el puerto 20 es para los servidores que conectan a los clientes, pero los clientes todavía podría servir archivos en 21.

Ambos puertos tienen un propósito totalmente diferente, y nuevamente, por simplicidad, eligieron usar dos puertos diferentes en lugar de implementar un protocolo de negociación.

Answer 2

FTP es un protocolo antiguo. Esa es realmente la única razón. Los diseñadores pensaron que la cantidad de datos que fluye sobre el puerto de datos lo haría de modo que no pudieran enviar comandos de control de manera oportuna, por lo que lo hicieron como dos puertos. Los firewalls, y especialmente NAT, vinieron mucho más tarde.

Answer 3

En mi opinión, es solo una mala elección de diseño en primer lugar. En las viejas eras donde se inventó, el firewall y NAT no existían ... Hoy en día, la verdadera pregunta es más "¿por qué la gente todavía quiere usar FTP?" Todo lo que FTP hace se puede hacer usando HTTP de una mejor manera.

Answer 4

FTP tiene una historia muy larga, ya que fue uno de los primeros protocolos de ARPANET en los años setenta (por ejemplo, ver RFC114 from 1971). Las decisiones de diseño que pueden parecer extrañas ahora tenían más sentido. Las conexiones fueron mucho más lentas, y realizar el control de conexión "fuera de banda" probablemente pareció un buen movimiento con la tecnología de red disponible.

La corriente RFC959 incluye una buena sección de historia, que une a los RFC anteriores, si te apetece hacer un poco de arqueología ...

Answer 5

Creo que hicieron este modo que mientras una transferencia estaba ocurriendo que podría seguir trabajando con el servidor e iniciar nuevas transferencias fácilmente (si su cliente puede soportar esto).

Tenga en cuenta que el modo pasivo resuelve casi todos los problemas de firewall/NAT.

Answer 6

Porque FTP permite control e información por separado. IIRC, como se diseñó originalmente, podría tener 3 hosts: el host A podría solicitar al host B que envíe datos al host C.

Answer 7

Al igual que muchos de los protocolos de cable más antiguos, FTP es adecuado para ser utilizado por humanos. Es decir, es bastante fácil de usar FTP desde una sesión de terminal. Los diseñadores de FTP anticiparon que los usuarios podrían querer continuar trabajando con el host remoto mientras se transferían los datos. Esto hubiera sido difícil si el comando y los datos pasaran por el mismo canal.

Answer 8

FTP fue diseñado en un momento en que la estupidez de un firewall moderno era inconcebible. Los puertos TCP están diseñados para esta funcionalidad; multiplexar múltiples conexiones en una sola IP. Son NOT un sustituto de las Listas de control de acceso. Son NOT destinados a extender direcciones IPv4 a 48 bits, tampoco.

Cualquier nuevo protocolo que no sea IPv6 tendrá que lidiar con el desorden actual, por lo que debe ajustarse a un pequeño rango contiguo de puertos.

Answer 9

Debería echarle un vistazo al protcol RTSP + RTP. Es un diseño similar: cada flujo se puede enviar en un puerto diferente, y las estadísticas sobre jitter, reordenamiento, etc. se envían a otro puerto.

Además no hay conexión ya que es UDP. Sin embargo, se desarrolló cuando el cortafuegos ya tenía algo banal (lo siento por mi inglés), por lo que se desarrolló un modo donde toda esta conexión podía integrarse en una conexión TCP con sintaxis HTTP.

¿Adivina qué? El protocolo multipuerto es mucho más simple (IMO) que implementar el multiplexado http y tiene muchas más características. Si no le preocupa el problema del cortafuegos, ¿por qué elegir el esquema de multiplexación complicado cuando ya existe uno (puerto TCP)?

Answer 10

IETF ha prohibido la práctica de asignar más de un puerto para nuevos protocolos, por lo que es probable que no veamos esto en el futuro.

Los protocolos IP más nuevos, como SCTP, están diseñados para resolver algunas de las deficiencias de TCP que podrían llevar a uno a utilizar múltiples puertos. El bloqueo de "encabezado de línea" de TCP impide tener varias solicitudes/secuencias separadas en vuelo, lo que puede ser un problema para algunas aplicaciones en tiempo real.

Answer 11

IIRC, el problema no era que FTP utilizara dos (es decir, más de uno) puertos. El problema es que la conexión de control es iniciada por el cliente y el canal de datos fue iniciado por el servidor. La mayor diferencia entre FTP y HTTP es que en HTTP el cliente extrae datos y en FTP el servidor lo empuja.El problema de NAT está relacionado con el servidor que envía datos a través de un firewall que no sabe esperar la conexión.

El uso de FTP de puertos separados para el control y los datos es bastante elegante en mi humilde opinión. Piensa en todos los dolores de cabeza en HTTP que rodean la multiplexación de control y datos: piensa en los encabezados finales, las reglas que rodean las solicitudes canalizadas, las actualizaciones de conexión y otras cosas. Gran parte de eso se evita al separar explícitamente el control y los datos, sin mencionar que es posible hacer cosas interesantes como encriptar una y no la otra o hacer que el canal de control tenga una QoS más alta que los datos.