Som*_*one 13 networking internet isp multicast video-streaming
YouTube（例如）可以发送一次视频文件并让多个用户流式传输吗？或者，即使所有用户都居住在同一地区，YouTube 是否需要将文件单独发送给每个人？
如果是第二种情况，除了P2P之外，还有什么方法可以让ISP处理并行性或类似的事情吗？
（编辑）除了 YouTube 之外，是否可以发送一次文件，然后多次下载，可能同时（实时）。我的意思是，我们可以将一个文件发送到多个 IP，而只需要上传一次吗？（这里不讨论云服务）
use*_*686 24
YouTube 向每个用户发送一份单独的副本。这几乎是互联网上唯一可用的选择。
\n\n\n除了 P2P 之外，还有什么方法可以让 ISP 处理并行性或类似的事情吗？
\n
不，没有。ISP 没有任何办法可以处理它。过去有两种方式 \xe2\x80\x93 多播和 ISP 提供的缓存代理 \xe2\x80\x93 但现在它们都不起作用。
\n虽然IP“多播”是一种东西，但它从未在互联网规模上发挥过作用（他们尝试过并放弃了），并且无论如何它也不适用于VOD。（一些 ISP 确实在其 IPTV 服务中使用内部多播，但它仅适用于实时、电视/广播风格的广播流 \xe2\x80\x93，不适用于“点播”视频，其中不同的观众想要开始播放不同时间。）
\n几十年前，一些 ISP 曾经提供 HTTP 代理，代表其客户端在本地缓存任何请求的文件（有时选择加入，有时强制执行）。然而，现在这样的代理不再起作用，因为所有网站都使用 HTTPS \xe2\x80\x93 代理无法通过HTTPS 查看，因此它不知道正在请求什么（并且大多数人不希望他们的 ISP不管怎样）\xe2\x80\x93 而且它们并没有提供那么多的好处，既然 100 Gbps WAN 链接是一种选择（而不是较小的 ISP 必须为整个国家共享 1 Mbps，返回当天）。
\n话虽这么说，YouTube 本身很可能会进行本地缓存（我确信 Netflix 会这样做，但我相信 YouTube 也会这样做）。YouTube 不是托管在一个地方 \xe2\x80\x93，它在各个区域都有存储和缓存节点，通过 Google 的专用 WAN 链接互连。因此，当同一区域的多个用户观看同一视频时，他们都会从其区域 YouTube 服务器 \xe2\x80\x93 请求该视频，该服务器很可能只接收该视频一次，并将其缓存以供后续请求。
\n因此，您可以说 YouTube 本身通过使数据更接近 ISP 并对其进行缓存来部分处理并行性。
\n路径的其余部分（从本地 YouTube 节点，通过 ISP，到最终用户）仍然是每个用户的单独副本 \xe2\x80\x93 无法以任何其他方式真正做到这一点 \xe2\x80\x93但这是一条相当短的路。
\n考虑一下，如果三个人正在观看同一个 50 分钟长的视频，则一个客户可能位于开头，另一个客户位于中间，第三个客户位于最后。人们甚至可以决定将视频倒退 15 分钟。尽管接收设备确实会缓冲几秒钟，但在这种情况下需要三个单独的流，可能通过TCP。
然而，对于同时广播，例如会议或卫星发射的实时视频，可以为数百万观众提供服务的用户数据报协议（UDP）流要少得多。为什么有多个来源？有些可能以 640x480 像素分辨率观看，而另一些则以 1920x1080 (1080p) 分辨率观看，因此每个视频都需要自己的 UDP 流。
回答：这取决于您正在观看的视频。
一对多广播称为 多播 ，而一对一广播称为 单播。在多播中，所有接收者同时接收完全相同的视频，而在单播中，接收者可以控制视频内的位置。
组播适用于面向大量观众的大型公共活动，因为它允许广播公司节省传输带宽，因此它用于大型直播活动。单播适合个人在 YouTube 上观看。
尽管在多播中，接收者无法选择他在视频中的位置，但这可以通过浏览器将接收到的视频存储在其临时互联网缓存中来抵消，这允许观看者在流中暂停和后退/前进，直到直播点。
为了使多播发挥作用，接收者和源之间的每个路由器都必须启用多播。为了使计算机加入多播组，它必须支持 Internet 组管理协议 (IGMP)。这曾经是一个问题，但如今大多数硬件都支持这一点。
众所周知的多播使用发生在 2000 年 5 月 18 日，当时超过 200 万互联网用户观看了维多利亚的秘密时装秀。该活动以 56 和 100 kbps 的单播以及 300 kbps 和 700 kbps 的两个组播流进行广播。如果每个人都使用 56 kbps，则流数据超过 100 Gbps，需要昂贵的带宽。当时大多数用户无法使用多播，但如果所有人都使用多播，那么维多利亚的秘密活动所需的最大带宽将为 1 Mbps。
有关详细信息，请参阅文章 全球 IP 网络多播常见问题解答。
目前最好的解决方案是暴力破解，以及分布在世界各地的本地代理服务器（CDN = Content Delivery Network）。
多播（https://en.wikipedia.org/wiki/IP_multicast）在技术上是存在的，但据我所知，公共互联网不支持它。（在互联网视频的早期，我记得读过有关多播在连接一些北美大学的互联网的一部分（ “mbone”，多播骨干网）上使用的信息，特别是用于多对多的视频会议连接。）
将其用于视频基本上可以让路由器完成 CDN 服务器（内容交付网络）用于实时馈送的工作：将数据发送到一个城市一次，并让该城市中的所有用户从附近的计算机进行流传输，因此没有“世界上没有一台机器通过主干链路多次发送所有流量。（也许不是“城市”，而是“互联网中心”。）
对于拥有大量观众的直播（例如奥运会、世界杯足球赛），大多数拥有该流观众的网络都有多个观众，如果我们有支持多播的网络，这可能是一个有趣的想法。或者，对于主要软件（如 Windows）发布后的软件更新，您可以想象让服务器多次多播更新文件，以便每个人都获得副本。
但存在重大技术挑战。
如果数据包被丢弃，多播并没有一个好的方法让单个客户端请求重传。对于适合双向聊天的低延迟视频会议，您只需接受流中的故障作为保持低延迟的代价。但是流式传输“实时”事件时，通常我们不关心几秒钟的延迟，这为 TCP 重传提供了足够的缓冲区。（Youtube 和整个网络都通过TCP/IP运行，这是一种重新传输丢弃的数据包的协议。）
路由器不会保留数据包的旧副本，并且无法扩展世界上的每个客户端向服务器发送请求以将丢弃的数据包重新传输给它们（可能通过单播 UDP）。（这也将为恶意用户创建 DOS（拒绝服务）攻击并消耗大量服务器带宽提供途径。）
因此，也许我们可以使用一些前向纠错（如ECC），以便接收器可以在丢失几个数据包时重建正确的数据。这会一直增加一些开销，并且不会丢失数据包，但可能会避免许多客户端需要重试。但是丢弃的数据包通常会突然出现，因此我们需要一个大的“块大小”供 FEC 来帮助（例如在许多秒或可能是一分钟的视频中的百分之几的开销，需要每个客户端上的大缓冲区才能重建）数据有纠错）。
对于通过多播进行软件分发（在发布日，每个人都下载它），这不是一个问题，因为 ECC 代码可以覆盖整个内容，例如Par2或可以嵌入到某些存档格式（例如 RAR）中的恢复数据。
但是，如果我们想要覆盖与 YouTube 缓冲当前可以吸收的内容相当的观看者的最坏情况（丢失数秒的数据），那么纠错开销就会太高。
因此，我们希望客户端能够回退到单播请求来填补空白，大概是通过 TCP（以获得其拥塞友好性）。因此，我们需要一个高带宽服务器或 CDN，特别是如果人们滥用它来始终从 TCP 流而不是多播（例如，为了解决在不支持多播的 ISP 上的问题）。或者，如果我们不考虑这种“滥用”，而只考虑多播来节省一些带宽。
这显然在技术上比接收 TCP 流复杂得多，并且可能会让您的 CDN 更便宜并且机器或容量更少。
围绕这种架构进行构建不会让人们暂停和倒带，而某些流确实希望支持这一点。（除非他们的客户已经收到并在本地保存了他们要倒回的视频。）
| 归档时间： |
|
| 查看次数： |
4008 次 |
| 最近记录： |