MCCP  [协议]
流压缩。开销小、部署广，也是本项目历史上最有教益的那个 bug 的来源。
https://www.mudhalla.net/tintin/protocols/mccp/

实测采用情况
  在887个已列出的游戏中，有 217 个被观测到提供了它（24.5%）
  /zh-Hans/games?protocol=MCCP

  未算进这里的游戏，并不是没有这个协议的游戏。一个游戏被算进这里，条件是我们观测到它的服务器在一次握手中提供了这个选项；其余的既包括没有向我们提供它的服务器，也包括我们还没有读到过握手的服务器，而我们说不出是哪一种。

  按代码库，在我们已识别的游戏中
    CoffeeMUD            32 个中有 31 个提供了它
    FluffOS              29 个中有 25 个提供了它
    ROM                  55 个中有 13 个提供了它
    Evennia              11 个中有 11 个提供了它
    DikuMUD              35 个中有 8 个提供了它
    CircleMUD            47 个中有 4 个提供了它
    MUCK                 24 个中有 3 个提供了它
    SMAUG                20 个中有 2 个提供了它
    AresMUSH             18 个中有 0 个提供了它
    CobraMUSH            2 个中有 0 个提供了它
    PennMUSH             34 个中有 0 个提供了它
    RhostMUSH            40 个中有 0 个提供了它
    tbaMUD               5 个中有 0 个提供了它
    TinyMUSH             9 个中有 0 个提供了它

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

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

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

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

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

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

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

另见
  ROM — /zh-Hans/reference/codebases/rom
  DikuMUD — /zh-Hans/reference/codebases/dikumud
  GMCP — /zh-Hans/reference/protocols/gmcp