技术选型：
React.js
Python & Sanic

1.背景

最近公司要做一个培训系统，其中一个模块为课程学习，需求为上传及播放学习视频。

2.简单实现

最简单、粗暴，同时体验最差的做法就是后台直接将视频文件以bytes写入http response，同时response headers中标记media相关的属性Content-Type: video/mp4，然后丢给浏览器播放。

这种实现对于后台来说，使用Python异步web库Sanic，函数中的具体实现只需要1行代码（查找文件路径相关的代码除外）：

from sanic.response import file_stream

bp = Blueprint('videos', url_prefix="/videos")

@bp.route('/<video_id>', methods=["GET"])
async def video(request, video_id):
    # get the video location with video_id
    file_path = '/path/to/file'
    return await file_stream(file_path)

3.优化思路

好吧，对于一个有理想、有追求的程序员来说，上面的这种简单做法是绝对无法接受的。

3.1 视频播放器

第一步，必须搞个视频播放器，就算后台服务再垃圾，网页的UI也必须花哨一些，至少看起来像点样子。

由于前端页面使用的React.js，了解到知乎开源了一个视频播放库Griffith，一开始满怀期待以为省了很多工作，但实际用下来发现这玩意设计上有些奇怪，而且有几处重要的bug，后来无奈换成react-player了，本文且已此为例，影响不大。

这个视频播放库使用起来也是极为简单，引入组件，定义好视频URL，一个功能强大的视频播放器就能在页面呈现了，自己调整下播放器的宽高，以适应页面大小，“看起来”就完美了。

import React from "react";
import Player from 'griffith';

export const Video = () => {

    const sources = {
        sd: {
             play_url: 'https://zhstatic.zhihu.com/cfe/griffith/zhihu2018_hd.mp4'
        },
        hd: {
             play_url: '/api/videos/001'
             // play_url: 'https://zhstatic.zhihu.com/cfe/griffith/zhihu2018_hd.mp4'
        }
    };

    return (
        <React.Fragment>
            <Player sources={sources} useAutoQuality={true} />
        </React.Fragment>
    );
};

3.2 分段缓冲

找到合适的播放器后，为什么只能说“看起来”完美呢？

经过一番尝试，发现在使用自己后台服务提供的URL时，打开页面播放视频时，播放器总是会呈现Loading状态，非得等整个视频完全下载后才开始播放。这要是播放一个稍微大点的文件，或者网速不太得劲的时候，那我岂不是要等到天荒地老？

对比Griffith示例提供的URL，这个视频在页面打开的瞬间就能播放，进度条也是渐进地增长，通过鼠标选定位置，还能跳跃式的播放！好嘛，这才是咱们想要的结果。

打开浏览器的调试工具，一遍播放一遍观察网络请求，发现了一些“不对劲”的地方。它首先发起第一个请求，会在request headers中包含range: bytes=0-1，同时reponse headers中包含accept-ranges: bytes，同时HTTP请求的Status Code为206，不是正常的200。

继续播放的过程中，又以同样的URL重新发起了多次请求，request headers中Range的参数值有所变化，看起来像是文件下载时分片下载、断点续传的思路，只不过这里是将视频文件一段一段地下载。

到这里，基本能够理解大概的思路了：

第一次请求时，请求头中发送range: bytes=0-1实际上是一次“试探”，后台服务收到请求后通过accept-ranges: bytes告诉客户端此文件是什么、大小是多少、能够支持文件内容部分下载。客户端收到信息后，就可以计算好每一次bytes的范围，一段一段地去下载文件内容；同时服务端也根据后续请求头中的range: bytes=start-end，将文件指定范围的bytes返回给客户端。重复这个步骤，直至整个视频文件下载完毕。

4.具体实现

不错，思路终于理清楚了，那么怎么实现这个逻辑呢？

前端播放器在发起第一个请求后，就要计算下一次想要下载文件的bytes范围，并且播放到一定进度的时候，还要继续发起新的请求，这里面猜想估计比较复杂，而且还涉及到视频解析相关的知识，由于能力有限，就不研究视频播放器是怎么处理这些逻辑的了。

把关注点放在后台服务的处理上！仔细研究了一下file_stream这个函数，其实它已经支持了按Range范围获取文件内容

async def file_stream(
    location: Union[str, PurePath],
    status: int = 200,
    chunk_size: int = 4096,
    mime_type: Optional[str] = None,
    headers: Optional[Dict[str, str]] = None,
    filename: Optional[str] = None,
    chunked="deprecated",
    _range: Optional[Range] = None,
) -> StreamingHTTPResponse:
    """Return a streaming response object with file data.

    :param location: Location of file on system.
    :param chunk_size: The size of each chunk in the stream (in bytes)
    :param mime_type: Specific mime_type.
    :param headers: Custom Headers.
    :param filename: Override filename.
    :param chunked: Deprecated
    :param _range:
    """
    if chunked != "deprecated":
        warn(
            "The chunked argument has been deprecated and will be "
            "removed in v21.6"
        )

    headers = headers or {}
    if filename:
        headers.setdefault(
            "Content-Disposition", f'attachment; filename="{filename}"'
        )
    filename = filename or path.split(location)[-1]
    mime_type = mime_type or guess_type(filename)[0] or "text/plain"
    if _range:
        start = _range.start
        end = _range.end
        total = _range.total

        headers["Content-Range"] = f"bytes {start}-{end}/{total}"
        status = 206

    async def _streaming_fn(response):
        async with await open_async(location, mode="rb") as f:
            if _range:
                await f.seek(_range.start)
                to_send = _range.size
                while to_send > 0:
                    content = await f.read(min((_range.size, chunk_size)))
                    if len(content) < 1:
                        break
                    to_send -= len(content)
                    await response.write(content)
            else:
                while True:
                    content = await f.read(chunk_size)
                    if len(content) < 1:
                        break
                    await response.write(content)

    return StreamingHTTPResponse(
        streaming_fn=_streaming_fn,
        status=status,
        headers=headers,
        content_type=mime_type,
    )

只不过在参数的传递上，缺少了_range，所以一开始的做法永远只会一次下载整个文件。那么只要从request headers中获取range，然后构造_range作为参数传递给file_stream函数，那么此函数中if _range:这部分逻辑就能够正常执行，每次请求时就会获取指定范围的bytes，而不是整个文件了，同时response header也包含了预期的信息。

最终，后台服务代码调整如下，同样省略查找文件路径相关的代码：

from sanic.handlers import ContentRangeHandler
from sanic.response import file_stream
from sanic.compat import stat_async

bp = Blueprint('videos', url_prefix="/videos")

@bp.route('/<video_id>', methods=["GET"])
async def video(request, video_id):
    # get the video location with video_id
    file_path = '/path/to/file'
    stats = await stat_async(file_path)
    _range = ContentRangeHandler(request, stats)
    return await file_stream(file_path, _range=_range)

到这里为止，用自己的后台服务提供的URL进行播放，效果基本与示例的效果一样了。

5.再次优化

那么，现在就优雅地实现了视频播放吗？并没有！

上面的处理中，后台服务的逻辑是根据video_id去服务器本地目录查找文件，这显然是不符合实际情况的。文件存储的方案通常不会选择直接存储在服务器本地，而是选择一些对象存储的服务。

所以上面的代码中提及的查找文件路径，再获取文件内容的逻辑就需要调整了。如此一来，file_stream这个函数就无用武之地了，因为它支持按路径读取本地文件。

不过呢，虽然不能直接使用file_stream，咱们依然可以参照它的处理方式，按照请求头中指定的文件bytes范围，从对象存储获取相应的部分文件并返回，而不是从本地路径读取文件。

这部分代码实际上将file_stream稍作调整就完成，这里就不贴出来了，有兴趣的可以动手实践一下！

6.总结

实现一个支持分段缓冲的视频播放功能，主要工作在于发起请求时，在request headers中携带Range属性，告知服务器想要获取的部分文件，服务器在接收到请求后获取Range中指定的范围，按这个范围返回文件内容。

本文中请求相关的处理，视频播放器已经帮我们做了，而后台服务相关的逻辑，web框架也提供了一些支持，也就是file_stream这个函数，尽管只支持读取服务器本地文件。如果选择使用其他编程语言和web框架，也可以参考这部分代码自己来实现。