已经建立的TCP，收到SYN会发生什么？

已经建立的TCP，收到SYN会发生什么？

该场景可以描述为：客户端与服务端建立连接后，突然客户端死机了，而服务器还处于establelisten状态，这时客户端开机后再次发送syn报文请求建立连接，那么服务端收到这个syn报文会做出什么反应呢？？

一个TCP连接是由一个四元组唯一确认的，此时源ip，目标ip，目标端口是确定的，只有源端口是不确定的。

客户端SYN报文的源端口与历史端口是不一样的

这样的话，相当于客户端重新建立起了一次新的连接

那么服务端处于establelisten状态的连接，如果服务端有数据要发送的话，那么客户端内核就会会给服务端RST报文，强制断开连接；如果没有数据要发送，那么一段时间后，保活机制便开始活动，几次探测后没有回应，便会断开连接

客户端SYN报文的源端口与历史端口一致

对于前面一个连接，服务端没有数据要发送，且没有被TCP保活机制杀掉，也就是一直保持着establelisten状态，那么这时收到了原来连接的syn报文，它会做出什么反应呢？？？丢掉syn报文？？发送RST报文？？回复ACK+SYN报文？？？

当客户端发送syn报文时(这个syn报文序列号是随机的)，这时服务端收到syn报文后，会回复包含正确序列号和应答号的ack报文，客户端在接收到这个ack报文后，发现与期待的序列号不一致，就会发送RST报文给服务端断开连接

这里服务端发给客户端正确ack报文，叫做Challenge ACK

连接终止后，客户端将继续尝试建立连接

自己如何关闭一个TCP连接呢？？

• 杀掉进程？
  在客户端可以通过杀掉一个进程来关闭一个端口，断掉连接；
  但是在服务端，你关闭一个端口，那不就是把全部连接都断开了嘛(服务端是只监听一个端口的)，这样显然是不行的。
• 伪造RST报文？？
  如果你伪造的RST报文不在对方的接受窗口内，还是会被丢弃滴！伪造符合预期的序列号是比较难的。
• 通过伪造SYN报文
  伪造符合预期的序列号比较难，那我们可以通过上面开头提到的知识来拿到合法的序列号嘛！！
  我们伪造一个syn报文发送过去后，服务端会返回一个正确的序列号以及应答号，这个应答号就是下一次发送的序列号，这样我们就得到了合法的序列号。

Linux上有一个叫killcx的工具，工作原理如下：