【认识TCP 序列和确认编号】

如果你正在阅读这篇文章，很可能你已经熟悉了TCP臭名昭著的"三向握手"或"SYN，SYN / ACK，ACK"。不幸的是，对于许多网络工作者来说，这就是TCP教育结束的地方。尽管TCP已经很老了，但它是一个相对复杂的协议，非常值得深入了解。本文旨在帮助您更自如地在 Wireshark 数据包分析器中检查 TCP 序列和确认编号。

在开始之前，请务必在Wireshark中打开示例捕获并继续进行。

示例捕获包含对 Web 服务器的单个 HTTP 请求，其中客户端 Web 浏览器请求单个图像文件，服务器返回 HTTP/1.1 200 （OK） 响应，其中包括请求的文件。您可以右键单击此捕获中的任何 TCP 数据包，然后选择"跟踪 TCP 流"以在单独的窗口中打开 TCP 流的原始内容以进行检查。来自客户端的流量显示为红色，来自服务器的流量显示为蓝色。

三方握手
TCP 在其标头中利用许多标志或 1 位布尔字段来控制连接的状态。我们在这里最感兴趣的三个是：

SYN - （同步）启动连接
FIN - （最终） 干净地终止连接
ACK - 确认收到的数据
正如我们将看到的，一个数据包可以设置多个标志。
在 Wireshark 中选择数据包 #1，然后在中间窗格中展开 TCP 层分析，然后进一步展开 TCP 标头中的"标志"字段。在这里，我们可以看到所有TCP标志的细分。请注意，SYN 标志处于打开状态（设置为 1）。

现在对数据包 #2 执行相同的操作。请注意，它设置了两个标志：ACK 用于确认接收客户端的 SYN 数据包，以及 SYN 以指示服务器也希望建立 TCP 连接。

来自客户端的数据包 #3 仅设置了 ACK 标志。这三个数据包完成初始 TCP 三向握手。

序列和确认编号
TCP 会话两端的客户端都维护一个 32 位序列号，该序列号用于跟踪已发送的数据量。此序列号包含在每个传输的数据包上，并由另一个主机确认为确认号，以通知发送主机已成功接收传输的数据。

当主机启动TCP会话时，其初始序列号实际上是随机的;它可以是介于 0 和 4294967295 之间的任何值（包括 0 和 4294967295）。但是，像Wireshark这样的协议分析器通常会显示相对序列和确认数字来代替实际值。这些数字是相对于该流的初始序列号而言的。这很方便，因为跟踪相对较小的可预测数字比跟踪网络上发送的实际数字要容易得多。

例如，数据包 #1 中显示的初始相对序列号是 0（自然），而第三个窗格中的 ASCII 解码显示实际序列号0xf61c6cbe，或者4129057982十进制。

可以通过导航到"编辑">首选项"来禁用相对序列号的显示。并取消选中 TCP 协议首选项下的相对序列号和窗口缩放。但是，请注意，本文的其余部分将仅引用相对序列和确认数。 

为了更好地了解在TCP会话期间如何使用序列和确认编号，我们可以利用Wireshark内置的流图功能。导航到"统计信息>流图..."，选择"TCP 流"，然后单击"确定"。Wireshark 会自动生成 TCP 流的图形摘要。

 

每行表示一个 TCP 数据包。左列指示数据包的方向、TCP 端口、段长度和设置的标志。右列以十进制形式列出相对序列和确认数字。选择此列中的行还会在主窗口中突出显示相应的数据包。

我们可以使用此流图来更好地了解序列和确认数的工作原理。

数据包 #1
TCP 会话的每一端都以零的（相对）序列号开始。同样，确认数也为零，因为对话中还没有一个互补的方面需要确认。
（注意：用于此演示的Wireshark版本1.2.7将确认编号显示为明显随机数。这被认为是一个软件错误;

会话的初始确认编号应始终为零，正如您从检查数据包的十六进制转储中看到的那样。

数据包 #2
服务器使用序列号为零响应客户端，因为这是其在此 TCP 会话中的第一个数据包，相对确认编号为 1。确认编号设置为 1，以指示在数据包 #1 中收到客户端的 SYN 标志。

请注意，尽管客户端尚未发送任何有效负载数据，但确认数已增加 1。这是因为接收的数据包中存在 SYN 或 FIN 标志会触发序列中 1 的增加。（这不会干扰有效负载数据的记帐，因为设置了 SYN 或 FIN 标志的数据包不携带有效负载。

数据包 #3

与数据包 #2 一样，客户端以确认编号 1 响应服务器的序列号 0。客户端包含自己的序列号 1（由于 SYN 而从零递增）。

此时，两个主机的序列号均为 1。在两个主机的序列号上，此初始增量为 1，发生在建立所有 TCP 会话期间。

数据包 #4

这是流中携带实际有效负载（特别是客户端的 HTTP 请求）的第一个数据包。序列号保留为 1，因为自此流中的最后一个数据包以来未传输任何数据。确认编号也保留为 1，因为也没有从服务器接收到任何数据。

请注意，此数据包的有效负载长度为 725 字节。

数据包 #5
此数据包由服务器发送，仅用于确认客户端在数据包 #4 中发送的数据，而上层处理 HTTP 请求。请注意，确认数已增加 725（数据包 #4 中有效负载的长度）增加到 726;例如，"到目前为止，我已收到 726 个字节。服务器的序列号仍为 1。

数据包 #6
此数据包标志着服务器的 HTTP 响应的开始。它的序列号仍然是1，因为在此之前它的数据包都没有携带有效载荷。此数据包携带 1448 字节的有效负载。

数据包 #7
客户端的序列号已增加到 726，因为它发送了最后一个数据包。从服务器接收到 1448 字节的数据后，客户端将其确认编号从 1 增加到 1449。

对于大多数捕获，我们将看到这个循环重复。客户端的序列号将稳定在 726，因为它没有数据可以传输超过初始 725 字节请求。相比之下，服务器的序列号会随着它发送更多 HTTP 响应段而继续增长。

拆解
数据包 #38

在确认来自服务器的最后一段数据后，客户端将处理整个HTTP响应，并决定不需要进一步的通信。数据包 #38 由设置了 FIN 标志的客户端发送。其确认编号与上一个数据包 （#37） 中的确认编号相同。

数据包 #39

服务器通过增加确认编号 1（类似于数据包 #2 中为确认 SYN 标志所做的操作）并设置 FIN 标志来确认客户端终止连接的愿望。

数据包 #40

客户端发送其最终序列号 727，并通过将确认编号递增 1 到 22952 来确认服务器的 FIN 数据包。

此时，两台主机都已终止会话，并且可以释放专用于其维护的软件资源。