¿Por qué un socket TCP se identifica con una tupla 4?

Novato a las redes aquí. Estoy leyendo el libro Computer Networking (3rd edition), y en la sección 3.2 están discutiendo la multiplexación / demultiplexación tanto para UDP como para TCP.

En el protocolo UDP, un socket se identifica de forma exclusiva por la IP de origen y el puerto de origen.

En el protocolo TCP, el socket se identifica de forma exclusiva por la IP de origen, el puerto de origen, la IP de destino y el puerto de destino. ¿Por qué el protocolo TCP requiere dos datos adicionales para que el host receptor demultiplexe correctamente el segmento y lo envíe al proceso correcto?

La única razón por la que puedo pensar por qué esto es necesario es si los clientes siempre envían el segmento TCP al mismo puerto que el segmento de solicitud de conexión. Por ejemplo, mi navegador siempre envía datos al puerto 80 del servidor a pesar de que el servidor ha establecido un socket TCP específicamente para esa sesión en un puerto diferente. En ese caso, TCP tiene que usar la IP de origen y la información del puerto de origen para demultiplexar al socket correcto. No puede confiar únicamente en la información de IP de origen, porque un solo host puede establecer varias sesiones, pero cada sesión debe estar en un puerto diferente.

La razón por la cual UDP no tiene este problema es porque el combo de IP / puerto de destino identifica el socket al que se adjunta el proceso que manejará la solicitud, ya que en UDP no hay "generación" de múltiples nuevos sockets para solicitudes.

¿Es esto correcto o he llegado a una conclusión incorrecta?

Desafortunadamente, las cosas se vuelven confusas porque hay dos definiciones diferentes de socket. El TCP rfc usa el término socket para referirse a una combinación de dirección y puerto, pero los sockets berkerly y sus derivados (la API utilizada por casi todas las implementaciones prácticas de IP en uso hoy en día) usa el término socket para referirse a un tipo de operación sistema de comunicaciones objeto.

¿Por qué el protocolo TCP requiere dos datos adicionales para que el host receptor demultiplexe correctamente el segmento y lo envíe al proceso correcto?

No se trata solo del proceso correcto sino del objeto de comunicación correcto.

La única razón por la que puedo pensar por qué esto es necesario es si los clientes siempre envían el segmento TCP al mismo puerto que el segmento de solicitud de conexión. Por ejemplo, mi navegador siempre envía datos al puerto 80

Ellas hacen.

a pesar de que el servidor ha establecido un socket TCP específicamente para esa sesión en un puerto diferente.

Esto parece ser un error común, probablemente causado por las diferentes definiciones de socket. La aceptación de una conexión crea un nuevo objeto de comunicaciones (socket en el sentido del término de los sockets de Berkerly) pero no asigna una nueva combinación de ip / puerto (socket en el sentido del término TCP RFC) en el servidor.

La razón por la cual UDP no tiene este problema es porque el combo de IP / puerto de destino identifica el socket al que se adjunta el proceso que manejará la solicitud, ya que en UDP no hay "generación" de múltiples nuevos sockets para solicitudes.

Correcto (suponiendo que su párrafo esté usando "socket" en el sentido de los enchufes berkerly).

En el protocolo UDP, un socket se identifica de forma exclusiva por la IP de origen y el puerto de origen.

En el protocolo TCP, el socket se identifica de forma exclusiva por la IP de origen, el puerto de origen, la IP de destino y el puerto de destino. ¿Por qué el protocolo TCP requiere dos datos adicionales?

NB para la terminología TCP, el socket es el par dirección-puerto; Un par de enchufes define la conexión . (Por RFC 793 p5)

Me temo que está equivocado acerca de UDP, que aunque en realidad no tiene "sockets", incluso si la biblioteca Berkeley Sockets los llama así, y es razonable llamar a un par de dirección-puerto, multiplexa en esencialmente la forma idéntica a TCP.

Una situación típica en la que puede ver esto es el caso de múltiples resoluciones DNS simultáneas de un host al mismo servidor DNS, donde claramente solo el número de puerto de origen es necesariamente diferente. Puede ver que esta es exactamente la misma situación que las conexiones TCP simultáneas múltiples desde un cliente a un único servidor web.

UDP tiene datagramas sin conexión. El host A envía el datagrama fuera de un par de dirección-puerto, dirigido a un par de dirección-puerto en B, que típicamente, pero no siempre, responde por duplicado. Hablando más libremente de la "comunicación", opera exactamente sobre la misma tupla de 4 que una conexión TCP.

A veces verá referencias a una tupla de 5 (protocolo, dirección de origen, puerto de origen, dirección de destino, puerto de destino), donde el protocolo sería 17 para UDP, 6 para TCP, etc. Esto es lo que utilizan la mayoría de los firewalls, enrutadores, etc. NAT y operaciones similares para identificar este par comunicante.

a pesar de que el servidor ha establecido un socket TCP específicamente para esa sesión en un puerto diferente

Me temo que también está equivocado sobre TCP, posiblemente debido al conflicto de terminología entre la definición del protocolo TCP (RFC 793) y su implementación práctica más común, Berkeley Sockets Library, como se usa en Unix y todo lo que se deriva de eso.

Si se enfoca en el protocolo, es mucho más claro: no hay un "puerto diferente". El servidor web solo está escuchando, por ejemplo, 1.1.1.1 puerto 80. El cliente solo envía desde, por ejemplo, 2.2.2.2 puerto 56789. Cada paquete será 1.1.1.1:80 a 2.2.2.2:56789 o viceversa ; se verifica fácilmente mirando paquetes con tcpdump / wireshark / etc.

(Para muy breve digresión a la aplicación de Berkeley, un TCP de conexión está representado por un número entero por lo general, pero confusamente llamado sockfd; una red TCP socket está representado por una struct sockaddrLa. accept()Llamada al sistema muy confusamente habla de hacer un "nuevo socket conectado", por el cual significa nueva conexiónestructura en el estado conectado. La tupla de esta cosa resultante estaría en nuestro ejemplo (1.1.1.1, 80, 2.2.2.2, 56789). Con respecto a UDP, la biblioteca le permite considerar UDP como conectado, lo cual es una forma conveniente, aunque completamente incorrecta, de describir el intercambio de datagramas UDP entre dos procesos, y solo significa que la estructura recuerda el par de direcciones y puertos lejanos, que en términos de programación hace que UDP "conexión" se parece a una TCP. Recuerde que la biblioteca Berkeley no es solo para IP, y tiene generalizaciones de varios sistemas de redes subyacentes diferentes. Si desea seguir estos términos de programación de red, sugiero Stack Overflow, que tiene muchos programadores de red muy competentes).

En el protocolo UDP, un socket se identifica de forma exclusiva por la IP de origen y el puerto de origen.

No mezcle la programación de red (sockets) con los protocolos de red.

Sin embargo, en el caso de UDP también tiene esta tupla de 4!

La diferencia entre TCP y UDP es que UDP no usa conexiones fijas, por lo que se puede usar un socket para enviar datos a diferentes computadoras y / o diferentes puertos de destino.

Por esta razón, el sistema operativo solo guarda 2 elementos de 4 tuplas (dirección IP y número de puerto del puerto local) mientras que los otros 2 elementos (dirección IP y número de puerto de la otra computadora) deben ser proporcionados por la aplicación (en la sendto()función)

Por otro lado, TCP está orientado a la conexión y un socket describe una conexión entre dos computadoras. Por lo tanto, un socket solo se puede usar para enviar datos a un determinado puerto TCP de una determinada computadora (usando la send()función).

Esto significa que los 4 elementos (y no solo 2 de ellos) de las 4 tuplas están fijos para el zócalo, por lo que el sistema operativo puede almacenar los 4 elementos y la aplicación no tiene que proporcionar 2 de los 4 elementos.

Si el libro que está leyendo es "Redes informáticas: un enfoque de arriba hacia abajo" de Jim Kurose, usted y yo estamos leyendo el mismo libro. :-) Para su información, el libro en realidad establece que las dos tuplas que identifican un socket UDP se basan en el IP y el puerto de destino (no de origen). Al menos, eso es lo que dice la séptima edición.

Para responder a su pregunta, TCP está orientado a la conexión, mientras que UDP no tiene conexión. Por lo tanto, cuando se establece una solicitud TCP entre un host y un servidor, cada lado de esa conexión querrá estar seguro de que las solicitudes posteriores utilizarán la misma conexión (de lo contrario, ¿cuál es el punto de usar un protocolo orientado a la conexión como TCP?). Y puesto que dos segmentos de datos con el mismo destino IP y el puerto, pero diferentes direcciones IP de origen y los puertos van a utilizar dos distintos zócalos en el lado del servidor, la única manera de garantizar que las solicitudes posteriores utilizan el mismo socket que la solicitud original es utilizar tanto la fuente e IP / puerto de destino al hacer coincidir segmentos de datos con sus sockets correctos.

Por el contrario, puede pensar que UDP configura una nueva conexión (y, por lo tanto, un nuevo socket) con cada solicitud por separado. Como no tiene que preocuparse por usar el mismo socket que las solicitudes anteriores, no es necesario incluir el IP / puerto de origen al identificar a qué socket UDP enrutar el segmento. Por lo tanto, una doble tupla es suficiente.