HTTP、WebSocket、gRPC 或 WebRTC：各种协议的区别

在为您的应用程序选择通信协议时，有很多不同的选择。 本文将了解四种流行的解决方案：HTTP、WebSocket、gRPC 和 WebRTC。 我们将通过深入学习其背后原理、最佳用途及其优缺点来探索每个协议。

通信方式在不断改进：变得更快、更方便、更可靠，从使用信鸽发送信息，发展到邮政邮件，再到固定电话的发明，再到便携式移动设备。未来，甚至可能将会议和生日派对过渡到 VR（但愿这只是个玩笑！）。

当然，最好的沟通方式总是要视情况而定。快速的短信有时比长的电子邮件更好。 其他时候，与团队进行视频通话是交流信息的最佳方式， 相比之下，重要的保险文件必须通过普通邮件发送并以纸质形式交付。而使用的网络技术和协议也是如此，不同的应用程序有不同的通信需求。

概述

在本文中，我们将介绍一些可以作为开发人员使用的流行通信协议，并探讨不同协议的优缺点。 正如开头所说，没有比另一个更好的解决方案，只有一些解决方案更适合特定的应用程序或问题。

一些应用程序需要点对点连接，具有低延迟和高数据传输，并且可以接受一些数据包（信息）丢失。 有些应用程序可以根据需要轮询服务器，而不需要获取被‬轮询方的同等数据，有些应用程序需要具有数据可靠性的实时通信，诸如此类。

在线多人游戏、消息传递应用程序、博客网站、媒体库应用程序和视频会议软件都有不同的通信和数据需求。如果您正在构建视频流解决方案，那可能‬还有其他注意事项。

什么是通信协议？

在计算机网络中，协议是一组规则，用于管理数据在设备之间的交换方式。 该协议定义了通信的规则、语法、语义和同步以及可能的错误恢复方法。本文中讨论的协议定义了应用层软件如何相互交互。 不同的协议遵循不同的规则，了解每个协议的优势和局限性至关重要。

不同协议的时间线

在本文中，您将了解以下协议：

• HTTP（超文本传输协议）：是分布式协作和超媒体信息系统的应用协议。 HTTP 是万维网数据通信的基础， 超文本是在包含文本的节点之间使用逻辑链接（超链接）的结构化文本。 HTTP 是交换或传输超文本的协议。
• HTTP/2： 旨在解决原始 HTTP 协议的缺点并提高性能。 HTTP/2 比 HTTP/1.1 更快、更高效，它支持多路复用，允许多个请求和响应在单个连接上进行多路复用。 其他值得注意的功能包括标头压缩和服务器推送， 它正逐渐成为网络流量的默认协议。
• WebSocket： 是一种允许客户端和服务器之间进行双向通信的协议。 它是处理实时数据应用程序的热门选择，例如聊天应用程序、在线游戏和实时数据流。
• gRPC ：是一个使用 HTTP/2 进行传输的现代开源 RPC 框架。 对于需要进行大量小而快的 API 调用的应用程序来说，这是一个很好的选择。 gRPC 为多种语言生成跨平台的客户端和服务器绑定，使客户端应用程序可以直接调用不同机器上的服务器应用程序的方法，就好像它是本地方法‬一样。
• WebRTC： 是一种允许客户端之间进行实时通信，并使得建立直接对等连接成为可能的技术。 它用于视频、聊天、文件共享和实时视频流应用程序。

了解 TCP 和 UDP

在深入研究上述应用层之前，重要的是要对 TCP 和 UDP 有一个基本的了解，这两个底层传输层以根本不同的方式促进数据传输。

• TCP（传输控制协议）：是定义如何通过 Internet 建立和维护网络对话的标准。 TCP 是 Internet 和任何面向连接的网络上最常用的协议。 当您浏览网页时，您的计算机会向网络服务器发送 TCP 数据包。 Web 服务器通过将 TCP 数据包发送回您的计算机来响应。 在交换任何数据之前，首先在两个设备之间建立连接，并且 TCP 使用纠错来确保所有数据包都成功传递。 如果数据包丢失或损坏，TCP 将尝试重新发送它。
• UDP（用户数据报协议）：是一种无连接、不可靠的传输层协议。 它不需要建立或维护连接，也不保证消息将按顺序传递。 这意味着如果数据包未发送或损坏，可能会丢失一些数据。 UDP 通常用于流媒体或实时应用程序，在这些应用程序中，丢失数据包的问题比确保交付要少。

HTTP/1

对应用层所有基于互联网的通信和数据传输的基础——HTTP（超文本传输协议）有一个基本的了解是很重要的。在更详细地探索其他协议并充分理解它们提供的功能之前，了解 HTTP/1 及其局限性也很重要。

使用 HTTP，客户端和服务器通过交换单独的消息进行通信。 客户端发送的消息称为请求，服务器发送的消息称为响应。 这些消息作为常规文本消息通过 TCP 连接发送。 它们也可以使用 TLS 加密并使用 HTTPS 协议发送。

客户端通常是在用户手机或计算机上运行的 Web 浏览器或应用程序，但从技术上讲，它可以是任何东西，例如，抓取网站的脚本。HTTP 请求只能沿一个方向流动，即从客户端到服务器。 服务器无法发起与客户端的通信， 它只能响应请求。

HTTP/1.1传输示例

HTTP 非常适合传统的 Web 和客户端应用程序，在这些应用程序中，信息是按需获取的。 例如，你刷新了一个页面，向服务器发出了获取最新信息的请求。

在接下来的部分中，我们将探讨 HTTP/1 的一些限制。

– HTTP/1 实时传输

当消息需要从客户端实时发送到服务器时，HTTP/1 效率低下。 例如，如果服务器上有新信息需要与客户端共享，则此事务只能在客户端发起请求后发生。当然，也有一些解决方法，例如‬使用称为 HTTP 短轮询和长轮询以及服务器发送事件的技术。

短轮询

HTTP 短轮询是一种客户端重复向服务器发送请求直到它响应新数据的技术。 一旦它接收到数据，它就会再次启动该过程并反复询问，直到有其他可用的数据‬为止。

HTTP短轮训

这是一种低效的实时通信策略，因为它通过持续传输和解析 HTTP 请求/响应浪费了大量资源。

长轮询

使用 HTTP 长轮询，从客户端发出单个请求，然后服务器保持该连接打开，直到有新数据可用并且可以发送响应。 客户端收到响应后，立即再次建立新的连接。

HTTP长轮询

长轮询比短轮询更有效，但不是实时通信的最佳解决方案。

服务器发送的事件 (SSE)

服务器发送的事件允许客户端保持打开的连接并实时从服务器接收推送消息，而不必不断地轮询服务器以获取新数据。 这是一种单向连接，因此您无法将事件从客户端发送到服务器。

SSE 是一种标准，描述了一旦建立了初始客户端连接，服务器如何启动向客户端的数据传输。

– HTTP/1 的性能问题

大多数 HTTP 数据流由小的、密集‬的数据传输组成，而 TCP 针对长期连接和批量数据传输进行了优化。 在大多数情况下，网络往返时间是 TCP 吞吐量和性能的限制因素。 因此，延迟是性能瓶颈，大多数 Web 应用程序都可以克服它。

上面的意思是 HTTP 使用的 TCP 是为处理长期连接和传输大量数据而构建的。 另一方面，HTTP/1 会打开一堆短暂的 TCP 连接，并且通常只发送小块数据。

队首阻塞

HTTP/1.0 的一个性能问题是您必须为每个请求/响应打开一个新的 TCP 连接。 对于 HTTP 最初发明的目的而言（获取超文本文档），这不是问题。 文档部分很重要，因为 HTTP 并不意味着“超媒体”。

随着网络的发展，为每个请求打开一个新的 TCP 连接成为一个问题。 我们开始构建完整的应用程序而不是简单的网页，浏览器需要检索的媒体和文件的数量变得更多。 设想一个典型的 Web 应用程序需要 HTML、CSS 和 JavaScript 文件，以及各种图像和其他资产。 对于每个文件，都必须建立一个新的连接。

随之而来的是 HTTP/1.1，它具有持久连接，它定义了可以在同一个 TCP 连接上有多个请求或响应。这个解决方案绝对是一个改进，