没有设置 ACK 标志的确认号有什么用？

这在RFC 793, 传输控制协议中有解释原因的概述，但如果您阅读并理解 RFC，则可以进一步了解详细信息：

2.6. 可靠的通讯

在 TCP 连接上发送的数据流在目的地按顺序可靠地传送。

通过使用序列号和确认使传输变得可靠。从概念上讲，数据的每个八位字节都分配有一个序列号。段中数据的第一个八位字节的序列号与该段一起传输，称为段序列号。段还携带一个确认号，它是反向传输的下一个预期数据八位字节的序列号。当 TCP 传输一个包含数据的段时，它会在重传队列中放置一个副本并启动一个计时器；当收到对该数据的确认时，该段将从队列中删除。如果在定时器用完之前没有收到确认，则重新传输该段。

TCP 的确认并不能保证数据已交付给最终用户，而只能保证接收方 TCP 已对此负责。

为了管理 TCP 之间的数据流，采用了流控制机制。接收 TCP 向发送 TCP 报告一个“窗口”。此窗口指定接收 TCP 当前准备接收的八位字节数，从确认号开始。

这解释了确认号的原因，但实际操作在 RFC 中有详细解释。

您是否曾将确认与普通消息混合使用 - 在同一 TCP 段中发送数据和确认消息？

是的，这是完全正常的。例如，响应请求而发送的数据可以包含请求的响应和确认。

我觉得一个是多余的 - ACK 标志，或确认号（当 ack 标志关闭时）

不，你应该真正阅读并理解 RFC，它是 TCP 的定义。

查看RFC 793 3.1 标头格式

确认编号：32 位

如果设置了 ACK 控制位，则该字段包含该段的发送方期望接收的下一个序列号的值。一旦建立了连接，这总是被发送。

反过来说：当 ACK 位未设置时，该字段将被忽略。

如果您仍然感兴趣，那是我的意见:)

我认为 ACK 位不仅用于指示 ACK 序列是相关的，而且在连接打开和关闭中用作告诉我们下一步要做什么的逻辑位。他们不会在 RFC 中直接写这个。

例如假设两个站 A 和 B 之间的标准 3 次握手：

1. A 向 B 发送 SYN (CLOSED -> SYN SENT)
2. B 接收到 SYN 并发送 SYN|ACK (LISTEN -> SYN RCVD)
3. A 收到 SYN|ACK 并发送 ACK（SYN SENT -> ESTABLISHED）
4. B 收到 ACK (SYN RCVD -> ESTABLISHED)

现在想象一下 ACK 位并不重要。看第 2 步。这会搞乱 RFC 中描述的建立连接的整个过程。步骤 3 中的站 A 会收到 SYN 并认为它是同时打开的，接下来……？