Tamaño de ventana y número ACK

Copiar y pegar de las diapositivas de mi profesor:

• Receiver indicates the window size is 3000 
• Transfer goes ahead 
• Acknowledge every 3000 bytes 
• Receiver increases window size to 4000 
• 4000 bytes will be transferred before the next acknowledgement 

Entonces, de esto deduzco que el tamaño de la ventana representa cuántos bytes reunirá el receptor antes de enviar un ACK.

Pero esto no es lo que veo en esta captura de Wireshark:

Como puede ver en la captura de pantalla (de una transferencia de archivos TCP), el servidor está ACKING cada ~ 1400 bytes más o menos (mirando el número ACK), pero al mismo tiempo indica un tamaño de ventana de 100'000 + bytes.

Por lo que entiendo de las diapositivas de mi profesor, ¿el servidor debería estar ACKING cada 100,000 + bytes? ¿Por qué está ACKING mucho más a menudo que eso?

Enseño TCP, y a menudo me encuentro con personas a quienes se les enseñó mal que el ACK solo se envía cuando se alcanza el tamaño de la ventana. Esto no es verdad. (Para ser realmente transparente, yo también enseñé esto incorrectamente antes de saberlo mejor, así que entiendo completamente el error).

NOTA, usaré Receiver / Sender para describirlo, pero tenga en cuenta que TCP es bidireccional, y ambas partes mantienen un Tamaño de ventana.

El tamaño de la ventana (que establece el receptor) es un límite estricto sobre cuántos bytes puede enviar el remitente sin verse obligado a detenerse para esperar un acuse de recibo.

El tamaño de la ventana no determina con qué frecuencia el receptor debe enviar acuses de recibo. Originalmente, el protocolo TCP requería que se enviara un acuse de recibo después de recibir cada segmento. Más tarde, TCP se optimizó para permitir que el receptor omita los ACK y envíe un ACKnowledgment cada otro paquete (o más).

El objetivo de TCP, entonces, es que el remitente envíe continuamente paquetes, sin demora o interrupción, porque recibe acuses de recibo continuamente, de modo que el recuento de "bytes en tránsito" siempre es menor que el tamaño de la ventana. Si en cualquier momento, el remitente ha enviado un recuento de bytes igual al tamaño de la ventana sin recibir un ACK, se ve obligado a pausar el envío y esperar.

Lo importante a considerar en todo esto es el tiempo de ida y vuelta. A menudo, cuando está estudiando TCP en un wirehark, solo está viendo la perspectiva de una de las partes en la conversación de TCP, lo que hace que sea difícil inferir, o realmente "ver", el efecto del RTT. Para ilustrar el efecto de RTT, eche un vistazo a estas dos capturas. Ambos capturan la misma conversación, una descarga de archivos de 2 MB a través de HTTP, pero uno es desde la perspectiva del Cliente y el otro es desde la perspectiva del Servidor .

Nota: es más fácil analizar TCP si desactiva la función Wireshark " Permitir que el subdissector vuelva a ensamblar flujos TCP "

Observe desde la captura del lado del servidor (quién es el remitente del archivo), el servidor envía 8 paquetes de tamaño completo en una fila (paquetes n. ° 6 a 13) antes de recibir el primer ACK en el paquete n. ° 14. ese ACK, observe que el reconocimiento del Cliente es para el segmento enviado en el Paquete # 7. Y el ACK que envió el Cliente en el paquete 20 es del segmento enviado en el Paquete # 9.

Vea cómo el Cliente reconoce cada otro paquete. Pero casi parece que los está reconociendo "tarde". Pero, de hecho, esto es solo el efecto del tiempo de ida y vuelta. El remitente puede enviar 7 ~ segmentos en el tiempo que le toma al primer segmento llegar al cliente y al ACK del cliente llegar al servidor. Si observa la captura desde la perspectiva del Cliente, se ve muy 'limpia', es decir que cada segundo paquete que recibe, envía un ACK.

Observe también lo que sucede en el paquete # 23. El servidor ha enviado todo lo que puede, porque los "bytes en tránsito" alcanzan el tamaño de la ventana, por lo que se ve obligado a dejar de enviar. Hasta que llegue el próximo ACK. Dado que los ACK están llegando en todos los demás segmentos recibidos. Cada ACK permite que el remitente envíe nuevamente dos segmentos nuevos, antes de que la ventana vuelva a estar llena y el servidor se vea obligado nuevamente a pausar. Esto sucede hasta el paquete n. ° 51, cuando el cliente (receptor) aumenta el tamaño de la ventana significativamente, lo que permite que el servidor (remitente) comience a transmitir datos desinhibidos nuevamente ... al menos hasta el paquete n. ° 175, cuando la nueva ventana se llena.

El tamaño de la ventana se usa para evitar la congestión en el receptor (a diferencia de la ventana de congestión que intenta evitar la congestión en la red).

La funcionalidad es relativamente simple: el receptor informa al remitente sobre el tamaño de su ventana, que generalmente representa el tamaño del búfer disponible. Por lo tanto, este número debe reducirse cada vez que llega un nuevo paquete al receptor y debe aumentarse cada vez que se procesa un paquete en el receptor.

En el lado del remitente, el remitente intenta asegurarse de que en un momento dado no tenga en tránsito más bytes que la última ventana anunciada recibida y, por lo tanto, reduce la probabilidad de inundar el receptor.

Ahora, a partir de su salida de Wirehark, podemos ver que el tamaño de su ventana es relativamente grande y, por lo tanto, sus transmisiones no se aceleran y recibe un ACK por cada paquete que envía (como debería ser en el caso general donde no se utiliza la agregación de ACK) . Actualmente, el tamaño máximo utilizado principalmente para las tramas de Ethernet es de 1500 bytes. Si elimina todos los encabezados, verá que los bytes que quedan son en realidad el número en el que aumentan sus ACK.