>多路复用 – 单个TCP连接可用于发出多个HTTP / 2请求并接收多个响应(到单个来源)
> HTTP / 2服务器推送 – 向客户端发送服务器响应而不接收请求,即由服务器发起
>双向连接 – HTTP/2 spec – Streams and Multiplexing：
A “stream” is an independent, bidirectional sequence of frames
exchanged between the client and server within an HTTP/2 connection.
HTTP / 2背后的动机在这里解释HTTP/2 FAQ：
HTTP/1.1 has served the Web well for more than fifteen years, but its
age is starting to show.
和
The goal of the Working Group is that typical uses of HTTP/1.x can use HTTP/2 and see some benefit.
所以HTTP / 2很好,取而代之的是HTTP / 1.x.不幸的是,HTTP/2 does not support WebSockets.在这个问题Does HTTP/2 make websockets obsolete?中,明确表示HTTP / 2服务器推送不是替代方案,Server-Sent Events也不是.
现在回答一个问题：如果我们想通过HTTP / 2获得WebSockts功能,我们会使用什么？
当前形式的HTTP / 2协议协商：HTTP / 2连接以三种方式之一启动：
>在使用ALPN(应用层协议协商)的加密连接(TLS / SSL)中.大多数浏览器需要HTTP / 2的TLS / SSL,并使用此方法建立HTTP / 2连接.
>以明文形式,使用HTTP / 1.1升级标头(与Websockets相同).大多数浏览器都需要TLS / SSL用于HTTP / 2,因此它的支持受到限制.
>在明文中,在HTTP / 1.1连接的开头使用特殊字符串(可以允许HTTP / 2服务器以明文形式禁用HTTP / 1.1支持).有限的客户支持.
谈判Websocket协议,现在时：
目前,协商Websocket连接需要HTTP / 1.1支持并使用HTTP / 1.1 Upgrade头.
这通常由侦听HTTP / 1.1和HTTP / 2连接的同一应用程序服务器执行.支持并发(无论是基于协议还是基于线程)的Web应用程序通常是协议不可知的(只要保留HTTP语义)并且在两种协议上都能正常工作.
这允许在连接建立期间使用HTTP数据(并且可能影响Websocket连接状态/认证过程).
一旦建立了Websocket连接,它就完全独立于HTTP语义/层.
在HTTP / 2世界中协商Websocket协议：
在HTTP / 2(唯一)世界中,可能还有一段时间,Websocket协议协商可能有许多可能的方法：基于ALPN的方法和HTTP / 2“隧道”(或“流”)做法.
ALPN方法以牺牲预升级(HTTP)阶段为代价来保持协议独立性,而“流”方法以高耦合和复杂性为代价提供HTTP预升级(或连接)阶段.
ALPN方法：
一种可能的未来方法只是将Websocket协议添加到the ALPN negotiation表.
目前,ALPN用于选择(或默认)“http / 1.1”协议,并且升级请求由HTTP / 1.1服务器处理.这意味着Websocket在协议协商期间仍然为我们提供HTTP头数据(同时使用它自己的TCP / IP连接)
将来,ALPN可能只是添加“wss”作为可用选择.
使用这种方法,可以使用ALPN扩展到TLS / SSL层轻松协商Websocket(目前使用HTTP / 1.1升级标头建立的加密和明文形式).
这将使Websocket协议独立于HTTP / 2协议,即使不支持HTTP,也允许使用它.
但是,这将带来的缺点是,作为协议协商的一部分,cookie和其他HTTP头可能不再可用.另一个区别(好的和坏的)是这种方法需要单独的TCP / IP连接.
HTTP / 2“隧道”/“流”方法
另一种可能的未来方法,即in this proposed draft反映,将处理Websocket协议的HTTP / 1.1变体,转而采用HTTP / 2“流”方法.
HTTP / 2“流”是HTTP / 2实现多路复用的方式,允许同时处理多个请求.每个请求接收流号ID,并且使用相同的数字流ID识别与该请求有关的任何数据(报头,响应等’).
在这种方法下,“Websocket”数据将包含在HTTP / 2包装器中,流ID将用于标识“Websocket”流.
虽然这可能会带来一些好处(HTTP头和cookie可以作为Websocket协商的一部分提供),但它并非没有它的垮台.
更高的复杂性和更严格的协议耦合只是两个例子,两者都是非常严重的垮台.
结论：
在撰写本文时,在使用明文(ws)和加密(wss)连接时,Websocket连接都需要HTTP / 1.1升级语义.
到目前为止,未来尚未确定,可能需要很长时间才能逐步淘汰当前的升级流程(使用HTTP / 1.1)