Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

HTTP 的 Upgrade 机制

  规范的 http2 并没有限定必须是 https,但是 http2 的请求头格式和 http 1.x 并不一样,而且 TCP 又没有 TLS 那样的 NPN、ALPN 之类的协议协商机制,那有怎么办呢?基于 http 1.x 的 Upgrade 机制也是可以实现协议切换的。虽然不如 NPN 那样纯粹,但也是个能用的方案。
  其实我们很早以前就在用 Upgrade 机制了,当时是解决 WebSocket 的握手而使用的 Upgrade。而且 Upgrade 这个机制是在 RFC 2616 中就定义的,而且更讽刺的是当时的例子就是 Upgrade 到 HTTP/2.0(那个年代我差不多还在上小学二年级)。
  Upgrade 机制确实在某种意义上和 NPN 异曲同工,它解决的问题也是协商下一个协议该用什么。但 Upgrade 机制的问题是基于 HTTP,服务器响应 101 状态码后才算完成,这一来一回又浪费了一次同步网络通信的时间。一些奇怪的应用场景中会出现 https + Upgrade 这样诡异的东西。比如 wss(WebSocket Security),我猜也许将来 WebSocket 也可以直接走 ALPN 之类的东西来协商协议,而不再依赖于 HTTP 的 Upgrade 升级机制。
  http 2 已经把 Upgrade 这东西干掉了,因为协议协商本来就不应该由应用层来做。将来如果 TLS 成为主流,那么 ALPN 才是更好的解决方案。而且 Upgrade 的设计理念并不好,所以我觉得现在已经不需要再纠结这个了。
  虽然 http 2 在可以通过 http/1.1 的 Upgrade 机制来实现,但这也仅仅是理论上的而已。目前浏览器还都不支持非 TLS 的 http 2 呢,这才是将来的潮流。而且即使没有 ALPN 和 Upgrade,服务器自己去尝试解析 http2 的头(http2 有个辨识度很高的 24 字节 preface 头),发现不对再切换回 HTTP也是可以实现的。
网名:
54.196.182.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^