流量管理 疏导为先

Sina WeiboBaiduLinkedInQQGoogle+RedditEvernote分享




在www.edu.cn上看到老毛署名的一篇文章,深入浅出,贴近用户业务,感觉很不错,征得他同意后帖到这里与大家分享。以前就知道老毛低调挣钱,没想到宣传推广上开始高调了,可喜可贺~~

原文地址:http://www.edu.cn/li_lun_yj_1652/20121118/t20121118_870547_1.shtml

随着教育信息化进程的不断加深,我国已建成规模庞大的教育网络,为高校提供了优越的接入条件。然而,日新月异的互联网应用吞噬着越来越多的带宽,校园网内终端接入数量也始终处于高速增长的态势,对高校网络的运维提出了新的挑战。在这种情况下,如何更合理地管理流量,为教科研任务提供更好的保障,成为各高校信息中心负责人普遍关注的问题。

面对洪流,最好的做法是主动疏导,而绝非被动封堵。如今,通过流控产品对应用流量进行梳理的做法已被普遍接受。在不少高校,流控产品都成为网络出口必不可少的设备,直接决定着网络带宽的利用率及用户应用体验。经过长期跟踪分析,笔者总结了一些流控产品在高校网络出口环境的评估经验与部署建议,在此与各位老师分享。

协议识别走向立体化

众所周知,流控产品的工作机制与防病毒网关、IPS等安全产品类似,主要依靠应用协议的数据特征对流量的应用归属进行判断。它的核心是协议识别引擎,其衡量标准包括识别率、误识别率、协议种类和性能等。许多用户认为能够识别的协议数量非常重要(厂商往往也乐于强调这一点),其实不然,流控产品在真实环境下的识别率才是最重要的指标。这就好比防病毒网关,某些产品在规格表中公布的病毒签名数量只有几万条,但每一个签名都涵盖了同一病毒家族的所有变种,实际查杀能力甚至能超越其他一些标称内置数十万签名的产品。

随着P2P类应用越来越强烈的加密趋势,传统的基于应用协议数据特征的识别方式往往难以奏效,这就要求协议识别引擎能够对流量行为进行综合分析,根据统计特征、连接相关性等方面表现出来的蛛丝马迹判断应用的类型。一些流控产品已经提供了这种启发式处理机制,可以与传统方式相配合,实现更好的流量控制效果。但根据流量的行为特征进行判断,也会在一定程度上增加应用协议的误识别率,极端情况下甚至会影响到网络的连通性。所以当无法保证准确识别时,流控产品要给用户提供纠正的手段,或将部分功能作为可选项进行交付。

应用协议特征的更新响应速度也是非常重要的评估指标,在爆发式增长的互联网应用面前,业界所有厂商都不遗余力地进行着越来越多的抓包、分析、测试、更新工作。这种模式未来到底能坚持多久,谁也无法给出准确答案。但从其他安全产品的发展历程看,流控厂商也许要在技术实现机制或运营模式方面探索新的道路。

发展中的流控技术

流控产品本身就因流量控制的需求而生,发展至今已经比较成熟。但在不断变化的应用需求面前,其功能与实现机制一直在进行调整,争取更好的优化与管控效果。目前,流控的核心理念已从传统的控制下行流量发展到对上行流量的控制。前者虽然易于实现,但仅对TCP流量有一定的效果(如调整TCP Window)。对于UDP流量来说,这种方式非但效果不明显,且易产生流量差,对带宽资源造成极大的浪费。一些老师反映部署流控产品后,1G带宽实际到用户的只有6、700M流量,基本就是因为这个原因。考虑到目前占用带宽比例最大的网络视频和多数P2P下载应用都以UDP通讯为主,流控产品必须应具有通过控制上行流量来压制下行流量的机制,从而减小流量差,提高带宽利用率。

当带宽资源紧张时,流控产品通常会采用丢包的方法来实现压缩流量的目的。在数据包的丢弃机制方面,目前常见的有队列与非队列两种。队列方式相对比较传统,流控引擎会将数据包放入队列,然后由队列调度器统一进行调度,许多开源软件都采用了这种实现。这样做的好处是网络波动小一些,特别是TCP流量会更加平缓,但对资源的占用相对较多,系统压力会增大。如果没有用到队列,流控引擎一般会采用TOKEN BUCKET机制,当TOKEN不够时,对当前数据包直接进行丢弃。其优点是系统压力小,占用资源少,并且基本上无延迟。总体来看,两种丢包机制各有优劣,但对于高校网络出口这种流量较大的应用场景来说,非队列模式显然更为适用。

总体控制可以对网络流量进行宏观管理,但无法解决单点流量过大而引发的公平性问题,因此要达到更好的流量控制效果,必须采用点面结合的管理思路。这就要求流控产品在对出口流量进行整体梳理的同时,能够提供针对IP/IP群组的控制能力,维护一定程度的公平。此外,带宽保证/带宽借用也是流控产品中比较常见的功能,根据以往的实施经验来看,该功能在企业、网吧等出口带宽较小的场景中具有很好的优化效果,在高校、运营商等大流量环境中效果并不明显。

应用路由渐成主流

仅仅控制流量并不能完全解决问题,在条件允许的情况下,还需要主动疏导,以争取更好的网络应用体验。对于高校来说,多线接入是非常普遍的情况,除了教育网,还会有联通、电信等不同运营商提供的链路资源。它们的价格与质量大多存在差异,因此可以利用流控产品的应用路由功能,在不影响教科研任务的前提下,将不同的应用流量有针对性地分配到不同链路,达到降低成本、提高应用体验的目的。比较常见的做法是将P2P下载、网络视频等非关键应用的流量分配到高带宽、低成本的线路,这些应用的实现机制决定了即便是在质量欠佳的链路环境下,仍能达到让人接受的效果。而视频会议、远程教学等关键应用的体验必须有所保障,它们应享用最好的链路资源。综上所述,应用路由已成为当今流控产品的标准功能之一,未来必将得到大范围应用,高校中更是如此。

目前,流控产品通常有3种实现应用路由的部署模式,分别为:

  1. 针对不同应用,打上不同的DSCP标记,路由器/防火墙根据DSCP做策略路由;
  2. 针对不同应用,实施不同的源地址NAT,路由器/防火墙根据源地址做策略路由;
  3. 取代路由器/防火墙做接入,直接针对不同应用做策略路由。

第一种方式实施起来比较简单,但笔者在许多部署中发现,可根据DSCP做策略路由的路由器/防火墙并不多。而基本上所有的路由器或防火墙都支持基于源地址的策略路由,所以第二种方式更通用一些(当然这个通用是以增加流控产品负载为前提的)。第三种实现方式最简单,但对网络拓扑的改动比较大,设备也要承担最重的负载,目前在高校中比较少见。不过流控产品与路由器/防火墙的融合趋势是比较明显的,相信未来第三种部署模式的比例会逐渐增加。个别高校目前采用了为每条链路单独配备流控产品的做法,这非但不能实现应用路由,对流量也缺乏整体感知与控制的能力,除非是极特殊的情况,否则不建议使用这种部署模式。

在启用应用路由时,还有两个重要的问题需要考虑。首先是不同运营商之间的互通问题,大的门户或在线视频网站都有自己的DNS(CDN)负载均衡服务,通过不同运营商的DNS解析出来的地址肯定有所差异。如果目标地址是电信IP,但经过应用路由后流量指向联通线路,那么非但不会起到优化效果,反而会降低应用体验。因此在很多情况下,应用路由需要搭配DNS重定向功能,如果将流量甩向联通的链路,就将DNS请求通过联通的DNS服务器解析,以获得正常的访问效果。

其次是应用连接的相关性问题。一些应用中,存在有单会话包含多条连接的情况,如果其中一部分连接走教育网,另一部分走其他运营商,轻则影响应用体验,重则会中断应用。这种情况对流控引擎提出了更高要求,只有辅以前面提到过的基于应用协议行为特征的判断机制,才能解决特征完整性的问题。不过,应用路由的成功率也并不等同于对应用的识别率,某些应用是服务端先发数据,难以实现分流。所以厂商在分析、描述应用特征时,也要预先考虑到应用路由的需要。

协作:1+1>2的优化效果

流控产品部署在高校网络出口,对出入校园网的所有流量进行管理与优化,地位不亚于路由器与核心交换机。虽然流量管理是其主要职能,但如果能够与其他设备协作,将会起到更好的优化效果,使其价值最大化。

目前来看,最适合与流控产品进行搭配的当属Cache加速设备。借助应用路由,流控产品可以将高校网络出口流量中的特定应用及内容进行重定向(例如文件下载或Web视频应用),指向Cache加速设备。此时它就相当于Cache加速设备的一个客户,对终端用户而言是完全透明的。使用流控产品实现重定向和传统的基于端口的重定向的一个显著区别是,前者可以根据精准的应用识别结果,只转发Cache加速设备需要处理的流量,从而提升了缓存系统的利用率与命中率,同时降低I/O与文件管理系统的压力,使其更“专心”地去做业务相关的工作。

另一个适合与流控产品协同工作的是审计系统。一般而言,审计系统需要通过交换机镜像端口获取数据。因为镜像而来的是所有流量,审计系统必须在接收所有数据包的同时过滤掉不在业务范围内的数据包,这一环节会占用不少的系统资源。流控产品可以利用其强大的协议识别能力,将需要审计的应用流量(如HTTP,IM等)有选择地镜像给审计系统,这样就可以大大降低审计系统的压力,避免由于性能导致的审计不完整问题。

实际上,几乎所有作用于特定业务的串行或旁路设备,都可以从流控产品的应用路由及应用流量镜像功能中受益。一些高校曾经由于性能问题拒绝了WAF或防病毒网关,经过分析,其性能瓶颈很大程度上是因为不必要的I/O处理所造成,而非安全业务。需要注意的是,应用路由及应用流量镜像的功能在流控产品上还不是很普及,它们的实现机制也会为设备带来额外的负载,对性能的影响比较大。所以建议老师们在进行评估选型的时候,更多地依据实际环境中的测试结果做出判断。

作者后记

正如一位老师曾经说的:站在用户角度,当然希望一个产品能解决的问题越多越好,但十全十美的产品是不存在的,大部分产品甚至只在一部分功能上有些许亮点。的确,流控产品无论在功能还是可部署场景方面都还有着很大的拓展空间,而来自用户的建议与支持无疑是完善产品的最好助力。本文只是笔者在运维及部署方面的一些浅见,希望能够抛砖引玉,了解工作在一线的老师们的真知灼见,促使Panabit产品能够更好地满足高校应用需求。

(作者系北京派网软件有限公司首席技术官)

(5个打分, 平均:3.00 / 5)

雁过留声

“流量管理 疏导为先”有18个回复

  1. ORACLE 于 2012-12-04 6:50 下午

    确实分析不错,化堵为疏,应用分流是趋势所在.传统的限制下行已经没什么市场拉.

  2. zion0302 于 2012-12-04 7:52 下午

    写的太简单了。对于应用的设别、对于控制的手段没有什么新意啊?

  3. 路上 于 2012-12-04 10:18 下午

    字体太小了 没看完 在教育网上看完了 顶下 毛工 做为panabit的忠实芬斯 虽然企业用的是深信服。。。。。。。。。。。。。

  4. kaida 于 2012-12-04 10:39 下午

    协议识别引擎不仅关系着流量管理,对网络安全也有着特殊的意义.日志和审计还是比较粗浅的应用,如果有一天能够像SDN一样开放,出个Software Defined Security(SDS),那么就可以玩出更多的东西了,不知道安全业界能否接受这个概念.

  5. 新手0 于 2012-12-04 11:59 下午

    请教一下,为什么说“对于高校网络出口这种流量较大的应用场景来说,非队列模式显然更为适用”?
    主要是出自性能考虑吗?
    但是如果没有队列做缓冲的话,单纯的丢包会对TCP的延迟造成较大的影响吧?

  6. aa 于 2012-12-05 12:39 上午

    个人感觉写得很真实,很浅显,基本描述了当前流控产品的现状。小有受益。

  7. aa 于 2012-12-05 12:47 上午

    补充一点:对于文中提到的“应用路由需要搭配DNS重定向功能”来使用,个人认为技术上不可行,因为应用基本上是在完成DNS解析之后才被识别出来的,这时候应该就没有DNS重定向一说了吧?

  8. aaa 于 2012-12-05 5:38 下午

    1+1>2里还可以做用户行为分析,可以配合做精准营销、广告运营等工作

  9. 路人甲 于 2012-12-05 8:24 下午

    受益多多

  10. test 于 2012-12-06 12:49 上午

    之前听深圳某厂商的公开宣讲介绍,他们的加速设备在几年前就开始实现了楼主的观点。还表示客户使用效果很好。不知是否真实

  11. 爱看小小说 于 2012-12-06 10:55 上午

    做通信的一点感触:一定要从技术上清楚的知道自己维护的产品短板,问题在哪里,而且要正视这些问题才能合适的维护好产品稳定。因为永远没有一个产品是“银弹”能解决任何的问题。

  12. 老韩 于 2012-12-06 12:34 下午

    3楼路上同志,看到你网站上的机柜照片,咋墙还渗水涅……

  13. 路上 于 2012-12-06 8:50 下午

    老韩
    机房环境就是这个样子
    呵呵
    这个是小机房
    应用服务器机房没在这个位置
    毛工 估计看到 图片上面的深信服 估计都。。。。。。。。。。

    如果千兆骨干网搞成后就更换毛工的 千兆panabit

  14. 小白 于 2012-12-08 3:54 上午

    1.”….流控产品必须应具有通过控制上行流量来压制下行流量的机制,从而减小流量差,提高带宽利用率。”
    按照我粗糙理解的上行带宽控制在实现上无非是对上行的网口(outer interface) 做个出口控制. 换句话说最一组网口分别做两个出口控制.

    2.”流控引擎一般会采用TOKEN BUCKET机制,当TOKEN不够时,对当前数据包直接进行丢弃。其优点是系统压力小,占用资源少,并且基本上无延迟”
    我请教个问题, 采用tokenbucket机制对于控制的数据量有没有影响? 例如我有10k个用户 要保证每个IP平均分配带宽,

    3.”带宽保证/带宽借用也是流控产品中比较常见的功能. ….在高校、运营商等大流量环境中效果并不明显。”
    不明显是什么意思, 不起作用么?
    假如高校里我希望如下效果: 既要保证HTTP应用,游戏的流畅访问, 又不能让视频太卡, 又要下载速度在一个可以接受的范围, 同时我在卖给学生带宽的时候我承诺100*xk的带宽.
    如果遇到这样的需求流控怎么才能做到呢如何做到呢?

  15. 小白 于 2012-12-08 3:57 上午

    我补充下我说的第一点结论:
    如果实现了下行带宽控制, 自然就有了上行控制的方法,无非是对两个网口做控制。

  16. @小白 于 2012-12-10 11:01 下午

    “如果实现了下行带宽控制, 自然就有了上行控制的方法,无非是对两个网口做控制。”
    亲没理解毛公的意思,比如你的公网接口P2P流量很大,于是你控制了入站P2P的流量,于是从内网看到P2P下载确实小一半,但是不代表流控的wan口及其上游的P2P流量也减小一半,他们可能占用着原始的带宽,导致了你P2P虽然下载速度减半,但是P2P的实际占用带宽不变。

    所谓的控上行减下行,就是P2P有一个道德,就是没有上传的人,不给下载速度,于是流控设备会主动降低P2P对应的上传速度,让wan口上过来的P2P流量减小,不占用物理带宽,这是和TCP流控的最大区别

    那么控上行减下行,关键就在这个下行超标不是硬丢下行的包,而是主动减P2P上行的联动的过程

  17. Panabit 于 2012-12-13 5:50 上午

    道理很简单,P2P流量模型也是REQUEST-RESPONSE模型,有REQUEST才会有RESPONSE,REQUEST少了,RESPONSE自然也就减少。所以控制住REQUEST就自然控制了RESPONSE。控制效果如何主要就体现在对REQUEST以及特定P2P的REQUEST-RESPONSE的细致研究上。

  18. 新手0 于 2012-12-16 11:48 下午

    感谢panabit赐教,这么看来,做应用的流控就应该把重点放在对应用行为的分析上,而不是简单的照搬IP层流控的一些技术手段。