序号和确认号

原文：http://packetlife.net/blog/2010/jun/7/understanding-tcp-sequence-acknowledgment-numbers/

翻译：https://blog.csdn.net/a19881029/article/details/38091243

一点总结

SYN - 创建一个连接

FIN -  终结一个连接

ACK - 确认接收到的数据

TCP会话的每一端都包含一个32位（bit）的序列号，该序列号被用来跟踪该端发送的数据量。每一个包中都包含序列号，在接收端则通过确认号用来通知发送端数据成功接收

当某个主机开启一个TCP会话时，他的初始序列号是随机的，可能是0和4,294,967,295之间的任意值，而不是都从0开始，这样主要是出于网络安全的因素着想。 如果不是随机产生初始序列号，黑客将会以很容易的方式获取到你与其他主机之间通信的初始化序列号，并且伪造序列号进行攻击，这已经成为一种很常见的网络攻击手段。同时可以避免不必要的冲突。初始序列号随机生成，一般是基于时间，利用散列函数（这个函数一定时间也会轮换）计算而成的，目的是防止被猜测序列号从而被伪造攻击。同时因为是基于时间的，所以几乎不会与最近断开的或正在等待中的序列号相同

接收端接受到发送端的报文号回送的序列号是在接受端的初始序列号开始累加（第一次传送有效数据的序列号为初始序列号，后续序列号(比如第一次发送端传送数据序列号为1，发送数据725byte，则下一次发送端的序列号为726))

确认号取决于发送过来数据的大小 比如初始发送了42byte，此时回送的ACK为43（表示<43的数据已全部确认(累积确认)期望收到序号为43的包)

如果客户端没有再向服务端发送数据，客户端序列号保持不变，服务端的序列号，由于服务端不断地发送HTTP响应，故其序列号一直在增长

序列号为当前端成功发送的数据字节数，确认号为当前端成功接收的数据位数，SYN标志位和FIN标志位也要占1位

TCP是以流水线发出的，比如发送端顺序的发出 Seq=1、Seq=2、Seq=3。

那么如果ACK确认的序号和收到的包的序号一致的话，那么需要发回 ACK=1、ACK=2、ACK=3 共三个包。

但是TCP协议对此进行了优化，即累积确认只需要发送一个ACK包就能代表说自己已经收到了前面三个包，

那就是发送ACK=4 （期望收到Seq为4的包）。这样节省了ACK确认的数量 

另外TCP是的序号是根据数据流编码的， 假设最开始Seq=0 Len=3， 那么 ACK=4的时候：

第一个意思是想表明期待收到下一个Seq为4的包。

第二个意思实际上是说，想收到的包开始的那个比特位于数据流中的第四个比特。

--部分总结摘自评论/原文