QUIC已为各流维护独立滑动窗口，为何数据包仍需序列号？

你觉得包级序列号冗余，核心是把流级数据偏移和**连接级包序列号（Packet Number, 简称PN）**的职责搞混了——两者作用层级、解决的问题完全不重叠，根本不存在谁替代谁的关系，设计包级序列号的核心原因可以归为四点：

• 加密与安全机制对包级序号有强依赖
  QUIC 所有报文的解密逻辑从根上就绑定包级序列号：每个报文的加密nonce是直接用PN计算生成的，连接的密钥更新、0-RTT/1-RTT密钥切换的判定边界也是按PN单调递增的顺序划分的。如果没有独立的包级序号，你收到UDP报文后连用来解密的nonce、对应密钥版本都确定不了——毕竟一个包里可能塞了属于多个不同流的帧，总不能随便挑某一个流的偏移量来算解密参数吧？
  除此之外，包级序号是QUIC防重放攻击的核心基础：单调递增的PN可以直接让接收方丢弃乱序幅度超过窗口的历史重放包，这个校验在报文解密前就能做，不需要等解析到内层的流帧，效率和安全性都高得多。
• 连接级传输逻辑需要统一的序号标识
  拥塞控制、丢包检测、RTT采样这些逻辑是作用在整条传输路径上的，不是针对单个流生效的：
  你如果只靠每个流自己的滑动窗口做确认，首先会遇到「一个UDP包携带多个流帧」的确认问题——总不能为这一个包里带的3个流、2个控制帧分别发5次确认吧？用包级序号的话，一个ACK帧就能一次性确认整包的所有内容，传输开销低很多。
  其次你没法准确做丢包判断和RTT采样：如果重传的流数据复用原有的流偏移，你根本分不清收到的ACK是对应第一次发包还是重传的包，会直接导致RTT采样不准、拥塞控制判断失准，这也是TCP当年被诟病很久的重传歧义问题。QUIC给每个新发出的包（哪怕内容是重传的流数据）分配全新的、单调递增的PN，从设计上就规避了这个问题——而流级偏移是和应用层交付的字节位置绑定的，重传时绝对不能改，根本承担不了这个职责。
• 非流类型的控制帧没有对应的流级序号
  QUIC的帧类型不只有流数据帧：连接级流控更新帧、路径探测帧、密钥更新帧、连接关闭帧、流重置帧这些都是连接全局生效的，不属于任何一个应用流，根本没有对应的流级偏移可以用来标识顺序、做可靠传输确认。比如你发了一个通知对方扩大连接接收窗口的MAX_DATA帧，必须靠包级序号来追踪它有没有被对方收到、要不要重传，靠流级序号完全覆盖不到这部分逻辑。
• 接收方的包处理效率需要包级序号做前置校验
  接收方收到UDP报文后，可以先基于PN快速判断这个包是不是已经接收过的重复包、是不是超出乱序接收窗口的无效包，不用花成本去解密、解析内层的多个流帧再逐流判断重复，能大幅降低大流量传输时的CPU开销。

你提到的「各流自己排序就不需要包排序、可以逐流做ACK」的假设，理论上不是完全不能跑，但会带来极高的传输开销、解决不了加密/控制帧的传输问题、还会继承TCP的重传歧义缺陷，完全得不偿失，所以QUIC才会在流级的偏移量之外，单独设计了连接维度的包序列号机制。

内容的提问来源于stack exchange，提问作者EL_9