Azure CDN-以某种方式截断“大文件”？

Question

编辑：尽管我无法弄清楚实际上是什么原因造成的，但现在这一切都在神秘地进行。可能根本不是CDN吗？留在这里作后代之用，如果我再次看到这种事情会更新...

我一直在尝试使用Azure CDN（由Microsoft托管，而不是Akamai或Verizon托管）来处理几个Azure Web Apps的文件下载，直到今天，当它开始返回截断的“大文件”，导致无法打开PDF文件（通过“大文件”，我特别指的是Azure CDN的Large File Optimisation功能）。

该文件可以从原始URL正常工作，并且为8.59mb，但是从CDN端点检索到的同一文件为恰好 8mb。巧合的是，它恰好与上述大文件优化功能使用的块大小相同。文档的相关部分：

  

Microsoft的Azure CDN Standard使用一种称为对象分块的技术。当请求大文件时，CDN从原始位置检索文件的较小部分。 CDN POP服务器收到完整或字节范围的文件请求后，CDN边缘服务器从原始位置以8 MB的块请求文件。   ...这种优化依赖于原始服务器支持字节范围请求的能力

有问题的文件网址：

• Origin
• CDN

我还将同一文件直接上载到网站的文件系统中，以排除CMS（Umbraco）及其blob-storage-filesystem东西的干扰，但是无论如何，结果都是完全相同的。这是供参考的链接。

• Origin
• CDN

在两种情况下，这两个文件都是二进制相同的，只是CDN中的文件突然停止在8mb处，即使原始文件支持字节范围请求（已通过Postman验证），并且上面链接的Azure CDN文档声称

  

如果不是所有块都缓存在CDN上，则使用预取从源请求块。

那

  

最大文件大小没有限制。

其他超过8mb的文件也发生了相同的问题，尽管这些文件以前在上个星期已经起作用。从那以后，没有对CDN配置进行任何更改。

我正在想的事情是这样的：

1. 客户端请求从CDN下载文件
2. CDN认为这是一个“大文件”，并从原始位置请求第一个8mb的数据块
3. 原始人按要求回复了8mb的数据块
4. CDN开始向客户端返回8mb数据块
5. CDN不请求下一个块，或者起源不提供它
6. 客户端仅收到文件的前8mb

或者我正在吠错树。已经尝试关闭压缩功能，但不确定是否还有其他选择。这可能是我的错，所以我是否对CDN进行了错误配置？我曾考虑清除CDN的缓存，但我并没有真正将其视为解决方案，而是宁愿避免手动解决方法...

Answer 1

这种优化依赖于源服务器支持字节范围请求的能力；如果源站不支持字节范围请求，则下载大于 8mb 数据的请求将失败。

https://docs.microsoft.com/en-us/azure/cdn/cdn-large-file-optimization