CloudFront如何正确分发IIS Smooth Streaming平滑流媒体？

IIS Smooth Streaming 是微软提出的一种基于 fragmented MP4 的自适应码率流媒体方案，源站由 IIS Media Services 扩展提供动态分片与清单响应。当把它接入 Amazon CloudFront 时，运维人员往往发现普通静态文件的缓存规则并不完全适用：客户端会请求 .ism 清单、.ismc 客户端清单以及多个 QualityLevels 下的碎片路径，这些请求必须被 CloudFront 精确转发并合理缓存。源站内容目录通常位于 C:\inetpub\wwwroot\media\BigBuckBunny.ism，磁盘布局直接对应 URL 中的虚拟路径。

一、从请求模型理解缓存难点

IIS Smooth Streaming 的访问入口并不是一个简单的 MP4 文件，而是一个以 .ism 结尾的服务器端清单路径。播放器首先加载 /media/BigBuckBunny.ism/Manifest，服务器根据客户端支持的码率返回 .ismc 清单；随后客户端按照清单中定义的 QualityLevels 请求具体视频或音频碎片，例如 /media/BigBuckBunny.ism/QualityLevels(1500000)/Fragments(video=0)。每个碎片对应独立的关键帧对齐媒体段，播放器可以无缝切换码率。

从 CloudFront 视角看，这些请求的 URL 路径并不是静态文件系统中的真实文件，而是 IIS 扩展在运行时解析并生成的响应。因此，CloudFront 必须把这些路径视作可缓存但需要正确回源的动态内容。如果把 .ism 或 .ismc 当作普通的静态扩展名处理，缓存策略可能过松或过严，导致码率切换失败或碎片过期。

此外，fragmented MP4 对字节范围请求依赖较强。播放器在拖动进度时会发送带 Range 头的请求，CloudFront 需要将 Range 头转发给源站，并缓存部分响应。若源站关闭了按 Range 响应或 CloudFront 配置了强制完整对象缓存，进度拖动会出现明显延迟。

二、CloudFront 分配与缓存行为的落地配置

在 CloudFront 控制台创建分配时，Origin Domain Name 应填写 IIS 源站的公网域名或内部负载均衡地址，Origin Path 可留空，因为 /media 层级已经在 URL 中体现。缓存行为建议至少拆分为两类：一类匹配 /media/*.ismc 清单文件，另一类匹配 /media/*.ismv 和 /media/*.isma 碎片文件。这样便于对不同对象设置差异化 TTL。

对于清单文件，建议使用较短的 TTL，例如 60 秒到 300 秒，让新增的码率轨道或隐藏字幕轨道能够及时同步到边缘节点。对于视频与音频碎片，可以设置较长 TTL，例如 7 天甚至更久，因为这些碎片一旦生成就不会改变。典型配置片段如下：

{
  "PathPattern": "/media/*.ismc",
  "TargetOriginId": "iis-smooth-origin",
  "ViewerProtocolPolicy": "redirect-to-https",
  "ForwardedValues": {
    "QueryString": true,
    "Cookies": {
      "Forward": "none"
    },
    "Headers": {
      "Forward": "whitelist",
      "Items": ["Range", "Origin"]
    }
  },
  "MinTTL": 0,
  "DefaultTTL": 60,
  "MaxTTL": 300
}

这里把 QueryString 设置为 true 是关键。虽然许多 Smooth Streaming 请求不带查询参数，但一旦启用签名 URL，播放器会在每个碎片请求后附加签名参数，关闭查询字符串转发会导致签名丢失，CloudFront 直接拒绝请求。同时，Range 头需要加入白名单，保证进度拖动和分片请求能够正常回源。

对于碎片缓存行为，可以将 DefaultTTL 和 MaxTTL 调高，以提升缓存命中率。需要注意的是，IIS 源站返回的 Cache-Control 头可能会覆盖 CloudFront 的默认 TTL。若源站对 .ismv 文件的响应头设置为 no-cache，则边缘节点不会按预期缓存，需要检查 IIS 输出缓存规则或使用 CloudFront 的响应头策略覆盖。

三、源站 IIS 与 Media Services 模块准备

源站的 IIS 需要安装 IIS Media Services 扩展，并确保 Web 站点启用了 Smooth Streaming 处理程序。安装完成后，IIS 管理器会在站点功能视图中增加 Smooth Streaming 相关图标。对于手动部署的场景，可以在站点根目录的 web.config 中加入媒体服务配置节，让特定虚拟目录启用平滑流媒体支持。下面的示例位于 C:\inetpub\wwwroot\media\web.config：

<configuration>
  <system.webServer>
    <mediaServices>
      <smoothStreaming enabled="true" />
    </mediaServices>
  </system.webServer>
</configuration>

除了配置节，IIS 还必须能够识别与 Smooth Streaming 相关的 MIME 类型。常见的扩展名包括 .ism、.ismc、.ismv 和 .isma。如果这些扩展名没有出现在 IIS 的 MIME 类型列表中，源站会返回 404.3 错误。管理员可以在 IIS 管理器的 MIME 类型页面添加，或直接在 C:\Windows\System32\inetsrv\config\applicationHost.config 中修改 <staticContent> 节点。修改后需要重启站点使配置生效。

还需留意应用程序池的身份权限。Smooth Streaming 处理程序需要读取源媒体文件，默认的 ApplicationPoolIdentity 在读取 C:\inetpub\wwwroot 下内容时通常没有问题，但如果媒体文件位于其他磁盘如 D:\MediaAssets\，则需要为对应目录授予 IIS_IUSRS 读取权限。

四、防盗链、排障与性能优化

CloudFront 为 Smooth Streaming 提供与普通 HTTP 内容一致的防盗链能力。签名 Cookie 更适合平滑流媒体场景，因为播放器在切换码率时会连续请求多个碎片，如果使用签名 URL，必须为每个碎片重新计算签名，既增加源站压力也容易因时钟偏差导致播放中断。启用签名 Cookie 后，只需要在播放器首次请求清单时下发 Cookie，后续碎片请求自动携带凭证，CloudFront 会校验策略并允许访问。

排障时优先检查边缘节点的缓存命中状态。通过请求头 X-Cache 可以判断某个碎片是命中缓存还是回源。若持续回源，检查源站返回的 Cache-Control、CloudFront 的 TTL 设置以及是否配置了 Origin Shield。另一个常见问题是 .ismc 文件被长期缓存后，客户端仍请求旧的码率轨道，此时需要对 .ismc 路径执行失效操作或等待短 TTL 过期。

性能方面，CloudFront 的区域缓存和 Origin Shield 可以显著降低源站压力。如果多区域用户同时请求相同碎片，开启 Origin Shield 后，只有固定区域的边缘节点会回源，其他边缘节点从 Shield 层获取内容。这种结构对 IIS 源站的 CPU 和带宽占用都有明显改善。对于高并发直播场景，还可以在源站前增加一层缓存代理，但需要保证 Range 请求能够透传。

AWS CloudFrontSmooth StreamingIIS平滑流媒体修改时间：2026-09-27 01:26:57