收到RST，就一定会断开TCP连接吗？

想必大家已经知道我的niao性，搞个标题，就是不喜欢立马回答。

就是要搞一大堆原理性的东西，再回答标题的问题。

说这个是因为我这次会把问题的答案就放到开头吗？

不！

我就不！

但是大家可以直接根据目录看自己感兴趣的部分。

之所以要先铺垫一些原理，还是希望大家能先看些基础的，再慢慢循序渐进，这样有利于建立知识体系。多一点上下文，少一点gap。

好了，进入正题。

下面是这篇文章的目录。

什么是RST

我们都知道TCP正常情况下断开连接是用四次挥手，那是正常时候的优雅做法。

但异常情况下，收发双方都不一定正常，连挥手这件事本身都可能做不到，所以就需要一个机制去强行关闭连接。

RST 就是用于这种情况，一般用来异常地关闭一个连接。它是一个TCP包头中的标志位。

正常情况下，不管是发出，还是收到置了这个标志位的数据包，相应的内存、端口等连接资源都会被释放。从效果上来看就是TCP连接被关闭了。

而接收到 RST的一方，一般会看到一个 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(