TCP三次握手四次挥手

TCP三次握手四次回收相关知识

下面的连接是我看的讲解感觉很不错
相关知识连接:
https://blog.csdn.net/qq_32534441/article/details/89598839

三次握手步骤:

• 第一次:建立连接客户端发送请求连接的包syn(syn=j)到服务器,等待服务器确认
• 第二次:服务器收到syn包之后需要确认客户端的SYN(ack=j+1),同时向客户端发送确认包syn(SYN+ACK)包(syn=k)并确认了自己和服务器的接收发送功能都正常,确认已经建立连接
• 第三次:客户端收到确认包SYN+ACK之后向服务器发送确认包ACK(ack+k+1),发送完毕后服务器确认建立连接

至此客户端与服务器建立连接成功

(SYN:同步序列编号)

相关图解:

• 面试问题有为什么不是四次或者是两次

  1. 三次握手双方就已经确认建立连接了而且是双方都确认了接受和发送正常,如果是四次握手的话就显得有点多余了
  2. 而如果是两次握手
     按照两次握手的协议:客户端发送连接请求syn包给服务器
     服务器接收到包之后发送确认包ack,
     这时候按照协议服务器已经确认连接已经建立开始发送数据信息,
     然而客户端并没有确立连接,在服务器发送到客户端的确认包ack丢失的情况下,
     客户端并不知道服务器是否收到包,甚至怀疑自己发送的连接请求包并没有被服务器接收到,
     因此客户端会忽视所有来自服务器的数据,仅仅等待连接确认
     然而服务器发送的数据超市会不断地再次发送,这就形成了死锁

  所以两次握手不可行

• 还有个问题就是如果已经建立了连接客户端突然出现故障的情况
  TCP中设有保活计时器,通常为2小时,服务器每次收到客户端请求就会复位这个计时器,若两小时内没有收到客户端的任何数据,服务器就会
  每隔75秒发送一个探测报文段,若连续发送10个报文仍没反应,服务器就会确认客户端出现故障,并关闭连接.

四次挥手

四次挥手的步骤详细内容挺多的,但理解起来不难

图解:

这里我就直接截取网页上的图作为参考
自己画的太丑了

• 过程与三次握手差不多
  但多了一次等待阶段
  为什么要多一次?
  是因为建立连接时客户端发送连接请求,服务器可以直接发送ACK+SYN确认,而断开连接时客户端发送FIN报文后,服务器需要先发送一个确认的ack告诉客户端我收到你的FIN了,然后服务器要等到所有的请求发送完毕才可以发送FIN报文,不能同时发送ack和FIN报文 所以要四次挥手

• 最后为什么会有个经过2MSL(最大报文生存时间)的TIME_WAIT状态,之后才会CLISE
  最后一个阶段客户端发送ACK确认的时候这个ACK可能会丢失,这时候服务端未接收到关闭确认,就不会关闭,这时候客户端已经关闭,这就导致浪费了服务器资源
  这个等待状态就是为了解决这个问题
  在服务器没收到ACK的情况下,服务器将不断地发送FIN片段给客户端,
  在2MSL时间内客户端如果再次收到FIN就会再次发送ACK并重置计时器继续等待2MSL,如果直到2MSL都没有收到FIN就确认ACK成功被服务器接收,此时就会结束TCP连接