MCCP

MCCP 用 zlib 压缩服务器到客户端的数据流。版本 1 是 telnet 选项 85，实际上只剩历史意义； 版本 2 是选项 86，也是现代服务器会协商的那一个。服务器发出 IAC SB MCCP2 IAC SE 之后， 随后的每一个字节都属于同一条连续的 zlib 流。

在一个文本协议上，这是实打实的节省——MUD 的输出压缩率极高——而且它在 Diku 和 LP 家族里很常见： 我们调查过的代码库中，大约三分之一会协商它。

它的故障模式，以及这在本站为什么要紧

一个协商了 MCCP2 却不去解压数据流的客户端，会从压缩标记开始收到一片二进制乱码。不是报错，也不是断线： 连接画面变成一整墙替换字符，而在它之后的一切——WHO 的回复、后面的任何 MSSP、整场会话——统统丢失。

这不是假想。我们自己的 telnet 库干的就是这件事。它协商了这个选项，触发了自己的“压缩已启用”回调， 却一个字节都没解压过。那份载荷用一个现成的 zlib 调用就干干净净地解开了，正是这一点让事情毫无疑义： 对的是服务器，错的是我们。我们调查的三十八个代码库里有十三个受到影响， 而在这段时间内，我们无法观测这些服务器在压缩开始之后协商了什么—— 所以我们对它们能力的记录是偏低的。

这个问题已在上游修复。还有一个后续缺陷——解压器是每次读取都重建，而不是随连接一直保留， 于是在一张很大的连接画面读到一半时失败——已经提交且仍未关闭，它影响的是最大那些画面的尾部。

读者应该从这里带走两件事。本页上的协议数字，既是对这个圈子的实测，同样也是对我们爬虫的实测， 凡是我们知道它错过的地方，我们都会说出来。另外，如果你在写客户端：协商 MCCP 很容易， 而正确地解压才是工作量真正所在的地方。