原创:打码日记,欢迎分享,转载请保留出处。简介 在目前微服务的背景下,网络异常越来越常见了,而有一些网络异常非常模糊,理解什么情况下会导致什么异常,还是有一定难度的,为此我做了大量实验,来复现各种异常场景。
socket状态变迁图 先快速回顾下正常情况下TCP的交互过程与socket状态变迁,如下:
文章图片
三次握手
- 客户端调用connect函数,会发SYN包给服务端,客户端状态变为SYN_SENT,服务端收到后变为SYN_RECV,同时回复SYN+ACK包给客户端。
- 客户端收到SYN+ACK包后,变成ESTABLISHED状态,同时回复ACK包给服务端,并且客户端的connect函数执行完成。
- 服务端收到ACK包后,也变成ESTABLISHED状态,至此连接建立完成。
客户端会重发SYN包给服务端,服务端收到后会再次发SYN+ACK给客户端。
思考:如果最后一个ACK包没收到,会怎么样?
服务端会重发SYN+ACK包给客户端,客户端收到后会再次发ACK给服务端。
这里可以发现,TCP协议里面,重发都发生在没有收到ACK的场景,纯ACK确认包不会重发。
数据传输
- 客户端调用write函数,发送请求数据,服务端调用read函数,接收请求数据。
- 服务端请求处理结束,服务端调用write函数,返回响应数据,客户端调用read函数,接收响应数据。
write发的数据包,也是带有ACK标记的,不管与之前的ACK包哪个先到,服务端都会变成ESTABLISHED状态。
而如果ACK与数据包都到不了服务端,一段时间后,服务端SYN_RECV状态的Socket会自动关闭,且不回复任何包给客户端,可以发现这种场景下,客户端认为连接成功,而服务端根本就没有连接。
四次挥手
- 客户端调用close函数,会发送FIN包给服务端,状态变为FIN_WAIT_1,服务端收到后,回复ACK,且状态变为CLOSE_WAIT。
- 客户端收到ACK后,状态变为FIN_WAIT_2状态。
- 服务端调用close函数,也会发送FIN包给客户端,状态变为LAST_ACK,客户端收到后,回复ACK,且状态变为TIME_WAIT。
- 服务端收到ACK后,Socket被操作系统回收,客户端的TIME_WAIT状态Socket在等待2MSL后,也被操作系统回收。
这时服务端会变成FIN_WAIT_2,这个状态也是有超时时间的,如果对方一直不发FIN过来,操作系统就会回收掉这个Socket,而客户端会一直是CLOSE_WAIT状态。
所以如果CLOSE_WAIT状态很多,一般是程序漏写了关闭Socket的代码。
从上面的状态变迁图,也可以推断出,绝大多数情况下,
SYN_SENT
、SYN_RECV
、FIN_WAIT_1
、LAST_ACK
状态应该很少,除非网络很卡,因为这些状态只要一收到了ACK就转变成其它状态了!ok,上面是TCP正常流程,下面以Java网络异常为例,讲讲各种异常情况!
常见网络异常场景 连接超时
发生异常:java.net.SocketTimeoutException: connect timed out
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:589)
【常见的Socket网络异常场景分析】这个异常原因是,客户端connect建立连接时,服务端一直没收到SYN包,超过了设置的连接超时时间后,就会报此异常。
文章图片
还可能是,服务端收到了SYN包,但SYN+ACK一直发不到客户端,也会报此异常。
文章图片
连接拒绝
发生异常:java.net.ConnectException: Connection refused (Connection refused)
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:589)
这个异常原因是,当服务端没有程序监听某个端口时,客户端却又试图connect连接这个端口就会出现此异常,其本质是服务端回复了一个RST包。
文章图片
注:RST包就是TCP协议中用来处理异常情况的,一般接收方收到RST包后,会直接回收Socket资源而不经过四次挥手过程。read读取超时
发生异常:java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
at java.net.SocketInputStream.read(SocketInputStream.java:171)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
当socket.read()读对端数据时,等待数据超时了,则会报
Read timed out
读取超时异常。- 服务端处理太慢
文章图片
- 网络卡了,数据包一直传输不过来
文章图片
socket.setSoTimeout()
来修改这个超时时间,注意理解这个超时时间,它不是整个读取过程时间,而是无任何数据通信的空闲时间。write重传超时
一般来说,由于socket有写缓冲(send buffer),write方法是不阻塞立即返回的,但如果write大量数据(如文件上传),当send buffer用完时write方法还是会阻塞的。
不管write方法是否阻塞,数据多次重传失败,会导致异常,区别是阻塞write被异常打断,而没有阻塞write时,会在下一次write时抛异常。
文章图片
对于这种情况的异常信息,不同的操作系统表现不一样,如下:
- Linux上,抛如下异常,且会同时会关闭本端Socket,不给对端发任何包。
发生异常:java.net.SocketException: Connection timed out (Write failed) at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:111) at java.net.SocketOutputStream.write(SocketOutputStream.java:143)
- Windows上,抛如下异常,且会同时会关闭本端Socket,不给对端发任何包。
发生异常:java.net.SocketException: Connection reset by peer: socket write error at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:111) at java.net.SocketOutputStream.write(SocketOutputStream.java:143)
对于重传的次数,Linux上默认15次,可通过内核参数net.ipv4.tcp_retries2
配置,而Windows上默认5次,可通过注册表项TcpMaxDataRetransmissions
配置。
Connection timed out (Write failed)
异常或Connection reset by peer
异常(Windows上)。读写时收到对方RST包
一般来说,如果对端机器上连接不存在了,还调用write往其发数据包,对方会回复RST包来终止连接。
文章图片
注:那什么时候会出现连接不存在呢?如机器直接断电后重启,或网络包被路由到了错误的机器上等,都会使得机器上没有相应的TCP连接。而当阻塞在write/read时,收到了对方的RST包,或先收到对方的RST包,再write/read时,就会报
Connection reset
异常。 文章图片
文章图片
如果对端机器上连接不存在了,本端连续调用write/read时,在不同操作系统上会产生不一样的异常序列,如下:
- 在Linux或Windows上先write,然后一直read,表现如下:
# 第一次write,调用正常,对端返回RST包# 第二次read,抛connection reset异常: 发生异常:java.net.SocketException: Connection reset at java.net.SocketInputStream.read(SocketInputStream.java:210) at java.net.SocketInputStream.read(SocketInputStream.java:141)# 第三次read,抛connection reset异常: 发生异常:java.net.SocketException: Connection reset at java.net.SocketInputStream.read(SocketInputStream.java:210) at java.net.SocketInputStream.read(SocketInputStream.java:141)
- 在Linux上一直write,表现如下:
# 第一次write,调用正常,对端返回RST包# 第二次write,抛connection reset异常: 发生异常:java.net.SocketException: Connection reset at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:115) at java.net.SocketOutputStream.write(SocketOutputStream.java:143)# 第三次write,抛broken pipe异常: 发生异常:java.net.SocketException: Broken pipe (Write failed) at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:111) at java.net.SocketOutputStream.write(SocketOutputStream.java:143)
- 在Windows上一直write,表现如下:
# 第一次write,调用正常,对端返回RST包# 第二次write,抛Connection reset by peer异常: 发生异常:java.net.SocketException: Connection reset by peer: socket write error at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:111) at java.net.SocketOutputStream.write(SocketOutputStream.java:143)# 第三次write,抛Connection reset by peer异常: 发生异常:java.net.SocketException: Connection reset by peer: socket write error at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:111) at java.net.SocketOutputStream.write(SocketOutputStream.java:143)
Connection reset
异常,同时也可能导致Broken pipe
异常。对方关闭连接后依然读写
如果对方调用close关闭了连接,本端再调用read或write方法读写数据会怎么样呢?
如果首次是read调用,Linux和Windows都会返回
-1
,表示EOF,如下: 文章图片
如果首次是write调用,对端会回复RST包,如下:
文章图片
而如果是连续的write/read调用,不同操作系统上表现不同,如下:
- 在Linux上一直write/read,表现如下:
# 第一次write,调用正常,对端返回RST包# 第二次write,抛broken pipe异常: 发生异常:java.net.SocketException: Broken pipe (Write failed) at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:111) at java.net.SocketOutputStream.write(SocketOutputStream.java:143)# 第三次write,抛broken pipe异常: 发生异常:java.net.SocketException: Broken pipe (Write failed) at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:111) at java.net.SocketOutputStream.write(SocketOutputStream.java:143)# 第四次read,返回-1
- 在Windows上一直write/read,表现如下:
# 第一次write,调用正常,对端返回RST包# 第二次write,抛Software caused connection abort: socket write error异常: 发生异常:java.net.SocketException: Software caused connection abort: socket write error at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:111) at java.net.SocketOutputStream.write(SocketOutputStream.java:143)# 第三次write,抛Software caused connection abort: socket write error异常: 发生异常:java.net.SocketException: Software caused connection abort: socket write error at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:111) at java.net.SocketOutputStream.write(SocketOutputStream.java:143)# 第四次read,抛Software caused connection abort: recv failed异常: 发生异常:java.net.SocketException: Software caused connection abort: recv failed at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.socketRead(SocketInputStream.java:116) at java.net.SocketInputStream.read(SocketInputStream.java:171) at java.net.SocketInputStream.read(SocketInputStream.java:141)
Broken pipe
或Software caused connection abort
异常。注:如果直接其它RST场景 上面已经看到了,绝大多数异常都是因为收到了RST包,除了端口未监听或连接不存在这两种情况会产生RST包外,还有一些特殊情况,也会导致RST包产生,如下:Ctrl+c
或kill -9
杀死程序,由于只是进程死亡,Linux内核还在,内核会给对端发送FIN包以关闭连接。
- TCP连接队列backlog满了
如果连接队列满了,在Linux上是丢弃SYN包,而Windows上是响应RST包。 - NAT环境中连接长时间空闲
目前的公网环境,除有公网IP的服务器外,基本上都是通过NAT转发技术连网的,如果程序中tcp连接长时间未通信,NAT设备会断开数据链路,而当连接被再次使用而发送数据时,NAT设备回复RST包。 - GFW国家防火墙
GFW国家防火墙如果发现数据包中有敏感信息,回复RST中断TCP连接。 - dns污染
dns污染会导致dns会被解析来错误的ip地址上,而如果对应ip地址上没有监听相关端口,就会回复RST包。 - socket的recv buffer中还有未读取的数据时关闭连接
如果socket的recv buffer中还有未读取走的数据,直接调用close(),会给对方发RST包。 - socket的send buffer中还有未发送的数据时关闭连接
默认情况下,socket的send buffer中还有未发送的数据时,直接调用close()会阻塞,直到数据发送完毕,但如果设置了TCP的SO_LINGER选项,则close会立马完成,并给对方发RST包。 - NAT环境下,启用了TCP快速回收
Linux在启用了tcp_recycle的情况下,若收到SYN包的timestamp比之前包的timestamp小,则会回复RST包,参考:https://mp.weixin.qq.com/s/uw... 。 - 使用Linux的NAT功能时,收到
out of tcp window
的数据包
Linux的NAT是使用netfilter机制实现的,对于out of tcp window
的数据包,经过netfilter时,会被标记为无效,而invalid的报文不在Connection Track模块里,即不处理也不丢弃,直接交给协议栈继续处理。
所以包的源ip地址不会被替换,对端接收到这个包后,会发现没有对应socket连接,就会回应RST数据包,进而导致连接断开,参考:https://mp.weixin.qq.com/s/ph... 。
# 观测22333端口数据包
sudo tcpdump -ni any port 22333# 添加iptables规则,丢弃22333端口的数据包
sudo iptables -t filter -I INPUT -p tcp -m tcp --dport 22333 -j DROP
# 添加iptables规则,丢弃22333端口除SYN+ACK的所有ACK包
sudo iptables -t filter -I INPUT -p tcp -m tcp --dport 22333 --tcp-flags SYN,ACK ACK -j DROP
# 删除iptables规则
sudo iptables -t filter -D INPUT -p tcp -m tcp --dport 22333 --tcp-flags SYN,ACK ACK -j DROP# 手动发RST包
# -a:源ip地址
# -s:源端口号
# -p:目标端口号
# --rst:开启RST标记位
# --win:设置tcp window大小
# --setseq:设置包seq号
sudo hping3 -a 10.243.72.157 -s 22333 -p 53824 --rst --win 0 --setseq 654041264 -c 1 10.243.211.45