摘要

  • RFC 794 设想终端服务进程在已有连接工作时仍保留一个 TCP LISTEN，让更高优先级的请求先进入，再由该进程决定是否中断较低优先级的连接。
  • Cerf 的 FTP 例子把责任摆在两端：接收主机的服务程序处理被抢占的任务，发起主机若自身资源耗尽，则要由本地系统先腾出启动请求的空间。

一份普通文件正在从主机 X 传向 Y。主机 Z 此时想向 X 发起一个「闪电越级」的 FTP 连接。SYN 到了门口，谁该下线？如果把答案写成“优先级高者先行”，被中断的文件传输就像被从故事里抹掉了。Vint Cerf 的 RFC 794 在 1981 年追问的，恰恰是这笔账由谁结。

他先把通信系统的几种拥堵摆在一张桌上。电话电路一旦分给用户，即使沉默也占着带宽；满员时，高优先级电话可以挤掉已有通话。存储转发的报文系统先把消息放进磁盘、磁鼓或磁带，再按优先级处理，紧急消息甚至可以打断较低优先级消息的打印。分组网络没有同样多的传输存储空间，饱和时重点变成给待进入系统的流量排序。三种系统，都在分配稀缺资源；稀缺的东西却各不相同。

回到 AUTODIN II 的终端，Cerf 把决定交给终端主机进程 THP。终端已经连着一人，THP 仍可在该端口挂着一个 LISTEN。新连接进来，进程看它的优先级，再比较手头已有的连接。如果必须腾位，就关闭或中止最低优先级的一条，把用户切到新连接，然后继续挂出一个 LISTEN 等候下一次请求。有客人可以敲门，不等于客厅里能无限加椅子。

这个办法要求 TCP 把进入请求的优先级交给使用 TCP 的进程。Cerf 没有让 TCP 本身担任裁员经理：TCP 通常面对的是进程，也不会仅凭一个新请求替终端凭空造出服务进程。终端若已经关机，造进程毫无意义。谁正在使用终端、哪些会话能同时存在、终止一条连接后怎么收尾，都是靠近用户的程序更清楚。多连接的设想还得服从安全要求。优先级是消息，处置权有具体位置。

FTP 场景让这种分工摸得着。X 的 FTP 服务即使忙着给 Y 传文件，也可以留一个额外的 LISTEN 接住 Z 的高优先级请求。如果再服务一人就无法继续留门，FTP 可让低优先级用户让位，并亲自处理原任务的收尾。反过来，一个服务进程在忙碌时连 LISTEN 都不留，在这套方案里就无法被抢占。写着「急件」的信封，遇上锁门的办公室也只能等。

门的另一侧还有一层意外。Z 若已经耗尽本机 FTP 或 TCP 资源，那位高优先级用户连请求都发不出来。Cerf 说，本地操作系统可能要替他抢占资源，极端例子是让低优先级用户退出登录。优先级可归于用户，也可归于终端；本地决策可以在 TCP 实现或操作系统。这些不是网络线上一个标志位替所有机器做出的统一选择。

这篇两页的短文真正锋利之处，是承认「插队」需要有人处理被挤出去的人。接收端的服务知道如何终止任务，发起端的系统知道怎样给新任务腾空间。TCP 负责把敲门声传到门口；门开不开、谁收拾桌面，得由屋里的人决定。