我遇到了一个奇怪的问题。
服务器1A是用户与之交互的服务器。服务器2B，2C和2D存储视频内容。
在网站上，放置一个 html 视频标签
<video src="server1adomain.com/videos?video=Gy12C899">
每当获取此内容时，服务器 1A 上的后端脚本都会确定视频存储在哪个服务器（2B、2C 或 2D）上并获取它。假设它在 2B 上。我不想等待整个视频从 2B 获取并存储在 1A 服务器中，然后才发送给用户。相反，我希望连续流同时从 2B 流向 1A 和用户。这样，用户就可以以最小的延迟获得视频的前几帧。
这个问题的标准解决方案是什么？我查看了 YouTube 上的视频 src，它们似乎都是从同一个域获取的，因此这种方法一定是可行的。
答案1
有多种解决方案或多或少符合行业标准。我建议不要为您的问题设计其他黑客解决方案。
首先，大型流媒体网站使用内容分发网络（CDN），实际内容托管于此。这些服务器不同于 Web 服务器（托管网页或脚本），独立运行；它们的主要目的是托管视频内容并将其存储在更靠近用户的位置。您的 Web 应用程序的工作是将指向服务器 A 的视频源链接替换为直接的链接到内容服务器 — 哪个离用户更近，哪个响应更快（典型的负载平衡情况）。对于第二层服务器，您应该在其上设置一个 Web 服务器（如 Nginx）并直接链接到视频。
请注意，当您检查浏览器发往 YouTube 的网络请求时，它们会使用不同的域。视频内容来自与实际网站完全不同的来源 - 它很可能是您附近的服务器，您的 ISP 与之有直接对等连接。
确保您的视频（如果是 MP4 文件）在文件开头有 MOOV 原子。这可以减少启动延迟，因为即使整个文件尚未传输，客户端也可能开始播放。使用 ffmpeg，您可以通过在-movflags +faststart编码时添加选项（用于ffmpeg -i input.mp4 -c copy -movflags +faststart output.mp4修复现有文件）来做到这一点。或者使用qt-faststart程序（或一些实施将其）放在现有文件上。
最好的选择是将 CDN 方法与使用HTTP 自适应流（DASH 或 HLS）。在这里，您无需使用简单的 HTML5 视频源（很可能是一个大文件），而是可以流式传输单独的视频块。这样可以缩短启动时间，并更好地处理不同的客户端带宽。但是，从头开始设置要复杂得多。当然，有些供应商提供 DASH 类型的流式传输解决方案，您只需向他们提供源视频，就可以在您的网站上实现他们的播放器。他们会处理编码和 CDN 事宜。一些示例是 Bitmovin、Encoding.com 或 Wowza。