Отложенное подтверждение TCP - TCP delayed acknowledgment - Wikipedia

Отложенное подтверждение TCP это метод, используемый некоторыми реализациями Протокол управления передачей в стремлении улучшить производительность сети. По сути, несколько ACK ответы могут быть объединены в один ответ, уменьшая накладные расходы протокола. Однако в некоторых случаях этот метод может снизить производительность приложения.

Метод и преимущества

Как описано в RFC 1122, хост может задержать отправку ответа ACK до 500 мс. Кроме того, с потоком полноразмерных входящих сегментов ответы ACK должны отправляться для каждого второго сегмента.

Задержанные ACK могут дать приложению возможность обновить Окно приема TCP а также, возможно, отправить немедленный ответ вместе с ACK. Для определенных протоколов, таких как Telnet, отложенные ACK могут уменьшить количество ответов, отправляемых сервером, в 3 раза, путем объединения ACK, обновления окна и данных ответа в один сегмент.[1]

Проблемы

Дополнительное время ожидания, вызванное отложенным ACK, может вызвать дополнительные задержки при взаимодействии с определенными приложениями и конфигурациями. Если Алгоритм Нэгла используется отправляющей стороной, данные будут помещены в очередь отправителем до получения ACK. Если отправитель не отправляет достаточно данных для заполнения максимальный размер сегмента (например, если он выполняет две небольших записи, за которыми следует блокирующее чтение), то передача будет приостановлена ​​до истечения времени ожидания задержки ACK. Linux 2.4.4+ поддерживает TCP_QUICKACK параметр сокета, отключающий отложенное ACK.[2]

Например, рассмотрим ситуацию, когда Боб отправляет данные Кэрол. На уровне сокетов Боба осталось отправить меньше данных, чем полный пакет. Согласно алгоритму Нагла, оно не будет отправлено, пока он не получит ACK для уже отправленных данных. В то же время прикладной уровень Кэрол не будет отправлять ответ, пока не получит все данные. Если Кэрол использует отложенные ACK, ее уровень сокета не будет отправлять ACK, пока не истечет время ожидания.

Если приложение передает данные небольшими порциями и ожидает периодических подтверждений, может произойти это негативное взаимодействие. Чтобы предотвратить эту задержку, прикладной уровень должен непрерывно отправлять данные, не дожидаясь ответов с подтверждением. В качестве альтернативы алгоритм Нэгла может быть отключен приложением на отправляющей стороне.

Рекомендации

  1. ^ http://tools.ietf.org/html/rfc1122#page-96
  2. ^ "tcp (7) в Linux". manpages.info. Получено 9 мая 2018.