某CDN公司在tcp上都做了啥？

首先，我申明一下俺不是这个据说有韩国背景的CDN公司的（好吧，我现在可以公开，就是同兴万点），所以分析他们的技术应该不存在法律问题。

本来是没有兴趣关心他们的，只是同事说他们服务效果很好，甚至比我们还好（后面证实这是个乌龙）。好吧，那就让我们看看他都做了啥。

note： 一下结果使用tcpdump抓的，ip我已经隐去了，只剩下端口
建立连接：

23:52:36.524988 IP 37043 > 80: S 3057031392:3057031392(0) win 5840
23:52:36.835004 IP 80 > 37043: S 4181496636:4181496636(0) ack 3057031393 win 64436 wscale 8>
23:52:36.835017 IP 37043 > 80: . ack 1 win 682
23:52:36.835050 IP 37043 > 80: P 1:156(155) ack 1 win 682
23:52:36.888571 IP 80 > 37043: S 4181496636:4181496636(0) ack 3057031393 win 64436
看上面带红色字体的这一行，算一算和第二行之间差了多少时间？ 没错，肯定不是3s。还有那个wscale 8，这也不是标准配置了。
继续往下看
23:52:37.143002 IP 80 > 37043: P 1:314(313) ack 156 win 5115
23:52:37.143006 IP 37043 > 80: . ack 314 win 680
23:52:37.143047 IP 80 >37043: . 314:1774(1460) ack 156 win 5115
23:52:37.143052 IP 37043 > 80: . ack 1774 win 668
23:52:37.143054 IP 80 > 37043: . 1774:3234(1460) ack 156 win 5115
23:52:37.143057 IP 37043 > 80: . ack 3234 win 657
23:52:37.143066 IP 80 > 37043: . 3234:4694(1460) ack 156 win 5115
23:52:37.143070 IP 37043 > 80: . ack 4694 win 645
23:52:37.442440 IP 80 > 37043: . 3234:4694(1460) ack 156 win 5115
23:52:37.442446 IP 37043 > 80: . ack 4694 win 645
注意一下那一行红色的，3234:4694 这个包是个重复包，是故意发的， 和上次收到的时间间隔差了300ms.
win 5115 *2的7次方，这个初始的接收窗口，也不是linux内核的标准了。
初始窗口是4，不是2

继续往下看，这一段抓包的记录好长，看官们要有点耐心。
23:52:37.449906 IP 80 > 37043: . 4694:6154(1460) ack 156 win 5115
23:52:37.449909 IP .37043 > .80: . ack 6154 win 634
23:52:37.450012 IP .80 > .37043: . 6154:7614(1460) ack 156 win 5115
23:52:37.450016 IP .37043 > .80: . ack 7614 win 623
23:52:37.450020 IP .80 > .37043: . 7614:9074(1460) ack 156 win 5115
23:52:37.450022 IP .37043 > .80: . ack 9074 win 611
23:52:37.450024 IP .80 > .37043: . 9074:10534(1460) ack 156 win 5115
23:52:37.450027 IP .80 > .37043: . 10534:11994(1460) ack 156 win 5115
23:52:37.450036 IP .37043 > .80: . ack 10534 win 600
23:52:37.450044 IP .37043 > .80: . ack 11994 win 588       
23:52:37.450130 IP 80 > .37043: . 13454:14914(1460) ack 156 win 5115                                     乱序丢包
23:52:37.450136 IP .37043 > .80: . ack 11994 win 588                第一个sack  第二个sack包是300ms后的事情
23:52:37.755710 IP .80 > .37043: . 14914:16374(1460) ack 156 win 5115
23:52:37.755715 IP .37043 > .80: . ack 11994 win 588
23:52:37.755744 IP .80 > .37043: . 16374:17834(1460) ack 156 win 5115
23:52:37.755748 IP .37043 > .80: . ack 11994 win 588
23:52:37.755811 IP .80 > .37043: . 17834:19294(1460) ack 156 win 5115
23:52:37.755815 IP .37043 > .80: . ack 11994 win 588
23:52:37.755876 IP .80 > .37043: . 19294:20754(1460) ack 156 win 5115
23:52:37.755880 IP .37043 > .80: . ack 11994 win 588
23:52:37.755939 IP .80 > .37043: . 20754:22214(1460) ack 156 win 5115
23:52:37.755943 IP .37043 > .80: . ack 11994 win 588
23:52:37.755945 IP .80 > .37043: . 22214:23674(1460) ack 156 win 5115
23:52:37.755947 IP .37043 > .80: . ack 11994 win 588
23:52:37.755951 IP .80 > .37043: . 23674:25134(1460) ack 156 win 5115
23:52:37.755953 IP .37043 > .80: . ack 11994 win 588
23:52:37.756000 IP .80 > .37043: . 25134:26594(1460) ack 156 win 5115
23:52:37.756003 IP .37043 > .80: . ack 11994 win 588
23:52:37.756004 IP .80 > .37043: . 26594:28054(1460) ack 156 win 5115
23:52:37.756006 IP .37043 > .80: . ack 11994 win 588
23:52:37.756008 IP .80 > .37043: . 28054:29514(1460) ack 156 win 5115
23:52:37.756010 IP .37043 > .80: . ack 11994 win 588
23:52:37.756093 IP .80 > .37043: . 29514:30974(1460) ack 156 win 5115
23:52:37.756097 IP .37043 > .80: . ack 11994 win 588
23:52:37.792829 IP 1.80 >.37043: . 11994:13454(1460) ack 156 win 5115     这是重传包  和第二个sack相差了只有几十ms，肯定不是被sack包触发的。
23:52:37.792836 IP .37043 > .80: . ack 30974 win 440

看完上面的注解以后，看我的结论， 重传不是被三个相同的ack触发的，而是在收到第一个sack以后的多少ms以后触发的，他们的时间和时延成正比关系。


最后做个总结：

初步来看他们做的改变有几个：

1  连接建立  ：第一个syn包重传时间更短，只有50ms 。 后续的是3s  6s  。。。。。。。

 

2更大的读缓存和初始读缓存  ；

3更大的初始拥塞窗口 4

 

4在300ms内收不到任何包的情况下， 用发送的最后一个数据包；

 

5完全颠覆了传统的丢包判断策略：  传统的方法是3个重复的ack包   ，他们的策略是第一个重复的ack包后 RTT/n 时间后就认为包丢包，然后重传；         

 

6拥塞控制算法：  初步来看，  AIMD算法 ，AI  加性增还是加1   ，MD 乘性减大致在0.7-0.8左右；