Марк Брукер (Marc Brooker), инженер от Amazon Web Services (AWS), разъяснил заблуждения, касающиеся повышения эффективности передачи мелких сообщений, применяя алгоритм Нейгла, используемый по умолчанию в стеке TCP/IP. Рекомендуется отключить алгоритм Нейгла по умолчанию, что в контексте отдельных приложений может быть выполнено путем установки опции TCP_NODELAY для сетевых сокетов с помощью вызова setsockopt, что давно реализовано в таких проектах, как Node.js и curl.
Алгоритм Нейгла позволяет агрегировать мелкие сообщения для снижения трафика — он приостанавливает отправку новых TCP-сегментов до тех пор, пока не будет получено подтверждение о приемке ранее отправленных данных. Например, без применения агрегирования при отправке 1 байта дополнительно отправляется 40 байтов с заголовками TCP и IP. В современных условиях использование алгоритма Нейгла вызывает заметное увеличение задержек, что неприемлемо для интерактивных и распределенных приложений.
Существует три основных аргумента в пользу использования опции TCP_NODELAY по умолчанию, отключающей алгоритм Нейгла:
- Несовместимость алгоритма Нейгла с оптимизацией «delayed ACK», при которой ответ ACK не отправляется сразу, а после получения ответных данных. Проблема заключается в том, что в алгоритме Нейгла получение пакета ACK является сигналом для отправки агрегированных данных, а если пакет ACK не получен, отправка выполняется по таймауту. Таким образом, возникает замкнутый круг: пакет ACK как сигнал не работает, так как другая сторона не получает данные из-за их накопления на стороне отправителя, а отправитель не отправляет их до таймаута, так как не получает пакет ACK.
- RFC для алгоритма Нейгла был принят в 1984 году, и он не подходит под характеристики современных высокоскоростных сетей и сървъри датацентров, что приводит к возникновению проблем с отзывчивостью. Задержка между отправкой запроса и получением ответа (RTT) в современных сетях составляет 0.5 мс + несколько миллисекунд при обмене данными между датацентрами в одном регионе + до ста миллисекунд при передачи по всему миру. За эти миллисекунды современный сервер способен выполнить огромный объём работы.
- Съвременните разпределени приложения отдавна не изпращат единични байтове данни, а агрегиране на малки данни обикновено се реализира на ниво приложение. Дори когато размерът на полезните данни е само няколко байта, реалният размер на изпратената информация обикновено нараства значително след прилагане на сериализация, използване на API обвивки в JSON и изпращане с TLS криптиране. Спестяването на 40 байта не става толкова актуално.
Източник: opennet.ru
