tcpdump抓包看到的奇怪现象

[ryooyr]

nginx在8003端口侦听，用curl取一个http对象，抓包结果如下：
10.141.42.91.63290 > 10.56.233.101.8003: Flags [S], cksum 0xbeac (correct), seq 4241521062, win 64240, options [mss 1460,nop,wscale 0,nop,nop,sackOK], length 0
10.56.233.101.8003 > 10.141.42.91.63290: Flags [S.], cksum 0x6b16 (correct), seq 2724284609, ack 4241521063, win 17920, options [mss 8960,nop,nop,sackOK,nop,wscale 7], length 0
10.141.42.91.63290 > 10.56.233.101.8003: Flags [.], cksum 0x1444 (correct), seq 1, ack 1, win 64240, length 0
10.141.42.91.63290 > 10.56.233.101.8003: Flags [P.], cksum 0x9f01 (correct), seq 1:190, ack 1, win 64240, length 189
10.56.233.101.8003 > 10.141.42.91.63290: Flags [.], cksum 0x0de3 (correct), seq 1, ack 190, win 149, length 0
10.56.233.101.8003 > 10.141.42.91.63290: Flags [.], cksum 0x61a8 (incorrect -> 0x6c0b), seq 1:14601, ack 190, win 149, length 14600
10.141.42.91.63290 > 10.56.233.101.8003: Flags [.], cksum 0x081f (correct), seq 190, ack 2921, win 64240, length 0
10.141.42.91.63290 > 10.56.233.101.8003: Flags [.], cksum 0xfcb6 (correct), seq 190, ack 5841, win 64240, length 0
10.56.233.101.8003 > 10.141.42.91.63290: Flags [.], cksum 0x4ad8 (incorrect -> 0x795, seq 14601:23361, ack 190, win 149, length 8760
10.141.42.91.63290 > 10.56.233.101.8003: Flags [.], cksum 0xf14e (correct), seq 190, ack 8761, win 64240, length 0
10.141.42.91.63290 > 10.56.233.101.8003: Flags [.], cksum 0xe5e6 (correct), seq 190, ack 11681, win 64240, length 0
....
在建立连接时，curl端的tcp已经声明了mss为1460，为何红色那行会一下子发14600个字节过去？另外，根据tcp的慢启动协议，应该是nginx端的tcp先发一个1460字节的segment过去，收到ack了，再发两个segment，即2920字节过去才对，怎么会在没收到curl端tcp的ack回复情况下，一口气发送14600个字节呢？请高手指教，在线等，谢谢！

[Wenxy1]

10.141.42.91.63290 > 10.56.233.101.8003: Flags [P.], cksum 0x9f01 (correct), seq 1:190, ack 1, win 64240, length 189 没有问题。

[ryooyr]

这个 win 64240只是接收端用来控制tcp receive buffer溢出的advertised window，发送端还有一个用来避免网络拥塞的congestion window，根据tcp的slow start算法，congestion window最初是一个mss大小，随着收到的ack个数的增加而增长，但在这个抓包结果里面，congestion window似乎没起作用

[再改变]

慢启动时，发送发取拥塞窗口（cwnd）和通告窗口（mss）中的最小值为发送上限，故lz的疑惑确实存在。 会不会不是慢启动的方式，上来就直接发多个报文段。