¿Por qué las conexiones IP (todavía) usan números de puerto en lugar de nombres de puerto?

Los puertos, y cómo los usamos en TCP / IP, se desarrollaron muy temprano en la evolución de nuestros protocolos de red interconectados. Eso significa que fueron creados para ser manejados con los recursos de hosts y enrutadores en ese momento. Menciono los enrutadores porque, aunque su función principal es la capa 3, hacen mucho trabajo en la capa 4, donde viven los puertos. Cambiar la forma en que funcionan las ACL de redes (Lista de control de acceso – Wikipedia) es una trampa muy profunda e incluso deriva en el mundo regulatorio, ya que varios tipos de regulaciones y acuerdos de privacidad obligan al bloqueo del tráfico de varias maneras y las ACL a menudo son parte de eso, aunque no proporcionan la misma funcionalidad que un firewall con estado. Todo esto significa que cambiar el comportamiento de los puertos es potencialmente muy costoso y al menos requeriría una revisión de TCP y UDP para que los nuevos hosts puedan usar el nuevo estándar al tiempo que permiten que los sistemas más antiguos (y potencialmente muy ocupados) no lo hagan.

Por el lado de los beneficios, esta es una característica “agradable de tener” y no una que considero que tenga un gran impacto en la usabilidad. Primero, la gran mayoría de los usuarios en Internet ni siquiera saben que existen estos puertos de llamada y la mayoría de nuestras aplicaciones hacen un buen trabajo al ocultar esa complejidad. Si un usuario se ha encontrado con la configuración del puerto, probablemente sea en el contexto de la configuración de su cliente de correo electrónico en un entorno que no esté realizando la configuración automática para esa configuración. No puedo pensar en otra aplicación de uso común que realmente necesite esa información. Incluso los clientes FTP (que muy pocas personas usan hoy en día) tienen casi todos los puertos preconfigurados. Los navegadores web ocultaban el: 80 o: 443 al final de las URL desde el principio y la mayoría de las personas que navegan por la web nunca han ingresado un número de puerto, y mucho menos uno no estándar para una sesión HTTP. Los desarrolladores, ingenieros de red, diseñadores de sistemas y algunos otros son excepciones obvias, pero ese es un porcentaje muy pequeño de usuarios.

TL; DR Los beneficios serían para la mayoría de las personas no técnicas, ya que las personas técnicas ya entienden y los nuevos entrantes deben entender cómo encajan las piezas. Los costos para hacerlo y obtener RFC actualizadas a través del proceso para un beneficio relativamente pequeño no parece factible. Si tiene un caso de uso o beneficio en el que no pensé, ¡eso podría cambiar de opinión!

En la mayoría de los sistemas, existe un mecanismo para la resolución de nombres para puertos. En los sistemas compatibles con POSIX, hay un archivo (normalmente /etc/services ) que enumera los puertos conocidos, y la rutina estándar de la biblioteca C getservbyname buscará la entrada de servicio para un nombre de servicio dado y devolverá su número de puerto y protocolo válido ( s) El Servicio de información de red (NIS) de Sun se puede configurar para centralizar la búsqueda de datos del servicio. (NIS se considera obsoleto, pero hay tecnologías sucesoras). Esta tecnología ha existido desde finales de los años 80, si no antes.

También hay servicios de mapeo de puntos finales RPC (por ejemplo, Sun RPC, Microsoft RPC Endpoint Mapper) que permiten que un sistema solicite a un sistema remoto que identifique en qué puerto se proporciona un servicio en particular. El mapeador RPC se ejecuta en un puerto conocido (Sun usa 111, Microsoft usa 135); Los servicios proporcionados a través del mapeador RPC pueden ejecutarse en cualquier puerto y pueden asignarse dinámicamente. Microsoft Windows usa el mapeador de puntos finales RPC ampliamente. El mapeador Sun RPC también data de finales de la década de 1980; Microsoft ha existido desde al menos Windows NT 3.51 (y puede haber estado en versiones anteriores de NT).

Además, los servidores DNS de Microsoft (y otros) pueden usar DNS para resolver números de servicio a partir de nombres que utilizan registros SRV. Los registros SRV han sido un estándar (un RR DNS para especificar la ubicación de los servicios (DNS SRV)) desde 2000 y se utilizan mucho en la implementación del Active Directory de Microsoft.

Obviamente, la razón por la que los números de puerto todavía se usan es porque los encabezados de datagramas TCP y UDP solo tienen dieciséis bits asignados dentro de ellos para los números de puerto de origen y destino, y no hay forma de insertar un “nombre” en dieciséis bits. Lo más cercano que puede obtener es interpretar el número de dieciséis bits en radix32 (AZ más los dígitos 0–5 o, a veces, 2–7) o radix64 (AZ, az, 0–9, + y /), pero eso no es realmente eso útil: CP (radix32) o BP (radix64) no son más esclarecedores que 80 para el número de puerto WWW estándar y en cualquier caso solo obtienes tres (radix64) o cuatro (radix32) caracteres, y algunas combinaciones serán ilegales. Sería insensato, y sinceramente innecesario, modificar estos protocolos para permitir números de puerto arbitrariamente largos, no cuando ya existen mejores soluciones (como los servicios de mapeo de puntos finales, como se mencionó anteriormente).

Los nombres de los puertos significarían incluir un campo de longitud variable en cada encabezado de IP y realizar una búsqueda de diccionario para cada paquete entrante. Esto aumentaría enormemente el costo de procesamiento de los paquetes de enrutamiento (debido al encabezado de longitud variable) y de recibirlos (debido a la búsqueda en el diccionario). Y presentaría otra capa de complejidad administrativa: ¿cuánto tiempo pueden durar los nombres de puerto? ¿Dependiente del caso? ¿Espacios o códigos de control permitidos? Ascii-7 o Unicode UTF-que?

¿Y para qué ganar? Tienes que saber un número exacto o una cadena exacta para contactar un puerto. ¿Es uno realmente más fácil que el otro? Si desea nombres, simplemente agregue un servicio de resolución de nombre a puerto en un último puerto conocido. Haga una resolución de nombre de puerto a número al comienzo de la conexión y continúe como ahora. Pero el hecho de que nadie haya creado un servicio tan simple sugiere que hay poca necesidad de hacerlo.

La resolución de nombres para puertos existe (en cierto modo), sin embargo, no es una parte ampliamente admitida del protocolo DNS en el sentido de que el software que utiliza debe tener soporte incorporado.

Los servidores DNS modernos admiten el registro SRV (servicio), al que se puede llamar por nombre y devuelve un nombre de host y un puerto.

Cuando el software solicita el registro, devuelve un puerto y el nombre de host. Realmente solo he visto esto implementado en un par de piezas de software, pero nuevamente, realmente no he estado buscando.

¡Hay resolución de nombres para puertos!

Intente ejecutar `telnet http://www.google.com http`

Obtendrá lo mismo que si hubiera ejecutado `telnet http://www.google.com 80`, o` telnet 172.217.5.100 80`.

En la mayoría de los sistemas actuales, la forma en que se resuelven los hosts y servicios (puertos) se describe en su archivo `/ etc / nsswitch.conf`. Esto podría implicar buscar el nombre en un archivo local (como `/ etc / hosts` o` / etc / services`) o usar una base de datos de red (como nis o nisplus o dns).

La forma “moderna” de transmitir esta información a través de una red es con un registro SRV en el DNS (registro SRV – Wikipedia), como lo utilizan protocolos como SIP y XMPP (Jabber).

Debido a que los puertos no son globalmente únicos, no hay caso de uso allí

Por ejemplo

El puerto 80 es el puerto ‘universal’ para servidores http y todos los navegadores lo usan de forma predeterminada para http no cifrado

Pero esto es completamente arbitrario y se puede cambiar a lo que quieras. Puede usar el puerto 36555 para escuchar el tráfico http, no hay problema.

Funcionaría perfectamente, pero tendría que navegar, por ejemplo: http://www.quora.com:36555

Del mismo modo, puede usar perfectamente el puerto 80 para las conexiones VPN entrantes o el correo. No es convencional, pero funciona bien.

Cada PC puede escuchar en los puertos 65535, pero la forma en que se usan no está establecida en piedra.

Básicamente, las IP que pertenecen a sitios web son globalmente únicas y la cantidad de IP resueltas es demasiado grande para almacenar en cada PC, de ahí la necesidad de DNS. Pero en lo que respecta a los puertos, cada servidor web solo escucha en el puerto 80 según lo acordado convencionalmente. No veo el problema …

La estandarización de puertos solo es realmente importante cuando una organización determinada se conecta a dispositivos que no saben qué puerto usar. Por ejemplo, un navegador que se conecta a un sitio web sabe que el puerto 80 se usará para HTTP y el 443 se usará para HTTPS.
En realidad, cualquier puerto puede usarse para cualquier propósito siempre que ambas partes estén de acuerdo, por lo que tener una estructura de nombres podría ser útil si no desea usar puertos estándar, pero la pregunta es por qué querría hacer eso y agregar un capa de complejidad (y, por lo tanto, costo administrativo y superficie de ataque) a su red.
Además, hay formas de cambiar el puerto utilizado para una conexión determinada, pero después de que se haya conectado a un puerto estándar para la autenticación.

Debido a que es mucho más simple que los registros DNS estándar se resuelvan en una IP y la aplicación responda a un número de puerto específico.

De lo contrario, el DNS se volvería más complicado y desordenado sin una buena razón.

Puede implementar eso sin problemas y sin gastos generales significativos.

¿Pero vale la pena? Ya podemos diferenciar el tráfico para ir a múltiples puertos en el servidor con un equilibrador de carga, de modo que un nombre corresponda a un puerto específico. Esto es mucho mejor.

porque tiene un rango de puertos que son desconocidos y se usan al azar, y también creo que podría redirigir de puerto conocido a desconocido como parte de la seguridad, por lo que no sería posible