TCP 三次握手和四次挥手

常见的 HTTP 请求类型

一、TCP 报文格式

其中比较重要的字段有：

1️⃣序号(sequence number)：Seq，占 32 位，用来标识从 TCP 源端向目的端发送的字节流，发起方发送数据时对此进行标记。
2️⃣确认号(acknowledgement number)：Ack，占 32 位，只有 ACK 标志位为 1 时，确认序号字段才有效，Ack=Seq+1。
3️⃣标志位(Flags)：共 6 个，即 URG、ACK、PSH、RST、SYN、FIN 等。具体含义如下：

1. URG：紧急指针(urgent pointer)有效。
2. ACK：确认序号有效。
3. PSH：接收方应该尽快将这个报文交给应用层。
4. RST：重置连接。
5. SYN：发起一个新连接。
6. FIN：释放一个连接。

注意：切记不要将确认号 Ack 与标志位中的 ACK 搞混了。确认方Ack=发起方Seq+1，两端配对。

二、TCP 三次握手(Three-Way Handshake)

TCP 名为传输控制协议，是一种可靠的传输层协议，IP 协议号为 6。原则上任何数据传输都无法确保绝对可靠，三次握手只是确保可靠的基本需要。在 TCP/IP 中，TCP 提供可靠的连接服务，采用三次握手建立一个连接。这个连接必须是一方主动打开，另一方被动打开的。握手之前主动打开连接的客户端结束 CLOSED 阶段，被动打开的服务器也结束 CLOSED 阶段，并进入 LISTEN 阶段。随后开始“三次握手”：

1️⃣第一次握手：客户端向服务器发送一段 TCP 报文，包括：

1. 标志位为 SYN，表示“请求建立新连接”。
2. 序号为 Seq=x (x一般为1)。
3. 随后客户端进入 SYN_SENT 阶段，等待服务器确认。

2️⃣第二次握手：服务器接收到来自客户端的 TCP 报文之后，结束 LISTEN 阶段。并返回一段 TCP 报文，包括：

1. 标志位为 SYN 和 ACK，表示“确认客户端的报文 Seq 有效，服务器能正常接收客户端发送的数据，并同意创建新连接”。
2. 序号为 Seq=y。
3. 确认号为 Ack=x+1表示收到客户端的 Seq 并将其值 +1 作为自己确认号 Ack 的值。随后服务器进入 SYN-RCVD 阶段。

3️⃣第三次握手：客户端接收到来自服务器的确认收到数据的 TCP 报文之后，明确了从客户端到服务器的数据传输是正常的，结束 SYN-SENT 阶段。并返回最后一段 TCP 报文。其中：

1. 标志位为 ACK，表示“确认收到服务器同意连接的信号”
2. 序号为 Seq=x+1表示收到服务器的确认号 Ack，并将其值作为自己的序号值；
3. 确认号为 Ack=y+1表示收到服务器序号 Seq，并将其值 +1 作为自己的确认号 Ack 的值；
4. 随后客户端进入 ESTABLISHED 阶段。

服务器收到来自客户端的“确认收到服务器数据”的 TCP 报文之后，明确了从服务器到客户端的数据传输是正常的。结束 SYN-SENT 阶段，进入 ESTABLISHED 阶段。

在客户端与服务器传输的 TCP 报文中，双方的确认号 Ack 和序号 Seq 的值，都是在彼此 Ack 和 Seq 值的基础上进行计算的，这样做保证了 TCP 报文传输的连贯性。一旦出现某一方发出的 TCP 报文丢失，便无法继续“握手”，以此确保了“三次握手”的顺利完成。

此后客户端和服务器进行正常的数据传输。这就是“三次握手”的过程。通过这样的三次握手，客户端与服务端建立起可靠的双工的连接，开始传送数据。 三次握手的最主要目的是保证连接是双工的，可靠更多的是通过重传机制来保证的。

为什么一定要进行三次握手来保证连接是双工的呢，一次或两次不行么？举个例子：把客户端比作男孩，服务器比作女孩。用他们的交往来说明“三次握手”过程：

1. 男孩喜欢女孩，写了一封信告诉女孩：请和我交往吧。写完信之后，男孩焦急地等待，因为不知道信能否顺利传达给女孩。

2. 女孩收到男孩的情书后，心花怒放，于是给男孩写了一封回信：我收到你的情书了，我也喜欢你，我愿意和你交往。写完信之后，女孩也焦急地等待，因为不知道回信能否能顺利传达给男孩。

3. 男孩收到回信之后很开心，因为发出的情书女孩收到了，并且从回信中知道了女孩喜欢自己，并且愿意和自己交往。然后男孩又写了一封信告诉女孩：你的心意和信我都收到了，谢谢你，还有我爱你！

女孩收到男孩的回信之后，也很开心，因为发出的情书男孩收到了。由此男孩女孩双方都知道了彼此的心意，之后就快乐地交流起来了。

这就是通俗版的“三次握手”，期间一共往来了三封信也就是“三次握手”，以此确认两个方向上的数据传输通道是否正常。

同理对于 TCP 为什么需要进行三次握手，可以这样理解：为了保证服务端能收接受到客户端的信息并能做出正确的应答而进行前两次(第一次和第二次)握手，为了保证客户端能够接收到服务端的信息并能做出正确的应答而进行后两次(第二次和第三次)握手。

三、为什么要进行第三次握手

为了防止服务器开启一些无用的连接增加服务器开销以及防止已失效的连接请求报文段突然又传送到了服务端产生错误。

由于网络传输是有延时的(要通过网络光纤和各种中间代理服务器)，在传输的过程中，比如客户端发起了 SYN=1 创建连接的请求(第一次握手)。

如果服务器就直接创建了这个连接并返回包含 SYN、ACK 和 Seq 等内容的数据包给客户端，这个数据包因为网络传输的原因丢失了，丢失之后客户端就一直没有接收到服务器返回的数据包。

客户端可能设置了一个超时时间，时间到了就关闭了连接创建的请求。再重新发出创建连接的请求，而服务器是不知道的，如果没有第三次握手告诉服务器“客户端收得到服务器响应的数据”的话，服务器是不知道“客户端有没有接收到服务器返回的信息”的。这个过程可理解为：

这样没有给服务器一个创建还是关闭连接端口的请求，服务器的端口就一直开着，等到客户端因超时重新发出请求时，服务器就会重新开启一个端口连接。那么服务器上没有接收到请求数据的上一个端口就一直开着，长此以往，这样的端口多了，就会造成服务器开销的严重浪费。

还有一种情况是已经失效的客户端发出的请求信息，由于某种原因传输到了服务器，服务器以为是客户端发出的有效请求，接收后产生错误。

所以需要“第三次握手”来确认这个过程，让客户端和服务器能够及时地察觉到因为网络等一些问题导致的连接创建失败，这样服务器的端口就可以关闭了不用一直等待。

也可以这样理解：“第三次握手”是客户端向服务器发送数据，这个数据就是要告诉服务器，客户端有没有收到服务器“第二次握手”时传过去的数据。若发送的这个数据是“收到了”的信息，接收后服务器就正常建立 TCP 连接，否则建立 TCP 连接失败，服务器关闭连接端口。由此减少服务器开销和接收到失效请求发生的错误。

四、TCP 四次挥手(Four-Way Wavehand)

所谓的四次挥手即 TCP 连接的释放(解除)。连接的释放必须是一方主动释放，另一方被动释放。客户端主动释放连接图解：

挥手之前主动释放连接的客户端结束 ESTABLISHED 阶段。随后开始“四次挥手”：

1️⃣首先客户端想要释放连接，向服务器发送一段 TCP 报文，其中：

1. 标记位为 FIN，表示“请求释放连接”。
2. 序号为 Seq=U。
3. 随后客户端进入 FIN-WAIT-1 阶段，即半关闭阶段。并且停止在客户端到服务器方向上发送数据，但是客户端仍然能接收从服务器传输过来的数据。

注意：这里不发送的是正常连接时传输的数据(非确认报文)，而不是一切数据，所以客户端仍然能发送 ACK 确认报文。

2️⃣服务器接收到从客户端发出的 TCP 报文之后，确认了客户端想要释放连接，随后服务器结束 ESTABLISHED 阶段，进入 CLOSE-WAIT 阶段(半关闭状态)并返回一段 TCP 报文，其中：

1. 标记位为 ACK，表示“接收到客户端发送的释放连接的请求”。
2. 序号为 Seq=V。
3. 确认号为 Ack=U+1，表示是在收到客户端报文的基础上，将其序号 Seq 的值 +1 作为本段报文确认号 Ack 的值。
4. 随后服务器开始准备释放服务器到客户端方向上的连接。

客户端收到从服务器发出的 TCP 报文之后，确认了服务器收到了客户端发出的释放连接请求，随后客户端结束 FIN-WAIT-1 阶段，进入 FIN-WAIT-2 阶段。

前"两次挥手"既让服务器知道了客户端想要释放连接，也让客户端知道了服务器收到了自己想要释放连接的请求。于是，可以确认关闭客户端到服务器方向上的连接了。

3️⃣服务器自从发出 ACK 确认报文之后，经过 CLOSED-WAIT 阶段，做好了释放服务器到客户端方向上的连接准备，再次向客户端发出一段 TCP 报文，其中：

1. 标记位为 FIN，ACK，表示“已经准备好释放连接了”。注意：这里的 ACK 并不是确认收到服务器报文的确认报文。
2. 序号为 Seq=W。
3. 确认号为 Ack=U+1。表示是在收到客户端报文的基础上，将其序号 Seq 值 +1 作为本段报文确认号 Ack 的值。

随后服务器结束 CLOSE-WAIT 阶段，进入 LAST-ACK 阶段。并且停止在服务器到客户端的方向上发送数据，但是服务器仍然能够接收从客户端传输过来的数据。

4️⃣客户端收到从服务器发出的 TCP 报文，确认了服务器已做好释放连接的准备，结束 FIN-WAIT-2 阶段，进入 TIME-WAIT 阶段，并向服务器发送一段报文，其中：

1. 标记位为 ACK，表示“接收到服务器准备好释放连接的信号”。
2. 序号为 Seq=U+1。表示是在收到了服务器报文的基础上，将其确认号 Ack 值作为本段报文序号的值。
3. 确认号为 Ack=W+1。表示是在收到了服务器报文的基础上，将其序号 Seq 值作为本段报文确认号的值。

随后客户端开始在 TIME-WAIT 阶段等待 2MSL。

服务器收到从客户端发出的 TCP 报文之后结束 LAST-ACK 阶段，进入 CLOSED 阶段。由此正式确认关闭服务器到客户端方向上的连接。

客户端等待完 2MSL 之后，结束 TIME-WAIT 阶段，进入 CLOSED 阶段，由此完成“四次挥手”。

后“两次挥手”既让客户端知道了服务器准备好释放连接了，也让服务器知道了客户端收到了自己准备好释放连接了。于是，可以确认关闭服务器到客户端方向上的连接了，由此完成“四次挥手”。

与“三次挥手”一样，在客户端与服务器传输的 TCP 报文中，双方的确认号 Ack 和序号 Seq 的值，都是在彼此 Ack 和 Seq 值的基础上进行计算的，这样做保证了 TCP 报文传输的连贯性，一旦出现某一方发出的 TCP 报文丢失，便无法继续"挥手"，以此确保了"四次挥手"的顺利完成。

把客户端比作男孩，服务器比作女孩。通过他们的分手来说明“四次挥手”过程。

1. “第一次挥手”：日久见人心，男孩发现女孩变了，于是决定分手，随即写了一封信告诉女孩。
2. “第二次挥手”：女孩收到信之后，知道了男孩要和自己分手，立马给男孩写了一封回信：分手就分手，给我点时间，我要把你的东西整理好，全部还给你！男孩收到女孩的第一封信之后，明白了女孩知道自己要和她分手。随后等待女孩把自己的东西收拾好。
3. “第三次挥手”：过了几天，女孩把男孩送的东西都整理好了，于是再次写信给男孩：你的东西我整理好了，快把它们拿走。
4. “第四次挥手”：男孩收到女孩第二封信之后，知道了女孩收拾好东西了，可以正式分手了，于是再次写信告诉女孩：我知道了，这就去拿回来！这里双方都有各自的坚持。女孩自发出第二封信开始，限定一天内收不到男孩回信，就会再发一封信催促男孩来取东西！男孩自发出第二封信开始，限定两天内没有再次收到女孩的信就认为，女孩收到了自己的第二封信；若两天内再次收到女孩的来信，就认为自己的第二封信女孩没收到，需要再写一封信，再等两天……

倘若双方信都能正常收到，最少只用四封信就能彻底分手！这就是“四次挥手”。

五、为什么建立连接是三次握手，而关闭连接却是四次挥手？

TCP 建立连接时之所以“三次握手”，是因为在第二次“握手”过程中，服务器发送给客户端的 TCP 报文是以 SYN 与 ACK 作为标志位的。SYN 是请求连接标志，表示服务器同意建立连接；ACK 是确认报文，表示告诉客户端，服务器收到了它的请求报文。即 SYN 建立连接报文与 ACK 确认接收报文是在同一次“握手”当中传输的，所以“三次握手”不多也不少，正好让双方明确彼此信息互通。

TCP 释放连接时之所以需要“四次挥手”，是因为 FIN 释放连接报文与 ACK 确认接收报文是分别由第二次和第三次“握手”传输的。为何建立连接时一起传输，释放连接时却要分开传输？

建立连接时，被动方服务器结束 CLOSED 阶段进入“握手”阶段并不需要任何准备，可以直接返回 SYN 和 ACK 报文，开始建立连接。释放连接时，被动方服务器，突然收到主动方客户端释放连接的请求时并不能立即释放连接，因为还有必要的数据需要处理，所以服务器先返回 ACK 确认收到报文，经过 CLOSE-WAIT 阶段准备好释放连接之后，才能返回 FIN 释放连接报文。所以是“三次握手”，“四次挥手”。

六、为什么客户端在 TIME-WAIT 阶段要等 2MSL

为的是确认服务器是否收到客户端发出的 ACK 确认报文。

当客户端发出最后的 ACK 确认报文时，并不能确定服务器能够收到该段报文。所以客户端在发送完 ACK 确认报文之后，会设置一个时长为 2MSL 的计时器。MSL 指的是 Maximum Segment Lifetime：一段TCP报文在传输过程中的最大生命周期。2MSL 即是服务器发出为 FIN 报文和客户端发出的 ACK 确认报文所能保持有效的最大时长。

服务器在 1MSL 内没有收到客户端发出的 ACK 确认报文，就会再次向客户端发出 FIN 报文；

1. 如果客户端在 2MSL 内，再次收到了来自服务器的 FIN 报文，说明服务器由于各种原因没有接收到客户端发出的 ACK 确认报文。客户端再次向服务器发出 ACK 确认报文，计时器重置，重新开始 2MSL 的计时。
2. 否则客户端在 2MSL 内没有再次收到来自服务器的 FIN 报文，说明服务器正常接收了 ACK 确认报文，客户端可以进入 CLOSED 阶段，完成“四次挥手”。

所以，客户端要经历时长为 2SML 的 TIME-WAIT 阶段。这也是为什么客户端比服务器晚进入 CLOSED 阶段的原因。