首先我之前的做法是，请求一个视频链接，然后无脑返回一整个视频文件。
对于chrome没有问题，只能说chrome兼容性做得比较好，并不是说视频传输协议就可以这样。
而对于safari来说，他不是一次性请求全部文件的（不论osx还是ios），一般首先会请求0-1字节，这个写在request header的"range"字段中：
range:'bytes=0-1'
如果是想要传输视频，必须要解析range字段，然后按照range字段的要求返回对应的数据，同时response header至少要包含三个字段："Content-Type", "Content-Range", "Content-Length"
"Content-Type"必需明确指定视频格式，有"video/mp4", "video/ogg", "video/mov"等等，网上可以查到。
"Content-Range"格式是 "bytes <start>-<end>/<total>"，其中start和end必需对应request header里的range字段，total是文件总大小，不是返回的数据长度
"Content-Length"指定返回的二进制长度
然后有几个坑：
1.chrome有时候会一次性请求全部内容，range是这样的 'bytes=0-'，解析的时候需要注意
2.所有的end是指inclusive end，意味着文件长度如果是245，返回"Content-Range"就是"bytes 0-244/245"，错一点视频就放不出来了（包括chrome）
思考为什么safari行为不一样：
既然视频传输协议就是这么规定的，当然应该按照规定的来，偷懒没有任何借口。
但是safari之所以分多次请求也有深层次原因。比方说先请求0-1字节（其实是2个字节），返回的时候数据并不多，但是可以通过分析"Content-Range"来获取文件总长度。然后分段请求，比如请求第一帧来渲染thumb nail等等。这样做有个好处就是，只有当用户点击播放了才请求完整文件，对于PC还好，对于手机这类数据传输需要收费的设备来说，必须要节省流量。
另外在iphone上chrome也用的是apple提供的内核，导致他们的行为基本上一致。（这是苹果的规定）
还不好使前端加（ url后加enableWK=YES 开启WKWebview
ap.pushWindow({
url: './troubleDetail.html?enableWK=YES',
});
）
这里有一些参考资料：
使用nodejs作为后端返回视频，http://cnodejs.org/topic/540037249769c2e93703c36c
使用video标签作为前端获取视频，http://www.w3school.com.cn/tiy/t.asp?f=html5_video_all