TCP的三次握手和四次挥手

关于 TCP 的 三次握手

关于 TCP 协议

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

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

关于 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 告诉服务器端 收到！