成熟的媒体应用往往面对这样的需求：
- 自定义封装的视频
- 加密的音视频
- 对接第三方的非标准媒体源
- 支持不同架构的播放器
- ……
其中一种比较灵活的解决方案是把自定义媒体数据推流为http，而大部分播放器都能很好地支持http（vlc/ffmepg/mediaplayer/ijkplayer/kodi等）。
数据流示意：
本篇文章主要讲解上图的http协议部分。
http协议基础
http协议是应用层协议，使用tcp进行传输。
请求报文是播放器(http客户端)发给http服务器的内容，由请求方法、请求URI、协议版本、可选的请求首部字段和内容实体构成，如：
POST /media HTTP/1.1
Host: 127.0.0.1:8000
Content-Type: application/x-www-form-urlencoded
Content-Length: 10
path=/tmp/1.mp4
第1行包含了请求方法、请求URI、协议版本，第2~4行是请求首部字段，最后一行是内容实体。
响应报文由协议版本、状态码、状态码原因短语、可选的响应首部字段和实体主体构成，如：
HTTP/1.1 200 OK
Content-Length: 53
Content-Type: text/html
<html>
...
第一行包含了协议版本、状态码、状态码原因短语，第2~3行是响应首部字段，最后几行是主体，也就是通常浏览器要渲染的内容
流媒体 - http chunk
流媒体就是像流水一样把视频数据通过网络传输到终端上播放。
通过http推送流媒体的时候，对应的是http的chunk传输。
chunk传输的典型（响应）报文如下：
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Content-Type: video/mpeg
400
...ad....fxa...
...
400
xai..
...
0
即，通过Transfer-Encoding: chunked告知客户端现在传输的是分块数据，这样客户端就会维持这个连接，直到数据接收完成。
数据传输过程中，每个chunk都是以大小\r\n数据\r\n的格式传输，最后以大小0通知客户端数据完成。
流传输在多媒体应用中常用于直播，因为直播的数据长度一般是不定的，这样就可以借助客户端和服务端间的这个长连接持续不断地传输媒体数据。
文件媒体 - http range
流媒体的缺点是不能跳进。
不能跳进不仅意味着用户无法seek观看节目，也意味着一些节目的信息无法获取(如时长)。
为了支持跳进，可以借助http的range请求。
range请求常以断点续传闻名，它允许客户端从任何位置开始，向服务器请求任意长度的数据。
比如：
POST /media HTTP/1.1
Host: 127.0.0.1:8000
Content-Type: application/x-www-form-urlencoded
Content-Length: 10
Range: bytes=500-1000
path=/tmp/1.mp4
这个请求报文通过Range向服务器请求了第500~1000字节的数据(共501字节，第一个字节是索引0)
服务器如果能正确返回这部分数据，就回复：
HTTP/1.1 206 OK
Content-Length: 53
Content-Type: video/mpeg
Accept-Ranges: bytes
Content-Range: bytes 500-1000/1024
Content-Length: 501
....
Accept-Ranges:bytes意思是接收按字节为单位进行range请求；Content-Range告诉客户端返回的数据对应的是哪个范围的数据，这里回复的是客户端请求的500-1000，其中1024是整个媒体的数据长度；Content-Length表示返回的数据长度(1000-500+1 = 501)
所以，一般播放器在播放http源的时候要进行seek就是通过发起新的http请求，并在请求中加入Range字段来从seek的目标位置读取数据。
然而，实际情况会复杂一些。
其一，播放器可能会在开始播放的时候就会跳转到尾部读取视频数据，以确定节目时长(比如ts封装就需要读取尾部数据来估算视频时长)；
其二，seek可能需要经过多次range请求才能跳转到目标位置(如ffmpeg会用二分查找来查找目标时间点)；
其三，http是无状态的，所以每次客户端来的请求所在的处理线程不一定相同，而且同次点播的多个http请求间是无关联的。这对于静态文件资源而言是无关紧要的，但对于动态内存资源（如动态解密的视频）而言就需要谨慎处理多线程问题和session管理了。
点播管理 - http session
上节了解过，seek基于多次range request的实现机制会导致在一次点播期间，服务端与客户端间会有多次的通信，而http的无状态特性导致这几次通信是无关联的，服务器无从知道这几次通信对应的是同一次点播。
通用的解决方法是利用http的cookie机制，在多次通信中携带id字段进行session关联。示意图如下：
对应于http报文则是：
"第一次通信"：
POST /media HTTP/1.1
Host: 127.0.0.1:8000
Content-Type: application/x-www-form-urlencoded
Content-Length: 10
Range: bytes=0-
path=/tmp/1.mp4
"你的id是123"：
HTTP/1.1 206 OK
Content-Length: 53
Content-Type: video/mpeg
Accept-Ranges: bytes
Content-Range: bytes 0-1023/1024
Content-Length: 1024
Set-Cookie: id=123
....
"我的id是123，Range 500-1000":
POST /media HTTP/1.1
Host: 127.0.0.1:8000
Content-Type: application/x-www-form-urlencoded
Content-Length: 10
Range: bytes=500-1000
Cookie: id=123
path=/tmp/1.mp4
"你的id是123，你的请求已受理"：
HTTP/1.1 206 OK
Content-Length: 53
Content-Type: video/mpeg
Accept-Ranges: bytes
Content-Range: bytes 500-1000/1024
Content-Length: 501
Set-Cookie: id=123
....
上面通信过程主要依赖Set-Cookie和Cookie两个字段保证。协议也很简单，服务端通过Set-Cookie给客户端发送id=123，客户端识别如果有Set-Cookie，则在下次请求中把Set-Cookie的内容放到Cookie中通知回服务端。
上述基本就是完成http推流所需要的核心协议了。总结下：
- http传输基于tcp，是可靠连接
- 传输流媒体可以使用chunk传输
- 为支持seek，需要支持range请求
- seek实现中，如果服务端资源是动态的，需要通过cookie引入session机制
我们将在http推流设计与实现这篇文章中介绍xport，详解如何自己动手实现一个http推流框架。
更多精彩文章，请关注我的知乎：https://www.zhihu.com/people/compilelife/activities
