打卡10個4-7層網絡測試網紅指標（上篇）--云帆興燁
藝術來源于生活而高于生活；
測試來源于現網而苛于現網；
越嚴苛的測試才能盡最大的可能來保障我們日常生活中網絡的穩定。
在4-7層測試中，工程師們往往會關注多方面的性能指標來衡量被測設備的各維度能力。
可以說只要提到4-7層測試，某些測試指標就是注定無法繞開的網紅指標。今天我們就來聊一聊常用的四七層測試指標以及它們背后的意義。
1、CPS(Connections/Second) 新建連接數
CPS(Connections/Second)一般指TCP連接的新建連接數，也就是每秒鐘能夠成功建立的TCP連接數，是一種反映TCP連接建立速率的測試。主要考核被測設備CPU的處理能力以應對突發的搶購、搶票、大量用戶上線的服務器開服等場景。
如果是單純的新建連接數測試，一般需要被測設備具有快建快拆的能力。
以單純的新建連接數測試為例，在沒有Unsuccessful的情況下，每秒鐘新建連接數越高，并發連接數（Open）越低，說明被測設備處理能力越強。
圖1 截取自Avalanche Commander Run 頁面
2、CC(Concurrent Connections)并發連接數
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 Result——Client Real Time報告
圖4：Avalanche抓包文件，對應圖3 Action的配置
如果我們不使用Think參數來保持連接，而是在服務器側通過服務器延遲響應的方式來控制連接的時長，Avalanche模擬的服務器會在收到HTTP請求后等待Lantency的時間計時完成再回復響應數據，由于此時HTTP的會話也處于保持階段，因此采用這種方式來控制連接時長的方法我們稱之為七層并發。
圖5：截取自Avalanche Commander Server Transactions頁面
圖6：Avalanche抓包文件，對應圖5 Server Transactions的配置
3、TPS(Transactions/Second) 每秒事務數
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報告
4、Throughput 吞吐量
吞吐量一般指單位時間內成功地傳送數據的數量（以比特、字節、分組等測量）。一個系統的吞度量（承壓能力）與請求對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報告
5、Response Time 響應時間
響應時間——從字面的意義上來說是指從用戶發出請求到他們收到響應所花費的總時間。越短的響應時間意味著更高的性能和更優質的用戶體驗。然而總的響應時間往往是由很多的子系統的響應時間所構成的，如光模塊的光電轉換時間、數據在線纜上傳輸的時間、通訊設備處理的時間、應用程序處理數據的時間等，如何根據各個系統的子響應時間來排查優化子系統對于提升整體網絡性能是非常有意義的。
下面我們將為大家展開談一談Response Time的分類與解讀。
圖10：截取自Avalanche Commander Result——Client Summary報告
Page Response Time（頁面響應時間）：
等于從對index.html的第一個GET請求到接收到3.jpg的最后一個數據包所經過的總時間。
最小和最大頁面響應時間是發送的所有頁面的最小和最大響應時間。
平均頁面響應時間是總頁面響應時間除以總頁面數。
這意味著較高的頁面數可能仍然會導致較短的平均頁面響應時間
圖11：截取自Avalanche Commander Result——Client Summary報告
圖12：截取自Avalanche Commander Result——Client Summary報告
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報告