tcpdump抓包看到的奇怪现象

gta

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个字节呢？请高手指教，在线等，谢谢！

gta

up up up up up up up up up

csumck

红色这行好像不是P包啊，这个长度是应用层数据的长度？

gta

从seq 1:14601来看，应该是携带了数据的，但flag里头又没有psh，非常费解

flw2

linux 3.0之前是3，也不是1，后面google认为10比较合理，对整个internet。
linux采纳了

https://developers.google.com/sp ... _initcwnd_paper.pdf

gta

豁然开朗，多谢多谢