Stack Overflow上部署HTTPS：长路尽头（二）

Python部落(python.freelycode.com)组织翻译，禁止转载，欢迎转发。

CDN/proxy：使用Cloudflare和Fastly计算延迟

我在Stack Overflow最为骄傲的事情之一是我们的堆栈的效率。太棒了，对吧？在一个数据中心的小型服务器上运行一个主要网站？不。没那么多。这次不行。虽然对于某些事情来说效率很高，但是在涉及延迟时，突然变成了一个问题。我们从来没有需要大量的服务器。我们从来不需要扩展到多个位置（但是，我们有另一个用于DR）。这一次，这是一个问题。由于光的速度，我们不能（还有）解决延迟的根本问题。我们被告知有人正在做这方面工作，但是还有一个小小的让人落泪的挫折，那就是在推诿中浪费了时间。

当涉及延迟时，我们来看看数字。赤道几乎正好40,000公里（光线往返速度最差）。真空中的光速为299,792,458米/秒。不幸的是，很多人使用这个数字，但大多数纤维并不是在真空中。实际上，大多数光纤比较慢30-31％。所以我们正在研究（40,075,000米）/（299,792,458米/秒* .70）= 0.191秒，最糟糕的情况是往返旅行的191ms，对吗？嗯...不，不是真的。这也是一个最佳途径，但互联网上的两个目的地之间很少是一条直线。有路由器，交换机，缓冲区，处理器队列以及各种其他一些小的延迟。它们加起来就是可测量的延迟。我们还没有谈论火星呢。

那么为什么这对Stack Overflow来说那么重要？这正是云计算发挥作用的领域。使用云提供商的服务器很有可能是本地的。对于我们却不是。通过直接连接，离开我们的纽约或丹佛数据中心（无论哪个活跃）越远，您的体验就越慢。关于HTTPS，在发送任何数据之前，还需要一个额外的往返协商来协商连接。这是在最好的情况下（尽管TLS 1.3和0-RTT有所改善）。而Ilya Grigorik对这点有一个很好的总结。

现在来介绍Cloudflare和Fastly。 HTTPS不是在一个仓库中部署的项目。在您阅读的时候，您会看到其他几个项目在多路复用。针对本地到用户的HTTPS终止端点这种情况（为了最小化往返持续时间），我们正在寻找几个主要标准：

• 本地HTTPS终止

• DDoS保护

• CDN功能

• 性能相当于或超过直接连接我们站点

准备代理：客户端计时

在转移到任何代理之前，测试性能必须到位。 为此，我们设置了一个完整的时间流程，以从浏览器获取性能指标。 多年来，可以通过JavaScript代码window.performance来访问浏览器的性能时间。 继续，打开监视窗口，试试吧！ 我们希望对此非常透明，这就是为什么第1天以后在teststackoverflow.com上提供了详细信息。没有传输敏感数据，只有页面直接加载的资源的URI及其时间。 对于记录的每个页面加载，我们得到如下所示的时间：

目前，我们试图从5％的流量记录性能时间。 这个过程并不复杂，但是所有的部分都必须搭建好：

1. 将时间转换为JSON

2. 上传页面加载完成后的时间

3. 将这些时间转发到我们的后端流量处理服务（它有报告）

4. 将这些时间存储在SQL Server中的集群列存储库中

5. 对Bosun的定时转发（通过BosunReporter.NET）

最终的结果是，我们现在可以很好地实时了解世界各地的实际用户表现，我们可以随时查看，警告并用于评估任何更改。 这是一个来自现场的时间分布视图：

幸运的是，我们有足够的持续流量在这里获得有用的数据。 在这一点上，我们有超过50亿的数据（并且不断增长）的数据来帮助推动决策。 以下是该数据的快速概述：

好的，现在我们有了基准数据。 是时候测试我们的CDN/Proxy设置了。

Cloudflare

我们评估了许多CDN/DDoS代理提供商。我们根据其基础设施，响应能力和Railgun的承诺选择了Cloudflare。那么我们怎么能测试世界各地使用Cloudflare背后是怎样呢？我们需要设置多少台服务器以获得足够的数据点？没有！

Stack Overflow这里有一个很好的资源：每月数十亿次。记住我们刚刚谈到的客户端计时？我们每天都有数千万用户访问我们的网站，为什么不问他们呢？我们可以通过在Stack Overflow页面中嵌入<iframe>来实现。 Cloudflare已经是我们的cdn.sstatic.net主机（我们共享的，无Cookie的静态内容域）。但是，这是通过CNAME DNS记录完成的，我们提供了指向他们的DNS的DNS。要使用Cloudflare作为代理，我们需要他们来服务我们的DNS。首先，我们需要测试其DNS的性能。

实际上，为了测试性能，我们需要将二级域名委托给他们，而不是something.stackoverflow.com，它将具有不同的胶合记录，有时不会以相同的方式处理（导致二次查询）。为了澄清，顶级域名（TLD）是像.com，.net，.org，.dance，.duck，.fail，.gripe，.here，.horse，.ing，.kim，.lol，.ninja，.pink，.red，.vodka。和.wtf。不，我不是在开玩笑（这里是完整的列表）。二级域名（SLD）是一级以下，大多数网站将是：stackoverflow.com，superuser.com等。这就是我们需要测试的行为和性能。因此，teststackoverflow.com诞生了。有了这个新的域名，我们可以测试全球的DNS性能。通过为一定百分比的访问者嵌入<iframe>（我们为每个测试打开和关闭），我们可以轻松地从每个DNS和主机配置获取数据。

请注意，这里至少测试24小时是很重要的。互联网的行为全天变化，因为跨越时区，世界各地的人们或醒来或睡着或观看Netflix。所以要测量一个国家，你真的需要一整天。最好是在工作日之内，（例如不是半周六）。还要注意，它就是发生了。它一直发生。互联网的表现不是稳定的事情，我们有数据证明。

我们最初的假设是，我们将失去通过Cloudflare的一些页面加载性能（额外的跳跃几乎总是增加延迟），但是我们可以通过DNS性能的提高来弥补这些性能损失。这个DNS的一方付出了回报。 Cloudflare的DNS服务器更加靠近用户，远远超过了我们在单个数据中心能做到的。性能好太多了。我希望能尽快找到发布这个数据的时间。有很多的事情需要处理（和托管），而现在，我最缺的就是时间。

然后，我们开始通过Cloudflare代理teststackoverflow.com来测试页面加载性能，再次在<iframe>中。我们看到美国和加拿大稍微慢一些（由于额外的跳跃），但世界其他地区均达到平均水平或更高。这完全符合整体的期望，我们开始对Cloudflare的网络进行调整。该过程中遇到了一些DDoS攻击更加速了这一迁移，但这是另一个故事。为什么我们在美国和加拿大的表现稍差？那么大多数页面的页面加载大约是200-300ms，这还是非常快的。但我们不喜欢输。我们认为Railgun将帮助我们赢得胜利。

一旦所有的测试完成，我们需要把这些部分放在DDoS保护中。这涉及在我们的数据中心安装额外的专用ISP，以连接CDN/Proxy。毕竟，通过代理进行DDoS保护不是非常有效，因为你可以绕过它。这意味着我们现在每个数据中心都有4台ISP，其中有两套路由器，全部运行BGP，全表。它也意味着2个新的负载平衡器，专用于CDN/Proxy流量。

Cloudflare: Railgun

当时，这个设置也意味着为Railgun需要另外两个箱子。 Railgun的工作方式是通过在本地内存缓存和Cloudflare末尾来缓存该URL的最后一个结果。当启用Railgun时，每个页面（大小阈值）都会在送出时缓存。在下一个请求中，如果条目是在Cloudflare的边缘缓存和我们的缓存（由URL键入），我们仍然要向Web服务器发送请求。但是，不是将整个页面发送回Cloudflare，而只是发送一个差异。该差异应用于其缓存并提供给客户端。根据管道的性质，这也意味着用于传输的gzip压缩包从Stack Overflow的9个Web服务器移动到1个活动的Railgun盒子...所以这必须是一个相当好的CPU强壮的机器。我指出这一点，因为所有这一切都必须在迁移时进行评估，购买和部署。

例如，考虑2位用户查看问题。抓取每个浏览器的快照。他们几乎是同一个页面，所以这是一个非常小的差异。如果我们只是将这差异发送给用户，将是一个巨大的优化。

总的来说，这里的目标是减少发送回来的数据量，希望能够获得胜利。当它工作时，事实确实如此。Railgun还有另一个巨大的优势：请求不再是新的连接。延迟的另一个后果是TCP慢启动的持续时间和速度，这是阻止互联网流动的拥塞控制的一部分。 Railgun保持与Cloudflare边缘的长连接，并复用用户请求，所有这些请求都通过预启动的连接，并且缓慢启动不会被延迟。较小的差异也减少了整体上传的需要。

不幸的是，从长远来看，长远来看，我们从来没有办法让Railgun永无问题的工作。据我所知，我们（当时）是技术的最大部署者，我们将这一技术比以前任何时候都推动的更远。虽然我们试图对其进行一年多的故障排除，但我们终于放弃了。这不仅仅是为了节省成本，更是防止烧光我们的钱。现在已经好几年了。如果您正在评估Railgun，您应该评估当前版本，并对其进行改进，并自行决定。

Fastly

移动到Fastly是最近的事，但由于我们在讨论CDN/Proxy主题，我现在将讲讲这方面知识。这个举措本身并不是非常有趣，因为任何代理所需的大部分都是在上面的Cloudflare时代完成的。但是，当然每个人都会问：为什么我们弃用呢？虽然Cloudflare在许多方面非常吸引人，主要是许多数据中心，稳定的带宽定价和DNS，但这并不适合我们。我们需要一些快速简单的做法来适应我们：边缘更多的灵活性，更快的变化传播以及完全自动化配置推送的能力。这不是说Cloudflare是坏的，它已经不再适合Stack Overflow了。

因为行动更响亮：如果我没有高度评价Cloudflare，我的个人博客现在就不会落在他们身后。你好！你正在读它。

Fastly的主要特点且如此引人注目的是Varnish和VCL。这使得边缘高度可配置。所以Cloudflare不能轻易实现（因为它们可能会影响所有客户）的功能，我们可以自己做。这就是这两家公司不同的工作方式，即不同的架构方法，而且高度可配置代码的方法非常适合我们。我们也喜欢他们在会议，聊天等方面的基础设施的开放。

以下是VCL来的非常方便的例子。最近我们部署了.NET 4.6.2，它有一个非常讨厌的错误，在2000年以上的缓存响应中设置最大值。为缓解受影响的所有服务的最快方法是在边缘覆盖该缓存头。当我写这个的时候，以下VCL是活动的：

这允许我们缓存用户天赋3分钟（因为它是一个体面的字节数量），并绕过其它一切。 这是一个易于部署的全球解决方案，用于解决所有应用程序中的紧急缓存中毒问题。 我们非常非常高兴我们现在能够在前沿做的所有事情。 幸运的是，我们有Jason Harvey懂得VCL，并实现了我们的配置自动推送。 我们不得不改进现在的库，所以看看fastlyctl，另一个开源的项目。

Fastly的另一个重要方面（该方面Cloudflare也有，但是因为成本原因，我们从未使用）正在使用您自己的证书。 如前所述，我们已经在使用它来准备HTTP/2推送。 但是，Fastly不做Cloudflare做的事情：DNS。 所以我们现在需要解决。 这个依赖链不是很有趣吗？

全域DNS

从Cloudflare转移到Fastly时，我们不得不评估并部署新的（对我们来说）全球DNS提供商。 这本身就是一个完全不同的帖子，一个是由亨德森写的。 一路上，我们也在控制：

• 我们自己的DNS服务器（仍然回落）

• Name.com服务器（重定向不需要HTTPS）

• Cloudflare DNS

• Route 53 DNS

• Google DNS

• Azure DNS

• ...还有其它几个（用于测试）

这是一个整个项目本身。 我们不得不提出有效的方法，所以DNSControl诞生了。 这是一个开源项目，在GitHub上提供，用Go语言来写。 简而言之：我们将JavaScript配置改为git，并在一分钟之内部署到全球。 这是一个来自我们更简单的DNS站点的示例配置，askubuntu.com：

好的，你怎么测试这一切都在工作？ 客户端计时！ 我们上面介绍的那些我们使用真实世界的数据，而不是模拟来测试所有这些DNS部署。 但是我们也需要测试一切工作。

测试

部署上述的客户端计时对于测试性能非常有帮助。 但是测试配置并不好。 毕竟，客户端计时来查看结果是非常棒的，但大多数配置失误导致没有页面加载，因此没有任何时间。 所以我们必须构建httpUnit（是的，团队后来挖出了命名冲突...）。 这是Go中另一个开源项目。 teststackoverflow.com的示例配置：

当我们改变防火墙，证书，绑定，重定向等时，进行测试非常重要。 我们需要确保每次更改都是好的，然后才能为用户启动（通过在第二个负载平衡器上部署它）。 httpUnit是允许我们这样做，并运行集成测试套件，以确保我们没有回归。

我们内部开发了另一个工具（由我们可爱的Tom Limoncelli开发），可以轻松管理我们的负载均衡器上的虚拟IP地址组。 我们通过次级范围对非活动负载平衡器进行测试，然后将所有流量移动，使之前的主站处于已知状态。 如果有什么问题，我们会回滚。 如果一切正常（yay！），我们也对这个负载平衡器应用更改。 这个工具被称为keepctl（保持控制的简称） - 一旦时间允许，会将这个工具开源。

准备应用程序

上述几乎都是基础设施工作。这通常是由Stack Overflow的几个其他站点可靠工程师团队完成的，我负责找到合适的位置。还有更多的需要在应用程序本身内部进行。这是一个很长的名单。我会喝点咖啡和吃个士力架。

这里需要注意的一点是Stack Overflow＆Stack Exchange Q＆A站点的架构是多租户。这意味着，如果您访问stackoverflow.com或superuser.com或bicycles.stackexchange.com，您将访问同样的站点。您正在访问相同的服务器上的完全相同的w3wp.exe进程。根据浏览器发送的主机头，我们更改了请求的上下文。如果您了解Current.Site在我们的代码中是请求的站点，那么以下几个将会更清楚。像Current.Site.Url和Current.Site.Paths.FaviconUrl这样的东西都被从核心概念中驱逐掉了。

使这个概念/设置更清晰的另一种方法：我们可以在单个服务器上运行整个Q＆A网络的单个进程，但你不会知道。我们今天在9个服务器中的每一个上运行一个流程，纯粹用于滚动版本和冗余。

英文原文：https://nickcraver.com/blog/2017/05/22/https-on-stack-overflow/
译者：jianli

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！