Eles não são a mesma coisa, mas estão de alguma forma relacionados e, quando usados juntos, algumas armadilhas e problemas podem surgir.
ACK atrasado
O ACK atrasado pode ser visto como algo implementado no lado do recebimento. Com ACK atrasado, os ACKs não são enviados imediatamente, mas atrasados por algum tempo (geralmente 200 ms.) Na esperança de que o ACK que ele precisa enviar possa ser combinado ou "associado" com alguns dados que o aplicativo local deseja enviar na outra direção .
A delayed ACK gives the application an opportunity to update the window and perhaps to send an immediate response. In particular, in the case of character-mode remote login, a delayed ACK can reduce the number of segments sent by the server by a factor of 3 (ACK, window update, and echo character all combined in one segment).
In addition, on some large multi-user hosts, a delayed ACK can substantially reduce protocol processing overhead by reducing the total number of packets to be processed. However, excessive delays on ACK's can disturb the round-trip timing and packet "clocking" algorithms. rfc1122
O ACK atrasado é usado para evitar esse tipo de situação:
Client Server
| |
|----- Request ---->|
| |
|<------ ACK -------|
| |
|<---- Response ----|
| |
|------- ACK ------>|
Com o ACK TCP atrasado, o Request ACK e Response serão enviados em um único segmento.
Client Server
| |
|----- Request ---->|
| |
|<-- Response/ACK---|
| |
|------- ACK ------>|
John Nagle mentions in this forum
A delayed ACK is a bet that the other end will reply to what you just sent almost immediately. Except for some RPC protocols, this is unlikely. So the ACK delay mechanism loses the bet, over and over, delaying the ACK, waiting for a packet on which the ACK can be piggybacked, not getting it, and then sending the ACK, delayed.
Algoritmo de Nagle
O algoritmo Nagle pode ser visto como algo implementado no lado de envio para melhorar a eficiência, tentando sempre enviar pacotes de dados TCP de tamanho normal.
Taken from TCP/IP illustrated (vol. 1): the protocols by W. Richard Stevens
The Nagle algorithm says that when a TCP connection has outstanding data that has not yet been acknowledged, small segments (those smaller than the SMSS) cannot be sent until all outstanding data is acknowledged. Instead, small amounts of data are collected by TCP and sent in a single segment when an acknowledgment arrives. This procedure effectively forces TCP into stop-and-wait behavior, it stops sending until an ACK is received for any outstanding data.
Em termos práticos, como John Nagle menciona em este fórum .
If you turn off the Nagle algorithm and then rapidly send single bytes to a socket, each byte will go out as a separate packet. This can increase traffic by an order of magnitude or two, with throughput declining accordingly.
Interação de algoritmo ACK e Nagle atrasada
Delayed ACK and Nagle algorithm interaction is described in TCP/IP illustrated (vol. 1): the protocols by W. Richard Stevens
Consider a client using delayed ACKs that sends a request to a server, and the server responds with an amount of data that does not quite fit inside a single packet.
Here we see that the client, after receiving two packets from the server, withholds an ACK, hoping that additional data headed toward the server can be piggybacked. Generally, TCP is required to provide an ACK for two received packets only if they are full-size, and they are not here. At the server side, because the Nagle algorithm is operating, no additional packets are permitted to be sent to the client until an ACK is returned because at most one “small” packet is allowed to be outstanding. The combination of delayed ACKs and the Nagle algorithm leads to a form of deadlock (each side waiting for the other).
Você também pode ler sobre os problemas causados pela interação entre o Algoritmo de Nagle e o ACK Adiado em este artigo de Stuart Cheshire .
