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

大家知道，TCP是全双工通信，意思是发送数据的同时，还可以接收数据。
Close()的含义是，此时要同时关闭发送和接收消息的功能。
客户端执行close()，正常情况下，会发出第一次挥手FIN，然后服务端回第二次挥手ACK 。如果在第二次和第三次挥手之间，如果服务方还尝试传数据给客户端，那么客户端不仅不收这个消息，还会发一个RST消息到服务端。直接结束掉这次连接。

对方没收到RST，会怎么样？我们知道TCP是可靠传输，意味着本端发一个数据，远端在收到这个数据后就会回一个ACK，意思是"我收到这个包了" 。
而RST，不需要ACK确认包。
因为RST本来就是设计来处理异常情况的，既然都已经在异常情况下了，还指望对方能正常回你一个ACK吗？可以幻想，不要妄想。
但问题又来了，网络环境这么复杂，丢包也是分分钟的事情，既然RST包不需要ACK来确认，那万一对方就是没收到RST，会怎么样？

文章插图

RST丢失
RST丢了，问题不大。比方说上图服务端，发了RST之后，服务端就认为连接不可用了。
如果客户端之前发送了数据，一直没等到这个数据的确认ACK，就会重发，重发的时候，自然就会触发一个新的RST包。
而如果客户端之前没有发数据，但服务端的RST丢了，TCP有个keepalive机制，会定期发送探活包，这种数据包到了服务端，也会重新触发一个RST 。

文章插图

RST丢失后keepalive

收到RST就一定会断开连接吗?先说结论，不一定会断开。我们看下源码。

// net/ipv4/tcp_input.cstatic bool tcp_validate_incoming(){// 获取sockstruct tcp_sock *tp = tcp_sk(sk);// step 1：先判断seq是否合法（是否在合法接收窗口范围内）if (!tcp_sequence(tp, TCP_SKB_CB(skb)->seq, TCP_SKB_CB(skb)->end_seq)) {goto discard;}// step 2：执行收到 RST 后该干的事情if (th->rst) {if (TCP_SKB_CB(skb)->seq == tp->rcv_nxt)tcp_reset(sk);elsetcp_send_challenge_ack(sk);goto discard;}}

收到RST包，第一步会通过tcp_sequence先看下这个seq是否合法，其实主要是看下这个seq是否在合法接收窗口范围内。如果不在范围内，这个RST包就会被丢弃。
至于接收窗口是个啥，我们先看下面这个图。

文章插图

接收窗口
这里黄色的部分，就是指接收窗口，只要RST包的seq不在这个窗口范围内，那就会被丢弃。

为什么要校验是否在窗口范围内正常情况下客户端服务端双方可以通过RST来断开连接。假设不做seq校验，如果这时候有不怀好意的第三方介入，构造了一个RST包，且在TCP和IP等报头都填上客户端的信息，发到服务端，那么服务端就会断开这个连接。同理也可以伪造服务端的包发给客户端。这就叫RST攻击。

文章插图

RST攻击
受到RST攻击时，从现象上看，客户端老感觉服务端崩了，这非常影响用户体验。
如果这是个游戏，我相信多崩几次，第二天大家就不来玩了。
实际消息发送过程中，接收窗口是不断移动的，seq也是在飞快的变动中，此时第三方是比较难构造出合法seq的RST包的，那么通过这个seq校验，就可以拦下了很多不合法的消息。

加了窗口校验就不能用RST攻击了吗不是，只是增加了攻击的成本。但如果想搞，还是可搞的。
以下是面向监狱编程的环节。
希望大家只了解原理就好了，不建议使用。
相信大家都不喜欢穿着蓝白条纹的衣服，拍纯狱风的照片。
从上面可以知道，不是每一个RST包都会导致连接重置的，要求是这个RST包的seq要在窗口范围内，所以，问题就变成了，我们怎么样才能构造出合法的seq 。

盲猜seq窗口数值seq本质上只是个uint32类型。
struct tcp_skb_cb {__u32seq;/* Starting sequence number */}如果在这个范围内疯狂猜测seq数值，并构造对应的包，发到目的机器，虽然概率低，但是总是能被试出来，从而实现RST攻击。这种乱棍打死老师傅的方式，就是所谓的合法窗口盲打（blind in-window attacks）。
觉得这种方式比较笨？那有没有聪明点的方式，还真有，但是在这之前需要先看下面的这个问题。