在客户端和服务器都将各自的序列号设置为0的情况下，我发现以下情况成立：
C-->S: SYN=1, SEQ=0 (No data bytes)
C<--S: SYN=1, SEQ=0, ACK=1 (No data bytes)
C-->S: SEQ=1, ACK=1 (Data bytes optional)
在第三部分中，我理解服务器期望下一个序列号是1，但序列号不是应该设置为initial_seq_num + sent_data_bytes_num吗？既然握手的第一部分没有发送数据字节，那么seq#不应该是0吗？
这只是握手过程中的一个例外吗？还是发送到的没有数据字节的段如果可以发送，则应该将序列号增加1？
(也有类似的问答，但答案没有解释这是握手阶段的异常，还是TCP连接建立后发生的异常。我甚至不确定是否可以发送没有数据字节的段。我假设你不能)
添加TCP保活数据包似乎也没有有效负载。RFC 1122说，在这些数据包中，SEG.SEQ = SND.NXT-1，因为这个序列号将是一个已经确认的号码，并且将发送一个重复的ACK，以便保持服务器的序列号相同。
否则，当序列号正确但没有有效载荷时，我找不到任何需要做什么的指示。我可能错了，因为我只是简单地扫描了文档，但除了示例之外，握手期间也没有关于序列编号规则的说明。
在RFC 1122中，它说
不幸的是，一些行为不端的TCP实现无法响应SEG.SEQ=SND.NXT-1的段，除非该段包含数据。
所以我假设它取决于每个实现，但如果有任何关于a)握手期间的序列编号的声明，以及b)当序列号正确但没有有效负载时如何表现的声明，如果有人能给我指一下这一部分，我将不胜感激。
谢谢！
第一个ACK(作为握手的一部分出现)确认从另一端接收到SYN。SYN段不携带任何数据。但是，为了允许对SYN的接收进行确认，尽管不存在有效载荷，但是第一ACK被递增。