异常测试之Socket网络异常

前言

不知道大家在测试的过程中有没有发现关于异常测试这样一个特点： 无论是分散在功能测试中的异常用例还是规模相对较大的专项异常测试中，异常测试的用例占比虽然不大但是对于挖掘问题却扮演着十分重要的角色。

随着项目组微服务化的演变进程，服务间通过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

• 客户端访问服务端

root@asdfd-10796:~# 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

root@asdfd-10796:~# netstat -antp | grep 8080
tcp        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

• 客户端访问服务端

root@asdfd-10796:~# 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

root@asdfd-10796:~# netstat -antp | grep 8080
tcp        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

• 客户端访问服务端

root@asdfd-10796:~# 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

root@asdfd-10796:~# netstat -antp | grep 8080
tcp        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

• 客户端访问服务端

testroot@asdfd-10796:~# 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日志

root@asdfd-10649:~# tcpkill -i eth2 port 8080
tcpkill: listening on eth2 [port 8080]
115.238.125.172:60030 > 115.238.125.169:8080: R 3022358001:3022358001(0) win 0
115.238.125.172:60030 > 115.238.125.169:8080: R 3022358230:3022358230(0) win 0
115.238.125.172:60030 > 115.238.125.169:8080: R 3022358688:3022358688(0) win 0
115.238.125.172:60030 > 115.238.125.169:8080: R 3022358001:3022358001(0) win 0
115.238.125.172:60030 > 115.238.125.169:8080: R 3022358230:3022358230(0) win 0
115.238.125.172:60030 > 115.238.125.169:8080: R 3022358688:3022358688(0) win 0
115.238.125.169:8080 > 115.238.125.172:60030: R 1694916106:1694916106(0) win 0
115.238.125.169:8080 > 115.238.125.172:60030: R 1694916333:1694916333(0) win 0
115.238.125.169:8080 > 115.238.125.172:60030: R 1694916787:1694916787(0) win 0
115.238.125.169:8080 > 115.238.125.172:60030: R 1694916106:1694916106(0) win 0
115.238.125.169:8080 > 115.238.125.172:60030: R 1694916333:1694916333(0) win 0
115.238.125.169:8080 > 115.238.125.172:60030: R 1694916787:1694916787(0) win 0
115.238.125.172:60030 > 115.238.125.169:8080: R 3022360124:3022360124(0) win 0
115.238.125.172:60030 > 115.238.125.169:8080: R 3022360386:3022360386(0) win 0
115.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的好帮手，大家可以在日常的测试中实验一下，会有意外收获哦 >_<

本文来自网易实践者社区，经作者张雨授权发布。