12次往返压到3次，XMPP用了7年

不到7年前，我写过一篇《慢数据》。那篇里聊的是XMPP在极慢链路上曾经怎样、以及在哪些情况下还能被优化。这篇是后续——隔了7年才动笔，我觉得挺应景。 先说基线。标准XMPP建立连接大约需要 12次往返 ，而如今几乎没人在用这套基线流程了。社区做了大量工作，设计出了把往返压到3次的方案，但至少是在重连场景下——而且只有设计，没有实现。 要实现它，需要很多人为两个关键扩展写代码： SASL2 （规范见XEP-0388）和 ISR （规范见XEP-0397）。结果是一个被采纳了，另一个没有。 社区接过了SASL2——按上一篇的说法，这应该让我们落到5次往返——但没有采纳任何1-RTT认证机制，而是更愿意用SCRAM更好的安全性，其中包含通道绑定（Channel Binding）。 通道绑定是一种确保SASL认证的两端与TLS会话的两端相互匹配的技术。考虑到CA偶尔会被攻破，也出现过国家级别攻击者针对特定XMPP服务器的情况，社区更愿意依赖这类机制，这完全可以理解。 于是我们走到了这一步： 6次往返 。不算差，但社区没有停在这里。 先是发明了“Bind2”（XEP-0386），把最后那部分资源绑定折叠进SASL2，弄乱了我的配色方案，但省下了末尾的一次往返。 接着是FAST（XEP-0484）。FAST是一套签发短期令牌的系统，令牌可以安全地用于单次往返的认证机制。它在建立阶段不增加往返，但把重新认证压缩到 一次往返 。 最后是IAP（XEP-0509），它让我们能够完全安全地跳过第一次往返。 现在就是 3次往返 ，和当年ISR达到的水平一样好——但它更通用，因为ISR依赖会话恢复，而FAST只是令牌的使用。 再往下就没法只靠一次应用层往返来改进了：这一步不仅要让客户端向服务器完成认证，也要让服务器向客户端完成认证，所以在它完成之前，我们不能开始发送消息。 零RTT 不过，我们可以看看前面那些往返。TLSv1.3有一个巧妙但复杂的功能叫“早期数据”（Early Data），通常称为0RTT，原则上它能让我们把剩下的那一次应用层往返塞进TLS交换里，再省一次往返。 这很复杂，而且对认证安全有连带影响，所以仍处在“研究”阶段。 慢，但是QUIC 社区目前有两个不同的实验在进行，都是关于在QUIC上跑XMPP。就会话建立而言，两者是一样的。QUIC把连接建立和TLSv1.3握手合并在一起，意味着这里也能省下一次往返。 这同样可以和早期数据结合——也就是说，我们能让一个会话在仅仅一次往返后就准备好使用——当然，前提是能安全地跑通。我本想画张图，但说实话，到这一步只剩一堆重叠箭头，纯属噪音。 还是慢 会话建立当然只是全貌的一部分。上一篇结尾我提到，一张250k的JPEG不管你怎么努力，它还是250k的JPEG。 而且即便会话建立完成，XMPP还得处理丢包和乱序，这两样在高延迟下都格外难受。但一旦建立起来，XMPP对高延迟的容忍度相当高，带宽占用也很小。丢包和乱序的问题，可以靠多流QUIC大幅缓解。 明年，XMPP就25岁了，仍被多个开源项目和公司广泛实现，尤其在“把消息送达”至关重要的时候被大量使用。感兴趣的话，XSF那边的讨论依然很热闹。 特别