Назад | Перейти на главную страницу

вопросы о nagle vs. delayed ack

Я читал, что отложенное подтверждение онлайн в сочетании с алгоритмом Нэгла может иметь проблемы с производительностью. Но, как я понимаю, алгоритм Нагла задерживается. Если они не совпадают, в чем разница?

Это не одно и то же, но они как-то связаны, и при совместном использовании могут возникнуть некоторые подводные камни и проблемы.

Отложенный ACK

Отложенный ACK можно рассматривать как нечто реализованное на принимающей стороне. При отложенном ACK, ACK не отправляются немедленно, а задерживаются на некоторое время (обычно 200 мс) в надежде, что ACK, который он должен отправить, может быть объединен или «совмещен» с некоторыми данными, которые локальное приложение желает отправить в другом направлении. .

Отложенный ACK дает приложению возможность обновить окно и, возможно, отправить немедленный ответ. В частности, в случае удаленного входа в систему в символьном режиме отложенный ACK может уменьшить количество сегментов, отправляемых сервером, в 3 раза (ACK, обновление окна и эхо-символ, объединенные в один сегмент).

Кроме того, на некоторых крупных многопользовательских хостах отложенный ACK может существенно снизить накладные расходы на обработку протокола за счет уменьшения общего количества обрабатываемых пакетов. Однако чрезмерные задержки ACK могут нарушить синхронизацию двустороннего обмена и алгоритмы "синхронизации" пакетов. rfc1122

Отложенный ACK используется, чтобы избежать таких ситуаций:

Client              Server
  |                   |
  |----- Request ---->|
  |                   |
  |<------ ACK -------|
  |                   |
  |<---- Response ----|
  |                   |
  |------- ACK ------>|

С отложенным ACK TCP отправит запрос ACK и ответ в одном сегменте.

Client              Server
  |                   |
  |----- Request ---->|
  |                   |
  |<-- Response/ACK---|
  |                   |
  |------- ACK ------>|

Джон Нэгл упоминает в этот форум

Задержанный ACK - это ставка на то, что другой конец почти сразу ответит на то, что вы только что отправили. За исключением некоторых протоколов RPC, это маловероятно. Таким образом, механизм задержки ACK теряет ставку снова и снова, задерживая ACK, ожидая пакета, в который ACK может быть совмещен, не получая его, а затем отправляя ACK с задержкой.

Алгоритм Нэгла

Алгоритм Нагла можно рассматривать как нечто реализованное на отправляющей стороне для повышения эффективности, пытаясь всегда отправлять полноразмерные пакеты данных TCP.

Взято из Иллюстрированный TCP / IP (том 1): протоколы У. Ричарда Стивенса

Алгоритм Нэгла говорит, что когда TCP-соединение имеет ожидающие данные, которые еще не подтверждены, небольшие сегменты (меньшие, чем SMSS) не могут быть отправлены, пока не будут подтверждены все ожидающие данные. Вместо этого TCP собирает небольшие объемы данных и отправляет их в одном сегменте при получении подтверждения. Эта процедура фактически заставляет TCP работать в режиме ожидания и остановки, он прекращает отправку, пока не будет получен ACK для любых ожидающих данных.

На практике, как упоминает Джон Нэгл в этот форум.

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

Отложенное взаимодействие ACK и алгоритма Нэгла

Взаимодействие отложенного ACK и алгоритма Нэгла описано в Иллюстрированный TCP / IP (том 1): протоколы У. Ричарда Стивенса

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

Здесь мы видим, что клиент, получив два пакета от сервера, удерживает ACK, надеясь, что дополнительные данные, направляемые на сервер, могут быть скопированы. Как правило, TCP требуется для предоставления ACK для двух полученных пакетов, только если они являются полноразмерными, а их здесь нет. На стороне сервера, поскольку работает алгоритм Нэгла, никакие дополнительные пакеты не могут быть отправлены клиенту до тех пор, пока не будет возвращен ACK, потому что не более одного «маленького» пакета может быть ожидающим. Комбинация отложенных ACK и алгоритма Нэгла приводит к тупиковой ситуации (каждая сторона ожидает другую).

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

Нагл: не отправляйте маленькие пакеты, пока не получите подтверждение

Отложенное подтверждение: отложенная отправка подтверждения до получения достаточного количества маленьких пакетов

так они в тупике