Reconocimiento diferido de TCP

El acuse de recibo diferido (ACK) de TCP es una técnica utilizada por algunas implementaciones del Protocolo de Control de Transmisión (TCP) para mejorar el rendimiento de la red . Básicamente, varias respuestas ACK se pueden combinar en una sola, lo que reduce la sobrecarga del protocolo. Sin embargo, en algunos casos, esta técnica puede disminuir el rendimiento de la aplicación.

Como se describe en la RFC 1122 , un host puede retrasar el envío de una respuesta ACK hasta 500 ms. Además, con un flujo de segmentos entrantes de tamaño completo, se deben enviar respuestas ACK por cada segundo segmento. La RFC 1122 hace referencia a la RFC 813 de 1982 como la descripción original del ACK retardado. ^{[ 1 ]}  

Los ACK retardados pueden brindar a la aplicación la oportunidad de actualizar la ventana de recepción TCP y, posiblemente, enviar una respuesta inmediata junto con el ACK. Para ciertos protocolos, como Telnet , los ACK retardados pueden reducir la cantidad de respuestas enviadas por el servidor en un factor de 3, al combinar el ACK, la actualización de la ventana y los datos de respuesta en un solo segmento. ^{[ 1 ]}

El tiempo de espera adicional introducido por el ACK diferido puede causar retrasos adicionales al interactuar con ciertas aplicaciones y configuraciones. Si el remitente utiliza el algoritmo de Nagle , los datos se pondrán en cola hasta que se reciba un ACK. Si el remitente no envía suficientes datos para completar el tamaño máximo del segmento (por ejemplo, si realiza dos escrituras pequeñas seguidas de una lectura bloqueante), la transferencia se pausará hasta que expire el tiempo de espera del ACK. Linux 2.4.4+ admite una TCP_QUICKACKopción de socket que desactiva el ACK diferido. ^{[ 2 ]}

Por ejemplo, supongamos que Bob envía datos a Carol. La capa de sockets de Bob tiene menos datos por enviar que los que caben en un paquete completo. Según el algoritmo de Nagle, no se enviarán hasta que reciba una confirmación (ACK) de los datos ya enviados. Del mismo modo, la capa de aplicación de Carol no enviará una respuesta hasta que reciba todos los datos. Si Carol utiliza confirmaciones diferidas (ACK), su capa de sockets no enviará una confirmación hasta que se agote el tiempo de espera.

Si la aplicación transmite datos en fragmentos pequeños y espera confirmaciones periódicas, puede producirse esta interacción negativa. Para evitar este retraso, la capa de aplicación debe enviar datos continuamente sin esperar confirmaciones. Como alternativa, la aplicación puede deshabilitar el algoritmo de Nagle en el lado emisor.