O que net.ipv4.tcp_app_win faz?

Question

Não consigo entender por que as tcp_adv_win_scale variáveis  tcp_app_win​​e coexistem no Linux. As informações detcp(7)diz:

Para tcp_adv_win_scale:

tcp_adv_win_scale(inteiro; padrão: 2; desde Linux 2.4)

Contar sobrecarga de buffer comobytes/2^tcp_adv_win_scale, se tcp_adv_win_scaleé maior que 0; ou bytes-bytes/2^(-tcp_adv_win_scale), setcp_adv_win_scaleé menor ou igual a zero.

 O espaço do buffer de recebimento do soquete é compartilhado entre o aplicativo e o kernel. O TCP mantém parte do buffer como janela TCP, este é o tamanho da janela de recebimento anunciada para a outra extremidade. O restante do espaço é usado como buffer de “aplicativo”, usado para isolar a rede do agendamento e das latências do aplicativo. Otcp_adv_win_scaleo valor padrão de 2 implica que o espaço usado para o buffer do aplicativo é um quarto do total.

E para tcp_app_win:

tcp_app_win(inteiro; padrão: 31; desde Linux 2.4)

Esta variável define quantos bytes da janela TCP são reservados para sobrecarga de buffer.

Um máximo de (window/2^tcp_app_win, mss) bytes na janela são reservados para o buffer do aplicativo. Um valor 0 implica que nenhum valor é reservado.

Portanto, não tenho certeza de entender o que tcp_app_winexatamente muda. Parece-me que ambas as variáveis ​​podem ser usadas para ajustar o buffer do aplicativo TCP, portanto não há necessidade de alterá-las juntas. Estou correto?

Answer 1

Encontrei esta informação que fala sobre tcp_adv_win_scale. A página tem o título:Ajuste de desempenho TCP - como ajustar o Linux.

excerto

O desempenho do TCP é limitado pela latência e pelo tamanho da janela (e pela sobrecarga, que reduz o tamanho efetivo da janela) por window_size/RTT (esta é a quantidade de dados que pode estar "em trânsito" no link a qualquer momento).

Para obter as velocidades reais de transferência possíveis, você deve dividir a janela resultante pela latência (em segundos):

A sobrecarga é: window/2^tcp_adv_win_scale (o padrão tcp_adv_win_scale é 2)

Portanto, para os parâmetros padrão do Linux para a janela de recebimento (tcp_rmem): 87380 - (87380/2^2) = 65536.

Dado um link transatlântico (RTT de 150 ms), o desempenho máximo termina em: 65536/0,150 = 436906 bytes/s ou cerca de 400 kbyte/s, o que é muito lento hoje.

Com o tamanho padrão aumentado: (873800 - 873800/2^2)/0,150 = 4369000 bytes/s, ou cerca de 4Mbytes/s, o que é razoável para uma rede moderna. E observe que este é o padrão, se o remetente estiver configurado com um tamanho de janela maior, ele será dimensionado até 10 vezes (8738000*0,75/0,150 = ~40Mbytes/s), muito bom para uma rede moderna.

2.6.17 e posteriores têm valores padrão razoavelmente bons e, na verdade, ajustam o tamanho da janela até o máximo permitido, se o outro lado suportar. Desde então, a maior parte deste guia não é necessária. Para um bom rendimento de longa distância, o valor máximo pode precisar ser aumentado.

Consegui acompanhar isso, mas não entendi muito bem a relação, se houver, entre essas duas variáveis.

Eu entendi apenas marginalmente o que isso estava tentando explicar. Basicamente, parece que este parâmetro para dimensionar a quantidade de espaço de buffer deve ser usado para TCP e para o aplicativo.

Pesquisando um pouco mais encontrei essas explicações que faziam mais sentido. A página foi intitulada:Tutorial Ipsysctl 1.0.4 - Capítulo 3. Referência de variável IPv4.

excerto

3.3.2. tcp_adv_win_scale

Esta variável é usada para informar ao kernel quanto do espaço do buffer do soquete deve ser usado para o tamanho da janela TCP e quanto deve ser salvo para um buffer de aplicativo. Se tcp_adv_win_scale for negativo, a seguinte equação será usada para calcular a sobrecarga do buffer para dimensionamento de janela:

Onde bytes são a quantidade de bytes na janela. Se o valor tcp_adv_win_scale for positivo, a seguinte equação será usada para calcular a sobrecarga do buffer:

A variável tcp_adv_win_scale assume um valor inteiro e é definida como 2 por padrão. Isso, por sua vez, significa que o buffer do aplicativo é 1/4 do espaço total do buffer especificado na variável tcp_rmem.

3.3.3. tcp_app_win

Esta variável informa ao kernel quantos bytes reservar para uma janela TCP específica no buffer de memória dos soquetes TCP para onde a janela TCP específica é transferida. Este valor é usado em um cálculo que especifica quanto do espaço do buffer reservar que se parece com a seguir:

Como você pode entender pelo cálculo acima, quanto maior for esse valor, menor será o espaço do buffer para a janela específica. A única exceção a este cálculo é 0, que diz ao kernel para não reservar espaço para esta conexão específica. O valor padrão para esta variável é 31 e, em geral, deve ser um bom valor. Não altere esse valor a menos que você saiba o que está fazendo.

Com base nessas explicações, parece que o primeiro parâmetro tcp_adv_win_scaleestá controlando a divisão do espaço do buffer do soquete em termos de como ele é dividido para uso da janela TCP versus buffer do aplicativo.

Já o segundo parâmetro tcp_app_winespecifica o número de bytes a serem reservados para o buffer da aplicação mencionado na tcp_adv_win_scaledescrição.

Answer 2

Aqui estão minhas descobertas das fontes do kernel:

• tcp_adv_win_scale é usado na macrotcp_win_from_space em include/net/tcp.h. Esta macro é usada emfunção tcp_grow_window em net/ipv4/tcp_input.c.
  Parece que é usado apenas para conexões estabelecidas, não para conexão.
  O valor padrão para este parâmetro é 1, o que resulta em 50% do buffer rcv para aplicação.
• tcp_app_win é usado emfunção tcp_init_buffer_space em net/ipv4/tcp_input.c.
  Parece que é usado apenas para conexão e não para conexões estabelecidas.
  O valor padrão para este parâmetro é 31, o que resulta em 0,0% de buffer rcv para aplicação.

Eu diria que a lógica não é reservar buffer para aplicação em novas conexões e aumentá-lo ao receber dados.
Dessa forma, o rwnd inicial, teoricamente, poderia ser anunciado tão grande quanto todo o buffer. O remetente enviará essa quantidade de dados. O buffer do receptor será preenchido, o receptor diminuirá o ganho e aumentará a parte do buffer do aplicativo de acordo com tcp_adv_win_scale.
Então, como mencionado em@slmresposta - parece não haver razão para tocar em tcp_app_win.