关键应用协议流分析
在过去一期的 Flows 中我曾经提及一个基于 TCP 会话进行故障诊断的话题，那时我主要的观点是针对基于 TCP 的应用，TCP 连接才是直接承载应用程序数据交易的最小通道。如果存在异常，在相对应的 TCP 会话交易过程中一定有所表现。其实 TCP 只是承载应用层数据交易的一种常用的传输协议，从更广泛的意义上来讲，当我们把目光聚焦到关键应用上面时，我们看到的不再是一条物理链路，不再是一种孤立的协议，也不再是堆积成山的数据包，取而代之的是由 TCP、UDP 等承载协议和HTTP、SMTP、TNS 等等应用协议组成的协议流。
另外一方面，解决各种网络、应用故障的困难度今非昔比。网络和应用早已融合，不再各自孤立。大到业务应用系统的层次化、模块化，小到负载均衡等技术的使用，无一不是通过网络连接和承载的。在过去，应用只是网络上的一个节点，界限清晰可见。而如今，应用本身就是一张网上的一组节点。在这样的应用结构下分析问题，谁又能孤立的来看待网络和应用呢？现代应用是应用程序和网络的结合体。
所以我们深深感觉到，只有面向关键应用的流量才能真实描述问题现象，只有发生在关键应用、关键位置、关键时刻的数据包才能完全透析问题本质，这就是协议分析系统的核心价值所在。而当面向关键应用时，往往会发现，所有的数据不再是以包为单位的去审视，而必须以协议流的方法去深度观察。
大理（Dali）因此而生，它是一个具有全新视角的协议分析工具，面向关键应用向用户提供针对协议流的深度分析。
比如，一个用户在使用基于 Web 的应用，直接与他交互的是 HTTP 协议，而其承载协议是 TCP，那么这个用户的每一次操作都可以归纳成 HTTP 和TCP 组成的特定协议流。当我们从协议流的角度来看待这些流量数据，将获得的是用户与应用程序之间传输交易的过程和行为细节。
如下图所示，Dali 其中一项功能就是用交互式数据流图真实呈现一个网络流的数据交易过程。这里的网络流是指网络层会话过程，当然在这个过程里面汇集了网络层会话交互行为的细节数据和关键事件，比如在下图中，客户端在第一个 UDP 网络流中，进行了DNS 的查询，之后开始访问Web站点。其中一个会话，从TCP 三次握手时的响应时间来看网络延迟非常小，而红色字体显示的间隔时间数值就表明了服务器在开始返回用户请求的数据之前至少耽搁了 2.8 秒的时间。
网络流图
网络流或者说是网络协议流，在上面这个示例中更确切的说是 TCP 协议流的交易过程，能够同时体现网络层通信状况和应用程序的响应性。因为在一个 TCP 协议流中，我们可以获得传输层的关键数据，比如每个数据包的负载长度、窗口大小、是否有丢包、是否有重传等等这些数据我们可以用于判断网络层此时是否对用户体验产生了重要影响。同时，TCP 承载的是应用数据块，在TCP 协议流交易过程中的每一个数据包我们都能够用时间戳标记出来，所以就能够看到应用程序或者应用服务器是否有足够好响应性。
看上去拿一个网络协议流图就可以去分析、解决问题了，然而我们遇到的实际情况可能复杂的多。一个网络协议流只是整个应用操作流程中的一部分，要想完整描述用户访问应用的过程和行为还需要把一系列的网络协议流罗列在一起整体分析，或者直接采用应用协议流来分析。
Dali 设计的初衷是面向关键应用的， Web 是当前最常用的企业应用前端，因此 Dali 首先对HTTP协议进行了深度解析。再看下面的截图， Dali 分别按照用户所访问的站点， HTTP 的请求、响应数量，以及具体的每一次请求URL 来呈现应用访问的过程和行为。如下图所示，在这个时间段内，用户一共访问了三个站点，共发出了23 次HTTP GET 请求，获得了4 次重定以及26 次成功的响应，从详细列出的URL 中可以看出主要访问了netexpert.cn/dali 这个页面，并且下载了Dali 的exe 安装文件（红色箭头所示）。
HTTP 协议深度分析
Dali 通过应用层分析，完整呈现了应用层 HTTP 协议流交易过程，包括了每一次请求的 Web 站点和元素，及其响应状态，据此可以定位应用程序细节问题。同时应用层交易过程的重现也暴露了应用交互行为，在这个示例中用户访问了 Dali 主页，并且下载了Dali 的安装包。
对于问题分析来说，网络和应用协议流全面呈现了应用交易的过程和行为，这至关重要，这些过程和行为是反映问题本质的最有力证据，把握这些证据即找到了问题的关键所在。
有时我们也需要结合协议流与一些通用关键性能指标（KPI）在整体上进行分析。宏观上Dali提供一个通用的关键性能指标模块，这个模块包含有网络层以及应用层的一些关键性能指标，比如说反映TCP 状态的TCP SYN、FIN、RST 指标，反映响应时间的“间隔时间超阈值”指标，以及 HTTP GET、POST 等反映应用层响应性的指标。把协议流和这些关键性能指标结合起来，也是重现问题的一种重要途径。
比如下面这个案例，网络流按照发生的先后时间排列，看得到这个业务应用的模式具有如下特征：每15 秒向同时发起15 个TCP 连接，每个TCP 连接持续15 秒后终止。网络流持续时间在时序这一列里面直接用处于不同起始位置、不同长度的长条表示，如下图所示，在这个案例里面一次 15个TCP 连接的起始时间相同，持续的长度也相同，每 15 秒开始新的一轮。
按照时序排列的网络流
从关键性能指标里面也看到同样特征，TCP FIN 的统计显示，每隔15 秒有15 个连接终止，同样的，从TCP SYN 的统计可以看出，每隔15 秒，有15 个新连接建立。
按照时间轴排列的TCP FIN 指标历史曲线
上面是这个应用在正常状态下的协议流交易特征，可以看出只有站在协议流的视角上审视这个应用才能理解它的运行模式，这是一种概览全局的分析方法。而当这个业务发生了异常问题，就会直接反映到它的协议流交易特征上来。如下图所示，原本持续 15 秒的TCP 连接现在只持续3.1 秒就终止。
异常时的网络流时序排列
同时TCP 连接终止、建立的数量达到75 个，远远超出原本设计的15 个，而发生的时间区间也与每15 秒的设计相差甚远。
异常时的TCP FIN 指标历史曲线
在这个案例中，网络层面上没有丢包、重传等网络层异常现象。而通过对比正常以及异常时的协议流特征，所获得的信息全部显示是应用程序的异常导致了协议流交易模式的变化（TCP 连接的建立、终止、持续时间是应用程序主动控制的结果）。然而回过头来想一下，能够快速发现这个问题的根本原因，用协议流的视角分析问题的方法功不可没。如果只把精力放在数据包解码上面，恐怕只有一无所获了。
大理（Dali）是这样一个运用了面向关键应用和基于协议流分析理念的新工具。区别于协议解码的老传统，它大幅度改变了协议分析中对流的理解，正试图建立一个全新的协议分析视角，重新审视、描述并且发现应用交易的过程、行为之间的联系与影响，从而应对当前高度复杂的网络和应用故障诊断。
Ricky
Recent Comments