Resumo

  • A regra de Nagle permite um primeiro envio pequeno quando não há dados anteriores pendentes e retém pequenas escritas seguintes até chegar uma confirmação ou formar-se um segmento completo.
  • Ela é separada de confirmações atrasadas, da prevenção de Silly Window Syndrome e do controle de congestionamento; a aplicação também deve poder desativá-la por conexão.

Em janeiro de 1984, a RFC 896 descreveu um problema das primeiras redes TCP/IP. Uma aplicação que emitisse um caractere por vez podia transportar um byte útil acompanhado de quarenta bytes de cabeçalhos TCP e IP. Em redes heterogêneas e enlaces sobrecarregados, muitos pacotes pequenos consumiam capacidade de transmissão e processamento dos gateways, agravavam o congestionamento e podiam contribuir para perdas e retransmissões.

Temporizadores de 200 a 500 milissegundos pareciam uma solução, mas eram difíceis de ajustar para redes com diferentes larguras de banda e tempos de ida e volta. Um valor adequado a uma rede local podia agregar pouco em um caminho longo; um valor adequado a esse caminho podia tornar a interação local lenta. A proposta de Nagle substituiu o relógio por uma condição observável no estado de confirmação.

A RFC 1122 descreve essa condição como SND.NXT > SND.UNA. Enquanto ela for verdadeira, há dados transmitidos ainda não confirmados. O emissor armazena os novos dados do usuário, independentemente do bit PSH, até que os dados pendentes sejam confirmados ou a fila alcance um segmento completo de tamanho Eff.snd.MSS. Portanto, um segmento completo é uma condição de liberação independente. Se a conexão estava ociosa e não há dados em trânsito, a primeira escrita pequena pode ser enviada imediatamente.

A RFC 1122 diz que TCP deveria implementar Nagle, mas exige que a aplicação possa desativá-lo em uma conexão individual. A RFC 9293 preserva essa fronteira e lembra que o envio continua sujeito ao slow start. Nagle decide sobre a formação de outro segmento pequeno; não concede uma autorização geral para transmitir nem substitui o controle de congestionamento.

A regra também não determina quando o receptor envia uma confirmação. A RFC 9293 distingue Nagle da prevenção de Silly Window Syndrome e alerta para sua interação com confirmações atrasadas. O emissor pode esperar o avanço de um ACK enquanto o receptor retarda sua confirmação; juntos, dois controles localmente razoáveis podem acrescentar uma pausa sem que qualquer um esteja violando o TCP.

Fontes