【測試環境】TCPCopy 使用方法

時間 2019-11-17

標籤測試環境 tcpcopy 使用方法简体版

原文原文鏈接

https://blog.csdn.net/ronmy/article/details/65657691mysql

TCPCopy是一種請求複製（全部基於tcp的packets）工具，能夠把在線請求導入到測試系統中去。目前此工具已經普遍應用於國內各大互聯網公司。git

TCPCopy七大功能
1）分佈式壓力測試工具，利用在線數據，能夠測試系統可以承受的壓力大小（遠比ab壓力測試工具真實地多）,也能夠提早發現一些bug
2）普通上線測試，能夠發現新系統是否穩定，提早發現上線過程當中會出現的諸多問題，讓開發者有信心上線
3）對比試驗，一樣請求，針對不一樣或不一樣版本程序，能夠作性能對比等試驗
4）流量放大功能
5）利用TCPCopy轉發傳統壓力測試工具發出的請求，能夠增長網絡延遲，使其壓力測試更加真實
6）熱備份
7）實戰演習（架構師必備）github

TCPCopy的特色
1）實時（離線經過configure --enable-offline)
2）效果然實
3）低負載，不影響在線
4）操做簡單
5）分佈式
6）零成本sql

TCPCopy使用方法
TCPCopy分爲TCPCopy client(即tcpcopy)和TCPCopy server(即intercept)兩部分。服務器

其中TCPCopy client運行在在線服務器上面，用來捕獲在線請求數據包；網絡

TCPCopy server（默認監聽端口爲36524）運行在測試機器上面，用來截獲響應包，並傳遞響應包頭信息給TCPCopy client,以完成TCP交互。session

TCPCopy使用分爲傳統使用方式和高級使用方式：架構

傳統使用方法：併發

TCPCopy server （root用戶執行）
採用IP Queue 模塊（內核<3.5，默認採用IP Queue）:
1）啓動內核模塊ip_queue運維

 
          modprobe ip_queue

2）設置要截獲的端口，而且設置對output截獲

iptables -I OUTPUT -p tcp --sport port -j QUEUE

3）運行intercept程序：

./intercept

intercept 經常使用參數：

-d 參數：能夠設置 tcpcopy，intercept 以 daemon 運行；

注意，測試完畢須要在測試設備上執行:

iptables -L --line
iptables -D OUTPUT 1 #刪掉 剛纔加入的規則

或者採用NFQueue 模塊（內核>=3.5，默認採用NFQueue）:
1）設置iptables：

 iptables -I OUTPUT -p tcp --sport port -j NFQUEUE

2）運行intercept程序：

./intercept

TCPCopy client （root用戶執行）

./tcpcopy -x 服務器應用端口號-測試服務器ip地址:測試服務器應用端口

tcpcopy 經常使用參數：

-x <transfer,>
Transfer 具體格式以下：
服務器對外IP地址 : 服務器應用端口號 - 測試服務器 IP 地址 : 測試服務器應用端口 tcpcopy -x 80-42.62.30.205:80

-n 參數：

若是你要進行多重複制，那麼此參數的值就是表明複製過去的流量是在線的n倍，倍數小，效果越好，由於多重複制的原理是修改端口號，所以複製的倍數越大，端口衝突的概越大，特別是源IP地址很是少，短鏈接的的內網應用場合。系統默認最大值爲 1023 倍。
舉例：

./tcpcopy -x 80-192.168.0.2:8080 -n 3

-r 參數：
若是你想複製在線服務器應用的部分流量，能夠採用-r參數來實現，參數範圍是1～99 ，其它值都是全流量複製。
舉例：

./tcpcopy -x 80-192.168.0.2:8080 -r 20    #複製20%的量

傳統使用方式注意事項：

（源代碼轉移到了github，敬請注意）

1）Linux平臺，內核2.6+，目前tcpcopy傳統架構須要支持netlink機制或者nfqueue(0.6.5版本+支持
nfqueue,在./configure指定nfqueue便可或者對於0.7.0+版本，若是內核爲3.5+,則自動採用nfqueue模式)

2）TCPCopy中的tcpcopy和intercept程序運行須要root權限

3）intercept在同一臺機器只須要運行一個實例就能支持多個應用的複製（設置多條iptables命令）

4）TCPCopy client須要鏈接測試服務器（默認36524端口），因此要對外開放相應端口

5）TCPCopy因爲依賴於抓包函數，壓力大的時候，抓包函數自己不可靠，因此會丟包，進而丟失請求

6）若是採用的是IP Queue模塊來截獲響應包，則intercept程序密切跟ip queue內核模塊相關，
因此當壓力很大的時候請求丟失率很高，須要優化sysctl系統參數才能達到好的效果
（經過cat /proc/net/ip_queue，查看ip queue運行狀況，若是Queue dropped的數值不斷增大，
則須要修改ip_queue_maxlen參數，好比echo 4096 > /proc/sys/net/ipv4/ip_queue_maxlen；
若是Netlink dropped的數值不斷增大，修改net.core.rmem_max和net.core.wmem_max參數,
好比sysctl -w net.core.rmem_max=16777216和sysctl -w net.core.wmem_max=16777216）

7）若是要複製127.0.0.1發出的請求到另一臺機器，須要設置-c參數

8）測試環境最好和在線環境一致，好比鏈接都保持keepalive

9）TCPCopy只與ip、tcp層的數據有關，若是請求驗證與tcp層以上的協議有關，則系統不能正常運行。
例如：mysql鏈接協議，因爲權限認證與tcp層上面的mysql協議有關，因此複製過去的請求會被目標測試
服務器認爲非法請求，這個時候須要針對mysql協議做具體針對性的處理，tcpcopy程序才能正常運行

10）多層架構環境下，測試系統必定要獨立，與在線系統沒有業務關聯，不然會影響在線

11）丟失請求率跟網絡情況有關，最好在內網內複製請求

12）本系統不支持域名，只支持ip地址

13）更多信息參考以下文檔
(http://tcpcopy.googlecode.com/files/TCPCopy_Manual_v0.9.6%28Chinese%29.pdf.pdf)

高級使用方式：
參考：
http://blog.csdn.net/wangbin579/article/details/8950282
http://blog.csdn.net/wangbin579/article/details/8994601
http://blog.csdn.net/wangbin579/article/details/10148247

TCPCopy架構和工做原理

基於server的請求回放領域，通常分爲離線回放和在線實時複製兩大領域，通常研究者都是從離線回放的角度在苦苦研究，而在實時複製領域，研究很是少。

請求實時複製，通常能夠分爲兩類：

1）基於應用層的請求複製
2）基於底層數據包的請求複製

傳統的作法通常從應用層面進行復制，好比基於服務器的請求複製，這種複製的好處就是實現起來相對簡單，但也存在着若干缺點：
1）請求複製從應用層出發，穿透整個協議棧，這樣就容易擠佔應用的資源，好比寶貴的鏈接資源；
2）測試跟實際應用耦合在一塊兒，容易致使對在線系統的影響，好比有些基於服務器的複製，會致使用戶請求的處理時間取決於最慢的請求處理時間（max(真正的請求處理時間，被複制的請求請求處理時間））；
3）很難支撐壓力大的請求複製（據若干用戶反映，這種類型的請求複製，曾經嚴重影響在線系統）；
4）很難控制網絡延遲；

基於底層數據包的請求複製，能夠作到無需穿透整個協議棧：

路程最短的，能夠從數據鏈路層抓請求包，從數據鏈路層發包，

路程通常的，能夠在IP層抓請求包，從IP層發出去；

無論怎麼走，只要不走TCP，對在線的影響就會小得多。

進入正題，tcpcopy是如何進行架構演化的呢？

tcpcopy架構已歷經三代，基本原理都同樣，本質是利用在線數據包信息，模擬tcp客戶端協議棧，欺騙測試服務器的上層應用服務。因爲tcp交互是相互的，通常狀況下須要知道測試服務器的響應數據包信息，才能利用在線請求數據包，構造出適合測試服務器的請求數據包，所以只要基於數據包的方式，不管怎麼實現（除非是tcp協議改的面目全非），都須要返回響應包的相關信息。

三種架構的差異就在於在什麼地方截獲響應包

咱們先看看tcpcopy最初的架構：

從上圖能夠看出，tcpcopy是從數據鏈路層(pcap接口)抓請求數據包，發包是從IP層發出去，測試服務器的TCP協議棧沒有相似ip queue或者nfqueue的干擾，響應包會直接返回給在線機器（經過設置路由），tcpcopy能夠在數據鏈路層捕獲到這些響應包，這些響應包會到達IP層，通常最終被丟棄掉（除非是客戶端IP地址就是這臺在線機器的IP地址，會經過IP層，但會被TCP reset掉）。

回到正題，這種架構通常只能工做在同一網段，並且對於外網應用，通常只能複製單臺在線流量給測試服務器，沒法對網易廣告投放系統進行深度問題發現和潛能挖掘。

第一種架構總結以下：
好處：
1）簡單，粗暴
2）適合冒煙測試
3）測試結果比較真實

很差的地方：
1）相對而言，會更加影響在線，由於響應包信息所有回給在線機器了（固然這種仍是比應用層面的請求複製，影響更小）
2）同一網段限制
3）對於外網應用，沒法充分利用或者很難充分利用多臺在線流量，從而沒法爲壓力測試提供技術支持
4）內網應用嚴重受限制，因請求的客戶端IP地址不能是被複制的在線機器的IP地址

第二種架構，也就是目前開源的架構，設計也是tcpcopy鼻祖王波同窗設計（2010年設計出來，2011.6月設計移交給多人,包括我），大體架構以下：

從上面圖中咱們能夠看出，tcpcopy默認從IP層抓包，從IP層發包，與第一種架構不一樣的是，咱們在測試服務器進行響應包的截獲，並經過intercept程序返回響應包的必要信息給tcpcopy。這種架構爲分佈式壓力測試提供了可能性，相比第一種架構，大大推進了tcpcopy的進化。

咱們先從響應包的截獲來分析，理論上，能夠在測試服務器的IP層或者數據鏈路層進行截獲響應包，咱們具體分析以下：

1）在數據鏈路層抓，正常狀況下，其響應數據包會返回給真正發起請求的客戶端，這會或多或少影響到客戶端的TCP（頻繁地reset）模塊，並且在壓力大的時候，會給交換機、路由器甚至整個網絡，帶來沒必要要的干擾。

2）在測試服務器的IP抓響應包，正好有netlink技術來解決上面的問題，netlink是一種用戶態進程與內核進行交互的技術，具體地咱們能夠利用內核模塊ip queue（內核3.5如下版本）或者nfqueue（內核3.5或者以上版本）來達到捕獲響應包的目的。

咱們採用了第二種方式，也即上圖中的IP層來截獲響應包，當響應包傳遞給intercept後，咱們就能copy到響應包信息的必要信息（通常爲TCP/IP頭部信息），傳遞給tcpcopy，咱們還能夠經過verdict告訴內核，該如何處理這些響應包，若是沒有設置白名單的話，就會在IP層丟棄掉這些響應包，這時候你是沒法利用tcpudmp來抓到這些響應包的（tcpdump工做在數據鏈路層）。

這種設計的好處就是能夠支持複製多臺在線流量到一臺測試服務器中去，咱們在intercept保留路由信息，知道響應包的相關信息該如何返回給哪個tcpcopy實例。然而這種架構，intercept會不一樣程度地佔用測試服務器的資源，並且ip queue或者nfqueue，並不必定可以高效工做，於是給測試，特別是高壓測試和短鏈接壓力測試，帶來了很大麻煩。

這種架構總結以下：
好處：
1）支持複製多臺在線流量
2）影響在線機器更小，由於通常只須要返回TCP/IP頭部信息

很差的地方：
1）較第一種更爲複雜
2）性能極限每每在ip queue或者nfqueue
3）intercept擴展性很差，受制於ip queue和nfqueue沒法支持多進程進行響應包的捕獲操做
4）intercept影響測試服務器的最終測試結果，特別是壓力大的時候
5）沒法對測試服務器進行完整測試（沒有覆蓋到數據鏈路層的出口）
6）運維不方便

第三種架構，以下圖：

上述架構，也即最新架構，是爲了極限測試的目的而設計的，把intercept的工做從測試服務器（test server）中offload出來，放到另一臺獨立的輔助服務器（assistant server，原則上必定要用同網段的一臺閒置的服務器來充當輔助服務器）上面進行截獲響應包，並且把原先從IP層捕獲響應數據包的工做轉移到從數據鏈路層抓響應包，這些改變大大下降了對測試機器的各類干擾（除了路由設置，其它已經沒有影響了），並且大大擴大了捕獲響應包的能力。固然這種測試也更加真實。

具體以下：

在運行上層服務的測試服務器test server上面設置路由信息，把待測試應用的須要被捕獲的響應數據包信息路由到輔助服務器assistant server 上面，在assistant server上面，咱們在數據鏈路層截獲到響應包，從中抽取出有用的信息，再返回給相應的tcpcopy。

爲了高效使用，這種架構推薦使用pcap進行抓包，這樣就能夠在內核態進行過濾，不然只能在用戶態進行包的過濾，並且在intercept端或者tcpcopy端設置filter（經過-F參數，相似tcpdump的filter），達到多個實例來共同完成抓包的工做，這樣可擴展性就更強，適合於超級高併發的場合。

這種架構須要的機器資源也更多，並且也變得更加難使用，須要瞭解tcp知識，route知識和pcap filter知識（相似於tcpdump過濾條件），所以推薦有條件的而且熟悉上述知識的人使用最新的架構。

須要注意的是，在某些場景，pcap抓包丟包率會遠高於raw socket抓包，所以tcpcopy出現大量「unsend:too many packets」的報警，請採用raw socket方式來抓包（tcpcopy採用./configure --enable-advanced，而intercept 採用./configure --enable-advanced --enable-pcap）。

總結以下：
好處：
1）更加真實
2）可擴展性更強
3）適合高併發場合
4）無ip queue或者nfqueue的各類限制
5）對測試服務器幾乎沒有任何性能干擾的影響
6）在運行服務的測試服務器，運維更加方便
7）不會隨運行服務的服務器崩潰而崩潰

很差的地方：
1）操做難度更大
2）須要的機器數量更多
3）須要的知識也更多
4）assistant server（運行intercept的機器）原則上必需要和測試服務器（test server）在同一個網段

上面三種架構均具備價值，目前開源出來的僅僅包括第二種架構和第三種架構，tcpcopy默認採用第二種架構，有條件的能夠採用第三種架構。

對於如何採用新架構，參考http://blog.csdn.net/wangbin579/article/details/8950282

最後，對於請求複製，要想達到對在線沒有影響或者影響儘量小，能夠採用以下對策：

利用高性能的旁路機制（若是採用鏡像，須要改客戶端數據包的目的地址），複製請求數據包到另一個獨立的系統，在這個獨立的系統，咱們採用第三種架構，進行請求的捕獲，再複製給測試服務器上面的應用。

官網地址 https://github.com/session-replay-tools/tcpcopy 裏面有包的下載地址、文檔和常見問題