AWS Cloudfront延迟：原始获取与互联网 [英] AWS Cloudfront latency: origin fetch vs internet

问题描述

通过Cloudfront从原始站点第一次获取任何给定文件是否比通过Internet直接从原始站点获取更快？我想知道AWS骨干网是否以某种方式超过了公共互联网的速度。

Is the first fetch of any given file from an origin via Cloudfront faster on average than fetching directly from the origin over the internet? I'm wondering if the AWS backbone somehow outperforms the speed of the public internet.

例如，悉尼的用户是否想从我在欧洲的S3中获取文件，而Cloudfront却没有它尚未缓存，是将它直接通过互联网直接传输，还是让Cloudfront从欧洲起源将其获取到悉尼边缘缓存以及最近几步传输到互联网的速度更快？但这只是一个例子。用户将遍及全球，许多人将在欧洲，离原点很近。

Eg if a user from Sydney wants a file from my S3 in Europe, and Cloudfront doesn't yet have it cached, is it quicker to get it directly over the internet, or for Cloudfront to fetch it from the European origin to the Sydney edge cache and to the internet for the last few hops? But that's just an example. Users will be worldwide, and many will be in Europe, close to the origin.

我确实知道在发出CDN原始请求之后将缓存文件和后续请求从悉尼出发，对于文件TTL中的同一文件会更快，但是在我的用例中，随后的请求不会经常发生...

I do understand that AFTER that request to origin the CDN will cache the file and subsequent requests from Sydney for that same file within the file's TTL will be much faster, but subsequent requests will not happen often in my use case...

S3上的小文件（<1MB）很少更改，很少单独下载，并且TTL大约为1周。

I have a large collection of small files (<1MB) on S3 which seldom change, and each of them individually is seldom downloaded and will have a TTL of about 1 week.

我很好奇在这种情况下，即使将Cloudfront置于S3前面也是值得的，即使我不会从CDN提供的边缘缓存服务中获得太多价值。

I'm curious if putting Cloudfront in front of S3, in this case, will be worth it even though I won't get much value from the edge caching service that the CDN provides.

因此，对于那些首次获取的情况，我是否应该期望平均减少任何延迟？

So should I expect to see any latency decrease on average for those first fetch scenarios?

编辑：随后我发现了本文提到了持久连接...减少了总体延迟...，但是我怀疑这只是意味着Cloudfront-to-origin子系统的性能更好，而不一定是端到端的更好。

I subsequently found this article which mentions "Persistent Connections... reduces overall latency...", but I suspect it just means better performance of the Cloudfront-to-origin subsystem, and not necessarily better end-to-end perf for the user.

推荐答案

我想知道AWS主干网是否在某种程度上超过了速度

I'm wondering if the AWS backbone somehow outperforms the speed of the public internet.

想法是应该的。

您应该看到一个整体的改进，因为CloudFront即使不进行缓存也做了很多有用的事情：

You should see an overall improvement, because CloudFront does several useful things, even when not caching:

• 将流量带到AWS上托管网络尽可能接近查看者，流量在AWS网络上而不是在公共Internet上遍历其大部分距离。

• brings the traffic onto the AWS managed network as close to the viewer as practical, with the traffic traversing most of its distance on the AWS network rather than on the public Internet.

通过创建两个TCP连接¹来划分浏览器和源之间的TCP交互，其中一个从浏览器到CloudFront，一个从CloudFront到Origin。优化了在建立连接，然后进行TLS协商，然后进行HTTP请求/响应的往返消息传递。

sectionalizes the TCP interactions between the browser and the origin by creating two TCP connections¹, one from browser to CloudFront, and one from CloudFront to origin. The back-and-forth messaging that occurs for connection setup, then TLS negotiation, then HTTP request/response, are optimized.

（可选）提供了http / 2到HTTP / 1.1网关/转换，允许浏览器通过单个http / 2连接发出并发请求，同时将这些请求转换为到源的单独连接上的多个HTTP / 1.1请求。

(optional) provides http/2 to HTTP/1.1 gateway/translation, allowing the browser to make concurrent requests over a single http/2 connection while converting these to multiple HTTP/1.1 requests on separate connections to the origin.

在离开某个区域访问Internet的流量成本和离开一个CloudFront边缘访问Internet的流量之间的差异中存在一些较小的套利机会。 （从EC2 / S3到CloudFront的流量出站不收费）。在许多情况下，这些操作对您有利，例如，低成本区域中的查看器访问高成本区域中的存储桶，但它们几乎总是不对称的。伦敦查看器和悉尼存储区直接访问存储区的费用为$ 0.14 / GB，但通过CloudFront访问同一存储区的费用为$ 0.085 / GB。另一方面，访问伦敦存储桶的Sidney查看器直接向存储桶收取$ 0.09 / GB，通过CloudFront进行访问的费用为$ 0.14 / GB。伦敦查看器/伦敦存储区通过CloudFront的价格为$ 0.085，或者直接向存储区的价格为$ 0.09 / GB。我的长期假设是，与AWS的私有传输成本相比，这些差异代表了Internet访问成本。您还可以通过价格类别功能将CloudFront配置为仅使用较低成本的边缘，这不能保证实际上仅使用较低成本的边缘进行流量，但是如果较低的成本边缘，则可以保证不向您收取更高的价格

There are some minor arbitrage opportunities in the discrepancies between costs for traffic leaving a region bound for the Internet and traffic leaving a CloudFront edge bound for the Internet. (Traffic outbound from EC2/S3 to CloudFront is not billable). In many cases, these work in your favor, such as a viewer in a low cost area accessing a bucket in a high cost area, but they are almost always asymmetric. A London viewer and a Sydney bucket is $0.14/GB accessing the bucket directly, but $0.085/GB accessing the same bucket through CloudFront. On the flip side, a Sidney viewer accessing a London bucket is $0.09/GB direct to the bucket, $0.14/GB through CloudFront. London viewer/London bucket is $0.085 through CloudFront or $0.09/GB direct to the bucket. It is my long-term assumption thst these discrepancies represent the cost of Internet access compared to the cost of AWS's private transport. You can also configure CloudFront, via the price class feature, to use only the lower cost edges, which is not guaranteed to actually use only the lower cost edges for traffic, but rather guaranteed not to charge you a higher price if a lower cost edge is not used.

还请注意，有两个（已知）服务使用CloudFront且始终禁用缓存

Note also that there are two (known) services that use CloudFront with caching always disabled:

在存储桶上启用S3传输加速从根本上来说是零配置所需的CloudFront分发，而未启用缓存。与自我配置的CloudFront + S3安排相比，传输加速只有三个显着差异：具体来说，它可以传递S3可以理解和接受的签名URL（对于S3加上您自己的CloudFront，您必须使用CloudFront签名URL， （使用不同的算法），地理位置附近靠近存储桶区域的用户将绕过CloudFront网络，这也消除了该请求的传输加速附加费。第三个区别是，它的成本几乎总是比您自己的CloudFront + S3高。

Enabling S3 Transfer Acceleration on a bucket is fundamentally a zero-config-required CloudFront distribution without the cache enabled. Transfer acceleration has only three notable differences compared to a self-provisioned CloudFront + S3 arrangement: specifically, it can pass-through signed URLs that S3 understands and accepts (with S3 plus your own CloudFront, you have to use CloudFront signed URLs, which use a different algorithm) and the CloudFront network is bypassed for users who are geographically close to the bucket region, which also eliminates the Transfer Acceleration surcharge for that request. The third difference is that it almost always costs more than your own CloudFront + S3.

AWS显然认为，此处的增加值足以使该功能的成本超过自己使用S3 + CloudFront很有意义。有时候，我用它从直接到桶的配置中挤出了更多的优化，因为这很容易进行更改。

AWS apparently believes the value added here is significant enough that for the feature to cost more than using S3 + CloudFront yourself makes sense. On occasion, I have used it to squeeze a bit more optimization out of a direct-to-bucket arrangement, because it is an easy change to make.

查找转帐在此页面上 进行加速测试并观察它的作用做。这是上传而不是下载，但这是相同的想法，它使您可以合理地描述公共互联网与AWS边缘网络（CloudFront基础架构）之间的差异。

Find the Transfer Acceleration speed test on this page and observe what it does. This is upload, rather than download, but it is the same idea -- it gives you reasonable depiction of the differences between the public Internet and the AWS "Edge Network" (the CloudFront infrastructure).

API网关边缘优化的API也会通过CloudFront进行路由。尽管API Gateway确实提供了可选的缓存，但它使用的是缓存实例，而不是CloudFront缓存。 API随后引入了第二种不使用CloudFront的API终端节点，因为当您在同一实际AWS区域内发出请求时，通过额外的硬件发送请求是没有意义的。这也使在自己的CloudFront后面部署API网关更加明智，避免了不必要的第二次通过相同的基础结构。

API Gateway edge-optimized APIs also do route through CloudFront for performance reasons. While API Gateway does offer optional caching, it uses a caching instance, not the CloudFront cache. API subsequently introduced a second type of API endpoint that doesn't use CloudFront, because when you are making requests within the same actual AWS region, it doesn't make sense to send the request through extra hardware. This also makes deploying API Gateway behind your own CloudFront a bit more sensible, avoiding an unnecessary second pass through the same infrastructure.

¹ 两个TCP连接实际上可能是三个，这应该趋于进一步提高性能，因为每个连接之间的边界提供了一个内容缓冲区，该缓冲区允许更平滑，更快地传输并更改带宽延迟乘积。有利的方式。自2016年以来，CloudFront具有两层边缘位置，即外部全局边缘（最靠近查看器）和内部区域性边缘（在实际AWS区域内）。这是记录，但是该文档非常丰富-级别，并且无法完全解释基础。轶事观察表明，每个全局边缘都有一个分配的本国区域边缘，该区域边缘是其最近的AWS区域中的区域边缘。连接从观察者到外边缘，再到内边缘，再到原点。该文档表明在某些情况下会绕过内部（区域）边缘，但观察结果表明这是例外。

¹two TCP connections may actually be three, which should tend to further improve performance because the boundary between each connection provides a content buffer that allows for smoother and faster transport and changes the bandwidth-delay product in favorable ways. Since some time in 2016, CloudFront has two tiers of edge locations, the outer "global" edges (closest to the viewer) and the inner "regional" edges (within the actual AWS regions). This is documented but the documentation is very high-level and doesn't explain the underpinnings thoroughly. Anecdotal observations suggest that each global edge has an assigned "home" regional edge that is the regional edge in its nearest AWS region. The connection goes from viewer, to outer edge, to the inner edge, and then to the origin. The documentation suggests that there are cases where the inner (regional) edge is bypassed, but observations suggest that these are the exception.

这篇关于AWS Cloudfront延迟：原始获取与互联网的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！