C'è uno storico problema di TCP che torna periodicamente nelle discussioni online (quella di oggi): il modo in cui l'algoritmo di Nagle e gli ACK ritardati interagiscono causando latenza aggiuntiva non necessaria. Nello specifico:
- L'algoritmo di Nagle ritarda la trasmissione di dati da parte del client finché ci sono dei dati non confermati, con l'idea di ridurre l'overhead dell'header TCP/IP. Ad esempio se scrivo una lettera in un terminale remoto i dati da trasmettere sono pari a 1 byte, ma gli header sono decine di byte.
- Gli ACK ritardati agiscono dall'altro lato della connessione ritardando appunto gli ACK se si ritiene che ci saranno a breve (es. 200ms) dati di risposta da inviare (piggybacking sull'ACK).
Il risultato è questo:
The interaction between these two features causes a problem: Nagle’s algorithm is blocking sending more data until an ACK is received, but delayed ack is delaying that ack until a response is ready.
Da qui la "proposta" di un ingegnere AWS di disattivare Nagle praticamente sempre, e quindi attivare l'opzione TCP_NODELAY sui socket oppure a livello di sistema operativo:
First, the uncontroversial take: if you’re building a latency-sensitive distributed system running on modern datacenter-class hardware, enable TCP_NODELAY (disable Nagle’s algorithm) without worries. You don’t need to feel bad. It’s not a sin. It’s OK. Just go ahead.
More controversially, I suspect that Nagle’s algorithm just isn’t needed on modern systems, given the traffic and application mix, and the capabilities of the hardware we have today. In other words, TCP_NODELAY should be the default.