使用Cloudfront修复Route 53 CNAME Alias的响应时间变慢

Question

我刚刚设置了CloudFront发行版以加快网站图像的速度。我的图像存储在S3中。我在Route53中使用CloudFront分布端点的CNAME别名设置了自定义子域。

但是，在使用示例图像测试速度时，我发现以下内容：

这三个URL指向同一张图片：

测试是使用来自达拉斯的Pingdom完成的。我在其他地方也取得了类似的结果。

来自S3的较慢加载时间非常合理。图像未在边缘位置缓存。但是，仅通过在发行版前面使用CNAME加载时间几乎翻了一番，这似乎太慢了。我希望使用CNAME，但不以这种性能为代价。

我在这里想念什么吗？我到处都读到，在大多数情况下，额外的DNS CNAME查找可以忽略不计。

Answer 1

一旦查找CNAME及其目标的结果被任何给定的解析器缓存，CNAME延迟就应该消失了，但是除非它是不跨越多个域的CNAME（例如foo.example.com. CNAME bar.example.com.），否则双查找时间总是必然。

但是，您不需要Route 53的CNAME即可指向CloudFront发行版。您可以使用A记录别名，它是Route 53的内部功能，因此查找是在Route 53的内部完成的，而不是通过CNAME的外部引用完成的。然后，延迟就消失了，因为Route 53从其内部数据库提供了答案。

在Route 53控制台中编辑现有RR ...将其从CNAME更改为A，然后将Alias设置为Yes。然后从别名目标选择列表中选择CloudFront分配并保存记录。

CloudFront 发行版的 ALIAS 的问题是它们的 TTL 是 60 秒（CF 发行版本身也有记录）。这不是很理想，因为基本上缓存是最少的。在我们的例子中，DNS 解析时间是对 CloudFront 的 HTTPS 请求的最大部分。 (2认同)