Что делает net.ipv4.tcp_app_win?

Question

Я не могу понять, почему tcp_adv_win_scale переменные  tcp_app_winи сосуществуют в Linux. Информация изtcp(7)говорит:

Для tcp_adv_win_scale:

tcp_adv_win_scale(целое число; по умолчанию: 2; начиная с Linux 2.4)

Подсчитайте накладные расходы на буферизацию какbytes/2^tcp_adv_win_scale, если tcp_adv_win_scaleбольше 0; или bytes-bytes/2^(-tcp_adv_win_scale), еслиtcp_adv_win_scaleменьше или равно нулю.

 Пространство буфера приема сокета разделяется между приложением и ядром. TCP сохраняет часть буфера как окно TCP, это размер окна приема, объявленный на другом конце. Оставшееся пространство используется как буфер "приложения", используемый для изоляции сети от планирования и задержек приложений.tcp_adv_win_scaleЗначение по умолчанию 2 подразумевает, что пространство, используемое для буфера приложения, составляет одну четвертую от общего объема.

И для tcp_app_win:

tcp_app_win(целое число; по умолчанию: 31; начиная с Linux 2.4)

Эта переменная определяет, сколько байтов окна TCP зарезервировано для буферизации служебных данных.

Максимум (window/2^tcp_app_win, mss) байт в окне зарезервированы для буфера приложения. Значение 0 подразумевает, что никакая сумма не зарезервирована.

Так что я не уверен, что понимаю, что tcp_app_winименно меняется. Мне кажется, что обе переменные можно использовать для настройки буфера приложения TCP, поэтому нет необходимости менять их вместе. Я прав?

Answer 1

Я нашел эту информацию, которая говорит о tcp_adv_win_scale. Страница называется:Настройка производительности TCP - как настроить Linux.

выдержка

Производительность TCP ограничена задержкой и размером окна (а также накладными расходами, которые уменьшают эффективный размер окна) по параметру window_size/RTT (это объем данных, которые могут «передаваться» по каналу в любой момент времени).

Чтобы получить реально возможную скорость передачи данных, необходимо разделить полученное окно на задержку (в секундах):

Накладные расходы составляют: window/2^tcp_adv_win_scale (tcp_adv_win_scale по умолчанию равен 2)

Итак, для Linux параметры по умолчанию для окна приема (tcp_rmem): 87380 - (87380 / 2^2) = 65536.

При трансатлантическом соединении (время передачи данных 150 мс) максимальная производительность составит: 65536/0,150 = 436906 байт/с или около 400 кбайт/с, что на сегодняшний день очень мало.

С увеличенным размером по умолчанию: (873800 - 873800/2^2)/0,150 = 4369000 байт/с, или около 4 Мбайт/с, что разумно для современной сети. И обратите внимание, что это значение по умолчанию, если отправитель настроен на больший размер окна, он с радостью масштабируется до 10 раз этого (8738000*0,75/0,150 = ~40 Мбайт/с), что довольно неплохо для современной сети.

2.6.17 и более поздние версии имеют достаточно хорошие значения по умолчанию и фактически настраивают размер окна до максимально допустимого, если другая сторона поддерживает это. Так что с тех пор большая часть этого руководства не нужна. Однако для хорошей пропускной способности на дальние расстояния максимальное значение может потребоваться увеличить.

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

Я только отчасти понял, что это пыталось объяснить. По сути, это звучит так, как будто этот параметр масштабирования объема буферного пространства должен использоваться для TCP и для приложения.

Поискав немного больше, я нашел эти объяснения, которые имели больше смысла. Страница была озаглавлена:Учебник Ipsysctl 1.0.4 - Глава 3. Справочник переменных IPv4.

выдержка

3.3.2.tcp_adv_win_scale

Эта переменная используется для того, чтобы сообщить ядру, сколько пространства буфера сокета следует использовать для размера окна TCP, а сколько сохранить для буфера приложения. Если tcp_adv_win_scale отрицательно, для расчета накладных расходов буфера для масштабирования окна используется следующее уравнение:

Где байты — это количество байтов в окне. Если значение tcp_adv_win_scale положительное, для расчета накладных расходов на буфер используется следующее уравнение:

Переменная tcp_adv_win_scale принимает целочисленное значение и по умолчанию равна 2. Это, в свою очередь, означает, что буфер приложения составляет 1/4 от общего пространства буфера, указанного в переменной tcp_rmem.

3.3.3.tcp_app_win

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

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

Исходя из этих объяснений, можно сделать вывод, что первый параметр tcp_adv_win_scaleуправляет разделением пространства буфера сокета с точки зрения того, как оно разделяется для использования окном TCP и буфером приложения.

Тогда как второй параметр tcp_app_winуказывает количество байтов, которые необходимо зарезервировать для буфера приложения, упомянутого в tcp_adv_win_scaleописании.

Answer 2

Вот мои выводы из исходников ядра:

• tcp_adv_win_scale используется в макросеtcp_win_from_space в include/net/tcp.h. Этот макрос используется вфункция tcp_grow_window в net/ipv4/tcp_input.c.
  Похоже, что он используется только для установленных соединений, а не при подключении.
  Значение по умолчанию для этого параметра равно 1, что дает 50% буфера rcv для приложения.
• tcp_app_win используется вфункция tcp_init_buffer_space в net/ipv4/tcp_input.c.
  Похоже, что он используется только при подключении, а не для установленных соединений.
  Значение по умолчанию для этого параметра равно 31, что приводит к 0,0% буфера rcv для приложения.

Я бы сказал, что логика заключается не в том, чтобы резервировать буфер для приложения в новых соединениях и увеличивать его при получении данных.
Таким образом, начальный rwnd теоретически может быть объявлен таким же большим, как весь буфер. Отправитель отправит столько данных. Буфер получателя заполнится, получатель уменьшит win и увеличит прикладную часть буфера в соответствии с tcp_adv_win_scale.
Итак, как упоминалось в@slmответ - похоже, нет причин трогать tcp_app_win.