[转帖] 常见的Socket网络异常场景分析

常见,socket,网络,异常,场景,分析 · 浏览次数 : 0

小编点评

使用Linux的NAT功能时,收到out of tcp window的数据包Linux的NAT是使用netfilter机制实现的,对于out of tcp window的数据包,经过netfilter时,会被标记为无效,而invalid的报文不在Connection Track模块里,即不处理也不丢弃,直接交给协议栈继续处理。所以包的源ip地址不会被替换,对端接收到这个包后,会发现没有对应socket连接,就会回应RST数据包,进而导致连接断开。 相关命令#如果你想复现这些网络异常,可以了解下iptables和hping3命令,实现包丢弃或发送指定包(如RST包), # 观测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往期内容 # 神秘的backlog参数与TCP连接队列Linux命令拾遗-入门篇原来awk真是神器啊Linux文本命令技巧(上)Linux文本命令技巧(下)字符编码解惑

正文

https://www.cnblogs.com/codelogs/p/16001770.html

 

原创:打码日记(微信公众号ID:codelogs),欢迎分享,转载请保留出处。

简介#

在目前微服务的背景下,网络异常越来越常见了,而有一些网络异常非常模糊,理解什么情况下会导致什么异常,还是有一定难度的,为此我做了大量实验,来复现各种异常场景。

socket状态变迁图#

先快速回顾下正常情况下TCP的交互过程与socket状态变迁,如下:
tcp_state

三次握手#

  1. 客户端调用connect函数,会发SYN包给服务端,客户端状态变为SYN_SENT,服务端收到后变为SYN_RECV,同时回复SYN+ACK包给客户端。
  2. 客户端收到SYN+ACK包后,变成ESTABLISHED状态,同时回复ACK包给服务端,并且客户端的connect函数执行完成。
  3. 服务端收到ACK包后,也变成ESTABLISHED状态,至此连接建立完成。

思考:如果第一个SYN包服务端没收到,会怎么样?
客户端会重发SYN包给服务端,服务端收到后会再次发SYN+ACK给客户端。

思考:如果最后一个ACK包没收到,会怎么样?
服务端会重发SYN+ACK包给客户端,客户端收到后会再次发ACK给服务端。

这里可以发现,TCP协议里面,重发都发生在没有收到ACK的场景,纯ACK确认包不会重发。

数据传输#

  1. 客户端调用write函数,发送请求数据,服务端调用read函数,接收请求数据。
  2. 服务端请求处理结束,服务端调用write函数,返回响应数据,客户端调用read函数,接收响应数据。

思考:如果之前三次握手时ACK丢失了,但客户端已经是ESTABLISHED状态了,调用write发数据了,会怎么样?
write发的数据包,也是带有ACK标记的,不管与之前的ACK包哪个先到,服务端都会变成ESTABLISHED状态。

而如果ACK与数据包都到不了服务端,一段时间后,服务端SYN_RECV状态的Socket会自动关闭,且不回复任何包给客户端,可以发现这种场景下,客户端认为连接成功,而服务端根本就没有连接。

四次挥手#

  1. 客户端调用close函数,会发送FIN包给服务端,状态变为FIN_WAIT_1,服务端收到后,回复ACK,且状态变为CLOSE_WAIT。
  2. 客户端收到ACK后,状态变为FIN_WAIT_2状态。
  3. 服务端调用close函数,也会发送FIN包给客户端,状态变为LAST_ACK,客户端收到后,回复ACK,且状态变为TIME_WAIT。
  4. 服务端收到ACK后,Socket被操作系统回收,客户端的TIME_WAIT状态Socket在等待2MSL后,也被操作系统回收。

思考:如果一个连接一直没有被使用(如连接池),而超过服务端最大空闲时间,服务端主动关闭了连接,会怎么样?
这时服务端会变成FIN_WAIT_2,这个状态也是有超时时间的,如果对方一直不发FIN过来,操作系统就会回收掉这个Socket,而客户端会一直是CLOSE_WAIT状态。

所以如果CLOSE_WAIT状态很多,一般是程序漏写了关闭Socket的代码。

从上面的状态变迁图,也可以推断出,绝大多数情况下,SYN_SENTSYN_RECVFIN_WAIT_1LAST_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)

这个异常原因是,客户端connect建立连接时,服务端一直没收到SYN包,超过了设置的连接超时时间后,就会报此异常。
syn_drop

还可能是,服务端收到了SYN包,但SYN+ACK一直发不到客户端,也会报此异常。
syn_ack_drop

连接拒绝#

发生异常: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包。
syn_refused

注: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读取超时异常。

  1. 服务端处理太慢
    read_process_timeout

  2. 网络卡了,数据包一直传输不过来
    read_net_timeout

大多数情况下,这种异常都是服务端处理太慢导致的,可通过socket.setSoTimeout()来修改这个超时时间,注意理解这个超时时间,它不是整个读取过程时间,而是无任何数据通信的空闲时间。

write重传超时#

一般来说,由于socket有写缓冲(send buffer),write方法是不阻塞立即返回的,但如果write大量数据(如文件上传),当send buffer用完时write方法还是会阻塞的。
不管write方法是否阻塞,数据多次重传失败,会导致异常,区别是阻塞write被异常打断,而没有阻塞write时,会在下一次write时抛异常。
write_timeout

对于这种情况的异常信息,不同的操作系统表现不一样,如下:

  1. 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)
  1. 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配置,或使用TCP_USER_TIMEOUT。

总而言之,write超时可能导致Connection timed out (Write failed)异常或Connection reset by peer异常(Windows上)。

读写时收到对方RST包#

一般来说,如果对端机器上连接不存在了,还调用write往其发数据包,对方会回复RST包来终止连接。
write_recv_rst

注:那什么时候会出现连接不存在呢?如机器直接断电后重启,或网络包被路由到了错误的机器上等,都会使得机器上没有相应的TCP连接。

而当阻塞在write/read时,收到了对方的RST包,或先收到对方的RST包,再write/read时,就会报Connection reset异常。
write_rst
read_rst

如果对端机器上连接不存在了,本端连续调用write/read时,在不同操作系统上会产生不一样的异常序列,如下:

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

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

总而言之,RST包会导致Connection reset异常,同时也可能导致Broken pipe异常。

对方关闭连接后依然读写#

如果对方调用close关闭了连接,本端再调用read或write方法读写数据会怎么样呢?

如果首次是read调用,Linux和Windows都会返回-1,表示EOF,如下:
fin_read_eof

如果首次是write调用,对端会回复RST包,如下:
fin_write_recv_rst

而如果是连续的write/read调用,不同操作系统上表现不同,如下:

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

总而言之,如果对方关闭了连接,本端还write数据,会报Broken pipeSoftware caused connection abort异常。

注:如果直接Ctrl+ckill -9杀死程序,由于只是进程死亡,Linux内核还在,内核会给对端发送FIN包以关闭连接。

其它RST场景#

上面已经看到了,绝大多数异常都是因为收到了RST包,除了端口未监听或连接不存在这两种情况会产生RST包外,还有一些特殊情况,也会导致RST包产生,如下:

  1. TCP连接队列backlog满了
    如果连接队列满了,在Linux上是丢弃SYN包,而Windows上是响应RST包。

  2. NAT环境中连接长时间空闲
    目前的公网环境,除有公网IP的服务器外,基本上都是通过NAT转发技术连网的,如果程序中tcp连接长时间未通信,NAT设备会断开数据链路,而当连接被再次使用而发送数据时,NAT设备回复RST包。

  3. GFW国家防火墙
    GFW国家防火墙如果发现数据包中有敏感信息,回复RST中断TCP连接。

  4. dns污染
    dns污染会导致dns会被解析来错误的ip地址上,而如果对应ip地址上没有监听相关端口,就会回复RST包。

  5. socket的recv buffer中还有未读取的数据时关闭连接
    如果socket的recv buffer中还有未读取走的数据,直接调用close(),会给对方发RST包。

  6. socket的send buffer中还有未发送的数据时关闭连接
    默认情况下,socket的send buffer中还有未发送的数据时,直接调用close()会阻塞,直到数据发送完毕,但如果设置了TCP的SO_LINGER选项,则close会立马完成,并给对方发RST包。

  7. NAT环境下,启用了TCP快速回收
    Linux在启用了tcp_recycle的情况下,若收到SYN包的timestamp比之前包的timestamp小,则会回复RST包,参考:https://mp.weixin.qq.com/s/uwykopNnkcRL5JXTVufyBw 。

  8. 使用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/phcaowQWFQf9dzFCqxSCJA 。

相关命令#

如果你也想复现这些网络异常,可以了解下iptables和hping3命令,实现包丢弃或发送指定包(如RST包),如下:

# 观测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

往期内容#

神秘的backlog参数与TCP连接队列
Linux命令拾遗-入门篇
原来awk真是神器啊
Linux文本命令技巧(上)
Linux文本命令技巧(下)
字符编码解惑

与[转帖] 常见的Socket网络异常场景分析相似的内容:

[转帖]常见的Socket网络异常场景分析

https://www.cnblogs.com/codelogs/p/16001770.html 简介# 在目前微服务的背景下,网络异常越来越常见了,而有一些网络异常非常模糊,理解什么情况下会导致什么异常,还是有一定难度的,为此我做了大量实验,来复现各种异常场景。 socket状态变迁图# 先快速回

[转帖] 常见的Socket网络异常场景分析

https://www.cnblogs.com/codelogs/p/16001770.html 原创:打码日记(微信公众号ID:codelogs),欢迎分享,转载请保留出处。 简介# 在目前微服务的背景下,网络异常越来越常见了,而有一些网络异常非常模糊,理解什么情况下会导致什么异常,还是有一定难度

[转帖]为什么网络 I/O 会被阻塞?

https://my.oschina.net/lenve/blog/5952439 我们应该都知道 socket(套接字),你可以认为我们的通信都要基于这个玩意,而常说的网络通信又分为 TCP 与 UDP 两种,下面我会以 TCP 通信为例来阐述下 socket 的通信流程。 不过在此之前,我先来说

[转帖]Linux句柄调优之nofile、nr_open、file-max

https://www.jianshu.com/p/8fb056e7b9f8 在开发运维的时候我们常常会遇到类似“Socket/File: Can’t open so many files”,“无法打开更多进程”,或是coredump过大等问题,这些都可以设置资源限制来解决。今天在教某位客户设置最大

[转帖]Linux句柄调优之nofile、nr_open、file-max

https://www.jianshu.com/p/8fb056e7b9f8 在开发运维的时候我们常常会遇到类似“Socket/File: Can’t open so many files”,“无法打开更多进程”,或是coredump过大等问题,这些都可以设置资源限制来解决。今天在教某位客户设置最大

[转帖]Linux句柄调优之nofile、nr_open、file-max

https://www.jianshu.com/p/8fb056e7b9f8 在开发运维的时候我们常常会遇到类似“Socket/File: Can’t open so many files”,“无法打开更多进程”,或是coredump过大等问题,这些都可以设置资源限制来解决。今天在教某位客户设置最大

[转帖]常见加密算法比较

加密算法 常见的 对称加密 算法主要有 DES(数据加密标准)、3DES(三重DES)、AES(高级加密标准) 和Blowfish(河豚鱼)等,常见的 非对称算法 主要有 RSA、DSA 等,散列算法 主要有 SHA-1、SHA-256、MD5 等。 HASH算法(散列算法) 目前常用的是SHA-2

[转帖] MySQL常见的存储引擎InnoDB、MyISAM的区别?

1)事务:MyISAM不支持,InnoDB支持2)锁级别:MyISAM 表级锁,InnoDB 行级锁及外键约束(MySQL表级锁有两种模式:表共享读锁(Table Read Lock)和表独占写锁(Table Write Lock)。什么意思呢,就是说对MyISAM表进行读操作时,它不会阻塞其他用户

[转帖]JS常见加密 AES、DES、RSA、MD5、SHAI、HMAC、Base64 - Python/JS实现

https://bbs.huaweicloud.com/blogs/386139 【摘要】 本文仅仅介绍了常见的一些JS加密,并记录了JS和Python的实现方式 常见的加密算法基本分为这几类: (1)base64编码伪加密 (2)线性散列算法(签名算法)MD5 (3)安全哈希算法 SHAI (4)

[转帖]TCP/IP常见的一些调优措施

文章目录 前言TCP/IP连接建立状态解释调优tcp_synack_retries :INTEGERtcp_keepalive_time :INTEGERtcp_keepalive_probes:INTEGERtcp_keepalive_intvl:INTEGERtcp_retries1 :INTE