2022 年 12 月 18 日，阿里云香港服务出现了异常。本站所用的香港服务器也中招，由于本人不正确的报警配置，导致部分域名没有正确切换解析，造成了一小部分用户最长半小时的不可用。然而，阿里云香港机房出现问题的时间远不止一个小时。根据我这里的监控，自北京时间 10:49 开始，我跑在香港阿里云上的 HTTP、HTTPS 服务就完全不可用了，直至 20:46 才恢复，共计宕机时间 10 小时。

事故回顾

本人是在早上起床后就发现阿里云香港服务器不可用。一开始以为是被神秘力量封锁了，但是看到报警邮件后发现，香港服务器在国外其他地区也不可用。

然后我就测了一下，发现主机能 ping，但无法 SSH 上去，HTTP/HTTPS 服务亦不可用。此外，yangxi.tech 网站服务也受到了影响。然后我登录了 AWS 中国区的 Route 53 去查看报警，结果发现 Route 53 上没有任何报警（我的 guozeyu.com 和 yangxi.tech 都在用中国区 Route 53）。查看最近的监控，发现我在 Route 53 上有一处配置错误，导致程序实际上没有在监控香港阿里云……于是修改了监测规则。此时我登录了 AWS 国际区，发现国际区的阿里云香港监控是在正常报警，发现是从 10:49 开始，全球所有监测点均不可用。

由于此时 AWS 中国区的报警已经被我改成正确的了，所以已经根据规则，在 DNS 层面进行自动宕机切换了；而且，我之前配置的 DNS TTL 也仅有 120 秒，所以我的所有网站应该在 11:20 前就已经完全恢复正常了。如果没有错误的报警规则，我的网站总共宕机时间也不会超过 5 分钟。

然后我登录了我自建的 Observium 监控，不出意外的看到了阿里云香港的机器已经宕机了。但我发现在宕机前，服务器的 CPU 是 100%。我就怀疑这是不是我自己服务器上某个程序卡死了，占用了所有资源，导致看起来 HTTP/HTTPS/SSH 服务都不可用了。

此时已经 11:30 了，我还觉得这个是我自己的问题，毕竟我也没收到阿里云任何邮件、电话提醒。于是我登录了阿里云后台，尝试进行重启。此时我没有选择强制关机。结果，关机指令已经执行了 10 分钟，机器仍未关闭。平时我使用 GCP 时，如果关机指令执行超过两分钟，那么就会自动执行强制关机，所以此时执行了 10 分钟的关机就很离谱。然后我就尝试发工单，但没能进入到工单，被转到了在线客服。我向在线客服描述了问题后，无人回复。然后我又尝试发工单，结果工单也是无人回复。只是得到了机器人回复，说在关机时，Windows 会执行系统更新，有时需要 10-15 分钟。请在等待 20 分钟后联系客服。

大概又过了半个小时，机器终于成功关闭了，但在尝试多次后，机器无法启动。即便我点了启动，机器也会在一段时间后变成 “已停止” 状态。由于此时我还是以为是我自己的问题，不是阿里云的问题，我以为是刚刚强制关机导致系统损坏了，于是尝试给现有云盘打快照，尝试回滚。但离谱的事又发生了，我发现我根本无法打快照！快照的进度一直是 0%。

在 11:55，我终于收到了工单的回复：“您好！阿里云监控发现香港地域某机房设备异常，影响香港地域可用区C的云服务器ECS、云数据库polardb等云产品使用，阿里云工程师已在紧急处理中，非常抱歉给您的使用带来不便，若您有任何问题，请随时联系我们”。此时我才知道，这次的宕机可能不是我自己的问题，我放弃了自己尝试恢复服务。

该回复没有提供解决方案，也没有预计的恢复时间，可以说无非就是告诉了我 “这个是我们阿里云的问题”，对于恢复服务没有实质性帮助。

无力吐槽阿里云

本次事件最值得吐槽的地方是，我从未收到阿里云发来的有关通知。直至现在，我在邮箱、短信、站内信中没有收到任何阿里云关于此次服务宕机的提醒。我相信阿里云是有很多监控的，我坚信阿里云早在我发现我的服务出现问题之前，就已经知道了我的服务，以及其他人的服务器出现了问题了。但我却没有收到任何通知。唯一告知我阿里云存在问题的还是我发工单自己问出来的。

我觉得阿里云有必要向所有受影响的，以及可能受影响的客户发送相关提醒。在连续宕机了 8 小时，且仍未恢复的情况下，阿里云仍不主动通知客户，我实在是难以怀疑阿里云是否是故意不做通知，试图掩盖问题。

那还用阿里云吗？

会的。作为中国第一大，以及全球也能排的上前几的云服务商，我不怀疑阿里云的技术实力。我现在用阿里云主要是为了阿里云香港的 CN2 精品网，用于数据跨境（价格为 3元/GB）。目前在这方面也没有什么可替代的方案。专线也考虑过，太贵了，买不起。

但是，我不会把核心业务放在阿里云上了。放在 AWS 上我更安心一些。本次阿里云香港宕机只影响了我的网站一小会儿，也正是因为我没有把核心业务放在阿里云上。

本站是如何做到高可用的？

很简单，本站在四个地区，使用了四个不同服务商的服务器：

• 德国 OVH
• 北京 AWS
• 香港 阿里云
• 美国 Google Cloud

而且本站是纯静态网站。本站会在构建后，将构建产物分别同步到四个服务器上，没有主服务器的概念。本站通过 GeoDNS，将访客解析到最近的服务器，以降低延迟。在阿里云香港服务器宕机后，只需要停止响应解析即可。原本亚太地区解析到香港，现在亚洲会解析到北京，澳洲会解析到美国，这部分用户就被分流到可用的服务器上了。

本站还使用了 Route 53 的 Health Check 功能，可以实现接近实时的监控主机运行状态，在发现运行状态异常时，自动停止响应解析。目前，我的网站会在出现异常后一分钟内检测并识别到，并停止响应解析。相关 DNS 记录的时间设置在了 120 秒，因此服务发生不可用时，用户影响的时间不会超过 3 分钟。

基本概念

这个视频介绍了 “基本概念”，下方文字是这个视频的概要。如果你熟悉域名相关的概念，可以直接跳转到操作步骤

域名

什么是域名？域名是互联网上的地址，用户通过域名来访问包括邮件、网站、App 在内的互联网资源。比如常见的以 .com 结尾的域名，以及新出现的 .xyz 和 .tech 结尾的域名。域名的价格大多在 40 到 200 元之间，具体的价格取决于域名后缀。

域名需要在注册商购买。那么如何选择域名注册商呢？这里推荐氧熙科技，通过与全球第七大注册商 PDR 合作，提供三百多种域名后缀的优惠注册。其特点是无需实名认证，支持支付宝或微信支付，自动发货，支持退款。

服务器

注册了域名之后，还需要有一个服务器，才可以建立自己的网站。服务器主要分为三种类型，包括虚拟主机、云服务器和独立服务器。这里推荐氧熙科技的虚拟主机，即适合新手，也适合专业人士使用。

其次是服务器位置，氧熙科技销售的虚拟主机可以选香港和美国加州两个位置，香港和美国加州的服务器都不需要备案。这里推荐香港主机，国内的访问速度更快。

软件

这里推荐WordPress建站软件，全球有 65.3% 的网站使用WordPress 作为 CMS，并且可一键安装到虚拟主机。

操作步骤

这个视频介绍了 “操作步骤”，下方文字是这个视频的概要。

购买域名和虚拟主机

首先需要购买域名和主机。新购买的虚拟主机可能需要半个小时才可以使用，在可以使用时会收到邮件提醒。

修改域名服务器

主机创建成功后，需要前往域名注册商将域名的服务器修改为虚拟主机的域名服务器。

安装 WordPress

前往管理虚拟主机进入 cPanel 面板，进入 WordPress Manager 去安装 WordPress。安装时需要暂时将协议调整为 http:// 开头的协议。

SSL 证书

修改域名服务器 48 小时内，SSL 证书会自动签发，然后就可以使用 https:// 协议访问网站了。

本文推荐一些本人用过或者正在使用的云服务，持续更新。未来还会增加购买建议。

云计算 Compute/VPS/EC2

最便宜: Scaleway Stardust

0.5GB RAM ，每月 €0.36，限速 100Mbps 不限流量（该价格为仅 IPv6 的价格，约¥2.48）购买链接

• N/A 代表共享核心

目前只有 Paris 1 和 Amsterdam 1 有。前往上方购买链接（如果跳转到了登录/注册页面，请在登录后再点一次，即可直达 Stardust 购买页面），如果遇到无货，就拉到最底部复制 API，用 API 创建机器一般可以绕过前端的无货购买限制。

性价比: BuyVM

1GB RAM ，每月 CA$3.50 ，1Gbps 不限流量（约¥17.77 ）。购买链接。注意，BuyVM 的计费周期是每月 1 日，所以若购买时不是 1 日，那么首月的价格会有所变化（因为到下个月或下下个月的 1 日不是整一个月）。

• N/A 代表共享核心，100% 代表每个核心均为独立核心

配置更高的主机价格是同比例增加的，可以参考 4GB 版本乘以 N。

付款时使用支付宝即可使用 CA$ 同币值缴费，相对要比美元便宜很多。本网站就在使用 BuyVM，如果你从美国西部访问此页面，那就会使用 BuyVM 的服务器。

BuyVM 还可以购买 Block Storage Slab，每 TB 仅需要 $5.00，最低每月 $1.25 就可以买到 256GB。

国内网络好: AWS Lightsail

0.5GB RAM ，每月$3.50 ，限流量 1TB ，可开日本、法兰克福、美国西部均可直连（约¥22.21 ）购买链接

• 代表每个 CPU 的基线性能，均可 Burst，Lightsail CPU 基线详情

本网站就在使用 Lightsail，如果你从美国东部或者亚洲 (中国大陆外) 访问此页面，那就会使用 Lightsail 的服务器。Lightsail 可以免费附加静态 IPv4；IPv6 则是随机器附带的，暂不可保留或迁移。此外，Lightsail 的自动快照功能是免费的，可以作为自动备份。

与其他同类产品对比

Vultr/Linode/Digital Ocean 都是与 Lightsail 类似的产品，价格也与 Lightsail 十分接近。他们可能没有 CPU 基线的限制，但这也未必是好事，因为失去了限制更有可能受到邻居（同机器上其他用户）的影响。这里有一些优惠码：

• Vultr $100 优惠码: 赠金 14 日内有效
• DigitalOcean $100 优惠码: 赠金 60 日内有效

大内存、多 IP: OVH VPS

2GB RAM，每月 $3.5（或 3 欧元），限速 100Mbps 不限流量，法兰克福可直连中国，但美国可能绕欧洲。OVH 两欧就可以买一个额外 IPv4 ，该 IPv4 没有月费，只要机器在 IP 就一直是你的。一个账户可以买 16 个额外 IPv4。美国区购买链接、国际美元区购买链接、国际欧元区购买链接

美国境内机器只有美国区可以购买，其他位置机器需去国际区购买。

• N/A 代表共享核心

本网站就在使用 OVH，如果你从欧洲访问此页面，那就会使用 OVH 的服务器。

永久免费: Google Cloud Compute Engine

美国 us-central-1，us-west-1，us-east-1 区域，1GB RAM ，30GB 最基础的盘，仅 IPv4 ，出站流量自费。这个试用期过了也免费！

• 12.5% 代表每个 CPU 可以有 12.5% CPU time，可 Burst，GCP E2 共享 CPU 详情

最灵活: AWS EC2

AWS 国际区，AWS 中国区

本网站就在使用 EC2 (中国区)，如果你从中国大陆访问此页面，那就会使用 EC2 的服务器。目前 AWS 中国区仅限企业注册。

与 Google Cloud 的 Compute Engine 和 Azure 的 VMs 对比

Google Cloud 的按量付费可能是三者中的最便宜的，此外个人感觉 Google Cloud 的操作页面使用起来相比 Azure 和 AWS 更简单。这几家提供的产品都大同小异，此外他们也都可以预留实例一年到三年，实现最大化折扣

与阿里云、腾讯云对比

最大的区别是计费模式。AWS 无论是国内版还是国际版，均默认使用后付费模式，即类似信用卡，每月支付上一个月结算的账单。而阿里云和腾讯云无论是个人用户还是企业用户，均使用预付费模式。哪怕使用的是按量付费的机器，竟然也需要提前充值；余额耗尽后会直接停机。所以用阿里云或腾讯云的按量计费服务之前，无比要保证有充足的余额，不然将欠费了将直接影响生产环境。

此外，阿里云和腾讯云在 API 使用上没有 AWS 方便。虽然 AWS 国内版在国内没有阿里云那么大的占有率，但由于 AWS 国内版和国际版 API 保持了一致，因此 AWS 的文档资源要远比阿里云、腾讯云丰富的多。

个人认为，AWS 国际版完胜阿里云、腾讯云的海外区域，AWS 国内版核心问题是支持的可用区太少，只支持北京和宁夏两个区域；Azure 国内版支持的区域比 AWS 国内版要多一点；阿里云和腾讯云在国内区域数量上是远多于 AWS 的。不过在网络方面，目前 AWS 国内版也是 BGP 接入，线路完全不比阿里云差。

数据跨境方面（指中国大陆境内与境外之间的跨境），阿里云提供了香港精品网、云企业网，这是 AWS 所没有的。

虚拟主机

这里推荐氧熙科技/TlOxygen 的虚拟主机，香港位置采用 CN2 GIA 线路，美国加州也是国内直连；均无需备案，购买后即用。相比之下，美国加州提供更多的流量和存储，带宽也更大。他们的虚拟主机还支持 SSH 访问、Let’s Encrypt 证书自动签发（不可 root）。香港/加州虚拟主机购买链接

CDN

等待补充

DNS

等待补充

域名注册类

等待补充

本文将带领你注册属于自己的域名，并获得以自己的域名结尾的专属邮箱。全程仅需不到 10 分钟[1]。你只需要一台可以上网的设备，支付方式（微信/PayPal/银行卡）和一个现有邮箱。通过本文提到的域名注册商注册的 .com 域名价格为 CN¥79.20/年，并且续费不涨价。该域名注册商免费提供企业邮箱服务，因此不需要额外付费。

[1]：由于全球 DNS 服务器同步需要时间，可能需要 24-72 小时后域名上的服务才能够使用。若注册 .cn 等中国域名还需要进行实名认证，需要额外的时间。其他国际域名（如 .com）则不需要实名认证。

注册域名

首先，你需要注册一个属于自己的域名。域名的注册门槛很低，基本在几分钟内就可以完成注册，并且包括 .com 在内的众多域名后缀均不需要进行实名登记。通常，大多数域名都是按年进行购买。

本文推荐的是 氧熙域名注册 (原 TlOxygen)。该注册商是本站站长亲自建立，是全球第 7 大的域名注册商 PDR Ltd. 的最高级代理之一，提供更多的支付方式和更低的价格。从这里购买域名可以帮助本站持续发展。并且本站域名注册提供了域名删除与退款服务、免费企业邮箱和域名锁等服务。

首先，前往 氧熙域名注册主页（也可以浏览器地址输入 yangxi.tech 前往），进行域名搜索。比如，如果想要注册 guozeyu.com，只需要在搜索框里输入这个域名并点击搜索。如果你不确定想要注册什么后缀，那么也可以不输入后缀，如 guozeyu。如果你更习惯英语界面，或者需要以美元计费的结算方式，请前往 International Version。

可以看到，咱们心仪的域名已经被注册了。但是页面下方可以看到更多的 “其他可注册的匹配域名”。

我们这里选择 guozeyu.online。注意划线价为域名续费的价格，为了可以方便地给域名续费，建议选择续费价格较低的域名。比如 .com 域名续费只需 CN¥79.20/年（国际版为 US$12.59/年），而 .online 的续费价为 CN¥270.00。我对域名的价格一向非常透明，我承认这绝不是市面上最低的价格。下表列出了一些注册商 .com 域名的续费价格

[2]：阿里云万网/DNSPod 注册 .com 域名需要实名认证，可能需要几天后域名才能够正常使用
[3]：Cloudflare Registrar 上注册的域名不支持修改 DNS 解析商、NS 记录，以及粘附记录（Glue Record）

完整的价格列表：中国大陆（人民币）， International Version (USD)

注意，本文后续的内容仅适用于在氧熙注册的域名。在其他注册商注册的域名配置有所不同。此外，并不是所有注册商都免费提供 DNS、企业邮箱和域名转发服务。

然后进行结账。结账时建议选择免费的 “隐私保护” 功能，这样你的注册信息（包括邮箱、手机号、地址）就不会公开：

然后填写注册信息。请确保注册信息是有效的（可以通过电子邮件联系到你），否则域名注册可能会失败。注册完成后即可选择支付方式了。目前支持的支付方式有微信支付、银行卡、PayPal

付款完毕后，会自动跳转到支付成功页，点击 “继续管理订单” 进入后台管理页面。

此时，你就可以看到你新注册的域名了。

配置 DNS

点击你刚刚注册的域名，然后前往 DNS 管理菜单，点击 “管理DNS” 以激活 DNS：

如果你看到 “您即将提交的信息不安全” 提示，请选择 “仍然发送”。随后看到如下页面即说明已经激活了：

配置企业邮箱

此时我们已经拥有了域名，但该域名下还没有任何服务。我们首先配置企业邮箱，实现任何发往 @guozeyu.online 的邮件都转发到自己的邮箱里。这样有很多好处，比如你可以在注册微博的时候使用 weibo@guozeyu.online，在注册 GitHub 时使用 github@guozeyu.online，这样可以区分不同服务商发来的邮件；也可知道是谁卖了自己的邮箱信息，给自己发送垃圾邮件。

前往电子邮件菜单，点击 “管理电子邮件” 以激活企业邮箱：

如果看到 “待验证域所有权 (Pending Domain Ownership Verification)”，则说明 DNS 尚未完成激活，请在 24-72 小时后尝试。新注册的域名默认使用我们提供的 DNS 服务器，邮件记录已经自动配置好了，所以无需手动添加记录。同时，你也可以点击 “设置 (Settings)”，选择 “修改语言偏好 (Modify Language Preference)” 然后选择 “Chinese (Simplified)” 以切换语言到简体中文。此外，如果你知道自己在做什么，也可以将域名换到其他 DNS 服务商，手动配置 DNS 记录。

待 24-72 小时，完成域名所有权验证后，你将看到如下页面，这时我们选择 “添加只转发帐户”：

这里我们用户名输入字母 i，“转发至” 输入自己的邮箱。这里只是拿我的邮箱演示。

添加成功后，发往 i@guozeyu.online 的邮件就会转发到你刚刚配置的 “转发至” 邮箱了。但发往其他用户名的邮件依然会被拒收。此时我们需要配置 Catch-All：

然后选择 “转发到以下用户/账户”，并输入刚刚设置的用户名 i，然后点击 “应用” 即可。

配置域名转发

目前，浏览器里的网站是无法访问的，因为我们还没有配置用于 Web 的服务器，也没有建立自己的网站。但我们可以配置域名转发，将访问到域名的的流量跳转到其他 URL。比如，你可以设置跳转到自己的微博、GitHub 等网站。具体操作如下：

前往域名转发菜单，点击 “管理域名转发” 以激活域名转发：

此时，你可以配置要转发的域名和要转发到的地址：

同时，也可以选择高级设置。我建议关闭 “URL掩蔽 / 重定向 / URL隐藏”。

同样，该配置需要 24-72 小时后才能生效。

总结

本文介绍了如何注册属于自己的域名，建立以自己域名结尾的的企业邮箱，以及配置域名转发。后续的文章将会更新如何建立属于自己的个人网站。可以点击页面顶部的关于按钮订阅本网站，这样就不会错过后续的内容啦～

最近 DNSPod 的解析服务器宕机了一段时间，导致许多 DNSPod 用户的网站无法访问。本文将推荐几个提供 100% SLA 的海外 GeoDNS 服务，可用于替代不稳定的 DNSPod。并介绍一下使用多家 DNS 提供商来提高服务可用性的方法。

本文包括 Azure DNS、NS1、Constellix 的全面对比。

简介

这次推荐的三家 DNS 均是海外的支持 GeoDNS 的服务商，并都支持 Anycast。其中的 Azure DNS 和 NS1 在国内的速度都非常好，是直接走的香港/亚洲线路，平均延迟能够在 50ms 以内，不输国内 DNS 服务商。而这三家的海外速度都是极快的，可以秒杀 DNSPod、CloudXNS、阿里云解析等国内提供商。

关于 GeoDNS，精细度最好的是 Constellix：支持国家、省、市（包括中国的省、市），甚至是 AS 号（可以实现分运营商解析）、IP 段。NS1 支持国家、美国的州，也支持 AS 号、IP 段。至于 Azure DNS，通过使用 Traffic Manager，可以支持国家、部分国家的州、IP 段。由于都支持 IP 段，所以理论上支持任意精度的 GeoDNS 了。

至于价格，NS1 提供了免费额度（每月 500k 请求），对于小流量网站而言是够用的，可一旦超出这个免费额度，那么收费是很高的：**$8/百万个请求**。相比而言，Azure DNS 和 Constellix 的价格都很便宜了，其中 Constellix 有 $5/月 的起价。

使用多家 DNS 服务商

同时使用多家 DNS 服务商是可行的，只要使用服务商的 DNS 记录保持相同即可。这要求所使用的服务商能够配置主域名的 NS 记录（建议但不是必须）。这次介绍的 Azure DNS、NS1、Constellix 三家，以及以前介绍过的 Route 53、Google Cloud DNS、Rage4、阿里云解析均可配置主域名的 NS 记录（其中阿里云解析和 Azure DNS 只能额外添加第三方记录；其他几家可以完全自定义 NS 记录）。而 Cloudflare 以及国内的 DNSPod、CloudXNS、阿里云解析由于不能配置主域名下的 NS 记录，意味着你不能很好的进行 DNS 混用。

要使用多家 DNS，有两种实现方法：主服务商和从服务商方式以及两个主服务商方式。完成配置后，将多家的 NS 服务器配置到权威 NS 记录以及域名注册商下的 NS 列表。

使用两家服务商会增加配置难度，但可以提高 DNS 服务的稳定性。如最近的 DNSPod 宕机以及 2016 年的 Dyn 宕机所导致的众多网站无法访问，均是因为众多网站仅使用了一家 DNS 提供商。如果使用了多家 DNS 提供商，则网站仅会在所使用的所有服务商均发生宕机事故时才会无法访问，而这显然发生概率很小。

主服务商和从服务商

要想这样配置，需要从服务商支持使用 AXFR 从主服务商获取记录，还需要主服务商也支持 AXFR 传输。其中，NS1、Constellix 均可作为主服务商或从服务商，意味着你可以同时使用这两家，并选择任何一家作为主服务商，另一家作为从服务商。

两个主服务商

你也可以使用两个主服务商，并保持所有的记录（包括主域名下的 NS 记录）相同（建议，但不是必须）。建议也将 SOA 的序列号同步。

样例

github.com. 这个域名就同时使用了 Route 53 和 DYN 的服务。这可以使用 dig 工具验证。

$ dig github.com ns +short  ns1.p16.dynect.net.  ns2.p16.dynect.net.  ns3.p16.dynect.net.  ns4.p16.dynect.net.  ns-1283.awsdns-32.org.  ns-421.awsdns-52.com.  ns-1707.awsdns-21.co.uk.  ns-520.awsdns-01.net.

经检验，在两家 DNS 服务商也配置了相同的记录。

$ dig @ns1.p16.dynect.net. github.com a +short  13.229.188.59  13.250.177.223  52.74.223.119  $ dig @ns-1283.awsdns-32.org. github.com a +short  13.229.188.59  13.250.177.223  52.74.223.119  

下面逐个介绍一下这三家 DNS 提供商。

所有 DNS 测评一览（还包括 CloudXNS、Route 53、Cloudflare、Google Cloud DNS、Rage4 以及阿里云解析）

Azure DNS

微软 Azure 产品线下的 DNS 服务。使用 Anycast 技术，并且国内能够直接连接到香港/亚洲节点，所以速度很快。

值得注意的是，类似 Route 53，Azure 所分配的四个服务器使用的是不同的网段、不同的线路，可能有更高的可用性。

注意：Azure 的 DNS 的分区解析可能不兼容 IPv6，这意味的解析结果可能会被 Fallback 到默认线路。

• 国外速度：★★★★☆，36 ms
• 北美速度：★★★★☆，27 ms
• 亚洲速度：★★★★☆，39 ms
• 欧洲速度：★★★★☆，29 ms
• 国内速度：★★★★☆，49 ms
• 最短 TTL：0s
• 国内分区解析：★★★★★，支持配置到中国，支持 IP 段配置（配合 Traffic Manager）
• 国外分区解析：★★★★★，支持配置到大州、国家以及部分国家的州，支持 IP 段配置（配合 Traffic Manager）
• DNSSEC：不支持
• IPv6：支持
• 记录类型：支持 A、AAAA、CNAME、NS、MX、TXT、SRV、CAA、PTR。
• 根域名 CNAME 优化：不支持
• 优先级：支持（配合 Traffic Manager）
• 自定义 NS：仅支持添加额外的 NS
• 价格：每个域名 $0.5/月，**$0.4/百万个请求**
• 用例 A 价格：**$0.90**
• 用例 B 价格：**$10.50**
• SLA：100%

NS1

NS1 也使用了 Anycast 技术，并且国内能够直接连接到香港/亚洲节点，所以速度很快。

• 国外速度：★★★★★，23 ms
• 北美速度：★★★★★，9 ms
• 亚洲速度：★★★★☆，40 ms
• 欧洲速度：★★★★★，20 ms
• 国内速度：★★★☆☆，65 ms
• 最短 TTL：0s
• 国内分区解析：★★★★★，支持配置到中国，支持 IP 段配置。
• 国外分区解析：★★★★★，支持配置到大州、国家、美国的州，支持 AS 号、IP 段配置。
• DNSSEC：支持
• IPv6：不支持
• 记录类型：支持 A、AAAA、AFSDB、CAA、CERT、CNAME、DS、HINFO、MX、NAPTR、NS、PTR、RP、SPF、SRV、TXT。
• 根域名 CNAME 优化：支持
• 优先级：支持（配合 Traffic Manager）
• 自定义 NS：仅支持添加额外的 NS
• 价格：每月前 500k 请求免费，超出部分 $8.0/百万个请求
• 用例 A 价格：**$4**
• 用例 B 价格：**$156**
• 用例 C 价格：**$156**
• SLA：100%

Constellix

此 DNS 以 GeoDNS 优势著称，使用了 Anycast 保证最低的延迟。

Constellix 三组有六个 DNS 服务器，每一组使用了不太相同的线路。

• 国外速度：★★★★☆，31.51 ms
• 北美速度：★★★★★，9.81 ms
• 亚洲速度：★★★★☆，48.87 ms
• 欧洲速度：★★★★★，23.77 ms
• 国内速度：★★☆☆☆，108.9 ms
• 最短 TTL：0s
• 国内分区解析：★★★★★，可以精确到每一个省、市，可以配置 ASN 以实现运营商分区解析。
• 国外分区解析：★★★★★，精确到了各个国家、省、市
• DNSSEC：不支持
• IPv6：支持
• 记录类型：更加齐全，只支持 A、AAAA、CNAME、NS、MX、TXT、SRV、HINFO、NAPTR、CAA、CERT、PTR、RP、SPF。
• 根域名 CNAME 优化：支持
• 优先级：支持
• 自定义 NS：支持
• 价格：第一个域名 $5/月，此后每个域名 $0.5/月。**$0.4/百万个请求**。分区解析 $0.6/百万个请求
• 用例 A 价格：**$5.39**
• 用例 B 价格：**$14.90**
• 用例 C 价格：**$19.30**
• 统计功能：支持，可以看到每个国家、城市的请求数。甚至还可以启用日志，看到每一个请求的客户端 IP、IP 数据包类型等等。
• SLA：100%

本网站曾经一直将国外解析到 CloudFront 实现为国外加速，最近看到 Cloudflare 支持了 Argo 这一新功能，于是就把国外的 CDN 从 CloudFront 换到了 Cloudflare 并开启了 Argo 来试一下效果，官方宣称无缓存时能明显降低 TTFB（首字节延迟），有缓存时也能提高缓存命中率。本文还会将其与 Cloudflare 的另一个企业级的 CDN 加速黑科技——Railgun 进行对比。

Cloudflare Argo

提升缓存命中率，Argo Tiered Cache

Cloudflare 的节点很多，但是节点太多有时不是一件好事——大多数 CDN 之间的节点是相对独立的。首先要先明白 CDN 的工作原理，CDN 通常不会预先缓存内容，而是在访客访问时充当代理的同时对可缓存的内容缓存。就拿本站来说，本站用的是香港虚拟主机，如果有英国伦敦的访客访问了我的网站，那么由于我的网站是可被缓存的，他就会连接到伦敦的节点并被缓存在这个节点。那么如果是英国曼彻斯特的访客访问了呢？由于 CDN 在曼彻斯特另有节点，访客会直接连接到曼彻斯特节点，然而曼彻斯特上并没有缓存，所以该节点会回源到香港。而显然的是，如果曼彻斯特回源到伦敦，使用伦敦的缓存会更快。 综上，如果能选择性的从其他节点上获取资源，TTFB 会更低，缓存命中率也会相应提高。但是一般的 CDN 不会去这样做，因为节点相互独立，节点之间并不知道对方是否已经缓存。一般的解决方法是节点与源站之间先经过为数不多的几个节点，这几个节点可能只是分布在几个州，比如整个欧洲就只有一个这种节点。这样的话，伦敦的访客访问后，同时也被欧洲的那个节点缓存。这样，当再有欧洲其他地区的访客连接到一个没有缓存的节点时，这些节点会直接提供欧洲的那个节点的缓存。CloudFront 和 KeyCDN 就利用了这样的技术。 Cloudflare 是如何实现的他们官方没有详细说明。然而在实际测试时，并没有观察到缓存率上有明显提升，远比不过 CloudFront 的效果。下图是通过这些节点测试的 TTFB，请求是逐个发起的。

降低 TTFB，Argo Smart Routing

通常情况下，节点与源站的连接是直接的，这之间的网络很大程度上取决于主机的网络接入。然而，有了 Argo Smart Routing，Cloudflare 会使用自己的线路。图片来自 Cloudflare.com。

国外请求测试地址，其中的 via 字段就是 Cloudflare 与本站建立的连接的 IP 地址。通过 GeoIP 服务查询，发现是香港的 IP。Cloudflare 将自己的节点之间都建立了长连接，并在离源站最近的服务器上与源站也提前建立了连接。这样，就能大大降低首次连接所需要的时间。如果回源是 HTTPS 的，那么效果更明显。我的另一个测试地址是没有开启这个功能的，用来对比，它的回源与本站建立的 IP 就不是香港的。

使用 Flexible SSL 的 TTFB 对比

使用 Full SSL 的 TTFB 对比

速度的确有一定的提升，但是不是特别明显，而且似乎开启了之后一些节点反而更不稳定——原本都是比较稳定的一个速度，开了这个之后一些节点反而忽快忽慢。看来提速的最佳方法还是半程加密。

Cloudflare Railgun

Railgun 是 Cloudflare 专门为 Business 和 Enterprise 企业级客户提供的终极加速方案。要使用它，先需要升级网站套餐为 Business 或 Enterprise，然后还需要在服务器上安装必要软件并在 Cloudflare 上完成配置。这相当于是一个双边加速的软件，其实现原理是让服务器与 Cloudflare 建立一个长久的 TCP 加密连接，使用 Railgun 独有协议而不是 HTTP 协议，这样显然能减少连接延迟。此外，它还会对动态页面缓存：考虑到大多动态页面都包含了大量相同的 HTML 信息，在用户请求一个新的页面时，服务器将只发送那些变化了的内容。这相当于一种多次的 Gzip 压缩。

官方宣称，使用 Railgun 能够实现 99.6% 的压缩率，并实现两倍的速度。实际体验也确实如此：

Railgun 的加速效果还是非常之明显的，明显强于 Argo。

总结

Argo 并没有想象中的那么好用，而且 $5/mo 的起步价和 $0.10/GB 的流量并不便宜。当然也有可能需要一段时间 Argo 去分析线路延迟才能更好的进行优化。本文预计将在一个月后补充更新。 Railgun 效果还是极其显著的，但是它需要企业版套餐才能够使用，并不亲民。

动态内容

延迟：Google Cloud CDN 延迟最低，Cloudflare Railgun 仅次。 流量：对于普通的动态 CMS，Cloudflare Railgun 大约能节省 10 倍以上流量，Google Cloud CDN 是做不到的。 我在国内外几家全站 CDN 对比中测试 Google Cloud CDN 时，其极低的 TTFB 令我惊讶，仔细研究后发现节点是与主机之间建立长连接，而且会保持很长一段时间，此外所有网络都走 Google 内网，本质上与 Argo 和 Railgun 类似。所以目前服务动态内容最快的应该还属 Google Cloud CDN 了，Railgun 基本与之相当。

静态内容

CloudFront 自带的 Regional Edge Caches 在缓存静态内容和提高缓存命中率上要比 Argo Tiered Cache 和 Railgun 好，但是 Argo Smart Routing 在服务于动态的不可缓存的内容上更显出优势。Railgun 和 Google Cloud CDN 除了会在边缘节点缓存之外没有其他专门的优化。

关于本站的分区解析

本站的解析没有使用 Cloudflare 而是 自建的 DNS，因为我的 Cloudflare 域名是通过 CNAME 接入的。Cloudflare 分配的 IP 在很长时间内都不会变动，所以我直接把其 IP 设置为了海外线路。使用自建的DNS是为了在备案后，为国内分区解析配置 CDN 线路。 PS: 大家应该都知道启用这个功能后并不会提升国内连接 Cloudflare 的速度，如果想要用 Cloudflare 并且希望国内快一点，源站最好就用美国西岸的。

建立网站、建立软件（或游戏）的服务器等，可能会有很多纠结的地方，也有很多坑，这篇文章根据我个人的经验来帮助大家选择最适合自己的方案，以及一些建议，在最后列出来一些我推荐的服务。

服务的三种类型

一般的，建站所需要购买的服务也是属于这三种服务之间的。从 SaaS、Paas 到 IaaS，依次从使用简便到复杂，从可拓展性低到高。了解这三种服务类型有助于选择合适的服务。

• SaaS，软件即服务：比如 WordPress.com 等提供了一整套服务（包括了域名、主机、平台和软件）的，就算是 SaaS，这种服务对于初学者使用起来最方便，专业人士也能玩出不少花样，但可拓展性受到软件的限制，通常这种服务都有较高的可用性，并且是分布式的。
• PaaS，平台即服务：比如基于 cPanel、Plesk 面板的虚拟主机，你可以在平台上安装已有的开源软件，或者将自己软件代码上传，总体使用几乎和 SaaS 一样简单，使用特定的操作系统和代码语言，安装各种程序。PaaS 有普通的也有分布式的，后者的在可用性和数据保障，以及可拓展性上都要好于前者。
• IaaS，基础设施即服务：包括 VPS、独立服务器、云 VPS 和共有/私有云服务器。VPS 和独立服务器相比主要差距是在配置上，包括 CPU、内存、硬盘等，后者的配置会高很多，可用性方面没有太大区别。云 VPS 和共有/私有云实际上是基于云端分布式的 VPS 和独立服务器，一样的，他们的在可用性和数据保障，以及可拓展性上都要好于 VPS 和独立服务器。IaaS 需要自己选择操作系统，所有的服务和软件都是自己配置，通常都给你 root 权限。

服务的选择

• 位置选择之国内：首先需要考虑的是国内还是国外？如果选择国内，首先你得域名需要经过备案，这可能需要将近一个月时间，这无疑为建网站增加了不少成本。而且国内的服务器普遍较贵。不过如果要选择国内，我比较推荐的主机是新浪的 SAE，它价格很低，是按需付费，并且还有免费额度，它属于分布式的 PaaS，提供高可用率的服务，支持 Docker 容器、DDOS 防御。不过 SAE 对于非企业用户不提供 CDN 和自定义域名 HTTPS，我推荐你使用 UPYUN 来实现 CDN 和自定义域名 HTTPS 功能。国内的优点：可以保证网络延迟低，并能符合目前的一些法律政策。
• 位置选择之国外：不少亚洲的主机（包括但不限于香港、日本、新加坡）从大陆连接会 “绕道”，导致延迟很高，购买前需要先了解清楚，香港便宜的共享主机推荐 TlOxygen。亚洲的主机普遍网络带宽不大，流量比较少，如果不选择亚洲的，那就建议先选北美的。国外的主机通常会有比国内很多主机更低的价格，更好的国际带宽。 如果有条件，可以配置多个服务器，两个服务器推荐的解决方案是亚洲 + 北美东岸，并将亚洲和大洋洲都指向亚洲，其余的都指向北美。如果有条件配置更多服务器，那么可以同时配置北美东岸 + 北美西岸 + 欧洲 + 亚洲的四个服务器并分区解析，就我的实际测试而言，把非洲指向欧洲，把大洋洲指向北美西岸能达到最快的速度。

一些可能需要的特性：基于要实现的不同功能，可能需要在以下方面有要求，在选择服务的时候需要优先考虑。

• 高数据可靠性：几乎所有的网站或是和网络相关的软件，都需要存储用户的数据，所以高数据可靠性是十分重要的。所以磁盘阵列为 RAID1 和 RAID10 是首选。而且用户数据的备份也是十分重要的，可以存储在第三方如 AWS S3。一些服务提供商提供了备份功能，其实也是能够保证高数据可靠性。
• 防御攻击的能力：攻击的成本已经越来越低，种类也很多。通常最难防御的攻击种类是 DDOS，其余的几乎都可以通过软件实现。建议在选择服务器时就要选择有 DDOS 防御的服务器，或者直接使用 CloudFlare 之类的基于第七层的防御。
• 可伸缩，按需付费：最简单的例子就是网络的计费方式不是按照带宽计费，而是按照每 GB 多少钱计费，不限带宽，能够避免不必要的支出的同时还会让用户享受最快的速度。同样的道理，按照系统资源的使用来计费的模式是最好的选择。一般的，基于云端的 PaaS 都是这种计费方式，IaaS 则需要自行配置来实现资源不够时升级配置，资源过剩时回收配置（也可以是 Auto Balancing），所以按小时（或分钟、秒种）级别的计费 IaaS 计费方式最适合这样伸缩以达到按需付费的目的。
• 网络可靠性：网络可靠性也十分重要，如果服务的网络不好，那么将极大的影响用户体验，导致用户不可以使用服务。
• SLA：重要的服务都需要 SLA，SLA 能给你承诺服务的可用率，当服务没有满足承诺时，服务提供商会给你赔偿。
• IPv6：就目前来看，如果不支持 IPv6 也没什么问题。但是能有原生的 IPv6 支持总比没有好，而且现在正在有越来越多的运营商支持 IPv6，使用 IPv6 有可能会有更低的网络延迟，同时配置 IPsec 也有优势。

其他

• 域名相关：不管你是选择使用虚拟主机、VPS 或是独立服务器，通常你还需要自己买一个域名，配置 DNS 解析等等，推荐免费的 DNS 解析有 CloudFlare、Rage4，国内还有 CloudXNS，一些虚拟主机商以及域名注册商也提供免费的解析，但不如前面介绍的那几个（详细关于 DNS 的介绍请见此）。如果选择使用 CloudFlare，那么你还可以在 DNS 后台选择开启 Proxy（CDN），这样能为你的网站缓存并加速（但实际上对于国内来说有可能反而减速），并获得一些基础的 DDOS 防护，并隐藏你的源站 IP 地址。
• 域名注册商的选择：首先，要保证总的域名保有量大；其次，要域名后缀种类齐全；第三，最好能附加免费的企业邮箱和高级的隐私保护；第四，域名注册后要能删除并退款，防止手抖注册错了；第五，价格不能太贵。在我做的 TlOxygen 这个公共域名注册服务上，使用的域名注册商是全球前十大域名注册商；有 500 多种域名后缀，数量超过 GoDaddy；赠送企业邮箱，可以配置无限个转发邮箱，甚至还可以配置子域名邮箱，还支持 DKIM；大多数种类域名删除可以拿到退款；价格比 Godaddy 便宜很多，续费价格没那么坑，基本上是 7 折；域名隐私保护只有 5 元，但功能比很多免费的高级：即使开了域名隐私保护，别人给你发邮件时，会收到表格，还能继续填写表格与你联系。

一些服务商的推荐

排列的顺序只是与添加在这个列表里的时间有关，新添加的会被放在后面。此处添加的服务商全是个人的推荐的，以后还会持续更新。 标注列表：

• (6)：全面支持 IPv6
• (6)：部分支持 IPv6
• (D)：支持免费 DDOS 防御

SaaS

建立网站

• WordPress.com
• Tumblr (6)
• GitHub Pages

CDN

以下 CDN 都支持 HTTPS 与 IPv6

• UPYUN/又拍云 (6)
• CloudFront (6)
• CloudFlare (6、D)

DNS

• Route 53 (6)
• Rage4 (6、D)

数据存储

• AWS S3

代码托管

• GitHub
• GitLab.com
• Coding

SaaS 还有很多，太多的东西都是 SaaS 了，所以这里只能算举几个例子。

PaaS

虚拟主机

• BlueHost

云主机

或者说是分布式的虚拟主机，但是有独立的 CPU 和内存资源。

• ResellerClub
• BlueHost

可自选软件语言的/Docker 容器

• 新浪 SAE (6¹、D)
• OpenShift
• AWS Elastic Beanstalk
• AWS EC2 Container Registry

IaaS

VPS/Cloud

标注列表：

• (U)：独享 CPU³

• (C)：基于云端的技术，高可用性

• (S)：关机后不计费

• Vultr (6、D⁶)

• OVH (6²、D、C⁴)

• Google Compute Engine (D⁵、C、U、S)

• Linode (6)

• DigitalOcean (6)

• AWS EC2 (S)

• QingCloud/青云 (S)

• 腾讯云

备注

1. SAE 的 IPv6 的激活需要额外的月付
2. OVH 的 SSD VPS 暂时不支持 IPv6
3. 在购买某种配置时，若告知你是共享 CPU，那么还是共享 CPU
4. OVH 只有 Cloud VPS 是基于云端的 VPS
5. Google 官方并没有明确说明提供 DDOS 防御，但实际上是有能力防御的
6. Vultr 的 DDOS 防御需要额外购买，且仅部分地区支持，最大防御仅 10Gbps

DNS（域名解析系统）的工作使命，就是服务于与域名相关的内容的底层。是域名（如：example.com）的核心组成部分。绝大多数与域名相关的东西，都离不开它。比如：

• 访问一个网站，通常是输入一个域名（如 https://www.example.com）
• 发送邮件，@ 后面是主机名，而主机名通常是个域名（如 webmaster@example.com）

整个 DNS 具有复杂的层次，这对刚开始购买域名的人有很大的疑惑。本文将详尽的介绍 DNS 的工作原理，有助于更深刻的理解。本文将介绍：

1. 在客户端上是如何解析一个域名的
2. 在 DNS 缓存服务器上是如何逐级解析一个域名的

同时还包含：

1. 域名的分类
2. 什么是 Glue 记录
3. 为什么 CNAME 不能设置在主域名上

先从本地的 DNS 开始讲起。

本地 DNS

本地的 DNS 相对于全球 DNS 要简单的多。所以先从本地 DNS 开始讲起。 127.0.0.1 常被用作环回 IP，也就可以作为本机用来访问自身的 IP 地址。通常，这个 IP 地址都对应着一个域名，叫 localhost。这是一个一级域名（也是顶级域名），所以和 com 同级。系统是如何实现将 localhost 对应到 127.0.0.1 的呢？其实就是通过 DNS。在操作系统中，通常存在一个 hosts 文件，这个文件定义了一组域名到 IP 的映射。常见的 hosts 文件内容如下：

127.0.0.1       localhost::1             localhost

它就定义了 localhost 域名对应 127.0.0.1 这个 IP（第二行是 IPv6 地址）。这样，当你从浏览器里访问这个域名，或者是在终端中执行 Ping 的时候，会自动的查询这个 hosts 文件，就从文件中得到了这个 IP 地址。此外，hosts 文件还可以控制其他域名所对应的 IP 地址，并可以 override 其在全球 DNS 或本地网络 DNS 中的值。但是，hosts 文件只能控制本地的域名解析。hosts 文件出现的时候，还没有 DNS，但它可以说是 DNS 的前身。 如果需要在一个网络中，公用同一个 DNS，那么就需要使用 IP 数据包向某个服务器去获取 DNS 记录。 在一个网络里（此处主要指本地的网络，比如家庭里一个路由器下连接的所有设备和这个路由器组成的网络），会有很多主机。在与这些主机通信的时候，使用域名会更加的方便。通常，连接到同一个路由器的设备会被设置到路由器自己的一个 DNS 服务器上。这样，解析域名就不仅可以从 hosts 去获取，还可以从这个服务器上去获取。从另一个 IP 上去获取 DNS 记录通过 DNS 查询，DNS 查询通常基于 UDP 或者 TCP 这种 IP 数据包，来实现远程的查询。我的个人电脑的网络配置如下，这是在我的电脑连接了路由器之后自动就设置上的：

重点是在路由器和搜索域上。 我的电脑的主机名（也是电脑名）设置的是 ze3kr，这个内容在连接路由器时也被路由器知道了，于是路由器就给我的主机分配了一个域名 ze3kr.local，local 这个一级域名专门供本地使用。在这个网络内所有主机通过访问 ze3kr.local 这个域名时，路由器（10.0.1.1）就会告知这个域名对应的 IP 地址，于是这些主机够获得到我的电脑的 IP 地址。至于搜索域的作用，其实是可以省去输入完整的域名，比如：

$ ping ze3krPING ze3kr.local (10.0.1.201): 56 data bytes64 bytes from 10.0.1.201: icmp_seq=0 ttl=64 time=0.053 ms--- ze3kr.local ping statistics ---1 packets transmitted, 1 packets received, 0.0% packet lossround-trip min/avg/max/stddev = 0.053/0.053/0.053/0.000 ms

当设置了搜索域时，当你去解析 ze3kr 这个一级域名时，便会先尝试去解析 ze3kr.local，当发现 ze3kr.local 存在对应的解析时，便停止进一步解析，直接使用 ze3kr.local 的地址。 现在你已经了解了本地 DNS 的工作方式。DNS 的基本工作方式就是：获取域名对应 IP，然后与这个 IP 进行通信。 当在本地去获取一个完整域名（FQDN）时（执行 getaddrbyhost），通常也是通过路由器自己提供的 DNS 进行解析的。当路由器收到一个完整域名请求且没有缓存时，会继续向下一级缓存 DNS 服务器（例如运营商提供的，或者是组织提供的，如 8.8.8.8）查询，下一级缓存 DNS 服务器也没有缓存时，就会通过全球 DNS 进行查询。具体的查询方式，在 “全球 DNS” 中有所介绍。

总结

在本地，先读取本地缓存查找记录，再读取 Hosts 文件，然后在搜索域中查找域名，最后再向路由器请求 DNS 记录。

全球 DNS

在全球 DNS 中，一个完整域名通常包含多级，比如 example.com. 就是个二级域名， www.example.com. 就是个三级域名。通常我们常见到的域名都是完整的域名。

一级域名被分为以下三个部分：

1. 普通域（gTLD）：通常是三个字节或三个字节以上的域名后缀，或者是 Unicode 字符的后缀。这些域名分配给机构管理。
2. 国家域（ccTLD）：所有两个字节的域名都是国家代码，这些域名分配给国家管理。不少国家域都开放了注册，不过有的国家域仅允许当前国家的人去注册。
3. arpa 域：用于将 IP 地址转换为对应的域名的根域。

我们通常所见到的域名都是普通域和国家域，而 arpa 域用作 IP 到域名的反向解析。 在本地 DNS 中，只存在域名对应 IP 这种映射关系。然而，在全球 DNS 中，有着更多的资源记录种类（RR），不只是域名对应 IP 的关系，下面将分别介绍一些最基本的资源记录种类：

• A 记录：定义了一个 IP 地址。（AAAA 记录则是定义一个 IPv6 地址）（RFC 1035）
• NS 记录：域名服务器记录，说明一个域名下的的授权域名服务器记录。内容必须是一个域名。（RFC 1035）

根域名

先从根域名开始，未命名根也可以作为 . 。你在接下来的部分所看到的很多域名都以 .结尾，以 .结尾的域名是特指的是根域名下的完整域名，然而不以 . 结尾的域名大都也是完整域名，实际使用时域名末尾的 .也常常省略。在本文中，我使用 dig 这一个常用的 DNS 软件来进行查询，我的电脑也已经连接到了互联网。 假设目前这个计算机能与互联网上的 IP 通信，但是完全没有 DNS 服务器。此时你需要知道根 DNS 服务器，以便自己获取某个域名的 IP 地址。根 DNS 服务器列表可以在这里下载到。文件内容如下：

;       This file holds the information on root name servers needed to;       initialize cache of Internet domain name servers;       (e.g. reference this file in the "cache  .  <file>";       configuration file of BIND domain name servers).;;       This file is made available by InterNIC;       under anonymous FTP as;           file                /domain/named.cache;           on server           FTP.INTERNIC.NET;       -OR-                    RS.INTERNIC.NET;;       last update:    October 20, 2016;       related version of root zone:   2016102001;; formerly NS.INTERNIC.NET;.                        3600000      NS    A.ROOT-SERVERS.NET.A.ROOT-SERVERS.NET.      3600000      A     198.41.0.4A.ROOT-SERVERS.NET.      3600000      AAAA  2001:503:ba3e::2:30;; FORMERLY NS1.ISI.EDU;.                        3600000      NS    B.ROOT-SERVERS.NET.B.ROOT-SERVERS.NET.      3600000      A     192.228.79.201B.ROOT-SERVERS.NET.      3600000      AAAA  2001:500:84::b;; FORMERLY C.PSI.NET;.                        3600000      NS    C.ROOT-SERVERS.NET.C.ROOT-SERVERS.NET.      3600000      A     192.33.4.12C.ROOT-SERVERS.NET.      3600000      AAAA  2001:500:2::c;; FORMERLY TERP.UMD.EDU;.                        3600000      NS    D.ROOT-SERVERS.NET.D.ROOT-SERVERS.NET.      3600000      A     199.7.91.13D.ROOT-SERVERS.NET.      3600000      AAAA  2001:500:2d::d;; FORMERLY NS.NASA.GOV;.                        3600000      NS    E.ROOT-SERVERS.NET.E.ROOT-SERVERS.NET.      3600000      A     192.203.230.10E.ROOT-SERVERS.NET.      3600000      AAAA  2001:500:a8::e;; FORMERLY NS.ISC.ORG;.                        3600000      NS    F.ROOT-SERVERS.NET.F.ROOT-SERVERS.NET.      3600000      A     192.5.5.241F.ROOT-SERVERS.NET.      3600000      AAAA  2001:500:2f::f;; FORMERLY NS.NIC.DDN.MIL;.                        3600000      NS    G.ROOT-SERVERS.NET.G.ROOT-SERVERS.NET.      3600000      A     192.112.36.4G.ROOT-SERVERS.NET.      3600000      AAAA  2001:500:12::d0d;; FORMERLY AOS.ARL.ARMY.MIL;.                        3600000      NS    H.ROOT-SERVERS.NET.H.ROOT-SERVERS.NET.      3600000      A     198.97.190.53H.ROOT-SERVERS.NET.      3600000      AAAA  2001:500:1::53;; FORMERLY NIC.NORDU.NET;.                        3600000      NS    I.ROOT-SERVERS.NET.I.ROOT-SERVERS.NET.      3600000      A     192.36.148.17I.ROOT-SERVERS.NET.      3600000      AAAA  2001:7fe::53;; OPERATED BY VERISIGN, INC.;.                        3600000      NS    J.ROOT-SERVERS.NET.J.ROOT-SERVERS.NET.      3600000      A     192.58.128.30J.ROOT-SERVERS.NET.      3600000      AAAA  2001:503:c27::2:30;; OPERATED BY RIPE NCC;.                        3600000      NS    K.ROOT-SERVERS.NET.K.ROOT-SERVERS.NET.      3600000      A     193.0.14.129K.ROOT-SERVERS.NET.      3600000      AAAA  2001:7fd::1;; OPERATED BY ICANN;.                        3600000      NS    L.ROOT-SERVERS.NET.L.ROOT-SERVERS.NET.      3600000      A     199.7.83.42L.ROOT-SERVERS.NET.      3600000      AAAA  2001:500:9f::42;; OPERATED BY WIDE;.                        3600000      NS    M.ROOT-SERVERS.NET.M.ROOT-SERVERS.NET.      3600000      A     202.12.27.33M.ROOT-SERVERS.NET.      3600000      AAAA  2001:dc3::35; End of file

这个文件中每一行分为 4 列，分别是完整域名、资源类型、生存时间（TTL，也就是可以缓存的时间）以及资源数据。通过这个文件就可以知道根域名所对应的 13 个根域名服务器的完整域名，还能知道这 13 个完整域名所对应的 IP 地址。这是因为 NS 记录只能设置为完整域名，所以为了告知 NS 所对应的 IP，还需要额外的数据去说明这 13 个完整域名对应的 IP（这些额外的数据叫做 Glue 记录）。这 13 个根域名服务器都是独立的且冗余的（但是所返回的内容应该是相同的），这样当其中的某个或某些服务器发生故障时，不会影响到解析。一旦无法解析根域名，那么所有的域名都将无法访问。

Glue 记录：如果 NS 记录对应的某个完整域名包含在那个域名之中，那么就需要添加一个 Glue 记录，来指定那个完整域名所对应的 IP。实际上任何完整域名都属于根域名之中，所以根域名就必须对这些 NS 记录设置对应的 IP 地址。Glue 记录实质上就是 A（或 AAAA）记录。（RFC 1033）

我们假设你已经通过某种方法成功获取到了这个文件，那么下一步，就是使用这里的服务器对根域名以及一级域名进行解析。对根域名的解析实际上是不必要的，但是我们还是对其进行解析以便进一步分析，获得在互联网上最新、最全的数据。 在根域名上的记录，以从根域名服务器中所解析其根域名的数据为准，而不是刚才的那个文件中的内容。刚才的文件内容只是告知根域名服务器的列表，也就是只有 NS 记录和 NS 记录对应的完整域名的 IP 记录，而不是根域名下的所有记录。 我们先向 198.41.0.4 这个 IP 发送查询根域名的所有记录，any 代表显示任何类型的记录，为了看起来方便，一些无关的响应已经删除（如果只是解析根域名，这一步不能跳过。如果需要直接解析一级域名，那么这一步就可以跳过）。

$ dig @198.41.0.4 . any;; QUESTION SECTION:;.INANY;; ANSWER SECTION:.518400INNSa.root-servers.net..518400INNSb.root-servers.net..518400INNSc.root-servers.net..518400INNSd.root-servers.net..518400INNSe.root-servers.net..518400INNSf.root-servers.net..518400INNSg.root-servers.net..518400INNSh.root-servers.net..518400INNSi.root-servers.net..518400INNSj.root-servers.net..518400INNSk.root-servers.net..518400INNSl.root-servers.net..518400INNSm.root-servers.net..86400INSOAa.root-servers.net. nstld.verisign-grs.com. 2016122400 1800 900 604800 86400;; ADDITIONAL SECTION:a.root-servers.net.518400INA198.41.0.4b.root-servers.net.518400INA192.228.79.201c.root-servers.net.518400INA192.33.4.12d.root-servers.net.518400INA199.7.91.13e.root-servers.net.518400INA192.203.230.10f.root-servers.net.518400INA192.5.5.241g.root-servers.net.518400INA192.112.36.4h.root-servers.net.518400INA198.97.190.53i.root-servers.net.518400INA192.36.148.17j.root-servers.net.518400INA192.58.128.30k.root-servers.net.518400INA193.0.14.129l.root-servers.net.518400INA199.7.83.42m.root-servers.net.518400INA202.12.27.33a.root-servers.net.518400INAAAA2001:503:ba3e::2:30b.root-servers.net.518400INAAAA2001:500:84::bc.root-servers.net.518400INAAAA2001:500:2::cd.root-servers.net.518400INAAAA2001:500:2d::de.root-servers.net.518400INAAAA2001:500:a8::ef.root-servers.net.518400INAAAA2001:500:2f::fg.root-servers.net.518400INAAAA2001:500:12::d0dh.root-servers.net.518400INAAAA2001:500:1::53i.root-servers.net.518400INAAAA2001:7fe::53j.root-servers.net.518400INAAAA2001:503:c27::2:30k.root-servers.net.518400INAAAA2001:7fd::1l.root-servers.net.518400INAAAA2001:500:9f::42m.root-servers.net.518400INAAAA2001:dc3::35

其中，可以看到 TTL 与刚才文件中的内容不一样，此外还多了一个 SOA 记录，所以实际上是以这里的结果为准。这里还有一个 SOA 记录，SOA 记录是普遍存在的，具体请参考文档，在这里不做过多说明。

SOA 记录：指定有关 _DNS 区域_的权威性信息，包含主要名称服务器、域名管理员的电邮地址、域名的流水式编号、和几个有关刷新区域的定时器。（RFC 1035）

_DNS 区域_：对于根域名来说，DNS 区域就是空的，也就是说它负责这互联网下所有的域名。而对于我的网站，DNS 区域就是 guozeyu.com.，管理着 guozeyu.com. 本身及其子域名的记录。

此处的 ADDITIONAL SECTION 其实就包含了 Glue 记录。

一级域名

根域名自身的 DNS 服务器服务器除了被用于解析根自身之外，还用于解析所有在互联网上的一级域名。你会发现，几乎所有的 DNS 服务器，无论是否是根 DNS 服务器，都会解析其自身以及其下级域名。 从之前的解析结果中可以看出，根域名没有指定到任何 IP 地址，但是却给出了 NS 记录，于是我们就需要用这些 NS 记录来解析其下级的一级域名。下面，用所得到的根 NS 记录中的服务器其中之一来解析一个一级域名 com.。

$ dig @198.41.0.4 com any;; QUESTION SECTION:;com.INANY;; AUTHORITY SECTION:com.172800INNSa.gtld-servers.net.com.172800INNSb.gtld-servers.net.com.172800INNSc.gtld-servers.net.com.172800INNSd.gtld-servers.net.com.172800INNSe.gtld-servers.net.com.172800INNSf.gtld-servers.net.com.172800INNSg.gtld-servers.net.com.172800INNSh.gtld-servers.net.com.172800INNSi.gtld-servers.net.com.172800INNSj.gtld-servers.net.com.172800INNSk.gtld-servers.net.com.172800INNSl.gtld-servers.net.com.172800INNSm.gtld-servers.net.;; ADDITIONAL SECTION:a.gtld-servers.net.172800INA192.5.6.30b.gtld-servers.net.172800INA192.33.14.30c.gtld-servers.net.172800INA192.26.92.30d.gtld-servers.net.172800INA192.31.80.30e.gtld-servers.net.172800INA192.12.94.30f.gtld-servers.net.172800INA192.35.51.30g.gtld-servers.net.172800INA192.42.93.30h.gtld-servers.net.172800INA192.54.112.30i.gtld-servers.net.172800INA192.43.172.30j.gtld-servers.net.172800INA192.48.79.30k.gtld-servers.net.172800INA192.52.178.30l.gtld-servers.net.172800INA192.41.162.30m.gtld-servers.net.172800INA192.55.83.30a.gtld-servers.net.172800INAAAA2001:503:a83e::2:30b.gtld-servers.net.172800INAAAA2001:503:231d::2:30

可以看到解析的结果和解析根域名的类似，com. 下也设置了 13 个域名服务器，但是这 13 个域名服务器与根域服务器完全不同。

此处也存在 ADDITIONAL SECTION 包含的 Glue 记录，然而 gtld-servers.net. 却并不包含在 com. 下。然而实际上，com. 和 net. 域名都是属于同一个所有者（Verisign），所以这样设置是可以的。

和根域名类似，此时解析到的内容只是 com. 的域名服务器，而并不是 com. 本身的记录，在 com. 上的记录，以从 com. 的域名服务器中所解析其 com. 域名的数据为准。 所以，下面再使用 com. 的域名服务器来解析 com. 自身，看情况如何（如果只是解析一级域名，这一步不能跳过。如果需要直接解析二级域名，那么这一步就可以跳过）：

$ dig @192.5.6.30 com any;; QUESTION SECTION:;com.INANY;; ANSWER SECTION:com.900INSOAa.gtld-servers.net. nstld.verisign-grs.com. 1482571852 1800 900 604800 86400com.172800INNSe.gtld-servers.net.com.172800INNSm.gtld-servers.net.com.172800INNSi.gtld-servers.net.com.172800INNSk.gtld-servers.net.com.172800INNSb.gtld-servers.net.com.172800INNSj.gtld-servers.net.com.172800INNSa.gtld-servers.net.com.172800INNSd.gtld-servers.net.com.172800INNSg.gtld-servers.net.com.172800INNSc.gtld-servers.net.com.172800INNSh.gtld-servers.net.com.172800INNSf.gtld-servers.net.com.172800INNSl.gtld-servers.net.;; ADDITIONAL SECTION:e.gtld-servers.net.172800INA192.12.94.30m.gtld-servers.net.172800INA192.55.83.30i.gtld-servers.net.172800INA192.43.172.30k.gtld-servers.net.172800INA192.52.178.30b.gtld-servers.net.172800INA192.33.14.30b.gtld-servers.net.172800INAAAA2001:503:231d::2:30j.gtld-servers.net.172800INA192.48.79.30a.gtld-servers.net.172800INA192.5.6.30a.gtld-servers.net.172800INAAAA2001:503:a83e::2:30d.gtld-servers.net.172800INA192.31.80.30g.gtld-servers.net.172800INA192.42.93.30c.gtld-servers.net.172800INA192.26.92.30h.gtld-servers.net.172800INA192.54.112.30f.gtld-servers.net.172800INA192.35.51.30l.gtld-servers.net.172800INA192.41.162.30

也和根域名解析的情况类似，此时多了一个 SOA 类型的记录。

二级域名

和解析一级域名 com. 时类似，继续使用 com. 的域名服务器解析 guozeyu.com.。

$ dig @192.5.6.30 guozeyu.com any;; QUESTION SECTION:;guozeyu.com.INANY;; AUTHORITY SECTION:guozeyu.com.172800INNSa.ns.guozeyu.com.guozeyu.com.172800INNSb.ns.guozeyu.com.guozeyu.com.172800INNSc.ns.guozeyu.com.;; ADDITIONAL SECTION:a.ns.guozeyu.com.172800INAAAA2001:4860:4802:38::6ca.ns.guozeyu.com.172800INA216.239.38.108b.ns.guozeyu.com.172800INAAAA2001:4860:4802:36::6cb.ns.guozeyu.com.172800INA216.239.36.108c.ns.guozeyu.com.172800INAAAA2001:4860:4802:34::6cc.ns.guozeyu.com.172800INA216.239.34.108

此处也存在 ADDITIONAL SECTION 包含的 Glue 记录，是因为 ns.guozeyu.com. 在 guozeyu.com. 之下。 同样的，在 guozeyu.com. 上的记录，以从 guozeyu.com. 的域名服务器中所解析其 guozeyu.com. 域名的数据为准。此时这种解析就尤为必要了，因为 guozeyu.com. 上不只有 SOA 记录，同时也有 A 记录和其他重要的记录。 现在使用 guozeyu.com. 的域名服务器来解析 guozeyu.com.（如果只是解析二级域名，这一步不能跳过。如果需要解析三级域名，那么这一步可以跳过）：

$ dig @216.239.38.108 guozeyu.com any;; QUESTION SECTION:;guozeyu.com.INANY;; ANSWER SECTION:guozeyu.com.21600INA104.199.138.99guozeyu.com.172800INNSa.ns.guozeyu.com.guozeyu.com.172800INNSb.ns.guozeyu.com.guozeyu.com.172800INNSc.ns.guozeyu.com.guozeyu.com.21600INSOAa.ns.guozeyu.com. support.tlo.xyz. 1 21600 3600 259200 300guozeyu.com.172800INMX100 us2.mx1.mailhostbox.com.guozeyu.com.172800INMX100 us2.mx2.mailhostbox.com.guozeyu.com.172800INMX100 us2.mx3.mailhostbox.com.;; ADDITIONAL SECTION:a.ns.guozeyu.com.604800INA216.239.38.108a.ns.guozeyu.com.604800INAAAA2001:4860:4802:38::6cb.ns.guozeyu.com.604800INA216.239.36.108b.ns.guozeyu.com.604800INAAAA2001:4860:4802:36::6cc.ns.guozeyu.com.604800INA216.239.34.108c.ns.guozeyu.com.604800INAAAA2001:4860:4802:34::6c

可以发现增加了 A、SOA 和 MX 记录。

• MX 记录：邮件交换记录，让发送到一个域名的邮件由其他的主机去接受，用于与 A 记录共存。（RFC 1035）

正是因为 MX 记录的存在，所以发往 username@guozeyu.com 的邮件不是指向 guozeyu.com. 对应的 IP 地址，而是使用 mailhostbox.com. 下的服务器。 当然，由于我是 guozeyu.com. 的所有者，所以我也可以控制 guozeyu.com. 下的三级或更高级的域名。比如 www.guozeyu.com.：

$ dig @216.239.38.108 www.guozeyu.com any;; QUESTION SECTION:;guozeyu.com.INANY;; ANSWER SECTION:www.guozeyu.com.172800INCNAMEguozeyu.com.guozeyu.com.21600INA104.199.138.99guozeyu.com.172800INNSa.ns.guozeyu.com.guozeyu.com.172800INNSb.ns.guozeyu.com.guozeyu.com.172800INNSc.ns.guozeyu.com.guozeyu.com.21600INSOAa.ns.guozeyu.com. support.tlo.xyz. 1 21600 3600 259200 300guozeyu.com.172800INMX100 us2.mx1.mailhostbox.com.guozeyu.com.172800INMX100 us2.mx2.mailhostbox.com.guozeyu.com.172800INMX100 us2.mx3.mailhostbox.com.;; ADDITIONAL SECTION:a.ns.guozeyu.com.604800INA216.239.38.108a.ns.guozeyu.com.604800INAAAA2001:4860:4802:38::6cb.ns.guozeyu.com.604800INA216.239.36.108b.ns.guozeyu.com.604800INAAAA2001:4860:4802:36::6cc.ns.guozeyu.com.604800INA216.239.34.108c.ns.guozeyu.com.604800INAAAA2001:4860:4802:34::6c

• CNAME 记录：规范名称记录，一个主机名字的别名。内容必须是一个域名。（RFC 1035）

我的三级域名 www.guozeyu.com. 使用 CNAME 记录指向了 guozeyu.com.，这代表着 guozeyu.com. 下所有资源类型均与 guozeyu.com. 相同。这也是为什么 CNAME 不能和其他任何记录连用的原因，CNAME 的存在会取代任何其他的记录。由于主域名下常常也存在 SOA、NS 以及 MX 记录，所以主域名下不能使用 CNAME 解析。此外，我也可以设置在 guozeyu.com. 下的三级域名指向一个 NS 记录，这样我就可以把我的三级域名再给别人使用。

总结

1. 如果需要解析一个根域名，使用根域名服务器解析根域名即可。
2. 如果需要解析一个一级域名，需要先使用根域名服务器解析一级域名，获取到一级域名的域名服务器，然后用一级域名服务器解析一级域名自身。
3. 如果需要解析一个二级域名，需要先使用根域名服务器解析一级域名，获取到一级域名的域名服务器，然后用一级域名服务器获取二级域名的域名服务器，然后用二级域名服务器解析二级域名自身。
4. 如果需要解析一个三级域名，需要先使用根域名服务器解析一级域名，获取到一级域名的域名服务器，然后用一级域名服务器获取二级域名的域名服务器，然后用二级域名服务器解析三级域名，若三级域名下没有 NS、CNAME 记录，则解析结束，如果有 CNAME 记录则再通过正常的解析方式解析这个 CNAME 所指向的域名的记录，如果有 NS 记录，则用三级域名服务器解析三级域名自身。

DNS 缓存

通常，凡是解析过的记录，都会被解析服务器、路由器、客户端、软件缓存。这样可以大大减少请求次数。凡是被缓存的记录，其在 TTL 规定的时间内都不会再次去解析，而是直接从高速缓存中读取。正常情况下，服务器、路由器等都不应该扩大 TTL 值。被缓存的内容，TTL 值要在每秒减 1 。

$ dig guozeyu.com;; QUESTION SECTION:;guozeyu.com.INA;; ANSWER SECTION:guozeyu.com.21599INA104.199.138.99;; Query time: 514 msec;; SERVER: 10.0.1.1#53(10.0.1.1);; WHEN: Sat Dec 24 20:00:29 2016;; MSG SIZE  rcvd: 43$ dig guozeyu.com;; QUESTION SECTION:;guozeyu.com.INA;; ANSWER SECTION:guozeyu.com.21598INA104.199.138.99;; Query time: 45 msec;; SERVER: 10.0.1.1#53(10.0.1.1);; WHEN: Sat Dec 24 20:00:30 2016

这是我连续两次在我的电脑上直接通过路由器解析 guozeyu.com. 的结果。显然第一次解析没有命中高速缓存，路由器向运营商的 DNS 服务器查询，运营商的 DNS 再从根域名逐级解析 guozeyu.com.，总耗时 514 毫秒。然后 guozeyu.com. 就会同时在运营商的服务器上和路由器的 DNS 服务器上进行缓存。在第二次请求 guozeyu.com. 时，就命中了在路由器上的缓存，于是由路由器直接返回解析记录，总耗时 45 毫秒。两次查询时间相隔一秒，所以 TTL 值也被减去 1 。

arpa 反向解析

反向解析用于：给定一个 IP 地址，返回与该地址对应的域名。函数 gethostbyaddr 正是使用了这种方法获取 IP 对应的域名。 一级域名 arpa. 用于设置反向解析，对于我的网站的 IPv4 地址 104.199.138.99，其所对应的 arpa 完整域名是：99.138.199.104.in-addr.arpa.，通过获取这个域名的 PTR 记录，就可以得到这个域名所对应的完整域名域名。

$ host 104.199.138.9999.138.199.104.in-addr.arpa domain name pointer 99.138.199.104.bc.googleusercontent.com.$ dig 99.138.199.104.in-addr.arpa. ptr +short99.138.199.104.bc.googleusercontent.com.

• PTR 记录：指针解析记录，内容是一个完整域名，定义一个 IP 所对应的域名。

可以看到，使用 host 命令获得 IP 地址的域名与使用 dig 获取的相同，均为 99.138.199.104.bc.googleusercontent.com. 。可以看出，这个 IP 是属于 Google 的。此外，需要注意的是 in-addr.arpa. 下的字域名正好与原 IPv4 地址排列相反。 这个记录通常可以由 IP 的所有者进行设置。然而，IP 的所有者可以将这项记录设置为任何域名，包括别人的域名。所以通过这种方法所判断其属于 Google 并不准确，所以，我们还需要对其验证：

$ dig 99.138.199.104.bc.googleusercontent.com a +short104.199.138.99

可以看到，这个域名又被解析到了原本的 IP，此时验证完毕，确认了这个 IP 属于 Google。所以，通过 gethostbyaddr 之后，还要继续 getaddrbyhost 验证。 然而，进行这种解析时解析服务器是由谁提供的呢？我们来看看 99.138.199.104.in-addr.arpa. 的上一级域名的解析记录：

$ dig 138.199.104.in-addr.arpa. any;; QUESTION SECTION:;138.199.104.in-addr.arpa.INANY;; ANSWER SECTION:138.199.104.in-addr.arpa. 21583INNSns-gce-public1.googledomains.com.138.199.104.in-addr.arpa. 21583INNSns-gce-public2.googledomains.com.138.199.104.in-addr.arpa. 21583INNSns-gce-public3.googledomains.com.138.199.104.in-addr.arpa. 21583INNSns-gce-public4.googledomains.com.138.199.104.in-addr.arpa. 21583INSOAns-gce-public1.googledomains.com. cloud-dns-hostmaster.google.com. 1 21600 3600 259200 300

可以看到，上一级 138.199.104.in-addr.arpa. 下配置了 Google 的域名服务器，所以 104.199.138.0/24（104.196.123.0 - 104.196.123.255）都是属于 Google 的。然而，既然这个域名下的域名服务器可以设置为 Google 自己的，所以这个域名下就可以设置任何记录，不只是 PTR，所以也可以添加 A 记录把 arpa 域名当作网站！ 我虽然没有那么大块的 IPv4 地址，但是我有这个 IPv6 地址：2001:470:f913::/48 并且能够设置在 arpa. 下的 NS 记录。这个 /48 的 IPv6 地址对应着 arpa. 反向解析的完整域名是 3.1.9.f.0.7.4.0.1.0.0.2.ip6.arpa. ，可以看到 IPv6 的反向解析在另一个二级域名 ip6.arpa. 下，此外其地址是将 IPv6 的每一个十六进制为拆开为一个字域并反向排列的。 我已把这个地址设置为了我自己可以控制的 NS，然后配置了 A 记录，瞬间这个反向解析域名就可以当作正常的解析使用了！

• 3.1.9.f.0.7.4.0.1.0.0.2.ip6.arpa
• ze3kr.3.1.9.f.0.7.4.0.1.0.0.2.ip6.arpa

如果你试图用浏览器访问这两个域名，会收到证书错误的报告，因为我还没给这个域名签发证书。

在上一篇文章中，我简单的介绍了 Google Compute Engine（简称 GCE）的基础使用。这篇文章我将介绍如何利用 GCE 建立一个 Anycast 网络，并测试了其速度。 想要实现这个功能，就需要使用 Cross-Region Load Balancing（跨地区的负载均衡），此功能就相当于一个 HTTP(S) 的反向代理，所以只能针对 HTTP/HTTPS 请求进行负载均衡。

简要概述

GCE 上所实现的这个功能是基于第七层的网络代理，所以其拓扑图是这样的： 用户 —> 边缘服务器 —> 实例

• 用户到边缘服务器之间的连接：使用 HTTP 或 HTTPS；如果是 HTTPS 连接，那么 TLS 加密过程是在边缘服务器上实现。
• 边缘服务器到实例的连接：使用 HTTP 或 HTTPS 连接，之前的网络是走的 Google 的专线。

不论配置了几个位置的实例，边缘服务器都是使用 Google 全部的边缘服务器。 启用这个功能后，就会得到另一个 Anycast 的 IP 地址，这是个独享的 IP 地址。

什么是 Anycast？Anycast 能够让多个主机使用一个 IP 地址，当用户连接这个 IP 地址的时候，连接到的只是这多个主机中的其中之一，通常会选择最快的线路，能有效的降低延迟，所以很多 DNS/CDN 提供商都使用了 Anycast。

此外，目前使用负载均衡是唯一能让其原生支持 IPv6 的方法。具体可以参见其文档：IPv6 Termination for HTTP(S), SSL Proxy, and TCP Proxy Load Balancing

配置方法

建立实例

首先，需要前往到 GCE 后台，建立至少两个不同地区的实例，我专门为测试 Anycast 功能建立了两个新的实例：

每个地区也可以建立多个实例以提高可用性，而我只给每个地区建立了一个实例，这两个实例分别叫 anycast-asia 和 anycast-us。

建立实例组

然后，需要给每个地区的实例建立一个实例组：

需要注意的是，实例组配置页面中位置里的 “多地区（Multi-zone）” 是指同一个地区（Region）的不同可用区域（Zone），而不是多个不同的地区，所以这实际上是翻译的错误，应该叫做 “多可用区域” 才对。

刚接触云服务的人可能不理解可用区域的概念，可以参考 AWS 的这篇文章来理解。简单点说，地区这个概念就是指离得很远的地区（比如城市之间，如北京和上海），所有在北京的服务器都算北京地区，所有在上海的服务器都算上海地区。但是为了能达到更高的可用性，通常还会在同一个地区设立多个数据中心，也就是可用区域。这些可用区域虽在一个地区中，其之间的距离可能相隔几十甚至几百公里，但这些可用区域之间的距离和不同地区之间的距离相比起来要小得多，所以这些可用区域之间的网络延迟也很低。

设立多个可用区域的意义是：可以能加更高的可用性（主要是为了避免外界因素：比如说火灾等），虽然是异地分布，但是可用区域之间的距离并不远，所以网络延迟可以忽略。

我只给每个地区建立了一个实例，所以我只需要选择 “单地区（Single-zone）”。每个地区都需要建立一个实例组，所以一共需要建立两个（或更多的）实例组。我配置了两个实例组，分别叫 asia-group 和 us-group。

建立负载均衡

完成前两步之后，就需要建立负载均衡的规则了，需要选择 “HTTP(S) 负载平衡” 来实现 Anycast 的功能。

在负载均衡的配置界面，把这两个实例组都添加到 “后端” 中。 该功能还需要创建一个运行状态检查（相当于监控功能），当主机宕机后能实现切换。

创建成功后，可以看到如下界面，其中的 IP 地址就是 Anycast IP 了。

Nginx 的配置

这里的配置只是为了方便调试，实际使用不用额外修改 Nginx 的配置。 在这两个主机上都安装 Nginx，然后稍微改动默认的配置文件：增加两个 Header，然后 Reload。

add_header X-Tlo-Hostname $hostname always;add_header Cache-Control "max-age=36000, public";

检测是否可用

在测试 Anycast 之前，先测试这两个主机是否存在问题。为了方便阅读，我将 curl 的 IP 地址换为主机名，并省略两个主机都相同的 Header 字段

$ curl anycast-us -IHTTP/1.1 200 OK…ETag: "57ef2cb9-264"X-Tlo-Hostname: **anycast-us**$ curl anycast-asia -IHTTP/1.1 200 OK…ETag: "57ef2b3b-264"X-Tlo-Hostname: anycast-asia

可以看到这两个主机都没有什么问题。然后，我用我的电脑去测试那个 Anycast IP：

$ curl anycast-ip -IHTTP/1.1 200 OK…ETag: "57ef2b3b-264"X-Tlo-Hostname: anycast-asiaAccept-Ranges: bytesVia: 1.1 google

可以看到，这是 anycast-asia 主机响应的。现在我使用另一个在美国的主机继续测试这个 Anycast IP：

$ curl anycast-ip -IHTTP/1.1 200 OK…ETag: "57ef2cb9-264"X-Tlo-Hostname: anycast-usAccept-Ranges: bytesVia: 1.1 google

此时就是 anycast-us 主机响应的，是因为客户端离这个服务器更近。 当通过 Anycast IP 访问时，就可以看到 HTTP Header 中的 Via: 1.1 google 字段。

速度测试

Ping 测试

Ping 测试发现速度很快，看来反代的操作是放在 Google 的边缘服务器上了。速度堪比 Google 啊！

中国的速度那更是一流的快，Google 有香港的边缘节点，所以基本上是直接走的香港节点，比原本的连接台湾可用区快不少。（只有部分 IP 段是完全直连的）

HTTP GET 测试

在开启 CDN 功能之前，负载均衡器是不会对任何内容缓存的，所以会发现 Connect 的速度很快，但是 TTFB 延迟还是有不少。

可以预测，如果启用了 HTTPS 功能，其 TLS 所需要的等待时间也会很短，TTFB 时间不变，总时长不会延长太多。

开启 CDN 后进行 HTTP GET 测试

当将 CDN 开启后，负载均衡器就会自动地对静态资源做缓存了，当缓存命中后会显示 Age 字段，这个字段是表示自缓存命中了，后面的数字代表这是多少秒之前缓存的内容。

curl anycast-ip -I
HTTP/1.1 200 OK
…
Via: 1.1 google
Age: 10

经过多次执行这个指令，会发现有一定几率 Age 字段消失，这可能是流量指到了同一个地区的不同可用区上。但总之，是缓存命中率不高，即使之前曾访问过了。

多次运行测试确保有缓存之后，发现速度似乎并没有太多明显的提升。能够明显的看出改善的是：巴黎和阿姆斯特丹的 TTFB 延迟从 200ms 减少到了 100ms，然而还是不尽人意。可能的原因是：Google 并没有将内容缓存到离访客最近的边缘节点上，而是别的节点上。 CDN 缓存服务器的位置列表

统计与日志

开启了 Load Balancing 后，就会自动在 Google Cloud Platform 下记录一些信息了。

实时流量查看

在网页后台的 Network，Load balancing，advanced menu 的 Backend service 下，可以查看实时的流量情况：

延迟日志

在网页后台的 Stackdriver，Trace 下，可以看到延迟日志：

这里的延迟包含了网络延迟和服务器响应延迟

总结

GCE 所能实现的 Anycast 功能，只能通过 HTTP 代理（第七层）的方式实现，所以只能代理 HTTP 请求，其他功能（如 DNS）无法实现。所以很多功能受限于负载均衡器的功能（比如证书和 HTTP2 都需要在负载均衡器上配置），然而由于 TLS 加解密过程是在边缘服务器上实现，而且其本身也带有 CDN 功能，所以会比单纯的 Anycast（比如基于 IP 层，或是 TCP/UDP 层）的更快一些。

价格

前五个 Rules $18/月，流量费用相比 GCE 不变，已经被缓存的内容的流量有一点优惠。

对比

Cloudflare

通过使用 Cloudflare 所提供的服务也能实现 Anycast，也是基于第七层的，即将也能实现 Cross-Region Load Balancing 的功能。虽然它还不能根据主机的 CPU 占用率去调整权重（毕竟它拿不到这些数据），却有强大的 Page Rules 功能以及 WAF 功能。 CloudFlare 并不提供独立 IP 地址，不过这不是什么大问题。 由于它属于第三方服务，不受服务提供商的限制，于是就可以给多种不同的服务提供商去做 Anycast 功能；而且无论服务商是否支持，都能够使用。 连接速度上，GCE 的在中国连接速度有明显的优势。

BuyVM

BuyVM 是一家 VPS 提供商，却提供免费的 Anycast 功能，其 Anycast 功能是直接基于 IP 层的 Anycast，所以可以配置 HTTP 之外的各种服务。BuyVM 没有所谓的边缘服务器一说，只能有三个节点，Ping 的结果不像前两家那么快，而且 TLS 过程也是在原本的主机（这三个主机中里用户最近的一个）上进行，也会有一定延迟。 BuyVM 并不提供任何亚洲的主机，所以中国的连接速度也没有比 Cloudflare 快多少，整个亚洲的速度也不是很快。

2017 年 4 月更新：由于 GCE 在国内经常不稳定，本站主机已经换到了 TlOxygen 的虚拟主机上了。 最近想要寻找按流量计费、连接中国速度比较快的 VPS，最终选择了 Google Compute Engine（下文简称 GCE）的亚洲区。GCE 的后台配置页面虽不能在中国访问，但是其 GCE 实例是可以在中国访问的。 创建一个新的 GCE 的流程十分简单，只需要自定义配置、选择操作系统、配置 SSH Key，然后选择创建就好了，整个流程十分像 VPS，但是可自定义的功能却远比 VPS 多。

价格与配置

具体价格请参见官方价格表。（由于有持续使用折扣，每月实际价格比按照每小时更低） GCE 的价格比较亲民，最低配 (f1-micro) 1 共享核-0.6 GB 内存-10GB HDD 每月只需要不到 5 美元，而且由于 CPU、内存大小和磁盘大小都是可调的，所以可以根据自己的需要去购买最适合的，能省去不必要的开销。 而且对于北美的部分机房而言，账户首个最低配 (f1-micro) 实例可以享受到永久免费配额，对于建站而言 (再配合 Cloudflare 使用) 还是很划算的。流量的话对于所有的可用区，连中国大陆 $0.23/Gbyte、美欧地区 $0.12/Gbyte，流量的价格有些小贵，但是如果是连接 Google 自己的服务的话（包括但不限于 Gmail、YouTube），流量不计费（但是流量是双向的，所以是本地通过 GCE 上传完全免费，下载还是原价）。 GCE 还有一点比较特殊的是它是按分钟计费的，当服务处于终止状态（相当于关机，磁盘数据保留）时，不收取费用（除了少量的磁盘使用费用）。每次计算 Uptime 时，如果不到 10 分钟则一律按十分钟算，超过 10 分钟后才是真正的按分钟计费，不过还是很划算了。

关于共享核的实例的补充

f1-micro（0.6 GB）和 g1-small（1.7GB）这两个版本使用的是共享核心（其余配置都是独立核心），根据 Google 的说明，0.60GB 是 0.2 vCPU，1.70GB 是 0.5 vCPU。但是却支持 Bursting，也就是短时间内最高能使用到 1.0 vCPU。 那么 1.0 vCPU 是多少呢？查 cpuinfo，是 Intel(R) Xeon(R) CPU @ 2.50GHz。也就是说这两个版本最高能占用到 2.5GHz。但是假如长时间占用，速度就会压缩到 0.5GHz 和 1.75 GHz。

我的 f1-micro 装了监控软件，对比 GCE 给的 CPU 占用率（深蓝色）和系统自己监控到的占用率（浅蓝色），发现 GCE 图表上统计的 CPU 占用率正好是本地统计的 5 倍，也就是说如果本地看到的 CPU 占用是 20%，GCE 图表上显示的就正好是 100%，本地为 20100%，GCE 图表上就是 100500%，这时就算作 Bursting 了。 和其他 VPS 对比，其他的 VPS 也几乎都是共享核心，但你却无从判断是否超售。比如有 10 个用户共用一个核心，如果那 10 个人都在不停的占用 CPU，那么你的 CPU 速度会低于单核的十分之一。而 Google 的共享核心，保证了一个最低的速度（0.2 vCPU 和 0.5 vCPU），就算其他用户用的再狠，也能给你保证一定的速度。

使用流程以及配置方法

首先需要前往创建实例的页面，然后进行配置

基础配置

其他一些选项配置介绍

• “抢占”：该模式能够获得更低廉的价格，但是不能用做需要长期保持在线的服务（比如 Web 服务），它最长的使用期限是 24 小时，然而在我的使用中，它有时候不到 1 小时就会被终止使用。它只适合短时间去计算一些东西，计算完后中止它，平常的一般使用不要开启此功能。
• 自动重启：推荐开启，以获得在云端的好处，以及更好的 Uptime
• 主机维护期间：推荐选择 “迁移”，原因同上
• IP 转发：建议关闭，几乎不会用得着此功能，关闭有助于提高安全性
• SSH：这可能不同于其他一些 VPS，它默认不自动生成用户密码，所以为了远程登录必须配置好公钥私钥。而且所填写的公钥末尾的用户名是有作用的，所填写的用户名就是所需要登录的用户名，默认不支持 root 登陆，除非你将用户名设置成了 root。

防火墙配置

GCE 默认开启了防火墙且不能关闭，只能允许你自己指定的协议和端口的流量；经过我自己的实际测试，GCE 能够自动过滤相当的 DDOS 攻击流量。 由于防火墙不能关闭，所以不能配置类似 IPv6 Tunnel 的服务，所以导致目前的 GCE 是不能够支持 IPv6 的，不过相信以后 Google 还是会启用 IPv6 支持。 在 “网络” 里，可以找到防火墙规则，然后可以添加防火墙规则。 默认已经允许了 SSH 和 ICMP 等（以 default 开头的）

我只需要另一个主机去访问 SNMP 监控，不需要将其公开到互联网上，所以限制了 IP。

有的 DNS 请求是通过 TCP 发送的，所以需要同样启用 TCP 请求。 如果配置了目标标记，那么就不是默认应用到所有实例的防火墙规则，还需要在实例上配置好同样的标记才可以。

网络——如同 Google 自身一样棒

由于 GCE 是 Google 的，其网络其实也是 Google 的 AS15169，于是不用想也知道连接 Google 旗下的服务会很快，但是实际使用后发现远比我想象的快，GCE 连接 Google 的服务简直就像内网一样。

$ ping google.comPING google.com (74.125.203.102) 56(84) bytes of data.64 bytes from th-in-f102.1e100.net (74.125.203.102): icmp_seq=1 ttl=53 time=0.631 ms64 bytes from th-in-f102.1e100.net (74.125.203.102): icmp_seq=2 ttl=53 time=0.433 ms64 bytes from th-in-f102.1e100.net (74.125.203.102): icmp_seq=3 ttl=53 time=0.330 ms64 bytes from th-in-f102.1e100.net (74.125.203.102): icmp_seq=4 ttl=53 time=0.378 ms64 bytes from th-in-f102.1e100.net (74.125.203.102): icmp_seq=5 ttl=53 time=0.413 ms^C--- google.com ping statistics ---5 packets transmitted, 5 received, 0% packet loss, time 3999msrtt min/avg/max/mdev = 0.330/0.437/0.631/0.103 ms

要是 traceroute 的话就更神奇了：

$ traceroute google.comtraceroute to google.com (64.233.189.113), 64 hops max  1   64.233.189.113  0.826ms  0.313ms  0.435ms

中国目前连接 GCE 亚洲区的速度还算不错，按流量计费，实际测试能够超过 100M 带宽。亚洲区的位置在台湾，中国连接通常会绕香港，然后从香港到台湾这条路线走的是 Google 自己的骨干网，所以最终的结果只是比香港服务器慢了十几毫秒而已。

其他国家连接的话优势就更明显了，Google 的网络实在太强大，无论是亚洲还是欧美，几乎还没有出这个城市/国家就立即跳进 Google 的骨干网络里了，然后 Google 自身的骨干网的选路通常要比运营商的选路要好一些，几乎不会出现绕路的情况。

配置 Anycast

详细内容已在下一篇文章中介绍，通过 Load Balancing 可以分配到一个独立的 IPv4 地址，还能够有原生的 IPv6，支持 CDN 和 HTTPS。Google 的 Anycast 有多快？和 Google 一样快。

内部网络互通

每个实例都有其对应的内网 IP，方便两个主机间建立直接的连接，这个内网 IP 的神奇之处在于：它可以跨可用区使用，包括跨大洲。经过实际测试，使用内网 IP 建立的连接速度会稍快，而且收取的价格（如果是跨州的话）也有优惠。

功能

统计功能

在 GCE 的后台，能够显示长达 30 天的 CPU 利用率、磁盘字节数、磁盘操作字节数、网络字节数、网络数据包量等数据，都能够精确到分钟级别的记录，而且是实时更新的。

快照

你可以为主机增加快照，方便在其他实例中恢复快照，或者用做备份功能。GCE 的快照是增量备份，这意味着如果有两个快照，第二份快照只备份与第一份快照的差异部分。使用这个脚本可以实现自动备份，并且能够实现到期自动删除老备份。

附加硬盘

你可以轻松的添加任意（大于 10 GB）大小的硬盘，有多种磁盘种类可供选择。经过我的测试，如果执行长时间的高 I/O 操作，硬盘读写速度会明显地降低。而且并不一定 SSD 就比 HDD 快，硬盘的大小与吞吐量限制和随机 IOPS 限制呈正相关，也就是说 40G 的 HDD 的速度相当于 10G 的 SSD。

适用场景

低配置的版本用来建站或者是当 “梯子” 都很不错，每月 5 美元的价格还是很吸引人的（做 “梯子” 的一定要注意流量价格！）。已经相当完善的 Web 控制页面可以大大降低使用和学习的门槛。高配置的版本拥有独立 CPU，而且可伸缩性很大。与 Google Cloud 各种功能配合使用，可以搭建大型网站或者游戏服务器。

GCE 的一些坑

下面来讲一讲它的一些坑，尤其是从传统 VPS 转到 GCE 会遇到的一些问题。由于 GCE 是基于云端的，所以有很多东西都不太一样。

主机的外网 IP 并不是直接分配的

GCE 虽然是提供独立 IP 的，但是当你执行 ifconfig -a 时，你会看到默认分配的 IP 是一个内网的保留 IP（形如 10.123.0.1），这是为了方便 instance 里之间互相连接的 IP。当你配置一些需要外网的服务要 bind 到指定 IP 时，你只需要 bind 到这个 IP 即可，所分配给你的外网 IP 会自动将流量转发到这个 IP 上。而且，你的主机并不知道那个外网 IP 就是主机本身，所以所有发向主机对应的外网 IP 的流量都会经过一个路由器，然后再由路由器返回，并且会应用防火墙策略。所以，如果需要本地的通讯，建议尽量多使用环回地址（如 127.0.0.1，::1）或那个内网地址。

防火墙

不能关闭的防火墙对于初次接触的人来说可能有些不适，不过一旦习惯后便会爱上这个功能，这个基于在路由器上的防火墙功能要比在 iptables 里做限制更方便。强烈建议利用好防火墙功能，不要默认允许所有端口。比如你的网站流量全部经过 Cloudflare，那么就可以通过防火墙来只允许 Cloudflare 的 IP 与你的主机连接。

不支持多 IP 与 IPv6

GCE 上不能通过加钱的方式去购买多个 IPv4 地址，所以一个实例只能有一个 IPv4 地址，需要多个 IPv4 需求的可以尝试多个实例（或者可以通过 Load Balancing 来实现多个 IP 地址）。 同时，GCE 目前不支持 IPv6，这实在是很可惜的。目前已经可以通过负载均衡器来实现 IPv6。