最近、nettyを使用して一連のプロキシサービスを作成しましたが、ネットワーク速度が非常に遅く、ダウンロードが約200kであり、プロキシサーバーの実際のネットワーク速度が約100Mbit / sであることがわかりました。長い間探していたところ、ようやく理由がわかりました。netty tcpパラメータSO_SNDBUFおよびSO_RCVBUFの設定が小さすぎることが判明しました（以前は32Kでしたが、現在は2Mに設定されているため、ネットワーク速度は通常に戻ります）。
ソースアドレス（CDNをサポート、スターを要求）：https： //github.com/zhining-lu/netty-websocket-proxy
意味
- SO_SNDBUF：TCP送信バッファ容量の上限;
- SO_RCVBUF：TCP受信バッファの容量の上限。
注：バッファの上限を無限にすることはできません。カーネルによって設定された上限を超える場合は、カーネル設定値が優先されます（sysctl -aコマンドで確認してください）。
net.ipv4.tcp_rmem = 8192 87380 16777216
net.ipv4.tcp_wmem = 8192 65536 16777216
net.ipv4.tcp_mem = 8388608 12582912 16777216実際のメモリ使用量とはどのような関係がありますか？
- SO_SNDBUFおよびSO_RCVBUFは、読み取りおよび書き込みバッファサイズの上限のみを指定します。実際の使用が上限に達する前は、SO_SNDBUFおよびSO_RCVBUFは機能しません。
- TCP接続が占有するメモリは、読み取りバッファと書き込みバッファが占有する実際のメモリの合計に相当します。
スライディングウィンドウとの関係は？
受信バッファ領域と受信スライディングウィンドウの関係
受信バッファ領域にはスライディングウィンドウが含まれます。つまり、受信バッファ領域のサイズ> =スライディングウィンドウのサイズです。受信バッファ内のデータは、主に2つの部分に分けられます。
- スライディングウィンドウで順不同のTCPパケットを受け入れます。
- 整然と、アプリケーションによって読み取られていないデータ（占有率：1 /（2 ^ tcp_adv_win_scale）、デフォルトのtcp_adv_win_scale構成は2）。
したがって、受信バッファの上限が固定されている場合、アプリケーションプログラムによるデータの読み取りが遅すぎると、受信スライディングウィンドウが小さくなり、接続側に通知して送信速度を下げ、不要なネットワーク送信を回避します。
送信バッファと送信スライディングウィンドウの関係
送信バッファ領域には、送信スライディングウィンドウが含まれます。つまり、送信バッファ領域> =送信スライディングウィンドウのサイズです。送信バッファ内のデータは、主に2つの部分に分けられます。
- 送信ウィンドウのデータ：送信されたがまだ確認されていないデータ。
- アプリケーションによって書き込まれたデータ。
バッファサイズの見積もり
####最大受信ウィンドウサイズの推定
一般に、BDPは最大受信ウィンドウを設定するために使用されます。BDPは帯域幅遅延積と呼ばれ、帯域幅とネットワーク遅延の積です。BDPはネットワーク負荷容量を表すため、最大受信ウィンドウは、ネットワーク負荷容量内で確認なしに送信できるパケットを表します。以下に示すように：
####受信バッファのサイズを
計算する受信ウィンドウサイズの比率1-1 /（2 ^ tcp_adv_win_scale）;に従って、バッファサイズの上限を計算します。
例：たとえば、帯域幅が2Gbpsで遅延が10msの場合、帯域幅遅延積BDPは2G / 8 * 0.01 = 2.5MBであるため、tcp_adv_win_scaleの場合、このようなネットワークでは最大受信ウィンドウを2.5MBに設定できます。 = 2最大読み取りキャッシュを4/3 * 2.5MB = 3.3MBに設定できる場合。