TCP中的三次握手和四次挥手

三次握手：目的是同步连接双方的序列号和确认号 并交换 TCP窗口大小信息。

理论上跟通话一样： a: 你听的到吗？  b: 我能听到。只需要两次就可以了，但建立连接阶段不是双向即时通信的，且最终的目的是为了建立安全稳定的连接。所以需要三次握手。

三次握手最终要达到的目的是，客户端以及服务端都知道自己以及对方发送接收正常，这样的机制才是健康安全的。

第一次握手：客户端给服务器发送了消息

解析：客户端发送了 SYN = 1,以及 seq = 1给服务端，这个过程结束后服务端知道了一件事情： 我自己的接收正常，客户端那边的发送正常。（这时候的客户端并不能确认自己的发送正常）

　　　seq = x相当于是一个暗号，客户端发完后就进入了等待发送状态（发送预启动）

第二次握手：服务端接收到了客户端的消息后作出反馈

解析：服务端返回给客户端的信息里：把刚才客户端发过来的 SYN = 1,以及 seq这个暗号 进行加1 得到ack = x+1,然后再发送一套自己的东西，ACK = 1， seq = Y.

客户端收到了 ack = x+1，明白了确实服务器收到了我刚才的那个请求，暗号是对的。并且也记下了服务器的那套东西， ACK以及seq

这个过程下来，客户可以确认：我的发送正常，接收也正常，服务器那边的接收正常，发送正常。（服务端那边还不能确认自己的发送正常），服务端进入等待接收状态（或者说是接收预启动）

第三次握手：客户端发送消息给服务端

解析： 客户端把之前收到的服务端发送过来的两个字段返回给服务端，并把那个暗号+1.

服务端可以做出总结：我之前发的服务端确实收到了，我的发送正常，客户端能收到我的消息并返回给我，那客户端的发送接收功能也正常。（第一次握手时候，服务端确认了自己的发送正常及客户端的发送正常）

至此： 客户端以及服务端都确认了，自己的发送接收正常，对方的发送接收也正常。结束，建立起tcp连接。双方由预启动状态正式开始工作。

总结：为什么要有三次握手：这个保证了即时性、有效性，假设一种场景：客服端给服务端发送的消息经历了太空漫游，网络延迟等，导致很久之后服务端才接收到。

　　  如果是客户端请求了，服务端接收到了请求就直接建立起tcp连接，这样服务端就会处在一个等待客户端请求端的状态（联想到了古代时期一妇女收到了战场上夫君的书信，然后天天桥头望夫归，信是几个月前军队寄       出来的，男人早已战死QAQ）。这种状态浪费了服务器的资源。

四次挥手：断开tcp连接的机制，防止对方话还没说完就挂电话了。。。

第一次挥手：客户端发送了报文给服务端，客户端进入了预关闭状态，表明自己没有啥话说了。

第二次挥手：服务端告诉客户端，我知道了。同时把暗号进行加1，返回给客服端。

第三次挥手：服务端继续告诉客户端，我也没啥话说了，那咱们挂电话吧？ 服务端进入准备挂电话状态。

第四次挥手：客服端收到了服务端发的消息，确认对方也没有话交代了，且准备挂电话了。然后客户端说：好，那挂吧。

　　　　　　服务端收到消息后，挂断电话（服务器进入关闭状态），客户端听到嘟嘟，知道对方挂电话了，于是自己也进入关闭状态。

　　　　　　（原理是，客户端发出消息后，几毫秒之后没有接收到服务端的任何消息，就知道服务端是进入关闭状态了，于是自己也这样）

总结：为什么要四次挥手，客户端告知服务端：我没啥话说了。服务端回复客户端：我知道你没话说了。这两步走完后，不可能立马就挂的，

　　  万一服务端还有话说呢？ 于是接下来，服务端需要通知客户端：我也没话说了，要不先挂了？下次再说？。这是第三步挥手。

　　 最后，客户端收到了服务端的消息，并说：好的，那挂了吧，下次再说。于是服务端挂电话，然后客户端也挂电话。TCP断开连接。

最后说明：以上内容纯自己手打，内容参考于以下两篇博客后自己做的总结巩固。

　　　　　https://blog.csdn.net/zixiaomuwu/article/details/60965466

　　　　　https://www.cnblogs.com/shihaochangeworld/p/5770294.html