jueves, 23 de octubre de 2014

Direccionamiento en los protocolos de Capa de Transporte TCP / IP (TCP y UDP) : Puertos y sockets.

Bueno, terminado recién (después de tanto) aquí les va. Como siempre que pasa mucho tiempo, pasaron un buen de cosas estos meses por las que valdría la pena gastar tinta, trataremos de actualizarnos un poco. Entre las posibles nuevas entregas (sin contar la continuación de las Selecciones de la Guía) está todo lo relativo al asunto (al asuntote) de systemd, que ya me mordió una mano así que probablemente salga algo por ahí al respecto. Esto es continuación de la entrada de enero (lo correspondiente entre esta parte y esta otra, vendrán tiempos mejores, estoy seguro). De manera que esto viene a ser un viernes de redes (un jueves en la noche de hecho). Espero les sea de utilidad y hasta el siguiente ;-)

Direccionamiento en los protocolos de Capa de Transporte TCP / IP (TCP y UDP) : Puertos y sockets.
Las direcciones IP del protocolo de Internet (IP) son la manera universalmente usada de abordar el direccionamiento en redes TCP / IP. Estas direcciones de capa de red identifican de manera única cada interfaz de red, y como tal, sirven como el mecanismo mediante el cual los datos se encaminan a la red correcta en la interconexión de redes, y luego al dispositivo correcto en esa red. Lo que algunas personas no se dan cuenta, sin embargo, es que hay un nivel adicional de direccionamiento que se produce en la capa de transporte de TCP / IP, por encima de la de la dirección IP. Los dos protocolos de transporte TCP / IP, TCP y UDP, utilizan los conceptos de puertos y sockets a manera de direccionamiento virtual por software, para habilitar la función de muchas aplicaciones de forma simultánea en un dispositivo IP.

En esta sección describo el mecanismo especial que se utiliza para el direccionamiento en TCP y UDP. Empiezo con una discusión de los procesos de aplicación de TCP / IP, incluyendo la naturaleza cliente / servidor de la comunicación, que proporciona un fondo para explicar cómo se utilizan los puertos y sockets. Luego doy una visión general del concepto de puertos, y cómo estos habilitan la multiplexación de datos a través de una dirección IP. Describo la forma en que los números de puerto se clasifican en rangos, y se asignan a los procesos de servidor para aplicaciones comunes. Explico el concepto de los números de puerto efímeros utilizados para los clientes. Finalmente, discutiremos los sockets y su uso en la identificación de conexiones, incluidos los medios para que varios dispositivos pueden hablar a un solo puerto en otro dispositivo. Finalmente proporciono una tabla resumen de los números de puerto conocidos y registrados más comunes.
Yo creo que el lugar más razonable para comenzar a aprender acerca de cómo funciona el conjunto de protocolos TCP / IP es examinando el Protocolo de Internet (IP) en sí, y los protocolos de apoyo que funcionan en tándem con él en la capa de red. IP es la base sobre la cual se construye la mayor parte del resto de TCP / IP. Es el mecanismo por el cual los datos se empaquetan y se envían a través de una interconexión de redes TCP / IP.

Tiene sentido, entonces, que cuando se examina el funcionamiento de TCP / IP desde el punto de vista del protocolo de Internet, hablamos muy genéricamente sobre el envío y la recepción de datagramas. Para el software de la capa IP que envía y recibe datagramas IP, la aplicación de nivel superior desde la que vienen estos datagramas y a la que se dirigen a es realmente poco importante: para el protocolo IP "un datagrama es un datagrama", más o menos. Todos los datagramas se empaquetan y se envían de la misma manera, e IP se centra principalmente en los aspectos de bajo nivel de moverlos entre dispositivos de una manera eficiente.

Es importante recordar, sin embargo, que esto es realmente una abstracción, para la conveniencia de la descripción de las operaciones sobre la capa tres. No tiene en cuenta la forma en que son generados y utilizados los datagramas en realidad por encima de la capa tres. La capa cuatro representa un punto de transición entre las capas relacionadas con el hardware del modelo OSI (uno, dos y tres) y las capas relacionadas con el software (de cinco a siete). Esto significa que los protocolos de capa de transporte TCP / IP, TCP y UDP, si necesitan atender a la forma en que el software utiliza el protocolo TCP / IP, incluso si el protocolo IP no le presta atención a este particular.

En última instancia, todo el punto de tener redes, interconexiones de redes y protocolos como TCP / IP es permitir aplicaciones de redes. La mayoría de los usuarios de Internet utilizan estas aplicaciones a diario. De hecho, la mayoría de nosotros corre muchas aplicaciones diferentes al mismo tiempo. Por ejemplo, puede que esté utilizando un navegador World Wide Web para consultar las noticias, un cliente FTP para subir algunas fotos para compartir con la familia, y un programa de Internet Relay Chat para hablar de algo con un amigo o colega. De hecho, es común tener varias instancias de una sola aplicación. El ejemplo más común es tener varias ventanas del navegador Web abiertas (a veces me encuentro con nada menos que 30 a la vez!)

Multiplexación y demultiplexación
La mayor parte de la comunicación TCP / IP toma la forma de intercambios de información entre un programa que se ejecuta en un dispositivo y un programa equivalente en otro dispositivo. Cada instancia de una aplicación representa una copia del software de aplicación que necesita enviar y recibir información. Estas instancias de aplicación son comúnmente llamadas procesos. Un proceso de aplicación TCP / IP es cualquier pieza de software que envía y recibe información a través de la suite de protocolos TCP / IP de red. Esto incluye tanto las aplicaciones "clásicas" de los usuarios finales, tales como los descritos anteriormente, como los protocolos de soporte que se comportan como aplicaciones cuando envían mensajes. Ejemplos de esto último incluiría un protocolo de gestión de red como SNMP, o incluso el protocolo de enrutamiento BGP (que envía mensajes a través de TCP como lo hace una aplicación).

Por lo tanto, un host TCP / IP típico tiene múltiples procesos cada uno de ellos con la necesidad de enviar y recibir datagramas. Todos ellos, sin embargo, deben ser enviados utilizando la misma interfaz para la interconexión de redes, utilizando la capa IP. Esto significa que los datos de todas las aplicaciones (con algunas excepciones posibles) son "canalizados hacia abajo", inicialmente a la capa de transporte, donde es manipulado por TCP o UDP. A partir de ahí, los mensajes pasan a la capa IP del dispositivo, donde se empaquetan en datagramas IP y se envían por sobre la interconexión de redes a diferentes destinos. El término técnico para esto es la multiplexación. Este término significa simplemente combinación, y su uso aquí es análogo de software a la manera que se hace con las señales.

Un mecanismo complementario es responsable de la recepción de datagramas. Al mismo tiempo que la capa IP multiplexa los datagramas de muchos procesos de aplicaciones que se envían hacia fuera, recibe muchos datagramas que están destinados a diferentes procesos. La capa IP debe tomar este flujo de datagramas no relacionadas, y, pasarlos eventualmente al proceso correspondiente (a través del protocolo de capa de transporte por encima de ella). Esto es lo inverso a la multiplexación: demultiplexación. Usted puede ver una ilustración del concepto básico detrás de los procesos TCP/IP multiplexación y demultiplexación en la figura 197.


En una típica máquina que ejecute TCP / IP hay muchos protocolos y aplicaciones diferentes que se ejecutan simultáneamente. Este ejemplo muestra cuatro aplicaciones diferentes que se comunican entre un cliente y la máquina servidor. Los cuatro son multiplexados para su transmisión usando el mismo software  IP y la misma conexión física; los datos recibidos son demultiplexados y pasan a la aplicación apropiada. IP, TCP y UDP proveen los medios para distinguir entre los datos de las diferentes aplicaciones.

Concepto clave: TCP / IP está diseñado para permitir que múltiples aplicaciones envíen y reciban datos simultáneamente utilizando el mismo software de Protocolo de Internet en un determinado dispositivo. Para lograr esto es necesario multiplexar los datos transmitidos de muchas fuentes, a medida que se transmiten a la capa IP. A medida que se recibe un flujo de datagramas IP, se demultiplexa y los datos adecuados son entregados a cada instancia de software de aplicación en el host de destino.

Procesos de cliente y servidor TCP / IP.
Hay otra característica del software TCP / IP que es muy importante para comprender  cómo la capa de transporte y las capas superiores de la suite operan: la capa IP es generalmente asimétrica. Esto significa que cuando un proceso de aplicación de TCP / IP en un equipo trata de hablar con un proceso de aplicación en otro equipo, los dos procesos por lo general no son exactamente los mismos. Son en cambio complementos el uno del otro, diseñados para funcionar juntos como un equipo.

Como he explicado en la descripción del panorama general de TCP / IP, la mayoría de las aplicaciones de redes utilizan un modelo de operación cliente / servidor. Este término puede ser utilizado para hacer referencia a las funciones de los ordenadores, donde un servidor es una máquina relativamente poderosa que brinda servicios a un gran número de clientes accionados por el usuario. También se aplica a software. En este contexto, un proceso cliente es generalmente uno que se ejecuta en una máquina cliente y inicia el contacto para llevar a cabo algún tipo de función. Un proceso servidor por lo general se ejecuta en un servidor de hardware, y escucha las peticiones de los clientes y responde a estas.

El ejemplo clásico de esto es, por supuesto, la World Wide Web. La WWW utiliza el Protocolo de transferencia de hipertexto (HTTP), un buen ejemplo de un protocolo de aplicación. Un navegador Web es un cliente HTTP, ejecutándose normalmente en un equipo cliente del usuario final, como el que usted probablemente está utilizando en este momento. Se inicia un intercambio de datos HTTP (web) mediante el envío de una petición a un servidor (HTTP) Web. Un proceso servidor en dicho servidor Web escucha la solicitud y responde ya sea con el artículo solicitado - una página web u otro mensaje de datos - o un error. El servidor está generalmente específicamente diseñado para manejar muchas peticiones de clientes entrantes, y en muchos casos para poco más.

Está bien, prácticamente puedo ver la mirada impaciente en tu cara preguntándote: "¿por qué me está diciendo todo esto en una sección que se supone que explica los puertos TCP y UDP"? Las respuestas se harán evidentes en breve, lo prometo. Empecé aquí debido al que el hecho de que muchos procesos de aplicaciones se ejecuten de forma simultánea y sus datos sean multiplexados para su transmisión es la razón por la que  es necesario un sistema de direccionamiento de nivel superior en TCP / IP. La disposición cliente / servidor utilizada por TCP / IP tiene un impacto importante en la forma en que se utilizan los puertos y de los mecanismos para los cuales son asignados. Los siguientes dos temas exploran estos conceptos de forma más completa.

Un host típico en una interconexión de redes TCP / IP tiene muchos procesos de aplicaciones diferentes ejecutándose simultáneamente. Cada uno genera datos que envía a TCP o UDP, que a su vez se lo pasa a IP para su transmisión. Este flujo multiplexado de datagramas es enviado por la capa IP a varios destinos. Al mismo tiempo, la capa IP de cada dispositivo recibe datagramas que se originaron en numerosos procesos de aplicación en otros hosts. Estos deben ser demultiplexados, de modo que terminen en el proceso correcto en el dispositivo que los recibe.

Multiplexación y demultiplexación Usando Puertos
La pregunta es: ¿cómo podemos Demultiplexar una secuencia de datagramas IP que necesita llegar ir a muchos procesos de aplicación diferentes? Vamos a considerar un host en particular con una sola interfaz de red que tenga la dirección IP 24.156.79.20. Normalmente, todos los datagramas recibidos por la capa IP tendrá este valor en el campo de dirección de destino IP. Varios datagramas consecutivos recibidos por IP pueden contener un pedazo de un archivo que ud esta descargando con el navegador Web, un correo electrónico enviado a usted por su hermano, y una línea de texto que escribió un compañero en un canal IRC. ¿Cómo sabe la capa IP qué datagramas van a donde, si todos tienen la misma dirección IP?

La primera parte de la respuesta está en el campo de Protocolo incluido en la cabecera de cada datagrama IP. Este campo contiene un código que identifica el protocolo que envió los datos en el datagrama IP. Dado que la mayoría de aplicaciones de usuario final utilizan TCP o UDP en la capa de transporte, el campo de  Protocolo en un datagrama recibido le indica al protocolo IP que le pase los datos sea a  TCP o UDP según corresponda.

Por supuesto, esto sólo le pasa el problema a la capa de transporte: TCP y UDP son utilizados por muchas aplicaciones a la vez. Esto significa que todavía TCP o UDP deben averiguar a qué proceso deben enviar los datos. Para hacer esto posible, es necesario un elemento de direccionamiento adicional. Esta dirección permite una identificar una localización mas especifica -- un proceso de software -- dentro de una dirección IP particular.  En TCP / IP, esta dirección de capa de transporte se llama puerto.

Concepto clave: El direccionamiento en la capa de transporte TCP / IP se lleva a cabo utilizando los puertos TCP y UDP. Cada número de puerto dentro de un dispositivo IP en particular identifica un proceso de software en particular.

Números de Puerto de origen y destino 
En ambos mensajes UDP y TCP aparecen dos campos de direccionamiento, para un puerto de origen y un puerto de destino. Estos son análogos a los campos de dirección de origen y dirección de destino en el nivel IP, pero a un mayor nivel de detalle. Estos números de puerto identifican el proceso origen en la máquina de origen, y el proceso de destino en la máquina de destino. Ambos son llenados por el software TCP o UDP antes de la transmisión, y se utilizan para dirigir los datos al proceso correcto en el dispositivo de destino.

Los números de puerto TCP y UDP tienen 16 bits de longitud, por lo que los números de puerto válidos pueden tomar teóricamente valores de 0 a 65535. Como veremos en el siguiente tema, estos valores se dividen en rangos para diferentes propósitos, con ciertos puertos reservados para usos particulares.

Un hecho que a veces es un poco confuso es que tanto UDP como TCP utilizan el mismo rango de números de puertos, y son independientes. Así que, en teoría, es posible que el número de puerto UDP 77 se refiera a un proceso de aplicación y el número de puerto TCP 77 se refiera a otro proceso completamente distinto. No hay ninguna ambigüedad, al menos desde la perspectiva de los ordenadores, ya que como se ha mencionado anteriormente, cada datagrama IP contiene un campo de protocolo que especifica si porta un mensaje TCP o un mensaje UDP. El protocolo IP le pasa el datagrama a TCP o UDP, que luego envían el mensaje al proceso correcto utilizando el número de puerto en el encabezado TCP o UDP. Este mecanismo se ilustra en la Figura 198.

Esta es una versión más "concreta" de la figura 197, que muestra cómo se utilizan los puertos TCP y UDP para realizar la multiplexación y demultiplexación por software. De nuevo aquí hay cuatro aplicaciones TCP / IP diferentes que se comunican, pero esta vez solo mostramos el tráfico que va desde el cliente al servidor. Dos de las aplicaciones están utilizando TCP y las otras dos UDP. Cada aplicación en el cliente envía mensajes a través de un puerto TCP o UDP específico. Estos números de puerto son utilizados por el software UDP y TCP del servidor para transmitir los datagramas al proceso de la aplicación correspondiente.

En la práctica, que TCP y UDP utilicen diferentes números de puerto es confuso, especialmente para los números de puerto reservados utilizados por las aplicaciones comunes. Por esta razón, por convención, la mayoría de los números de puerto reservados (están reservados) para ambos TCP y UDP. Por ejemplo, el puerto # 80 está reservado para el protocolo de transferencia de hipertexto (HTTP) para TCP y UDP, aunque sólo HTTP utiliza TCP. Examinaremos esto en mayor detalle en el siguiente tema.

Resumen de uso de Puertos para transmisión y Recepción de datagramas.
Así que, para resumir, aquí está lo básico de cómo trabaja el direccionamiento (direccionamiento de puertos) en la capa de transporte  en TCP y UDP:
  • Envío de datagramas: una aplicación especifica el puerto de origen y de destino que desee utilizar para la comunicación. Estos se codifican en la cabecera TCP o UDP, dependiendo de qué protocolo de capa de transporte esté utilizando la aplicación. Cuando TCP o UDP pasan los datos a IP, este indica el tipo de protocolo apropiado para TCP o UDP en el campo Protocolo del datagrama IP. Los números de puerto de origen y de destino están encapsulados como parte del mensaje TCP o UDP, dentro de la zona de datos del datagrama IP. 
  • Recepción de datagramas: El software IP recibe el datagrama, inspecciona el campo Protocolo y decide a que protocolo pertenece del datagrama (en este caso, TCP o UDP, pero por supuesto hay otros protocolos que utilizan IP directamente, como ICMP). TCP o UDP reciben el datagrama y pasan su contenido al proceso apropiado basándose en el número de puerto de destino.
Concepto clave: La multiplexación y demultiplexación de procesos de aplicaciones en TCP / IP se implementa utilizando el campo de Protocolo IP y los campos de puerto de origen y destino UDP / TCP. Después de la transmisión, al campo Protocolo se le da un número para indicar si se utilizó TCP o UDP, y los números de puerto se rellenan para indicar el proceso de software que envía y recibe. El dispositivo que recibe el datagrama utiliza el campo de Protocolo para determinar si se utilizó TCP o UDP, y luego pasa los datos al proceso de software indicado por el número de puerto de destino.

Nota: En un aparte, debo señalar que el término "puerto" tiene, aparte de éste en TCP / IP muchos significados. Por ejemplo, una salida física en un dispositivo de red a menudo se llama un puerto. Por lo general, uno puede discernir si el "puerto" en cuestión se refiere a un puerto de hardware o software a partir del contexto, pero ud deberá tener cuidado con esto.

Los números de puerto que discutimos en el tema anterior proporcionan un método de direccionamiento de capa de transporte que permite que muchas aplicaciones utilicen TCP y UDP simultáneamente. Al especificar el número de puerto de destino adecuado, una aplicación que envía datos puede estar segura de que el proceso correcto en el dispositivo de destino recibe el mensaje. Por desgracia, todavía hay un problema que tenemos que resolver antes de este sistema de direccionamiento funcione.

El Problema: La identificación de procesos particulares en el servidor
Para explicarlo, tengo que volver a un ejemplo familiar: el uso de la World Wide Web. Iniciamos nuestro navegador de Internet, que es un software cliente que envía solicitudes utilizando el Protocolo de transferencia de hipertexto (Hypertext Transfer Protocol HTTP). Tenemos que conocer ya sea la dirección IP del sitio Web que queremos acceder, o podemos tener la dirección IP que nos provee de forma automática nuestro DNS. Una vez que tenemos la dirección, el navegador Web puede generar un mensaje HTTP y enviarlo a la dirección IP del sitio Web.

Este mensaje HTTP no estará siendo enviado "a cualquier lugar" en la que la dirección IP: está destinado al proceso del servidor Web en el sitio que estamos tratando de alcanzar. El problema es: ¿cómo sabe el navegador Web (proceso del cliente), que número de puerto se ha asignado al proceso del servidor en el sitio Web? Los números de puerto pueden ir de 0 a 65.535, lo que significa un montón de opciones. Y en teoría, cada sitio Web podría asignar un número de puerto diferente para su proceso de servidor Web.

La Solución: Números de puerto reservados
Hay un par de diferentes formas de resolver este problema. TCP / IP usa la que es probablemente la forma más sencilla posible: reserva ciertos números de puerto para aplicaciones particulares. Cada aplicación común tiene un número de puerto específico asignado a la misma para el uso de procesos de servidor que escuchan las solicitudes de esa aplicación y luego responden a ellos. Para evitar el caos, el software que implementa un proceso servidor determinado normalmente utiliza el mismo número de puerto reservado en todos los dispositivos IP, por lo que los clientes lo pueden encontrar fácilmente.

En nuestro ejemplo, el número de puerto reservado para HTTP es 80. Cada navegador Web sólo "sabe" que los sitios web están diseñados para escuchar las solicitudes enviadas al puerto 80. Por lo tanto van a utilizar este valor en las solicitudes, para asegurar que el software IP y TCP en el navegador Web dirigen estos mensajes HTTP al software del servidor Web. Es posible que un servidor web en particular utilice un número de puerto diferente, pero en este caso, el usuario del navegador web debe ser informado de este número de alguna manera, y debe indicarle explícitamente al navegador web que use este número en lugar del número de puerto predeterminado (80).

Concepto clave: Para permitir que los dispositivos cliente establezcan conexiones más fácilmente a los servidores TCP / IP, los procesos de servidor para aplicaciones comunes utilizan números de puerto universales que los clientes están pre-programados para saber utilizar de forma predeterminada.

Rangos de números de puertos TCP / UDP.
Para que este sistema funcione bien, es esencial un acuerdo universal sobre las asignaciones de puertos. Por lo tanto, esto se convierte en otra situación en la que se necesita una autoridad central para administrar una lista de asignaciones de puertos que todo el mundo utilice. Para TCP / IP, esta es la misma autoridad responsable de la asignación y coordinación de los otros números administrados centralmente, incluyendo direcciones IP, números de protocolo IP y así sucesivamente: la Autoridad de Asignación de Aúmeros de Internet (Internet Assigned Numbers Authority IANA).

Como hemos visto, hay 65.536 números de puerto que se pueden utilizar para los procesos. Pero también hay un número bastante grande de aplicaciones TCP / IP, y la lista crece cada año. IANA debe manejar cuidadosamente el "espacio de direcciones" de números de puerto para asegurar que no se desperdicien en protocolos que no se utilizan ampliamente, mientras proporciona la flexibilidad para las organizaciones que necesiten hacer uso de aplicaciones oscuras. Para este fin, el espectro completo de números de puertos TCP y UDP se divide en tres rangos, como se muestra en la Tabla 144.:

La existencia de estos rangos garantiza que habrá un acuerdo universal sobre el modo de acceder a un proceso de servidor para los protocolos TCP / IP más comunes, permitiendo al mismo tiempo la flexibilidad para aplicaciones especiales. La mayoría de las aplicaciones TCP / IP y los protocolos de aplicación utilizan números en el rango de números de puertos bien conocidos para sus servicios. Estos números de puerto no se usan generalmente para procesos de cliente, pero hay algunas excepciones. Por ejemplo, el puerto 68 está reservado para un cliente usando el Protocolo Boostratp (BOOTP) o el Protocolo de Configuración Dinámica de Host (Dynamic Host Configuration Protocol DHCP).

Concepto clave: La asignación de números de puertos es administrada por IANA para asegurar la compatibilidad universal en torno a la Internet global. Los números se dividen en tres rangos: números de puerto conocidos utilizados para las aplicaciones más comunes, los números de puerto registrados para otras aplicaciones, y los números de puertos privados / dinámicos que se pueden utilizar sin registro IANA.

La importancia de la asimetría entre clientes y servidores en TCP / IP se hace evidente cuando se examina en detalle cómo se utilizan los números de puerto. Dado que los clientes inician la transferencia de datos de la aplicación a través de TCP y UDP, son ellos los que necesitan conocer el número de puerto del proceso del servidor. En consecuencia, los servidores están obligados a utilizar los números de puerto universalmente conocidos. Por lo tanto, los números de puerto conocidos y registrados identifican los procesos del servidor. Se utilizan como el número de puerto de destino en las solicitudes enviadas por los clientes.

En contraste, los servidores responden a los clientes; no inician el contacto con ellos. Por lo tanto, el cliente no tiene que utilizar un número de puerto reservado. De hecho, esto es realmente un eufemismo: el servidor no debe utilizar un número de puerto conocido o registrado para responder a los clientes. La razón es que es posible para un dispositivo particular tener el software cliente y el software de servidor del mismo protocolo ejecutándose en la misma máquina. Si un servidor recibe una petición HTTP en el puerto 80 de su máquina y envía la respuesta de vuelta al puerto 80 de la máquina cliente, estaría enviando la respuesta al un (hipotético) proceso del servidor HTTP en la máquina cliente y no al proceso del cliente que envía la solicitud inicial.

Para saber a dónde enviar la respuesta, el servidor debe conocer el número de puerto que utiliza el cliente. Este es suministrado por el cliente como el puerto de origen en la solicitud, y luego es utilizado por el servidor como puerto de destino para enviar la respuesta. Los procesos de cliente no utilizan puertos conocidos o registrados. En lugar de ello, a cada proceso cliente se le asigna un número de puerto temporal para su uso. Esto comúnmente se conoce como número de puerto efímero.

Nota: Su palabra de $10 del día: Efímero: "de corta duración; existente o continuo por un corto tiempo." - Diccionario revisado Webster Unabridged.

Asignación de puertos efímeros.
Los números de puertos efímeros se asignan según sea necesario para los procesos por el software de TCP / IP. Obviamente, cada proceso cliente que se ejecuta concurrentemente tiene que utilizar un número de puerto efímero único, por lo que las capas TCP y UDP deben llevar un registro de los que están en uso. Estos números de puerto se asignan generalmente de una manera pseudo-aleatoria de un pool de números reservados. Digo "pseudo-aleatorio" porque no existe un significado específico a un número de puerto efímero asignado a un proceso, por lo que se puede seleccionar uno de manera aleatoria para cada proceso cliente. Sin embargo, ya que es necesario volver a utilizar los números de puerto de este pool a través del tiempo, muchas implementaciones utilizan un conjunto de reglas para minimizar la posibilidad de confusión debido a la reutilización.

Considere la posibilidad de un proceso cliente que acaba de utilizar el número de puerto efímero 4121 para enviar una solicitud, recibe una respuesta, y luego termina. Supongamos que de inmediato reasignamos el número de puerto 4121 a algún otro proceso. Sin embargo, el servidor que atendió al usuario antes por el puerto 4121 por alguna razón envía una respuesta adicional. Esta respuesta iría dirigida entonces al nuevo proceso, creando confusión. Para evitar esto, es prudente esperar el mayor tiempo posible antes de volver a utilizar el número de puerto 4121 para otro proceso del cliente. Algunas implementaciones ciclarán entonces a través del pool de puertos disponibles para asegurar la máxima cantidad de tiempo transcurrido entre usos consecutivos del mismo número de puerto efímero.

Concepto clave: Los números de puertos registrados y bien conocidos son utilizados por los procesos del servidor dado que los clientes deben conocer el número de puerto del servidor para iniciar el contacto. Por el contrario, los procesos de cliente pueden utilizar cualquier número de puerto. Cada vez que un proceso cliente inicia una comunicación UDP o TCP se le asigna un número de puerto temporal o efímero, puerto que se utilizará para esa conversación. Estos números de puerto se asignan de una manera pseudo-aleatoria, ya que el número exacto utilizado no es importante, siempre y cuando cada proceso tenga un número diferente.

Rango de números de puertos efímeros.
El rango de números de puerto que se utiliza para los puertos efímeros en un dispositivo también depende de la implementación. El rango de puertos efímeors "clásico" fue establecido por la implementación de TCP / IP del UNIX de BSD (Berkeley Distribución estándar), donde se define como el espacio entre 1024 y 4999, lo que provee 3.976 puertos efímeros. Este parece ser un número muy grande, y de hecho es por lo general más que suficiente para un cliente típico. Sin embargo, el tamaño de este número puede ser engañoso. Muchas aplicaciones utilizan más de un proceso, y es teóricamente posible que un dispositivo IP muy ocupado se quede sin números de puertos efímeros. Por esta razón, la mayoría de las veces el rango de números de puerto efímero se puede cambiar. El rango predeterminado puede ser diferente para otros sistemas operativos.

Así como los números de puertos bien conocidos y registrados se utilizan para procesos de servidor, los números de puerto efímeros solo se usan para procesos cliente. Esto significa que el uso de un rango de direcciones desde 1024 a 4999 no entra en conflicto con el uso de ese mismo rango de números de puerto registrados, como se ve en el tema anterior

Uso de números de puertos durante un intercambio Cliente / Servidor
Así que, volvamos a la cuestión del intercambio de mensajes de la aplicación cliente / servidor. Una vez asignado un número de puerto efímero, este es utilizado como el puerto de origen en el mensaje de solicitud TCP / UDP del cliente. El servidor recibe la solicitud y, a continuación, genera una respuesta. En la formación de este mensaje de respuesta, el servidor intercambia los números de puerto de origen y de destino, así como lo hace con las direcciones IP de fuente y destino. Por lo tanto, la respuesta del servidor se envía desde el número de puerto bien conocido o registrado en el proceso de servidor, de regreso al número de puerto efímero en la máquina cliente.

Ufff, esto es confuso ... rápido, volvamos a nuestro ejemplo! Nuestro navegador web, con dirección IP 177.41.72.6 quiere enviar una petición HTTP a un sitio Web en particular en la dirección IP 41.199.222.3. La petición HTTP se envía a través de TCP, con un número de puerto de destino de 80 (que es el puerto reservado para los servidores HTTP). El número de puerto de origen se asigna a partir de un pool de puertos efímeros, vamos a decir que es el puerto 3022. Cuando llega la petición HTTP al servidor Web es transportada al puerto 80 en el que la recibe el servidor HTTP. Ese proceso genera una respuesta, y la envía de vuelta a 177.41.72.6, utilizando el puerto de destino 3022 y de puerto de origen 80. Los dos procesos pueden entonces intercambiar información de ida y vuelta, y cada vez los puertos de origen y destino son intercambiados junto con las direcciones IP de origen y destino. Este ejemplo se ilustra en la Figura 199.


Este ejemplo muy simplificado muestra cómo los clientes y servidores utilizan los números de puerto para un intercambio solicitud/respuesta El cliente está haciendo una petición HTTP y la envía al servidor en el número de puerto bien conocido de HTTP, 80. Su número de puerto para este intercambio es pseudo-seleccionado al azar el 3022. El servidor envía su respuesta de regreso a ese número de puerto, que se lee a partir de la solicitud.

Concepto clave: En la mayoría de las comunicaciones cliente / servidor TCP / IP, el cliente utiliza un número de puerto efímero aleatorio y envía una solicitud a un número de puerto reservado apropiado en la dirección IP del servidor. El servidor envía su respuesta de regreso a cualquiera que sea el numero de puerto que encuentre en el campo de Puerto de origen de la solicitud.

Los temas anteriores han puesto de manifiesto la diferencia fundamental entre el direccionamiento en el nivel del protocolo de Internet, y el direccionamiento como es visto desde la perspectiva de los procesos de aplicación. En resumen, en la capa tres, una dirección IP es todo lo que se necesita para transmitir correctamente datos entre dispositivos IP. En contraste, los protocolos de aplicación deben estar atentos a los puertos asignados a cada instancia de la aplicación, para que puedan utilizar adecuadamente TCP o UDP.

Sockets: Identificación de procesos
Lo que todo esto significa es que la identificación general de un proceso de aplicación en realidad utiliza la combinación de la dirección IP de la máquina en que se ejecuta - o la interfaz de red a través de la que está hablando, para ser más precisos - y el número de puerto que ha sido asignado a ella. Esta dirección combinada se llama socket. Los sockets se especifican utilizando la siguiente notación:

<Dirección IP>:<Número de puerto>

Así, por ejemplo, si tenemos un sitio Web que se ejecuta en la dirección IP 41.199.222.3, el socket correspondiente al servidor HTTP para ese sitio sería 41.199.222.3:80.

Concepto clave: El identificador global de un proceso de aplicación TCP / IP en un dispositivo es la combinación de su dirección IP y un número de puerto, y se llama socket.

En ocaciones ud verá un socket especificado utilizando un nombre de host en lugar de una dirección IP, como sigue:

<Nombre de host>:<Número de puerto>

Para utilizar este descriptor, el nombre primero se debe resolver en una dirección IP utilizando un DNS. Por ejemplo, es posible encontrar la URL de un sitio web de esta manera: "http://www.thisisagreatsite.com:8080". Esto le dice al navegador Web que primero deberá resolver el nombre de "www.thisisagreatsite.com" a una dirección IP usando un servicio de DNS, y luego podrá enviar una solicitud a esa dirección a través del puerto del servidor no estándar 8080, que en ocasiones se utiliza en lugar del puerto 80 debido a su parecido. (Véase el análisis del direccionamiento de capa de aplicaciones mediante direcciones URL para más información)

El socket es un concepto muy fundamental para el funcionamiento del software de aplicaciones TCP / IP. De hecho, es la base para una importante interfaz de programación de aplicaciones (API) TCP / IP con el mismo nombre: sockets. Una versión de esta API para Windows se llama Windows Sockets o WinSock, que es posible que haya oído mencionar antes. Estas API permiten que los programas de aplicación utilicen fácilmente TCP / IP para comunicarse.

Pares de sockets: Identificación de conexiones.
Así, el intercambio de datos entre un par de dispositivos consta de una serie de mensajes enviados desde un socket en un dispositivo a un socket en el otro. Cada dispositivo tendrá ocurriendo normalmente múltiples conversaciones simultáneas de esta clase.  En el caso del TCP, se establece una conexión para cada par de dispositivos durante la duración de la sesión de comunicación. Estas conexiones deben ser administradas, y esto requiere que sean identificadas unívocamente. Esto se hace usando el par de identificadores de socket para cada uno de los dos dispositivos que están conectados.

Concepto clave: Cada dispositivo puede tener múltiples conexiones TCP activas en un momento dado. Cada conexión se identifica unívocamente mediante la combinación del socket de cliente y el socket del servidor, que a su vez contiene cuatro elementos: La dirección IP y el puerto del cliente, y la dirección IP y el puerto del servidor.

Volvamos al ejemplo que usamos en el tema anterior (figura 199). Estamos enviando una solicitud HTTP de nuestro cliente en 177.41.72.6 al sitio Web en 41.199.222.3. El servidor de ese sitio Web utiliza el número de puerto bien conocido 80, por lo que su socket será 41.199.222.3:80, como vimos anteriormente. Hemos usado el número de puerto efímero 3022 para nuestro navegador Web, por lo que el socket de cliente es 177.41.72.6:3022. La conexión global entre estos dispositivos puede ser descrita usando este par de sockets:

(41.199.222.3:80, 177.41.72.6:3022)

Para más información sobre cómo identifica TCP las conexiones, consulte el tema sobre los puertos e identificación de conexiones en TCP en la sección sobre fundamentos de TCP.

A diferencia de TCP, UDP es un protocolo no orientado a conexión, por lo que, obviamente, no utiliza conexiones. El par de sockets en los dispositivos emisor y receptor aún puede ser utilizado para identificar los dos procesos que intercambian datos, pero ya que no hay conexiones el par de sockets no tiene la misma importancia que en TCP.

La gran popularidad de la suite de protocolos TCP / IP ha llevado al desarrollo de literalmente miles de diferentes aplicaciones y protocolos. La mayoría de éstos utilizan el modelo de operación cliente / servidor que hemos comentado anteriormente en esta sección. Los procesos de servidor para una aplicación en particular están diseñados para utilizar un número de puerto reservado concreto, con los clientes utilizando un número de puerto efímero (temporal) para iniciar una conexión con el servidor.

Gestión de Números de puerto reservados
Para asegurarse de que todos están de acuerdo en que número de puerto deben usar las aplicaciones de servidor, estos son administrados de forma centralizada por la Internet Assigned Numbers Authority (IANA). Originalmente, IANA mantiene la lista de números de puerto conocidos y registrados en un extenso documento de texto, junto con todos los otros muchos parámetros para los que IANA era centralmente responsable (como números de campo de protocolo IP, el tipo y los valores de campo de Código de ICMP, y así sucesivamente). Estos fueron publicados en forma periódica en documentos de estándares de Internet (RFCs) titulados Asignación de Números.

Este sistema funcionó bien en los primeros días de la Internet, pero a mediados de la década de 1990, estos valores empezaron a cambiar tan rápidamente que no era factible utilizar el proceso RFC. Era demasiado trabajo mantener su publicación, y el RFC estaba prácticamente desactualizado el día después de que fue eliminado.

El último estándar de Números Asignados fue el RFC 1700, publicado en octubre de 1994. Después de ese tiempo, IANA cambió a un conjunto de documentos de la World Wide Web que contienen los parámetros que gestionan. Esto permitió a la IANA mantener las listas siempre al día, y a los usuarios de TCP / IP poder obtener la información más actual. El RFC 1700 fue declarado obsoleto oficialmente en 2002.

En la Web: La información completa sobre todos los parámetros mantenidos por IANA se puede encontrar en http://www.iana.org/numbers.html. La dirección URL del archivo que contiene las asignaciones de puertos TCP / UDP es http://www.iana.org/assignments/port-numbers.

El documento mencionado anteriormente es la lista definitiva de la asignación de todos los puertos TCP / UDP bien conocidos y registrados.  A cada número de puerto se le asigna una palabra clave corta, con una breve descripción del protocolo que lo utiliza. Hay dos problemas con este documento. La primera es que es increíblemente largo: más de 10.000 líneas de texto. La mayoría de los protocolos mencionados en esos miles de líneas son para aplicaciones oscuras de las que probablemente nunca ha oído hablar de antes (yo ciertamente nunca he oído hablar de la mayoría de ellas!) Esto hace que sea difícil ver fácilmente las asignaciones de puertos para los protocolos que son los más comúnmente utilizados.

El otro problema con este documento es que muestra el mismo número de puerto como reservado para TCP y UDP para una aplicación. Como mencioné anteriormente, los números de puertos TCP y UDP son realmente independientes, por lo que se podría, en teoría, asignar el puerto TCP 80 para un tipo de aplicación de servidor y el puerto UDP 80 a otro. Se creía que esto llevaría a confusiones, por lo que con muy pocas excepciones, el mismo número de puerto se muestra en la lista para la misma aplicación para TCP y UDP. Esto tiene sentido, pero mostrarlo de esta manera en la lista tiene un inconveniente: no se puede saber cuál es el protocolo que la aplicación utiliza en realidad, y cual ha sido reservado por un asunto de consistencia.
Teniendo en cuenta todo eso, he decidido incluir aquí un par de tablas resumen que muestran los números de puerto conocidos y registrados para las aplicaciones TCP / IP más comunes, e indico si el protocolo utiliza TCP, UDP o ambos.

Aplicaciones y puertos bien conocidos
La tabla 145 lista los números de puerto conocidos para los protocolos más comunes de aplicaciones TCP / IP.


Números de puertos registrados comunes y aplicaciones.
Los números de puerto registrados son, por definición, para los protocolos que no están estandarizadas por el proceso RFC, por lo que son en su mayoría aplicaciones esotéricas y considero no tiene mucho sentido extenderse sobre el particular. La tabla 146 muestra algunos que creo que son de particular interés: