Un enginyer AWS suggereix reemplaçar Nagle per TCP_NODELAY per solucionar els problemes de latència

Latència a Linux

Fa pocs dies, Marc Brooker, un enginyer d'AWS, critic i va abordar els problemes amb els quals sempre ha hagut de bregar en el tema eficiència en les transferències de missatges petits quan es fa servir l'algorisme Nagle.

I és que esmenta que avui dia en els sistemes distribuïts, la latència és un factor crític que pot impactar significativament en el rendiment i lexperiència de lusuari i una de les solucions clau és la configuració de paràmetres com TCP_NODELAY.

Marc esmenta que tot i que «els problemes de latència que es van solucionar ràpidament al habilita aquesta opció de socket simple» TCP_NODELAY, aquesta no està habilitada, ja que l'opció predeterminada a la pila TCP/IP és l'algorisme de Nagle.

L'algoritme de Nagle, formulat al RFC896 per John Nagle el 1984, va tenir com a objectiu abordar l'eficiència en la transmissió de dades a les xarxes TCP. Aquest permet afegir missatges petits per reduir el trànsit, suspenent l'enviament de nous segments TCP fins que es rebi la confirmació de recepció de les dades enviades anteriorment. Per exemple, sense aplicar agregació, en enviar 1 byte s'envien 40 bytes addicionals amb capçaleres de paquets TCP i IP. En les condicions modernes, l'ús de l'algorisme Nagle provoca un augment notable dels retards, cosa que és inacceptable per a aplicacions interactives i distribuïdes.

Una de les complexitats que van sorgir amb la implementació de l'algorisme de Nagle va ser el seu interacció amb els ACK retardats. Mentre Nagle buscava optimitzar la mida dels paquets enviats, els ACKs retardats endarrerien l'enviament de confirmacions de paquets rebuts. Aquesta combinació pot generar problemes de latència en aplicacions sensibles a aquest factor.

A més d'això, Marc ha citat tres raons principals per utilitzar TCP_NODELAY com a predeterminada, en lloc de Nagle, el qual suggereixi sigui deshabilitat:

  1. Incompatibilitat amb l'optimització ACK endarrerit: L'algorisme de Nagle entra en conflicte amb l'estratègia d'ACK endarrerit, on la resposta ACK no s'envia immediatament sinó després de rebre les dades de la resposta. El problema és que, a l'algoritme de Nagle, l'arribada d'un paquet ACK és un senyal per enviar dades agregades. Si el paquet ACK no es rep, l'enviament es fa quan s'esgota el temps d'espera. Això crea un cicle el paquet ACK com a senyal no funciona perquè l'altra banda no rep les dades a causa de la seva acumulació al costat del remitent, i el remitent no les envia abans del temps d'espera en no rebre el paquet ACK.
  2. Antiguitat del RFC de l'algorisme de Nagle: El RFC per a l'algorisme de Nagle es va adoptar el 1984 i no està dissenyat per a les xarxes i servidors moderns d'alta velocitat als centres de dades, cosa que genera problemes de capacitat de resposta. A les xarxes modernes, el retard entre l'enviament d'una sol·licitud i la recepció d'una resposta (RTT) és molt curt, cosa que permet als servidors moderns fer una enorme quantitat de treball durant aquests breus intervals de temps.
  3. Canvis al patró d'enviament de dades: Les aplicacions distribuïdes modernes ja no envien bytes individuals de dades, i l'agregació de dades petites generalment s'implementa al nivell de l'aplicació. Fins i tot si la mida de càrrega útil és mínima, la mida real de la informació enviada augmenta significativament després d'aplicar la serialització, l'ús d'APIs JSON i l'enviament mitjançant xifratge TLS. Per tant, l'estalvi de 40 bytes esdevé menys rellevant en comparació amb el rendiment i la capacitat de resposta millorats en deshabilitar l'algorisme de Nagle.

És per això que Brooker ha fet una crida per deshabilitar l'algorisme Nagle per defecte. Això es pot aconseguir configurant l'opció TCP_NODELAY per a sockets de xarxa usant l'anomenada setsockopt, com s'ha fet durant molt de temps en projectes com ara Node.js i curl.

Finalment, si estàs interessat a poder conèixer més sobre això, pots consultar els detalls al següent enllaç.


Deixa el teu comentari

La seva adreça de correu electrònic no es publicarà. Els camps obligatoris estan marcats amb *

*

*

  1. Responsable de les dades: Miguel Ángel Gatón
  2. Finalitat de les dades: Controlar l'SPAM, gestió de comentaris.
  3. Legitimació: El teu consentiment
  4. Comunicació de les dades: No es comunicaran les dades a tercers excepte per obligació legal.
  5. Emmagatzematge de les dades: Base de dades allotjada en Occentus Networks (UE)
  6. Drets: En qualsevol moment pots limitar, recuperar i esborrar la teva informació.