La ventana de recepción es la cantidad de datos que receptor Se puede tomar de una vez sin agobiarse. Es el control de flujo impuesto por el receptor.
La ventana de congestión (nota: es la "ventana de congestión"; no hay una "ventana de transmisión", por lo que su título está un poco apagado) es la cantidad de datos que red (los enrutadores entre el remitente y el receptor) pueden tomarse de una vez sin sentirse abrumados (es decir, sin causar o exacerbar la congestión). La ventana de congestión se puede considerar como una forma de control de flujo impuesto por el remitente.
Antes de entrar en la ventana de congestión, comencemos con los detalles de la ventana de recepción.
La ventana de recepción es la cantidad de datos que la pila TCP receptora está dispuesta a recibir y el búfer para la aplicación receptora, antes de que la aplicación receptora lea los datos en espera de la pila TCP receptora y libere esos búferes del kernel. El tamaño de la ventana de recepción puede estar limitado por los detalles específicos de la implementación. Por ejemplo, un kernel similar a Unix puede limitar el tamaño de la ventana de recepción por la cantidad de buffers de mensajes del kernel (mbufs) que el kernel está dispuesto a asignar a cada conexión TCP.
Suponiendo que no está limitado por los recursos en el receptor, puede calcular una ventana de recepción óptima para usar para una conexión TCP dada. Básicamente, la ventana de recepción debe ser al menos el "producto de retardo de ancho de banda * (BDP) de la conexión TCP. Entonces, para usar un ejemplo típico de 1300Mbps 802.11ac, si tiene un enlace de 1,300,000,000 de bits por segundo (este es su ancho de banda), con un Tiempo de viaje de ida y vuelta de 0.003 segundos (RTT; piense en "tiempo de ping"; este es su retraso), su recepción la ventana debe ser de al menos 1,300,000,000 bits / seg * 0.003 seg = 3,900,000 bits, que es aproximadamente 476KiBytes. El tamaño de la ventana de recepción en el BDP permite al remitente "llenar el conducto", enviando tantos datos a la red como la red puede mantener en vuelo hasta que haya tiempo suficiente para devolver un Ack al remitente. Nada menos que esto, y el remitente no podrá transmitir continuamente; en su lugar (una vez que el inicio lento de TCP se acelera lo suficiente) enviará una ráfaga del tamaño de una ventana de recepción, pero se terminará de inyectar esa ráfaga en la red antes de que reciba un Ack de vuelta diciéndole que hay más espacio en la ventana de recepción. Por lo tanto, tendrá que pausar y esperar a que Ack antes de que sepa que puede enviar más sin abrumar la pila TCP del receptor. Ese tiempo que pasa en pausa, a la espera de un Ack, se pierde el tiempo que podría haber pasado transmitiendo.
Así que eso es lo que es la ventana de recepción, y cómo se calcula. Ahora veamos la ventana de congestión.
La ventana de congestión es una de las cosas que el remitente realiza un seguimiento para asegurarse de que no esté causando congestión en la red para los saltos de la red (enrutadores, enlaces entre enrutadores) entre el remitente y el receptor. Eventualmente, se implementarán ampliamente innovaciones como la Notificación explícita de congestión (ECN), lo que permitirá a los enrutadores notificar a los remitentes TCP de congestión. Pero hasta entonces, los remitentes de TCP deben intentar detectar y evitar la congestión de otras maneras, y la mayor parte de eso proviene de comenzar a transmitir paquetes lentamente para sondear la red para determinar qué tan rápido puede ir sin perder paquetes, interpretando la pérdida de paquetes como un signo de congestión. , reduciendo en gran medida la velocidad de transmisión de paquetes cuando se produce la pérdida, y volviendo a subir lentamente.
Los estándares actuales de seguimiento de RFC en TCP Control de congestión, RFC 5681 , dice que la ventana de congestión debe calcularse inicialmente entre 2 y 4 veces el tamaño máximo de segmento de TCP (MSS; como el equivalente de la capa TCP de una MTU); específicamente, 2-4 veces el TCP MSS que el remitente es el seguimiento. Este es el MSS o SMSS del remitente. El RFC también establece que el remitente debe respetar lo que sea más bajo entre la ventana de congestión y la ventana de recepción. Es decir, incluso si la red es rápida e incongestionada (y, por lo tanto, la ventana de congestión ha crecido más que la ventana de recepción), no tiene sentido enviar más datos a la red de lo que el receptor puede manejar; eso acabará abrumando al receptor y causando eso para eliminar los paquetes después de que hayan llegado a la red con éxito
Esa es la relación entre la ventana de congestión y la ventana de recepción. Uno es el control de flujo del lado del receptor para que el receptor no se agobie, y el otro es el control de flujo del lado del emisor para que los enrutadores en la red no se vean abrumados. Al decidir si puede o no poner más paquetes en vuelo, el remitente de TCP debe mirar tanto la ventana de congestión como la ventana de recepción y respetar la que sea menor.
La ventana de congestión generalmente comienza con aproximadamente 3 SMSSes (3 * 1448 bytes = 4344 bytes), y durante el inicio lento de TCP, aumenta hasta 1 SMSS (1448 bytes) por Ack, asumiendo que el valor de al menos 1 SMSS de bytes previamente Desconectados se ha Ackiado . Después de un inicio lento, el algoritmo para evitar la congestión se activa y la ventana de congestión aumenta en no más de 1 SMSS por RTT. Si el remitente detecta la pérdida de paquetes, interpreta eso como congestión y corta la ventana de congestión básicamente a la mitad para una pérdida fácilmente recuperable (Retransmisión rápida / Recuperación rápida, activada por "Ack de duplicado triple"), y la reduce a 1 SMSS para escenarios de pérdida más graves (no se reciben Acks antes de que expire el temporizador de retransmisión).
Tenga en cuenta que su pregunta contiene un error. Es incorrecto decir que la ventana de congestión se duplica cuando el remitente recibe un Ack. La ventana de congestión comienza generalmente en 3 SMSSes y se incrementa en no más de un SMSS por cada SMSS Ack'd. Cuando se produce una pérdida, la ventana de congestión se reduce básicamente a la mitad o peor. De hecho, la política de redimensionamiento de la ventana de congestión a menudo se resume como "aumento aditivo, disminución multiplicativa".