http://blog.csdn.net/wangbin579/article/details/8949315
基於server的請求回放領域，一般分爲離線回放和在線實時複製兩大領域，一般研究者都是從離線回放的角度在苦苦研究，而在實時複製領域，研究非常少，至少從sigcomm評審人的評審意見來看，沒有看到相關內容。
請求實時複製，據我所知，一般可以分爲兩類：
1）基於應用層的請求複製2）基於底層數據包的請求複製
傳統的做法一般從應用層面進行復制，比如基於服務器的請求複製，這種複製的好處就是實現起來相對簡單，但也存在着若干缺點：
1）請求複製從應用層出發，穿透整個協議棧，這樣就容易擠佔應用的資源，比如寶貴的連接資源
2）測試跟實際應用耦合在一起，容易導致對在線系統的影響，比如有些基於服務器的複製，會導致用戶請求的處理時間取決於最慢的請求處理時間（max(真正的請求處理時間，被複制的請求請求處理時間））
3）很難支撐壓力大的請求複製（據若干用戶反映，這種類型的請求複製，曾經嚴重影響在線系統）
4）很難控制網絡延遲
基於底層數據包的請求複製，可以做到無需穿透整個協議棧，路程最短的，可以從數據鏈路層抓請求包，從數據鏈路層發包，路程一般的，可以在IP層抓請求包，從IP層發出去，不管怎麼走，只要不走TCP，對在線的影響就會小得多。
因此從數據包的角度去做基於server的請求複製，方向是對的，而且潛力非常巨大，很可惜，tcpreplay的作者做了一點這方面的探索（flowreplay），就放棄了。這方面的研究至少我沒有看到過（一般都去研究整個網絡了，sigcomm評審人也沒有提出類似的研究方案）。
進入正題，tcpcopy是如何進行架構演化的呢？
三種架構的差別就在於在什麼地方截獲響應包
我們先看看tcpcopy最初的架構：
從上圖可以看出，tcpcopy是從數據鏈路層(pcap接口)抓請求數據包，發包是從IP層發出去，測試服務器的TCP協議棧沒有類似ip queue或者nfqueue的干擾，響應包會直接返回給在線機器（通過設置路由），tcpcopy可以在數據鏈路層捕獲到這些響應包，這些響應包會到達IP層，一般最終被丟棄掉（除非是客戶端IP地址就是這臺在線機器的IP地址，會通過IP層，但會被TCP reset掉）。
這裏要特別感謝tcpcopy鼻祖王波同學（@wbo65），是他在這方面進行了最初探索。
（2009年設計並代碼實現，僅僅300多行代碼就支撐了網易廣告投放系統的最初開發（上線零失誤，解決上線前數百個問題）,當然這個最簡單的版本應用範圍非常有限，本人也在2010年末在這個架構上面進行了深度改造，擴展到1000多行代碼，因此對tcp協議有了最初的認識）。
回到正題，這種架構一般只能工作在同一網段，而且對於外網應用，一般只能複製單臺在線流量給測試服務器，無法對網易廣告投放系統進行深度問題發現和潛能挖掘。
第一種架構總結如下：
好處：
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
最後，對於請求複製，要想達到對在線沒有影響或者影響儘可能小，可以採用如下對策：
利用高性能的旁路機制（如果採用鏡像，需要改客戶端數據包的目的地址），複製請求數據包到另外一個獨立的系統，在這個獨立的系統，我們採用第三種架構，進行請求的捕獲，再複製給測試服務器上面的應用。