HTTP 内容协商机制
指客户端和服务端就响应的资源内容进行交涉，然后提供给客户端最为合适的资源。
内容协商会以响应资源的语言，字符，编码方式等作为判断的基准
客户端驱动
客户端发起请求，服务器发送可选项列表，客户端做出选择后在发送第二次请求
服务端
服务器检查客户端的请求头并决定提供哪个页面的版本
透明协商
某个中间设备(通常是缓存代理)代表客户端进行协商
服务器驱动内容协商 请求头
Accept:告知服务器发送何种媒体类型
Accept-Language：告知服务器发送何种语言 对应Content-Language
Accept-Charset： 告知服务器发送何种字符集 对应Content-Charset
Accept-Encoding: 告知服务器采用何种编码 对应Content-Encoding
服务器驱动内容匹配
Accept-Language：en;q=0.5,fr;... q从0~1，表示可接受范围
服务器有默认值，即便没有默认偏好，那也会有默认值
实际使用场景不会很多，但是对于大公司的国际化很重要
用的最多的是language
断点续传和多线程下载
HTTP是通过在Header里两个参数实现的
客户端发请求时对应的应该是Range,服务端响应时对应的是Content-Range
如果续传成功返回206
如果文件有变动返回200和新文件的内容
Range
用于请求头，指定第一个字节的位置和最后一个字节的位置
一般格式：
Range:(unit=first byte pos)-[last byte pos]
如：
Range: bytes=0-499
Range: bytes=500-999
Range: bytes=-500 0-599下载
Range: bytes=500-从500字节开始到文件结束部分的内容
Range: bytes=500-600,601-999 即从500-600，又从601-999下载，分成两块下载
响应头 Content-Range
用于响应头中，在发出带Range的请求后
服务器会再Content-Range头部返回当前接受的范围和总文件大小
一般格式：
Content-Range:bytes(unit first byte post) - [last byte post] / [entity length]
响应完成：
HTTP1.1 200 OK （不使用断点续传）
HTTP1.1 206 Partial Content(使用断点续传方式)
完整断点续传过程
- 客户端下载一个1024K文件，已经下载了其中512K
- 网络中断，客户端请求续传，因此需要在HTTP头部中声明本次需要续传的片段：Range：bytes=512000-这个请求头通知服务端从文件的512K开始传输文件
- 服务器端接收到断点续传请求，从文件的512K位置开始传输，并且在HTTP头中增加
Content-Range:bytes 512000 -/ 1024000
并且此时服务端返回的HTTP状态码应该是206，而不是200
断点续传是被动的分片，多线程下载是主动的分片下载
