我试图理解服务器架构之间的本质区别是什么设计将流媒体（例如 FLV 或 h.264）传输到 Flash 播放器，而不是使用普通的 HTTP 服务器（例如，提供静态内容的 Apache），它能够提供从大文件内的偏移量提供数据的功能。
我指的是静态电影内容，而不是实时摄像头或其他东西的流媒体。我的印象一直是普通的网络服务器可以做到这一点。要求是通常的播放/暂停，但也需要在视频的非预加载部分进行向前搜索。我的印象是后者在普通服务器上也是可能的。
是不是真正的流媒体服务器做这个效率更高，或者它们能做某些事情，而普通服务器做不到？
谢谢
答案1
实时和/或动态流式传输的问题在于，简单的 HTTP 协议没有内置任何机制（与 RTMP 等协议不同）。因此，一端或另一端必须具有智能。实际上，最好让客户端拥有所谓的“大脑”，而让 Web 服务器变得笨拙。这对可扩展性有好处。 微软，苹果， 和Adobe现在，所有这些解决方案都具有相当可靠的 HTTP 流式传输解决方案，客户端知道如何向服务器请求不同的分辨率、比特率，最重要的是，视频流的不同时间段。这使得它们成为非常有利于带宽、缓存和 CDN 的解决方案。微软和 Adobe 确实需要一个模块服务器端来将大文件“分块”成多个段，而苹果则要求您预先分块文件并使用完全标准的 HTTP 服务器。但除此之外，智能都在客户端插件上，您可以将代理缓存或原始获取模式的 CDN 与任何解决方案混合使用，以非常快速地扩展规模。
传统的面向连接的流媒体协议需要专用服务器，而且扩展性很差。您必须向 Akamai 或 Limelight 支付大笔费用才能向大量观众播放大量流媒体。他们有数万台服务器来处理这类事情。
上面提到的相对较新的基于 HTTP 的选项实际上可以与组织和 ISP 网络上已有的庞大 HTTP 缓存基础设施以及 CDN 提供的庞大 HTTP 缓存基础设施（通常提供比基于连接的流媒体更低的 HTTP 传输价格）一起使用。
苹果甚至已经向 IETF 提交了他们的实时 HTTP 流媒体解决方案，以供其作为开放标准进行考虑（尽管我怀疑开创此类技术的 Move Networks 可能会有专利问题）。
答案2
“它能够提供从大文件内的偏移量提供的数据”
这需要客户端和服务器具备一些额外的智能 - 本质上，您是在 HTTP 之上分层另一种协议。但有很多可用的工具可以做到这一点。但是，我不知道有任何工具可以在流媒体源（例如相机）上操作 - 只能在具有定义的开始来测量偏移量的文件上操作。另一方面，浏览实时流媒体源将非常困难。