異常測試之Socket網路異常
阿新 • • 發佈：2018-12-14
本文由作者張雨授權網易雲社群釋出。
前言
不知道大家在測試的過程中有沒有發現關於異常測試這樣一個特點： 無論是分散在功能測試中的異常用例還是規模相對較大的專項異常測試中，異常測試的用例佔比雖然不大但是對於挖掘問題卻扮演著十分重要的角色。
隨著專案組微服務化的演變程序，服務間通過http介面訪問的場景也越來越多，本文站在測試的角度，對與socket的網路異常測試場景進行了一下整理和模擬方法的實踐，拋磚引玉，歡迎大家提出更多更好的方法。
常見Socket網路異常型別
| 異常 | Exception型別 | 原因 | 場景 |
|---|---|---|---|
| connect timed out | java.net.SocketTimeoutException | Socket TCP建立連線時三次握手超時，如果建立連線的時間超過了設定的Socket連線的超時時間觸發TimeoutException異常 | 網路延遲、網路斷開、網絡卡異常、服務端效能、客戶端異常等等 |
| Read timed out | java.net.SocketTimeoutException | 如果輸入緩衝佇列RecvQ中沒有資料，read操作會一直阻塞而掛起執行緒，直到有新的資料到來並且已經超過了設定的讀超時時間時觸發 | 客戶端或者服務端程序崩潰、對方機器突然重啟、網路斷開等 |
| Connection refused | java.net.ConnectException | 訪問服務端IP不通或者埠服務沒有啟用 | 網路異常、服務down掉等 |
| Connection reset or connection reset by peer | java.net.SocketException | 客戶端或者服務端其中一方退出，但退出時並未關閉該連線，另一方仍然在從連線中讀資料則丟擲該異常（傳送的第一個資料包引發該異常Connect reset by peer | 服務端併發連線數達到負載主動斷開連線；客戶端關閉但服務端仍讀寫資料 |
網路異常場景構造實驗
通過上面對於異常場景原理的瞭解， 我們通過一些linux網路小工具結合tcp的連線建立流程依次製造異常，從而更好的瞭解上面這些異常~
服務端： tomcat server 8080
客戶端： curl
工具： iptables 、tcpkill
國際慣例，tcp三次握手非高清大圖
1. connect timed out
客戶端通過iptables 構造異常
這裡統一從出口進行流量的限制，大家也可以自己試下從入口方向做限制。
iptables -A OUTPUT -p tcp --syn --dport 8080 -j DROP
客戶端訪問服務端
[email protected]:~# curl http://115.238.125.169:8080 -v* About to connect() to 115.238.125.169 port 8080 (#0)* Trying 115.238.125.169... * Connection timed out* couldn't connect to host * Closing connection #0 curl: (7) couldn't connect to host
客戶端檢視socket狀態：SYN_SENT
[email protected]:~# netstat -antp | grep 8080tcp 0 1 115.238.125.172:59038 115.238.125.169:8080 SYN_SENT 3692/curl
2. Read timed out
客戶端通過iptables 構造異常
iptables -A OUTPUT -p tcp -m state --state ESTABLISHED --dport 8080 -j DROP
客戶端訪問服務端
[email protected]:~# curl http://115.238.125.169:8080 -v* About to connect() to 115.238.125.169 port 8080 (#0)* Trying 115.238.125.169...* connected* Connected to 115.238.125.169 (115.238.125.169) port 8080 (#0)> GET / HTTP/1.1> User-Agent: curl/7.26.0> Host: 115.238.125.169:8080> Accept: */*> * additional stuff not fine transfer.c:1037: 0 0* additional stuff not fine transfer.c:1037: 0 0* additional stuff not fine transfer.c:1037: 0 0 ......................* Recv failure: Connection timed out* Closing connection #0 curl: (56) Recv failure: Connection timed out
客戶端檢視socket狀態：ESTABLISHED
[email protected]:~# netstat -antp | grep 8080tcp 0 84 115.238.125.172:58986 115.238.125.169:8080 ESTABLISHED 3671/curl
客戶端抓包情況
當tcp連線完成syn-》syn ack後進入ESTABLISHED狀態， 而由於iptables的配置導致服務端之後返回的tcp報文被drop掉，服務端多次重傳後無ack返回，返回read time out
3. Connection refused
客戶端通過iptables 構造異常
iptables -A OUTPUT -p tcp --dport 8080 -j REJECT
客戶端訪問服務端
[email protected]:~# curl http://115.238.125.169:8080 -v* About to connect() to 115.238.125.169 port 8080 (#0)* Trying 115.238.125.169... * Connection refused * couldn't connect to host * Closing connection #0 curl: (7) couldn't connect to host
客戶端檢視socket狀態：FIN_WAIT1
[email protected]:~# netstat -antp | grep 8080tcp 0 85 115.238.125.172:58986 115.238.125.169:8080 FIN_WAIT1 -
服務端抓包情況
由於iptables的配置，客戶端主動reject掉服務端返回的syn ack
4. Connection reset by peer or connection reset
服務端通過tcpkill命令構造異常
tcpkill是一個網路分析工具集dsniff中的一個小工具，可用來輕量級斷開網路連線
tcpkill -i eth2 port 8080
客戶端訪問服務端
[email protected]:~# curl http://115.238.125.169:8080/test2 -v* About to connect() to 115.238.125.169 port 8080 (#0)* Trying 115.238.125.169...* connected* Connected to 115.238.125.169 (115.238.125.169) port 8080 (#0)> GET /test2 HTTP/1.1> User-Agent: curl/7.26.0> Host: 115.238.125.169:8080> Accept: */*> * additional stuff not fine transfer.c:1037: 0 0* Recv failure: Connection reset by peer* Closing connection #0 curl: (56) Recv failure: Connection reset by peer
服務端檢視tcpkill日誌
[email protected]:~# tcpkill -i eth2 port 8080tcpkill: listening on eth2 [port 8080]115.238.125.172:60030 > 115.238.125.169:8080: R 3022358001:3022358001(0) win 0115.238.125.172:60030 > 115.238.125.169:8080: R 3022358230:3022358230(0) win 0115.238.125.172:60030 > 115.238.125.169:8080: R 3022358688:3022358688(0) win 0115.238.125.172:60030 > 115.238.125.169:8080: R 3022358001:3022358001(0) win 0115.238.125.172:60030 > 115.238.125.169:8080: R 3022358230:3022358230(0) win 0115.238.125.172:60030 > 115.238.125.169:8080: R 3022358688:3022358688(0) win 0115.238.125.169:8080 > 115.238.125.172:60030: R 1694916106:1694916106(0) win 0115.238.125.169:8080 > 115.238.125.172:60030: R 1694916333:1694916333(0) win 0115.238.125.169:8080 > 115.238.125.172:60030: R 1694916787:1694916787(0) win 0115.238.125.169:8080 > 115.238.125.172:60030: R 1694916106:1694916106(0) win 0115.238.125.169:8080 > 115.238.125.172:60030: R 1694916333:1694916333(0) win 0115.238.125.169:8080 > 115.238.125.172:60030: R 1694916787:1694916787(0) win 0115.238.125.172:60030 > 115.238.125.169:8080: R 3022360124:3022360124(0) win 0115.238.125.172:60030 > 115.238.125.169:8080: R 3022360386:3022360386(0) win 0115.238.125.172:60030 > 115.238.125.169:8080: R 3022360910:3022360910(0) win 0
客戶端抓包情況
服務端在tcp連線建立後主動down掉連線
總結
其實socket的異常不僅限於次如Broken pipe、 Too many open files等，這些更多的是在壓力併發測試過程中容易出現，本文介紹的這些異常更多的適用於功能性異常測試中，是發現bug的好幫手，大家可以在日常的測試中實驗一下，會有意外收穫哦
免費領取驗證碼、內容安全、簡訊傳送、直播點播體驗包及雲伺服器等套餐
更多網易技術、產品、運營經驗分享請訪問網易雲社群。
相關文章：
【推薦】 從DevOps到Cloud Native，應用上雲姿勢全解鎖