动图图解！收到RST，就一定会断开TCP连接吗？ _TCP连接

想必大家已经知道我的niao性，搞个标题，就是不喜欢立马回答。
就是要搞一大堆原理性的东西，再回答标题的问题。
说这个是因为我这次会把问题的答案就放到开头吗？
不！
我就不！
但是大家可以直接根据目录看自己感兴趣的部分。
之所以要先铺垫一些原理，还是希望大家能先看些基础的，再慢慢循序渐进，这样有利于建立知识体系。多一点上下文，少一点gap 。
【动图图解！收到RST，就一定会断开TCP连接吗？】好了，进入正题。
下面是这篇文章的目录。

文章插图

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

什么是RST我们都知道TCP正常情况下断开连接是用四次挥手，那是正常时候的优雅做法。
但异常情况下，收发双方都不一定正常，连挥手这件事本身都可能做不到，所以就需要一个机制去强行关闭连接。
RST 就是用于这种情况，一般用来异常地关闭一个连接。它是一个TCP包头中的标志位。
正常情况下，不管是发出，还是收到置了这个标志位的数据包，相应的内存、端口等连接资源都会被释放。从效果上来看就是TCP连接被关闭了。
而接收到 RST的一方，一般会看到一个 connection reset 或 connection refused 的报错。

文章插图

TCP报头RST位

怎么知道收到RST了？我们知道内核跟应用层是分开的两层，网络通信功能在内核，我们的客户端或服务端属于应用层。应用层只能通过 send/recv 与内核交互，才能感知到内核是不是收到了RST 。
当本端收到远端发来的RST后，内核已经认为此链接已经关闭。
此时如果本端应用层尝试去执行读数据操作，比如recv，应用层就会收到 Connection reset by peer 的报错，意思是远端已经关闭连接。

文章插图

ResetByPeer
如果本端应用层尝试去执行写数据操作，比如send，那么应用层就会收到 Broken pipe 的报错，意思是发送通道已经坏了。

文章插图

BrokenPipe
这两个是开发过程中很经常遇到的报错，感觉大家可以把这篇文章放进收藏夹吃灰了，等遇到这个问题了，再打开来擦擦灰，说不定对你会有帮助。

出现RST的场景有哪些RST一般出现于异常情况，归类为对端的端口不可用和 socket提前关闭。

端口不可用端口不可用分为两种情况。要么是这个端口从来就没有"可用"过，比如根本就没监听（listen）过；要么就是曾经"可用"，但现在"不可用"了，比如服务突然崩了。
端口未监听

文章插图

TCP连接未监听的端口
服务端listen 方法会创建一个sock放入到全局的哈希表中。
此时客户端发起一个connect请求到服务端。服务端在收到数据包之后，第一时间会根据IP和端口从哈希表里去获取sock 。

文章插图

全局hash表
如果服务端执行过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(&tcp_hashinfo, skb, th->source, th->dest);if (!sk)goto no_tcp_socket;no_tcp_socket:// 检查数据包有没有出错if (skb->len < (th->doff << 2) || tcp_checksum_complete(skb)) {// 错误记录} else {// 发送RSTtcp_v4_send_reset(NULL, skb);}}

内核在收到数据后会从物理层、数据链路层、网络层、传输层、应用层，一层一层往上传递。到传输层的时候，根据当前数据包的协议是TCP还是UDP走不一样的函数方法。可以简单认为，TCP数据包都会走到 tcp_v4_rcv() 。这个方法会从全局哈希表里获取 sock，如果此时服务端没有listen()过 , 那肯定获取不了sock，会跳转到no_tcp_socket的逻辑。