博客园_海阔天空

网络拥塞控制(十) 总结

2011-11-15T15:11:00Z

也是总结的时候了，写完了TCP的多个经典的拥塞算法，但是由于这方面的优化算法还有很多，没办法能够一一讲完，所以下面对其他的一些比较典型的也进行一个简单的介绍：

Fast TCP: Fast TCP由于后来没有对开源界做贡献了，因为作者本人自己创办了公司，把Fast TCP变成了商业产品，所以后续的学术研究就比较少了。Fast TCP是从TCP vegas的思想发展而来，利用网络延时进行拥塞判断。之前讨论过，基于延迟的算法是对整个网络的拥塞控制有好处的，但是和当前的基于丢包的算法来说两者不公平。所以估计作者后面也做了很多的改进。

ECN：显式拥塞通知，该算法的思想是想借助路由器，因为拥塞的状况中间的路由器是最清楚的，所以让路由器在发现有拥塞现象时在连接的TCP或者IP头里面打上拥塞的标记，让终端自己去根据标记进行处理。这种思想需要中间所有的路由设备均能支持才能在整个广域网上使用起来，所以推广起来不是那么容易的事情。目前Win7、Linux均都已支持ECN标记的处理。

UDT：UDT是一个开源的基于UDP实现的可靠传输协议，对于想知道如何去实现一个可靠的传输协议可以说值得参考。严格地来说UDT没有对TCP进行优化，不能算是一种TCP的优化，但是在UDT里面实现的拥塞算法是和UDP或TCP没有关系的，UDT采用的是一种带宽估计的算法，在利用包对进行带宽的探测，然后由接收方把估计的带宽反馈到发送端，发送端的拥塞算法就是把拥塞窗口利用一个函数无限逼近于带宽值，这种思想对于传输的稳定性非常好，因为是一个无限逼近，所以永远不会超过带宽的值，而不是像TCP一样在平衡状态后继续一直往上增大窗口，从而在平衡状态能够维持比较久。但是缺点也显而易见，带宽的估计不是特别的精确，尤其是在小带宽环境和有丢包的环境下误差有点大，当然我们需要明白作者开发UDT的需求不是为了小带宽和丢包环境的。

很多人都会有一个初步印象就是实现一个类TCP看上去都会是一件很容易的事，不就是加上连接机制，重传机制，定时器机制，序列化机制等就可以保证TCP能够工作了，download点开源的各种实现或者Linux内核，很快就可以改造出一个自己可用的版本出来。没错，一个可用的TCP实现确实就这样完成了，但是一个可用的版本和一个高性能版本的TCP实现那差别就远的很了。该系列的文章已经从TCP的发展进行了描述过逐步引发的一些问题，下面再列举一些问题来说明：

1. 对各种网络环境的适应能力。现在的各种网络环境都存在不一样的特征，例如有高达Gbps的网络需要超大的传输能力，家用ADSL的小带宽需要保持稳定吞吐能力，卫星网络/跨国网络有着很大的延时和一定的丢包率，3G存在异构的网络，跨运营商的网络有着很大的丢包率(主要是在中国的跨运营商之间)，等等，这些不同的网络环境对TCP算法的挑战性非常大。

2. 对不同应用的适应能力。有数据备份应用需要大量的文件传输，有对交互延时非常敏感的如RDP/Citrix/网游等应用，有一直只发送小包(发送的包长度小于MSS)的应用，也有不停的发送大包的应用，还有两边同时发送和接收数据的应用。而一旦实现的不好，就有可能对某些传输应用效果很好，但是对某种特殊的应用就很差，例如TCP的Nagle算法，ACK回复机制，如何控制突发性，重传算法等。曾经我就碰到过很多这种问题，因为多传输了一个包导致多回复了一个ACK，最终造成性能下降1/3，因为突发(尤其是重传时的突发)没有控制好导致500-600KB的带宽却也只能达到100KB的性能。

3. 对连接的友好型和抢占性。1条TCP连接是否能够有利用完整个带宽的能力，同时上万条连接并发是否有能够足够公平友好，从而充分利用带宽，而不是造成带宽的浪费？否则某些连接速度是快了，但是其他的连接速度就降下来了。同时抢占过重导致网络中延迟变大，从而交互性应用体验性非常不好。

上述这些问题，把TCP各种机制融合成为了一个整体，任何地方一个小小的改动可能会造成整体性能急剧的下降，测试的工作量也是一个非常复杂的工程。为了解决这些问题，对于TCP的优化的算法已经多达二十多种，包括公开的、私有的或者专利化的，在维基百科上都可以看到这些算法的列表。

要解决上述各种问题，已经不是简单的拥塞控制对拥塞窗口进行调整可以解决的，需要结合很多其他的方面的信息，例如：

1. 最重要的是要提高重传数据的准确度且尽快地重传已经丢失的包，这两者看上去本身有点矛盾，因为要尽快地重传就有可能造成误判，错误的重传反而浪费原本宝贵的带宽资源。我尝试过给在丢包环境下每个包都直接重传两遍，这样相当于非常早的进行了重传，但是效果却还不如判断后再重传。

2. 发送数据的平稳性，很多小带宽的网络不能突然间发送过多的数据包，否则很快就会把网络再次陷入拥塞，导致速度比小流量的稳定发送更慢，控制这个发送的突发性值得考虑。

3. 如何判断当前已经达到了最佳值，否则最佳值之后上涨过快可能又会导致网络进入拥塞从而降低吞吐，实际上BICTCP/CUBIC在稳定后的增长速度都是比较快的，否则就又没办法达到高BDP网络的吞吐，所以利用网络带宽估计是一个比较靠谱的反馈，也有不少论文涉及到此方法，实际使用如UDT。

本文链接

读书观影2

2011-01-16T05:48:00Z

本周看了电影三部，电影一般都是两个小时左右，比较容易完成，但是要认真的看完一本书，所花费的时间远远超过这个值。本周开始看两本书，在公司休息时间就看《围城》，钱钟书的《围城》的地位自然不必说，只是一直没有去看。在家里就看《华为的世界》，元旦时去顺德的同乡那里玩的时候借回来的，由于公司的性质和华为比较类似，所以一直对华为的发展比较关注。

Death Race 2(《死亡飞车2》)：这是《死亡飞车》的前传，而非续集，美国电影的制作方式也是如此类似，一旦成功后，后续和前传就都来了。影片的表现也非常一般，记得看《死亡飞车》的时候刺激火爆的场面给我留下了深刻的印象，看完后还沉浸在那种场景里面。而这部2，无论是赛车场面的效果还是剧情的对白，都是挺2的。由于一开始没看主演等介绍，那个男主角的声音出来的时候，略带嘶哑的声音让我一开始还以为是Jason Statham，后来才发现原来不是。各种前传中，我记忆中最好的是诺兰的《黑暗骑士》，这部可以说是蝙蝠侠的前传的电影把蝙蝠侠的故事提升到了一个新的高度，再次掀起一个高潮，据料说诺兰已经答应执导前传3(The Dark Knight Rises)，一起期待吧。

The Road(《末日危途》)：关于世界末日的电影很多，而最著名的莫过于《2012》了。然而，《2012》确实让人过足了瘾，也赚足了票房，但我相信大部分人看完后留下的是电影里面的精彩的场面和一个世界末日的主题。如果想真正看看世界末日时会是什么样子的，推荐看这部电影。这部电影看的时候才会在心底涌起世界末日到来时的恐惧感，至少在观看2012的时候我没有感觉到(反而是一种特爽的感觉)。影片讲述的是世界末日后，幸存的人的生活。一个父亲带着儿子两人在犹如地狱般的世界里面一起开始着漫无止境的旅途，其中需要躲避吃人的人的追逐，需要不停的寻找食物，寻找可以避风雨的地方，至于明天会如何，没有人能够回答。整个电影过程有点压抑的，而且80%的时间里面除了父子俩，几乎没有其他人物的出现。究竟什么是好人，什么是坏人？我们的人生又会咋样？结尾的那一家人的出现，加上那条看上去还算可爱的狗，算是给了这部绝望的电影一个温馨的结局。

《秋天的童话》：周六晚上的11点到12点半就交给了这部老电影。或许这种能打动心灵的电影就本应该在夜深人静时观看。三十来岁老男人的初恋是否和年轻气盛的我们一样呢？影片中的爱情不是那种一见钟情式的，而是从最初的坏印象到逐渐了解后而产生感觉。按照“恋爱使优点扩大化，而婚姻使缺点扩大化”的理论观点，我一直觉得来源于这种的感情比一见钟情式的要稳定可靠得多，因为对双方的缺点了解得更多。泰坦尼克号为我们描述了一个经典的一见钟情式的爱情，但正如黄子华在某次栋笃笑里面调侃的那样，这爱情的伟大在于时间短得还没过完新鲜期。一个女人最能够让人感动的地方在于把一个乱糟糟的家收拾得整整齐齐干干净净，当男人推开门看到时的那一个moment，感动到一塌糊涂，于是倾尽自己的所有买下了那个表带。一只表，一条表带，这是心有灵犀呢抑或是阴错阳差呢？

本文链接

一周书影

2011-01-09T16:11:00Z

本人打开电脑大部分情况在做两件事：看电子书或看电影。浮光掠影过去，发现留下的没多少，故作此记录。

《完美嫁衣》，一部很轻松，偶尔带点浪漫的香港电影，在看惯了所谓的大片后，这部小片却可以让人感觉到非常温馨和幸福。Happy ending结局的同时，我在想，为什么恋人之间都喜欢赌气？难道非要等到失去了的时候才知道去挽回？或许这是电影的套路吧。

《得闲炒饭》，许鞍华的女同电影，透露着“许式”女性意识和“得闲”显示的港味。影片轻松简单，时而可以会心的微笑下，配乐也不错，周慧敏依然很有魅力。

《笑傲江湖》三部曲，看这部电影纯粹是心情影响，不知突然间感觉到压力好大，于是乎网上down了这部电影。如果人真的可以退出江湖的话，那该有多好，没有派别，没有恩怨情仇，当小船上《沧海一声笑》的歌声响起的时候，一霎那间真的觉得自己好像已经身处某个世外桃源当中。然而那毕竟只是一个幻想，人就是江湖，有人的地方有就江湖。第二天起床还得照样准时去上班，照样得面对生活在这个城市的压力。

《My name is Khan》(《我的名字叫可汗》)，看完后，再一次为印度电影所折服，尽管影片的后面有点渲染过度的趋势，但个人认为这不妨碍其成为一部好片。从影片一开始Khan的一句“I am not a terrorist”就知道这会是一部有点沉重的电影。影片里所反映出美国人所谓的人权，也只是针对自己的同胞，一旦关系到自身利益的时候，仿佛就被扔到九霄云外去了。9.11事件对整个世界来说是一个灾难，但之后的行动又何尝不是一个世界的灾难呢？“古兰经里说，一个无辜者的死亡等同于整个人类的死亡”，种族之间，民族之间的纷争何时才能消除？再说回印度的电影，这几年凭着《贫民窟里的百万富翁》，《Three Idiots》让人觉得这个国家尽管贫穷，但却充满着希望，纵观中国的电影，这几年似乎都没有能够留下深刻印象的（《让子弹飞》还没看，希望这部一片好评的电影能够留下点印象），全是“大片”下的和谐社会啊，比起印度来，至少连自嘲的勇气都没有。

《纸婚》，周六的一个下午，耳边听着Yanni的new age，非常轻松的就把此书翻阅完毕。一个故事，一种感动，非常的贴近现实，绝对能够引起共鸣。对于80后来说，都处于已经或者即将步入婚姻的阶段，应该都值得一看。故事讲述的是一个非常贴近现实的婚姻生活，甚至有时我都怀疑是作者本身的真实故事，至少有糅杂一点在里面吧。相爱容易相处难，那么到底有多难？这些难题又该如何去化解？都说人生没有彩排，一直在现场直播，那么很多事情为什么非得要自己亲自去试验一把，才会知错呢？

本文链接

Linux下WEB100补丁对窗口扩大选项的问题

2010-11-07T15:55:00Z

前段时间在跟踪一个RDP应用的问题，RDP应用在过设备透明代理处理后速度变得比不过要慢的多，至少一半以上。嫌RDP每次使用太麻烦了，于是使用了一简单的TCP发包服务端和收包客户端，用来模拟RDP的数据流，加快测试的效率。结果发现最简单的发包应用经过透明代理后就会慢上3s左右，一开始以为这是代理处理带来的处理时延，每个包的处理时延累加起来就达到的这个数字，后来抓包看了下发现不对，于是使用Linux做发包的服务端，Windows做客户端，连接时抓包如下：

-bash-2.05b# tcpdump -i eth0 port 8888 -nn -c 20

tcpdump: listening on eth0

15:24:16.709831 192.168.0.148.60320 > 192.168.3.121.8888: S 1286639064:1286639064(0) win 8192 <mss 1460,nop,nop,sack,nop,wscale 8> (DF)

15:24:16.713211 192.168.3.121.8888 > 192.168.0.148.60320: S 1778803221:1778803221(0) ack 1286639065 win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 7>

15:24:16.709831 192.168.0.148.60320 > 192.168.3.121.8888: . ack 1 win 256 (DF)

15:24:19.740047 192.168.3.121.8888 > 192.168.0.148.60320: P 1:257(256) ack 1 win 45

15:24:19.929831 192.168.0.148.60320 > 192.168.3.121.8888: . ack 257 win 255 (DF)

15:24:19.936427 192.168.3.121.8888 > 192.168.0.148.60320: P 257:1461(1204) ack 1 win 45

15:24:19.936538 192.168.3.121.8888 > 192.168.0.148.60320: P 1461:1601(140) ack 1 win 45

15:24:19.929831 192.168.0.148.60320 > 192.168.3.121.8888: . ack 1601 win 256 (DF)

15:24:19.929831 192.168.0.148.60320 > 192.168.3.121.8888: P 1:21(20) ack 1601 win 256 (DF)

15:24:19.937526 192.168.3.121.8888 > 192.168.0.148.60320: . ack 21 win 45

15:24:19.929831 192.168.0.148.60320 > 192.168.3.121.8888: P 21:41(20) ack 1601 win 256 (DF)

15:24:19.937731 192.168.3.121.8888 > 192.168.0.148.60320: . ack 41 win 45

15:24:19.929831 192.168.0.148.60320 > 192.168.3.121.8888: P 41:61(20) ack 1601 win 256 (DF)

15:24:19.937927 192.168.3.121.8888 > 192.168.0.148.60320: . ack 61 win 45

15:24:19.966700 192.168.3.121.8888 > 192.168.0.148.60320: . 1601:3061(1460) ack 61 win 45

15:24:19.966830 192.168.3.121.8888 > 192.168.0.148.60320: P 3061:3201(140) ack 61 win 45

问题出现在三次握手过程的第三个包和服务端发送的第一个包上，中间有一个3s的间隔，上层的服务端在acceept后，就立即发送数据了，没有任何的时延。为了确定延迟在何处引发的，在上层加了些调试信息，同时在LOCAL_OUT的最高优先级上注册了钩子函数来打印一些调试信息，结果表明延迟只可能发生在TCP协议栈中。

同时还有一个奇怪的现象，上层发的包长度都是1600字节，按道理TCP根据MSS拆包发送出去的包应该是1460+140的组合方式，这个从后面的包可以看出来，但是产生延迟的包被发送出去的时候的拆分方式却是256+1204+140的方式，而256刚好是三次握手中第三个ACK包携带的窗口值，看上去好像是刚好被这个窗口限制了。内核添加调试日志证明了就是被该窗口限制的，TCP认为超过了对方的接收窗口，导致在上层调用send的时候没有发送成功，第二次超时重发，同时拆包发送出去的。

在三次握手中可以看到有wscale的选项的，256<<8=65536，而不是256的，看来这个窗口扩大选项处理出现了问题。把TCP的建立流程再详细的跟踪一遍，主要看处理snd_wnd的地方，在tcp_rcv_state_process()里面发现，处理三次握手的第三个ACK包时，赫然一句：

tp->snd_wnd = ntohs(th->window);

这个地方应该是需要考虑窗口扩大选项的，不太相信Linux有这个大的一个BUG，去lxr上翻看Linux的原始代码，发现却是：

tp->snd_wnd = ntohs(th->window) << tp->snd_wscale;

最终发现是我们打的WEB100补丁上把这句话给修改了，补丁的这部分代码如下：

   tp->snd_una = TCP_SKB_CB(skb)->ack_seq;
-  tp->snd_wnd = ntohs(th->window) << tp->snd_wscale;
+  WEB100_VAR_SET(tp, SndUna, tp->snd_una);
+  /* RFC1323: The window in SYN & SYN/ACK segments is
+  * never scaled (PSC/CMU patch {rreddy,mathis}@psc.edu).
+  */
+
+  tp->snd_wnd = ntohs(th->window);
+  WEB100_UPDATE_FUNC(tp, web100_update_rwin_rcvd(tp));

Google了一把，发现是这个是比较老的Web100的补丁上有的代码，新的好像没有这个代码了。

修改后测试，3s的时延消除。但是RDP慢上一半，3s的时延消除影响不大，下篇继续。

本文链接

Linux下BICTCP实现上burst control机制分析

2010-04-11T10:06:00Z

问题现象在测试部发现的问题：测试SqlPlus的数据库查询速度的时候，发现经过我们连接代理后速度比不过代理时候慢一倍，在关闭我们的功能后1分钟能够完成查询，但是启用后就2分钟才能完成。当时对SqlPlus的数据流还有TCP的抓包进行分析，该查询器查询数据的特点是客户端发出21个字节的数据包，然后服务器回应9356字节的数据，然后再由客户端发21字节的数据，再回应9356字节，如此重复直到查询完成。...

身体是革命的本钱

2010-04-09T13:11:00Z

清明小长假，没啥正事要做，被人约去爬梧桐山。于是周六下去小打了2个小时的羽毛球，周日一大早乘车到盐田，早上9点多从盐田那边开始上山，由于有两个女生，稍慢一点，中午11：40左右到顶，然后从泰山涧下山，到环山公路处再沿好汉坡再次登顶。再从泰山涧下，顺着环山公路，翻越小梧桐，步行至仙湖植物园。到园区5点多，一直想去仙湖植物园看看一些没见过的植物，可惜到了的时候已经腿发软了，没心思再看那些养眼的植物了。...

一个new失败问题的查找过程

2010-01-16T05:26:00Z

在测试部发现一个问题，整个系统跑一阵后就有daemon程序崩溃，虽不是必现，但是一天还是可以出现好几次，导致性能测试无法继续下去，看core的信息是new失败了，具体堆栈如下： (gdb) bt#0 0x2acd25c1 in kill () from /lib/libc.so.6#1 0x2adfc58d in pthread_kill () from /lib/libpthread.so.0#2 0x2adfc90b in raise () from /lib/libpthread.so.0#3 0x2acd2364 in raise () from /lib/libc.so...

碎碎平安

2010-01-03T14:05:00Z

元旦那天，因为请了个朋友吃饭，看到下面有只没用的碗，想拿出来用，没想到刚一洗完，手一滑，清脆的一声，就开花了。今天下午去打羽毛球，刚打了两分钟，就听崩一声，线被打断了。碎碎平安！！！

网络拥塞控制(九) CUBIC

2009-11-29T09:46:00Z

接上文，在BIC-TCP提出后不久，NorthCarolinaStateUniversity的研究人员在根据BI-TCP的一些缺点后，再次提出了CUBIC的算法，CUBIC不仅仅是简单的对BIC-TCP存在问题的一些修正，它的整个算法都已经做了较大的调整。先看下BIC-TCP的缺点：首先就是抢占性较强，BIC-TCP的增长函数在小链路带宽时延短的情况下比起标准的TCP来抢占性强，它在探测阶段相当于...

带你的耳朵去旅行

2009-05-30T07:38:00Z

什么东西能够带你的耳朵去旅行？这段时间太忙，基本上晚上下班回家就没怎么开电脑了，因而也都好长一段时间没有听听音乐。今天放假特意在优酷上找音乐听，于是就找到了《带你到耳朵去旅行》，并一口气把其全部听完。没错，带耳朵去旅行的是音乐。这张李志辉的音乐会专辑《带你到耳朵去旅行》，确实起到了它所号称的名字的作用，音乐旋律多变，展开的是跨越时间和空间的神秘之旅。最爱的还是中间的那首《紫禁花园》，大气磅礴，跌宕...