网络测试2版课件ch7

第7章应用层测试和故障诊断7.1应用层测试相关知识1．数据格式（1）原始数据原始数据即通过测试工具捕获的网络中实际传送的数据分组，并存储成专用的文件格式，如pcap或cap格式。（2）流格式数据借助于网络设备，将数据分组形成流记录，每条流记录包含源地址或目标地址、源端口号或目标端口号、端口标签或时间标签等信息。网络设备将流数据发送至专用分析测试平台进行数据存储。流存储节省了大量数据内容信息，大大压缩了原始数据量。2．应用协议分析中的关键技术（1）捕包（2）线速存储（3）海量存储（4）流量分类（5）协议和应用（6）异常事件的可视性（7）多级架构（8）点对点方式3．常用应用介绍（1）电子邮件1）SMTP三个基本路径。①MUA（MailUserAgent，邮件用户代理）通过SMTP将邮件发送给本地MTA（MailTransferAgent，邮件传输代理）（位于邮件服务器中）。②本地MTA查询所需投递域名的MX（MailExchanger）记录，如果位于本地服务器中，则传递给本邮件服务器的MDA（MailDeliveryAgent，邮件投递代理）；如果在异地，则通过SMTP将邮件发送到对端MTA。③对端MUA通过POP3将邮件接收到本地MUA。常用的SMTP命令和ESMTP命令命

令描

述HELO向接收方标记发送方MAIL初始化邮件传输RCPT标记邮件接收方DATA声明邮件数据开始（消息的主体）RSET中止当前的传输VRFY用于确认接收用户NOOP无操作QUIT关闭连接SEND使接收主机知道消息必须送到另一个终端命

令描

述EHLOHELO的扩展8BITMIME指明8位MIME传输SIZE限制消息的长度2）POP3POP（PostOfficeProtocol，邮局协议）是适用于客户-服务器结构的脱机模型的电子邮件协议，目前已发展到第3版（POP3）。POP3的工作过程如下。①服务器通过侦听TCP端口110开始POP3服务，当客户端主机需要使用服务时，与服务器主机建立TCP连接。②连接建立后，POP3发送确认消息。③客户端和POP3服务器相互交换命令和响应，此过程持续到连接终止。命

令描

述USER输入用户名PASS此命令若成功，将导致状态转换APOPDigest是MD5消息摘要STAT请求服务器发回关于邮箱的统计资料UIDL返回邮件的唯一标识符LIST返回邮件数量和每个邮件的大小RETR返回由参数标识的邮件的全部文本DELE服务器将由参数标识的邮件标记为删除RSET服务器将重置所有标记为删除的邮件TOP服务器将返回由参数标识的邮件前n行内容NOOP服务器返回一个肯定的响应QUIT删除标记的邮件（3）超文本传输协议目前使用的最为广泛的应用层协议是HTTP（超文本传输协议），其将HTML（超文本置标语言）文档从Web服务器传送到Web浏览器，是一种基于客户-服务器模式、面向事务的应用层协议，可以传送任意类型的数据对象。典型的HTTP事务处理过程如下：①客户端和服务器建立连接；②客户端向服务器提出请求；③服务器接受请求，并根据请求返回相应的文件作为应答；④客户端与服务器关闭连接。7.2应用层故障分类应用层故障的原因非常复杂，甚至有下层传递给应用层的故障。应用层故障大致可分为两类：①可用性类故障，即不能访问特定的服务；②性能类故障，如访问缓慢，时断时续等现象。7.2.1应用可用性类故障应用层测试和故障诊断时一般按以下步骤进行：①应用程序的配置；②进程是否异常（如处于高负荷状态导致无法及时响应）；③应用程序所需相关服务是否正常启用。1．网络基本服务DNS故障借助于Windows操作系统中自带的Nslookup工具可以查询主机名、MX记录和NS记录等。2．邮件认证故障SMTP在发送邮件时经常遇到不能通过认证的情况，除了密码错误外，主要原因是认证方式配置不匹配。ESMTP有三个认证方式：CRAM-MD5、PLAIN和LOGIN。不同的邮件服务器要求的认证方式可能不同，如果配置错误结果就会导致认证不通过。图（a）为运用Wireshark协议分析软件的TCP流功能还原指令流，图（a）为成功认证的情形，图（b）为LOGIN方式时错误口令的情形。7.2.2应用性能类故障以下列举5种常见的应用性能故障。1．代码效率问题2．分层服务环境中的访问故障对采用分层架构的网络进行故障排查是极其困难的，除非对所有服务器的流量进行监控。NPM、APM和BPM是三种不完全相同的应用分析方式。APM采用Agent技术，可以覆盖应用节点；NPM采用探针部署，可以覆盖网络节点；而BPM并不是前两者相加，因为它采取的方式是，以包的层面分析业务数据，覆盖应用节点和网络节点，实现网络与应用的关联，以业务为导向实现对全链路性能的监控。

NetSensor业务应用拓扑结构NetSensor负载量分析NetSensor延时（时延）和重传分析NetSensor网上银行详单3．资源用尽或匮乏导致访问缓慢服务器资源不足会导致访问性能下降，这类情况也可以借助NetFlow协议软件采集的数据和统计信息进行应用层分析4．网络设计缺陷导致服务器访问缓慢在此类网络中，网管人员需要监控不同区域内网络的流量，监控每个VLAN内的流量和协议分布，必要时在防火墙上添加策略，限制某些网段或某些应用的访问，还必须监测上行链路。5．病毒攻击导致整个网络应用变慢在网络主干链路（特别是与外部相连的广域链路）中，流量的组成情况异常复杂，需要进行高粒度分析，而NetFlow软件非常适合此类故障中的分析应用。从OutboundSymantec流量观察，测试期间，流量也是维持在210kbps左右，但使用者只有一个IP地址（91），而该地址没有分配给服务器，故判断该机器有可能中毒了。7.3应用层的测试和故障诊断7.3.1故障分析和排除环境中的测试1．部署方式进行分析前需要了解被测系统的大致情况，以确定如何部署测试工具和以何种方式进行分析。一般的Web访问可分为以下4个步骤。①DNS查找解析：客户端首先查找DNS服务器，然后通过DNS获取访问网站的IP地址信息，DNS将信息返回给客户端。②TCP连接建立：客户端和Web服务器建立连接。③服务器响应：服务器在接收到客户端请求后，通常会先运行处理后再传送数据。④数据传送：服务器将数据传送给客户端。在进行Web应用类故障分析时，要特别注意服务群的访问流程（又称为分层应用），如果采用的是多级架构的模式，由于Web应用是前端应用，后端还有其他服务器（如认证服务器或数据库服务器等），因此在进行分析时，需要同时捕获其他服务器的流量，合并后进行协同分析。另外，需要注意Web应用路径中相关设备的配置，如采用Cache（缓存）技术、镜像服务器技术和CDN（内容分发网络）技术等。在这类环境中测试时，需要在多个网络路径上部署探针以捕获数据。4个分析位置，对应4种不同的情形①分析位置1：分析重点是客户端是否存在问题，如DNS响应请求慢、客户端延时是否合理等。②分析位置2：分析重点是服务器是否存在问题，区分问题出在服务器还是网络中。③分析位置3：分析重点是数据包途经设备后是否存在内容变化或者延时变化。④分析位置4：分析重点是多级架构服务器中的数据流访问是否有异常。2．分析方法一般协议分析过程包括三个阶段：实时监控、捕获数据和事后分析。设备接入被测系统后，开始进行实时监控；在需要时进行捕包；捕包完成后，启用数据分析显示功能。分析Web应用类故障需要对网页的加载过程逐步进行详细分析。在DNS查询并返回结果后，客户端和服务器会进行3次握手建立TCP连接。在连接建立后，客户端会向服务器请求数据，一般HTTP服务器会向客户端回应其相应的HTTP报头和数据，当数据传输完毕后，客户端发送FIN关闭连接。假设测试仪接在客户端（分析位置1）通过在分析位置1和分析位置2部署测试仪，可以分析Web应用访问缓慢的原因。①如果客户端与服务器距离太远，将导致3次握手的时间过长，两者之间的路由器增多，数据包经过的路径增长会导致访问速度慢。②服务器响应时间过长。某些操作（如请求）中存在过多的页面脚本或图片等，会造成响应时间的增加，导致访问速度变慢。对比常态和故障时服务器的耗时比例，可以判断是否由于服务器问题而导致故障。如果测试仪处在分析位置3（相当于在网络传输路径上设置监控点）。在合并后的视图中显示了同一个数据帧经过不同网络设备传输后的情况，通过对比可以获知数据包有没有被改变和延时等信息。如果测试仪处在分析位置4（相当于在网络服务群中的传输路径上设置监控点）则可以监控经过不同服务器后的数据包变化情况。在分析时可以进行分层查看，如图7.31所示，将用户访问分为三层，每层实现不同的功能，并记录时间信息。这样，多级架构网络中的应用访问就变得可视了，可以清楚地了解每层中所消耗的时间。导致服务器变慢的因素可能包括：①

服务器资源不够，导致性能下降；②

服务器在等待后续服务器的响应；③

服务器处于其他基础应用服务等待中延时发生于第一层延时发生于第二层延时发生于第三层区别于测试仪处在分析位置3的情况，采用多级架构服务器时，数据包的对应关系不复存在。如果客户端请求Web服务器，而Web服务器继而访问数据库服务器，那么客户端同Web服务器之间的数据以及Web服务器和数据库服务器之间的数据通常只有时间上的关联，内容上的关联性可能很小。分析时需要将流程相关服务器进行手动关联，指定时间点后展现在同一视图中在故障定位时，如果已经获得了引起延时的位置，可以分析具体的访问流程。如果是因为某条数据库查询语句导致的，则有以下典型的可能性：①数据库检索对象为全局而非某一字段；②被查询内容没有建立索引；③数据库系统优化不够，如重复提交等。7.3.2监控网络运行场景中的测试1．部署方式应用层的流量监控比网络层的要复杂得多，其主要目的如下。①分析指定应用的响应时间和趋势，以及应用的组成和分布。②分析指定的事务过程，可能涉及不同的应用协议并同时进行分析。③分析行为和过程，评估访问效率。常用的应用层流量监控基于以下三种方式。①SNMP分析（基于RMON、RMONII提供应用层的相关信息）：是端口级的分析。②NetFlow分析（基于流）：是FDR和IP级分析。③

探针分析（基于原始数据）：是应用协议和应用级分析。（1）NetFlow分析NetFlow架构如图7.37所示。其中，NetFlow分析器和NetFlow源设备是NetFlow架构中的两个关键因素。判断Flow记录是否到期的4个原则如下。①当TCP连接完成（FIN）或被重置（RST）时，Flow记录将终止。②当缓存满时，删除多余的Flow记录。③如果Flow记录在一段时间内均为Idle状态，则认为该Flow超时，并将其从缓存中移除。④将长时间存在的Flow记录从缓存中移除。在默认情况下，Flow记录的生存时间不允许超过30min。路由器每秒检查一次缓存，若Flow记录的不活动时间超过15s或者Flow记录的活动时间超过30min，都将造成Flow记录在缓存中超时。具体时间可以根据需要进行配置。（2）探针分析为了从更深层次上了解网络，通常采用将探针部署在网络不同位置的方式，以获得原始数据。探针是泛指的概念，有Box架构或Server架构之分，有基于广域网和局域网之分，有基于本地存储数据和异地存储数据之分，有基于串行接入和基于旁路接入之分。2．分析方法（1）NetFlow分析①基于端口的网络流量监控②基于应用的网络流量监控（2）探针分析7.3.3性能评估场景中的测试1．部署方式应用层测试中，性能测试是非常重要的测试内容，分为应用性能仿真测试和功能仿真测试。应用层的性能测试是主动测试方式，可以根据测试需要定制各类仿真流量。此时，被测网络被视作黑盒，在其中注入不同的应用流，以获得在不同条件下被测网络对于各类激励流量的响应情况。在测试部署时，通过TrafficAgent（TA，流量代理）加TestCenter（TC，测试中心）的方式组成测试系统TA可以是网络设备，也可以是PC机或者服务器、测试工具等。TA负责执行测试过程并提交测试数据，TC负责下发测试要求并统计TA提交的数据。复杂的应用仿真系统在TA和TC的基础上还会扩展出UI（UserInterface，用户接口）、脚本代理（免安装TA）等。电信运营商网络的主动应用性能仿真测试系统示意图，TA分布在不同的数据中心、分支机构、小型分支、办公室等处，位于总部数据中心的TC则负责下发和收集测试数据，并进行汇总，获得全网的主动测试数据。2．分析方法应用性能测试主要有三种方法。（1）端到端的End-to-End测试

（2）端到端的End-through-End测试（3）端到端的Client-Server测试7.4应用层的测试和故障诊断案例7.4.1典型案例1：大型数据中心的网络访问异常状况分析NTM捕获的数据如图7.70所示，系统分析过程如下。（1）查看DLC低层情况①查看广播包：本例中是正常的。②查看流量趋势：本例中无明显异常（如流量突发或趋势变大）。（2）查看网络层数据观察流量最大的188和186服务器的数据流，分别如图7.71和图7.72所示。如果有以往的数据（如一个月前的相应数据），则可进行时间上的纵向比较。本例中从趋势图无法获得更详细的信息。（3）查看应用层统计单击进入应用层统计数据显示，如图7.73所示，发现存在大量错误，主要是401未认证错误。特别要注意的是，这类错误并不一定与网络访问缓慢有直接关系，可能是由于代码效率问题导致的，需要进一步细查，并做出优化。（4）应用流分析由于本次故障现象集中表现在访问速度慢或不能提供服务，因此对访问188服务器的流量进行分析，如图7.74和图7.75所示为其中流量最大的IP地址为93的客户端的过滤分析数据。故障状态下服务器访问延时数据正常工作时服务器访问延时数据由于NTM部署于服务器前端，可以认为处于同一位置，从有关数据和解码界面进行分析判断，数据POST请求已经到达NTM，那么可以认为也到达了服务器端口，基本可以判断访问速度慢或服务不可用的主要原因来自服务器。报文到达了服务器端口，但是服务器没有及时做出响应，需要应用服务软件开发人员进一步确认具体原因。7.4.2典型案例2：大型数据中心的网络流量监控和优化对于大型数据中心，经常需要对网络流量趋势进行分析，以了解网络中的流量成分，从而根据业务进行流量优化。①网络流量突发严重，需要进行错峰处理，做到削峰填谷。②网络流量中存在很大的背景流量，需要给出应用整改建议，同时定位耗用带宽大户。③关键网络设备的CPU利用率居高不下，响应时间增加或不响应，需要确认原因。BPC对存在问题的系统发出告警，并且通过企业微信告警平台给客户发送微信。客户收到告警后，可以进行处理。BPC发出告警140和141服务器响应率低140和141服务器各项指标的曲线图多维统计分析中，对异常交易类型的层层钻取新增服务器之后，从应用层视图明显发现响应时间降低，响应率提高多维统计分析中，重要业务类型响应率恢复正常，各台服务器响应时间和响应率也都处于正常值7.4.3典型案例3：大型数据中心复杂应用环境下的分析大型数据中心中经常需要进行多级应用架构的网络分析，特别是当客户端访问缓慢或提交表单数据响应时间长时，基于多级应用架构的分析尤为重要。部署于数据中心，旁路接在交换机上即可。通过镜像口设置将客户端IP地址为99、Web服务器（IP地址为5）、报表服务器（IP地址为3）、数据库服务器（IP地址为1）等数据导入测试仪。本