巨匠好，我是小林。

之前有位读者在口试中，被问到这样一个问题。

「如安在不杀掉程度前提，关闭一个 TCP 衔接?」

这个我之前的著作也说起过「处于 establish 景色的衔接，收到 SYN 报文会发生什么?」

我这里再把要道的点，讲一下。

正文

巨匠在关闭 TCP 衔接第一反映王人是「杀掉程度」。

是的，这个是最狞恶的面貌，杀掉客户端程度和处事端程度影响的限制会有所不同：

在客户端杀掉程度的话，就会发送 FIN 报文，来断开这个客户端程度与处事端诞生的系数 TCP 衔接，这种面貌影响限制唯有这个客户端程度所诞生的衔接，而其他客户端或程度不会受影响。 而在处事端杀掉程度影响就大了，此时系数的 TCP 衔接王人会被关闭，处事端无法不绝提供探望处事。

是以，关闭程度的面貌并不可取，最佳的面貌要细腻到关闭某一条 TCP 衔接。

有的小伙伴可能会说，伪造一个四元组雷同的 RST 报文不就行了?

这个想路很好，然而不要忘了还有个序列号的问题，你伪造的 RST 报文的序列号一定能被对方遴选吗?

若是 RST 报文的序列号弗成落在对方的滑动窗口内，这个 RST 报文会被对方丢弃的，就够不上关闭的衔接的后果。

是以，要伪造一个能关闭 TCP 衔接的 RST 报文，必须同期得志「四元组雷同」和「序列号正值落在对方的滑动窗口内」这两个条目。

平直伪造妥当预期的序列号是相比繁重，因为若是一个正在传输数据的 TCP 衔接，滑动窗口技巧王人在变化，因此很难刚好伪造一个刚好落在对方滑动窗口内的序列号的 RST 报文。

方针已经有的，咱们不错伪造一个四元组雷同的 SYN 报文，来拿到“正当”的序列号!

因为若是处于 establish 景色的处事端，收到四元组雷同的 SYN 报文后，会申诉一个 Challenge ACK，这个 ACK 报文里的「证实号」，正值是处事端下一次想要汲取的序列号，说白了，等于不错通过这一步拿到处事端下一次预期汲取的序列号。

然后用这个证实号动作 RST 报文的序列号，发送给处事端，此时处事端会觉得这个 RST 报文里的序列号是正当的，于是就会开释衔接!

在 Linux 上有个叫 killcx 的器具，等于基于上头这样的面貌完毕的，它会主动发送 SYN 包赢得 SEQ/ACK 号，然后哄骗 SEQ/ACK 号伪造两个 RST 报文分散发给客户端和处事端，这样两边的 TCP 衔接王人会被开释，这种面貌活跃和非活跃的 TCP 衔接王人不错杀掉。

使用面貌也很浮浅，只需指明客户端的 IP 和端标语。

./killcx

killcx 器具的职责旨趣，如下图

它伪造客户端发送 SYN 报文，处事端收到后就会申诉一个佩戴了正确「序列号和证实号」的 ACK 报文(Challenge ACK)，然后就不错哄骗这个 ACK 报文内部的信息，伪造两个 RST 报文：

用 Challenge ACK 里的证实号伪造 RST 报文发送给处事端，处事端收到 RST 报文后就会开释衔接。 用 Challenge ACK 里的序列号伪造 RST 报文发送给客户端，客户端收到 RST 也会开释衔接。

恰是通过这样的面貌，得手将一个 TCP 衔接关闭了!

这里给巨匠贴一个使用 killcx 器具关闭衔接的执包图，巨匠多望望序列号和证实号的变化。

是以，以后执包中，若是无言奇妙出现一个 SYN 包，有可能对方接下来想要对你发起的 RST 袭击，平直将你的 TCP 衔接断开!

 

怎样样，很玄机吧!