服务器 Gind.cn
  1. 服务器 Gind.cn
  3. Amazon CloudFront CORS特定的延迟
Intereting Posts
将CentOS 5.5上的Perl升级到版本5.10+ GRE隧道TTL号码 Windows Server虚拟磁盘高速caching设置 是否应该在开发和生产环境中使用相同的机器密钥？ 如何在SQL Server Amazon RDS实例上重命名数据库？ Inetd / xinetd不在cygwin下工作，为什么？ logging成功后，sshclosures连接 sh VPN VPN客户端和连接到McAfee（IKE阶段1 IPsec阶段2）VPN服务器的configuration 在Apache / htaccess压缩redirect。 怎么样？ Tripwire：tripwire –update -Z low说错误：文件无法打开 从较新的Powershell版本导入模块 无法删除Windows服务器上的文件句柄 如何从KVM主机（CPU，MEM，HDD，NET，…）监控来宾虚拟系统 在Linux服务器上“挂载”cloudfiles？ MongoDB故障转移副本集

Amazon CloudFront CORS特定的延迟

我正在经历服务CORS请求之间的延迟，但直接请求服务罚款。 我正在使用它来通过HTTP分发媒体stream，所以减less启动延迟是非常重要的。

当通过CloudFront分发（通过浏览器或curl的直接请求）获得媒体清单时，以及从我们网站上播放器发出的CORS请求返回成功时，大约需要90-180秒。 我已经在CloudFront分配中启用了OPTIONS请求转发，并且也包含了OPTIONS请求的结果。 我在下面的Chrome开发工具中包含了curl请求的结果以及来自networking选项卡的相应结果。 请注意，这些请求是在15秒内从同一个客户端发出的（首先发送curl请求）。

=== CURL请求=== 

* Trying 54.192.135.101... * Connected to <exampleDistributionID>.cloudfront.net (1.1.1.1) port 443 (#0) * ALPN, offering http/1.1 * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH * successfully set certificate verify locations: * CAfile: /opt/local/share/curl/curl-ca-bundle.crt CApath: none * TLSv1.2 (OUT), TLS header, Certificate Status (22): * TLSv1.2 (OUT), TLS handshake, Client hello (1): * TLSv1.2 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (IN), TLS handshake, Server key exchange (12): * TLSv1.2 (IN), TLS handshake, Server finished (14): * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): * TLSv1.2 (OUT), TLS change cipher, Client hello (1): * TLSv1.2 (OUT), TLS handshake, Finished (20): * TLSv1.2 (IN), TLS change cipher, Client hello (1): * TLSv1.2 (IN), TLS handshake, Finished (20): * SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256 * ALPN, server accepted to use http/1.1 * Server certificate: * subject: C=US; ST=Washington; L=Seattle; O=Amazon.com, Inc.; CN=*.cloudfront.net * start date: Sep 17 00:00:00 2015 GMT * expire date: Dec 15 23:59:59 2016 GMT * subjectAltName: <exampleDistributionID>.cloudfront.net matched * issuer: C=US; O=Symantec Corporation; OU=Symantec Trust Network; CN=Symantec Class 3 Secure Server CA - G4 * SSL certificate verify ok. > GET /path/to/manifest/stream.m3u8 HTTP/1.1 > Host: <exampleDistributionID>.cloudfront.net > User-Agent: curl/7.47.1 > Accept: */* > < HTTP/1.1 200 OK < Content-Type: application/vnd.apple.mpegurl < Content-Length: 1435 < Connection: keep-alive < Server: nginx/1.9.10 < Date: Sun, 17 Apr 2016 00:26:06 GMT < Last-Modified: Sun, 17 Apr 2016 00:26:05 GMT < ETag: "5712d81d-59b" < Cache-Control: no-cache < Access-Control-Allow-Origin: * < Accept-Ranges: bytes < X-Cache: Miss from cloudfront < Via: 1.1 f687c6e8ce478528ab87681ac35779ab.cloudfront.net (CloudFront) < X-Amz-Cf-Id: P01_dDWZRWZ0lzAqROqOMnaipstK484vPWnicw3F0kcG_7elxBGNkQ== <...Content of stream.m3u8...>

=== Chrome请求===

显示收到的404错误的Chrome开发工具networking选项卡的屏幕截图

===选项请求=== 

 * Trying 1.1.1.1... * Connected to <exampleDistributionID>.cloudfront.net (1.1.1.1) port 443 (#0) * ALPN, offering http/1.1 * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH * successfully set certificate verify locations: * CAfile: /opt/local/share/curl/curl-ca-bundle.crt CApath: none * TLSv1.2 (OUT), TLS header, Certificate Status (22): * TLSv1.2 (OUT), TLS handshake, Client hello (1): * TLSv1.2 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (IN), TLS handshake, Server key exchange (12): * TLSv1.2 (IN), TLS handshake, Server finished (14): * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): * TLSv1.2 (OUT), TLS change cipher, Client hello (1): * TLSv1.2 (OUT), TLS handshake, Finished (20): * TLSv1.2 (IN), TLS change cipher, Client hello (1): * TLSv1.2 (IN), TLS handshake, Finished (20): * SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256 * ALPN, server accepted to use http/1.1 * Server certificate: * subject: C=US; ST=Washington; L=Seattle; O=Amazon.com, Inc.; CN=*.cloudfront.net * start date: Sep 17 00:00:00 2015 GMT * expire date: Dec 15 23:59:59 2016 GMT * subjectAltName: <exampleDistributionID>.cloudfront.net matched * issuer: C=US; O=Symantec Corporation; OU=Symantec Trust Network; CN=Symantec Class 3 Secure Server CA - G4 * SSL certificate verify ok. > OPTIONS /path/to/manifest/stream.m3u8 HTTP/1.1 > Host: <exampleDistributionID>.cloudfront.net > User-Agent: curl/7.47.1 > Accept: */* > < HTTP/1.1 200 OK < Content-Type: text/plain < Content-Length: 0 < Connection: keep-alive < Server: nginx/1.9.10 < Date: Sun, 17 Apr 2016 22:05:15 GMT < Access-Control-Allow-Origin: http://my.origin.com < Access-Control-Allow-Methods: GET, OPTIONS < Access-Control-Allow-Headers: Authorization < Access-Control-Allow-Credentials: true < X-Cache: Miss from cloudfront < Via: 1.1 ed2825b48bb51b4febd93a82e71f7ed9.cloudfront.net (CloudFront) < X-Amz-Cf-Id: WY-KPfTlNTenTjWyYF9GS4ikyrGMQONAm4mXpbuKpHzfBk_xKfxG2w== < * Connection #0 to host <exampleDistributionID>.cloudfront.net left intact

在损失看到我的configuration错误，任何帮助将不胜感激。

CloudFront 默认通过将错误响应caching5分钟来尝试保护源服务器免受不可用对象的不必要请求。

从这个问题中可以明显看出，最可能的解释是，在实际存在之前，这个对象正在被请求（不pipe什么原因），并且错误响应被caching了几分钟，导致看起来是“延迟“在对象的可用性。 但CloudFront没有传播延迟，因为CloudFront是一个直通式caching – 没有什么可传播的。

你的curltesting看起来是成功的，但是实际上没有certificate任何东西，显然是因为（除其他可能的原因之外）你在curl请求中没有包含Origin:标头。 这使得curl请求在语义上不同于浏览器发送的请求。

在评估某个对象是否可以从caching中提供服务时，CloudFront不仅考虑path。 大多数转发到原始服务器的头文件也会进行比较，如果使用此请求转发的头文件与使用caching的可用响应的先前请求发送的头文件不匹配，则不会使用caching的响应，而将请求发送到原点。 它的响应将与发送的头文件一起被caching。

所以，以下两个要求： 

 GET /object HTTP/1.1 Host: www.example.com

和 

 GET /object HTTP/1.1 Host: www.example.com Origin: http://www.example.com

…（假设Origin:头被转发到源服务器，因为它需要用于CORS）被视为两个不同的，基本上不相关的请求，必要的 – CloudFront不知道源服务器是否可能根据发送的请求头修改其响应。 对这两个请求的响应将被分开caching，并且每个响应未来的匹配请求将只响应。

如果分配被configuration为转发cookie或查询string，则这些也会与caching的响应一起存储，caching的响应只会响应与生成caching响应的原始请求完全匹配的请求而被提供 – 基于所有转发参数。 （这就是为什么不必要地转发您的原始服务器不需要的信息会损害您的caching率。）

将404错误分布的错误caching最小TTL设置为0可以通过防止404响应的高速caching来解决此问题。