¿Qué hace net.ipv4.tcp_app_win?

Question

No puedo entender por qué las variables tcp_adv_win_scale y  tcp_app_wincoexisten en Linux. La información deTCP(7)dice:

Para tcp_adv_win_scale:

tcp_adv_win_scale(entero; predeterminado: 2; desde Linux 2.4)

Cuente la sobrecarga del almacenamiento en búfer comobytes/2^tcp_adv_win_scale, si tcp_adv_win_scalees mayor que 0; o bytes-bytes/2^(-tcp_adv_win_scale), sitcp_adv_win_scalees menor o igual a cero.

 El espacio del buffer de recepción del socket se comparte entre la aplicación y el kernel. TCP mantiene parte del búfer como ventana TCP, este es el tamaño de la ventana de recepción anunciada en el otro extremo. El resto del espacio se utiliza como búfer de "aplicación", que se utiliza para aislar la red de la programación y las latencias de las aplicaciones. Eltcp_adv_win_scaleEl valor predeterminado de 2 implica que el espacio utilizado para el búfer de la aplicación es una cuarta parte del total.

Y para tcp_app_win:

tcp_app_win(entero; predeterminado: 31; desde Linux 2.4)

Esta variable define cuántos bytes de la ventana TCP se reservan para la sobrecarga del almacenamiento en búfer.

Un máximo de (window/2^tcp_app_win, mss) los bytes de la ventana están reservados para el búfer de la aplicación. Un valor de 0 implica que no se reserva ningún importe.

Así que no estoy seguro de entender qué tcp_app_wincambia exactamente. Me parece que ambas variables se pueden utilizar para modificar el búfer de la aplicación TCP, por lo que no es necesario cambiarlas juntas. ¿Estoy en lo correcto?

Answer 1

Encontré esta información que habla de tcp_adv_win_scale. La página se titula:Ajuste del rendimiento de TCP: cómo ajustar Linux.

extracto

El rendimiento de TCP está limitado por la latencia y el tamaño de la ventana (y la sobrecarga, lo que reduce el tamaño efectivo de la ventana) por el tamaño de la ventana/RTT (esta es la cantidad de datos que pueden estar "en tránsito" a través del enlace en un momento dado).

Para obtener las velocidades de transferencia reales posibles, debes dividir la ventana resultante por la latencia (en segundos):

La sobrecarga es: ventana/2^tcp_adv_win_scale (el valor predeterminado de tcp_adv_win_scale es 2)

Entonces, para Linux, los parámetros predeterminados para la ventana de recepción (tcp_rmem): 87380 - (87380/2^2) = 65536.

Dado un enlace transatlántico (RTT de 150 ms), el rendimiento máximo termina en: 65536/0,150 = 436906 bytes/s o alrededor de 400 kbytes/s, lo que es realmente lento hoy en día.

Con el tamaño predeterminado aumentado: (873800 - 873800/2^2)/0,150 = 4369000 bytes/s, o aproximadamente 4 Mbytes/s, lo cual es razonable para una red moderna. Y tenga en cuenta que este es el valor predeterminado, si el remitente está configurado con un tamaño de ventana más grande, felizmente escalará hasta 10 veces (8738000*0,75/0,150 = ~40 Mbytes/s), bastante bueno para una red moderna.

2.6.17 y posteriores tienen valores predeterminados razonablemente buenos y, de hecho, ajustan el tamaño de la ventana hasta el máximo permitido, si el otro lado lo admite. Desde entonces, la mayor parte de esta guía no es necesaria. Sin embargo, para obtener un buen rendimiento de larga distancia, es posible que sea necesario aumentar el valor máximo.

Pude seguir eso pero no entendí muy bien la relación, si la hay, entre estas 2 variables.

Sólo entendí marginalmente lo que eso estaba tratando de explicar. En esencia, parece que este parámetro para escalar la cantidad de espacio de almacenamiento en búfer se utilizará para TCP y para la aplicación.

Buscando un poco más encontré estas explicaciones que tenían más sentido. La página se tituló:Tutorial de Ipsysctl 1.0.4 - Capítulo 3. Referencia de variables IPv4.

extracto

3.3.2. tcp_adv_win_scale

Esta variable se utiliza para indicarle al kernel cuánto espacio del búfer del socket debe usarse para el tamaño de la ventana TCP y cuánto guardar para el búfer de una aplicación. Si tcp_adv_win_scale es negativo, se utiliza la siguiente ecuación para calcular la sobrecarga del búfer para el escalado de la ventana:

Donde bytes es la cantidad de bytes en la ventana. Si el valor de tcp_adv_win_scale es positivo, se utiliza la siguiente ecuación para calcular la sobrecarga del búfer:

La variable tcp_adv_win_scale toma un valor entero y está establecida de forma predeterminada en 2. Esto a su vez significa que el búfer de la aplicación es 1/4 del espacio total del búfer especificado en la variable tcp_rmem.

3.3.3. tcp_app_win

Esta variable le dice al kernel cuántos bytes reservar para una ventana TCP específica en el búfer de memoria de los sockets TCP donde se transfiere la ventana TCP específica. Este valor se utiliza en un cálculo que especifica cuánto espacio de búfer reservar que se ve como la siguiente:

Como puede comprender del cálculo anterior, cuanto mayor sea este valor, menor será el espacio del búfer para la ventana específica. La única excepción a este cálculo es 0, que le indica al kernel que no reserve espacio para esta conexión específica. El valor predeterminado para esta variable es 31 y, en general, debería ser un buen valor. No cambie este valor a menos que sepa lo que está haciendo.

Según estas explicaciones, parece que el primer parámetro tcp_adv_win_scalecontrola la división del espacio del búfer del socket en términos de cómo se divide para el uso de la ventana TCP frente al búfer de la aplicación.

Mientras que el segundo parámetro tcp_app_winespecifica el número de bytes que se reservarán para el búfer de la aplicación mencionado en la tcp_adv_win_scaledescripción.

Answer 2

Aquí están mis hallazgos de las fuentes del kernel:

• tcp_adv_win_scale se usa en macrotcp_win_from_space en incluir/net/tcp.h. Esta macro se utiliza enfunción tcp_grow_window en net/ipv4/tcp_input.c.
  Parece que se usa solo para conexiones establecidas, no para conectar.
  El valor predeterminado para este parámetro es 1, lo que da como resultado el 50% del búfer rcv para la aplicación.
• tcp_app_win se utiliza enfunción tcp_init_buffer_space en net/ipv4/tcp_input.c.
  Parece que se usa solo en conexiones y no para conexiones establecidas.
  El valor predeterminado para este parámetro es 31, lo que da como resultado un 0,0% del búfer rcv para la aplicación.

Yo diría que la lógica no es reservar el búfer para su aplicación en nuevas conexiones y aumentarlo al recibir datos.
De esa manera, en teoría, el rwnd inicial podría anunciarse tan grande como todo el búfer. El remitente enviará esa cantidad de datos. El búfer del receptor se llenará, el receptor reducirá las ganancias y aumentará la porción del búfer de la aplicación de acuerdo con tcp_adv_win_scale.
Entonces, como se menciona en@slmrespuesta: parece que no hay ninguna razón para tocar tcp_app_win.