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.