作为欧洲用户，我应该期望 AWS/CloudFront 提供的服务能提供什么样的下载速度？我应该在什么时候报告下载速度缓慢，向谁报告？
对于 WeTransfer，示例链接我得到一个示例下载 URL（在网络控制台中找到，F12）。然后我使用iftop查看哪个主机为我提供文件，mtr看看是否有任何明显的问题突出（尽管从他们的主机到我的机器的跟踪路由可能与其他方式不同）。
昨天，该文件由 CloudFront 的马德里边缘，类似这样的server-54-192-61-242.mad50.r.cloudfront.net，我的下载速度没有超过 300 KiB/s，大部分时间保持在 150-200 KiB/s。这太慢了。*我没有保存跟踪路由，但没有明显的数据包丢失或延迟；IIRC 数据包通过了 Telia。
今天，文件从server-54-240-166-250.lhr5.r.cloudfront.net（伦敦）提供，我在家里获得 1.1 MiB/s，在北欧服务器上平均获得 13 MiB/s（峰值为 25 MiB/s）。这是我的预期。
鉴于亚马逊/AWS 从昨天开始更换了主机，现在一切正常，问题似乎更有可能出在他们身上。然而，下载速度很慢说他们不会做任何事情。CloudFront 文档和AWS 论坛没有关于如何报告网络/路由/对等问题的信息。那么在这种情况下该怎么办？我猜只有 AWS 客户才能完成某件事，但前提是收到报告的人能够理解网络。
我到 CloudFront Madrid 的跟踪路由如下：
10.|-- 62-101-124-129.fastres.net 0.0% 50 4.6 13.8 3.5 101.1 20.3
11.|-- 89.96.200.21 0.0% 50 17.6 16.6 2.6 92.9 22.0
12.|-- mno-b2-link.telia.net 4.0% 50 52.6 26.3 13.1 69.2 13.7
13.|-- mei-b1-link.telia.net 0.0% 50 23.7 30.3 20.4 87.7 11.3
14.|-- bcn-b2-link.telia.net 0.0% 50 47.5 53.7 30.2 92.9 16.4
15.|-- mad-b2-link.telia.net 0.0% 50 62.7 57.7 36.1 102.2 14.4
16.|-- mad-b1-link.telia.net 0.0% 50 37.7 42.1 34.3 59.8 5.6
17.|-- a100-ic-314004-mad-b1.c.telia.net 0.0% 50 70.2 58.5 39.7 87.2 12.5
18.|-- ??? 100.0 50 0.0 0.0 0.0 0.0 0.0
19.|-- ??? 100.0 50 0.0 0.0 0.0 0.0 0.0
20.|-- ??? 100.0 50 0.0 0.0 0.0 0.0 0.0
21.|-- server-54-192-61-242.mad50.r.cloudfront.net 2.0% 50 71.1 83.5 56.4 156.2 19.5
跟踪路由现在是这样的：
10.|-- 62-101-124-94.fastres.net 0.0% 50 68.6 79.5 36.1 108.8 15.4
11.|-- 89.96.200.110 0.0% 50 75.9 94.8 46.0 141.8 17.6
12.|-- ??? 100.0 50 0.0 0.0 0.0 0.0 0.0
13.|-- 54.239.4.248 2.0% 50 107.2 112.9 71.6 146.7 18.2
14.|-- 54.239.41.135 0.0% 50 112.8 108.7 72.8 147.6 15.0
15.|-- 178.236.3.22 0.0% 50 115.8 102.3 58.4 127.9 16.9
16.|-- 176.32.106.11 4.0% 50 95.8 103.2 73.7 130.7 14.2
17.|-- 176.32.106.11 40.0% 50 110.6 108.6 80.4 136.1 14.7
18.|-- ??? 100.0 50 0.0 0.0 0.0 0.0 0.0
19.|-- ??? 100.0 50 0.0 0.0 0.0 0.0 0.0
20.|-- server-54-240-166-250.lhr5.r.cloudfront.net 60.0% 50 88.7 100.0 57.6 131.9 18.0
正如第一个答案所指出的那样，文件是否已缓存在 CloudFront 边缘非常重要。这是一个缓存未命中的示例（目前已设法使我的带宽饱和）：
$ LANG='en' wget -S 'https://download.wetransfer.com/wetransfer-eu1/f7a2031249f56fdeeda9040adda5a26f20160224143804/wetransfer-f7a203.zip?expiration=1456605646&escaped=false&signature=3d916716d49e415f637b4f824c7709f7483b67a8f02588caece30d6c2a3ed0ea&filename=wetransfer-f7a203.zip'
--2016-02-27 21:34:39-- https://download.wetransfer.com/wetransfer-eu1/f7a2031249f56fdeeda9040adda5a26f20160224143804/wetransfer-f7a203.zip?expiration=1456605646&escaped=false&signature=3d916716d49e415f637b4f824c7709f7483b67a8f02588caece30d6c2a3ed0ea&filename=wetransfer-f7a203.zip
Resolving download.wetransfer.com (download.wetransfer.com)... 54.192.61.62, 54.192.61.196, 54.192.61.80, ...
Connecting to download.wetransfer.com (download.wetransfer.com)|54.192.61.62|:443... connected.
HTTP request sent, awaiting response...
HTTP/1.1 200 OK
Content-Type: application/octet-stream
Content-Length: 1449534395
Connection: keep-alive
Server: nginx
Date: Sat, 27 Feb 2016 20:34:39 GMT
Content-Transfer-Encoding: binary
Content-Encoding: none
Cache-Control: private, no-transform, no-store
Allow: GET, HEAD
Accept-Ranges: bytes
Content-Disposition: attachment; filename="wetransfer-f7a203.zip"
X-Transfer-Id: f7a2031249f56fdeeda9040adda5a26f20160224143804
X-Cache: Miss from cloudfront
Via: 1.1 943ab292a0096b706fe263560805857e.cloudfront.net (CloudFront)
X-Amz-Cf-Id: 4hEZcZL56GWMBn8z1T2txF-O3TTdrAC6OxCtqVDZUoJREUd9_EBo6A==
Length: 1449534395 (1.3G) [application/octet-stream]
进一步测试， 我总是gewt X-Cache: Miss from cloudfront，即使在我第六次请求相同的资源时，WeTransfer 似乎也没有在 CloudFront 上缓存任何东西（或者没有缓存这个大小的文件）。有趣的是，X-Transfer-Id: f7a2031249f56fdeeda9040adda5a26f20160224143804虽然我单击下载按钮获得的实际下载 URL 有所不同，但标头始终相同；Via和X-Amz-Cf-Id标头也有所不同。截至本次更新，我第一次请求给定的下载 URL 时非常快，第二次非常慢，第三次出现 404。我试过了，我可以同时进行两次下载，一次是在第二次尝试时，一次是在第一次尝试时：虽然网络条件显然相同，但第一次会非常慢，而后者会非常快。
看https://paste.debian.net/408552/在我的北欧服务器上进行测试：下载 A* 是一个 URL，下载 B* 是另一个 URL；A-2 在 A-1 之后，B-2 在 B-1 之后，但 B* 在 A-2 运行时启动。然而 A-1 和 B-1 非常快，A-2 和 B-2 非常慢。
这越来越像是服务质量/QoS（又称节流）的问题。CloudFront 能否通过缓存未命中来限制我，还是我们应该只怪他们的客户端？
(*) 注意：我有一个 10/10 Mb/s FTTH 连接，使用 Fastweb。可用带宽从未低于此保证速度。据了解，ISP 不会应用 QoS 限制，但有时在意大利以外的地方确实会出现一些路由问题。当我发现问题时，我并没有遇到用其他服务来饱和带宽的问题。
答案1
如果您不是拥有 CloudFront 分发的 AWS 账户的代表（并且问题中使用的措辞看起来好像您不是），那么您的适当联系点就是您遇到性能不佳的网站。
那么他们的如果他们认为合适，他们就有责任向 AWS 支持部门提交支持事件，因为他们是 CloudFront 的客户。
CloudFront 旨在将您的请求路由到最优的 CloudFront 边缘位置（“最优”通常但并不总是意味着地理位置接近），在分销商所有者选择的定价层内（所有者可以选择不支付更昂贵的边缘，而亚马逊的成本更高，在这种情况下，对该站点的请求将避开这些边缘，或至少会避开溢价，即使 CloudFront 可以自行选择使用成本更高的位置但以较低的费率计费）。
由于多种因素，特定下载器位置的最佳边缘将随着时间的推移而发生变化，包括延迟、拥塞、跳数和 AS 路径大小、链路带宽以及许多其他因素……这些因素不是公开信息，但 CloudFront 路由算法会考虑这些因素，以确定您连接到由 CloudFront 提供支持的站点时收到的 DNS 响应。DNS 响应因请求客户端 IP 地址而异。
我从位于美国俄亥俄州南部的一个源 IP 地址看到我的CloudFront 测试站点通过一个边缘位置进行路由，该位置在南本德（印第安纳州，美国）、芝加哥（伊利诺伊州，美国）和阿什本（弗吉尼亚州，美国）之间定期变化——我请求页面的实际 IP 地址甚至没有变化。从距离不到 5 英里的类似设置，但使用不同的 ISP 使用不同的静态源 IP 地址，我得到的响应同样变化，但通常不同。
这可以通过 CloudFront 的算法最容易地解释，该算法尝试根据从外部看不明显的因素来选择最合适的边缘。
您可能知道，昨天您与 CloudFront 的连接速度缓慢可能已被检测到，并触发选择算法选择不同的策略，从而导致性能问题“自行修复”。也有可能由于在更好的位置选择上存在可用性问题，马德里边缘被用作次优选择。
CloudFront 和原始服务器之间也可能存在问题。CloudFront 的响应标头会为您提供更多信息...如果X-Cache: Hit from Cloudfront存在，则表示您将从边缘缓存中获得服务，Age:标头将告诉您对象在边缘缓存了多长时间。如果存在X-Cache: Miss from Cloudfront，则表示您的下载未缓存在边缘，您当前接收的文件正在从原始服务器获取，同时正在暂存到缓存并流回给您。让该下载完全完成，然后使用相同的请求再次下载应该会为您提供缓存的副本，假设您的下一个请求命中相同的边缘，并且速度差异（如果有）大约表示返回原始服务器的连接速度。CloudFront 是一个拉通 CDN；对象不会复制到边缘，它们只存储在初始请求之后被请求的位置。
作为 CloudFront 客户，我从未需要报告下载速度缓慢的情况。这并不意味着它完美无缺，但该服务在性能和弹性方面确实设计得非常可靠。