The OpenNET Project / Index page

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

Актуальность опции TCP_NODELAY для распределённых приложений
Один из инженеров Amazon Web Services (AWS) разобрал заблуждения, связанные
с повышением эффективности передачи мелких сообщений при  использовании
алгоритма Нейгла, применяемого по умолчанию в 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 байтов становится не столь актуальной.
 
10.05.2024 , Источник: https://brooker.co.za/blog/2024/05/...
Ключи: tcp, tcp_nodelay, optimization, latency / Лицензия: CC-BY
Раздел:    Корень / Администратору / Сетевая подсистема, маршрутизация / Туннелинг, VPN, VLAN

Обсуждение [ RSS ]
  • 1, An (??), 13:54, 10/05/2024 [ответить]  
  • +/
    https://access.redhat.com/documentation/ru-ru/red_hat_enterprise_linux_for_rea
     
  • 3, pavlinux (ok), 19:59, 16/05/2024 [ответить]  
  • +1 +/
    https://www.opennet.ru/openforum/vsluhforumID3/133690.html#109
     
  • 4, Ivan_83 (ok), 23:19, 26/07/2024 [ответить]  
  • +/
    А по факту всё работает прекрасно и так и эдак, и профита от выключения на практике не видно.
     
  • 5, InuYasha (??), 11:33, 30/10/2024 [ответить]  
  • +/
    > если размер полезных данных составляет 1 байт, то, как правило, фактически

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

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

     


     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:




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

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