TCP连接的建立与释放（超详细）

前言：在计算机网络协议中，TCP只是其中一个，然而在网络使用中，TCP也是最离不开的协议之一，它的重要性毋庸置疑，最最重要的是，面试的重点就是它啊，呜呜~~，今天我们一起来看下TCP的连接建立与释放，相信很多小伙伴也想给他一次性整明白。

TCP连接的建立

下图给出TCP三次握手的过程：

在进入正文之前先让我们来复习复习几个选项位，待会儿会用到哦！！！

确认ACK

仅当ACK = 1 时确认号字段才有效。当ACK = 0 时，确认号无效。TCP规定：在连接建立后，所有传送的报文段都必须把ACK置为1。

同步SYN

在连接建立时用来同步序号。当 SYN = 1 而 ACK = 0 时，表名这是一个连接请求报文段。对方若同意建立连接，则应在响应的报文段中使 SYN = 1 和 ACK = 1 。

终止FIN

用来释放一个连接。当FIN = 1 时，表示此报文段的发送方的数据已经发送完毕，并要求释放运输连接。

在复习完这些选项之后，我们一起来聊聊TCP连接的建立：

如上图画出了TCP的建立连接过程。假定主机A运行的时TCP客户端，而B运行TCP服务器程序。途中主机下面的方框分别是TCP进程所处的状态。请注意，此时A是主动打开连接，B是被动打开连接。

1. 初始时候，客户端和服务端都处于 CLOSED （关闭）状态。当客户端需要给服务端发送数据包的时候，客户端主动打开连接。这个时候应该是通知了服务端，让服务端也打开连接，所以服务端是被动打开连接。打开连接之后，分别开始创建传输控制模块 TCB，接着服务端进入 LISTEN（监听）状态，等待客户端的连接请求。客户端也开始准备连接请求数据包，开始发送。客户端发送的第一个数据包是一个连接请求报文段，这个报文的内容如上图，是一个同步位SYN = 1，另一个是一个初始序号 seq = x 。TCP 规定，SYN = 1 的报文段不能携带数据，但要消耗一个序列号。客户端发送了这个报文之后，进入SYN-SENT（同步已发送）状态。

2.服务器端己收到这个数据包之后，知道有客户端请求连接。如果当前有资源，可以同意连接，则给客户端发送确认报文。这个确认报文的内容有：SYN=1（没有变化），seq=y（变成了服务端的序列号），新增ACK=1，ack = x + 1（客户端序列号+1）。这里 SYN=1，所以报文不能携带数据，同样消耗了服务端的一个序列号。然后服务端进入了 SYN-RCVD（同步收到）状态。

3.客户端收到服务端的确认报文之后，还需要给客户端发送一个客户端的确认报文。这个报文的内容是 ACK = 1，seq = x + 1，ack = y + 1。这里没有了 SYN 这个字段，所以这个报文可以携带数据。这个客户端确认报文发送出去之后，客户端进入ESTABLISHED（已建立连接）状态。服务端接收到这个数据包之后，也进入了 ESTABLISHED（已建立连接）状态。

上面给出的连接建立过程叫做 三次握手（three-way handshake） 。

提问： 正常来说，连接的建立只需要前面两次就足够了，为什么还要有一次客户端给服务器端的 ACK ？

1）这是因为，首先建立连接，必须要有两次握手吧，客户端主动一次，告知服务端，我想和你建立连接，然后看服务端是否同意。然后如果服务端同意的话，得给一个回复，然后开始等待客户端的数据包，这就是两次握手。如果这个时候就建立连接，客户端开始给服务端发送数据包，在正常情况下没啥问题。但是由于网络并不是100%任何时候都稳定，一旦因为某些原因导致服务端发送给客户端的确认报文丢失，那这个时候客户端收不到确认数据包，会误以为服务端不同意连接，不会给服务端发送数据包，但是这时候服务端已经在等待了。这样的差错会导致服务端一直处于等待状态，浪费资源。

2）而三次握手的话，客户端在确认服务端同意之后再发一次数据包给服务端，告知服务端，不管怎么样我都会给你发送数据包的。因为TCP协议中，建立连接之后，每一次发送数据包客户端都会等待服务端的确认信息，如果收不到某一个数据包的确认信息，客户端就会重发这个数据包。这样就不会发生差错了。

TCP的连接释放

前面说了TCP的连接建立过程是三次握手，现在我们来说释放过程，也就是我们常说的四次挥手。

话不多说，上图：

如上图所示，我们来详细说一下TCP的释放过程：

1、当TCP连接需要释放时，客户端和服务端都是处于 ESTABLISHED（已建立连接） 状态。此时，客户端数据发送完毕，想要结束连接了，主动发出连接释放请求数据包。这个数据包内容：Fin=1，seq=u（这个u是这个数据包之前一个数据包的序列号+1），客户端进入FIN-WAIT-1（终止等待1）状态，不在发送数据包，等待服务端的确认。

2、服务端接收到释放数据包之后发出确认，确认包中内容：确认号ack=u+1，序列号seq=v（这个v是服务端上一个发送的数据包的序列号+1），另一个是ACK=1。然后服务端进入CLOSE-WAIT（关闭等待）。这个时候客户端到服务端的连接已经结束了。但是TCP是全双工通信，因为这个时候是客户端主动发起的结束，在服务端这边可能还存在着数据没有完全发送给客户端，所以服务端到客户端仍然没有结束。客户端已经不能在发送数据了，如果服务端还有数据发送过来，客户端仍然要接收。

3、客户端收到服务端的确认之后，进入FIN-2（终止等待2）状态，等待服务端发送服务端发器的连接释放数据包。这时候服务端可能还有一些数据包要发送给客户端，客户端一一接收。最后，没有数据要发送了之后，服务端发送连接释放数据包，这个数据包内容：FIN=1，ACK=1，seq=w（因为在服务端回复客户端的连接请求（数据包的序列号是v）之后，可能仍然有其他数据包要发送，所以这里的w不一定是v+1），ack=u+1（确认号和上次回复客户端的请求释放连接的确认号一样）。接着服务端进入LAST-ACK（最后确认状态），等待客户端的确认。

4、客户端收到服务端的连接释放数据包之后，发出一个确认数据包，内容：ACK=1，seq=u+1，ack = w+1。然后客户端进入TIME-WAIT（时间等待）状态。这个时候TCP还没有释放。仍需要经过时间等待计时器设置的时间2MSL后，客户端才会进入CLOSED状态。MSL称为最长报文段寿命。RFC793建议把这个值设为2分钟，那这样的话，在客户端收到服务端的连接释放数据包之后，需要等待4分钟才能进入CLOSED状态。这显然时间太长了，不过这个值设为2分钟也只是建议，还是可以设置适合的时间的。最后服务端收到这个客户端的确认包之后就进入了CLOSED状态。显然，服务端一般先于客户端进入关闭状态。

客户端需要等待 2MSL 时间才完全结束TCP连接的原因：

1）为了保证客户端发送的最后一个确认包能正确到达服务端。因为如果由于网络原因丢失的话，服务端会重新发送连接释放数据包，在等待过程中，如果真的发生这种情况就可以得到处理。客户端每接收到一次服务端发送来的接释放数据包都会重新设置时间等待计时器，然后等待2MSL时间才完全结束TCP连接。

2）等待才2MSL时间完全结束TCP连接，可以避免再次开启TCP连接的时候收到上一次TCP连接存在网络中的数据包，显然这样的数据包不是属于本次连接的，是无效的数据包。

以上就是TCP连接释放的4次握手，也可以叫做四次挥手。

好了，今天我们就聊到这里，大家下期见。