前言
该部分博主在做量产项目时候，分析doip协议的时候,总结的tcp/ip 说明
当然，这东西记不住…容易忘记…
总览
https://www.golinuxcloud.com/tcp-sequence-acknowledgement-numbers/
15 -»»» CANOE -»»» Client 64 -»»»>IFC -»»»» Serve
逐包分析
总体流程透视
第一帧数据
说明
这是从客户端到服务器的第一个数据包 (也称为 SYN 数据包)，源端口和目标端口分别为 46961、13400 TCP 连接中的所有数据都从随机选择的 SN (初始序列号)开始编号。尽管第一个数据包(SYN) 不包含任何数据，但它使用一个序列号，因此实际数据从ISN+1 开始。为了便于理解，Wireshark 从IS 开始，称为“相对序列号”，而在上面的屏幕截图中，我们可以清楚地看到客户端已将其实际序列号设置为631238114。相对序列号只是为了便于分析。由于这是流中的第一个数据包，因此确认号设置为零。通过这些设置，客户端会通知服务器它将使用某些选项，并要求服务器在下一个数据包 (SYN/ACK) 中发送其选项。
第二帧数据
说明
从服务器到客户端的第二个数据包(也称为 SYN/ACK 数据包)与第一个数据包非常相似，只是这次 ACK 标志设置为 1。尽管此数居包不携带任何数据，而是传输连接设置，但确认号会增加 1，这告诉客户端在将其序列号设置为零时已收到 SYN 数据包。
第三帧数据
说明
这是用于 TCP 3 向握手的最后一个数据包(也称为 ACK 数据包)。客户端将其序列和确认编号增加 1，让服务器知道它已收到其SYN/ACK 数据包。从这一点开始，只有在一端发送或接收到一些数据后，序列和确认号才会增加。
第四帧数据
说明
这这是第一个包含一些实际数据(doip 的路由请求)的数据包，也称为 TCP 有效负载。序列号在会话期间累积。换句话说，客户端让服务器知道它按序列号总共发送了多少数据。它还通过确认号指定从服务器接收的数据总量。由于它之前没有发送或接收过任何数据，因此序列和确认编号仍为 1。
第五帧数据
说明
此数包不携带任何数据，如您从 len: 0 中看到的那样。一旦服务收到 15 字节的数据，它需要让客户端知道它已经收到了设置了ACK 标志的数据。由于客户端之前没有发送过任何数据，因此它将其序列号设置为 1，而确认号增加 1 到 16。简而言之，服务器告诉客户端它获得了 15 字节的数据，并且它期望从 16 字节开始的新数据。
第六帧数据
说明
该数据包为doip 路由激活的响应，由服务端发出，数据长度为17。由于server 以前没有发过数据，所有序列号依旧是1，确认号为16。
第七帧数据
说明
该数据为客户端的tcp 响应。序列号为16，确认号为18。
第八帧数据
说明
该数据tcp 发送的did 数据请求，序列号为16，确认号为18。
第九帧数据
说明
该数据为服务端发送的tcp ack响应，序列号为18，确认号为31。
第十帧数据
说明
该数据为服务端发送的uds 22 服务响应，序列号为18，确认号为31
