> 文章列表 > 三次握手和四次挥手

三次握手和四次挥手

三次握手和四次挥手

三次握手和四次挥手

  • 1. TCP和UDP的共同点
  • 2. TCP的三个关键步骤
    • 2.1 三次握手
      • 2.1.1 为什么要三次握手而不是两次握手
    • 2.2 传输确认
    • 2.3 四次挥手
      • 2.3.1 为什么客户端需要等待超时时间

1. TCP和UDP的共同点

TCP和UDP都是工作在传输层

他们的目标都是在程序之间传输数据。

2. TCP的三个关键步骤

三次握手、传输确认、四次挥手

2.1 三次握手

三次握手和四次挥手
建立连接的过程,当客户端向服务端发起连接时:

先发一包连接请求数据过去询问一下能否与你建立连接。这包数据我们称之为SYN包

如果对方同意连接,则回复一包SYN+ACK包

客户端收到之后回复一包ACK包。

因为这个过程中互相发送了三包数据,所以称之为三次握手

2.1.1 为什么要三次握手而不是两次握手

服务端回复完SYN+ACK之后就建立连接,这是为了防止已失效的请求报文突然又传到服务器引起错误

假设采用两次握手建立连接,客户端向服务端发送了一个SYN包来请求建立连接。因为某些未知的原因并没有到达服务器。

在某个中间节点产生了滞留,为了建立连接客户端会重发SYN包,这次的数据包正常送达。服务端回复SYN+ACK建立了连接。

但是第一包数据阻塞的网络节点突然恢复,第一包SYN又送达到服务端,这时服务端会误认为是客户端又发起了一个新的连接,从而在两次握手之后进入等待数据状态。服务端认为是两个连接,而客户端认为是一个连接。造成了状态不一致,如果在三次握手的情况下,服务端收不到最后的ACK包,自然不会认为连接建立成功。

所以三次握手本质上来说就是为了解决网络信道不可靠的问题。

2.2 传输确认

三次握手和四次挥手
这样一问一答的发送方式,能够使发送端确认发送的数据已经被对方收到。发送端也可以一次发送连续的多包数据。接收端只需要回复一次ACK就可以了。

这样发送端可以把待发送的数据分割成一系列的碎片发送到对端。对端根据序列号和长度在接收后重构出来完整的数据。

假设其中丢失了某些数据包,在接收端可以要求重传,比如丢失了100-199这100个字节,接收端向发送端发送ACK=100的报文,发送端收到后重传这一包数据,接收端进行补齐。

以上过程不区分客户端和服务端。tcp连接是全双工的。对于两端来说均采用上述机制。

2.3 四次挥手

处于连接中的客户端和服务端都可以发起关闭连接的请求。

此时需要四次挥手来进行连接关闭。

假设客户端主动发起连接关闭请求,他需要客户端发FIN包,表示要关闭连接。自己进入终止等待1状态。这是第一次挥手

三次握手和四次挥手

服务端收到FIN包,发送一个ACK包,表示自己进入了关闭等待状态。客户端进入终止等待2状态。这是第二次挥手

三次握手和四次挥手

服务端此时还可以发送未发送的数据,而客户端还可以接收数据。待服务端发送完数据之后,发送一包FIN进入最后确认状态。这是第三次挥手

三次握手和四次挥手

客户端收到之后回复ACK包,进入超时等待状态,经过超时时间后关闭连接。服务端收到ACK后立即关闭连接。这是第四次挥手

三次握手和四次挥手

2.3.1 为什么客户端需要等待超时时间

这是为了保证对方已收到ACK包。因为假设客户端送完最后一包ACK包后就释放了连接,一旦ACK包在网络中丢失服务端将一直停留在最后确认状态

如果客户端发送最后一包ACK包后等待一段时间,这时服务端因为没有收到ACK包会重发FIN包。客户端会响应这个FIN包,重发ACK包并刷新超时时间。这个机制和三次握手一样。也是为了保证在不可靠的网络链路中进行可靠的连接断开确认。

三次握手和四次挥手

参考资料:一条视频讲清楚TCP协议与UDP协议-什么是三次握手与四次挥手