tcp传输速率优化分析

1， 简要说明

对于TCP传输，出口带宽和网络带宽都很高，传输速率就比如很大吗？

答案是：不一定。

考虑这样一种场景：有一个主播在美国推流，国内用户观看直播，拉流速率很小，视频非常卡顿。分析发现，带宽其实并不小，只是延时比较大（大于300ms）。

所以说速率跟延时相关，延时大会导致速率变下。

2，速率跟延时的关系推导

由于TCP的滑动窗口特性，已发送出去的一组数据必须ACK之后（经过一个RTT)，滑动窗口才会滑动，才可以发送下一组数据，一组数据大小为SWND ，1S之内可以发送1000/RTT组数据，于是速度为：

Rate = SWND*8*1000 / RTT

所以速率跟发送窗口成正比，跟RTT成反比；

其中：SWND(发送窗口) = min｛RWND(接收窗口), CWND(拥塞窗口)｝；RTT：往返延时

还有一个问题：跟进上面推到公式，如果RTT无线接近0那速率就无限大了吗？显然不会，但RTT小于某个值的时候，整个链路的速率就受限于带宽了。

3，测试验证

因为RTT是相对固定的，没法更改；那只能通过增大SWND来增加速率。

可以通过两种方式来增大SWND，来增加速率：

1）增大接收方接收缓存；

2）使用多连接传输；（单连接因为SWND相对比较小往往很难吃满带宽，通过增加连接数，每条连接都占用带宽来增加总的速度）

增大接收缓存效果分析

验证方案：

具体流程是： 1） client发起拉取文件请求到proxy client； 2） Proxy client把请求转发到proxy server 3） Proxy server转发请求到server； 4） server读取测试文件内容，并发送到proxy server； 5） Proxy server把TCP包转包到proxy client； 6） Proxy client把TCP包转包到client； 7） client把收到的内容写文件；

环境信息：

client 和 proxy client部署在同一台机器，位于东京；

server 和 proxy server部署在同一台机器，位于休斯敦；

东京和休斯敦的机器之间延时为：135ms左右；通过tc命令，增加200ms延时，使东京和休斯敦机器之间的延时为350ms左右。

tc qdisc add dev eth1 root netem delay 200ms

拉取的测试文件50M；通过比较修改proxy client的接收缓存大小来验证：接收缓存跟速率之间的关系情况。

通过修改linux内核参数来调整接收缓存大小，修改办法如下：

通过使用sysctl命令修改net.ipv4.tcp_rmem的第三个值。

下面是具体的测试结果情况（每种场景测试三次）：

1），接收缓存为：2194304

第一次测试：

拉取文件大小：52059880 bytes；

耗时：18369 ms;

速率：2834116.17Byte/s；

第二次测试：

拉取文件大小：52059880 bytes；

耗时：18282 ms;

速率：2847603.11Byte/s；

第三次测试：

拉取文件大小：52059880 bytes；

耗时：18381 ms;

速率：2832265.93Byte/s；

2），接收缓存为：4194304

第一次测试：

拉取文件大小：52059880 bytes；

耗时：10848 ms;

速率：4799030.24Byte/s；

第二次测试：

拉取文件大小：52059880 bytes；

耗时：10794 ms;

速率：4823038.73Byte/s；

第三次测试：

拉取文件大小：52059880 bytes；

耗时：11120 ms;

速率：4681643.88Byte/s；

3），接收缓存为：6194304

第一次测试：

拉取文件大小：52059880 bytes；

耗时：8455 ms;

速率：6157289.18Byte/s；

第二次测试：

拉取文件大小：52059880 bytes；

耗时：8452 ms;

速率：6159474.68Byte/s；

第三次测试：

拉取文件大小：52059880 bytes；

耗时：8426 ms;

速率：6178480.89Byte/s；

4），接收缓存为：16388608

第一次测试：

拉取文件大小：52059880 bytes；

耗时：3469 ms;

速率：15007172.10Byte/s；

第二次测试：

拉取文件大小：52059880 bytes；

耗时：3468 ms;

速率：15011499.42Byte/s；

第三次测试：

拉取文件大小：52059880 bytes；

耗时：3800 ms;

速率：13699968.42Byte/s；

5），接收缓存为：32388608

第一次测试：

拉取文件大小：52059880 bytes；

耗时：2451 ms;

速率：21240261.12Byte/s；

第二次测试：

拉取文件大小：52059880 bytes；

耗时：2451 ms;

速率：21240261.12Byte/s；

第三次测试：

拉取文件大小：52059880 bytes；

耗时：2057 ms;

速率：25308643.66Byte/s；

6），接收缓存为：323886080

第一次测试：

拉取文件大小：52059880 bytes；

耗时：2074 ms;

速率：25101195.76Byte/s；

第二次测试：

拉取文件大小：52059880 bytes；

耗时：2444 ms;

速率：21301096.56Byte/s；

第三次测试：

拉取文件大小：52059880 bytes；

耗时：2778 ms;

速率：18740057.60Byte/s；

使用多连接传输

验证方案：

具体流程是： 1） client发起拉取文件请求到proxy client； 2） Proxy client把请求转发到proxy server(选择一个连接) 3） Proxy server转发请求到server； 4） server读取测试文件内容，并发送到proxy server； 5） Proxy server把TCP包使用多个连接转包到proxy client； 6） Proxy client收到TCP包,并按顺序进行组包,并发送到client； 7） client把收到的内容写文件；

1）环境信息：

client 和 proxy client部署在同一台机器，位于休斯敦；

server 和 proxy server部署在同一台机器，位于休斯敦；

2台休斯敦的机器之间延时为：0.1ms左右；通过tc命令，增加300ms延时，使它们之间的延时为300ms左右。

tc qdisc add dev eth1 root netem delay 300ms

拉取的测试文件大小为：52059880 bytes；

Proxy server 到proxy client之间的连接数可以通过配置文件修改。

下面是具体的测试结果情况（每种场景测试三次）：

1)，1个连接

第一次测试：

拉取文件大小：52059880 bytes；

耗时：7289 ms;

速率：7142252.71Byte/s；

第二次测试：

拉取文件大小：52059880 bytes；

耗时：7293 ms;

速率：7138335.39Byte/s；

第三次测试：

拉取文件大小：52059880 bytes；

耗时：7289 ms;

速率：7142252.71Byte/s；

2)，5个连接

第一次测试：

拉取文件大小：52059880 bytes；

耗时：5137 ms;

速率：10134296.28Byte/s；

第二次测试：

拉取文件大小：52059880 bytes；

耗时：5136 ms;

速率：10136269.47Byte/s；

第三次测试：

拉取文件大小：52059880 bytes；

耗时：5124 ms;

速率：10160007.81Byte/s；

3)，10个连接

第一次测试：

拉取文件大小：52059880 bytes；

耗时：3697 ms;

速率：14081655.40Byte/s；

第二次测试：

拉取文件大小：52059880 bytes；

耗时：3979 ms;

速率：13083659.21Byte/s；

第三次测试：

拉取文件大小：52059880 bytes；

耗时：3698 ms;

速率：14077847.49Byte/s；

4，测试结论：

1，在其他条件不变的情况下，可以通过增大接收缓存的大小，来增加速率；

2，速率增加的比例 和 接收缓存的比例 并不是严格线性的；速率增加的比例稍小于线性比例值；

3，并不是说，可以无限增加接收缓存，来无限提高速率。当接收缓存大于某个阀值时，速率就不增加了。

4，多连接是有效果的，使用多连接可以增加速率40%左右；

5，并不是连接数越多越好。因为每个连接变差，会导致整个传输变差，连接多了，出现某个连接差的情况概率就高了。测试过40个连接的情况，效果比单连接还差。

6，建议多连接为5左右，不要大于10；