HTTP其他

如何实现断点上传

要实现断点续传的功能，通常都需要客户端记录下当前的下载进度，并在需要续传的时候通知服务端本次需要下载的内容片段
HTTP1.1协议（RFC2616）中定义了断点续传相关的HTTP头Range和Content-Range字段,一个最简单的断点续传实现大概如下:
1.客户端下载一个1024K的文件，已经下载了其中512K
2.网络中断，客户端请求续传，因此需要在HTTP头中申明本次需要续传的片段：
Range:bytes=512000-
这个头通知服务端从文件的512K位置开始传输文件
3.服务端收到断点续传请求，从文件的512K位置开始传输，并且在HTTP头中增加：
Content-Range:bytes 512000-/1024000
并且此时服务端返回的HTTP状态码应该是206，而不是200。
但是在实际场景中，会出现一种情况，即在终端发起续传请求时，URL对应的文件内容在服务端已经发生变化，此时续传的数据肯定是错误的。如何解决这个问题了？显然此时我们需要有一个标识文件唯一性的方法。在RFC2616中也有相应的定义，比如实现Last-Modified来标识文件的最后修改时间，这样即可判断出续传文件时是否已经发生过改动。同时RFC2616中还定义有一个ETag的头，可以使用ETag头来放置文件的唯一标识，比如文件的MD5值。
终端在发起续传请求时应该在HTTP头中申明If-Match 或者If-Modified-Since 字段，帮助服务端判别文件变化。另外RFC2616中同时定义有一个If-Range头，终端如果在续传是使用If-Range。If-Range中的内容可以为最初收到的ETag头或者是Last-Modfied中的最后修改时候。服务端在收到续传请求时，通过If-Range中的内容进行校验，校验一致时返回206的续传回应，不一致时服务端则返回200回应，回应的内容为新的文件的全部数据

如何判断消息的传输长度

优先级:

任何不含有消息体的消息（1XXX、204、304等响应消息和HEAD请求的响应消息),总是由一个空行（CLRF）结束
如果出现了Transfer-Encoding头字段并且值为非“identity”，那么transfer-length由“chunked” 传输编码定义，除非消息由于关闭连接而终止。
如果没有出现Transfer-Encoding但是有Content-Length头字段，按照Content-Length。如果Transfer-Encoding和Content-Length同时出现，忽略Content-Length
如果消息使用媒体类型“multipart/byteranges”，并且transfer-length 没有另外指定，那么这种自定界（self-delimiting）媒体类型定义transfer-length 。除非发送者知道接收者能够解析该类型，否则不能使用该类型。
由服务器关闭连接确定消息长度

为了兼容HTTP/1.0应用程序，HTTP/1.1的请求消息体中必须包含一个合法的Content-Length头字段，除非知道服务器兼容 HTTP/1.1

Http Pipelining(HTTP管线化)

默认情况下HTTP协议中每个传输层连接只能承载一个HTTP请求和响应，浏览器会在收到上一个请求的响应之后，再发送下一个请求
在使用持久连接的情况下，某个连接上消息的传递类似于请求1 -> 响应1 -> 请求2 -> 响应2 -> 请求3 -> 响应3。 HTTP Pipelining（管线化）是将多个HTTP请求整批提交的技术，在传送过程中不需等待服务端的回应
使用 HTTP Pipelining 技术之后，某个连接上的消息变成了类似这样请求1 -> 请求2 -> 请求3 -> 响应1 -> 响应2 -> 响应3。注意下面几点：

管线化机制通过持久连接（persistent connection）完成，仅 HTTP/1.1 支持此技术（HTTP/1.0不支持）
只有 GET 和 HEAD 请求可以进行管线化，而 POST 则有所限制
初次创建连接时不应启动管线机制，因为对方（服务器）不一定支持 HTTP/1.1 版本的协议
管线化不会影响响应到来的顺序，如上面的例子所示，响应返回的顺序并未改变
HTTP /1.1 要求服务器端支持管线化，但并不要求服务器端也对响应进行管线化处理，只是要求对于管线化的请求不失败即可由于上面提到的服务器端问题，开启管线化很可能并不会带来大幅度的性能提升，而且很多服务器端和代理程序对管线化的支持并不好，因此现代浏览器如 Chrome 和 Firefox 默认并未开启管线化支持