TCP字节流、序号与累计确认

形式陈述

TCP在IP数据报之上提供面向连接、双向、按序的字节流。每个方向独立编号；一端的发送序号不与反方向的数据共享计数器。应用连续写入的字节可以被分成不同TCP段，也可以合并；接收调用返回多少字节不必与发送调用或网络段的边界一致。

每个数据字节占一个序号。段首SEQ标出首字节的位置，累计ACK= $a$ 表示接收TCP已收到该方向从当前连接起点到 $a$ 之前的连续序号，下一期待位置为 $a$ 。SYN与FIN各占一个序号，纯ACK不占；这不是“ACK等于已收到的包数”。收到后面的数据仍不能越过前面的缺口交给按序读取者。

发送者维护SND.UNA（最早未确认序号）和SND.NXT（下一新发送序号）。新的有效累计确认须落在 $\mathrm{SND.UNA}<a\le\mathrm{SND.NXT}$ 的序号区间内；旧确认不让UNA倒退，超出已发范围的确认不能释放尚未发出的字节。接收者维护RCV.NXT，并依据窗口决定可接受范围；已交付的重复字节不能再次进入应用字节流。

实际序号按模 $2^{32}$ 运算。为解释局部比较，在候选距离严格小于 $2^{31}$ 的共同序号窗口内，可定义 $a$ 在 $b$ 之前，当且仅当 $0<(b-a)\bmod2^{32}<2^{31}$ 。相隔半圈没有这种无歧义顺序，不能把该式当整个模空间上的全序；完整TCP还用接收窗口、连接实例与旧段寿命规则排除歧义。RFC7323窗口缩放最多左移14位，实际最大通告窗口为 $65535\times2^{14}<2^{30}$ ；不能把半空间比较条件替代这个协议窗口上限。本文小算例先用不绕回的展开序号，再单独检查绕回。

直觉

序号给字节安排座位，ACK报告“前面的座位已经连续坐满到哪里”。第六至第八字节先到，并不能把缺失的第三至第五字节猜出来。后段可以暂存，前缀仍需等待或重传修补。

TCP确认的是对端TCP的接收状态。字节可能还在内核缓冲里，应用尚未读取，更不用说业务提交。发送调用返回也通常只说明本地接受了相应前缀，离远端业务结果更远一层。

例子与边界

握手后首数据序号为101。发送ABC占[101,104)，DEF占[104,107)，GH占[107,109)。若到达顺序为GH、ABC、DEF、重复DEF，且接收者保留乱序数据，累计ACK依次为101、104、109、109；可交付字节前缀依次为空、ABC、ABCDEFGH、ABCDEFGH。ACK从104跳到109是补洞后的连续推进。

同一串ABCDEFGH可由应用分成两次写入ABC、DEFGH，接收方却分三次得到A、BCDE、FGH。TCP仍正确。若协议要求先处理一条“ABC消息”，应用必须使用分帧规则，不能把第一次read当第一条消息。

绕回例中，首序号为 $2^{32}-2$ ，四个字节的序号依次是4294967294、4294967295、0、1，全部收到后的ACK为2。普通整数判断“2小于4294967294，所以是旧ACK”会错；模差为4，符合本例的局部前进区间。

校验和并不构成密码认证。本文不分析恶意注入、序号猜测及中间盒修改；其防御不能仅用“有32位序号”概括。连接失败前可能已经交付任意合法前缀，TCP不提供回滚此前字节的能力，也不承诺在永久断网时完成整条流。

推论与应用

受限可靠流状态机可逐步展示补洞和重传为何保持同一前缀；它删去了真实TCP的握手、模序号、拥塞及许多恢复细节，因此不能替代规范实现。连接生命周期再说明SYN、FIN如何进入这套编号。

读写循环要按实际返回字节数推进缓冲位置；出现错误时，已被对端执行的请求不能从TCP错误码反推。RPC结果判定需要应用响应和业务合同，既不是数ACK，也不是查看本地write是否全长。

同一连接若承载多个独立排序的流，需另外区分包身份与每流内容偏移；多流重组以abcd和XY展示另一条流为何能先交付，并用真实HTTP/2 DATA帧对照单TCP缺口。它不改变本页一个方向只有一条字节序列的合同。

参考资料

RFC 9293，2022，§2.2、§3.4、§§3.8–3.9：TCP服务、模序号、累计ACK及用户接口；该文为本页基本TCP规范版本。
RFC 7323，2014，§2.3：窗口缩放移位及最大窗口范围。
Peterson、Davie，Computer Networks: A Systems Approach，在线6.2-dev版，§§5.2.2、5.2.4：字节流、缓冲与滑动窗口；2026-10-08实读。

形式陈述 ​

反向链接

形式陈述