基于流量监测的通信网故障分析技术研究

侯 浩，李伟娜，朱小朋，刘 丹

（西安卫星测控中心，陕西 西安 710043）

0 引 言

传统的网络性能评估指标[1]主要是IETF IPPM工作组定义的IP网络性能指标，包括：连通性、吞吐量、带宽、时延、时延抖动和丢包率等，常见的指标数据采集手段包括：基于ICMP协议的ping命令测试，可以得到连通性、时延、丢包率等指标数据；利用网络设备支持的SNMP MIB库可得到连通性、吞吐量、带宽等指标数据；利用网络测试仪可得到网络链路的连通性、带宽、丢包率、时延、抖动等指标数据。但是，上述性能测量方法缺少对特定业务场景流量特点的具体分析，性能评估的粒度粗，对实际业务传输质量进行评估时的指导性较弱[2]。

本文从网络流量特点出发，提取面向业务流的网络性能评估指标，采用关键节点设备的镜像监测网络流量，通过协议分析对业务流各指标项进行监测，进而实现通信网络中常见的UDP分片数据丢包、TCP高速数据速率下降等故障场景的监测告警[3]。

1 通信网络流量基线要素分析

1.1 企业通信网流量特点

目前，企业对网络的稳定性、时延、抖动等各项指标要求都比较高，特别是对于一些十分重要的业务，网络实时性、安全性显得十分重要且特别突出。根据企业网络运行的状况和业务数据，目前，大部分企业的网络流量多为基于UDP的业务和基于TCP的文件传输类型业务。基于UDP和TCP的业务，根据其工作原理和收发数据的机制来看，其网络流量类型都会表现出较强的规律性，使我们有章可循，能够通过发现内在规律判断网络的实时运行状况。目前，由于市场上企业类型的不同，网络要求也不同，企业通信网络流量监测的监视点、数据流颗粒度、业务测试内容和应用要求等方面关注点差异比较大，常规的网络性能评估指标对企业业务数据而言颗粒度过粗，如何精确、精细识别，需要我们一步研究[4]。

通过查询文献，邵国林等人研究提出了基于统计的流量结构的定义以及流量结构稳定性的相关描述，值得借鉴流量结构一定期间网络流量各属性值的大小、规模、分布及变化的综合状态，说明网络流量在特定时间内的统计特性和综合表现情况。流量和结构主要包括两层含义：各流量属性以及各属性的构成关系，对特定时间窗口内的流量统计属性进行描述，综合各属性值以及各属性在系统中的构成（所占比重）。流量结构稳定性，是对于一定时期网络流量结构的变动程度的刻画，表现了网络流量层面的稳定情况。该思路为我们提供了解决问题的办法[5]。

本文通过分析企业通信网络内业务的白名单，并利用基于时间序列的流量统计方法，对通信网内业务通信流量进行抓包监测，可发现其网络流量具有流量结构稳定性的属性，具体表现为数据包的包长分布、平均速率、TTL分布、端口分布、协议分布等方面，可据此构建网络基线[6]。

1.2 网络流量基线要素分析

网络基线包含来自不同终端设备的流量样本及统计属性，梳理网络流量白名单，构建网络流量基线，进而获得网络上每个设备节点的整体流量快照，在网络或设备工作不正常时作为比较的基准，成为监测网络故障的重要支撑数据[7]。

（1）使用的协议

在出口路由器上捕获网段所有设备的流量，对照流量白名单，分析是否缺少本应出现的协议，或者网络上是否出现了新的协议，从而发现高于正常数量的特定类型的流量。

（2）身份验证序列

各类应用程序的协议交互中，通常包括任意客户端到所有服务的身份验证过程的流量，比如Web应用程序、C/S消息交互软件，身份验证过程中通常包括丰富的通信参数协商信息，可用于协助定位该验证过程是否是通信缓慢的原因。

（3）数据传输率

在网络节点位置测量发送/接收的业务传输流量数据，确定传输速率和连接的一致性，每当在网段上建立或拆除连接速度很慢时，可以运行与基线同样的数据并比较结果，用于协助定位通信缓慢的原因。

（4）关联/依赖关系

通过特定场景的流量捕获构建网络基线，梳理各终端的业务关联/依赖关系，以及同一业务流上不同数据包的关联关系，利用关联关系基线协助定位终端引起的网络性能问题[8]。

2 面向业务层传输性能监测指标体系

2.1 网络性能指标体系构建

2.1.1 基于五元组的业务流描述

TCP和UDP流的定义可用如下定义进行描述。

定义1 拥有相同的四元组（源地址、目的地址、源端口、目的端口）的一系列在一定超时时间内（Ns）连续到达的TCP数据包，或以建立连接、断开连接为标记的区间时段内，称为一个TCP流。

定义2 在两个终端之间且拥有相同端口号的一系列在一定超时时间内（Ns）连续到达的UDP数据包，或以应用层开始、结束字段为标志的区间时段内，称为一个UDP流。

根据网络的业务传输特性，TCP流可以取建立连接、断开连接为标记的区间时段内的TCP数据包，UDP流可以取应用层开始、结束字段为标志的区间时段内的UDP数据包，基于五元组（源地址、目的地址、源端口、目的端口、协议）对不同的业务流进行分析[9]。

2.1.2 基于特定业务场景的流量性能评估指标分析

根据协议交互流程，按照TCP和UDP协议，可提取出如下指标，具体见表1～表3所列。

表1 UDP业务流中采集的指标

表2 TCP三次握手采集的指标

表3 TCP业务数据交互采集的指标

2.2 基于性能监测指标的故障分析

2.2.1 基于UDP协议的业务流丢包或丢失数据包分片算法

（1）算法概述

从UDP数据包中提取标识符（Identification）、标识（Flags）和分片偏移（Fragment Offset）。

（a）对于未分片的UDP数据包

比较同一网络路径上不同节点位置的抓包进行比较分析，判断同一标识符（Identification）是否均按预期路由出现，进而判断是否丢包。

在应用层数据字段中，存在用于标识数据包序号的字段，该字段值为递增取值，此种情况下，可通过同一节点位置的抓包数据进行该流前后数据包的对比，进而判断是否丢包。

（b）对于分片的UDP数据包

可采集标识（Flags），若为分片字段，则判断分片偏移（Fragment Offset）是否连续，进而判断是否丢失数据包分片。

（2）输入

接入设备入口、出口抓包流量；业务及链路已知参数：链路流量监管限速参数CIR、PIR、CBS（或令牌桶经验值），业务流参数源地址、目的地址、目的端口号、协议等。

（3）输出

通过分析，定位丢包的位置（时间，id，off），判断丢包的原因，归纳为以下3种：

①突发流量丢包：通过流量监管的限速参数CIR、PIR、CBS判定是否发生突发流量；

②设备已知缺陷：触发高危端口封控策略丢包；

③随机丢包：列出丢失IP数据包，进行人工分析。

（4）模型描述

①根据业务及链路约束参数（源地址、目的地址、目的端口号、协议；监管限速参数CIR、PIR、CBS）输入，提取UDP业务流Flow（time，id，off）信息。

②利用time和id修订两条UDP业务流Flow1和Flow2的抓包时间，time为抓包终端的时间；由于id最大值为65 535，因此同一条业务流在不同时间段存在id相同的情况，因此需要time和id两个参数来定位特定IP数据包。

③对比两条业务流的IP数据包id，判断Flow1（id，time）∈Flow2（id，time），若不成立，则说明存在丢包，转入⑤。

④对于分片数据包，判断 Flow1（id，，time，off）∈Flow2（id，time，off），若不成立，则说明有丢失分片，通过时间time、标示符id、偏移off判断IP数据包分片丢失发生的时间范围以及具体的数据包，转入⑤。

⑤判断是否为突发流量超过流量监管引发的丢包，若短时间（如20 ms）丢失多个分片，初步分析为突发流量丢包，可通过流量监管的限速参数CIR、PIR、CBS进一步判定是否发生突发流量，结束分析。

⑥判断是否为设备已知缺陷：触发高危端口封控策略丢包，若丢失的为IP分片包且第37、38字节与高危端口值相同，则为设备已知缺陷引发的丢包，否则转入⑦。

⑦判断为随机丢包，列出丢失IP数据包，进行人工分析。

UDP丢包问题分析算法流程如图1所示。

图1 UDP丢包问题分析算法流程

2.2.2 基于TCP协议的业务流降速算法

（1）算法概述

从TCP三次握手环节以及业务数据过程中可采集业务流相关性能指标，监测各指标值，与基准取值范围进行比较，分析线路侧、客户端、服务端引发故障的可能性。

（a）线路延迟导致降速故障监测

分析关联包时间间隔中的服务端发包间隔A（接收客户端SYN和发送SYN/ACK的时间间隔），当服务端收到客户端SYN数据包时，由于不涉及任何传输层以上的处理，因此发送一个响应只需要非常小的处理量。即使服务器正承受巨大的流量负载，通常也会迅速向SYN数据包响应一个SYN/ACK。这排除了服务器导致高延迟的可能性。因此基本可推断，延迟是因为线路中的一些设备出了问题。

往返时间（未启用延时确认情况下），若干秒内持续超过基准值，基本可推断线路或客户端存在问题；结合ICMP包采集往返时间（启用延时确认情况下），若干秒内持续超过基准值，基本可推断线路或客户端存在问题。

（b）客户端故障导致降速故障监测

分析关联包时间间隔中的服务端发包间隔A（接收客户端SYN和发送SYN/ACK的时间间隔），当客户端接收到三次握手的ACK后，应该很快就发送数据包，因为所有动作都是以客户端为中心的。延迟超过基准值，表明客户端无法及时执行该动作，基本可推断延迟的根源在于客户端自身[10]。

客户端接收到服务端发送的重复ACK后，未及时发送对应数据包，基本可推断客户端存在问题；网络未拥塞且服务端接收窗口足够大时，客户端仍未加大发送窗口时，基本可推断客户端存在问题。

（c）服务端故障导致降速故障监测

分析TCP业务数据交互过程中的接收窗口大小（服务端接收窗口*窗口扩大因子），当接收窗口若干秒内远低于基准取值范围时，基本可推断服务器端存在问题；若服务端可以同步抓包，通过分析服务端关联数据包的发包间隔A，同样可以判断是否为服务器端的问题[11]。

（2）输入

接入入口抓包流量；出口抓包流量；业务及链路已知参数：链路流量监管限速参数CIR、PIR、CBS（或令牌桶经验值），业务流参数源地址、目的地址、目的端口号、协议等[12]。

（3）输出

通过服务器端重复的ACK确认数量以及客户端发送的数据包id，统计丢包数量，通过分析定位丢包的位置（时间，id，off），判断丢包的原因，归纳为以下4种：

①抓包区间，定位引发丢包的单点设备；

②传输层或服务器端网络质量问题：与服务器端测试传输层链路质量，协调应用方协助定位丢包位置；

③客户端数传软件存在问题：服务器端接口窗口正常，但客户端仍未加大发送窗口时，基本可推断客户端数传软件存在问题；

④服务器端数传软件存在问题：网络空闲但服务器端接收窗口若干秒内远低于基准取值范围时，或ACK确认不及时，基本可推断服务器端存在问题。

（4）模型描述

①根据业务及链路约束参数（源地址、目的地址、目的端口号、协议；监管限速参数CIR、PIR、CBS）输入，提取TCP业务流Flow（time，id）信息。

②若Flow1中，服务端发送的重复ACK超过阈值，初步判断链路中存在丢包，转入③。

③客户端发送重复对应ACK数据包，则判定为客户端软件问题，结束判断。

④若服务器端不再发送对应ACK，则判断为网络偶发丢包，若丢包次数未超过阈值，则为偶发丢包，转入⑤，反之判断为网络频发丢包，转入⑦，继续分析。

⑤判断是否为网内存在丢包问题，若Flow1（id，time）∈Flow2（id，time）不成立，则为网内丢包，缩小测抓包区间，定位引发丢包的单点设备，否则转入⑥。

⑥判断为传输层链路存在丢包问题，协调应用中心协助定位丢包位置，结束分析。

⑦网络质量问题，与应用方测试传输层链路质量，结束分析。

⑧判断是否已降速：“数传速率＜经验值”且“链路利用率＜经验值”，若重复ACK超过阈值，则转入②；反之转入网络质量正常，初步判定数传软件功能故障，转入⑨。

⑨判断是否为客户端数传软件存在问题：若服务器端反馈的接收窗口正常，但客户端仍未加大发送窗口时，基本可推断客户端存在问题，结束分析，反之转入⑩。

⑩判断是否为服务器端数传软件存在问题：网络空闲但服务器端接收窗口若干秒内远低于基准取值范围时，或ACK确认不及时，基本可推断服务器端存在问题，协调应用中心进行进一步定位[13-15]。

TCP降速问题分析算法流程如图2所示。

图2 TCP降速问题分析算法流程

3 结 语

本文首先对网络性能评估指标研究现状进行阐述，结合网络流量特点，构建面向业务层传输性能监测指标体系，以UDP业务流丢包、TCP业务流降速等常见故障为案例，实现故障监测机理分析与故障监测告警[16-17]。