Алгоритм Наглса - Nagles algorithm

Алгоритм Нэгла является средством повышения эффективности TCP / IP сети за счет уменьшения количества пакетов, которые необходимо отправить по сети. Он был определен Джоном Нэглом во время работы в Ford Aerospace. Он был опубликован в 1984 году как Запрос комментариев (RFC) с заголовком Контроль перегрузки в сетях IP / TCP (видеть RFC 896 ).

RFC описывает то, что он назвал «проблемой малых пакетов», когда приложение постоянно выдает данные небольшими порциями, часто только 1 байт по размеру. С TCP пакеты имеют 40-байтовый заголовок (20 байтов для TCP, 20 байтов для IPv4 ), это приводит к 41-байтовому пакету для 1 байта полезной информации, огромным накладным расходам. Такая ситуация часто возникает в Telnet сеансы, в которых большинство нажатий клавиш генерируют один байт данных, который передается немедленно. Что еще хуже, по медленным каналам многие такие пакеты могут передаваться одновременно, что потенциально может привести к коллапс заторов.

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

Алгоритм

RFC определяет алгоритм как

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

Где MSS - это максимальный размер сегмента, самый большой сегмент, который может быть отправлен по этому соединению, и размер окна это приемлемое в настоящее время окно неподтвержденных данных, это может быть записано в псевдокоде как[нужна цитата ]

если есть новые данные для отправки тогда    если размер окна ≥ MSS и доступные данные ≥ MSS тогда        отправить полный сегмент MSS сейчас еще        если в трубе еще есть неподтвержденные данные тогда            помещать данные в буфер до получения подтверждения еще            отправить данные немедленно конец, если    конец, есликонец, если

Взаимодействие с отложенным ACK

Этот алгоритм плохо взаимодействует с Отложенные подтверждения TCP (отложенный ACK), функция, введенная в TCP примерно в то же время в начале 1980-х, но другой группой. При включенных обоих алгоритмах приложения, которые выполняют две последовательные записи в TCP-соединение, за которыми следует чтение, которое не будет выполнено до тех пор, пока данные из второй записи не достигнут места назначения, испытывают постоянную задержку до 500 миллисекунд, "ACK delay ». Рекомендуется отключить любой из них, хотя традиционно проще отключить Nagle, поскольку такой переключатель уже существует для приложений реального времени.

Решение, рекомендованное Нэглом, состоит в том, чтобы избежать отправки алгоритмом преждевременных пакетов путем буферизации записи приложения и последующей очистки буфера:[1]

Решение на уровне пользователя - избегать последовательностей записи-записи-чтения на сокетах. Запись – чтение – запись – чтение в порядке. Запись – запись – запись в порядке. Но запись-запись-чтение - убийца. Так что, если можете, скопируйте свои небольшие записи в TCP и отправьте их все сразу. Обычно работает использование стандартного пакета ввода-вывода UNIX и запись на диск перед каждым чтением.

Нэгл считает отложенные ACK "плохой идеей", поскольку уровень приложения обычно не отвечает в пределах временного окна.[2] Для типичных случаев использования он рекомендует отключить «отложенный ACK» вместо своего алгоритма, поскольку «быстрые» ACK не несут столько накладных расходов, как многие небольшие пакеты.[3]

Отключение Nagle или отложенного ACK

Реализации TCP обычно предоставляют приложениям интерфейс для отключения алгоритма Нэгла. Обычно это называется TCP_NODELAY вариант. В Microsoft Windows TcpNoDelay переключатель реестра определяет значение по умолчанию. TCP_NODELAY присутствует со стека TCP / IP в 4.2BSD 1983 года, у него много потомков.[4]

Интерфейс для отключения отложенного ACK не согласован между системами. В TCP_QUICKACK flag доступен в Linux с 2001 года (2.4.4) и, возможно, в Windows, где официальный интерфейс SIO_TCP_SET_ACK_FREQUENCY.[5] Параметр TcpAckFrequency 1 в реестре Windows по умолчанию отключает отложенный ACK.[6]

Отрицательное влияние на большие записи

Алгоритм применим к данным любого размера. Если данные в одной записи занимают 2п пакетов, последний пакет будет задержан, ожидая ACK для предыдущего пакета.[7] В любых протоколах приложений «запрос-ответ», где данные запроса могут быть больше пакета, это может искусственно наложить задержку в несколько сотен миллисекунд между запрашивающей стороной и отвечающей стороной, даже если запрашивающая сторона должным образом буферизовала данные запроса. В этом случае запросчик должен отключить алгоритм Нэгла. Если данные ответа могут быть больше пакета, отвечающая сторона также должна отключить алгоритм Нэгла, чтобы запрашивающая сторона могла быстро получить весь ответ.

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

Взаимодействие с системами реального времени

Приложения, ожидающие ответов в реальном времени и низкие задержка может плохо реагировать с алгоритмом Нэгла. Такие приложения, как сетевые многопользовательские видеоигры или движение мыши в дистанционно управляемой операционной системе, ожидают, что действия будут отправлены немедленно, в то время как алгоритм намеренно задерживает передачу, увеличивая пропускная способность эффективность за счет задержка. По этой причине в приложениях с узкой полосой пропускания, чувствительной ко времени передачи, обычно используется TCP_NODELAY для обхода задержки ACK с задержкой по Нэгла.[8]

Другой вариант - использовать UDP вместо.

Реализация операционных систем

Большинство современных операционных систем реализуют алгоритмы Нэгла. В AIX[9] и Linux и Windows [10] он включен по умолчанию и может быть отключен для каждого сокета с помощью TCP_NODELAY вариант.

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

  1. ^ Джон Нэгл (19 января 2006 г.), Повышение производительности сокетов в Linux, Slashdot
  2. ^ Нэгл, Джон. «Вздох. Если вы выполняете массовую передачу файлов, вы никогда не столкнетесь с этой проблемой. (Ответ 9048947)». Хакерские новости. Получено 9 мая 2018.
  3. ^ Нэгл, Джон. «Тот фиксированный таймер задержки ACK на 200 мс был ужасной ошибкой. Почему 200 мс? Время реакции человека. (Ответ 9050645)». Хакерские новости. Получено 9 мая 2018.
  4. ^ TCP (4) – FreeBSD Интерфейсы ядра Руководство
  5. ^ "сокеты - C ++ отключить отложенное подтверждение в Windows". Переполнение стека.
  6. ^ «Новая запись реестра для управления поведением подтверждения TCP (ACK) в Windows XP и Windows Server 2003».
  7. ^ «Проблемы производительности TCP, вызванные взаимодействием между алгоритмом Нэгла и отложенным ACK». Stuartcheshire.org. Получено 14 ноября, 2012.
  8. ^ Ошибка 17868 - некоторые приложения Java работают медленно при удаленных X-соединениях..
  9. ^ «Центр знаний IBM». www.ibm.com.
  10. ^ «Как можно отключить алгоритм Нэгла в Linux?». Переполнение стека.

внешняя ссылка