为什么三次握手的时候ack=seq+1

估计很多人都知道三次握手和四次挥手的过程，但这其中有一个问题困扰了我一会（其实是TM很久）

按照定义，seq是要发送的第一个字节的序号，ack等于他收到的seq序列号加上字节流数据的长度，他代表期望收到的下一个字节的序号，同时他也代表这个序号前的字节我都已经收到了。

那么为什么三次握手过程中，比如第一次握手，A向B发了seq=x，B给A回的ack是=x+1呢？如果有数据的话，那理应等于x+LEN，

如果没有数据，那就应该保持不动就等于x才对。

答案是在三次握手过程中：

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.)

服务器端回复的这个+1，是代表他收到了SYN标示。

也就是说由于SYN或者FIN的存在，即使没有数据传输，但服务器端仍然需要通过+1来回应一句“我收到了”。因此握手过程中seq=x的话，ack = x+1。其他几次握手挥手也是同样道理。

P.S：SYN和FIN这种标示只占1bit

附上参考的文章，感谢～

https://aryb1n.github.io/2018/05/03/%E7%BD%91%E7%BB%9C-%E5%AF%B9ACK%E4%B8%80%E7%82%B9%E7%96%91%E6%83%91/

https://zhuanlan.zhihu.com/p/53374516