简述 HTTP 协议中的 Conditional Request

01

Condition Request

Condition Request 后文简称CR， 是在HTTP请求中，加入特定的header， 得以在真正执行请求前可以增加一些条件判断（先决条件）。

总体上说，CR的先决条件基于目标资源（GET请求要获取的资源，PUT等要更新的资源，即Resource， 想想REST）的状态， 目标的状态会影响请求的结果。

对于安全（safe）的请求， 如GET， 在获取资源的时候，可以预设条件，满足条件再返回Resource，可以减少不必要请求返回Resource的资源浪费的情况。

对于非安全（unsafe）请求， 如PUT， 更新资源， 上传文件，在多线程的场景下可以作为乐观锁，根据目标资源和本地资源的“版本“来判断是否真正执行update操作。

02

强弱验证

CR Headers的判断起点是目标resouce是否匹配header中指定的”版本“。

带宽资源一般是”珍贵的“， 进而判断资源版本是否一致一般不会通过直接对比Resource， 而是需要一个属性来表征resource的”版本“， 这个属性就是Validators。

Validators的两种类型：

a)根据更新时间标记： last-modified；

协议中定义为：

b)根据版本id标识：etag

协议中定义为：（ 仔细看看构成，后面有问题。 ）

根据Validators的验证强度，分为”强验证（Strong validator）“和“弱验证（Weak validator）”

强验证 ：对比资源的一致性， 通常情况下（协议中没有定义MUST， SHOULD，等关键字， 参考https://tools.ietf.org/html/rfc2119），每一次的资源变动会改变资源的”版本“，有一定性能损耗。一般用在cache验证、范围请求（如断点续传， 参考Range Request https://tools.ietf.org/html/rfc7233）， 更新覆盖（lost update）等。

弱验证 ：协议中列举了几类可以弱验证的场景， 比如

a) 天气预报（理论上数值是实时变化的）， 但是为了保证cache的有效性（权衡资源的实时性和系统性能），不会实时更新cache；

b) 更新时间作为标记（假设以秒为精度）， 1秒之间可能有多次修改；

c) 定制场景， 取决于版本的计算法方式，类似以 java 中的重写equals方法来判断object是否相等，比如资源变更后，attribute2有了变化，

变更后

在计算版本的id时， 如果只考虑name，attribute，他们相同就判定为相同。

简单说来， 如果多个”修改的“资源可能共享统一版本，（判断为资源一致），那么就是弱一致性。

从强弱校验的角度Http协议给出了说明：

第一行强验证为什么为”no match“， 参照Http协议RFC2626中Etag的定义，作为读者的思考吧：)

03 

Http中的Preconditon Header Field

协议中指出， 使用如下header的请求即为Conditional， 根据名字很容易理解。

a）If-Match
b）If-None-Match
c）If-Modified-Since
d）if-Unmodified-since
e）if-Range, 通过匹配Range Request的部分，来获取整个entity（200 response 而不是206 Partial content）。

04 

应用场景

a）Cache更新

比较典型的一个应用场景， 如果没有缓存，缓存为空，会返回Resource和Validators（200 OK）

缓存为失效，不会发起任何请求，直接使用缓存， 如果失效则发起条件请求（使用Preconditon Header Field）。

资源未变化， 返回304 Not Modified并刷新缓存

资源变化， 返回200 OK，使用新资源并更新缓存

b）断点续传（partial request）

HTTP协议中定义了Partial Request， 用来对资源进行切割，分批请求，

获取Resource，

资源会广播具备Partial Request的能力（Accept-Range）， 然后根据range进行请求资源

一旦过程中资源发生了变化，获取文件就corrupted， 为了避免，在Preconditon Header Field的控制下，会返回412 Precondition Failed，然后客户端可以再次发起请求。

未了减少请求次数（上例为2个）， 使用If-Range， 在资源变更后直接返回新资源的版本

c）乐观锁

客户端更新场景一般是读取数据，更新数据如下

实际应用中，多线程的场景，多用的情况下，经常会发生的一个情况是，用户A获取了资源（R1_V1.1），正在做更新，在没有提交（PUT）到服务器前，用户B也获取了资源(R1_V1.1），本地更新，然后A提交了更新，这时服务器资源已经变成了（R1_V1.2）， 用户B本地还是在基于R1_V1.1进行更新提交服务器，这时会覆盖（R1_V1.2）， 资源版本编程R1_V1.3。

为了解决上诉竞态条件（Race Condition）的问题，使用乐观锁（OLA），在上诉场景中， 如果B在提交资源更新的时候发现提交版本（If-Match指定）不匹配时，返回412 Precondition Failed。

最后根据协议， 不同的CR，执行逻辑图如下

参考：

1. https://tools.ietf.org/id/draft-fielding-httpbis-http-conditional-00.html#rfc.section.2.4

2. https://developer.mozilla.org/en-US/docs/Web/HTTP/Conditional_requests

3. https://tools.ietf.org/html/rfc2616

THE END

- 晚安 -

图片长按2秒，关注订阅号