让博客变得更快——Google Load Balancer 和 Google CDN 使用小记
两周前我发了一条推：
并且将自己的博客迁移到了 Google Load Balancer 上，顺便也调整了一下博客的部署结构，先说结论——新的结构在国内环境下访问速度有较大的提升，平均延迟下降了许多（从 200ms -> 40ms），费用也有较大的提升。
在许久的一篇文章「使用 Google Cloud Platform 的 Storage 托管静态站点并通过 Google CDN 加速」中我们知道，Google 的 CDN 在大陆有着较低的延迟，但是 Google CDN 只能套在 Google Load Balancer 上用，而 Google Load Balancer 也只能用在 GCP 家产品上，这样，如果要使用 Google CDN，就必须使用 Google 的不少产品，捆绑上车。
Google Load Balancer
我们知道，业界 Load Balancer 一般有以下实现方案：
- 一个 Anycast IP（比如 Google LB）
- 一个普通 IP（比如 Ucloud LB）
- 一个 CNAME 分区解析（比如 AWS ELB）
且不讨论 CNAME 那个看上去像是一个没钱 Anycast 的解决方案，而且如果用给 APEX 解析的话，在没有特殊加成(APEX FLATTEN)的情况会把 MX 记录炸穿（然后你就无法收邮件了），前者看上去是一个比较用户友好的方式，因为你只需要 A 记录到一个 IP 就可以了，绿色无害。
GFE
在了解 Google LB 之前，我们需要了解一个名词——GFE，感谢 Snowden 的 PPT，我们可以有一个直观的图示：
所有到 Google 的流量会在 GFE 上 SSL Offload（应该叫 SSL 卸载？），并且后端全部是在 Google 内网内以 HTTP 的方式进行传输。
在 Google Infrastructure Security Design Overview 中，我们也可以看到：
When a service wants to make itself available on the Internet, it can register itself with an infrastructure service called the Google Front End (GFE). The GFE ensures that all TLS connections are terminated using correct certificates and following best practices such as supporting perfect forward secrecy.
Google LB 也是一样，使用 GFE 作为面相用户的前端，将 SSL 流量在 GFE 上终结，然后以 HTTP 的方式回到后端的 Service 上。
使用一个统一的入口好处有很多，比如 GCP 就提供了一个统一的位置修改 SSL Policy：
可以自己选择心水的 Cipher Suite 和最低 TLS 版本等，和 Cloudflare 差不多（但是要让 Ucloud LB 做到这一点似乎就太困难了，他们基于 HAProxy 搞的 ULB 到本文发布时还不支持 TLS 1.3，而且要改 Cipher Suite 需要提工单）。
Premium IP
GCP 上的 IP 分为两种，一种是 Premium ，一种是 Standard，默认是前者，Google LB 也只能用 Premium。
Premium 使用的是冷土豆路由，所发送的数据包会保持在 Google 的内网内，并且在尽可能靠近用户的 PoP 离开。
比如，从 GCP 日本到美西的一台非 GCP 机器的路由追踪是这样的：
1?: [LOCALHOST] pmtu 1460
1: 4.68.70.161 105.157ms asymm 11
2: no reply
3: ??? 121.825ms asymm 14
4: no reply
5: no reply
6: no reply
7: us-east.novanetwork 118.394ms reached
Resume: pmtu 1460 hops 7 back 18
可以看到第一跳就已经到了 LEVEL3, - United States, Colorado, Louisville 的机房，之前的路由完全在 Google 内网下完成。
相比较之下 Standard 使用的热土豆路由，流量会在机房所在地丢出 Google 网络，剩下的事情走公网，也就是我们一般看到的路由追踪路径了。
SSL Certificate
说到 SSL，在「使用 Google Cloud Platform 的 Storage 托管静态站点并通过 Google CDN 加速」写作的时候，Google LB 上只支持使用自己的证书，这样对于 Let’s Encrypt 用户来说就非常不友好，因为需要每 3 个月去续一下，虽然 GCP 提供了 API 可以自助上传/更改证书，但是还是比较麻烦。
这一次，Google LB 支持 Managed Certificate，只需要创建 Cert，写上域名，将 IP 指过去，然后等小段站点完全不可用时间（20分钟左右），就可以了，证书签发机构是：Google Trust Services，最上层是 GlobalSign。
一个 IP 下最多支持 9 个 SSL 证书，考虑到 Google LB 较高的起步价（18 USD 起步）来看，多个人一起合租似乎是一个比较靠谱的选择，如果你有兴趣（且觉得本站打开速度蛮快，且希望自己的站的速度能变快，且你的服务器在日本附近）的话，欢迎来 联系 我。
哦对了，The managed SSL certificates feature is not covered by Cloud SLA。
Nginx Tune
Google LB 也是反向代理，对应的来源 IP 是 35.191.0.0/16 和 130.211.0.0/22，所以在自己的实例上可以选择将这个两个 IP 段白名单并且禁止其余 IP 的访问，可以参考「让 Nginx 只允许 Cloudflare 反向代理流量以隐藏源站」。
除此之外，还有两个需要 Tune 的地方：
- GFE 默认 response timeout 是 30s，所以如果有一个请求后端需要大于 30s 才能完成的话，在默认情况下会超时，但这个可以调。
- GFE 还有一个默认为 10 分钟的不可调的 TCP session timeout，在这个 timeout 区间内 GFE 和你的后端是一个 keepalive 的长连接，而 Nginx 默认是 75s，所以如果不调整一下的话，GFE 和后端会有一部分时间浪费在建立 TCP 连接上，这里推荐让 Nginx 超时时间改为 620s，Nginx 配置文件中写法如下：
keepalive_timeout 620s;
Cache Policy
Cloudflare 默认会缓存所有静态文件（比如 jpg, css, js, png, ppt），而且如果需要全部缓存的话只需要指定一个 Page Rule 就好了，而对于 Google CDN 来说，要让一个资源被缓存，需要：
- It was served by a backend service or backend bucket with Cloud CDN enabled.
- It is a response to a
GETrequest. - Its status code is
200,203,206,300,301,302,307, or410. - It has a
Cache-Control: publicheader. - It has a
Cache-Control: s-maxage,Cache-Control: max-age, orExpiresheader. - It has a
Content-Length,Content-Range, orTransfer-Encodingheader. - Its size is less than or equal to the maximum size.
好处是更加灵活了，坏处是需要手动改 Nginx，而不能像 Cloudflare 那样在后台面板上直接修改，而且 Google CDN 也没有提供一个 Purge All Cache 的选项，只能像 AWS S3 那样一个个手动 invalidation，比较原始。
Higher Performance/Price Ratio
在上面提到的文章中我们知道，如果 Google Load Balancer 的后端是 Google Storage 的话，是没有 HTTP 到 HTTPS 的重定向的，加上我博客并不是静态页面，所以就需要一个 Instance Group 作为 LB 的后端。
从性价比来说，使用 GCP 的 Instance 其实并不高，GCP 中默认创建的实例 CPU 为 Intel(R) Xeon(R) CPU @ 2.00GHz，如果你需要一个 1C，1.7G 内存的 g1-small 机器，每个月的实例费用（不包括流量）为 14.20 USD，而这个价格在 Vultr 上可以买到主频为 3.8GHz，2G 内存，64G NVMe 空间的 High Frequency Compute，在自己的 ab 测试情况下，后者的 Request per Second 可以是前者的 3 倍左右。
所以最实惠的方案似乎是在 GCP 上起一个配置一般的实例，并在 Vultr 附近可用区内创建一个 High Frequency Compute，两点通过 Wireguard 打通，并让 GCP 转发流量，这样可以做到更高的性价比，大概像这样：
Pricing
上面说了那么多，这样一套结构，在 GCP 这一侧价格大概如何呢？
| Product | Price(USD) |
|---|---|
| Google LB + Google CDN | 18/month |
| GCP instance * 2 (g1-small) | 28.4/month |
| Traffic to China | 0.23/G |
| Traffic to US | 0.14/G |
Faster and Faster
切换到 Google CDN 之后，在部分同学那儿反应速度已经提升了不少，在阿里云上海机房段可以做到秒开，但是其实还是有很多可以改进的地方的。
比如博客用的 DNS，依然是 Cloudflare 的 IP，在国内普遍延迟 200ms，所以之前是 200ms 解析 + 200ms 连接的话，现在是 200ms 解析+40ms 连接，我们应该还可以更快一些，比如使用 NS1 作为 DNS 服务商（可以降到 60ms 左右），不过由于 nova.moe 域名上面有不少需要 Cloudflare 反代+缓存的内容，一时半会还没法迁移走。