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;

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏小白安全

批量检测SQL注入工具

0×01 前言 SQL注入,这个类型的漏洞我真的学了好久好久好久好久,即是我刚刚开始接触安全就学习的第一种漏洞,也是一个迄今为止还在学习的漏洞类型,只...

1.3K60
来自专栏开源优测

如何参与到开源优测-积微速成计划任务

通过过完第一次任务,你应该掌握: 安装和部署git 学会git基本的命令 学会如何使用github来管理的你的学习任务 初步了解如何利用python编程 本...

31060
来自专栏月色的自留地

为OPENCV添加freetype支持并显示中文字符(在mac上编译opencv及contrib库)

  在mac电脑上管理这些gnu的库一般都使用Homebrew,但总有一些你个性化的需要是官方的Homebrew配方无法满足的。比如在屏幕的输出中使用中文字...

55010
来自专栏深度学习自然语言处理

这些进程的后台可靠运行命令你都知道了吗

当用户注销(logout)或者网络断开时,终端会收到 HUP(hangup)信号从而关闭其所有子进程。因此,我们的解决办法就有两种途径:要么让进程忽略 HUP ...

8310
来自专栏嵌入式程序猿

三张图看懂MQX下多任务的调试

在基于MQX RTOS的应用软件开发中,我们经常会遇到多任务的创建和调试,今天我们就来看看多任务的调试。 在IAR环境下,基于MQX操作系统的多任务调试其实还是...

31660
来自专栏Java技术栈

浅析负载均衡的6种算法,Ngnix的5种算法。

常见的几种负载均衡算法 ? 1、轮询法 将请求按顺序轮流地分配到后端服务器上,它均衡地对待后端的每一台服务器,而不关心服务器实际的连接数和当前的系统负载。 2、...

349120
来自专栏ericzli

Jetson TX1上安装Tensorflow Serving遇到的问题总结

本文的目的是分享在TX1上安装Tensorflow Serving时遇到的主要问题,避免重复踩坑。

41640
来自专栏自然语言处理

目标检测第1步-运行tensorflow官方示例

2 运行环境:python3.6、Windows10、tensorflow_gpu1.10

16820
来自专栏深度学习那些事儿

深度学习必备:通过VNC连接ubuntu(linux)工作站

此篇讲解如果通过VNC实现win10电脑操控(ubuntu)linux电脑,只需一个键盘一个鼠标就可以操控两个电脑,实现高效率工作。

75250
来自专栏点滴积累

geotrellis使用(十八)导入多波段Tiff、读取多波段Tile

Geotrellis系列文章链接地址http://www.cnblogs.com/shoufengwei/p/5619419.html 目录 前言 多波段数...

43650

扫码关注云+社区

领取腾讯云代金券