3. 可靠传输核心概念

车云之间的链路天然不稳定：车辆高速移动导致基站切换、隧道遮挡造成瞬时断链、弱网下丢包与乱序频发。要让 T-Box 上报的遥测、告警、诊断数据以及云端下发的 OTA 指令、控制策略“不丢、不重、不乱”，就必须在应用层或传输层之上建立一套可靠传输机制。这套机制的核心由五个相互咬合的部件构成：确认机制负责“知道对方收到了”，重传策略负责“没收到就再发”，超时控制负责“多久算没收到”，序列号负责“区分每一条消息”，滑动窗口负责“一次能发多少、如何连续发”。

一、确认机制：从“发出去”到“被收到”

发送方把消息发到网络上，只代表消息离开了本机，并不代表对端应用真正处理了它。确认机制（ACK）就是接收方回送的一个“我收到了”的信号。工程上常见的确认粒度有三种：

• 逐条确认：每收到一条消息回一个 ACK。实现简单，但消息量大时 ACK 风暴会显著增加上行开销。
• 累积确认：接收方回送“我已经连续收到序号 N 及之前的全部消息”。一个 ACK 可以覆盖多条消息，效率高，但一旦中间缺一条，后续消息即使到达也无法被确认。
• 选择确认（SACK）：接收方明确告知“我收到了 1、2、4、5，缺 3”。发送方只需重传缺失的那一条，避免整段重发，特别适合车云之间高丢包、大带宽波动的场景。

在车云协议设计中，通常采用“累积确认 + 选择确认”的组合：正常连续到达时用累积 ACK 压缩开销，出现空洞时用 SACK 精确指出缺口。

二、序列号与滑动窗口：让连续发送成为可能

序列号（Sequence Number）是可靠传输的“坐标系”。发送方为每条消息分配一个单调递增的序号，接收方据此判断消息是否重复、是否乱序、是否缺失。没有序列号，接收方无法区分“这条是新消息”还是“上一条的重传”。

如果发送方每发一条都必须停下来等 ACK，吞吐量会被往返时延（RTT）严重限制。滑动窗口（Sliding Window）解决了这个问题：发送方维护一个窗口，窗口内的消息可以连续发出而不必逐条等待确认；当窗口左沿的消息被确认后，窗口向右滑动，腾出新的发送额度。

发送窗口示例（窗口大小 = 4）
序号:      1   2   3   4   5   6   7   8
状态:     [已确认][已发待确认][已发待确认][已发待确认] | 未发送 ...
           ↑窗口左沿                    ↑窗口右沿

收到 ACK=2 后窗口右滑：
序号:      1   2   3   4   5   6   7   8
状态:     [已确认][已确认][已发待确认][已发待确认][已发待确认] | 未发送 ...
                           ↑窗口左沿              ↑窗口右沿

窗口大小决定了“在途未确认消息”的上限。窗口太小，链路利用率低；窗口太大，一旦丢包会带来大量无效重传和内存占用。车云场景中，窗口大小往往需要根据网络质量动态调整。

三、超时控制与重传策略：多久重发、怎么重发

发送方发出消息后启动一个定时器。如果在超时时间内没有收到对应 ACK，就认为消息丢失并触发重传。超时时间（RTO）的设置是可靠传输中最微妙的参数之一：

• RTO 过短：ACK 还在路上就误判为丢包，产生大量不必要的重传，加剧网络拥塞。
• RTO 过长：真正丢包后长时间不重传，端到端时延变大，告警、控制类消息的时效性无法满足。

工程上通常采用自适应 RTO：根据 RTT 的测量值和平滑值动态计算，并设置最小 RTO 与最大重传次数。常见重传策略包括：

四、五个部件的协同关系

这五个概念不是孤立的技术点，而是一条闭环链路：序列号给消息编号，滑动窗口决定一次能发多少，确认机制告诉发送方哪些已到达，超时控制判断何时该怀疑丢失，重传策略决定如何补发。任何一个环节参数失配，都会表现为“消息重复”“消息丢失”“时延抖动”或“带宽浪费”。

五、典型场景与常见误区

以车辆进入隧道为例：T-Box 连续发送 10 条遥测消息，序号 1～10。进入隧道后链路中断，序号 3、4、5 丢失，6～10 到达云端。云端通过序号检测到缺口，回送 SACK 指出“缺 3、4、5”。发送方收到 SACK 后立即选择重传这三条，而不必重发 6～10。若隧道内长时间无信号，重传次数达到上限，T-Box 将消息写入本地持久化队列，待链路恢复后按序号续传——这正是断点续传的基础。

理解确认、重传、超时、序列号与滑动窗口这五个基础概念及其协同关系，是后续设计车云可靠传输协议、实现断点续传与消息去重的前提。它们共同回答了一个核心问题：在不可靠的网络上，如何让收发双方对“哪些消息已经可靠送达”达成一致，并在不一致时自动修复。