异常测试之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 8080tcp 0 1 115.238.125.172:59038 115.238.125.169:8080 SYN_SENT 3692/curl

1. 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 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

1. 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 8080tcp 0 85 115.238.125.172:58986 115.238.125.169:8080 FIN_WAIT1 -
服务端抓包情况

由于iptables的配置，客户端主动reject掉服务端返回的syn ack

1. 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 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的好帮手，大家可以在日常的测试中实验一下，会有意外收获哦

免费领取验证码、内容安全、短信发送、直播点播体验包及云服务器等套餐

更多网易技术、产品、运营经验分享请访问网易云社区。

文章来源： 网易云社区