为什么B站视频已经播放过了，再拉回时还需要重新加载？

流媒体本来就不是必须要磁盘缓存的，占点儿内存当缓冲区就行。

至少二十多年前，一些流媒体点播平台，就在用rtsp协议进行流媒体传输了。

而rtsp就是不在磁盘上进行缓存的。

后来，flash+flv的方案普及后，带磁盘缓存的才一度成了主流。

至于原因，有几个方面吧。

1，为了降低部署成本，流媒体传输协议使用的是http，而http，别管是200的，还是201的，都是可以建立临时文件的，但注意！是“可以”！这并不是必须！

2，可以在某些使用场景下，降低服务端压力。

注意，只是某些使用场景下。比如把进度条往后拖，或者快进到已经缓存完的部分。由于可以直接访问本地磁盘的数据，就不需要再向服务器发送请求了。

3，当年用户的内存还是比较值钱的，视频播放时的缓冲区都不大，当时播放视频的缓冲区只有几百KB，稍微来一点儿网络波动，可能就卡顿了，等待缓冲了。所以就要未雨绸缪，在网络状况理想时，就有必要多接收一些响应数据，以应对可能会到来的网络波动。

而多接收数据，都放入内存作缓冲区，在当时是不现实的。因为当时的内存贵啊，许多人家只用得起256M的，根本放不下。这时候，磁盘缓存就是最理想的方案了。

而现如今呢？

哪怕不用rtsp之类的第三方传输协议，只靠http及在其基础上设计的hls+m3u8方案，也能实现不进行磁盘缓存了。

因为可以在服务端把一个较长的视频进行切片，然后把这些切片的地址放进M3U8列表。

客户端根据M3UB，播放到哪个切片了，就请求哪个切片。

看似请求次数变多了，似乎对服务器压力会增大一些。

但它解决了一个非常实际的问题，就是对文件数据流进行查找时，偏移量越大，耗时越长。

说人话就是，你把进度条拖的越往后，服务端就需要越长的时间来“倒带”。

而把长视频的大文件，切片成小文件，可以非常有效的解决这个问题。

毕竟对于服务器来说，相比于多几次请求次数，IO负载才是更可怕的。

另外，切片后，每个文件的尺寸都不大，如今的内存也不像当年那么之前了。

完全可以把整个一段切片都放进内存作缓冲区。

如今内存够大，还可以多请求几个切片放入缓冲区，以对抗网络波动。

再说，如今带宽大了，轻微的网络波动不会有太大影响了。

如此一来，上面提到的三点原因，都可以用HLS+M3U8方案来解决了。

就可以不要磁盘缓存了。