zt开启P2P与宽带路由器的某种水产时代——StreamEngine技术分析与验证测试

asiaeagle

觉得很振奋！新技术出现了，今后刷机就没那么必要了。

来源：计算机世界实验室 作者：韩勖

上行带宽、P2P与宽带路由器的三角矛盾

　　近年来，电信运营商下大力气改造与建设数据网络，宽带接入的速度与服务质量都有了较大提高。以我国最流行的ADSL接入方式为例，许多城市都可以申请2Mbps或者4Mbps的接入速度，有些地方甚至已经开始提供8Mbps的高速接入服务。与之相应的，基于互联网的应用模式也有了很大转变。有了充足的带宽保障，网络游戏、在线视频、VoIP、P2P等应用逐渐流行开来，互联网用户有了更加丰富多彩的应用体验。带宽的提高也使多机共享具有实际意义，个人或小型企业对宽带路由器的需求让这类产品在市场上持续热卖。
　　与下行速度的突飞猛进不同，宽带的上行速度提高相对缓慢。很多地方ADSL的下行带宽达到4Mpbs或8Mbps，上行带宽却依旧维持在512kbps的水平。事实上，这种情况在拨号上网时代就存在，那时最快的调制解调器可以提供56kbps的下行带宽与33.6kbps或48kbps的上行带宽。互联网研究人员通过对各类应用模式的整理分析，得出一个结论，即绝大多数情况下，用户对下行带宽的需求远远超过上行带宽。举个例子，我们用尽所有下行带宽从Web或FTP服务器下载文件时，上行带宽可能只被占用了几KB。这个结论日后被广泛应用在各类标准制定与网络建设中，目前的ADSL标准即提供了最大8Mbps的下行带宽与1.5Mbps的上行带宽。
　　而现在基于网络的应用模式在改变，新应用对上行带宽提出了更高要求，这个理论正在失效。P2P是目前最受个人用户喜爱的一类应用，它的理念是在从他人处获取的同时也为他人分享。从技术角度看，此类应用会建立数倍于从前的连接数，占用所有的上下行带宽。连接数对现在的宽带路由器不是大问题，3月份我们进行的针对P2P应用的横向评测可以证实这一点；带宽占用是致命伤，尤其是现阶段比下行带宽更容易达到饱和的上行带宽，它被占满就意味着用户请求或确认很难发出，宽带路由器对此无能为力。
　　一个简单的实验可以证明上面的推断：分别用HTTP和BT下载任务占满下行带宽，同时Ping新浪网站，前者响应及时无丢包，后者响应极慢大量丢包。由此可见，罪魁祸首在于延迟，是它造就了不同的应用体验。相信很多人都对开BT时浏览网页的速度有刻骨铭心的回忆，在此我们就不做验证了。
　　分析一下P2P应用造成较大延迟的原因。首先，宽带路由器的CPU性能有限，在处理大量新建连接请求或维持、查找较大的并发连接表时会消耗很多资源，造成一定延迟。这方面新产品（如支持11n的无线宽带路由器）因为应用了较强的CPU，受到的影响有限；老产品就很难说了，轻则在高延迟的情况下勉强维持运行，重则死机或重启。其次，P2P应用导致宽带路由器维持了庞大的出栈队列，新的连接请求必须排队等待发送，延迟无法预料。如果出栈队列中的数据报多或大到占满了所有上行带宽，那么连接请求很可能因为传输超时而被丢弃，这样的网络几乎就没有可用性了。
　　再做一个实验，来证明上行带宽被占满是造成网络延迟与丢包的主要原因。将BT上行带宽限制为理论值得2/3，下行带宽不限，再进行下载时的Ping测试，响应时间马上恢复到与HTTP同一数量级。那么为P2P类应用限带宽就是有效的解决方法么？也不尽然，这种做法实际操作起来局限性太大。首先，某些软件并不能进行这样的限制，尤其是那些基于P2P理念的视频应用。其次，买宽带路由器就是为了多机共享，大多数情况下让所有使用者都对P2P应用进行限制是个不现实的想法。
　　某些厂商尝试将传统的QoS理念引入宽带路由器，可效果并不好。此类产品的性能并不足以实现基于应用层协议的QoS特性，2-4层的优先级设定对P2P应用的限制效果又很有限。最关键的，QoS策略的设定对于宽带路由器用户来说显得太复杂了。

Ubicom的前卫解决方案

　　前段时间我们测试过一款来自SMC的无线宽带路由器，它采用Ubicom的IP5160U作为CPU，在同类产品中很少见。我们并不熟悉这家公司与这款产品，仔细研究一下，发现别有洞天。Ubicom提供了一套软硬结合的解决方案，宣称可以有效改善上行链路拥塞造成的延迟与丢包。尽管所有工程师都对此表示怀疑，我们还是以最快的速度开始征集产品。最后，D-Link为我们送来了DIR-655，这也是截至到目前为止唯一一款在国内零售的采用Ubicom解决方案的千兆有线/11n无线产品。在此向D-Link表示感谢。

　　Ubicom作为芯片与解决方案提供商，并没有公开提供很多技术资料，我们只能从官方网站上的少量文档与网络上搜索到的信息推断出一些技术细节。根据白皮书所示，这套名为StreamEngine的解决方案包括一系列的功能步骤。它先对来往数据流进行识别分类，自动判断哪些是需要保持流量或延迟敏感型应用，然后将出栈队列中大小超过阀值设定的数据报分片，并根据前面的判断，为相应的出栈数据报自动设定最多256个优先级。

  

　　从应用的角度判断优先级，这算是QoS的理念。如果应用优先级判断的命中率令人满意，应该可以起到比较好的优化效果。我们无法得知这部分具体的技术细节，想必厂商也不便公开，权且将效果作为测试重点之一。分片，这是很聪明的做法，虽然出栈队列因此变得更深，但队列中不会再有大包。高优先级的数据报可以尽可能快地被发送，降低了延迟与抖动。从理论上分析，这些手段确实有助于解决上行链路拥塞的问题，抖动的降低也可以提高VoIP应用的通信效果。
　　要保证宽带路由器不成为瓶颈，还要实现StreamEngine提供的特性，CPU的性能非常关键。Ubicom IP5K系列CPU很有意思，竟然采用了10线程设计，流水线数量虽未公开，理论上总要与线程数有个匹配关系，应该也不会太少。多核多线程处理器已逐渐成为网络产品的主流选择，某种程度上这是应用需求决定的。以StreamEngine为例，CPU在对应用流量建模与分类时一定有不少预测未命中的情况，10线程并行处理可以保证资源调用的合理性与连贯性，避免出现过高延迟。

[ 本帖最后由 asiaeagle 于 2008-6-3 00:49 编辑 ]

asiaeagle

StreamEngine实战测试

　　我们在一条上/下行带宽为512kbps/1Mbps的北京网通ADSL线路上进行了实际测试，除D-Link DIR-655外，还找来一台某品牌几年前推出的11g无线宽带路由器作为参考。内网中有一台PC和一台笔记本，其中PC机设定为DMZ主机作为P2P应用的客户端，同时开启BT、eMule和迅雷占满所有上下行带宽进行海量下载，平均并发连接过千；笔记本作为测试机，考察各种应用的实际效果。所有测试结果被汇总在一个大表内，便于进行对比。应用中除Ping外，基本按照对时延的敏感性排列。因为本测试主观因素较多，我们在尽可能详细叙述真实情况的前提下，也依据主观感受为每项应用的表现打分，供读者参考。而采用11g无线宽带路由器在无背景流量下的应用效果，作为基准表现，也就是主观感受的满分5分。

　　从无背景流量的Ping测试中，可以看出这条ADSL链路的质量还是很不错的。低延迟、无抖动、丢包，以致所有应用的体验都堪称完美。可当P2P流量占满了链路的上下行带宽，网络几乎丧失了可用性。别说是在线视频或Skype，就算是浏览网页这种轻量级应用，都很难顺利完成。还有些细节在表格中无法体现，比如测试时间稍长路由器就会死机，几年前的产品设计看来确实很难满足如今的需求。关闭了StreamEngine特性的DIR-655也好不到哪去，Ping测试中几百毫秒的延迟比起前者上千毫秒的成绩不过是五十步笑百步，可用性一样是0分。不过综合二者所有测试结果来看，不开StreamEngine的DIR-655普遍比几年前的11g产品好上一点，这应该源自CPU及整体架构的进步。之前我们也对SMC的产品进行过极限性能测试，就算是长时间超负荷运行，路由器也未曾死机或重启，瓶颈已被完全转移至上行链路。
　　开启了StreamEngine特性的DIR-655表现极其令人惊讶，P2P背景流量对各项应用的影响已经很小。浏览网页的体验与无背景流量时没什么不同；股票软件的操作偶尔会有迟滞，但在可以接受范围之内。在线视频播放的一些细节值得一提：当网页中的视频开始载入时，会有几秒钟的延迟；播放开始后，可以看到下载进度条与播放进度几乎保持一致，视频没有过中断；当持续播放一段时间后，视频下载速度开始超过播放进度，并且越来越快。我们认为这是StreamEngine根据应用的流量模型自动进行分类的最好例证，也显示出应用优先级提升的几个阶段中系统的处理机制。跑跑卡丁车的游戏效果也很好，比赛进行中偶尔会有跳帧现象，与前面测试中根本无法进行游戏成鲜明对比。唯一有些遗憾的是，在进行Skype通话时，对端听到的声音并不是很清晰（但能明白是在说什么）。由此可见，VoIP对链路时延与抖动的要求还是很高的。
　　不过，我们也发现Ubicom的整体解决方案还存在一些的问题。开启StreamEngine的情况下，当背景流量大到一定程度时，路由器会不能及时相应ADSL Modom发送的Echo-Request报文，导致PPPoE连接被复位。虽然路由器马上会重新拨号建立连接，但对网络应用还是有些影响的。而采用以太网连接进行极限性能测试时，并没有发生这种情况。D-Link对我们提供的反馈非常重视，派专人对测试流量进行了抓包分析，并会同UBicom对底层处理机制进行了改进。我们期待新版固件能够尽快发布，彻底解决这一瑕疵。

测试后记

　　测试结束，我们对StreamEngine的实现思路与实际效果有了比较深入的了解。总体看来，优化机制可以概括为两部分，即基于流量模型的应用分类和对出栈数据报的分片。这二者关联非常紧密，但以前者为主，后者为从。开启应用分类就是开启了StreamEngine，但可以不选择分片。我们在这种配置下进行了测试，可以看到虽然效果改善也很明显，但延迟与抖动都大了许多。想想也是，就算出栈队列的顺序被很好地优化调整，前面也会有一些无法预知大小的数据报等待发送，造成了不规则的延迟与抖动。而分片不能在应用分类关闭的情况下开启，那样没任何意义，只能增加系统的负担。
　　分片是IP协议最基本也是最重要的特性之一，其初衷是为了保证数据报在不同介质间的正常传送。利用为数据报整形的手段帮助实现链路优化，这倒是一个具有创新精神的想法，实际测试的效果也不错。但我们对此有三个担忧，第一，在测试中证明分片没有增大网络流量（bps），却显著增加了数据报的数量（pps）。如果此类产品被大量采用，为运营商局端到骨干网设备带来的压力是显而易见的。第二，分片肯定会为应用层设备带来影响，从以往的测试经验来看，并不是所有的IPS、UTM或安全审计产品都能识别分片后的数据。第三，分片对IPSec VPN的干扰是无法预知的，也许只有基于Ubicom方案开发的VPN模块或产品才能避免这个问题。
　　无论如何，Ubicom提供的解决方案可以非常好地解决P2P造成的上行链路拥塞问题，我们甚至认为以“革命性”这个词来形容都不为过。有趣的是，包括用户、下游厂商甚至Ubicom自己似乎都没有意识到这一点，StreamEngine更多地被强调用在无线传输的优化方面，这很可能与国外网络接入的特点有关。向P2P模式转移是当前网络应用的发展趋势，相信会有越来越多的用户关注这套解决方案，并为之买单。虽然采用Ubicom方案的产品性能价格比已经很高，但还要实现大量普及，价格显然还是最大瓶颈。
　　我们认为StreamEngine最有价值的一点是新思路，这超越了技术层面的一切。之前，无论是SOHO、企业还是电信级产品或方案，解决问题时都先入为主。要解决P2P给网络带来的影响么？让我们先识别它们，然后限制或者阻断它们，从而保证其他应用。可惜道高一尺魔高一丈，随着P2P应用协议与各种反制手段的更新，管理者或产品永远处于下风，无法做到全面控制。另外，这种做法的实现成本太高，用在宽带路由器上也划不来。StreamEngine则采取了相反的思路，既然P2P流量难控制，那就抽象考虑问题，由各类应用不同的流量模型入手，保证时延敏感型应用的需求，剩下的带宽余量再给对时延要求不高的应用。它确实不能对P2P应用做到完全控制，但宽带路由器用户又有几个真想封禁P2P呢？
　　上古时代，水淹华夏，民不聊生。首领尧命鲧治水。鲧坚持筑堤堵水，最终失败。其子禹改封堵为疏导，取得了成功。同样的人力，同样的工具，结果却截然相反，关键就在于解决问题的思路是否正确。如今P2P流量有如比特的洪水，技术只是“人力和工具”，要成功“治水”，必须要找到正确的思路。
　　做产品，需求主导，思路为主，技术为辅。

zdcps

好文章，实际使用确实效果明显，再也不用设置繁琐的QOS了。

hcym

1. 做产品，需求主导，思路为主，技术为辅。

复制代码

:(