Кратко

  • Правило Нейгла разрешает первый небольшой сегмент, когда прежних неподтверждённых данных нет, а последующие малые записи удерживает до прихода подтверждения или накопления полного сегмента.
  • Оно отличается от задержанных подтверждений, предотвращения Silly Window Syndrome и управления перегрузкой; приложение должно иметь возможность отключить правило для отдельного соединения.

RFC 896, опубликованный в январе 1984 года, описал проблему малых пакетов в ранних сетях TCP/IP. Приложение, выдающее по одному символу, могло отправлять один полезный байт вместе с сорока байтами заголовков TCP и IP. В неоднородных и перегруженных сетях поток таких пакетов расходовал пропускную способность и ресурсы шлюзов, усиливал перегрузку и мог приводить к потерям и повторным передачам.

Фиксированные таймеры накопления длительностью 200–500 миллисекунд было трудно настроить для сетей с разной полосой пропускания и задержкой туда-обратно. Значение, подходящее для локальной сети, могло почти не собирать данные на длинном маршруте; значение для длинного маршрута могло ухудшать локальную отзывчивость. Предложение Нейгла сделало условием отправки состояние подтверждений, а не прошедшее время.

RFC 1122 задаёт проверку SND.NXT > SND.UNA. Если она истинна, уже отправленные данные ещё не подтверждены. Отправитель буферизует пользовательские данные независимо от бита PSH, пока прежние данные не будут подтверждены или очередь не достигнет размера полного сегмента Eff.snd.MSS. Полный сегмент является самостоятельным условием выпуска. Если соединение простаивало и данных в полёте нет, первая малая запись может быть отправлена сразу.

RFC 1122 рекомендует реализациям TCP применять алгоритм Нейгла, но одновременно требует предоставить приложению возможность отключить его для отдельного соединения. RFC 9293 сохраняет эту нормативную границу и напоминает, что отправка по-прежнему ограничена медленным стартом. Нейгл решает, формировать ли ещё один малый сегмент, но не заменяет управление перегрузкой.

Правило также не определяет, когда получатель отправляет подтверждение. RFC 9293 отделяет Нейгла от предотвращения Silly Window Syndrome и предупреждает о возможном неблагоприятном взаимодействии с задержанными подтверждениями. Отправитель может ждать продвижения ACK, пока получатель намеренно откладывает ACK; два локально разумных механизма способны добавить задержку на границе взаимодействия.

Источники