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