用户从浏览器上传需要存储在服务器上并播放的视频。从谷歌的初步了解建议我需要在这里使用 HTTP 实时流媒体（HLS）。 但我不确定它内部是如何运作的？
上述工作流程中有三个组件，即用于保存和检索视频的客户端/服务器/数据存储。
节省流量： 我相信我需要插入 HLS 客户端来发送流数据。 客户端本身是否在发送时将文件分成块并维护这些块的链接（其中每个块指向下一个块）？像这样的事情，因为我相信服务器是愚蠢的，并且将以与http上传功能相同的方式工作，并且这里不需要其他智能？ 但不确定 HLS 服务器端组件在这里如何工作，即它会保存为单个文件还是将单个文件拆分为多个文件然后保存在磁盘上？ 我相信它将文件存储为单个文件，就像常规的 http 上传文件一样？
检索部分 在正常的常规 http 文件下载中，客户端请求文件数据，服务器以块的形式发回响应，但所有响应块都是根据同一请求发回。
我相信在 HLS 的情况下，它的拉取基于客户端为每个流请求发起拉取请求的位置。在每个块拉取请求中，客户端获取下一个块的文件名，并将请求发送到服务器，每个轮询请求的单个文件中的相关块等？因此，对于服务器来说，它是一种常规的 http 文件下载请求，所有智能都取决于客户端
保存流量：上传视频时，必须将其转换为HLS格式。您可以使用 FFMPEG 来做到这一点。您最终将创建清单文件以及视频的所有片段。
检索部分： 播放器将读取清单文件以了解要请求哪些片段。我写了一篇关于 HLS 播放如何与清单文件配合使用的文章：https://api.video/blog/video-trends/what-is-hls-video-streaming-and-how-does-it-work
那么如果在玩家访问清单文件时正在写入清单文件，会发生什么情况呢？是否以这样的方式编写，服务器端的更改是原子的？大型清单文件 (.m3u8) 可能需要几毫秒才能获取，并且当玩家获取它时，它很可能是“半写入”。标准是否要求玩家处理这个问题 - 或者只是令人窒息？