我们要离开 Cloudflare – 这就是原因 – Pale Moon

尽管 CloudFlare（本文其余部分简称为 CF）在提供 CDN 功能和普遍有利的 Web 属性缓存方面为我们提供了很好的服务，但我们将在未来几周内逐步停止使用它们。其原因将在此处详细概述。一点历史 我们一直（非常）早期采用 CF，实际上通过积极的帖子、博客条目等帮助他们成长并为人所知。我们几乎从一开始就和他们在一起，并见证/帮助他们成长为最大的 CDN 之一和他们今天的互联网流量庞然大物。除了一些问题，主要是处理他们的“防火墙”和他们必须达到的必要平衡，以提供广告保护，同时不减少代理网站的功能，合作一直是有利的。不幸的是，在过去的几年里，他们开始更多地关注主要由市场上最大的参与者推动的“时尚”技术（如 DoH 和其他高度集中的技术），而他们似乎忽略了成千上万的小客户他们拥有和需要什么，无论他们过去是否对他们的成长有帮助。我们之前已经碰过几次头（例如关于山茶花密码），但这里的这个话题是压垮骆驼的最后一根稻草。什么是 Brotli，为什么它很重要？ Brotli 是一种由 Google 设计的压缩方法（类似于 zip）。对于基于文本和较小的数据，它可以轻松提供比 zip 高 20% 的数据压缩，但对于某些类型的其他本身尚未压缩的数据也有显着改进，而解压缩速度会很高并且通常很轻-资源权重。很大一部分网络流量是文本（html、CSS 和 JavaScript 都是基于文本的格式）。现在，Web 上的压缩并不是什么新鲜事，多年来一直是内容交付的重要组成部分。压缩是在每个请求的基础上进行的，因此每个从服务器传输到浏览器的文件都可以被压缩或解压缩，这取决于这样做是否经济（稍后会详细介绍）。使用的方法多年来一直是旧的 compress（过时）、deflate 和 gzip。 Brotli 与 gzip 极其相似，但由于所谓的“上下文建模”，它提供了显着更密集的压缩（我将在此处为您提供技术细节，请随意查找！）。它是作为 woff2 字体格式的可下载字体的最佳压缩而引入的。之后在 2015 年被许多浏览器（包括我们）采用来压缩网页内容。您可以看到为什么 Web 具有更好的压缩并且几乎没有缺点很重要，我希望，以及为什么 Brotli 在这种情况下很重要（显着）节省用于下载 Web 内容的带宽。为什么只支持https？当 Brotli 首次被引入时，它与一些（很少使用，主要由谷歌使用）中间件盒冲突，这些中间件盒试图使用一种称为 SDCH（“三明治”）的方法在提供内容的服务器之外执行数据的透明压缩。不幸的是，中间件不够聪明，无法识别新的压缩方法，并且会通过“双重压缩”已经经过 Brotli 压缩的数据而导致损坏。当然，谷歌想要防止他们自己的网站遭到破坏，就不得不处理这个问题。因此，它仅限于那些无论如何都无法被这些中间件盒子压缩的数据，即在 https 上（https 的端到端加密将防止这些盒子接触数据）。当然，作为临时措施，这一切都是有道理的，并且这个原因已被用作（但作为最终原因！）作为为什么 Brotli-over-http 不可用的原因。所以是的，不是修复中间件以识别 Brotli，而是压缩仅限于 https。值得注意的是，SDCH（也需要浏览器的支持）已被弃用并同时从所有 Web 客户端中删除，因此这些框实际上是 RIP。现在，您可能会问，为什么没有将 Brotli 开放给 http？提示“加密网络”的推动。在 Brotli 被引入的时候，也有人认真地尝试让 https 无处不在。当然，如果 https 本身具有更好的压缩，它看起来非常适合推广诸如 http/2 和其他正在开发的“独家 https 俱乐部”功能。我很确定，与 http 相比，许多显示“更快的 https”的比较研究不会考虑在 https 上禁用 Brotli 以进行苹果对苹果的比较。在我最近与 Mozilla 的接触中，我清楚地知道“推进 [the] 加密网络”是目前无法在 Firefox for http 中启用 Brotli 的唯一原因。我很确定谷歌对 Chrome 有相同的方法，如果不仅仅是因为他们往往永远不会回到既定的实现来改变它们。值得注意的是：“市场领先”的浏览器明确没有表明他们通过 HTTP 支持 Brotli，因此如果它是由服务器启用的，那么它们就没有区别，因为服务器必须从浏览器表明它支持的压缩方法中进行选择，这将排除 Brotli。现在，我不想讨论 http 与 https，因为这完全不是重点，并且已经在其他地方多次讨论过了。关键是在这个实现中，http 与 https 相比在带宽的有效使用方面处于不必要的劣势。当我发现在我们的实现中也存在这种不必要的分裂（当我们分叉 UXP 时从 Mozilla 继承）时，我在这里做了我的研究，这导致我们当前的浏览器版本在服务器支持时通过 http 启用 Brotli（这很容易设置）起来，实际上）。 CF 如何处理 Brotli？根据 HTTP 规范，内容压缩是在逐个请求的基础上处理的。对于每个请求，浏览器会指示它支持该请求的压缩方案，并且服务器会根据所提供的选项确定使用哪些选项来传送内容。如果不匹配，内容将不压缩发送。这允许服务器非常有效地选择对每个请求的文件使用什么压缩（如果有的话），并且浏览器所要做的就是指出它支持服务器“选择”什么。 CF 已开始在其云边缘提供 Brotli 作为压缩方法。他们提供它的方式是他们从源服务器请求数据，然后在他们的边缘服务器上（重新）压缩它以将 brotli 压缩的 Web 内容提供给 Web 客户端。他们不会从原始服务器请求经 Brotli 压缩的数据（出于未知原因），并且最多只能为此使用 gzip。然而，CF 没有做的是在 http 连接上为客户端提供相同的压缩，这是我向他们询问以启用它的来源，因为这似乎是一个错误。因此，CF 决定为实际用户提供的内容使用哪种压缩。如果连接是 HTTP，他们决定不响应表明他们支持 Brotli 的浏览器，但如果浏览器表明他们支持 HTTPS 时的 Brotli，他们会做出响应。我问的是还要在 http 上启用现有的压缩（已经在使用中！）。这应该像简单地为 http 连接启用现有管道一样简单。甚至可能是单线配置。讨论 最初的讨论只是“它打破了网络，因为中间件盒子”和旧公告的链接 - 忽略了这些陈述来自 2015 年的事实，当时是的，确实，在初始阶段这是一个问题。我让他们考虑到当前的数据，即没有人使用SDCH，并且谈论的盒子早已退役。显然这引起了他们工程团队的注意，因为我得到了更详细的转发回复，其中引用了一些似乎想在那里结束讨论的事情，然后像“安全问题”（最初没有详细说明任何内容，因此不得不询问具体细节） -- 如果通过 http 和 https（例如 BREACH）提供压缩，则引用压缩侧信道攻击。但是我已经在这方面进行了研究（有些了解我的人知道，在考虑功能时，Web 安全性往往是我考虑的首要因素）并且这些类型的攻击（当服务器易受攻击时）无论如何都是有效的其中将使用压缩，包括每个人都支持的 gzip。换句话说，它不是 Brotli 特有的，当我问到 Brotli 以何种方式更容易受到影响时，我被要求提供证据：“你能帮我证明 Brotli over HTTP 不会带来更大的内容解密风险吗？” .众所周知，不可能最终证明某事没有发生。然而，我仍然提供了研究文献（也被要求）清楚地证明了 Brotli 在所有方面对 gzip 采取的非常相似的立场，包括安全性。那时我被引导到“社区”来讨论它。不幸的是，这是大公司在处理他们不想承认错误的“困难问题”时的常见策略（Mozilla 也参与了转发到 Google Groups 的工作，在那里这些主题几乎被发送到失败了） .所以..尽管我有更好的判断（并保持直接票打开）我开始了这个讨论：https://community.cloudflare.com/t/brotli-over-http-not-in-use/286210 请随意去并参与讨论。 CF 表示他们“继续监视 Cloudflare 社区以及更广泛的网络上的讨论”以“优先考虑改进”，因此保持该主题的活跃非常重要（CF 社区讨论将在 2 周无人发帖后关闭。如果你问我，非常小的窗口）。被推掉 在社区讨论达到这一点之后的支持票中，我清楚地提出了为什么应该启用 Brotli 的非常好的和可靠的论点（我在撰写本文时的最后一次回复）我随后基本上被他们以同样的旧论点推掉了开始于：Ella，CloudFlare 写道：我们将此事上报给了我们的工程团队，他们审查了请求 - 感觉这里有一个权衡。带宽效率与中间盒导致请求失败的可能性之间的权衡。由于这些设备不受 HTTP 端点的控制，并且很难在 Internet 规模上进行测量、观察和调试，因此我们缺乏强有力的数据来进行权衡。这些是在优先考虑开发和支持工作时考虑的因素。我回复 Moonchild 写道：我真的很失望（但并不完全惊讶......）你的工程团队一直坚持他们最初的陈述。中间件盒导致问题的风险实际上为零，因为 SDCH 压缩已从 Google Chrome 和其他 Chromium 产品中删除，在版本 59 (2017-06-05) 中。 [1] 因此，如果您的工程团队根据 2015 年的声明进行判断，那么他们将您的结论基于任何 Web 客户端中都不再存在的技术。我们不支持它，Mozilla 不支持，Google 不支持，Apple 不支持。所以权衡是在带宽效率和不存在的用例之间，我根本不会称之为权衡。如果您觉得有必要进行更多研究，请进行研究。 ... [1] “意图卸载：SDCH”。 https://groups.google.com/a/chromium.or ... Ql0ORHy7sw ...我认为这不是一个不合理的要求；这会影响他们所有的客户，所以如果他们觉得在启用它之前需要更多地研究它，那很好。然而，对此的回应基本上是完全拒绝考虑它，不管我的观点是否正确。 Ella, CloudFlare 写道：虽然我们承认您提出了有效的观点，但遗憾的是，我们目前无法承诺在 HTTP 上支持 Brotli：我们必须权衡实施的利弊、破坏风险和潜在好处。目前，我们不会在短期内支持 Brotli，但我们将继续积极关注社区中有关此主题的任何讨论。如果情况发生变化，我们很乐意在未来再次访问。不幸的是，我们无法准确评论哪些情况会让我们重新评估 brotli 对 HTTP 的优先级。那是为什么？为什么推迟这个，基本上告诉我走开？他们甚至不会考虑为支持它的客户启用 Brotli 的真正（未向我透露）原因是什么？请记住，如果浏览器没有表明他们的支持——Chrome 和 Firefox 都没有这样做——那么即使服务器有这种支持，它也不会被使用。我只能得出结论，这里有一些议程我一直被蒙在鼓里，如果他们根本不考虑调查这个问题的话…… 结论：信任问题 这导致了我在这里的最终结论很长的帖子（对不起，如果你觉得它太多了，但我想把所有这些都说出来，我仍然相当简洁。更多细节参见 CF 社区讨论）。 CF 作为受制裁的 MitM“反向代理”，将有权访问流经启用了 CF 的 Palemoon.org 主机（包括 https）的所有流量。 CF 还可以完全控制我们的 DNS 区域，这对于在 Web 上进行访问至关重要，也是许多安全措施（如 CAA、SPF、DKIM 和我们的域电子邮件）的关键基石。值得庆幸的是，我已经足够聪明了，没有将它们用作我的 SSL 证书的注册商或 CA。这是一个需要高度信任 CF 的职位，因为他们所做的一切都是光明正大的。如果他们决定，他们可以有效地完成或破坏项目的位置。这种信任级别要求不保留任何秘密。这需要他们提供很多透明度，而他们显然不愿意再提供任何透明度（CF 过去在其运营中非常透明，但显然情况已不再如此）。结果，我不再相信 CF 可以控制项目的 Web 存在（或我拥有的任何域，就此而言），我们将离开它们。虽然有些人出于各种（社会）政治原因不喜欢 CF，但正如您所看到的，这与我在这里的决定无关。这是一个简单的问题，因为受到不良对待并侵蚀了我的信任，以至于我根本无法证明继续在项目的如此重要和关键位置使用它们是合理的。是的，这可能会导致性能下降（例如，下载新版本更新时）。就这样吧。 TL;DR CF 拒绝考虑我们通过 http 启用 Brotli 的请求，尽管有压倒性（且无可争议）的证据，这样做对整个 Internet 上的每个人来说都是完全安全和有益的。更重要的是，这种处理方式显示出严重缺乏客观洞察力，并且明显偏袒私人议程而不是技术进步。最终的结果是，由于他们提供的服务的性质，需要客户完全信任的公司失去了信任，我们将停止使用它们。 “孩子，在生活中，你打仗不是因为你想赢，你打仗只是因为他们需要打仗。” -- 杂鱼