顺便一提，SPDY的请求头压缩算法是DEFLATE
| HTTP/2 | WebSocket | |
|---|---|---|
| 请求头 | 压缩(HPACK算法) | 无 |
| 二进制 | √ | 二进制或文本流 |
| 多路复用 | √ | √ |
| 优先级 | √ | × |
| 压缩 | √ | √ |
| 方向 | 客户端/服务器+服务器端推送（Server Push） | 双向的 |
| 全双工 | √ | √ |
正如我们上面看到的，HTTP/2 引入了 Server Push ，它使服务器能够主动地将资源推送到客户端缓存。但是，它并不允许将数据推送到客户端应用程序本身。服务器推送只能由浏览器处理，不会在应用程序代码中弹出服务器数据，这意味着应用程序没有 API 来获取这些事件的通知。
澄清server push/websocket/sse的一些概念：
https://blog.csdn.net/axman/article/details/79875463
如何选择 WebSocket 和 HTTP/2 ？
WebSockets 肯定会在 HTTP/2 + SSE 的领域中生存下来，主要是因为它是一种已经被很好地应用的技术，并且在非常具体的使用情况下，它比 HTTP/2 更具优势，因为它已经被构建用于具有较少开销(如报头)的双向功能。
假设你想建立一个大型多人在线游戏，需要来自连接两端的大量消息。在这种情况下，WebSockets 的性能会好很多。
**一般情况下，只要需要客户端和服务器之间的真正低延迟，接近实时的连接，就使用 WebSocket 。**请记住，这可能需要重新考虑如何构建服务器端应用程序，以及将焦点转移到队列事件等技术上。
如果你使用的方案需要显示实时的市场消息，市场数据，聊天应用程序等，依靠 HTTP/2 + SSE(Server Sent Events) 将为你提供高效的双向通信渠道，同时获得留在 HTTP 领域的各种好处：
当考虑到与现有 Web 基础设施的兼容性时，WebSocket 通常会变成一个痛苦的源头，因为它将 HTTP 连接升级到完全不同于 HTTP 的协议。
规模和安全性：Web 组件（防火墙，入侵检测，负载均衡）是以 HTTP 为基础构建，维护和配置的，这是大型/关键应用程序在弹性，安全性和可伸缩性方面更喜欢的环境。
另外，你必须考虑到浏览器的支持。 看看 WebSocket ：
实际上相当不错，不是吗？
然而，HTTP/2 的情况并不相同：
-
仅 TLS（不是那么糟糕）
-
部分支持 IE 11 ，但只在 Windows 10 上
-
仅在 OSX 10.11+ 上支持 Safari
-
如果你可以通过 ALPN 协商，可以只支持 HTTP/2（这是你的服务器需要明确支持的东西）
SSE 的支持比较好：
只有 IE / Edge 不提供支持。（Opera Mini 既不支持 SSE 也不支持 WebSocket ，所以我们可以将其完全排除在外）。 在 IE / Edge 中也有一些像样的 polyfill 提供 SSE 支持。
转载自：https://www.oschina.net/translate/how-does-javascript-actually-work-part-5?lang=chs&p=2