内容协议机制、断点续传与多线程下载

内容协议机制

指客户端和服务器端就响应的资源内容进行交涉，然后提供给客户端最为合适的资源。内容协商会以响应资源的语言，字

符集，编码方式等作为判断的基准。

内容协商方式

客户端驱动

客户端发送请求，服务器发送可选项列表，客户端作出选择后在发送第二次请求

服务器驱动

服务器检查客户端的请求头部集并决定提供哪个版本的页面

透明协商

某个中间设备（通常是缓存代理）代表客户端进行协商

服务器驱动内容协商-请求首部集

Accept：告知服务器发送何种媒体类型

Accept-Language：告知服务器发送何种语言

Accept-Charset：告知服务器发送何种字符集

Accept-Encoding：告知服务器采用何种编码

Content-Type

Content-Language

Content-Type

Content-Encoding

服务器驱动内容协商-近似匹配

 

断点续传与多线程下载

HTTP是通过在Header里两个参数实现的，客户端发送请求时对应的是Range，服务器端响应时对应的是Content-Range

Renge

用于请求头中，指定第一个字节的位置和最后一个字节的位置

一般格式：

 

 

 

 

 Content-Range

用于响应头中，在发出带Range的请求后，服务器会在Content-Range头部返回当前接受的范围和文件总大小。

一般格式：

 

 而在响应完成后，返回的响应内容也不同：

HTTP/1.1 200 Ok（不使用断点续传方式）

HTTP/1.1 206 Partial Content（使用断点续传方式）

断点续传的过程

1、客户端下载一个1024K的文件，已经下载了其中512K

2、网络中断，客户端请求续传，因此需要在HTTP头中申明本次需要传输续传的片段：

Range：bytes = 512000-

这个头通知服务端从文件的512K位置开始传输文件

3、服务端收到断点续传请求，从文件的512K位置开始传输，并且在HTTP头中增加：

Content-Range：bytes 512000-/1024000

并且此时服务端返回的HTTP状态码应该是206，而不是200