详解 TCP 连接的“ 三次握手 ”与“ 四次挥手 ”

1: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等。具体含义如下：

         URG：紧急指针（urgent pointer）有效。ACK：确认序号有效。PSH：接收方应该尽快将这个报文交给应用层。

         RST：重 置连接。SYN：发起一个新连接。FIN：释放一个连接。

需要注意的是：

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

2:TCP三次握手机制中的seq和ack的值到底是什么？

1. seq是序列号，这是为了连接以后传送数据用的，
2. ack是对收到的数据包的确认，值是等待接收的数据包的序列号。
3. 在第一次消息发送中，A随机选取一个序列号x作为自己的初始序号发送给B；
4. 第二次消息B使用ack对A的数据包进行确认，因为已经收到了序列号为x的数据包，准备接收序列号为x+1的包，所以ack=x+1，同时B告诉A自己的初始序列号，就是seq=y；
5. 第三条消息A告诉B收到了B的确认消息并准备建立连接，A自己此条消息的序列号是x+1，所以seq=x+1，而ack=y+1是表示A正准备接收B序列号为y+1的数据包。

seq是数据包本身的序列号；ack是期望对方继续发送的那个数据包的序列号。

3:TCP的三次握手（Three-Way Handshake）

1.”三次握手”的详解

所谓的三次握手即TCP连接的建立。这个连接必须是一方主动打开，另一方被动打开的。以下为客户端主动发起连接的图解：

 

握手之前主动打开连接的客户端结束CLOSED阶段，被动打开的服务器端也结束CLOSED阶段，并进入LISTEN阶段。随后开始“三次握手”：

（1）首先客户端向服务器端发送一段TCP报文，其中：

         标记位为SYN，表示“请求建立新连接”;序号为Seq=X（X一般为1）；随后客户端进入SYN-SENT阶段。

（2）服务器端接收到来自客户端的TCP报文之后，结束LISTEN阶段。并返回一段TCP报文，其中：

         标志位为SYN和ACK，表示“确认客户端的报文Seq序号有效，服务器能正常接收客户端发送的数据，

         并同意创建新连接”     （即告诉客户端，服务器收到了你的数据）；

         序号为Seq=y；确认号为Ack=x+1，表示收到客户端的序号Seq并将其值加1作为 自己确认号Ack的值；

         随后服务器端进入  SYN-RCVD阶段。

（3）客户端接收到来自服务器端的确认收到数据的TCP报文之后，明确了从客户端到服务器的数据传输是正常的，

         结束SYN-SENT阶段。并返回最后一段TCP报文。其中：

        标志位为ACK，表示“确认收到服务器端同意连接的信号”（即告诉服务器，我知道你收到我发的数据了）；

        序号为Seq=x+1，表示收到服务器端的确认号Ack，并将其值作为自己的序号值；

        确认号为Ack=y+1，表示收到服务器端序号Seq，并将其值加1作为自己的确认号Ack的值；

        随后客户端进入ESTABLISHED阶段。服务器收到来自客户端的“确认收到服务器数据”的TCP报文之后，

        明确了从服务器到客户端的数据传输是正常的。结束SYN-SENT阶段，进入ESTABLISHED阶段。

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

此后客户端和服务器端进行正常的数据传输。这就是“三次握手”的过程。

4:“三次握手”的通俗理解 

 

举个栗子：把客户端比作男孩，服务器比作女孩。用他们的交往来说明“三次握手”过程：

（1）男孩喜欢女孩，于是写了一封信告诉女孩：我爱你，请和我交往吧！;写完信之后，男孩焦急地等待，

         因为不知道信能否顺  利传达给女孩。

（2）女孩收到男孩的情书后，心花怒放，原来我们是两情相悦呀！于是给男孩写了一封回信：我收到你的情书了，

         也明白了你的心意，其实，我也喜欢你！我愿意和你交往！;

         写完信之后，女孩也焦急地等待，因为不知道回信能否能顺利传达给男孩。

（3）男孩收到回信之后很开心，因为发出的情书女孩收到了，并且从回信中知道了女孩喜欢自己，并且愿意和自己交往。

         然后男孩又写了一封信告诉女孩：你的心意和信我都收到了，谢谢你，还有我爱你！

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

         之后就快乐地交流起来了~~

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

5:为什么要进行第三次握手？

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

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

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

客户端可能设置了一个超时时间，时间到了就关闭了连接创建的请求。再重新发出创建连接的请求，而服务器端是不知道的，如果没有第三次握手告诉服务器端客户端收的到服务器端传输的数据的话，

服务器端是不知道客户端有没有接收到服务器端返回的信息的。

这个过程可理解为：

(1)无差错情况:

这种正常情况是没有问的 

(2)超时重传情况: 

但超时重传情况就会出现问题:

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

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

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

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

6:TCP的四次挥手（Four-Way Wavehand）

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

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

         标记位为FIN，表示“请求释放连接“；序号为Seq=U；随后客户端进入FIN-WAIT-1阶段，即半关闭阶段。

         并且停止在客户端到服务器端方向上发送数据，但是客户端仍然能接收从服务器端传输过来的数据。

（2）服务器端接收到从客户端发出的TCP报文之后，确认了客户端想要释放连接，随后服务器端结束ESTABLISHED阶段，

         进入CLOSE-WAIT阶段（半关闭状态）并返回一段TCP报文，其中：

         标记位为ACK，表示“接收到客户端发送的释放连接的请求”；序号为Seq=V；确认号为Ack=U+1，

         表示是在收到客户端报文的基础上，将其序号Seq值加1作为本段报文确认号Ack的值；

         随后服务器端开始准备释放服务器端到客户端方向上的连接。客户端收到从服务器端发出的TCP报文之后，

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

前"两次挥手"既让服务器端知道了客户端想要释放连接，也让客户端知道了服务器端了解了自己想要释放连接的请求。

于是，可以确认关闭客户端到服务器端方向上的连接了

（3）服务器端自从发出ACK确认报文之后，经过CLOSED-WAIT阶段，做好了释放服务器端到客户端方向上的连接准备，

         再次向客户端发出一段TCP报文，其中：

         标记位为FIN，ACK，表示“已经准备好释放连接了”。注意：这里的ACK并不是确认收到服务器端报文的确认报文。

         序号为Seq=W；确认号为Ack=U+1；表示是在收到客户端报文的基础上，将其序号Seq值加1作为本段报文确认号Ack

         的值。

         随后服务器端结束CLOSE-WAIT阶段，进入LAST-ACK阶段。并且停止在服务器端到客户端的方向上发送数据，

         但是服务器端仍然能够接收从客户端传输过来的数据。

（4）客户端收到从服务器端发出的TCP报文，确认了服务器端已做好释放连接的准备，结束FIN-WAIT-2阶段，

         进入TIME-WAIT阶段，并向服务器端发送一段报文，其中：

         标记位为ACK，表示“接收到服务器准备好释放连接的信号”。序号为Seq=U+1；表示是在收到了服务器端报文的基础上，

         将其确认号Ack值作为本段报文序号的值。确认号为Ack=W+1；表示是在收到了服务器端报文的基础上，

         将其序号Seq值作为本段报文确认号的值。随后客户端开始在TIME-WAIT阶段等待2MSL

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

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

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

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

7:“四次挥手”的通俗理解

这里双方都有各自的坚持。女孩自发出第二封信开始，限定一天内收不到男孩回信，就会再发一封信催促男孩来取东西！男孩自发出第二封信开始，限定两天内没有再次收到女孩的信就认为，女孩收到了自己的第二封信；若两天内再次收到女孩的来信，就认为自己的第二封信女孩没收到，需要再写一封信，再等两天…..

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

8.为什么“握手”是三次，“挥手”却要四次？

为什么是四次挥手，不是三次或五次？

首先，主动关闭方是会先发送FIN包给被动关闭方的，这个主动关闭方可能是客户端也可能是服务端，只不过大部分的情况都是客户端主动关闭。

那为啥是四次？？？我们以客户端主动关闭举例

首先我们已经知道了TCP的连接是全双工的，可以发送也可以接收，主动关闭方发送FIN，表明主动方已经没有数据需要发送了，告诉被动方我要断了，被动方回一个ACK，表明已知晓主动方无数据，准备断开了。

但是被动方也就是服务端可能依旧有数据还没有发送完毕，客户端没有数据发送不代表服务端没有数据发送啊，于是等服务端数据发送完毕。等到服务端这一端数据发完了，就可以彻底断开连接的，所以服务端也发了一个FIN包，告诉客户端我工作做完了，我也要关了，等到服务端收到客户端的ACK或者超出等待时间那么就断开连接，此时的连接才算真正意义上的断开。

三次的话如果类比三次握手，在第二次挥手的时候直接发FIN + ACK明显不合理，因为被动方可能没有数据发送完，你这么关太草率了，所以需要四次，至于五次，四次就能断开了，还来五次。。。多此一举。。