关于传输层TCP协议的三次握手
前言：记录关于传输层TCP协议的三次握手
TCP的简单了解
TCP(Transmission Control Protocol 传输控制协议)是一种面向连接(连接导向)的、可靠的、 基于IP的传输层协议。
TCP工作在网络OSI的七层模型中的第四层，对应的也就是传输层
数据从应用层发下来，会在每一层都会加上头部信息，进行 封装，然后再发送到数据接收端。
在数据传输之前，所有基于TCP协议进行通信都需要通过三次握手来建立可靠的连接。
TCP的三次握手
TCP的三次握手的流程如下图所示
有关TCP标志位Flags
SYN标志：建立连接的请求标志位
ACK标志：针对请求确认的应答标志位
PSH(push传送)
FIN标志：请求断开连接的标志位
RST(reset重置)
URG(urgent紧急)
Sequence number序列号：发送的这个包中第一个字节（如果有payload的话）的序号
Acknowledge number确认号：已成功接受Sequence number序列号到Acknowledge number-1的数据，期望接收的下一个字节的序号为Acknowledge number
TCP三次握手抓包分析
红框所圈处：TCP进行三次握手的数据包
第一次握手
主机A向主机B发送一个带有标志位为SYN的数据包，主机A会进去到会进入SYN-SENT状态，即代表主机A向主机B发起建立连接的请求，其中可以看到seq的序列号为0（这个是相对的序列号，实际情况中不是为0）
可以看到对应的SYN标志位为1，其他的标志位都为0，ACK为0的原因是当前这个SYN请求包没有得到响应
同样的Sequence number也是为0，原因是这是主机A和主机B之间通信的第一个数据包，所以Sequence number编号为0
这里我们还可以继续观察相关的Acknowledge number确认号，可以看到同样是0，因为主机A根本没有接收到带有数据的数据包，所以Acknowledge number确认号当前期望的数据包自然为0
第二次握手
主机B收到主机A的请求后，会进入SYN-RECEIVE状态，此时主机B会给主机A回复一个带有确认应答(ACK=1)和请求同步序列号(SYN=1)标志位的数据段响应主机A，也告诉主机A如下两件事
- 主机B发送的数据包中的标志位SYN=1，告诉主机A，我和你建立请求连接
- 主机B发送的数据包中的标志位ACK=1，告诉主机A，我接收到你的消息了
然后这里还需要观察下Acknowledge number确认号和Sequence number序列号
Sequence number序列号为0，因为这是第一个握手包中发送的数据还是为0
Acknowledge number确认号为1，代表已成功编号为0的数据，期望接收的下一个字节的序号为1，所以这里就说明了下一次主机A发送的时候，其Sequence number序列号将为1
但是这里其实有一个问题，就是明明第一个数据包中没有数据，但是为什么第二个数据包中Acknowledge number确认号会加1？该笔记后面我有说明
第三次握手
主机A收到主机B发送的这个数据包后，再发送一个确认应答(ACK=1)，表示确认已收到主机B的数据包:"我已收到回复，我现在要开始传输实际数据了，这样3次握手就完成了，接下来的话就开始主机A和主机B就可以传输数据了
此时的数据包为ACK标志为1
Sequence number序列号为1，因为第二个握手包中的Acknowledge number确认号已经为1，所以这次发送的肯定是要从1开始
Acknowledge number确认号还是为1，因为其中并没有相关的数据发送
该报文发送完毕后，客户端和服务器端都进入ESTABLISHED状态，完成TCP三次握手。
问题1：为什么握手的第一次数据为0，但是握手的第二个包的ack number还会+1？
参考文章：https://blog.csdn.net/anlian523/article/details/119704954
这个是TCP的规则，简而言之，接收方反馈的ACK之所以加1，是因为发送方包含了SYN标志位或FIN标志位。
也就是说，只要发送方包含了 SYN标志位或FIN标志位，即使没有包含数据，接收方也得认为 发送方消耗掉了一个序号。
另外，带有 SYN标志位或FIN标志位的报文段（在三次握手和四次挥手中），也是不允许携带数据的。
