必看（1）打卡10个4-7层网络测试网红指标（上篇）

CPS(Connections/Second)一般指TCP连接的新建连接数，也就是每秒钟能够成功建立的TCP连接数，是一种反映TCP连接建立速率的测试。主要考核被测设备CPU的处理能力以应对突发的抢购、抢票、大量用户上线的服务器开服等场景。

如果是单纯的新建连接数测试，一般需要被测设备具有快建快拆的能力。

以单纯的新建连接数测试为例，在没有Unsuccessful的情况下，每秒钟新建连接数越高，并发连接数（Open）越低，说明被测设备处理能力越强。

图1：截取自Avalanche Commander Run 页面

CC(Concurrent Connections)并发连接数一般指在单位时间内，被测设备可以维持的已经建立成功的TCP连接数。比如某网络游戏同时在线几十上百万用户。就会产生几十上百万的并发连接数。并发连接数主要考核被测设备的内存处理能力。理论上来说，被测设备内存容量越大，可以维持的最大并发数就会越大。

在仪表的统计中Current Established TCP Connections就代表了并发连接数的指标。

图2：截取自Avalanche Commander Result——Client Real Time报告

在日常测试中，有时候我们会提到四层并发或者七层并发的概念，那么什么是四层并发，什么是七层并发呢？

以Avalanche仪表为例，如果我们使用Think方式来控制TCP的连接时长，Avalanche模拟的用户会在完成HTTP请求后等待Think时间（模拟用户浏览网页）计时完成后再关闭连接。

由于此时HTTP交互已经完成，只是TCP的连接在保持，因此这种方式我们称之为四层并发。

图3：截取自Avalanche Commander Client Actions页面

图4：Avalanche抓包文件，对应图3 Action的配置

如果我们不使用Think参数来保持连接，而是在服务器侧通过服务器延迟响应的方式来控制连接的时长，Avalanche模拟的服务器会在收到HTTP请求后等待Lantency的时间计时完成再回复响应数据，由于此时HTTP的会话也处于保持阶段，因此采用这种方式来控制连接时长的方法我们称之为七层并发。

图5：截取自Avalanche Commander Server Transactions页面

图6：Avalanche抓包文件，对应图5 Server Transactions的配置

TPS(Transactions/Second)每秒会话数一般指每秒钟HTTP事务成功的交互次数。对于服务器来说，如果TPS能力突出，则意味着服务器多线程处理能力优秀，反之，如果服务器的多线程处理能力不强，或者多线程处理效率较低，HTTP事务交互速率增加后可能会导致服务器负载过高，影响服务器的响应速度和服务质量。每秒会话数的处理能力直接关系到了并发连接数以及系统的吞吐量指标。每秒会话数的处理能力越强，并发连接数会越低，系统的吞吐量就会越大。

一般来说只有当1条TCP连接只传输一个事务时，CPS才会等于TPS，如果启用HTTP长连接功能，1条TCP连接传输多个事务，TPS就会是CPS的多倍关系。如下图所示，我们配置1条TCP连接传输4个HTTP事务，最终结果CPS和TPS就是1比4的关系。

图7：截取自Avalanche Commander Result——Client Real Time报告

吞吐量一般指单位时间内成功地传送数据的数量（以比特、字节、分组等测量）。一个系统的吞度量（承压能力）与请求对CPU的消耗、外部接口、IO等等紧密关联。单个请求对CPU消耗越高，外部系统接口、IO响应速度越慢，系统吞吐能力越低，反之越高。

图8：截取自Avalanche Commander Result——Client Real Time报告

系统吞吐量几个重要参数：TPS、并发数、响应时间；

在四七层测试中，除了要关注二层吞吐量。还需要关注应用层吞吐量。

所谓的应用层吞吐量Goodput(或Good throughput)，一般被定义为每单位时间内正确转发到被测设备或系统(DUT/SUT)目的接口的应用数据比特数，减去丢失或重传的比特数(RFC 2647)。这基本上是应用程序协议所看到的应用程序级吞吐量，不包括重传的任何TCP数据包。TCP/IP报头也不包括在内。

相对于传统网络设备来说，应用层网络设备不再简单的关注数据报文的转发，而更关注和应用协议相关的内容，如url解析，协议解析、应用特征识别、应用威胁识别等，并基于此开发相关的功能特性。针对这些特性，通常应用层网络设备都有各种各样的识别引擎，无论是哪一种算法，其核心的基本要求都需要把数据包解封装到OSI模型的应用层。而网络层设备以数据包转发为主要目的，只关心数据包转发能力，只需要解封到网络层，找到对应的路径信息即可。

数据包封装和解封的层次越多，CPU计算的负载就会越高，最终会直接体现在性能的衰减上。同样处理能力的CPU，处理网络层数据转发和应用层识别，所呈现的性能特性可能会截然不同，因此使用传统网络层性能指标来评价应用层设备的性能，实际上是有悖于真实的应用场景与测试需求的。

图9：截取自Avalanche Commander Result——Client Real Time报告

响应时间——从字面的意义上来说是指从用户发出请求到他们收到响应所花费的总时间。越短的响应时间意味着更高的性能和更优质的用户体验。然而总的响应时间往往是由很多的子系统的响应时间所构成的，如光模块的光电转换时间、数据在线缆上传输的时间、通讯设备处理的时间、应用程序处理数据的时间等，如何根据各个系统的子响应时间来排查优化子系统对于提升整体网络性能是非常有意义的。

下面我们将为大家展开谈一谈Response Time的分类与解读：

图10： 截取自Avalanche Commander Result——Client Summary报告

Page Response Time（页面响应时间）：

等于从对index.html的第一个GET请求到接收到3.jpg的最后一个数据包所经过的总时间。

最小和最大页面响应时间是发送的所有页面的最小和最大响应时间。

平均页面响应时间是总页面响应时间除以总页面数。

这意味着较高的页面数可能仍然会导致较短的平均页面响应时间。

图11： 截取自Avalanche Commander Result——Client Summary报告

图12：图11测试结果数据对应的抓包文件

URL Response Time（URL响应时间）：

从初始HTTP请求(例如，GET)到被请求的URL被完全检索的时间量（收到响应最后一个字节数据），以毫秒为单位，即TTLB(Time To Last Byte)。

对于没有设置Keep-Alive的HTTP 1.0，当从服务器接收到FIN时，将认为检索到了URL。

对于HTTP 1.1，当接收到响应头中声明的Content-Length总数的数据包时，将完全检索URL。

对于HTTP 1.1中的分块（CHUNK）传输，当服务器发送完时，数据被完全接收。

注意:即使您在Action列表中只有一个URL，页面响应时间也可能低于URL响应时间，特别是当您有重定向和不成功的交易时。

如果您只有一个URL并且交易100%成功，那么页面响应时间和URL响应时间应该匹配。

Time To TCP SYN/ACK：

从会话发出SYN报文到收到相应的ACK报文所花费的时间，单位为毫秒。

注意:如果下一跳MAC地址尚未被解析，该值可能包括解析下一跳MAC地址所花费的时间。

Time To First Data Byte：

初始HTTP请求(例如GET)和从服务器接收到第一个数据包之间的时间间隔，以毫秒为单位。

Estimated Server Response Time (ms) ：

估算的服务器响应请求所需的时间(以毫秒为单位)，从服务器收到HTTP请求的最后一个字节到服务器HTTP响应的第一个字节的时间间隔。该统计数据由以下公式得出:

Estimated Server Response Time (ms) =Time To First Data Byte减去两倍的Time To TCP SYN/ACK

注意:这是对服务器响应请求所需时间的估计。该公式旨在将网络损耗时间从等式中删除，以便生成仅包含服务器处理时间的时间。损耗时间是Time To SYN/ACK时间的两倍。当服务器响应第一个SYN请求的时间较短时，此公式最有效。

RTT：

从发送数据到接收该数据的ACK的时间量，以毫秒为单位。

图13： 截取自Avalanche Commander Result——Client Summary报告