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

posted @ 2018-06-15 14:53 萝卜爱吃青菜 阅读(...) 评论(...) 编辑 收藏