ネットワークを介して大量のデータを転送するときに断続的にネットワークの問題が発生したが、誰かがこのオプションを1に設定すると問題を解決できることが示唆されました。
文書によると：
tcp_workaround_signed_windows (Boolean; default: disabled; since Linux
2.6.26)
If enabled, assume that no receipt of a window-scaling option
means that the remote TCP is broken and treats the window as a
signed quantity. If disabled, assume that the remote TCP is not
broken even if we do not receive a window scaling option from
it.
TCPを知っている人なら、このパラメータの役割が正確に何であるかを明確に知ることができますか？ウィンドウのサイズ変更が何であるか、「ウィンドウのサイズ変更オプションを受け取っていないと仮定すると、リモートTCPが破損していることを意味する」ことがこの状況でどのように大きく役立つのかわかりません。
また、私が経験している問題が何であるかを正確に絞り込んでいないことにも言及する必要があります。この問題は断続的に発生し、データ転送が予期せず中断されます（Wiresharkは、2台のコンピュータ間のパケット転送が遅れることを示しています）。他にもいくつかの項目があり、この値を設定すると役に立つようです。
ありがとう
答え1
TCPでは、ウィンドウサイズは、受信者が現在受信できるデータバイト数を示す16ビット符号なしフィールドです。
与えられた時間に64 KBのデータしか転送できないため、16ビットでは不十分であることがわかりました。これがウィンドウのサイズ変更オプションが導入された理由です。ウィンドウのサイズ変更を使用すると、フィールドはまだ16ビットにすぎませんが、シングルバイトを計算する代わりに、一度に2、4、8、...、または16384バイトを計算できます。
ウィンドウのサイズ変更がどのように機能するかについての正確な詳細は、あなたの質問と特に関係がありません。引用した説明によると、このtcp_workaround_signed_windowsオプションはウィンドウのサイズ変更が使用されていない場合にのみ適用されます。
このオプションがウィンドウのサイズ変更が無効になっている場合にのみ適用されるのは、ウィンドウのサイズ変更をサポートしていない古いシステムでのみ発生するバグの回避策です。
間違い
参照は、ウィンドウサイズフィールドを符号付き値として扱うバグを持つ受信機を指します。これは、最大32 KBのすべての値に対してうまく機能しますが、32 KBを超える値が負の数として誤って解釈されることを意味します。
その結果、このエラーのあるピアに現在48KB以上のデータを受信するメモリがあると言うと、ピアはこれを-16KBと誤って解釈し、次の1.4KBがはっきりと勝ちたいので、より多くのデータ転送を中断します。そうではありません。 （または、正の値でなければならないフィールドで負の値を見つけると、それよりも愚かなことができます。）
このエラーが発生すると、非常に古いソフトウェアを実行している特定のコンピュータと通信するときに何らかの理由なくデータ転送が停止することがわかります。
この問題は、32KBを超えるウィンドウサイズを送信しないことで解決できます。その説明で設定がそうなることを願っています。
設定は何をしますか？
利用可能なウィンドウサイズを64 KBから32 KBに縮小すると、このエラーが発生したTCP実装と通信するときに接続の中断を回避できます。
しかし、ここには費用がかかります。転送速度がウィンドウサイズによって制限されている場合、ウィンドウサイズを半分にすると、転送速度も半分になります。したがって、もともと予想される速度よりも遅く実行された送信は、最終的に半分の速度で実行される可能性がある。
これがこの回避策が永久に有効にならない理由です。
ウィンドウのサイズ変更を使用しない場合にのみ問題を解決するのはなぜですか？
このエラーとウィンドウのサイズ変更の間には直接的な関連付けはありません。したがって、ウィンドウのサイズ変更を考慮する唯一の理由は、それが特定のバグのある実装を検出するための最もよく知られている経験的な方法であると思います。
誰かがウィンドウのサイズ変更を実装する前に、このようなバグが修正される可能性があるように聞こえます。結局のところ、より大きなウィンドウが必要な場合、ウィンドウのサイズを実際のサイズの半分に制限するバグを修正しないのは愚かです。
答え2
ウィンドウのズーム受信バッファのサイズを元の許容サイズより大きく拡張できるようにTCPで設定できるオプション。このオプションがどのように役立つかわかりません。実装にバグがある場合は、この方法で設定するか、他の方法でバグを避けることができると思いましたが、現実的にTCPはどちらでも機能する必要があります（場合によっては必要なものより少し長くなることがあります。もっと頻繁に確認してください）。