再談弱網測試

在去年，寫過一篇手游弱網測試的文章，主要是介紹在客戶端，運用Network Emulator Tookit工具模擬弱網情況，進行相關的測試工作，在當時，這個方法較好的滿足了項目組弱網的專項測試工作。但最近發生了一個事情，導致了需要對弱網測試的方法更進一步探究，事情是這樣的：某天項目組在集中測試的時候，發現客戶端卡頓非常明顯，程序懷疑是弱網情況下，造成的客戶端卡頓。雖然事後排查證明，不是網路的鍋，但程序這邊希望QA可以把弱網加入到平時的測試工作中，而不是作為一個專項測試，只有在一些大版本的時候進行。

當然，我們依然可以運用Network Emulator Tookit工具，達到程序的期望，但我在想：為什麼平時測試的時候，沒有使用弱網測試呢，而只是作為一個專項測試來開展呢？一方面當然是，基礎的網路庫較為穩定，不需要我們時刻去測試；另一方面，還是由於測試環境的配置不夠自動化。雖然說Network Emulator Tookit工具的使用不算複雜，但畢竟需要QA手動去搭建，人嘛，都用惰性的，你們肯定懂的。所以這次研究的主要目的是，如何自動化的配置一個弱網測試環境，方便的將弱網測試加入到日常的測試工作中。

一般而言，app分為客戶端和server端，可以簡單的認為，弱網加在客戶端或者伺服器的測試效果是差不多的，都能起到模擬app在弱網情況下的效果。這次調研過程中，考慮過幾種不同的方案，有些沒有實踐，有些實踐了，下面我會針對每個方案簡單的說下思考過程和實踐過程。

第一種方法是利用Facebook的開源框架ATC。但需要自己搭建一個wifi，這和公司IT部門的安全指導相違背，同時，由於自己搭建的wifi存在物理距離上的限制，所以沒有採用這個方法。

第二種方法是設置手機wifi的默認網關屬性，將默認網關的值修改到某個linux寄主的網關，然後通過tc命令，對這台linux機器的網路進行流程式控制制，達到模擬弱網的效果。可惜的是，由於公司wifi不支持修改默認網關，所以失敗了。

第三種方法是設置sock5代理。

Windows系統下，通過Proxifier這個軟體，設置全局sock5代理，實際測試發現，當我通過Proxifier軟體，直接將sock5的代理設置成遠程的配置的代理伺服器後，一般的應用程序，比如chrome、音樂播放器等流程成功的走了設置的代理伺服器。此時我在代理伺服器上進行弱網設置，就達到了測試的目的。

但是很遺憾，對遊戲進行如上操作，確沒有到達預期的延遲效果。通過查看login進程的日誌，可以看到遊戲客戶端的登入ip的確顯示的是代理伺服器的ip，說明成功了。但是當我通過iftop去查看網卡流量的時候，發現遊戲內的通訊都不走代理了。這是為什麼呢？原來我們遊戲默認通訊（除了和login通訊是tcp）採用的是基於udp的協議，而很可惜，Proxifier這個軟體，在設置成系統全局代理後，只能轉發http、https、tcp協議，不支持udp協議。如果你測試的應用程序不是基於tcp的，那麼上述方法是可行的。

我們的app是支持網路協議切換的，即可以通過配置文件設置是基礎tcp還是udp的，默認是udp，當我將app的網路協議修改成tcp後，使用上述的方法實測可行。

當然還有一種方法，就是把Proxifier軟體換成另一個支持udp轉發的軟體，但目前筆者沒有找到，如果誰知道，也可以告訴我下。

手機端，通過設置wifi的http代理選項，可以開啟sock5代理（通過設置PAC文件，網上有較多攻略，這裡就不詳細介紹了）。但是很遺憾，運行遊戲，查看服務端的登入日誌，顯示沒有通過代理伺服器，但是打開微博、瀏覽器等，都顯示是通過代理伺服器訪問的。估計在手機端，也需要下載某個應用，開啟手機的全局代理，而不能簡單的在wifi屬性項中設置。

這裡要特別說明下sock5代理的。

如上圖，當我們開啟代理後，客戶端和服務端的通訊都是通過代理來訪問的，但這裡有幾個需要注意的幾個點是：

1：在代理伺服器（一般是linux）上，通過tc實現某個客戶端的流量限制，不可行。因為tc的流量限制一般發生在出隊列，而當客戶端的經過代理程序後，其ip就發生改變了，我們不知道改變後的ip是多少，所以也就不能針對某個客戶端設置一個流量限制了。當然了，你可以通過開N個不同埠的代理，每個客戶端連接不同的代理，然後在tc通過針對不通的埠的判斷，實現某個客戶端的流量限制。

2：既然不能通過linux上的tc去針對某個客戶端限速，那麼自然我們想到了，通過代理程序去實現，因為代理程序可以識別到不同客戶端的原始ip，目前實現的的代理程序中，能夠通過參數加上一個固定的延遲，還沒有實現類似tc那樣全面的模擬弱網的各種情況，這也是後面我需要去完善的。具體如何實現一個sock5代理的原理，網上有很多介紹，我也就不多說了。

如果你的app通訊是基於http的，那麼你也可以直接通過使用Charles這個成熟的軟體，實現我剛才說的。Charles可以在window、linux上運行，並開啟一個代理，你可以通過對其配置文件的修改，指定開啟代理的埠號，最終達到對指定客戶端實現弱網測試的要求。

第四種方法：修改客戶端的代碼或者配置文件，改變需要連接的伺服器ip，修改成某個linux機器，然後在這台linux機器上，通過iptable進行包轉發，同時配合tc，實現流量的控制，達到弱網的測試要求。這種方法，由於筆者對iptable不是很熟，而且時間有限，就沒有實際部署測試了。

第五種是方法直接在伺服器對應的linux上，使用tc。

這裡又可以分為三個小方法。

a：在對應的伺服器所在linux上，對所有的出口流量加一個弱網環境：

tc qdisc add dev eth1 root netem delay 100ms loss 1%

這樣所有連接到這個伺服器的客戶端都會加一個100毫秒的延遲和百分之1的丟包率。不過這個方法，首先你要確認好，你的伺服器所在的linux的出口網卡是哪個，其次當這台伺服器執行上述命令後，我通過xshell等工具連接控制linux的時候，也會收到弱網的影響，體驗不好。

b：對指定目標ip的流量進行一個限制：

tc qdisc del dev eth1 root

tc qdisc add dev eth1 roothandle 1: prio

tc qdisc add dev eth1parent 1:1 handle 10: netem delay 1s loss 2%

tc qdisc add dev eth1parent 1:2 handle 20: pfifo_fast

tc filter del dev eth1

tc filter add dev eth1protocol ip parent 1: prio 1 u32 match ip dst 123.58.160.153 flowid 1:1

這樣，所有目標ip是123.58.160.153，都會被加上延遲1秒，百分之2的丟包率。這裡有個問題，我們的伺服器是架設在外網的，也就是說客戶端通過公司內部wifi訪問這台伺服器的時候，顯示的ip都是同一個，即公司的統一出口ip。所以想通過這個方法對某一個客戶端設置一個弱網環境不可行。當然，可以通過把伺服器架設到內網，或者用4G訪問都可以繞過這個問題。

c：對指定埠的流量進行一個限制：

tc qdisc add dev eth1 roothandle 1: prio bands 4

tc qdisc add dev eth1parent 1:4 handle 40: netem delay 5s

tc filter add dev eth1protocol ip parent 1:0 prio 4 u32 match ip sport 5655 0xffff flowid 1:4

tc filter add dev eth1protocol ip parent 1:0 prio 4 u32 match ip sport 5656 0xffff flowid 1:4

通過指定的源埠，對流量進行一個控制，達到了弱網測試的目標。上面的5655 5656是我們伺服器提供對外服務的介面。所有的客戶端，會按照負載均衡的原則，連接不同的埠，我們可以通過對不通的埠附加不同的弱網策略，達到測試目的。

最終我採取的是上面c中提到的方法：對指定埠的流量進行一個限制，然後配合Jenkins達到一鍵配置弱網測試環境的效果。最終的執行界面是這樣：

QA點擊建置按鈕後，就能按照填寫的要求，構造一個弱網環境了。

當然，也可以簡單點，通過下拉選項選擇弱網環境，如下：

或者自己填寫相應的弱網參數：

通過上述介紹的這些方法，不管被測應用是何種性質的，應該都能實現弱網測試環境的搭建，如果不能，希望可以得到你的反饋，一起討論商量。

補充資料：

在運用TC對流量進行控制的過程中，對TC寫法的理解還是花費了一定的時間，我總結了下面的關鍵理解點：

TC分為隊列、類別、過濾器。過濾器對數據進行過濾，決定分配到哪個類別，每個類別對應一個隊列，隊列呢，是可以有限制的，比如帶寬啊，比如延遲啊。過濾器中就可以針對ip、埠去過濾到具體的某個類別中，然後這個類別是屬於某個隊列的，我在這個隊列設置中加了延遲，丟包等。最後根據TC的命令，其實畫出來的結構圖就是一顆樹。

接下去需要要完善的點：

1：加入帶寬的限制，用來模擬2G、3G、4G的情況。這個可以在TC中實現。

2：完善sock5代理程序，加入根據ip地址進行延遲設置和丟包率設置。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！