三次握手和四次挥手

关于TCP的 三次握手

关于TCP协议

TCP（Transmission Control Protocol，传输控制协议） 是一种面向连接的，可靠的，基于字节流的传输层通信协议。

与之对应的是UDP（User Datagram Protocol，用户数据协议），是不可靠的传输层协议。

关于TCP报文

tcp报文

在了解什么三次握手之前，我们需要知道TCP报文的一些知识。

  • 源端口号
  • 目的端口号
  • ACK : TCP协议规定，只有ACK=1时有效，也规定连接建立后所有发送的报文的ACK必须为1。
  • SYN(SYNchronization) : 在连接建立时用来同步序号。当SYN=1而ACK=0时，表明这是一个连接请求报文。对方若同意建立连接，则应在响应报文中使SYN=1和ACK=1. 因此, SYN置1就表示这是一个连接请求或连接接受报文。

生活中的例子说明什么是三次握手

直接给出专业名词确实很难理解，那么就举个生活中的例子：

  • 小明说: 你好吗?
  • 小红说：我很好，你呢？
  • 小明说：我也是！

这段话中，

小明和小红 就分别是 源端口号 和 目的端口号 ，

你好吗？ 是询问对方的， 所以是 SYN ， 而 seq 就可以理解为询问的内容。

我很好，你呢？ 中 我很好 是回应对方的，所以是 ACK，而 ack 就可以理解为 回应的内容 ， 你呢? 是询问对方的， 所以是 SYN

我也是！ 同样 回应对方的， 所以是 ACK

而这整个流程就是 三次握手 ！

三次握手

三次握手流程

三次握手流程
这个过程中，分别是：

  1. 客户端发送 SYN = 1 的 询问报文给服务器端， seq 是 x， 进入 SYN_SENT 状态
  2. 服务器回应一个 ACK =1 , SYN =1 的应答 + 询问报文。 应答号ack是 x+1 , 询问号seq是 y， 进入 SYN_RCVD 状态
  3. 客户端收到后，回应一个 ACK = 1的应答报文， 应答号是 y+1 , 进入 ESTAB-LISHED 状态

为什么不是俩次握手 或者是 四次握手呢？

假设如果是 俩次握手的话， 那么客户端发送请求报文A， 因为网络延迟的原因，服务器没收到， 然后客户端发送第二遍报文A , 服务器终于收到了然后建立连接等待客户端发送数据， 然后客户端正常发送数据。 但是过了一会 第一次发送的报文A也到达了服务器，那么服务器就会再次建立连接等待客户端发送数据，而客户端并不知情，这样就导致 服务器资源的浪费了。

TCP作为一种可靠的传输控制协议，其核心思想就是：既要保证数据的可靠传输，又要提高传输的效率，而用三次恰恰可以满足以上俩方面的需求。

所以三次握手能解决的问题，为什么需要画蛇添足呢？

四次挥手

当客户端和服务器端建立TCP连接（三次握手）后，客户端请求HTTP，服务器端响应给他，等到客户端收到响应后。客户端和服务器端会断开 TCP连接。 而断开TCP连接需要经过四次挥手这个流程。

如下图：

四次挥手

  1. 客户端发送一个 FIN ， 告诉服务器关闭连接
  2. 服务器端发送一个 ACK ，告诉客户端 已经收到。
  3. 然后服务器端通知 其他应用程序关闭连接，等程序关闭后，服务器会发送一个 FIN ，告诉 客户端 我已断开连接
  4. 客户端再发送 一个ACK 告诉服务器端 收到！