图解网络｜收到 RST，就一定会断开 TCP 连接吗？
时间：2021-11-16 13:37:37
手机看文章
扫描二维码
随时随地手机看文章
[导读]什么是RST我们都知道TCP正常情况下断开连接是用四次挥手，那是正常时候的优雅做法。但异常情况下，收发双方都不一定正常，连挥手这件事本身都可能做不到，所以就需要一个机制去强行关闭连接。RST就是用于这种情况，一般用来异常地关闭一个连接。它是一个TCP包头中的标志位。正常情况下，不...
什么是RST我们都知道TCP正常情况下断开连接是用四次挥手，那是正常时候的优雅做法。但异常情况下，收发双方都不一定正常，连挥手这件事本身都可能做不到，所以就需要一个机制去强行关闭连接。RST 就是用于这种情况，一般用来异常地关闭一个连接。它是一个TCP包头中的标志位。正常情况下，不管是发出，还是收到置了这个标志位的数据包，相应的内存、端口等连接资源都会被释放。从效果上来看就是TCP连接被关闭了。而接收到 RST的一方，一般会看到一个 TCP报头RST位 ResetByPeer BrokenPipe TCP连接未监听的端口 全局hash表
connection reset 或 connection refused 的报错。怎么知道收到RST了？
我们知道内核跟应用层是分开的两层，网络通信功能在内核，我们的客户端或服务端属于应用层。应用层只能通过send/recv 与内核交互，才能感知到内核是不是收到了RST。当本端收到远端发来的RST后，内核已经认为此链接已经关闭。此时如果本端应用层尝试去执行 读数据操作，比如recv，应用层就会收到 Connection reset by peer 的报错，意思是远端已经关闭连接。send，那么应用层就会收到 Broken pipe 的报错，意思是发送通道已经坏了。出现RST的场景有哪些
RST一般出现于异常情况，归类为 对端的端口不可用 和 socket提前关闭。端口不可用
端口不可用分为两种情况。要么是这个端口从来就没有"可用"过，比如根本就没监听（listen）过；要么就是曾经"可用"，但现在"不可用"了，比如服务突然崩了。端口未监听
listen 方法会创建一个sock放入到全局的哈希表中。此时客户端发起一个connect请求到服务端。服务端在收到数据包之后，第一时间会根据IP和端口从哈希表里去获取sock。listen，就能从全局哈希表里拿到sock。但如果服务端没有执行过listen，那哈希表里也就不会有对应的sock，结果当然是拿不到。此时，正常情况下服务端会发RST给客户端。端口未监听就一定会发RST吗？
不一定。上面提到，发RST的前提是正常情况下，我们看下源码。// net/ipv4/tcp_ipv4.c
// 代码经过删减
int tcp_v4_rcv(struct sk_buff *skb)
{
// 根据ip、端口等信息 获取sock。
sk = __inet_lookup_skb( 
下载文档
