用AI赚第一桶💰低成本搭建一套AI赚钱工具,源码可二开。 广告
# 5. http2的基本概念 http2到底做了些什么呢?到多远才是HTTPbis小组工作的界限? 事实上,http2的界定非常严格,让小组的工作颇为掣肘。 - [X] 它必须维持HTTP的范式。毕竟它只是一个让客户端发送请求到服务器的基于TCP的协议。 - [X] 不能改变`http://`和`https://`这样的URL,也不能对其添加新的结构。使用这类URL的网站太多了,没法指望他们全部改变。 - [X] HTTP1的服务器和客户端依然会存在很久,所以我们必须提供HTTP1到http2服务器的代理。 - [X] 随后,我们也要让这种代理能够将http2的功能一对一的映射到HTTP 1.1的客户端。 - [X] 删除或者减少协议里面那些可选的部分。虽然这并不是一个大的需求,但是SPDY和Google的团队会非常喜欢这点。让协议里所有部分都成为强制要求的,就能防止人们在实现的时候偷懒,从而避免将来的问题。 - [X] 不再使用小版本号。服务器和客户端都必须确定自己是否完整兼容http2或者彻底不兼容。如果将来该协议需要被扩充更变,那么新的协议将会是http3,而不是http 2.x。 ## 5.1. http2和现有的URI结构 如前所述,现有的URI结构正在被HTTP 1.x使用而不能改变,所以http2也必须沿用该结构。正因如此我们才必须找到一种方式将协议升级至http2,或者让服务器使用http2来彻底替代旧的协议。 HTTP 1.1本身就有制定“升级”的方案:提供一个头,让服务器在收到旧协议请求的时候,向客户端发送新协议的响应。这样做的代价是需要一次往返通信。 这个往返通信的代价是SPDY团队不能接受的。因为他们只实现了基于TLS的SPDY,所以他们也只开发了一个TLS的扩展来简化协议的协商。这个扩展被称作NPN(Next Protocol Negotiation),通过它,服务器通知客户端所有他支持的协议,从而让客户端从中选择一个合适的。 ## 5.2. 为`https://`所准备的http2 足够的关注使得http2在TLS上得以正常运作,SPDY只支持TLS,所以按理说TLS也应成为http2 必需的组件,但出乎意料的是http2仅将TLS作为可选部分。然而,全球两大浏览器领导者 - Firefox和Chrome明确地表示,他们只实现基于TLS的http2. 只选择TLS的原因包括了保护用户隐私,早期的评估结果表明,将新的协议建立在TLS上更可能成功。这也是因为所有来自80端口的流量都会被当作HTTP 1.1或者是其某个变种,而不是另外一个种全新的协议。 关于是否该强制使用TLS的主题在邮件组和会议上引起了不小的争议 - 这到底是好是坏呢?不管怎么样,对于这种备受争议的话题请谨慎讨论,尤其是当你面对一个HTTPbis小组成员的时候。 类似地,还有一个激烈而长期的辩论,即当使用TLS时http2是否应该强制规定密码列表,或者应该建立一个黑名单,或者它根本就不需要从TLS层得到任何东西,而由TLS工作组来解决。最后规范指定TLS最低版本是1.2,并且有加密组的限制。 ## 5.3 基于TLS之上的http2协商 Next Protocol Negotiation (NPN)是一个用来在TLS服务器上协商SPDY的协议。IETF将这个非正式标准进行规范,从而变成了ALPN(Application Layer Protocol Negotiation)。ALPN被推广用于http2,而SPDY客户端和服务器仍然使用NPN。 由于NPN先诞生,而ALPN还经历了一些标准化过程。所以许多早期的http2客户端和服务器在协商http2时同时实现了这两者的扩展。并且,由于SPDY使用NPN,不少服务器同时提供SPDY和http2来支持NPN和APLN。 ALPN和NPN的主要区别在于谁持有会话协议的决定权,ALPN是由客户端给服务器发送一个协议优先级列表,由服务器最终选择一个合适的。而NPN则正好相反,是客户端有最终决定权。 ## 5.4 为`http://`所准备的http2 如前所述,对于纯文本的HTTP1.1来说,协商http2的方法就是给服务器发送一个带**升级**头部的报文。如果服务器支持http2,它将回复“101 Switching”状态码,并从此开始在该连接上使用http2。也许你很容易就发现这个升级流程会造成一个完整的往返时延开销,但好处是http2连接相比HTTP1可以被更大限度地重用和保持。 虽然有些浏览器厂商的发言人宣称他们不会实现这种http2会话方式,但IE团队已公开表示他们会实现,与此同时,curl已经支持该方式。