The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Раздел полезных советов: Актуальность опции TCP_NODELAY для распределённых приложений"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Раздел полезных советов: Актуальность опции TCP_NODELAY для распределённых приложений"  +/
Сообщение от auto_tips (??), 10-Май-24, 13:54 
Один из инженеров Amazon Web Services (AWS) [[https://brooker.co.za/blog/2024/05/09/nagle.html разобрал]] заблуждения, связанные с повышением эффективности передачи мелких сообщений при  использовании
[[https://en.wikipedia.org/wiki/Nagle%27s_algorithm алгоритма Нейгла]], применяемого по умолчанию в TCP/IP стеке.

Рекомендации сводятся к отключению по умолчанию алгоритма Нейгла через выставление опции TCP_NODELAY для сетевых сокетов при помощи вызова  setsockopt.

   setsockopt(descriptor, SOL_TCP, TCP_NODELAY, &one, sizeof(one));


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

Приводится три основных довода в пользу использования по умолчанию опции TCP_NODELAY, отключающей алгоритм Нейгла:

1. Несовместимость алгоритма Нейгла  с оптимизацией "delayed ACK", при которой ACK-ответ направляется не сразу, а после получения ответных данных. Проблема в том, что в алгоритме Нейгла поступление ACK-пакета является сигналом для отправки агрегированных данных, а если ACK-пакет не поступил, отправка выполняется при наступлении таймаута. Таким образом, возникает замкнутый круг и ACK-пакет как сигнал не работает, так как другая сторона не получает данные из-за их накопления на стороне отправителя, а отправитель не отправляет их до таймаута, так как не получает ACK-пакет.

2. RFC для алгоритма Нейгла принят в 1984 году и он не рассчитан на параметры современных высокоскоростных сетей и серверов в датацентрах, что приводит к возникновению проблем с отзывчивостью. Задержка между отправкой запроса и получением ответа (RTT) в современных сетях составляет 0.5 мс + несколько  миллисекунд при обмене данными между датацентрами в одном регионе + до сотни миллисекунд при отправке по всему миру. За эти миллисекунды современный сервер способен выполнить огромный объём работы.

3. Современные распределённые приложения давно не отправляют единичные байты данных, а агрегирование мелких данных обычно реализуется на уровне приложения. Даже если размер полезных данных составляет 1 байт, то, как правило, фактически размер отправляемой информации существенно возрастает после применения сериализации,  использования API-обвязок    в JSON и отправки с использованием TLS-шифрования. Экономия 40 байтов становится не столь актуальной.


URL: https://brooker.co.za/blog/2024/05/09/nagle.html
Обсуждается: https://www.opennet.ru/tips/info/3249.shtml

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


1. "Актуальность опции TCP_NODELAY для распределённых приложений"  +/
Сообщение от An (??), 10-Май-24, 13:54 
https://access.redhat.com/documentation/ru-ru/red_hat_enterp...
Ответить | Правка | Наверх | Cообщить модератору

3. "Актуальность опции TCP_NODELAY для распределённых приложений"  +1 +/
Сообщение от pavlinux (ok), 16-Май-24, 19:59 
https://www.opennet.ru/openforum/vsluhforumID3/133690.html#109
Ответить | Правка | Наверх | Cообщить модератору

4. "Актуальность опции TCP_NODELAY для распределённых приложений"  +/
Сообщение от Ivan_83 (ok), 26-Июл-24, 23:19 
А по факту всё работает прекрасно и так и эдак, и профита от выключения на практике не видно.
Ответить | Правка | Наверх | Cообщить модератору

5. "Актуальность опции TCP_NODELAY для распределённых приложений"  +/
Сообщение от InuYasha (??), 30-Окт-24, 11:33 
> если размер полезных данных составляет 1 байт, то, как правило, фактически

размер отправляемой информации существенно возрастает после применения
сериализации, использования API-обвязок в JSON и отправки с использованием
TLS-шифрования.

"This is why we can't have nice things"
И то, что XML ещё более громоздкий, не оправдание.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру