我的疑惑大概在于

TCP里正常情况, 没有丢数据的时候
一个包(n号)的Ack值等于上一个包(n-1号)的Seq + Len, 大概是说已经收到的数据量(字节)
而n号包的Seq值等于上一个包的Ack, 就是这次要从Seq字节继续传

而且这个确认(Ack)包可以延迟确认, 就说明这个Ack值前面的包都收到了

表示出来大概是

Seq=X Ack=Z Len=L1
------------------------>

Seq=Z Ack=X+L1 Len=L2
<------------------------

Seq=X+L1 Ack=Z+L2 Len=L3
------------------------>
...

而在TCP建立连接时三次握手的时候, 为什么是

[SYN] Seq=0, Len=0
-------------------------------->

[SYN, ACK] Seq=0, ACK=1, Len=0
<--------------------------------

[ACK] Seq=1, Ack=1, Len=0
-------------------------------->

观察这些包的Len=0, 那为什么Ack会变成上个包的Seq+1, 而不是Seq呢

断开连接时的四次握手也是类似

[FIN, ACK] Seq=X, Ack=Y, Len=0
-------------------------------->

[ACK] Seq=Y, ACK=X+1, Len=0
<--------------------------------

[FIN, ACK] Seq=Y, Ack=X+1, Len=0
<--------------------------------

[ACK] Seq=Y+1, ACK=X+1, Len=0
-------------------------------->

这是…为什么呢QAQ
书里还提到…这里可以延迟确认, 省去第二个包…其实看起来好像第二个包没起到什么作用
像下图一样

[FIN, ACK] Seq=X, Ack=Y, Len=0
-------------------------------->

[FIN, ACK] Seq=Y, Ack=X+1, Len=0
<--------------------------------

[ACK] Seq=Y+1, ACK=X+1, Len=0
-------------------------------->

关于网络…其实好多东西…怎么说
就像NAT里好多东西, 在不同RFC里定义都不一样了
可能有一些东西就互相矛盾了
当然还是我菜…

后来

学长给了资料, 我还是太菜了
http://packetlife.net/blog/2010/jun/7/understanding-tcp-sequence-acknowledgment-numbers/

博主的这段

The server responds to the client with a sequence number of zero, as this is its first packet in this TCP session, and a relative acknowledgement number of 1. The acknowledgement number is set to 1 to indicate the receipt of the client's SYN flag in packet #1.

Notice that the acknowledgement number has been increased by 1 although no payload data has yet been sent by the client. This is because the presence of the SYN or FIN flag in a received packet triggers an increase of 1 in the sequence. (This does not interfere with the accounting of payload data, because packets with the SYN or FIN flag set do not carry a payload.)

就是说因为SYN和FIN标志位的存在, 使得序列号加了1…
不用担心会对带payload的包的情况产生影响, 因为置位SYN和FIN的包是不会带数据的…

emmmm, 我也可以认为这算是一种特殊情况吧