百度360必应搜狗淘宝本站头条
mqtt服务器xftp6mybatiscollectionkeyerrorc#var
当前位置：网站首页 > 热门文章 > 正文

常见的Socket网络异常场景分析

bigegpt 2024-09-09 01:25 5 浏览

原创：打码日记（微信公众号ID：codelogs），欢迎分享，转载请保留出处。

简介

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

socket状态变迁图

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

三次握手

  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_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)

这个异常原因是，客户端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读取超时异常。

  1. 服务端处理太慢
  2. 网络卡了，数据包一直传输不过来

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

write重传超时

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

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

  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配置。

总而言之，write超时可能导致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)

总而言之，RST包会导致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)

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

注：如果直接Ctrl+c或kill -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

相关推荐

Java 泛型大揭秘:类型参数、通配符与最佳实践

引言在编程世界中，代码的可重用性和可维护性是至关重要的。为了实现这些目标，Java5引入了一种名为泛型（Generics）的强大功能。本文将详细介绍Java泛型的概念、优势和局限性，以及如何在...

K8s 的标签与选择器:流畅运维的秘诀

在Kubernetes的世界里，**标签（Label）和选择器（Selector）**并不是最炫酷的技术，但却是贯穿整个集群管理与运维流程的核心机制。正是它们让复杂的资源调度、查询、自动化运维变得...

哈希Hash算法:原理、应用（哈希算法 知乎）

原作者：Linux教程，原文地址：「链接」什么是哈希算法？哈希算法（HashAlgorithm），又称为散列算法或杂凑算法，是一种将任意长度的数据输入转换为固定长度输出值的数学函数。其输出结果通常被...

C#学习:基于LLM的简历评估程序（c# 简历）

前言在pocketflow的例子中看到了一个基于LLM的简历评估程序的例子，感觉还挺好玩的，为了练习一下C#，我最近使用C#重写了一个。准备不同的简历：image-20250528183949844查...

55顺位，砍41+14+3!季后赛也成得分王，难道他也是一名球星?

雷霆队最不可思议的新星：一个55号秀的疯狂逆袭！你是不是也觉得NBA最底层的55号秀，就只能当饮水机管理员？今年的55号秀阿龙·威金斯恐怕要打破你的认知了！常规赛阶段，这位二轮秀就像开了窍的天才，直接...

5分钟读懂C#字典对象（c# 字典获取值）

什么是字典对象在C#中，使用Dictionary类来管理由键值对组成的集合，这类集合被称为字典。字典最大的特点就是能够根据键来快速查找集合中的值，其键的定义不能重复，具有唯一性，相当于数组索引值，字典...

c#窗体传值（c# 跨窗体传递数据）

在WinForm编程中我们经常需要进行俩个窗体间的传值。下面我给出了两种方法，来实现传值一、在输入数据的界面中定义一个属性，供接受数据的窗体使用1、子窗体usingSystem;usingSyst...

C#入门篇章—委托（c#委托的理解）

C#委托1.委托的定义和使用委托的作用：如果要把方法作为函数来进行传递的话，就要用到委托。委托是一个类型，这个类型可以赋值一个方法的引用。C#的委托通过delegate关键字来声明。声明委托的...

C#.NET in、out、ref详解（c#.net framework）

简介在C#中，in、ref和out是用于修改方法参数传递方式的关键字，它们决定了参数是按值传递还是按引用传递，以及参数是否必须在传递前初始化。基本语义对比修饰符传递方式可读写性必须初始化调用...

C#广义表（广义表headtail）

在C#中，广义表（GeneralizedList）是一种特殊的数据结构，它是线性表的推广。广义表可以包含单个元素（称为原子），也可以包含另一个广义表（称为子表）。以下是一个简单的C#广义表示例代...

「C#.NET 拾遗补漏」04:你必须知道的反射

阅读本文大概需要3分钟。通常，反射用于动态获取对象的类型、属性和方法等信息。今天带你玩转反射，来汇总一下反射的各种常见操作，捡漏看看有没有你不知道的。获取类型的成员Type类的GetMembe...

C#启动外部程序的问题（c#怎么启动）

IT&OT的深度融合是智能制造的基石。本公众号将聚焦于PLC编程与上位机开发。除理论知识外，也会结合我们团队在开发过程中遇到的具体问题介绍一些项目经验。在使用C#开发上位机时，有时会需要启动外部的一些...

全网最狠C#面试拷问:这20道题没答出来，别说你懂.NET!

在竞争激烈的C#开发岗位求职过程中，面试是必经的一道关卡。而一场高质量的面试，不仅能筛选出真正掌握C#和.NET技术精髓的人才，也能让求职者对自身技术水平有更清晰的认知。今天，就为大家精心准备了20道...

C#匿名方法（c#匿名方法与匿名类）

C#中的匿名方法是一种没有名称只有主体的方法，它提供了一种传递代码块作为委托参数的技术。以下是关于C#匿名方法的一些重要特点和用法：特点省略参数列表：使用匿名方法可省略参数列表，这意味着匿名方法...

C# Windows窗体(.Net Framework)知识总结

Windows窗体可大致分为Form窗体和MDI窗体，Form窗体没什么好细说的，知识点总结都在思维导图里面了，下文将围绕MDI窗体来讲述。MDI（MultipleDocumentInterfac...

一周热门
最近发表
标签列表