博客园_海阔天空

读书观影3

2011-11-19T13:16:00Z

T.I.A，This is Africa，《血钻》（blood diamond）。

一部好的电影能够给人带来很多的思考，《血钻》就是这样的一部电影。电影描述的是非洲战乱生活里面，非法的钻石贸易下，一个价值连城的粉色钻石给人带来的命运考验。非洲的大陆，在大部分人包括我的记忆里，两种印象最为普遍，一种是到处是饥饿、贫穷的人民的灾难景象，另一种是各种各样的野生动物，一望无际的大草原和森林，还有朴实的人民，这些景象都是来源于电影或者各种媒体的报道，也就是电影中女记者说的那句话“这里是非洲第二大的难民营，上百万的难民，但是只换来BBC两分钟的报道，夹杂在体育和天气之间”。

我们没有生活在非洲，无法体会到那种视生命如草芥般的生活环境，那些生命对于我们来说就是数字，就像当今中国各地不同大大小小的灾难产生的数字一样。端着AK47，对着人就是一顿扫射，冰冷得连人的惨叫声都没有听到一声；小孩得到的教育就是拿枪去杀人，抢劫，然后获得某个队长的称号，从一开始还需要蒙住眼睛地开枪到后来直接拿张枪对着自己父亲的头部；原本物产丰富的地方，石油，黄金，象牙，钻石，每一种本都应该使得国家可以借此稀有的资源过上富裕的生活，但是相反的是带来的却都是灾难。我想起曾经去过的巴基斯坦，当我从繁华的迪拜机场转机，降落在卡拉奇时，一种巨大的反差感就形成了。当再走出机场，踏上这片土地时，顿时就有一种强烈的发展不平衡感，与此同时还有一种无助感，车顶上和四周都“挂”满了人的公共汽车，门前拿着枪站岗的酒店、饭馆，随时都可能没有电力供应的城市，刚好还碰上本拉登出事的日子，街头上可以看到因骚乱被烧毁遗弃的汽车。面对如此的一个环境，“一个人怎么可能改变这里？”只有成长在那里的人才了解这种痛苦。再想想，就得接受这种现实，这个世界就一直都是弱肉强食的世界，就像电影《战争之王》中所表达的一样，全世界都在说要和平，但是世界前五的军火商却是目前的联合国5大常任理事国，不断的贩卖军火资助他们战争然后从中获利，这就是赤裸裸的现实世界。所以从这点说，不可否认当前中国社会的稳定为经济的发展创造了良好的条件。

人类的虚荣心使得钻石价格飙升，有利可图于是间接就导致了血钻的诞生，又或者鱼翅导致了鲨鱼的灭顶之灾，象牙导致了大象的减少，还有《可可西里》里面所记录的藏羚羊的灭绝。如果知道每粒钻石的后面，都是以一条或者多条生命为代价的时候，不知道又该如何？

人类需要消费，也需要钻石的点缀，但是在此之前，还是请理性思考下。

This is Africa，一个称之为"被上帝遗弃的地方"，但是我们也看到Soloman和Archer为此做出的努力，一两个人改变不了，那就花上数代人的努力，只要坚强地活着，明天总是会更好的。

本文链接

网络拥塞控制(十) 总结

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字节，如此重复直到查询完成。在没过代理时发现，9356字节的数据都是一瞬间送到客户端的，从而每次交互就是一个RTT的时间，而被代理后抓包发现这9356个字节都是分两次送出的，并不是一次性的全部发出，每次发出了6个包之后就开始等待对端的ACK，直到收到ACK后才发送剩下的字节，这样每一次交互就相当于耗费了两个RTT的时间，从而总时间多出了一倍。

摸索过程

在分析了SqlPlus的数据流后，写了一个简单的测试程序，因为SqlPlus拿来测试太麻烦了，每次都要登录等操作，极其繁琐。该测试程序工作方式：客户端发送m字节，然后服务端收到后回应n字节数据，如此反复，取m=21，n=9356用来模拟SqlPlus的数据情况，得到的现象是一样的，走代理后时间增加了一倍，后来继续加大该比例，当取到m=21，n=50000时发现过代理慢了2倍，从抓包分析是中间等了2次ACK。

那么是我们的代理程序引起的还是BICTCP的原因呢？

TCP的实现上算法有很多，但是影响发送性能，并且需要等对端ACK的只有2个值，拥塞窗口和对端的流控窗口。利用TCP提供的TCP_INFO套接字选项，把这些值全部取出来看，窗口是远超过6的，流控窗口方面，因为之前修改过TCP的缓冲区，所以这次把接收缓冲区修改为很大，但是问题依旧，利用netstat可以看到，TCP的Send-Q基本上都是几十K，说明大部分情况是有数据可以发送的，后来干脆把该测试程序直接在Linux上跑，也不经过代理，结果也发现比Windows下跑还是慢了1倍，从而可以肯定是与我们的业务程序代码是没有关系的，罪魁祸首肯定是Linux的TCP协议栈。

既然牵涉到协议栈，首先最大嫌疑的就是BICTCP，于是将/proc/sys/net/ipv4/bictcp=0，再跑，居然还是一样，看来又怀疑错对象了。

在应用层能做的事情就这么多了，还不能解决问题，那就要深入到内核里面去看代码了，是否有遗漏的东西，强调下要记得目标方向，内核里面的TCP代码相对比较复杂，机制非常多，很容易看走眼。

TCP在发包之前调用了一个函数来检测是否可以发送数据包：

int tcp_rcv_established(struct sock *sk, struct sk_buff *skb,  struct tcphdr *th, unsigned len)
{
    struct tcp_opt *tp = &(sk->tp_pinfo.af_tcp);

    tp->bictcp_max_packets_in_flight = 0;    /* reset burst moderation count  */
        ……
}

int tcp_transmit_skb(struct sock *sk, struct sk_buff *skb)
{
    ……
    if (tp->bictcp_max_packets_in_flight == 0)
        tp->bictcp_max_packets_in_flight =  tcp_packets_in_flight(tp)+tcp_max_burst(tp);
     ……
}

也就是说在establish状态每收到任何一个包，bictcp_max_packets_in_flight就被置0了，然后每次发送一个包的时候再重新赋值为“in_flight”的数据包个数加上突发个数，其中tcp_max_burst(tp)是等于3的，那么在交互的过程当中，一旦收到对端的全部确认后，显然bictcp_max_packets_in_flight就为0了，那么下次再发送数据包的时候，bictcp_max_packets_in_flight就等于3了，当数据越发越多的时候，那么"in_flight"的数据也变大，所以bictcp_max_packets_in_flight也随之增大，但是当一次交互完成后，"in_flight"就为0了，也就相当于每一次交互都需要重新启动这个过程，因而就导致了之前看到的交互都变慢了的现象。

该控制机制的好处在于可以防止突然的大量数据：如果有一个包乱序或者丢失，后面接着就来了一大把数据，从而造成这个包一旦到达后，可以连续确认非常多的数据，如果没有此机制的话，那么便可以一次性的发出一大片数据，而使用了该方式后，则一次能发送的数据少的多，可以很大程度上的减少超时和包丢失率。

关于burst control的讨论可以在此看到：http://oss.sgi.com/archives/netdev/2004-07/msg00988.html，同时有数据分析，对比了burst control机制的影响：

http://www4.ncsu.edu/~rhee/export/bitcp/tiny_release/experiments/BIC-600-75-7500-1-0-0-noburst/index.htm

http://www4.ncsu.edu/~rhee/export/bitcp/tiny_release/experiments/BIC-600-75-7500-1-0-0/index.htm

建议解决方案

最简单的方式就是把/proc/sys/net/ipv4/bictcp_moderation置0，通过模拟测试可以确认该方法可以达到和不过代理时一样快的速度。

因为在2.6版本的内核代码里面找不到该限制了，在2.6的内核的发包函数里面只有对拥塞窗口、流控窗口和nagle算法的检查，没有burst的检查，在BIC的实现里面也没有该条件，可能某种原因把它去掉了，但是没有找到其说明，又或者用其他什么算法给替换了，暂时没有找到。

本文链接

身体是革命的本钱

2010-04-09T13:11:00Z

     清明小长假，没啥正事要做，被人约去爬梧桐山。于是周六下去小打了2个小时的羽毛球，周日一大早乘车到盐田，早上9点多从盐田那边开始上山，由于有两个女生，稍慢一点，中午11：40左右到顶，然后从泰山涧下山，到环山公路处再沿好汉坡再次登顶。再从泰山涧下，顺着环山公路，翻越小梧桐，步行至仙湖植物园。到园区5点多，一直想去仙湖植物园看看一些没见过的植物，可惜到了的时候已经腿发软了，没心思再看那些养眼的植物了。
    回来当天感觉还好，可能是腿没感觉了，第二天的时候腿就要用手搬了，出去走了一趟，一瘸一拐的。养了一天脚，第三天脚好了，终于走的动去上班了，没想却感冒了，爬山那天是阴天，梧桐山上是一片雾海，能见度最多20m左右，头发衣服都一直是湿的，估计就这引发的。感冒了一天，极其不舒服，没想到更痛苦的在后头。第四天喉咙开始痛了，买了点药吃，结果没见好转，痛到最后连说话都不行了，吃饭也疼，第五天一大早跑去医院，一诊断急性咽炎，晕，咋就这么不走运了，还是医院效率高点，当天下午开始好转。至今天总算全部康复。
    一直以为自己身体还不错，平时锻炼得也不算少，每周都会去打羽毛球，每次几个小时都可以顶下来。但是这一次的一连串动作让我再次注意到体质的下降，这估计是自从大学以来身体不舒服的最长时间了。
    身体是革命的本钱，再忙不能不顾身体，腾不出时间照顾身体，迟早会腾出时间来生病，hoho。

本文链接

一个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来抢占性强，它在探测阶段相当于...