已经建立的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的工具,工作原理如下: