Summary

  • 10 月 27 日版个人 QUIC 草案新增用例：客户端保存服务器发来的历史网络统计，并在后续连接中交回。
  • 用例要求按发送方的认证身份和端点关联记录；既有隐私条文建议用户清除 Cookie 时删除这些统计，删除动作必须能抵达传输层缓存。

点了“清除 Cookie”，还有多少记忆藏在别处？新版 QUIC 拥塞数据草案把这个产品问题摆到了传输协议面前。它让客户端保存服务器发来的网络观测记录，下次连接时再送回。服务器因此可以取回自己的历史信息，而不必为每个客户端留存完整的测量历史。

新附录 B 把这只抽屉的归属写得更清楚。恢复用例要求客户端将缓存记录与发出它的服务器认证身份、以及当次连接的服务器端点关联。另一台服务器即使声明愿意接收历史统计，也不能收走前一台的记录。用例举出的范围可以是 HTTPS 来源加上 IP 地址和端口；单凭 IP 地址，确认不了服务器身份。无法建立所需关联，就不发送回忆帧。

这一步发生在客户端交出记录之前。设备访问许多服务，地址说明数据包去哪里，却不能独自说明缓存里的东西属于谁。把两者混在一起，省下的是身份判断，丢掉的则是记录的交付边界。

草案还提供三个开关。CONSUME 表示希望在当前连接使用统计，例如帮助视频应用选择码率；CACHE 表示愿意接收并可能在以后交回；CONSIDER 表示愿意接收自己从前提供的数据。默认值为零。这些是端点之间的能力与意愿信号，用户的存储和隐私设置还需要由产品接上去。

安全章节承认，回传统计可能成为追踪机制，并将这种能力与 QUIC 已有的地址验证令牌作比较。统计本身对客户端可读，客户端可以检查内容，也可以拒绝交回无法理解的值。该章节还建议，在用户清除 Cookie 等其他追踪机制时，删除保存的网络统计。上一版已经有这项删除建议；本次新增的用例，让客户端如何保管和交回记录变得更具体。

问题于是落到软件分工。人认识的按钮在浏览器设置里，数据可能放在传输组件的缓存里。建议变成实际删除，需要一条贯通两端的调用路径。产品也可以只取当前好处：新附录的流媒体用例采用 CONSUME 使用当次统计，无须同时承诺保存并在未来回传。

Datatracker 将文档列为个人 Internet-Draft，10 月 27 日公告确认新版发布，尚无 IETF 背书。资料没有给出任何浏览器版本的缓存删除测试结果；具体版本上的结果，才能回答那个熟悉的按钮是否管得住这只新抽屉。