流量管理 疏导为先——关于高校的流控技术应用

天使之泪

导读：
    随着P2P类应用越来越强烈的加密趋势，传统的基于应用协议数据特征的识别方式往往难以奏效，这就要求协议识别引擎能够对流量行为进行综合分析，根据统计特征、连接相关性等方面表现出来的蛛丝马迹判断应用的类型。　　随着教育信息化进程的不断加深，我国已建成规模庞大的教育网络，为高校提供了优越的接入条件。然而，日新月异的互联网应用吞噬着越来越多的带宽，校园网内终端接入数量也始终处于高速增长的态势，对高校网络的运维提出了新的挑战。在这种情况下，如何更合理地管理流量，为教科研任务提供更好的保障，成为各高校信息中心负责人普遍关注的问题。

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

协议识别走向立体化

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

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

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

发展中的流控技术

　　流控产品本身就因流量控制的需求而生，发展至今已经比较成熟。但在不断变化的应用需求面前，其功能与实现机制一直在进行调整，争取更好的优化与管控效果。目前，流控的核心理念已从传统的控制下行流量发展到对上行流量的控制。前者虽然易于实现，但仅对TCP流量有一定的效果（如调整TCP Window）。对于UDP流量来说，这种方式非但效果不明显，且易产生流量差，对带宽资源造成极大的浪费。考虑到目前占用带宽比例最大的网络视频和多数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处理所造成，而非安全业务。须要注意的是，应用路由及应用流量镜像的功能在流控产品上还不是很普及，它们的实现机制也会为设备带来额外的负载，对性能的影响比较大。所以建议教师们在进行评估选型的时候，更多地依据实际环境中的测试结果做出判断。
   
                                                                                                                                  作者：网纵CTO 毛守焱