使用 HTTP/2 时，我们是否应该更喜欢 SSE + REST 而不是 websocket？
Should we prefer SSE + REST over websocket when using HTTP/2?
使用 websocket 时，我们需要一个专用连接进行双向通信。如果我们使用 http/2，我们就会有第二个连接由服务器维护。
在那种情况下，使用 websocket 似乎会引入不必要的开销，因为使用 SSE 和常规 http 请求，我们可以通过单个 HTTP/2 连接获得双向通信的优势。
你怎么看？
从网络开发人员的角度来看，Websockets 和 REST 接口之间的区别在于语义。 REST 使用 request/response 模型，其中来自服务器的每条消息都是对来自客户端的消息的响应。另一方面，WebSockets 允许服务器和客户端随时推送消息，而与先前的请求没有任何关系。
使用哪种技术取决于哪种技术在您的应用程序上下文中更有意义。当然，您可以使用一些技巧来模拟一种技术与另一种技术的行为，但通常最好使用更适合您的通信模型的技术。
服务器发送的事件是一项相当新的技术，尚未得到所有主流浏览器的支持，因此它还不是正式 Web 应用程序的一个选项。
在一个多路复用 HTTP/2 TCP 连接中使用 2 个流（一个流用于服务器到客户端的通信 - Server Sent Events (SSE)，一个流用于客户端到服务器的通信和正常HTTP 通信）与使用 2 个 TCP 连接（一个用于普通 HTTP 通信，一个用于 WebSocket）不容易比较。
里程可能会因应用程序而异。
开销？好吧，连接数肯定会翻倍。
但是WebSocket可以压缩消息，而SSE不能。
灵活性？如果连接是分开的，它们可以使用不同的加密。 HTTP/2 通常需要非常强的加密，这可能会限制性能。
另一方面，WebSocket 不需要 TLS。
明文 WebSocket 是否适用于移动网络？根据我的经验，这取决于。防病毒软件、应用程序防火墙、移动运营商可能会限制 WebSocket 流量，或降低其可靠性，具体取决于您所在的国家/地区。
API 有空吗？ WebSocket 是一个广泛部署和公认的标准；例如在 Java 中有一个正式的 API (javax.websocket)，另一个即将出现 (java.net.websocket)。
我认为 SSE 是双向网络通信的技术劣势解决方案，作为一种技术，它并没有变得非常流行（与 WebSocket 相比，没有标准 APIs，没有书籍等）。
如果它从 HTML5 掉落，我不会感到惊讶，我也不会错过它，尽管它在 Jetty one of the first to implement it。
根据您的兴趣，您必须针对您的特定情况进行基准测试或评估技术。
这在很大程度上取决于你想实现什么样的应用程序。如果您确实需要服务器和客户端之间的双向通信，WebSocket 更适合，但您必须实现所有通信协议，并且它可能无法得到所有 IT 基础架构的良好支持（某些防火墙、代理或负载平衡器可能不支持 WebSockets） .因此，如果您不需要 100% 双向 link，我建议将 SSE 与 REST 请求一起使用，以获取从客户端到服务器的附加信息。
但另一方面，SSE 有一些注意事项，例如在 Javascript 实现中，您不能覆盖 headers。唯一的解决方案是传递查询参数，但是您可能会遇到查询字符串大小限制的问题。
因此，再次强调，在 SSE 和 WebSockets 之间进行选择实际上取决于您需要实现的应用程序类型。
几个月前，我写了一篇博客post，可能会给你一些信息：http://streamdata.io/blog/push-sse-vs-websockets/。虽然当时我们没有考虑 HTTP2，但这可以帮助您知道您需要问自己什么问题。
使用 websocket 时，我们需要一个专用连接进行双向通信。如果我们使用 http/2，我们就会有第二个连接由服务器维护。
在那种情况下，使用 websocket 似乎会引入不必要的开销，因为使用 SSE 和常规 http 请求，我们可以通过单个 HTTP/2 连接获得双向通信的优势。
你怎么看？
从网络开发人员的角度来看，Websockets 和 REST 接口之间的区别在于语义。 REST 使用 request/response 模型，其中来自服务器的每条消息都是对来自客户端的消息的响应。另一方面，WebSockets 允许服务器和客户端随时推送消息，而与先前的请求没有任何关系。
使用哪种技术取决于哪种技术在您的应用程序上下文中更有意义。当然，您可以使用一些技巧来模拟一种技术与另一种技术的行为，但通常最好使用更适合您的通信模型的技术。
服务器发送的事件是一项相当新的技术，尚未得到所有主流浏览器的支持，因此它还不是正式 Web 应用程序的一个选项。
在一个多路复用 HTTP/2 TCP 连接中使用 2 个流（一个流用于服务器到客户端的通信 - Server Sent Events (SSE)，一个流用于客户端到服务器的通信和正常HTTP 通信）与使用 2 个 TCP 连接（一个用于普通 HTTP 通信，一个用于 WebSocket）不容易比较。
里程可能会因应用程序而异。
开销？好吧，连接数肯定会翻倍。 但是WebSocket可以压缩消息，而SSE不能。
灵活性？如果连接是分开的，它们可以使用不同的加密。 HTTP/2 通常需要非常强的加密，这可能会限制性能。 另一方面，WebSocket 不需要 TLS。
明文 WebSocket 是否适用于移动网络？根据我的经验，这取决于。防病毒软件、应用程序防火墙、移动运营商可能会限制 WebSocket 流量，或降低其可靠性，具体取决于您所在的国家/地区。
API 有空吗？ WebSocket 是一个广泛部署和公认的标准；例如在 Java 中有一个正式的 API (javax.websocket)，另一个即将出现 (java.net.websocket)。
我认为 SSE 是双向网络通信的技术劣势解决方案，作为一种技术，它并没有变得非常流行（与 WebSocket 相比，没有标准 APIs，没有书籍等）。 如果它从 HTML5 掉落，我不会感到惊讶，我也不会错过它，尽管它在 Jetty one of the first to implement it。
根据您的兴趣，您必须针对您的特定情况进行基准测试或评估技术。
这在很大程度上取决于你想实现什么样的应用程序。如果您确实需要服务器和客户端之间的双向通信，WebSocket 更适合，但您必须实现所有通信协议，并且它可能无法得到所有 IT 基础架构的良好支持（某些防火墙、代理或负载平衡器可能不支持 WebSockets） .因此，如果您不需要 100% 双向 link，我建议将 SSE 与 REST 请求一起使用，以获取从客户端到服务器的附加信息。 但另一方面，SSE 有一些注意事项，例如在 Javascript 实现中，您不能覆盖 headers。唯一的解决方案是传递查询参数，但是您可能会遇到查询字符串大小限制的问题。 因此，再次强调，在 SSE 和 WebSockets 之间进行选择实际上取决于您需要实现的应用程序类型。 几个月前，我写了一篇博客post，可能会给你一些信息：http://streamdata.io/blog/push-sse-vs-websockets/。虽然当时我们没有考虑 HTTP2，但这可以帮助您知道您需要问自己什么问题。