一文带你了解 HTTP 黑科技(13) _HTTP

文章插图

支持断点续传的服务器通过发送 Accept-Ranges 标头广播此消息，一旦发生这种情况，客户端可以通过发送缺少范围的 Ranges标头来恢复下载

文章插图

这里你可能有疑问 Ranges 和 Content-Range是什么，来解释一下
Range
Range HTTP 请求标头指示服务器应返回文档指定部分的资源，可以一次请求一个 Range 来返回多个部分，服务器会将这些资源返回各个文档中。如果服务器成功返回，那么将返回 206 响应；如果 Range 范围无效，服务器返回416 Range Not Satisfiable错误；服务器还可以忽略 Range 标头，并且返回 200 作为响应。
Range: bytes=200-1000, 2000-6576, 19000-还有一种表示是
Range: bytes=0-499, -500 它们分别表示请求前500个字节和最后500个字节，如果范围重叠，则服务器可能会拒绝该请求。
Content-Range
HTTP 的 Content-Range 响应标头是针对范围请求而设定的，返回响应时使用首部字段 Content-Range ，能够告知客户端响应实体的哪部分是符合客户端请求的，字段以字节为单位。它的一般表示如下
Content-Range: bytes 200-1000/67589 上段代码表示从所有 67589 个字节中返回 200-1000 个字节的内容
那么上面的 Content-Range你也应该知道是什么意思了
断点续传的原理比较简单，但是这种方式存在潜在的问题：如果在两次下载资源的期间进行了资源更新，那么获得的范围将对应于资源的两个不同版本，并且最终文档将被破坏。
为了阻止这种情况的出现，就会使用条件请求。对于范围来说，有两种方法可以做到这一点。一种方法是使用 If-Modified-Since和If-Match ，如果前提条件失败，服务器将返回错误；然后客户端从头开始重新下载。

文章插图

即使此方法有效，当文档资源发生改变时，它也会添加额外的响应/请求交换。这会降低性能，并且 HTTP 具有特定的标头来避免这种情况 If-Range 。

文章插图

该解决方案效率更高，但灵活性稍差一些，因为在这种情况下只能使用一个 Etag 。
通过乐观锁避免丢失更新Web 应用程序中最普遍的操作是资源更新。这在任何文件系统或应用程序中都很常见，但是任何允许存储远程资源的应用程序都需要这种机制。
使用 put 方法，你可以实现这一点，客户端首先读取原始文件对其进行修改，然后把它们发送到服务器。

文章插图

上面这种请求响应存在问题，一旦考虑到并发性，事情就会变得不准确。当客户端在本地修改资源打算重新发送之前，第二个客户端可以获取相同的资源并对资源进行修改操作，这样就会造成问题。当它们重新发送请求到服务器时，第一个客户端所做的修改将被第二次客户端的修改所覆盖，因为第二次客户端修改并不知道第一次客户端正在修改。资源提交并更新的一方不会传达给另外一方，所以要保留哪个客户的更改，将随着他们提交的速度而变化；这取决于客户端，服务器的性能，甚至取决于人工在客户端编辑文档的性能。例如下面这个流程

文章插图

如果没有两个用户同时操作服务器，也就不存在这个问题。但是，现实情况是不可能只有单个用户出现的，所以为了规避或者避免这个问题，我们希望客户端资源在更新时进行提示或者修改被拒绝时收到通知。
条件请求允许实现乐观锁算法。这个概念是允许所有的客户端获取资源的副本，然后让他们在本地修改资源，并成功通过允许第一个客户端提交更新来控制并发，基于此服务端的后面版本的更新都将被拒绝。