Кратко

  • Получатель может ненадолго удержать ACK первого упорядоченного сегмента, чтобы подтвердить сразу два или совместить подтверждение со своим ответом.
  • Второй сегмент, истечение таймера либо свидетельство потери прекращают ожидание до того, как экономия превратится в отсутствие управления.

К началу задержки байты уже приняты, а следующий ожидаемый номер последовательности продвинут. Ждёт только сообщение отправителю. Второй полный сегмент позволяет одному накопительному ACK охватить оба; если его нет, подтверждение выпускает таймер.

RFC 1122 рекомендовал delayed ACK ради меньшей нагрузки на хосты и сеть, одновременно потребовав задержку менее 0,5 секунды и рекомендовав хотя бы один ACK на каждые два полноразмерных сегмента. В примере интерактивного терминала пауза позволяла объединить ACK, обновление окна и возвращаемый символ.

RFC 5681 уточнил: рекомендуется подтверждать как минимум каждый второй полноразмерный сегмент, а ожидание второго сегмента никогда не должно превышать 500 мс. Счётчик 2*RMSS способен породить stretch ACK, если отправитель из-за MTU пути использует меньшие сегменты: одно подтверждение тогда охватывает более двух фактических сегментов. Чтобы этого избежать, рекомендуется подтверждать по меньшей мере каждый второй полученный сегмент независимо от его размера.

Пробел в последовательности меняет приоритет. RFC 5681 рекомендует немедленно отвечать дублирующим ACK на данные выше пробела; на данные, заполняющие пробел полностью или частично, также рекомендуется отвечать немедленно. ACK здесь сообщает ход восстановления, а не просто экономит управляющий пакет.

RFC 2525 зафиксировал stretch ACK как известную ошибку реализации. Приход ACK участвует в управляющем такте отправителя, поэтому чрезмерное объединение способно замедлить рост и сделать выпуск данных более пакетным.