Linuxスロースタート：IPルートを変更しても初期ウィンドウに影響がない

以下のように、マシンのtcp初期ウィンドウを10に変更しました

[user@site etc]$ sudo ip route change default via 17.255.209.1 dev eth0  proto static initcwnd 10 

そしてtcp_slow_start_after_idle以下のように変更

[user@site etc]$ sudo sysctl -a | grep tcp_slow_start_after_idle
net.ipv4.tcp_slow_start_after_idle = 0

IPルートショーの確認は以下に与えられています

[user@site etc]$ ip route show
default via 17.255.209.1 dev eth0  proto static  initcwnd 10
169.254.0.0/16 dev eth0  scope link  metric 1002
17.255.209.0/24 dev eth0  proto kernel  scope link  src 17.255.209.19

Webサイトでtcpdumpを実行しても、WIN / MSSがデフォルトで4のままになっている初期ウィンドウに変更が表示されないようです。5840/1460 = 4

[user@site etc]$ sudo tcpdump -n -i any 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn and port 80'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
11:17:45.048174 IP 21.101.151.198.45873 > 17.255.209.19.http: Flags [S], seq 2008673341, win 5840, options [mss 1460,sackOK,TS val 1724223146 ecr 0,nop,wscale 6], length 0

私がWebページに対して行ったカールヒットは、約30 KBのデータを要求しました。

[user@machine ~]$ curl http://www.site.com/js/main.js > /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 88212  100 88212    0     0   179k      0 --:--:-- --:--:-- --:--:--  272k

私のアプローチの何が悪いのでしょうか？

カーネル

[user~]$ uname -r
3.0.4x86_64-linode21

更新として、google.comを試した結果は次のとおりです

[user@site ~]$ sudo tcpdump -n -i any 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn and host www.google.com'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
17:20:28.033236 IP 17.255.209.19.42799 > 74.125.127.106.http: Flags [S], seq 3148947324, win 14600, options [mss 1460,sackOK,TS val 193695310 ecr 0,nop,wscale 4], length 0

ご覧のとおり、この場合、WIN / MSSは14600/1460 = 10です。

サーバーマシン自体からcurlを介して自分のサイトにアクセスしてみました。結果は次のとおりです。

[user@site ~]$ sudo tcpdump -n -i any 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn and host www.site.com'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
17:25:14.584338 IP 17.255.209.19.35008 > 17.255.209.19.http: Flags [S], seq 3894567470, win 32792, options [mss 16396,sackOK,TS val 193981861 ecr 0,nop,wscale 4], length 0

この場合、WIN / MSSは32792/16396 = 2です。

TCPのしくみを誤解していると思います。

各パケットて送信を常に見、受信ウィンドウ（別名。RWIN）と、オプションのスケーリング係数をアドバタイズしますRFC 1323

送信者は、RWINで指定された量を超えるデータを、確認なしに送信することはできません。輻輳ウィンドウに応じて、送信者はRWINをいっぱいにするかどうかを決定できます。

したがって、TCPパケットで公開される2ビットの情報があります。サーバー上のRWINとクライアント上のRWIN。これらの数値の両方は、輻輳ウィンドウの最大サイズが両端で何であることができるかを決定します。

サーバー上のRWINは、たとえばファイルのアップロードのパフォーマンスを最適化しようとしているときに興味深いものです。

クライアント上のRWINは、ダウンロード速度を決定しようとするときに興味深いものです。

これらの数値のどちらも、もう一方の端の輻輳ウィンドウを公開しません。

私は64KのRWINを持っている場合はSO、サーバー上の輻輳ウィンドウをすることができANY 64kのより低い数。

実際の輻輳ウィンドウを判別する唯一の方法は、パケットをカウントすることです。

私が知っている場合：

1. 私の往復時間（RTT）は〜200msです。
2. 100kのリソースをリクエストしました。
3. 私は64kのRWINを持っています。

200ms以内に1452バイト長の2つのパケットがサーバーから返された場合、サーバーの輻輳ウィンドウが4356よりも小さい可能性があります。これが大きければ、3つのパケットが送信されます。IWが10に設定されている場合、200msマーク付近で10パケットのバーストが発生します。

IWを変更し、変更が機能したことを確認したい場合は、パケットをカウントして、サーバーの輻輳ウィンドウサイズの見積もりを取得する必要があります。

おそらく、SYN、SYN-ACK、ACKの直後に会話を確認して、会話の途中（輻輳ウィンドウがすでに拡大している可能性がある場所）を確認していないことを確認してください。

ウィンドウサイズは、サーバー初期ウィンドウサイズまたはクライアントRWINのいずれか小さい方になります。5840はLinux 2.6のデフォルトのRWINであるため、クライアントがここでの制限要因のようです。

Windowsボックスからお試しください。Windows XPのRWINは64k、新しいバージョンは8kです。

出典：http : //www.cdnplanet.com/blog/tune-tcp-initcwnd-for-optimum-performance/（興味深い部分はビデオの下にあります）

編集：より明確にするために答えを拡張します：

• TCPハンドシェイクでは、クライアントはSYNパケットをサーバーに送信し、最大許容ウィンドウサイズを送信します。（tcpdump出力が示すように、これらは5840バイトです）
• サーバーはSYN ACKと応答するウィンドウサイズで応答します。このウィンドウサイズは、クライアントが提案したサイズよりも小さくすることはできず、大きくすることはできません。サーバーがどのように構成されていても、そのクライアントでは5840バイトよりも大きなウィンドウサイズにすることはできません。
• クライアントはACKを返し、その後も喜んでデータを交換します。

Edit2：質問に追加されたtcpdumpは、サーバーがgoogleへの接続を開いており、それ自体がクライアントとして機能していることを示しています。