故障定位的方法和装置的制造方法
【专利摘要】本发明提供一种故障定位的方法和装置，应用在第一网络设备上，所述方法包括：获取来自终端设备的业务报文；确定所述业务报文的协议类型；根据所述协议类型，按照预设格式对所述业务报文进行存储；当网络中发生业务故障时，基于存储的业务报文进行分析，对所述业务故障进行故障定位。应用本发明实施例，可以按照一定格式实时地保存网络中的业务报文，在网络中发生业务故障时，可以对这些业务报文进行分析，从而实现故障定位，与纯人工的故障定位方式相比较，可以减小故障排查范围，提高故障定位效率。
【专利说明】
故障定位的方法和装置
技术领域
[0001] 本发明涉及通信技术领域，尤其涉及一种故障定位的方法和装置。
【背景技术】
[0002] 在网络应用中，尤其是一些比较重要的网络应用中，业务报文的准确可达性尤为 重要，举例来说，在电网调度系统中，若在业务报文传输的过程中丢失部分业务报文，则在 进行电网调度时，从站就不能正确地理解主站命令，从而导致业务故障发生。
[0003] 然而，若采用纯人工方式进行业务故障排查，以实现故障定位，则排查范围较大， 且故障定位效率较低。
【发明内容】
[0004] 有鉴于此，本发明提供一种故障定位的方法和装置，以在进行故障定位时，减小排 查范围，提高故障定位效率。
[0005] 具体地，本发明是通过如下技术方案实现的：
[0006] 本发明提供一种故障定位的方法，所述方法应用在第一网络设备上，包括：
[0007] 获取来自终端设备的业务报文；
[0008] 确定所述业务报文的协议类型；
[0009] 根据所述协议类型，按照预设格式对所述业务报文进行存储；
[0010] 当网络中发生业务故障时，基于存储的业务报文进行分析，对所述业务故障进行 故障定位。
[0011] 本发明还提供一种故障定位的装置，所述装置应用在第一网络设备上，包括：
[0012] 报文获取单元，用于获取来自终端设备的业务报文；
[0013] 协议识别单元，用于确定所述业务报文的协议类型；
[0014] 第一存储单元，用于根据所述协议类型，按照预设格式对所述业务报文进行存 储；
[0015] 故障定位单元，用于当网络中发生业务故障时，基于存储的业务报文进行分析，对 所述业务故障进行故障定位。
[0016] 应用本发明实施例，可以按照一定格式实时地保存网络中的业务报文，在网络中 发生业务故障时，可以对这些业务报文进行分析，从而实现故障定位，与纯人工的故障定位 方式相比较，可以减小故障排查范围，提高故障定位效率。
【附图说明】
[0017] 图1是本发明一不例性实施例不出的一种应用场景不意图；
[0018] 图2是本发明一示例性实施例示出的一种故障定位的方法的流程示意图；
[0019] 图3是本发明一示例性实施例示出的一种故障定位的装置的所在设备一硬件结 构示意图；
[0020] 图4是本发明一示例性实施例示出的一种故障定位的装置的结构框图。
【具体实施方式】
[0021] 这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及 附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例 中所描述的实施方式并不代表与本发明相一致的所有实施方式。相反，它们仅是与如所附 权利要求书中所详述的、本发明的一些方面相一致的装置和方法的例子。
[0022] 在本发明使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本发明。 在本发明和所附权利要求书中所使用的单数形式的"一种"、"所述"和"该"也旨在包括多 数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语"和/或"是指 并包含一个或多个相关联的列出项目的任何或所有可能组合。
[0023] 应当理解，尽管在本发明可能采用术语第一、第二、第三等来描述各种信息，但这 些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离 本发明范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第 一信息。取决于语境，如在此所使用的词语"如果"可以被解释成为"在……时"或"当…… 时"或"响应于确定"。
[0024] 图1是本发明一不例性实施例不出的一种应用场景不意图。
[0025] 如图1所示，本发明实施例提供的故障定位的方法和装置的应用场景中，可以包 括终端设备a、终端设备b、交换机以及第一网络设备（比如，Unified Access Gateway， 统一访问网关，简称UAG)，其中，终端设备a和终端设备b可以是便携式移动设备、 PC (Personal Computer，个人计算机）或者服务器，交换机设置在终端设备a和终端设备b 之间，而第一网络设备采用旁路部署方式与交换机连接，从而获取终端设备a和终端设备b 之间传输的业务报文，并对业务报文进行相应的业务处理，比如，终端设备a和终端设备b 在进行通信时，通过业务报文进行应用交互，第一网络设备可以获取该业务报文，并识别业 务报文的协议类型，再根据协议类型存储获取到的业务报文，如此，在终端设备a和终端设 备b的所在组网（或者网络）中发生业务故障时，可以对该存储的大量业务报文进行分析， 实现故障定位，及时确定引起该业务故障的起因，从而及时解决该故障问题。
[0026] 为了使本技术领域的人员更好地理解本发明实施例中的技术方案，将结合以下附 图对本发明实施例中技术方案作进一步详细的说明。
[0027] 图2是本发明一示例性实施例示出的一种故障定位的方法的流程示意图。
[0028] 如图2所示，一种故障定位的方法，该方法应用在第一网络设备上，包括如下步 骤：
[0029] 步骤201，获取来自终端设备的业务报文。
[0030] 在本发明实施例中，第一网络设备可以采用旁路部署方式与交换机连接，当来自 终端设备的业务报文经过交换机时，交换机可以对业务报文进行镜像后发送给第一网络设 备，从而使第一网络设备可以获取到来自终端设备的业务报文。
[0031] 步骤202,确定业务报文的协议类型。
[0032] 在本步骤中，根据本发明一可选实施例，可以从业务报文中提取出报文特征，并判 断是否从预设的第一识别表中匹配到该业务报文的报文特征，其中，第一识别表包括不同 的报文特征与协议类型的对应关系，若匹配，则获取与该业务报文的报文特征对应的协议 类型。
[0033] 需要说明的是，本发明实施例中，业务报文的报文特征可以包括知名端口、四元 组（包括目的IP地址、源IP地址、目的端口和源端口）以及负载内容特征中的至少一个， 换言之，第一识别表可以包括知名端口与协议类型的对应关系，或者，四元组与协议类型的 对应关系，或者，负载内容特征与协议类型的对应关系，或者知名端口、四元组以及负载内 容特征中两个或者三个的任意组合与协议类型的对应关系，比如，知名端口和四元组的组 合与协议类型的对应关系，在此不再一一举例。具体而言，第一种可选实施例，即第一识别 表可以包括不同知名端口与协议类型的对应关系，本技术领域人员可以理解的是，知名端 口的端口号的范围从〇至1023,这些端口可以固定地分配给一些服务，例如，21端口分配 给 FTP(File Transfer Protocol，文件传输协议）服务、25 端口分配给 SMTP(Simple Mail Transfer Protocol，简单邮件传输协议）的服务、80或8080端口分配给HTTP (Hypertext Transfer Protocol，超文本传送协议）服务，当业务报文的端口号匹配到第一识别表中的 知名端口时，可以获取知名端口对应的协议类型，从而确定该业务报文的协议类型。如表1 所示，为不同知名端口与协议类型的对应关系：
[0034] 表 1
[0035]
[0036] 而上述第一种可选实施例，是对于知名端口而言，利用知名端口对应的协议类型 确定业务报文的协议类型，然而，有些协议类型没有固定端口（即不是基于知名端口进行 通信交互的），比如TCP (Transmission Control Protocol，传输控制协议），TCP是一种 面向连接的、可靠的、基于字节流的传输层通信协议，因此，第一种可选实施例将不能适用 TCP，为此，本发明提供了第二种可选实施例，即第一识别表可以包括不同四元组与协议类 型的对应关系，当获取到的业务报文的四元组与第一识别表中的四元组时，可以获取第一 识别表中四元组对应的协议类型，从而确定该业务报文的协议类型。如表2中所示，为不同 四元组与协议类型的对应关系：
[0037] 表 2
[0038]
[0039] 根据本发明的一可选实施例，本发明还提供另一种确定业务报文的协议类型的方 法，在此，称为第三种可选实施例，即第一识别表可以包括负载内容特征与协议类型的对应 关系，举例来说，HTTP的业务报文的请求行request line的请求方法字段，如get可以标识 HTTP协议中的消息请求类型，因此，可以将get作为HTTP报文的负载内容特征，并将get与 HTTP的对应关系存储到第一识别表中，当获取到的业务报文请求方法字段从第一识别表中 查找到（即携带get)时，确定该业务报文的协议类型为HTTP。总而言之，将从各类协议对 应的业务报文中提取出该协议特有的特征作为负载内容特征，并保存该负载内容特征与该 协议类型的对应关系，基于该对应关系，可以确定获取到的业务报文的协议类型，在此不再 举例。需要说明的是，上述实施例中表1和表2不出的第一识别表均为不例性的，本发 明不对此作限制。
[0040] 其中，知名端口、四元组以及负载内容特征中两个或者三个的任意组合与协议类 型的对应关系，与上述实施例相比，增加了对应关系中的匹配条件，比如，知名端口和四元 组的组合与协议类型的对应关系，较知名端口与协议类型的对应关系，增加了四元组的匹 配，即，业务报文的中的知名端口与四元组均能够从该组合对应的第一识别表中匹配到时， 才能确定该业务报文的协议类型，其具体匹配方式、第一识别表中的对应关系的表达等可 以参考上述实施例，在此不再一一赘述。
[0041] 步骤203,根据协议类型，按照预设格式对业务报文进行存储。
[0042] 根据本发明可选实施例，网络管理员或者技术人员可以预先在第一网络设备中 配置特定的协议类型，在此，称为预设类型，当第一网络设备获取到业务报文时，可以基于 该预设类型确定是否要对该业务报文进行保存，可选地，可以将业务报文转为pcap文件格 式，其中，pcap文件格式是bpf(Berkeley Packet Filter，柏克莱封包过滤器）保存原始 数据包的格式，在本发明实施例中，当步骤202中确定的业务报文的协议类型能够匹配该 预设类型时，可以按照pcap文件格式将该业务报文存储在本地内存中，或者，第一网络设 备可以与第二网络设备建立TCP连接，并通过该TCP连接将业务报文发送给第二网络设备， 第二网络设备为存储设备，第二网络设备接收到该业务报文后，将存储该业务报文，其中， 业务报文的预设格式也为pcap文件格式，具体来说，可以获取业务报文的数据域和头部信 息，并对获取到的这些数据内容添加 pcap报文头，将添加了 pcap报文头的数据内容再封装 到TCP报文中，将TCP报文发送给第二网络设备，以使第二网络设备以pcap文件格式存储 业务报文。在本发明实施例中，使用TCP连接对业务报文进行传输，可以保障业务报文的传 输的可靠性和完整性。
[0043] 步骤204,当网络中发生业务故障时，基于存储的业务报文进行分析，对业务故障 进行故障定位。
[0044] 当网络中发生业务故障时，可以基于存储的业务报文进行分析，从而实现故障定 位，举例来说，在客户端设备在向服务器发送请求后，客户端设备却没接收到服务器的响应 信息，此时，可以基于存储的客户端设备与服务器之间进行交互的业务报文，分析一定时间 段内网络中流量、带宽使用率或者对业务报文的收包情况等，若经分析发现在两者进行交 互的过程中，所在网络的带宽使用率高于了预设使用率，或者流量超过了预设流量，则可以 确定该业务故障是由于网络攻击行为引起的，再基于这些超过预设流量的业务报文的报文 特征等，可以确定网络攻击源。此外，由于步骤202的可选实施例中将业务报文以pcap文 件格式进行存储，因此，在本步骤中，可以结合网络数据包分析工具对pcap文件格式的业 务报文进行分析，比如tcpdump、wireshark等等，在对业务报文进行分析时，分析形式、分 析功能会更多样化，且基于pcap文件格式，网络数据包分析工具可以实现批量分析，因此， 可以提尚分析效率。
[0045] 应用本发明实施例，可以按照一定格式实时地保存网络中的业务报文，在网络中 发生业务故障时，可以对这些业务报文进行分析，从而实现故障定位，与纯人工的故障定位 方式相比较，可以减小故障排查范围，提高故障定位效率。
[0046] 根据本发明一可选实施例，一种故障定位的方法还可以包括：提取任一协议类型 的业务报文的字段数据（比如，包括但不限于字段内容、字段长度），对字段数据进行分析， 得到该字段数据的数据规律，并在预设的第二识别表中保存数据规律与协议类型的对应关 系。举例来说，RTMFP(Real Time Media Flow Protocol，实时流媒体协议）是一种可以让 使用Adobe Flash Player的终端用户之间直接连接并进行通信的协议，RTMFP的UDP首包 满足如下数据规律：其大小大于或者等于12字节，可以取前12个字节，以每4字节为一组， 假设分别为A、B和C，且A、B和C满足A~B = C，将满足该数据规律的协议确定为RTMFP，并 将这种数据规律与RTMFP的对应关系保存到预设的第二识别表中。
[0047] 基于上述可选实施例子，第一网络设备在获取到业务报文后，可以根据业务报文 的字段数据生成业务报文的数据规律，并判断是否能够从第二识别表中匹配到该业务报文 的数据规律，若匹配到，则获取该业务报文的数据规律对应的协议类型，从而确定该业务报 文的协议类型。
[0048] 应用上述可选实施例，若一些业务报文的报文特征提取较困难，则可以采用该可 选实施例，对该业务报文的协议类型进行识别，为这类报文提供一种可用的准确的协议识 别方法。
[0049] 根据本发明的另一可选实施例，一种故障定位的方法还可以包括当任一业务报文 的存储时间到达预设时间时，删除该业务报文。可选地，在存储该业务报文时，可以记录起 始时间，第一网络设备可以按照一定时间周期对存储的业务报文进行检查，当前检查时间 与起始时间的差值为存储时间，在存储时间大于或者等于预设时间时，将删除该业务报文。 举例来说，任一业务报文的起始时间为6月1日，第一网络设备的检查周期为15天，假设到 达第一个检查周期时，当前检查时间为6月15日，而预设时间为30天，此时，存储时间为15 天，小于预设时间，因此在第一检查周期时不删除该业务报文，而到达第二个检查周期时， 当前检查时间为6月30日，则存储时间为30天，等于预设时间，因此，删除该业务报文。在 本发明实施例中，存储业务报文的目的是在发生业务故障时，基于这些业务报文进行故障 定位，因此，不必要将所有时间段的业务报文进行存储，只需要存储任一个时间段内的业务 报文即可，比如，30天内的业务报文，因此，可以将存储时间超过30天的业务报文删除，这 样，能够节省网络设备的内存资源，减少存储空间耗费，当获取到任一个新的业务报文时， 将又根据图2所示实施例中的步骤对该业务报文进行处理，从而可以循环利用网络设备的 存储空间。本实施例中，关于起始时间、检查时间以及预设时间均为示例性，本发明不对这 些内容作限制。
[0050] 可选地，第一网络设备还可以对存储的业务报文的报文特征、存储状态、存储空 间、丢包情况以及自身的运行状态等进行实时显示，从而使网络管理员或者技术人员实时 了解网络环境、业务报文的存储情况和第一网络设备的运行情况等，可以理解的是，第一网 络设备也可以与外设显示设备连接，以在该显示设备上对上述数据信息进行显示，本发明 对此不作限制。
[0051] 与前述故障定位的方法的实施例相对应，本发明还提供了故障定位的装置的实施 例。
[0052] 本发明故障定位的装置400的实施例可以应用在网络设备上。装置实施例可以通 过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑 意义上的装置，是通过其所在网络设备的处理器将非易失性存储器中对应的计算机程序指 令读取到内存中运行形成的。从硬件层面而言，如图3所示，为本发明故障定位的装置所在 设备的一种硬件结构图，除了图3所示的处理器、内存、网络接口、以及非易失性存储器之 外，实施例中装置所在的网络设备通常根据该设备的实际功能，还可以包括其他硬件，对此 不再赘述。
[0053] 图4是本发明一示例性实施例示出的一种故障定位的装置的结构框图。
[0054] 如图4所示，一种故障定位的装置400,应用在第一网络设备上，包括报文获取单 元401、协议识别单元402、第一存储单元403以及故障定位单元404。
[0055] 报文获取单元401用于获取来自终端设备的业务报文。
[0056] 协议识别单元402用于确定所述业务报文的协议类型。
[0057] 根据本发明的可选实施例，协议识别单元402可以包括提取子单元、第一判断子 单元以及第一获取子单元，其中，提取子单元用于提取所述业务报文的报文特征；第一判断 子单元用于判断是否从预设的第一识别表中匹配到所述业务报文的报文特征，所述第一识 别表包括不同的报文特征与协议类型的对应关系；第一获取子单元用于当匹配到所述业务 报文的报文特征时，获取与所述业务报文的报文特征对应的协议类型。可选地，报文特征可 以包括知名端口、四元组以及负载内容特征中的至少一个。
[0058] 第一存储单元403用于根据所述协议类型，按照预设格式对所述业务报文进行存 储。
[0059] 根据本发明一可选实施例，第一存储单元403具体可以用于将所述业务报文转为 pcap文件格式，当所述协议类型匹配预设类型时，按照pcap文件格式将所述业务报文存 储在本地内存中，或者，当所述协议类型匹配预设类型时，在与第二网络设备建立TCP连接 后，通过所述TCP连接，按照pcap文件格式将所述业务报文发送给所述第二网络设备，以使 所述第二网络设备存储所述业务报文。
[0060] 故障定位单元404用于当网络中发生业务故障时，基于存储的业务报文进行分 析，对所述业务故障进行故障定位。
[0061] 根据本发明一可选实施例，一种故障定位的装置400还可以包括数据提取单元、 规律确定单元以及第二存储单元，其中，数据提取单元用于提取任一协议类型的业务报文 的字段数据；规律确定单元用于对所述字段数据进行分析，得到所述字段数据的数据规律； 第二存储单元用于在预设的第二识别表中保存数据规律与协议类型的对应关系。基于该可 选实施例，协议识别单元402可以包括规律生成子单元、第二判断子单元以及第二获取子 单元，其中，规律生成子单元用于根据所述业务报文的字段数据生成业务报文的数据规律； 第二判断子单元用于判断是否从所述第二识别表中匹配到所述业务报文的数据规律；第二 获取子单元用于当匹配到所述业务报文的数据规律，获取与所述业务报文的数据规律对应 的协议类型。
[0062] 根据本发明另一可选实施例，一种故障定位的装置400还可以包括报文删除单 元，用于当任一业务报文的存储时间到达预设时间时，删除该业务报文。
[0063] 上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的 实现过程，在此不再赘述。
[0064] 对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实 施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件 说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以 不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的 需要选择其中的部分或者全部模块来实现本发明方案的目的。本领域普通技术人员在不付 出创造性劳动的情况下，即可以理解并实施。
[0065] 以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精 神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明保护的范围之内。
【主权项】
1. 一种故障定位的方法，其特征在于，所述方法应用在第一网络设备上，包括： 获取来自终端设备的业务报文； 确定所述业务报文的协议类型； 根据所述协议类型，按照预设格式对所述业务报文进行存储； 当网络中发生业务故障时，基于存储的业务报文进行分析，对所述业务故障进行故障 定位。2. 根据权利要求1所述的方法，其特征在于，所述确定所述业务报文的协议类型，包 括： 提取所述业务报文的报文特征； 判断是否从预设的第一识别表中匹配到所述业务报文的报文特征，所述第一识别表包 括不同的报文特征与协议类型的对应关系； 若匹配到所述业务报文的报文特征，则获取与所述业务报文的报文特征对应的协议类 型； 所述报文特征包括知名端口、四元组以及负载内容特征中的至少一个。3. 根据权利要求1所述的方法，其特征在于，所述方法还包括： 提取任一协议类型的业务报文的字段数据； 对所述字段数据进行分析，得到所述字段数据的数据规律； 在预设的第二识别表中保存数据规律与协议类型的对应关系； 所述确定所述业务报文的协议类型，包括： 根据所述业务报文的字段数据生成业务报文的数据规律； 判断是否从所述第二识别表中匹配到所述业务报文的数据规律； 若匹配到，则获取与所述业务报文的数据规律对应的协议类型。4. 根据权利要求1所述的方法，其特征在于，所述根据所述协议类型，按照预设格式对 所述业务报文进行存储，包括： 将所述业务报文转为pcap文件格式； 当所述协议类型匹配预设类型时，按照pcap文件格式将所述业务报文存储在本地内 存中； 或者， 当所述协议类型匹配预设类型时，在与第二网络设备建立TCP连接后，通过所述TCP连 接，按照pcap文件格式将所述业务报文发送给所述第二网络设备，以使所述第二网络设备 存储所述业务报文。5. 根据权利要求1所述的方法，其特征在于，所述方法还包括： 当任一业务报文的存储时间到达预设时间时，删除该业务报文。6. -种故障定位的装置，其特征在于，所述装置应用在第一网络设备上，包括： 报文获取单元，用于获取来自终端设备的业务报文； 协议识别单元，用于确定所述业务报文的协议类型； 第一存储单元，用于根据所述协议类型，按照预设格式对所述业务报文进行存储； 故障定位单元，用于当网络中发生业务故障时，基于存储的业务报文进行分析，对所述 业务故障进行故障定位。7. 根据权利要求6所述的装置，其特征在于，所述协议识别单元，包括： 提取子单元，用于提取所述业务报文的报文特征； 第一判断子单元，用于判断是否从预设的第一识别表中匹配到所述业务报文的报文特 征，所述第一识别表包括不同的报文特征与协议类型的对应关系； 第一获取子单元，用于当匹配到所述业务报文的报文特征时，获取与所述业务报文的 报文特征对应的协议类型； 所述报文特征包括知名端口、四元组以及负载内容特征中的至少一个。8. 根据权利要求6所述的装置，其特征在于，所述装置还包括： 数据提取单元，用于提取任一协议类型的业务报文的字段数据； 规律确定单元，用于对所述字段数据进行分析，得到所述字段数据的数据规律； 第二存储单元，用于在预设的第二识别表中保存数据规律与协议类型的对应关系； 所述协议识别单元，包括： 规律生成子单元，用于根据所述业务报文的字段数据生成业务报文的数据规律； 第二判断子单元，用于判断是否从所述第二识别表中匹配到所述业务报文的数据规 律； 第二获取子单元，用于当匹配到所述业务报文的数据规律，获取与所述业务报文的数 据规律对应的协议类型。9. 根据权利要求6所述的装置，其特征在于，所述第一存储单元，具体用于： 将所述业务报文转为pcap文件格式； 当所述协议类型匹配预设类型时，按照pcap文件格式将所述业务报文存储在本地内 存中； 或者， 当所述协议类型匹配预设类型时，在与第二网络设备建立TCP连接后，通过所述TCP连 接，按照pcap文件格式将所述业务报文发送给所述第二网络设备，以使所述第二网络设备 存储所述业务报文。10. 根据权利要求6所述的装置，其特征在于，所述装置还包括： 报文删除单元，用于当任一业务报文的存储时间到达预设时间时，删除该业务报文。
【文档编号】H04L12/24GK105991353SQ201510447374
【公开日】2016年10月5日
【申请日】2015年7月27日
【发明人】郑言
【申请人】杭州迪普科技有限公司