Linuxで変数tcp_adv_win_scale
と 変数が共存する理由がわかりません。tcp_app_wintcp(7)言う：
のためにtcp_adv_win_scale：
tcp_adv_win_scale(整数; デフォルト: 2; Linux 2.4 以降)
バッファリングオーバーヘッドを次のようにカウントする
bytes/2^tcp_adv_win_scale、 もしtcp_adv_win_scale0より大きい、またはbytes-bytes/2^(-tcp_adv_win_scale)、 もしtcp_adv_win_scaleゼロ以下です。ソケット受信バッファスペースは、アプリケーションとカーネルの間で共有されます。TCP はバッファの一部を TCP ウィンドウとして保持します。これは、相手側に通知される受信ウィンドウのサイズです。残りのスペースは「アプリケーション」バッファとして使用され、ネットワークをスケジューリングやアプリケーションの遅延から分離するために使用されます。
tcp_adv_win_scaleデフォルト値 2 は、アプリケーション バッファーに使用されるスペースが合計の 4 分の 1 であることを意味します。
そしてtcp_app_win：
tcp_app_win(整数; デフォルト: 31; Linux 2.4 以降)この変数は、バッファリング オーバーヘッド用に予約される TCP ウィンドウのバイト数を定義します。
最大（
window/2^tcp_app_winウィンドウ内の 1000 バイト (1000 バイト、mss) はアプリケーション バッファー用に予約されます。値が 0 の場合、予約される量はありません。
したがって、正確に何が変更されるのかよくわかりませんtcp_app_win。両方の変数を使用して TCP アプリケーション バッファを微調整できるため、両方を同時に変更する必要はないように思われます。私の考えは正しいでしょうか?
答え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 ミリ秒 RTT) の場合、最大パフォーマンスは 65536/0.150 = 436906 バイト/秒、つまり約 400 キロバイト/秒となり、これは現在では非常に遅い値です。
デフォルト サイズを増やすと、(873800 - 873800/2^2)/0.150 = 4369000 バイト/秒、つまり約 4M バイト/秒となり、これは現代のネットワークでは妥当な値です。また、これはデフォルトであり、送信側がより大きなウィンドウ サイズで構成されている場合は、この 10 倍 (8738000*0.75/0.150 = 約 40M バイト/秒) まで問題なく拡張されることに注意してください。これは現代のネットワークではかなり良い値です。
2.6.17 以降では、妥当なデフォルト値が設定されており、反対側がサポートしている場合は、実際にウィンドウ サイズを最大許容値まで調整します。そのため、それ以降はこのガイドのほとんどは必要ありません。ただし、長距離スループットを良好にするには、最大値を増やす必要がある場合があります。
私はそれを理解できましたが、これら 2 つの変数の間に関係があるかどうかは、よくわかりませんでした。
それが何を説明しようとしていたのか、私はほとんど理解できませんでした。本質的には、バッファリング スペースの量を調整するこのパラメーターは、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 に設定されています。つまり、アプリケーション バッファーは tcp_rmem 変数で指定された合計バッファー スペースの 1/4 になります。
3.3.3. tcp_app_win
この変数は、特定の TCP ウィンドウが転送される TCP ソケット メモリ バッファー内の特定の TCP ウィンドウ用に予約するバイト数をカーネルに指示します。この値は、次の式のように、予約するバッファー領域の量を指定する計算に使用されます。
上記の計算からわかるように、この値が大きくなるほど、特定のウィンドウのバッファ スペースは小さくなります。この計算の唯一の例外は 0 で、これはカーネルにこの特定の接続にスペースを予約しないように指示します。この変数のデフォルト値は 31 で、一般的には適切な値です。何をしているのかわからない場合は、この値を変更しないでください。
これらの説明に基づくと、最初のパラメータは、tcp_adv_win_scaleTCP ウィンドウの使用とアプリケーション バッファ用にソケット バッファ スペースを分割する方法を制御しているようです。
一方、2 番目のパラメータは、tcp_app_win説明に記載されているアプリケーション バッファ用に予約するバイト数を指定しますtcp_adv_win_scale。
答え2
カーネルソースから得た知見は次のとおりです。
- tcp_adv_win_scaleはマクロで使用されますinclude/net/tcp.h の tcp_win_from_spaceこのマクロは、net/ipv4/tcp_input.c の関数 tcp_grow_window
確立された接続にのみ使用され、接続時には使用されないようです。この
パラメータのデフォルト値は 1 で、アプリケーションの rcv バッファの 50% になります。 - tcp_app_winは以下で使用されますnet/ipv4/tcp_input.c の関数 tcp_init_buffer_space。
これは接続時にのみ使用され、確立された接続には使用されないようです。
このパラメータのデフォルト値は 31 で、アプリケーションの rcv バッファは 0.0% になります。
このロジックは、新しい接続でアプリケーション用のバッファを予約せず、データを受信したときにバッファを増やすというものではないと思います。
そのようにすると、理論的には、初期rwndはバッファ全体と同じ大きさでアドバタイズできます。送信者はその量のデータを送信します。受信バッファがいっぱいになると、受信側はwinを縮小し、tcp_adv_win_scaleに従ってバッファのアプリケーション部分を増やします。
したがって、スラム回答 - tcp_app_win に触れる理由はないようです。