打卡10個4-7層網(wǎng)絡(luò)測試網(wǎng)紅指標（上篇）--云帆興燁
藝術(shù)來源于生活而高于生活；
測試來源于現(xiàn)網(wǎng)而苛于現(xiàn)網(wǎng)；
越嚴苛的測試才能盡最大的可能來保障我們?nèi)粘Ｉ钪芯W(wǎng)絡(luò)的穩(wěn)定。
在4-7層測試中，工程師們往往會關(guān)注多方面的性能指標來衡量被測設(shè)備的各維度能力。
可以說只要提到4-7層測試，某些測試指標就是注定無法繞開的網(wǎng)紅指標。今天我們就來聊一聊常用的四七層測試指標以及它們背后的意義。
1、CPS(Connections/Second) 新建連接數(shù)
CPS(Connections/Second)一般指TCP連接的新建連接數(shù)，也就是每秒鐘能夠成功建立的TCP連接數(shù)，是一種反映TCP連接建立速率的測試。主要考核被測設(shè)備CPU的處理能力以應(yīng)對突發(fā)的搶購、搶票、大量用戶上線的服務(wù)器開服等場景。
如果是單純的新建連接數(shù)測試，一般需要被測設(shè)備具有快建快拆的能力。
以單純的新建連接數(shù)測試為例，在沒有Unsuccessful的情況下，每秒鐘新建連接數(shù)越高，并發(fā)連接數(shù)（Open）越低，說明被測設(shè)備處理能力越強。
圖1 截取自Avalanche Commander Run 頁面
2、CC(Concurrent Connections)并發(fā)連接數(shù)
CC(Concurrent Connections)并發(fā)連接數(shù)一般指在單位時間內(nèi)，被測設(shè)備可以維持的已經(jīng)建立成功的TCP連接數(shù)。比如某網(wǎng)絡(luò)游戲同時在線幾十上百萬用戶。就會產(chǎn)生幾十上百萬的并發(fā)連接數(shù)。并發(fā)連接數(shù)主要考核被測設(shè)備的內(nèi)存處理能力。理論上來說，被測設(shè)備內(nèi)存容量越大，可以維持的最大并發(fā)數(shù)就會越大。
在儀表的統(tǒng)計中Current Established TCP Connections就代表了并發(fā)連接數(shù)的指標。
圖2：截取自Avalanche Commander Result——Client Real Time報告
在日常測試中，有時候我們會提到四層并發(fā)或者七層并發(fā)的概念，那么什么是四層并發(fā)，什么是七層并發(fā)呢？
以Avalanche儀表為例，如果我們使用Think方式來控制TCP的連接時長，Avalanche模擬的用戶會在完成HTTP請求后等待Think時間（模擬用戶瀏覽網(wǎng)頁）計時完成后再關(guān)閉連接。
由于此時HTTP交互已經(jīng)完成，只是TCP的連接在保持，因此這種方式我們稱之為四層并發(fā)。
圖3：截取自Avalanche Commander Result——Client Real Time報告
圖4：Avalanche抓包文件，對應(yīng)圖3 Action的配置
如果我們不使用Think參數(shù)來保持連接，而是在服務(wù)器側(cè)通過服務(wù)器延遲響應(yīng)的方式來控制連接的時長，Avalanche模擬的服務(wù)器會在收到HTTP請求后等待Lantency的時間計時完成再回復(fù)響應(yīng)數(shù)據(jù)，由于此時HTTP的會話也處于保持階段，因此采用這種方式來控制連接時長的方法我們稱之為七層并發(fā)。
圖5：截取自Avalanche Commander Server Transactions頁面
圖6：Avalanche抓包文件，對應(yīng)圖5 Server Transactions的配置
3、TPS(Transactions/Second) 每秒事務(wù)數(shù)
TPS(Transactions/Second)每秒會話數(shù)一般指每秒鐘HTTP事務(wù)成功的交互次數(shù)。對于服務(wù)器來說，如果TPS能力突出，則意味著服務(wù)器多線程處理能力優(yōu)秀，反之，如果服務(wù)器的多線程處理能力不強，或者多線程處理效率較低，HTTP事務(wù)交互速率增加后可能會導(dǎo)致服務(wù)器負載過高，影響服務(wù)器的響應(yīng)速度和服務(wù)質(zhì)量。每秒會話數(shù)的處理能力直接關(guān)系到了并發(fā)連接數(shù)以及系統(tǒng)的吞吐量指標。每秒會話數(shù)的處理能力越強，并發(fā)連接數(shù)會越低，系統(tǒng)的吞吐量就會越大。
一般來說只有當(dāng)1條TCP連接只傳輸一個事務(wù)時，CPS才會等于TPS，如果啟用HTTP長連接功能，1條TCP連接傳輸多個事務(wù)，TPS就會是CPS的多倍關(guān)系。如下圖所示，我們配置1條TCP連接傳輸4個HTTP事務(wù)，最終結(jié)果CPS和TPS就是1比4的關(guān)系。
圖7：截取自Avalanche Commander Result——Client Real Time報告
4、Throughput 吞吐量
吞吐量一般指單位時間內(nèi)成功地傳送數(shù)據(jù)的數(shù)量（以比特、字節(jié)、分組等測量）。一個系統(tǒng)的吞度量（承壓能力）與請求對CPU的消耗、外部接口、IO等等緊密關(guān)聯(lián)。單個請求對CPU消耗越高，外部系統(tǒng)接口、IO響應(yīng)速度越慢，系統(tǒng)吞吐能力越低，反之越高。
圖8：截取自Avalanche Commander Result——Client Real Time報告
系統(tǒng)吞吐量幾個重要參數(shù)：TPS、并發(fā)數(shù)、響應(yīng)時間；
在四七層測試中，除了要關(guān)注二層吞吐量。還需要關(guān)注應(yīng)用層吞吐量。
所謂的應(yīng)用層吞吐量Goodput(或Good throughput)，一般被定義為每單位時間內(nèi)正確轉(zhuǎn)發(fā)到被測設(shè)備或系統(tǒng)(DUT/SUT)目的接口的應(yīng)用數(shù)據(jù)比特數(shù)，減去丟失或重傳的比特數(shù)(RFC 2647)。這基本上是應(yīng)用程序協(xié)議所看到的應(yīng)用程序級吞吐量，不包括重傳的任何TCP數(shù)據(jù)包。TCP/IP報頭也不包括在內(nèi)。
相對于傳統(tǒng)網(wǎng)絡(luò)設(shè)備來說，應(yīng)用層網(wǎng)絡(luò)設(shè)備不再簡單的關(guān)注數(shù)據(jù)報文的轉(zhuǎn)發(fā)，而更關(guān)注和應(yīng)用協(xié)議相關(guān)的內(nèi)容，如url解析，協(xié)議解析、應(yīng)用特征識別、應(yīng)用威脅識別等，并基于此開發(fā)相關(guān)的功能特性。針對這些特性，通常應(yīng)用層網(wǎng)絡(luò)設(shè)備都有各種各樣的識別引擎，無論是哪一種算法，其核心的基本要求都需要把數(shù)據(jù)包解封裝到OSI模型的應(yīng)用層。而網(wǎng)絡(luò)層設(shè)備以數(shù)據(jù)包轉(zhuǎn)發(fā)為主要目的，只關(guān)心數(shù)據(jù)包轉(zhuǎn)發(fā)能力，只需要解封到網(wǎng)絡(luò)層，找到對應(yīng)的路徑信息即可。
數(shù)據(jù)包封裝和解封的層次越多，CPU計算的負載就會越高，最終會直接體現(xiàn)在性能的衰減上。同樣處理能力的CPU，處理網(wǎng)絡(luò)層數(shù)據(jù)轉(zhuǎn)發(fā)和應(yīng)用層識別，所呈現(xiàn)的性能特性可能會截然不同，因此使用傳統(tǒng)網(wǎng)絡(luò)層性能指標來評價應(yīng)用層設(shè)備的性能，實際上是有悖于真實的應(yīng)用場景與測試需求的。
圖9：截取自Avalanche Commander Result——Client Real Time報告
5、Response Time 響應(yīng)時間
響應(yīng)時間——從字面的意義上來說是指從用戶發(fā)出請求到他們收到響應(yīng)所花費的總時間。越短的響應(yīng)時間意味著更高的性能和更優(yōu)質(zhì)的用戶體驗。然而總的響應(yīng)時間往往是由很多的子系統(tǒng)的響應(yīng)時間所構(gòu)成的，如光模塊的光電轉(zhuǎn)換時間、數(shù)據(jù)在線纜上傳輸?shù)臅r間、通訊設(shè)備處理的時間、應(yīng)用程序處理數(shù)據(jù)的時間等，如何根據(jù)各個系統(tǒng)的子響應(yīng)時間來排查優(yōu)化子系統(tǒng)對于提升整體網(wǎng)絡(luò)性能是非常有意義的。
下面我們將為大家展開談一談Response Time的分類與解讀
圖10：截取自Avalanche Commander Result——Client Summary報告
Page Response Time（頁面響應(yīng)時間）：
等于從對index.html的第一個GET請求到接收到3.jpg的最后一個數(shù)據(jù)包所經(jīng)過的總時間。
最小和最大頁面響應(yīng)時間是發(fā)送的所有頁面的最小和最大響應(yīng)時間。
平均頁面響應(yīng)時間是總頁面響應(yīng)時間除以總頁面數(shù)。
這意味著較高的頁面數(shù)可能仍然會導(dǎo)致較短的平均頁面響應(yīng)時間
圖11：截取自Avalanche Commander Result——Client Summary報告
圖12：截取自Avalanche Commander Result——Client Summary報告
URL Response Time（URL響應(yīng)時間）：
從初始HTTP請求(例如，GET)到被請求的URL被完全檢索的時間量（收到響應(yīng)最后一個字節(jié)數(shù)據(jù)），以毫秒為單位，即TTLB(Time To Last Byte)。
對于沒有設(shè)置Keep-Alive的HTTP 1.0，當(dāng)從服務(wù)器接收到FIN時，將認為檢索到了URL。
對于HTTP 1.1，當(dāng)接收到響應(yīng)頭中聲明的Content-Length總數(shù)的數(shù)據(jù)包時，將完全檢索URL。
對于HTTP 1.1中的分塊（CHUNK）傳輸，當(dāng)服務(wù)器發(fā)送完<CR><LF>0<CR><LF>
注意:即使您在Action列表中只有一個URL，頁面響應(yīng)時間也可能低于URL響應(yīng)時間，特別是當(dāng)您有重定向和不成功的交易時。
如果您只有一個URL并且交易100%成功，那么頁面響應(yīng)時間和URL響應(yīng)時間應(yīng)該匹配。
Time To TCP SYN/ACK：
從會話發(fā)出SYN報文到收到相應(yīng)的ACK報文所花費的時間，單位為毫秒。
注意:如果下一跳MAC地址尚未被解析，該值可能包括解析下一跳MAC地址所花費的時間。
Time To First Data Byte：
初始HTTP請求(例如GET)和從服務(wù)器接收到第一個數(shù)據(jù)包之間的時間間隔，以毫秒為單位。
Estimated Server Response Time (ms) ：
估算的服務(wù)器響應(yīng)請求所需的時間(以毫秒為單位)，從服務(wù)器收到HTTP請求的最后一個字節(jié)到服務(wù)器HTTP響應(yīng)的第一個字節(jié)的時間間隔。該統(tǒng)計數(shù)據(jù)由以下公式得出:
Estimated Server Response Time (ms) =Time To First Data Byte減去兩倍的Time To TCP SYN/ACK
注意:這是對服務(wù)器響應(yīng)請求所需時間的估計。該公式旨在將網(wǎng)絡(luò)損耗時間從等式中刪除，以便生成僅包含服務(wù)器處理時間的時間。損耗時間是Time To SYN/ACK時間的兩倍。當(dāng)服務(wù)器響應(yīng)第一個SYN請求的時間較短時，此公式最有效。
RTT：
從發(fā)送數(shù)據(jù)到接收該數(shù)據(jù)的ACK的時間量，以毫秒為單位。
圖13：截取自Avalanche Commander Result——Client Summary報告