TCP协议

TCP（传输控制协议）是互联网中的核心协议之一，它提供了面向连接、可靠的数据传输服务。在TCP中，建立一个连接需要通过“三次握手”过程，而终止一个连接则需要通过“四次挥手”过程。下面我将详细解释这两个过程。

想要了解TCP的三次握手与四次挥手，首先得了解一下TCP的报文格式，因为这两个过程需要依赖TCP报文中的一些字段。下面我们通过一幅图来讲解TCP的报文格式：

三次握手：
CLOSED：不在连接状态。（客户端原本所处的状态）
LISTEN：等待从任何远端TCP 和端口的连接请求。（服务器原本所处的状态）
 SYN_SENT：发送完一个连接请求后等待一个匹配的连接请求。（客户端在第一次握手后所处的状态）
 SYN_RECEIVED：发送连接请求并且接收到匹配的连接请求以后等待连接请求确认。（服务器在第二次握手后所处的状态）
 ESTABLISHED：表示一个打开的连接，接收到的数据可以被投递给用户。连接的数据传输阶段的正常状态。（客户端和服务器在第三次握手成功后所处的状态）
四次挥手：
FIN_WAIT_1：等待远端TCP 的连接终止请求，或者等待之前发送的连接终止请求的确认。（客户端在第一次挥手后所处的状态）
 CLOSE_WAIT：等待本地用户的连接终止请求。（服务器在第二次挥手后所处的状态）
 FIN_WAIT_2：等待远端TCP 的连接终止请求。（客户端在第二次挥后前所处的状态）
 LAST_ACK：等待先前发送给远端TCP 的连接终止请求的确认，包括它字节的连接终止请求的确认。（服务器在第三次挥手后所处的状态）
TIME_WAIT：等待足够的时间过去以确保远端TCP 接收到它的连接终止请求的确认。（客户端在第四次挥后前所处的状态）
 CLOSING：等待远端TCP 的连接终止请求确认。
三次握手：
        三次握手（Three-way Handshake）其实就是指建立一个TCP连接时，需要客户端和服务器总共发送3个包。

三次握手的主要作用：
        就是为了确认双方的接收能力和发送能力是否正常、指定自己的初始化序列号为后面的可靠性传送做准备。

三次握手的过程：
第一次握手：

客户端发送网络包，服务端收到了。
客户端的发送能力、服务端的接收能力是正常的。
客户端给服务端发一个 SYN 报文，并指明客户端的初始化序列号 ISN。
此时客户端处于 SYN_SENT 状态。
首部的同步位SYN=1，初始序号seq=x，SYN=1的报文段不能携带数据，但要消耗掉一个序号。
第二次握手：

服务端发包，客户端收到了。
服务端的接收、发送能力，客户端的接收、发送能力是正常的。
但此时服务器并不能完全确认客户端的接收能力是否正常。
服务器收到客户端的 SYN 报文之后，会以自己的 SYN 报文作为应答，并且也是指定了自己的初始化序列号 ISN。同时会把客户端的 ISN + 1 作为ACK 的值，表示自己已经收到了客户端的 SYN，
此时服务器处于 SYN_RCVD 的状态。
在确认报文段中SYN=1，ACK=1，确认号ack=x+1，初始序号seq=y。
第三次握手：

客户端发包，服务端收到了。
客户端的接收、发送能力正常，服务器的发送、接收能力也正常。
只有当客户端接受了服务器发送的包，并成功发送给服务器，才能确认客服端的接受能力是正常的。
客户端收到 SYNACK 报文之后，会发送一个 ACK 报文，当然，也是一样把服务器的 ISN + 1 作为 ACK 的值，表示已经收到了服务端的 SYN 报文，
此时客户端处于 ESTABLISHED 状态。服务器收到 ACK 报文之后，也处于 ESTABLISHED 状态，此时，双方已建立起了连接。
确认报文段ACK=1，确认号ack=y+1，序号seq=x+1（初始为seq=x，第二个报文段所以要+1），ACK报文段可以携带数据，不携带数据则不消耗序号。
第三次握手的作用：
        前两次握手只能确认服务器和客户端的发送和接收能力正常，但服务器并不知道客户端是否成功接收到了自己发送的消息。通过第三次握手，客户端返回确认消息给服务器，服务器才能确认自己的发送和客户端的接收都正常。

第三次握手的主要目的是为了确认客户端的接收能力正常。

三次握手的图文表示：

为什么是三次握手而不是两次：
  首先我们要明确，两次握手是必要的。第一次握手，客户端将SYN报文发送到服务器，服务器接收到报文后，即可确认客户端到服务器是可达的；而服务器向客户端发送响应的SYNACK报文，客户端接收到后，即可确认服务器到客户端也是可达的。至此，连接已经算是建立，那为什么还要有第三次握手呢？

  客户端和服务器的握手过程，不仅仅是确认互相可达的过程，更重要的是一个同步的过程，SYN就是同步（Synchronize）的缩写。对于TCP报文段来说，序号是一个至关重要的部分，它保证了TCP传输数据的完整性。而我们上面也说过，TCP报文的初始序号不是从0开始的，而是一个随机的序号，而所谓的同步，就是TCP客户端和服务器互相同步初始序号的过程。第一次握手，客户端发送SYN报文，将自己的初始序号发送到了服务器，服务器接收到后，向客户端发送SYNACK报文段，告诉客户端已经收到了它的初始序号，同时在这个报文段中带上了自己的初始序号。这个时候，第三次握手的作用就出来了：第三次握手实际上就是客户端在告诉服务器，自己已经收到了它的初始序号，完成了同步，可以开始相互传输数据了。若没有第三次握手，服务器将无法保证客户端接收到了自己的SYNACK报文段，若此时SYNACK报文段丢失，客户端不知道服务器的初始序号，将无法处理之后到达客户端的数据。

二次握手会的情况：
        所有如果只有两次握手，那么客户端和服务器之间的连接可能无法正常建立。具体来说的话，可能会出现以下情况：

已失效的连接请求报文段可能会突然传送到服务器，导致服务器错误地认为客户端已经建立了连接，从而发送数据给客户端。但是，由于客户端并没有发送第三次握手，所以客户端无法接收到这些数据，从而导致数据丢失或连接中断。
客户端和服务器之间的网络可能会存在延迟或丢包等问题，导致第二次握手无法到达客户端或服务器。如果只有两次握手，那么客户端和服务器都无法确定对方是否成功接收到了自己的消息，从而导致连接无法正常建立。
        为了避免这些问题，TCP 引入了第三次握手，以确保客户端和服务器之间的连接能够正常建立，并且防止已失效的连接请求报文段突然传送到服务器产生错误。

四次挥手的过程：

TCP四次挥手的过程：
  TCP在断开连接时，客户端与服务器之间要交换四次报文，所以，TCP的断开连接也叫四次挥手。

第一步：客户端进程发出断开连接指令，这将导致客户端的TCP程序创建一个特殊的TCP报文段，发送到服务器。这个报文段的FIN字段被置为1，表示这是一条断开连接的报文；
第二步：服务器接收到客户端发来的断开连接报文，向客户端回送这个报文的确认报文（ACK字段为1），告诉服务器已经接收到FIN报文，并允许断开连接；
第三步：服务器发送完确认报文后，服务器的TCP程序创建一条自己的断开连接报文，此报文的FIN字段被置为1，然后发往客户端；
第四步：客户端接收到服务器发来的FIN报文段，则产生一条确认报文（ACK为1），发送给服务器，告知服务器已经接收到了它的断开报文。服务器接收到这条ACK报文段后，释放TCP连接相关的资源（缓存和变量），而客户端等待一段时间后（半分钟、一分钟或两分钟），也释放处于客户端的缓存和变量；

其中：

第一次挥手：

客户端发送一个 FIN 报文，报文中会指定一个序列号。

即发出连接释放报文段（FIN=1，序号seq=u），并停止再发送数据，主动关闭TCP连接。
进入FIN_WAIT1（终止等待1）状态，等待服务端的确认。
第二次挥手：

服务端收到 FIN 之后，会发送 ACK 报文，且把客户端的序列号值 +1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了

即服务端收到连接释放报文段后即发出确认报文段（ACK=1，确认号ack=u+1，序号seq=v）。
服务端进入CLOSE_WAIT（关闭等待）状态。
此时的TCP处于半关闭状态，客户端到服务端的连接释放。客户端收到服务端的确认后，进入FIN_WAIT2（终止等待2）状态，等待服务端发出的连接释放报文段。
第三次挥手:

如果服务端也想断开连接了，和客户端的第一次挥手一样，发给 FIN 报文，且指定一个序列号。

即服务端没有要向客户端发出的数据，服务端发出连接释放报文段（FIN=1，ACK=1，序号seq=w，确认号ack=u+1）
服务端进入LAST_ACK（最后确认）状态，等待客户端的确认。
第四次挥手：

客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答，且把服务端的序列号值 +1 作为自己 ACK 报文的序列号值，需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态，服务端收到 ACK 报文之后，就处于关闭连接了，处于 CLOSED 状态。

即客户端收到服务端的连接释放报文段后，对此发出确认报文段（ACK=1，seq=u+1，ack=w+1）
客户端进入TIME_WAIT（时间等待）状态。
此时TCP未释放掉，需要经过时间等待计时器设置的时间2MSL后，客户端才进入CLOSED状态。
四次挥手的图文表示：

四次挥手释放连接时，等待2MSL的意义：
        为了保证客户端发送的最后一个ACK报文段能够到达服务器。因为这个ACK有可能丢失，从而导致处在LAST-ACK状态的服务器收不到对FIN-ACK的确认报文。服务器会超时重传这个FIN-ACK，接着客户端再重传一次确认，重新启动时间等待计时器。最后客户端和服务器都能正常的关闭。假设客户端不等待2MSL，而是在发送完ACK之后直接释放关闭，一但这个ACK丢失的话，服务器就无法正常的进入关闭连接状态。