TCP的三次握手与四次挥手

下图是TCP报文格式

序列号seq(sequence )：

占4个字节，用来标记数据段的顺序，TCP把连接中发送的所有数据字节都编上一个序号，第一个字节的编号由本地随机产生；给字节编上序号后，就给每一个报文段指派一个序号；序列号seq就是这个报文段中的第一个字节的数据编号。

确认号ack：

占4个字节，期待收到对方下一个报文段的第一个数据字节的序号；序列号表示报文段携带数据的第一个字节的编号；而确认号指的是期望接收到下一个字节的编号；因此当前报文段最后一个字节的编号+1即为确认号。

确认ACK(ACKnowledge Character，确认字符)：

占1位，仅当ACK=1时，确认号字段才有效。ACK=0时，确认号无效。

同步SYN（Synchronize sequence numbers，同步序列编号）：

连接建立时用于同步序号。SYN是一个标志位，虽然它的全称是Synchronize sequence numbers（同步序列编号），但是作为SYN，它只是一个标志。当SYN=1，ACK=0时表示：这是一个连接请求报文段。若同意连接，则在响应报文段中使得SYN=1，ACK=1。因此，SYN=1表示这是一个连接请求，或连接接受报文。SYN这个标志位只有在TCP建产连接时才会被置1，握手完成后SYN标志位被置0。

终止FIN(finsh,结束)：

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

PS：

ACK、SYN和FIN这些大写的单词表示标志位，其值要么是1，要么是0；ack、seq小写的单词表示序号。

三次握手过程理解

三次握手是指建立TCP连接协议时，需要在客户端和服务器之间发送三个包，握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。

TCP可靠传输的精髓

TCP连接的一方A，由操作系统动态随机选取一个32位长的序列号（Initial Sequence Number）,假设A的初始序列号为1000，以该序列号为原点，对自己将要发送的每个字节数据进行编号，1001,1002,1003，…，并把自己的初始序列号ISN告诉B，让B有个思想准备什么样编号的数据是合法的，什么编号是非法的，比如编号900就是非法的，同时B还可以对A每一个编号的字节数据进行确认。如果A收到B确认编号为2001，则意味着字节编号为1001-2000，共1000个字节已经安全到达。
同理B也是类似操作，假设B的初始序列号ISN为2000，以该序列号为原点，对自己将要发送的每个字节的数据进行编号，2001,2002,2003，…，并把自己的初始序列号ISN告诉A，以便A可以确认B发送的每一个字节。如果B收到A确认编号为4001，则意味着2001-4000，共2000个字节已经安全到达。

第一次握手：

建立连接时，客户端发送一个包（SYN=1，seq=x，x是随机int）到服务器，并进入SYN_SENT状态，等待服务器确认。

第二次握手：

服务器收到客户端传来的包后，结束LISTEN阶段。并返回一个包，其中：
标志位为SYN=1和ACK=1，表示“确认客户端的报文seq序号有效，服务器能正常接收客户端发送的数据，并同意创建新连接”（即告诉客户端，服务器收到了你的数据）；
序号为seq=y；
确认号为ack=x+1（并不是真的加1，而是加一个数字，这里以1 为例），表示收到客户端的序号seq并将其值加1作为自己确认号ack的值；随后服务器端进入SYN-RCVD阶段。

第三次握手：

客户端接收到来自服务器端的确认收到数据的TCP报文之后，明确了从客户端到服务器的数据传输是正常的，结束SYN-SENT阶段。并返回最后一段TCP报文。其中：
标志位为ACK=1，表示“确认收到服务器端同意连接的信号”（即告诉服务器，我知道你收到我发的数据了）；
序号为seq=x+1，表示收到服务器端的确认号ack，并将其值作为自己的序号值；
确认号为ack=y+1，表示收到服务器端序号seq，并将其值加1作为自己的确认号ack的值；
随后客户端进入ESTABLISHED阶段建立成功状态。
到此，三次握手完成。

为什么要进行第三次握手？（为什么不是两次握手、四次握手？）

以A<------------------>B之间传输为例
四次握手过程：

• A发送同步信息SYN+A’s Initial sequence number
• B 确认收到A的同步信号，并记录 A’s ISN 到本地，命名 B’s ACK sequence number
• B发送同步信号SYN + B’s Initial sequence number
• A确认收到B的同步信号，并记录 B’s ISN 到本地，命名 A’s ACK sequence number
  很显然1.2和1.3 这两个步骤可以合并，只需要三次握手，可以提高连接的速度与效率。

二次握手过程：

• A 发送同步信号SYN + A’s Initial sequence number
• B发送同步信号SYN + B’s Initial sequence number+ B’s ACK sequence number
  这里有个问题，A与B就A的初始序列号达成了一致，假设这里是1000.但是B无法知道A是否已经收到自己的同步信息，如果这个同步信息丢失了，A和B就B的初始序列号将无法方达成一致。

三次握手各自出现问题，会发生什么结果？

第一次握手出现问题：第一个包，即A发给B的SYN 中途被丢，没有到达B
答：A会周期性超时重传，直到收到B的确认

第二次握手出现问题：第二个包，即B发给A的SYN +ACK 中途被丢，没有到达A
答：B会周期性超时重传，直到收到A的确认

第三次握手出现问题：第三个包，即A发给B的ACK 中途被丢，没有到达B
答：A发完ACK，单方面认为TCP为 Established状态，而B显然认为TCP为Active状态：

a.假定双方此时都没有数据发送，B会周期性超时重传，直到收到A的确认，，收到之后B的TCP 连接也为 Established状态，双向可以发包。
b.假定此时A有数据发送,B收到A的 Data + ACK，自然会切换为established 状态，并接受A的 Data。
c.假定B有数据发送，数据发送不了，会一直周期性超时重传SYN + ACK，直到收到A的确认才可以发送数据。

四次挥手过程理解

1）客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
2）服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
3）客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
4）服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
5）客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
6）服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。

引用文章：
https://blog.csdn.net/qq_38950316/article/details/81087809
https://blog.csdn.net/sinat_41144773/article/details/88314735
https://baijiahao.baidu.com/s?id=1654225744653405133&wfr=spider&for=pc
https://www.zhihu.com/question/24853633