三次握手四次挥手过程剖析

【一】预备知识：
1.三次握手并不一定非得成功，最担心得其实就是最后一个akc（应答）丢失，但是还是有配套得解决方案，比如超时重传机制。

2.连接是需要被保存下来得，是需要被os管理起来得，所以需要先描述再组织，这个是有时间和空间成本得。

3.syn洪水：当多个主机对你的服务器发起syn请求，导致你的服务器内部对连接的保存失败，从而导致服务器崩溃的网络攻击。

【二】为什么需要三次握手，一次两次握手不行吗？

一次握手，客户端仅发送一次syn信息即代表链接建立成功，当多个主机同时对你的服务器发起请求，这个时候，你不就直接炸裂？

两次握手，客户端发送syn请求，服务端接受后发送syn+ack请求，表示我接受到了信息且同意了建立链接，这从理论上来说和一次握手一样，只要你客户端发送请求成功了，链接就算建立了。

三次握手，客户端发送syn请求，服务端接收后发送syn+ack请求，客户端接受后再次发送afile:///C:/Users/吴神/Desktop/20230603_tcp_链接管理_滑动窗口.pngck请求，表示自己收到了服务端发送来的信息，可以建立链接了。这就有效的防止了syn洪水攻击。

tips：三次握手是用最小的成本来验证通信双方的全双工通信是流畅的。

 

【三】三次握手，四次握手~~~可以吗？

        其实这都不用我回答都是可以的，你三次握手都能做到的东西，为啥我四次握手，五次握手做不到呢？我不仅能做到，而且我能做的更好，那我为什么不做呢？其实主要还是三次就能做到的东西，我为啥要花费额外的成本去多做几次？通信也是有时间和空间的成本在里面的。

tips：其实关于syn攻击的问题还是没有得到根本上的解决，但是你想想，服务器收到攻击了，这本身就不是咱这握手解决的事情。

【四】为什么是四次挥手？

        你要把自己带入到这个网络协议里面，想象你和你的对象就是服务端和客户端，你们表白的时候的一般情况不就是，“xxx你能当我女朋友吗？”，“好的啊”，“xxx我爱死你了”,一般情况下，基本上就是这个流程了。（咱也没表过白，也不知道具体流程，纯靠脑部）

        但是你们分手的时候就会出现这种情况，“我们分手吧”，“好”，“真的分手了？”，“真的分了”，一般情况下，情侣之间的分手就是这么个流程。（手动狗头）

        因为断开连接是两个人的事情，所以需要两个人的同意，且双方要做好相应的事宜，需要各自把曾经对方送的东西给退回去。

【五】四次挥手的流程

        首先由一方发送fin信号，表示自己想要断开这个连接（在tcp协议中，服务端和客户端是对等的，谁发送fin信号都行），另一方返回ack连接表示自己收到了这个信号，在发送回一条fin信号，表示自己也要断开连接，最开始发送fin信号的一方收到之后返回ack信号，表示自己收到，并处于time_wait状态，另一方接收到ack信号后，立马关闭连接。有人又要问，为啥处于等待状态？不直接关闭，因为你没有办法包装最后一条ack报文被一定接收到，方便重传。且双方在断开连接的时候，网络中还有残存的报文，保证滞留的报文进行消散。

        

 【六】time_wait导致的问题

        不知道小伙伴们有没有写过简单的服务器程序，有时候中止了程序后，重新启动会发现你之前使用的端口号是没有办法用的，只能被迫的换一个端口号。

        其实这种情况对我们的影响是小的，但是对那些大公司呢？一单重启，换端口号，所有的客户端都找不到服务器了，tcp只有你主动连接了我我才能找到你的机制哎。

        其实在刚开始的绑定里设置绑定状态就可以解决这个问题了。

这就是本期的全部内容了，麻烦给个一件三连啊哈哈哈哈。