TCP 三次握手和四次挥手

TCP 三次握手和四次挥手

三次握手

TCP 三次握手和四次挥手_第1张图片
三次握手

如图所示,客户端主动打开连接,服务端被动打开连接。连接过程如下:

  1. 客户端发送连接请求报文段,同步位 SYN = 1,同时选择一个初始序号 seq = x(TCP 协议规定,SYN 报文段,也就是 SYN = 1 的报文段不能携带数据,但是会消耗一个序号),这时客户端进入 SYN-SENT (同步已发送)状态。

  2. 服务端接收到连接请求报文段以后,如果同意连接,则向客户端发送确认。确认报文段中 SYN 位和 ACK 位都置为 1,确认号是 ack = x + 1,同时也为自己选择一个初始序号 seq = y,服务端进入到 SYN-RCVD(同步收到)状态。

  3. 客户端收到服务端的确认号以后,还要向服务端发送确认。确认报文段的 ACK 置 1,确认号 ack = y + 1,自己的序号 seq = x + 1(TCP 协议规定,ACK 报文段可以携带数据,但是如果不携带数据就不消耗序号,下一个数据报文段的序号仍然是 seq = x + 1),这时 TCP 连接已经建立,客户端进入到 ESTABLISHED(已建立连接)状态,服务端接收到确认报文后也进入到 ESTABLISHED 状态。

为什么需要第三次握手?

因为要防止已失效的连接请求报文突然又传送到了服务端,因而产生错误。

如果是两次握手,当客户端发送请求给服务端,但是可能因为网络原因请求没有到达,客户端再次发送请求,然后收到了确认,建立了连接。当数据传输完成后客户端和服务端连接关闭,此时之前那个失效的连接到达了服务端,服务端以为是客户端又发送了一次请求,因此给客户端返回了确认报文,如果是两次握手,那么客户端收到确认报文以后连接就建立了。

如果采用三次连接,服务端发送了响应报文,但是客户端不认识,就拒绝连接,这样连接就不会建立。

四次挥手

TCP 三次握手和四次挥手_第2张图片
四次挥手

如图所示,客户端主动关闭连接,服务端被动关闭:

  1. 客户端发送断开连接请求,报文段首部 FIN = 1,序号 seq = u(等于前面已经传输过的数据的最后一个字节的序号 +1),这时客户端进入 FIN-WAIT-1(终止等待 1)状态,等待服务端的确认。

  2. 服务端收到连接释放报文段以后发出确认,确认号为 ack = u + 1,这个报文段自己的序号为 v(服务端前面已经传送过的数据的最后一个字节的序号 +1),然后服务端进入到 CLOSE-WAIT(关闭等待)状态,服务端进程通知上层应用进程,然后客户端到服务端这个方向的连接就释放了,这时 TCP 连接处于半关闭(half-close)状态,即客户端已经没有数据要发送了,服务端如果还有数据要发送,客户端仍然可以接收到。客户端收到服务端的确认后,进入到 FIN-WAIT-2(终止等待 2)状态,等待服务端发送释放连接报文段。

  3. 当服务端没有要发给客户端的数据以后,向客户端发送连接释放报文段,报文段首部 FIN = 1,假定当前服务端的序号为 w(在半关闭期间服务端可能又发送有数据),报文还需要加上上次已经发送过的确认号 ack = u + 1,这时服务端进入到 LAST-ACK(最后确认状态),等待客户端的确认。

  4. 客户端收到服务端的连接释放报文段以后需要发出确认,在确认报文段中将 ACK 置为 1,确认号 ack = w + 1,自己的序号 seq = u + 1,然后进入到 TIME-WAIT(时间等待)状态,此时连接还没有释放,必须经过时间等待计时器设置的时间 2MSL 后(这个时间可能有不同的长度),客户端才进去到 CLOSED 状态。

为什么客户端在 TIME-WAIT 状态必须等待 2MSL 时间?

  1. 为了保证客户端发送的最后一个 ACK 报文段能够到达服务端,处在 LAST-ACK 状态的服务端如果一定时间内收不到确认报文,就会超时重传连接释放报文段,如果客户端不等待,那么服务端就无法正常关闭。

  2. 防止已失效的连接请求报文段,客户端发送完最后一个 ACK 报文段以后,经过时间 2MSL,就可以使本次连接内所有的报文段都从网络中消失,下一次连接就不会出现旧的连接请求报文段。

你可能感兴趣的:(TCP 三次握手和四次挥手)