Chinaunix首页 | 论坛 | 博客
  • 博客访问: 380523
  • 博文数量: 124
  • 博客积分: 30
  • 博客等级: 民兵
  • 技术积分: 11
  • 用 户 组: 普通用户
  • 注册时间: 2011-08-29 22:22
文章分类

全部博文(124)

文章存档

2016年(8)

2015年(52)

2014年(53)

2013年(11)

分类: LINUX

2014-09-29 17:41:31

        憨厚老实的tcp协议

已不记得多少次玩游戏时,被隔壁loser下毛片卡掉线

已不记得多少次浏览网页时,被隔壁sb下毛片卡得动弹不了

为什么带宽总是被P2P下载抢光呢?

是因为P2P太流氓了吗?


有句老话说得好,人背不能归社会。与其抱怨P2P协议太流氓,不如说tcp协议太憨厚老实了。

tcp协议的拥塞控制算法,会根据丢包、重传、延时等现象,判断当前网络状态。当网络状况不好时,tcp协议会自动降低传输速率,以降低网络压力,避免网络因过重的压力而崩溃。

P2P拼命抢带宽时,tcp协议却不停的降低自己的速度,结果就是带宽被P2P吃完而tcp的速度接近于0


        贪婪TCP协议

tcp拥塞控制,是针对PCà服务器的整条线路进行流量控制。保护的是“整条互联网线路”。

这是一个舍己为人的“君子”协议在带宽大而且p2p不是很泛滥的国家(除中国外的全世界),tcp能让大家都过上网络通畅的好日子。

但是在中国,“流氓”软件越来越多。各种P2P下载工具、视屏插件疯狂抢带宽使得TCP拥塞控制变得越来越不合时宜。

我们需要对TCP协议的拥塞控制做一次革命!!!


我们真的需要拥塞控制吗?

需要的,但不是针对“整条互联网线路”,而是仅仅针对我们的出口带宽做拥塞控制。

假如我的出口带宽只有10MB,那么我们的拥塞控制就应该针对10MB来做,正好占满这10MB带宽。至于电信小区出口带宽不够了,电信移动间连接节点带宽不够了,这些位置的拥塞都和我们没关系。

P2P只管自己死活,我们的tcp也必须以同样的策略对抗才能保证用户正常上网。这就是我们的贪婪TCP协议:仅针对自身的网络出口带宽进行拥塞控制。


        说来容易实现难

tcp协议中的拥塞控制是由发送方控制的,也就是说,当我们用PC浏览网页时,PC只能控制自己上传数据的速率,无法控制服务器发送数据的速率。

所以贪婪tcp协议主要是做在服务器端的。通过在服务器端采用贪婪tcp协议来提高用户访问网站/玩游戏的流畅度。

很多大公司都会采用“把拥塞控制初始窗口改大几十倍”的办法来达到提高拥塞窗口的效果。不过我们作为一家自己写内核的公司,顺手做一个贪婪tcp协议能达到更好的效果。


在实现贪婪tcp协议时主要涉及到几个技术点:

出口带宽的监控和各个连接间的速率分配

我们是通过流量控制模块来实现的(因为之前已经有流控了,这样做成本最小),将各个tcp连接的数据包接入流控管理队列,流控管理队列根据当前出口带宽情况控制选择合适的数据包通过网卡发送出去;然后再将积压未发送的数据长度反馈给各个tcp连接,减小tcp发送速率。


一个更高性能的实现方案是:各个tcp连接将自己的发送状态反馈到一个per-cpu流量管理中心,per-cpu流量管理中心为tcp连接分配当前时间周期能发送的数据量;各个per-cpu的流量管理中心则隔几十毫秒同步一次数据。


流量控制窗口

tcp协议中,接收方可以通过流量控制窗口来限制发送方的发送速率。

一般来说,当接收方的接收缓冲区不够时,就会通过tcp流量控制窗口来限制发送方的发送速率。

正常情况下,这种限制是很少发生的。但是为了保险起见,我们需要对tcp流量控制窗口进行支持。


别真的发的太快了

因为我们只考虑了服务器端出口带宽,没有考虑客户端的出口带宽。如果真的拼命发到1GB/s的数据,有可能把PC用户的出口带宽冲垮。

因为我们只是用贪婪tcp协议来支持游戏、网页浏览这种耗流量较小的服务器,很少会碰到一次发送数据超过1MB的情况,所以基本不会碰到“发的太快”的情况。


如果要支持大文件传输,则必须对客户端出口带宽进行预测。我们可以假定客户端的网络带宽在若干小时内一般是固定的。然后计算当我们提高/降低速率时丢包率的变化。

例如当我们以10KB/s传输数据时,丢包率就已经达到了20%100KB/s时丢包率仅仅升高为23%,就可以认为丢包主要不是由我们引起的,可以进一步提高发送速率,提高我们抢带宽的能力。

阅读(1252) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~