我想知道是否有任何特殊原因要增加 ACK 序列号而不是确认收到的序列号。为什么 RFC 这样设计？
Actual:
[SYN] SEQ=100
[SYN, ACK] Seq=300 Ack=101
[ACK] Seq=101 Ack=301
Why not:
[SYN] Seq=100
[SYN/ACK] Seq=300 Ack=100
[ACK] Seq=101 Ack=300
自然，确认您刚刚收到的序列号而不是确认您收到的序列号 + 1 是否更有意义？
答案1
在 TCP 中，协议使用序列号来跟踪已发送的内容。实际上，它是已发送内容的计数器 +1。
更多详情https://www.rfc-editor.org/rfc/rfc793#section-3.3
ACK 增加 1，因为数据包携带 SYN，它不为空。SYN 有助于增加 SEG.LEN，如 rfc 中所述：
SEG.LEN = 段中数据占用的八位字节数（包括 SYN 和 FIN）
如果数据包是空的并且没有 SYN/FIN，则计数器就不会增加。
rfc 中也考虑到了这一点，其中规定下一个要发送的序列号必须大于或等于而不是 ACK 中指示的那个：
新的确认（称为“可接受的确认”）是满足以下不等式的确认：
SND.UNA < SEG.ACK =< SND.NXT
其中 SND.UNA 是最早的未确认序列号，SND.NXT 是下一个要发送的序列号。
通过增加序列号，数据包基本上是在询问对方“我希望你现在向我发送第一个字节的数据”
答案2
我的理解是这样的：
这些数字不计算数据包（因为它不是连续的），它们代表 TCP 流中的“位置”：
Seq 表示“我从这个位置发送了数据”
Ack 表示“我已收到此位置的数据”
SYN，FIN的虚拟长度为1。