扩展

由 lqx554924976 创建, 最后一次修改 2016-02-24

7. 扩展

协议强制规定接收方必须读取并忽略掉所有未知帧类型的帧。双方必须在逐跳原则(hop-by-hop basis)基础上协商使用新的帧,这些帧的状态无法被改变,并且也不受流控制。

是否应该允许添加扩展的这个话题在制定http2协议的时候被反复讨论了很久。在draft-12之后,最终确定允许添加扩展。

但扩展不再是协议本身的一部分,它被记录在核心协议规范之外。到目前为止,有两种曾被http2工作组包含在协议里的帧,很可能率先被纳入协议的扩展部分。这两个曾被当作“原生”的帧非常流行,所以接下来我会详细讨论它们。

7.1. 备选服务(Alternative Services)

随着http2逐渐被接受,我们有理由猜测,相对于HTTP 1.x,TCP连接会更长且被保持的更久。对客户端来讲,最好是到每个主机/站点的每一条连接都可以做尽可能多的事情,这也需要每个连接保持开启更长的时间。

但这会影响到HTTP负载均衡器的正常工作,比如在一个网站想建议客户端连接到另外一个主机的时候。通常,网站此举的目的在照顾性能,但也可能是正常维护或类似原因。

服务器将会通过发送Alt-Svc头(或者http2的ALTSVC帧)来告知客户端另一个备选服务。即另外一条指向不同的服务源、主机或端口,但却能获取同样内容的路由。

客户端可以尝试异步的连接到该服务,或者可用的话就选择备选方案。

7.1.1. 机会型TLS(Opportunistic TLS)

Alt-Svc头部允许服务器通过http://告诉客户端:同样的内容也可以通过TLS连接来获取。

这是个还在讨论中的功能。这样的连接会导致未认证的TLS,并且在任何地方也不会被广播为“安全”,同时不会在客户端界面上出现任何锁标识,所以没法让用户知道这其实不是常规的HTTP连接。这就是很多人强烈反对机会型TLS的原因。

7.2. 阻塞(Blocked)

当有数据需要被发送,但流控制却禁止发送任何数据时,此类型的帧将会被发送一次。这种帧设计的目的在于,如果你接收到了此帧,那么连接中必然有错误发生或者是得到了低于期望的传输速度。

在此帧被放到协议扩展部分之前,draft-12中的一段话:

阻塞帧被包含在此版本的草案中作为实验,如果没有得到良好的反馈,就把它删除。

以上内容是否对您有帮助:
二维码
建议反馈
二维码