开发者实测邮件、WhatsApp与fmsg数据传输量

我对 email、WhatsApp 和 fmsg 在发送相同消息时的数据收发量做了实证测试。我的初衷自然是想拿出可信的图表，证明 fmsg（我开发了一段时间的协议）既有 IM 应用的效率，又能像 email 一样自托管，也就是两全其美。不过心里始终有个念头：不实测就不知道真相，而实测之后往往会发现一些意想不到的事情。果然如此，我确实发现了一些东西， namely：WhatsApp 对图片做了相当激进的压缩，email 的中继转发比我意识到的更值得担忧，而 fmsg 真正省下的流量来自有状态性——而非单条消息的大小——尽管我一直专注于用紧凑的二进制编码来最小化消息体积。

完整的测试套件、结果和源码都在 https://github.com/markmnl/fmsg-bench。Email 和 fmsg 都按域名托管，我各选了三个主机。Email 选了一个我可进行测量、自托管的 mailcow（使用 Postfix），以及另外两个最流行的提供商：Gmail 和 Outlook。fmsg 我则在多个大洲跑了三个主机——我自托管的裸金属服务器、一台 GCP 虚拟机和一台 Digital Ocean 虚拟机，全部使用基于 fmsgd 的开源栈：https://github.com/markmnl/fmsgd。WhatsApp 则有些不同，无法控制主机（一切都发往 Meta 的服务器），所以我用了 whatsapp-web.js 配合关联账号——这充其量只能算勉强可信。

先看基础情况，典型消息往来中线路上的字节数是什么样子。Email 的字节数会增长，因为测试模拟了所有 email 客户端的典型行为——在每封邮件中包含之前的内容——公平地说，SMTP 并没有这样的要求。但 email 是无状态的，所以在不知道收件人是否仍保留先前邮件的情况下，它们每次都会把这些历史记录加上去。

以上是同一段对话的情况，详情见链接的 GitHub 仓库，其中也详细说明了方法，即用 tcpdump 抓包写入 .pcap 文件。

有趣的是，我一直觉得 WhatsApp 发图片比 Messenger 好，因为图片看起来明显更清晰，而我注意到 Messenger 里图片会有可见的画质下降。我一直以为那大概是因为 Messenger 会调整尺寸并使用更多有损压缩。好吧，WhatsApp 对图片确实做了些处理（所以要称赞他们，因为我肉眼根本没注意到）：

如你所见，.png 和 .jpg 被 WhatsApp 大幅缩减了！？我仍不清楚具体怎么做到的——这一定是某种专有处理，之后又被还原，因为正常图片从另一端出来还是正常的。

在早前一轮测试中，我意识到自己还配置着一个 email 中继，那是我为自托管 email 设置的。之所以需要中继，是因为作为住宅用户，我的 ISP 不允许我为公网 IP 配置反向 DNS（PTR）记录——email 反垃圾控制会用到——所以必须用 email 中继来保证可靠投递。这段经历让我深刻意识到：中继会终止你的连接，如果你依赖 TLS，那 TLS 就到此为止了！你把极大的信任交给了中继，它可能悄悄窃听所有经过的邮件。fmsg 要求主机之间直接连接，这防止了中继，并且不依赖我控制之外的东西，比如反向 DNS 记录，使得自托管 fmsg 对我来说比 email 更可行、更安全。中继会掩盖线路上的总字节数，因为无论收件人数量多少，一切先发往中继再分发出去。所以我不得不关掉中继，信任收件人一侧的邮件服务器，然后重新测量。

在 fmsg 中，主机必须持有被回复的父消息（通过哈希链接构建起有向无环图），否则消息会被拒绝。这有助于证明先前参与过某个线程并防止垃圾邮件。这也意味着，向主机已持有的消息添加额外收件人只需要头部——因为消息不可变且主机已持有它，例如，如果把 @bob@example.com 添加到从 @alice@acme.com 发给 @carol@example.com 的消息中，传输过程中 example.com 检测到它已有这条消息，只需记录 @bob 是额外收件人即可。这在 fmsg 规范中有完整描述。这一点凸显了下面测试可视化的意义：

总体来说，我对 fmsg 的表现很满意，感觉在优化消息交换方面已达到实际极限。另外，fmsg 现已在 IANA 正式注册于 TCP 4930：https://www.iana.org/assignments/service-names-port-numbers?search=4930，我们还有了一个 fmsg MVP 托管服务商 fmsg.ai——今天就认领你的 fmsg 地址吧！或者自托管——完整的后端开源栈可在以下地址获取：https://github.com/markmnl/fmsg-docker