海阔天空

导航

2011年11月15日 #

网络拥塞控制(十) 总结

摘要: 也是总结的时候了,写完了TCP的多个经典的拥塞算法,但是由于这方面的优化算法还有很多,没办法能够一一讲完,所以下面对其他的一些比较典型的也进行一个简单的介绍:FastTCP:FastTCP由于后来没有对开源界做贡献了,因为作者本人自己创办了公司,把FastTCP变成了商业产品,所以后续的学术研究就比较少了。FastTCP是从TCPvegas的思想发展而来,利用网络延时进行拥塞判断。之前讨论过,基于延迟的算法是对整个网络的拥塞控制有好处的,但是和当前的基于丢包的算法来说两者不公平。所以估计作者后面也做了很多的改进。ECN:显式拥塞通知,该算法的思想是想借助路由器,因为拥塞的状况中间的路由器是最清 阅读全文

posted @ 2011-11-15 23:11 fll 阅读(3849) 评论(2) 推荐(1) 编辑

2010年11月7日 #

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

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

posted @ 2010-11-07 23:55 fll 阅读(1240) 评论(0) 推荐(0) 编辑

2010年4月11日 #

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

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

posted @ 2010-04-11 18:06 fll 阅读(1888) 评论(1) 推荐(0) 编辑

2010年1月16日 #

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

摘要: 在测试部发现一个问题,整个系统跑一阵后就有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... 阅读全文

posted @ 2010-01-16 13:26 fll 阅读(4332) 评论(1) 推荐(0) 编辑

2009年11月29日 #

网络拥塞控制(九) CUBIC

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

posted @ 2009-11-29 17:46 fll 阅读(8031) 评论(1) 推荐(1) 编辑

2009年3月20日 #

网络拥塞控制(八) 外传之如何测量TCP的拥塞窗口

摘要: 我们一直讲了许多种网络拥塞算法,这些一直都是理论上的算法,到底在实际中窗口的调整是怎么样的呢?对于一个连接来说,如何知道当前的拥塞窗口值是多少呢?在Linux下,使用内核模块tcpprobe,可以得到TCP连接的参数,但是麻烦的是,该模块需要内核kprobes的支持,如果不怕麻烦的话,当然可以尝试下。我们希望的是能够不需要通过这么复杂的机制,就能够得到内核中TCP连接的参数。在翻遍了proc目录和... 阅读全文

posted @ 2009-03-20 23:31 fll 阅读(5159) 评论(1) 推荐(0) 编辑

2009年2月24日 #

网络拥塞控制(七)BIC-TCP

摘要: 上面我们已经提到了HSTCP,它通过简单的修改标准TCP的增长方式,从而达到了高吞吐。方法很简单,但是缺点在于,它存在严重的RTT不公平性,RTT不公平性在标准TCP中也是存在的,但是HSTCP显然扩大了这个不公平性。RTT的不公平性指的是当有多条连接在同一个瓶颈带宽上跑时,如果这些连接的RTT不相等,那么这些TCP连接在该链路上分得的带宽也是不一样的。作为一个公平性的协议,是应该达到这一点的。从... 阅读全文

posted @ 2009-02-24 23:31 fll 阅读(7100) 评论(3) 推荐(3) 编辑

2009年1月3日 #

数学爵士乐

摘要: 最近一直在看《数学爵士乐》这本书,并且有些地方还好好的琢磨了几次。其实我对数学的态度的改观是在工作之后,以前在大学的时候完全就不明白我学了那么多的数学究竟有什么用,比如线性代数,复变函数,概率论等等之类的,现在才知道我不知道有什么用那是因为学校的教材的原因,在我们的教科书中从头看到尾的就是一大堆数学公式,方程,定理等等,而并没有告诉我们的实际用途。最郁闷的课程就是《信号处理》,这个郁闷不是说我考试... 阅读全文

posted @ 2009-01-03 13:53 fll 阅读(1108) 评论(0) 推荐(0) 编辑

2008年11月30日 #

网络拥塞控制(六)HSTCP

摘要: 六、HSTCP 注意到上面所提到的TCP的一些缺陷,国外学者开始提出新的拥塞控制方法,最先由Floyd提出了HSTCP(High-Speed TCP),并在2003年由ietf组织标准化(rfc3649)。 HSTCP为了所达到的目标: 1.单个连接能够达到高吞吐率而不需要不现实的低丢包率要求。上面提到,普通的TCP要想在1Gbps,100ms的环境下达到满吞吐率,需要8333个RTT才能达到窗口... 阅读全文

posted @ 2008-11-30 16:20 fll 阅读(4145) 评论(9) 推荐(0) 编辑

2008年9月20日 #

字符串匹配算法

摘要: 这是一个非常古老的话题,最近因为工作的原因,又翻了下字符串匹配算法,这一翻又翻出来新花样。 学过数据结构和算法的应该最熟悉的是著名的KMP算法,KMP利用模式串自身的匹配性质,在不匹配的时候可以跳跃比较长的距离,从而比之朴素的字符串算法速度快。 首先要说的是BM算法,据称该算法比KMP又快上3-5倍,该算法在Linux内核中有实现,详见Ts_bm.c,我用的内核版本是2.6.25,其他版本可能文... 阅读全文

posted @ 2008-09-20 22:45 fll 阅读(7835) 评论(2) 推荐(1) 编辑