摘要

  • 1994 年 11 月的实验性 RFC 1693讨论部分顺序、部分可靠性的传输服务。文中四条记录的虚构查询，视排序条件分别允许 1、2、4 或 4! = 24 种排列。
  • IESG 在文首说明：不建议实施所提 TCP 修改，同时认为关于乱序和缺失数据的分析在 TCP 之外也有价值。研究问题与实施决定同时留在档案里。

柜台手里有货，却要等前一张号

可靠、有序的字节流是 TCP 的基本承诺。RFC 793给应用一个连续的序列：前面的字节还没到，后面的字节即使已抵达接收端，也得先等等。传文件时，这通常很合适。可如果上层拿的是几条彼此独立的查询结果，等候就有些滑稽：柜台明明握着第二张单据，却以第一张尚未到场为由拒绝递出。

T. Connolly、P. Amer 和 P. Conrad 没有只抱怨队伍太长。他们在 RFC 1693 里摆出四条数据库记录，逐次改变排序条件。按四个各不相同的销售员姓名排序，结果只有一种合法次序；按地点排，其中两条同城，可以有两种；按两两相同的描述排，有四种；去掉 ORDER BY，四条记录有 4!，即 24 种排列。这是例题的组合数，并非线路测速。变化来自查询的真实约束，而非数据包突然学会了魔术。

作者把中间地带叫作“部分顺序”。某些记录必须在另一些记录之前交付；无依赖的记录可以互换。两端需要把这些约束传达或商定，接收端则在每条记录到来时，检查它所依赖的前项是否已经到齐。这样安排仍有秩序，只是不会把四条记录强行绑成一根绳。

另一个可调旋钮是可靠性。数据库可能允许顺序灵活，却要求每条结果最终都到齐；多媒体则可能在一个频道内部讲顺序，同时容忍过时画面的丢失。RFC 1693 举到视频、两个音频频道、文字、手语画面，还讨论窗口重绘。画面是否仍有用，哪一条结果必须先出场，这些都是应用层知道的事。

作者研究了在修改过的 TCP 中提供部分顺序连接，也考虑建立连接时如何识别普通对端。他们分析了少等一条无关记录可能带来的收益。四条记录的排列数不能拿来报“提速 24 倍”，文中也没有给出一个能推广到整个互联网的实测收益。提案是实验性研究，不能写成后来 TCP 已经照办。

更值得看的，是文章还没开始论证，IESG 的意见就先印在前面：运输领域负责人及其团队不建议实施所述 TCP 修改，但认可分析乱序、缺失数据的工作在 TCP 以外有用。这不是历史倒霉地错过了一个功能的戏码；它是一次把需求拆得很细、又把实施边界写得很明白的讨论。第二条结果还在柜台上。它最有力的问题是：究竟谁规定它非等第一条不可？