¿Cómo se puede permitir que un tamaño de ventana TCP sea mayor que el tamaño máximo de un paquete de Ethernet?

Sé que los tamaños de las ventanas TCP se pueden escalar a más de 64 KB, pero mirando un datagrama de paquetes de Ethernet, como este:

parece que un paquete de capa 2 tiene un tamaño limitado para ser mucho más pequeño que eso. ¿Cómo funciona ACKing en la capa TCP si una sola solicitud TCP requiere que se ensamblen varias solicitudes de red en un receptor?

El tamaño de la ventana TCP es generalmente independiente del tamaño máximo de segmento que depende de la unidad de transferencia máxima que a su vez depende del tamaño máximo de trama .

Comencemos bajo.

El tamaño máximo de trama es la trama más grande que puede transportar una red (segmento). Para Ethernet, esto es 1518 bytes por definición.

La trama encapsula un paquete IP, por lo que el paquete más grande, la unidad de transferencia máxima MTU, es el tamaño máximo de trama menos la sobrecarga de la trama. Para Ethernet, eso es 1518-18 = 1500 bytes.

El paquete IP encapsula un segmento TCP, por lo que el tamaño máximo de segmento MSS es la MTU menos la sobrecarga IP menos la sobrecarga TCP (MSS no incluye el encabezado TCP). Para Ethernet y TCP sobre IPv4 sin opciones, esto es 1500-20 (sobrecarga IPv4) - 20 (sobrecarga TCP)) = 1460 bytes.

Ahora, TCP es un protocolo de transporte que se presenta como un socket de flujo para la aplicación. Eso significa que una aplicación puede transmitir cualquier cantidad de datos de tamaño arbitrario a través de ese socket. Para eso, TCP divide el flujo de datos en dichos segmentos (0 a MSS bytes de longitud {1}), transmite cada segmento a través de IP y los vuelve a unir en el destino.

Los segmentos TCP son reconocidos por el destino para garantizar la entrega. Imagine que el nodo fuente solo enviaría un solo segmento, esperará el acuse de recibo y luego enviará el siguiente segmento. Independientemente del ancho de banda real, el rendimiento de esta conexión TCP estaría limitado por el tiempo de ida y vuelta (RTT, el tiempo que tarda un paquete en viajar desde el origen hasta el destino y viceversa).

Por lo tanto, si tuviera una conexión de 1 Gbit / s entre dos nodos con un RTT de 10 ms, podría enviar efectivamente 1460 bytes cada 10 ms o 146 kB / s. Eso no es muy satisfactorio.

TCP, por lo tanto, utiliza una ventana de envío : múltiples segmentos que pueden estar "en vuelo" al mismo tiempo, enviando y esperando el reconocimiento. También se llama ventana deslizante a medida que avanza cada vez que se reconoce el segmento al comienzo de la ventana, lo que desencadena el envío del siguiente segmento al que avanzó la ventana. De esta manera, el tamaño del segmento no importa. Con una ventana de tradicionalmente 64 KiB podemos tener esa cantidad en vuelo y, en consecuencia, transportar 64 KiB en cada 10 ms = 6.5 MB / s. Mejor, pero aún no es realmente satisfactorio para una conexión gigabit.

El TCP moderno utiliza la opción de escala de ventana que puede aumentar la ventana de envío exponencialmente hasta 2 GiB, proporcionando un crecimiento futuro.

Pero, ¿por qué no se envían todos los datos a la vez y por qué necesitamos esta ventana de envío? Si envía todo lo más rápido que puede, localmente, y hay (muy probablemente) un enlace más lento en algún lugar de la ruta hacia el destino, sería necesario poner en cola cantidades significativas de datos. Ningún conmutador o enrutador puede almacenar en el búfer más de unos pocos MB (si es que lo hace), por lo que sería necesario eliminar el exceso de tráfico. Si no se confirma, será necesario reenviarlo, y el exceso se eliminará nuevamente. Esto sería altamente ineficiente y congestionaría severamente la red. TCP maneja este problema con su control de congestión, ajustando el tamaño de la ventana de acuerdo con el ancho de banda efectivo y el tiempo de ida y vuelta actual en un algoritmo complejo.

{1} Los segmentos vacíos se pueden usar para evitar tiempos de espera de conexión utilizando la opción keepalive . Deduplicador Thx