ftp - registrados - En el diseño de protocolos, ¿por qué usarías 2 puertos?
puertos de red y sus funciones (11)
Al igual que muchos de los protocolos de cable más antiguos, el FTP es adecuado para el uso humano. Es decir, es bastante fácil 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 estaban transfiriendo los datos. Esto hubiera sido difícil si el comando y los datos estuvieran en el mismo canal.
Cuando un servidor TCP acepta un socket en un puerto, obtiene un nuevo socket para trabajar con ese cliente.
El socket de aceptación sigue siendo válido para ese puerto y puede aceptar más clientes en ese puerto.
¿Por qué la especificación de FTP RFC 959 original 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.
Dados todos los problemas con los firewalls y 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 querría hacer esto es para poder servir los archivos desde un host diferente al que van los comandos.
Creo que hicieron esto para que mientras ocurría una transferencia, usted pudiera continuar trabajando con el servidor e iniciar nuevas transferencias fácilmente (si su cliente podía admitir esto).
Tenga en cuenta que el modo pasivo resuelve casi todos los problemas de firewall / NAT.
Deberías echar un vistazo al protocolo RTSP + RTP. Es un diseño similar: cada flujo puede enviarse en un puerto diferente, y las estadísticas sobre jitter, reordenación, etc. se envían en otro puerto.
Además no hay conexión ya que es UDP. Sin embargo, se desarrolló cuando el firewall ya era algo banal (lo siento por mi inglés), por lo que se desarrolló un modo en el que toda esta conexión podría integrarse en una conexión TCP con sintaxis HTTP.
Adivina qué ? El protocolo multipuerto es mucho más simple (IMO) de implementar que el http multiplexado y tiene muchas más funciones. Si no le preocupa el problema del firewall, ¿por qué elegir un esquema de multiplexación complicado cuando ya existe uno (puerto TCP)?
El FTP se diseñó 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. NO son un sustituto de las listas de control de acceso. Tampoco están diseñados para extender IPv4 a direcciones de 48 bits.
Cualquier nuevo protocolo que no sea IPv6 tendrá que lidiar con el desorden actual, por lo que debe mantenerse dentro de un pequeño rango de puertos contiguos.
El IETF ha prohibido la práctica de asignar más de un puerto para nuevos protocolos, por lo que probablemente no veremos esto en el futuro.
Los protocolos IP más nuevos, como el SCTP, están diseñados para resolver algunos de los inconvenientes de TCP que podrían llevar a uno a usar varios puertos. El bloqueo de "cabecera de línea" de los TCP le impide tener múltiples solicitudes / flujos separados en vuelo, lo que puede ser un problema para algunas aplicaciones en tiempo real.
El razonamiento inicial detrás de esto fue para que pudieras:
- Continúe enviando y recibiendo instrucciones de control en la conexión de control mientras está transfiriendo datos.
- Tener 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 podrían haber logrado el mismo resultado al especificar un complicado protocolo de multiplexación integrado al protocolo FTP, pero como en ese momento el NAT no era un problema, optaron por usar lo que ya existía, los puertos TCP.
Aquí hay un ejemplo:
Alice quiere dos archivos de Bob. Alice se conecta al puerto 21 de Bob 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 a 21 en Alice y pide el archivo. Alice se conecta al puerto 20 en Charles cuando está listo y envía los archivos.
Como puede ver, el puerto 21 es para el cliente que se conecta a los servidores y el puerto 20 es para los servidores que se conectan con los clientes, pero esos clientes aún podrían 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.
En mi opinión, es solo una mala elección de diseño en primer lugar. En la antigüedad, donde se inventaba, el firewall y el NAT no existían ... Hoy en día, la pregunta real 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.
FTP es un protocolo antiguo. Esa es realmente la única razón. Los diseñadores pensaron que la cantidad de datos que fluyen a través del 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, llegaron mucho más tarde.
FTP tiene una larga historia, siendo uno de los primeros protocolos de ARPANET a principios de los años setenta (por ejemplo, consulte RFC114 de 1971 ). Las decisiones de diseño que pueden parecer extrañas ahora tienen más sentido entonces. 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.
El RFC959 actual incluye una buena sección sobre la historia, que se vincula a RFC anteriores, si te apetece hacer un poco de arqueología ...
IIRC, el problema no era que FTP use dos puertos (es decir, más de uno). 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 los empuja. El problema de NAT está relacionado con el servidor que empuja los datos a través de un firewall que no sabe que puede esperar la conexión.
El uso de FTP de puertos separados para control y datos es bastante elegante en mi humilde opinión. Piense en todos los dolores de cabeza en HTTP que rodean la multiplexación de control y datos: piense en los encabezados finales, las reglas que rodean las solicitudes segmentadas, las conexiones de conexión, y lo que no. Mucho de eso se evita separando explícitamente el control y los datos, sin mencionar que es posible hacer cosas interesantes como cifrar una y no la otra o hacer que el canal de control tenga una QoS más alta que la de los datos.
Porque FTP permite un control y datos separados. IIRC, como se diseñó originalmente, podría tener 3 hosts: el host A podría pedirle al host B que envíe datos al host C.