Marc Brooker, engenheiro da Amazon Web Services (AWS), desmistificou as concepções sobre a eficácia da transmissão de pequenas mensagens utilizando o algoritmo de Nagle, aplicado por padrão na pilha TCP/IP. As recomendações incluem desativar o algoritmo de Nagle por padrão, o que pode ser feito em aplicativos individuais ao definir a opção TCP_NODELAY para sockets de rede usando a chamada setsockopt, o que já é feito há muito tempo em projetos como Node.js e curl.
O algoritmo de Nagle permite agregar pequenas mensagens para reduzir o tráfego — ele pausa o envio de novos segmentos TCP até receber a confirmação da recepção dos dados previamente enviados. Por exemplo, sem a agregação, ao enviar 1 byte, 40 bytes adicionais de cabeçalhos TCP e IP são enviados. Em condições modernas, o uso do algoritmo de Nagle resulta em latências significativas, inaceitáveis para aplicações interativas e distribuídas.
Três principais argumentos são apresentados em favor do uso padrão da opção TCP_NODELAY, que desativa o algoritmo de Nagle:
- Incompatibilidade do algoritmo de Nagle com a otimização "delayed ACK", onde a resposta ACK não é enviada imediatamente, mas após receber os dados de resposta. O problema é que, no algoritmo de Nagle, a chegada do pacote ACK é um sinal para enviar dados agregados, e se o pacote ACK não chegou, o envio ocorre apenas após um timeout. Assim, surge um círculo vicioso, e o pacote ACK como sinal não funciona, pois o outro lado não recebe os dados devido à sua acumulação no lado do remetente, e o remetente não os envia até o timeout, pois não recebe o pacote ACK.
- O RFC para o algoritmo de Nagle foi aceito em 1984 e não é projetado para os parâmetros das modernas redes de alta velocidade e servidores data centers, o que leva a problemas de responsividade. O tempo de latência entre o envio de uma solicitação e a recepção da resposta (RTT) em redes modernas é de 0.5 ms + alguns milissegundos na troca de dados entre data centers em uma mesma região + até cem milissegundos ao enviar globalmente. Durante esses milissegundos, um servidor moderno pode realizar uma enorme quantidade de trabalho.
- Aplicações distribuídas modernas não enviam mais bytes individuais de dados; a agregação de pequenos dados geralmente é realizada no nível do aplicativo. Mesmo que o tamanho dos dados úteis seja de apenas alguns bytes, o tamanho real das informações enviadas geralmente aumenta substancialmente após a aplicação da serialização, o uso de APIs em JSON e o envio utilizando criptografia TLS. A economia de 40 bytes se torna menos relevante.
Fonte: opennet.ru
