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 毗连上有多个哀求或相应。这个办理方案绝对是一个改进，但它不答应服务器同时返回多个相应。 这是一个序列化协议，您必须在此中发送哀求并等候相应，然后发送第二个哀求，依此类推。 这称为队头壅闭。
然而，实现某种并行性是大概的，由于欣赏器最多可以打开六个（差异欣赏器有差异）同一泉源的 TCP 毗连（此中“泉源”被界说为主机和端标语的唯一组合）。
比方，如果您有一个必要加载 12 张图像的照片库应用步调，那么将发出六个哀求来加载前六张图像，而且每个哀求都会在背景打开一个新的 TCP 毗连。 其他六个图像将被制止，直到收到相应而且打开的毗连之一可用于加载下一个图像。 最初的六个开放的同源 TCP 毗连将在可用时被重用，但您仅限于六个运动毗连。
很自然地，步调员找到了一个简朴的办理方法——改变图片源。 不是在同一个源上托管全部资产，而是在一个源上托管六个图像，别的的在另一个源上。 现在您可以有 12 个并发哀求（或打开 TCP 毗连），这被称为“分片”。

• 图片 1–6 托管在 1.images.com 上
  
• 图片 7–12 托管在 2.images.com 上
  

但是，您可以实行此利用的次数是有限定的，而且很难确定最佳的分片数量。 在某些时间，添加更多分片会增长复杂性、增长开销，并大概导致链路拥塞和数据包丢失。
尚有其他题目，由于每个 TCP 毗连都会给服务器增长不须要的开销。 毗连相互竞争，每次 TCP 和 TLS 握手都会增长不须要的资源，而且必须使用其他服务器/署理资源来维持运动毗连。 HTTP/1 使用底层 TCP 毗连的方式有一个显着的限定。
标头（Headers）和 Cookie 爆炸

另一个题目是，随着 HTTP 规范的发展，规范中添加了更多的标头。 开辟职员还可以选择将 cookie 添加到标头，这些 cookie 可以恣意大。 这增长了许多巨细，由于每个哀求和相应都必要传输全部这些文本信息，而且 HTTP/1.1 不包罗压缩标头和元数据的机制。
如果您必要一个高性能的 RPC 协议，这种开销会变得更大，此时 HTTP 不再是最佳办理方案。
优先级（Prioritization）

在 HTTP/1.1 中，欣赏器通过在客户端持有一个优先级队列来“确定”资源的优先级，并对怎样充实使用可用的 TCP 毗连举行有根据的推测。 欣赏器嵌入了启发式方法，用于确定哪些资源比其他资源更有代价。
比方，加载 CSS 将比加载图像具有更高的优先级。题目在于，作为开辟职员，您无法确定一个哀求的优先级高于另一个哀求或更改正在举行的消息的优先级。 起首加载什么内容取决于欣赏器，您对优先级方案没有发言权。
HTTP/2

HTTP/2 的长处

HTTP/2 是 HTTP 协议的改进版本，办理了上述 HTTP/1 的全部性能题目，并在不改变任何语义（标头等）的情况下添加了其他增强功能。
HTTP/2 中最显着的变革是使用多路复用。通过单个 TCP 毗连同时发送和汲取多个 HTTP 哀求和相应。 全部 HTTP/2 毗连都是长期的，每个源只必要一个毗连。 这答应更有用地使用网络资源，并可以显着进步应用步调的性能。
HTTP/2 的其他一些利益：

• 使用标头压缩来减小标头的巨细，从而制止一遍又一各处发送雷同的纯文本标头。 这显着镌汰了哀求/相应的开销和发送的数据量。
  
• 启用优先级，答应客户端（开辟职员）指定其所需资源的优先级。 也可以更新正在举行的哀求的优先级——比方，在滚动时，如果图像不再可见，则优先级可以改变。
  
• 使用服务器推送，在客户端哀求之前将数据发送到客户端。 这可用于通过消除客户端发出多个哀求的必要来收缩加载时间。
  

HTTP/2 是怎样工作的？

HTTP/2 中的根本协议单元是帧。 这种新的二进制帧机制改变了客户端和服务器之间的数据互换方式。
该尺度界说了十种差异的帧范例，每种都有差异的用途。 比方，HEADERS 和 DATA 帧构成了 HTTP 哀求和相应的底子：

HTTP/1.1 vs HTTP/2
帧是承载特定范例数据的最小通讯单元。 其他一些帧示例是：

• 设置(SETTINGS)：在开始或毗连期间互换设置信息。
  
• 优先级(PRIORITY)：重新分配消息的优先级。
  
• PUSH_PROMISE：答应服务器向您推送数据,这是对服务器将发送的内容的答应。 比方，如果您哀求 index.html，服务器可以创建一个 PUSH_PROMISE 来答应推送 app.js 和 styles.css，这意味着客户端不必要自动哀求这些资源。
  

帧组合在一起形成消息，比方上图中的标题和数据帧。 这等同于正常的哀求或相应。末了，一系列消息可以成为流的一部分。 这答应客户端和服务器之间的双向数据流以及完备的哀求和相应多路复用。

多路复用
上图有点误导，给人的印象是客户端和服务器之间打开了多个毗连。但它是单个 TCP 毗连，数据以非壅闭方式在客户端和服务器之间自由运动。

多路复用
新的二进制框架层答应客户端和服务器将 HTTP 消息分解为独立的帧，组合发送，然后在另一端重新组合它们。这只是 HTTP/2.0 工作原理的总结。 如果您想相识更多信息并探索优先级排序、服务器推送和标头压缩，请参阅文末资料。
HTTP/2 双向数据流

HTTP/2 规范表明：

1. “流”是在 HTTP/2 连接中客户端和服务器之间交换的独立地、双向帧序列。

复制代码

流有几个紧张的特性：

• 单个 HTTP/2 毗连可以包罗多个并发打开的流，此中任一端点交错来自多个流的帧。
  
• 流可以单方面创建和使用，也可以由客户端或服务器共享。
  
• 流可以被任一端点关闭。
  

服务器推送功能存在许多误解，它答应服务器通过 HTTP/2 自动发送它以为您大概必要的资源，比方 .js 和 .css 文件，而无需客户端哀求。 这与双向流无关，只是一种针对可缓存资源的 Web 优化技能。
毕竟是，对于 HTTP/2 服务器无法启动流。 但是一旦客户端通过发送哀求打开一个流，双方就可以随时通过长期套接字发送数据帧。 一个很好的例子是 gRPC，我们将在反面讨论。
使用 HTTP/2，可以实现双向数据流，你可以争辩说它是比 WebSockets 之类的东西更优化的办理方案，大概你可以争辩说它不是。 我们将在 WebSocket 部分更详细地讨论这个题目。
WebSockets

WebSockets 规范阐明

来自 WebSocket 协议规范：
该技能的目的是为基于欣赏器的应用步调提供一种机制，这些应用步调必要与不依赖于打开多个 HTTP 毗连的服务器举行双向通讯（比方，使用 XMLHttpRequest 或 iframe 和长轮询）。
WebSockets 的发明是为了实现客户端和服务器之间的全双工通讯，这答应数据立即通过单个打开的毗连双向传输。
创建 WebSocket 毗连后，客户端无需轮询服务器以获取更新。 相反，通讯是双向发生的。 与 HTTP/1 的原始长轮询和短轮询相比，这进步了速率和及时本领。 WebSocket 没有特定要遵照的数据格式， 您可以使用它发送任何数据、文本或字节，这种机动性是 WebSockets 盛行的缘故原由之一。
此中一些内容听起来大概与我们在 HTTP/2 部分中讨论的内容很熟悉，但紧张的是要注意 WebSockets 是在 HTTP/2 之前很久就发明的。 稍后我们将对它们举行更多比力。
WebSockets 怎样工作？

WebSockets 底层基于 TCP 的传输层运行。 要创建 WebSocket 毗连，客户端和服务器起首必要通过正常的 HTTP/1.1 毗连实行握手。此握手是从 HTTP 升级到 WebSockets 的桥梁。

下面是一个示例客户端握手哀求。客户端可以使用称为升级标头的 HTTP/1.1 机制将其毗连从 HTTP 切换到 WebSockets：

1. GET /chat HTTP/1.1
2. Host: example.com:8000
3. Upgrade: websocket
4. Connection: Upgrade
5. Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
6. Sec-WebSocket-Version: 13

复制代码

然后服务器将用一个特别的相应竣事握手，该相应表明协议将从 HTTP 更改为 WebSocket：

1. HTTP/1.1 101 Switching Protocols
2. Upgrade: websocket
3. Connection: Upgrade
4. Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

复制代码

WebSockets 必要具有 ws:// 或 wss:// 方案的同一资源标识符 (URI)。 ws:// 方案用于未加密毗连，wss:// 方案用于加密毗连，雷同于 HTTP URL 使用 http:// 或 https:// 方案的方式。
一旦创建了双向通讯通道，客户端和服务器就可以来回发送消息。 这些消息可以是从二进制数据到文本的任何内容。 WebSocket 毗连将保持打开状态，直到客户端或服务器断开毗连。
WebSocket 多路复用

在撰写本文时，WebSocket 协议不支持内置多路复用。 我们在 HTTP/2 部分讨论了多路复用，相识到它是 HTTP/2 的内置功能，而且可以在同一毗连上多路复用多个流。 每个流都有一个唯一的标识符，全部发送的帧都有一个与相应流关联的 ID。
不支持多路复用意味着 WebSocket 协议必要为每个 WebSocket 毗连创建一个新的传输毗连。 比方，在同一欣赏器的差异选项卡中运行的多个客户端将使用单独的毗连。 要在 WebSockets 上举行多路复用，您通常必要依赖第三方插件或库。
WebSocket 与 HTTP/2

HTTP/2 代替了 WebSockets 了吗？ 答案是不！
HTTP/2 使双向流成为大概，这使得 WebSockets 不是唯一/最佳选择。 与 WebSockets 相比，HTTP/2 作为规范为您做了更多的工作。 它具有内置的多路复勤奋能，在大多数情况下，将导致与源站创建的 TCP 毗连更少。 另一方面，WebSockets 提供了很大的自由度，而且在创建毗连后怎样在客户端和服务器之间发送数据方面没有限定。 但是，您必要自己管理重新毗连（或依赖为您实行此利用的库）。
至于谁人更好，本文不给出答案，每个人有每个人的见解。WebSockets 提供了很大的机动性，而且作为一个既定尺度，它得到全部当代欣赏器的完全支持，而且围绕客户端和服务器库的生态体系是强大的。有关更详细和自以为是的讨论，请参阅这些 Stack Overflow 题目：

• HTTP/2 是否让 WebSocket 过期了
  
• 用于低延伸客户端到服务器消息的 HTTP/2 或 Websockets
  
• 用于双向消息流的 HTTP/2 与网络套接字
  

尚有一个 RFC 答应在 HTTP/2 毗连的单个流上运行 WebSocket 协议的机制。可以或许从 HTTP/2 引导 WebSockets ，即答应两个协议共享一个 TCP 毗连，并将 HTTP/2 对网络的更有用使用扩展到 WebSockets。这已在 Chrome 和 Firefox 中实现。 您可以在此处阅读 Chrome 计划文档和动机。
什么时间使用 WebSocket？

Websockets 最适当必要及时双向通讯的应用步调，以及必要快速传输小块数据的应用步调：

• 谈天应用
  
• 多人游戏
  
• 协作编辑应用步调
  
• 直播体育赛事
  
• 股票买卖业务应用
  
• 及时运动提要
  

对于服务器发送变乱 (SSE)， 在 HTTP/2 上非常高效且易于使用。 SSE 不是双向通讯体系； 服务器单方面向客户端推送数据。 但是，如果您所必要的只是服务器向客户端发送数据的一种方式，那么这大概是比使用 WebSockets 更好的选择。 当 HTTP/2 不可用时，SSE 也会回退到 HTTP/1.1。 别的，客户端（或欣赏器）为您管理毗连并支持自动重新毗连。
如果通过 WebSockets 的毗连丢失，则不包罗用于负载均衡或重新毗连的机制。 这必须手动或由第三方库实现。
gRPC

gRPC 是一个当代开源高性能长途过程调用 (RPC) 框架，可以在任何情况中运行。 它可以通过对负载均衡、跟踪、康健查抄和身份验证的可插拔支持，有用地毗连数据中心内和跨数据中心的服务。 它还实用于分布式盘算的末了一英里，将装备、移动应用步调和欣赏器毗连到后端服务。
gRPC 是一个开源的、基于约定的 RPC 体系，最初由谷歌开辟。 gRPC 使应用步调可以或许透明地通讯并简化毗连体系的构建。它为多种语言天生跨平台的客户端和服务器绑定，使客户端应用步调可以直接调用差异呆板上服务器应用步调的方法，就好像它是当地对象一样。
gRPC 基于 HTTP/2 构建，使用双向流和内置传输层安全性 (TLS) 等功能。
gRPC 动机

深入相识 gRPC 背后的动机、发明它的缘故原由以相识其利益非常紧张。 为什么倒霉用我们已经拥有的现有技能：比方 HTTP/2 和 WebSockets？ 为什么我们必要在已有的本领之上再抽象一层？
可以通过多种方式构建数据并通过 Internet 发送数据。 一些盛行的例子是 SOAP、REST 和 GraphQL。 您乃至可以创建自己的协议，通过原始 TCP 发送数据，并根据必要自行处置惩罚实现。
但无论您选择什么作为您的通讯协议，题目在于您必要确保客户端和服务器就该协议告竣同等。 比方，如果您正在构建 REST API，则必要用于发送 REST 数据的客户端库是 HTTP 库。 HTTP 库默认内置于欣赏器中，欣赏器会为您处置惩罚齐备：

• 它与服务器创建通讯。
  
• 它处置惩罚 HTTP/2 并回退到 HTTP/1， 而且将来必要支持 HTTP/3。
  
• 它处置惩罚 TLS 并协商协议。
  
• 它处置惩罚标头、流和其他全部内容。
  

但是，如果您不在欣赏器上怎么办？ 如果您是在某个服务器上运行的 Python 应用步调、GoLang CLI 或在 iOS 上运行的 Flutter 应用步调怎么办？ 全部这些客户端都必要自己的 HTTP 库，该库可以明白您正在与之通讯的协议。
荣幸的是，许多人正在为全部这些语言和框架开辟各种 HTTP 库。 有些语言乃至有多个具有差异特性的 HTTP 库。 然而，全部这齐备都是有代价的，那就是维护。
如果您要将服务器升级到 HTTP/2（如果您使用的 GoLang 库支持它），此资源大概会影响您。 但是，在您的前端 Python 客户端上，等效的 HTTP 库尚未实现 HTTP/2，大概大概不再维护。
随着 HTTP 规范的发展，这些库必须同步更新，如安全题目、新功能等。 HTTP 只是一个例子，对于 WebSocket 协议或任何其他协议也是云云。 有些东西大概在主流欣赏器中得到很好的实现，但该功能必须移植到多种差异的语言和框架中。
gRPC 有何差异？

gRPC 试图通过维护盛行语言自己的库来办理这个题目，这意味着全部这些语言都将支持添加的新功能。
gRPC 使用 HTTP/2 作为其协议，但是，这个实现对您是无感的。 将来，gRPC 的维护者可以轻松地将 HTTP/2 更换为 HTTP/3，您将立即从该更改中受益。
gRPC 还使用协议缓冲区作为接口界说语言 (IDL) 及其底层消息互换格式。 这种格式是语言中立的，可以轻松地在差异的编程语言之间举行通讯。 我们将在下一节中更多地探究这个概念。

什么是协议缓冲区？

Protocol buffers 是 Google 计划的语言中立、平台中立、可扩展的布局化数据序列化机制——想想 XML，但更小、更快、更简朴。 您一次性界说了数据的布局方式。 然后，您可以使用特别天生的源代码轻松地将布局化数据写入各种数据流并使用各种语言从中读取布局化数据。
在 API 机制的设定中，您通常无需关心协议自己。 比方，如果您使用的是 REST，您通常只是发送带有键/值对的 JSON 消息，直到消息到达汲取端才举行查抄。 此消息通常可以是任何内容，由您来确保界说了准确的布局。
检察以下 JSON 数据(payload)：

1. {
2. 'id': 123,
3. 'name': 'Gordon',
4. 'email': '[email protected]'
5. }

复制代码

在客户端/服务器上汲取到此数据，就可以将其反序列化为一个对象，比方：

1. class Person {
2.     int id;
3.     String name;
4.     String email
5. }

复制代码

但是，作为开辟职员，您必要为上述数据实现准确的序列化和反序列化逻辑——这大概涉及手动编写 toJson 和 fromJson 方法，可以依赖于代码天生，大概它大概是你正在使用的语言。
无论您怎样序列化此数据，底层代码都必要手动更新，大概在多个情况中，以防模式发生变革。而使用协议缓冲区，您可以创建一个模式来界说字段的对象范例并指定哪些是必须的，哪些是可选的：

1. // The request message containing the person’s information
2. Message Person {
3.     optional int32 id = 1;
4.     required string name = 2;
5.     optional string email = 3;
6. }
8. // The response message containing the greetings
9. message HelloReply {
10.   string message = 1;
11. }

复制代码

然后您可以指定对外的方法:

1. // The greeting service definition.
2. service Greeter {
3.   // Sends a greeting
4.   rpc SayHello (Person) returns (HelloReply) {}
5. }

复制代码

一旦您指定了数据布局和模式，您就可以使用协议缓冲区编译器 将 protoc 从您的 proto 界说中，以您的首选语言天生数据访问类。这些是形貌 proto 文件中概述对象的接口，每个字段都有访问器，以及将整个布局序列化/分析为原始字节的方法。
gRPC 模式

gRPC 有四种传输方式， 这四种模式实现了之前讨论的举动，比方，正常的哀求/相应、SSE 和 WebSockets。
一元 RPC

一元 RPC 是简朴的哀求和相应，雷同于调用函数。 客户端哀求一些数据，服务器举行一些处置惩罚并返回该数据。
服务器流式 RPC

服务器流式 RPC，此中客户端向服务器发送单个哀求并渴望多个相应或相应流。 客户端从返回的流中读取，直到没有更多消息为止。
一个例子是视频流，您哀求加载视频，服务器相应视频流。
客户端流式 RPC

客户端流式 RPC，此中客户端写入一系列消息并将它们发送到服务器，再次使用提供的流。 客户端完成消息写入后，它会等候服务器读取消息并返反相应。
一个例子是将一个大文件上传到服务器，一旦全部数据发送完毕，客户端可以发送终极消息以指示上传完成，而且服务器可以选择相应。
双向流 RPC

客户端和服务器流媒体的组合。 谈天应用步调或多人视频游戏是数据必要在客户端和服务器之间自由运动的示例。
双向流式 RPC，双方使用读写流发送一系列消息。 这两个流独立运行，因此客户端和服务器可以按照他们喜好的任何序次举行读写。
在双向流式 RPC 中，调用由调用方法的客户端发起。 客户端和服务器端流处置惩罚是特定于应用步调的。 由于两个流是独立的，因此客户端和服务器可以按恣意序次读写消息。
微服务

gRPC 强大之处的一个很好的例子是在微服务中。

在这个例子中，我们有用 Python、Java 和 GoLang 编写的微服务，必要在它们之间发送数据。
使用 HTTP/1.1 和 JSON 将必要您为每种语言实现 HTTP 毗连和序列化。 您还必要确保为每种语言准确实行架构，如果 API 发生变革，则必要手动更新全部服务。
另一方面，gRPC 为我们处置惩罚了 HTTP/2.0 协议的实现。 编写单个模式，可以为全部使用的语言天生相应的代码。 这种模式可以看作是全部语言都必要服从的左券，这使这些服务之间的通讯更加轻易和可靠。
gRPC 性能

gRPC 速率很快，通常比 REST 等价物的性能高得多：

• 协议缓冲区被序列化并作为二进制文件通过网络发送，这比平常的 JSON 消息小得多。
  
• gRPC 使用 HTTP/2.0 进一步改进
  

gRPC 有用压缩发送的数据具有明显上风，由于传输的数据负载越小，必要的 TCP 来回次数就越少。 最大传输单元 (MTU) 是表现联网装备将继承的最大数据包的巨细，即 1,500 字节。
压缩是自动处置惩罚的，你只需使用 gRPC 就可以从中受益。 作为替换方案，可以在通过通例 HTTP 发送之前使用 GZIP 之类的东西来压缩 JSON 消息。 然而，这大概会带来未便，并增长了一层复杂性。 差异的语言和情况也大概对 GZIP 和其他等效压缩工具有差异级别的支持。 对于您使用的每种语言，您都必要自己重新实现准确的压缩和通讯逻辑。 这与我们讨论的有关 HTTP 库的题目雷同。
什么时间应该使用 gRPC？

如果您使用多种差异的编程语言，这些语言必要相互紧麋集成，而且必要快速频仍地发送大量数据的通讯，那么 gRPC 将是完善的选择。

• 长处：
  
  
  
  • 使用 gRPC 流式传输，可以轻松确定上传/下载进度，无需发出任何不须要的更新哀求。
    
  • 可以取消哀求。
    
  • HTTP/2 的全部长处。
    
  • 如果 gRPC 支持你的语言，你就不必引入外部库。
    
  
  
• 缺点：
  
  
  
  • gRPC 不支持全部语言。
    
  • 该架构大概会让人感到限定和贫苦。
    
  • 与 WebSockets 相比，它的设置大概很复杂。
    
  • 出现时间较晚，错误大概难以调试。
    
  • 与 gRPC 的通讯自己并不实用于 Web 欣赏器， 您必要使用 gRPC-Web 库。
    
  
  

WebRTC

WebRTC 特点

WebRTC 是一个免费的开源项目，可为基于开放尺度运行的应用步调提供及时通讯 (RTC) 功能。 它支持在对等点之间发送视频、语音和通用数据。
该技能作为一组实用于全部主流欣赏器的 JavaScript API 和实用于 Android 和 iOS 应用步调等本机客户端的库提供。
WebRTC根本上差异于 WebSockets 和 gRPC，一旦创建毗连，数据就可以（在某些情况下）直接在欣赏器和装备之间及时传输，而无需打仗服务器。
这镌汰了延伸并使 WebRTC 非常适当音频、视频或屏幕共享，低延伸而且可发送大量数据。
WebRTC 动机

WebRTC 旨在尺度化媒体（比方音频和视频）怎样通过线路举行通讯，并通过简朴易用的 API 方便地实现这一目的。
其他办理方案，比方 WebSockets，确实可以在两个对等点之间传输任何数据； 但是，此数据必要通过署理或服务器传输。 依赖另一台服务器会增长延伸，由于通过它发送的全部内容都必要汲取、处置惩罚息争密。对于视频流乃至及时谈天，这种延伸是不可取的。
现在的欣赏器也比几年前更强大。 欣赏器可以访问网络摄像头和麦克风，必要内置 API 和一种简朴的方法来传输这些丰富的信息。 WebRTC 旨在简化整个过程，并公开欣赏器本机可用的，易于使用的 API。
WebRTC 题目

动机已经明白，WebRTC 好像是一种神奇的办理方案，可以让两个对等方之间的通讯更快。 但不幸的是，存在一些题目。

• 第一个题目是创建点对点毗连并不简朴，互联网很复杂。加利福尼亚的 Alice 和南非的 Ben 之间有许多路由器、署理和防火墙。 在某些情况下，大概无法在两个对等点之间创建直线。 两个对等点之间的毗连大概必要绕过制止打开毗连的防火墙，您大概没有公共 IP 地点，大概路由器大概不答应对等点之间的直接毗连。
  
• 第二个题目是必要有一种方法让两个对等点相互发现并确定可以举行通讯的最佳路由。 这必要在两个客户端知道怎样最好地相互通讯之前在两个客户端之间共享某些信息，而共享此信息的一种常见方法是使用 WebSockets。
  

这有点可笑， 一个 HTTP 毗连升级为 WebSocket 毗连只是为了共享创建 WebRTC 毗连的信息。
如果您真的想相识 WebRTC 的功能及其复杂性，您必要熟悉一些大概不熟悉的术语：NAT、STUN、TURN、ICE、SDP 和信令。
WebRTC 是怎样工作的？

在上面的概述中，我们形貌了 WebRTC 的动机，本节将深入探究您必要相识的一些底层概念，以充实把握 WebRTC。
网络地点转换 (NAT)

相识 NAT 是什么以及它怎样工尴尬刁难于明白 WebRTC 至关紧张。NAT 用于为您的装备（条记本电脑或手机）提供公共 IP 地点； 这很紧张，由于我们要在大概都在路由器反面的两个对等点之间创建毗连。 路由器将有一个公共 IP 地点，毗连到路由器的每个装备都将有一个私有 IP 地点。
这些装备不直接袒露在互联网上。 相反，全部流量都通过与外界通讯的路由器。 当您从长途服务器哀求资源时，路由器负责将哀求从当地盘算机“路由”到该服务器，并将服务器的相应路由回当地盘算机。
这些哀求从装备的私有 IP 地点转换为具有唯一端口的路由器的公共 IP，然后存储在 NAT 表中。 如许，当地网络上的每个装备都没有须要拥有唯一的公共 IP。

上图是 NAT 表的简朴示例。 假设私有 IP 为 192.168.1.50 的当地装备哀求公共地点 82.88.31.26:80 获取一些数据。
这是通过当地装备起首向路由器发送哀求，路由器将哀求路由到长途装备来实现的。 路由器然后告诉长途装备将相应发送到其外部 IP 地点，具有唯一端口，在本例中为 86.88.71.25:8830。
这个唯一的端口很紧张，由于它将答应路由器确定发出哀求的当地装备。 全部这些信息都存储在 NAT 表中, 一旦路由器得到相应，它就可以实行查找并决定将相应转发到哪个当地装备。
当我们有一个正常的哀求/相应对，即一个装备和一个服务器时，这很轻易明白。 但是，如果另一个具有完全差异 IP 地点的外部装备决定将数据包发送到先前使用的同一端口上的路由器外部 IP 地点，会发生什么情况？ 路由器是否应该将其转发到映射到该端标语的当地装备？
该决定取决于路由器使用哪种 NAT 转换，并终极确定是否可以创建对等毗连。 根据您使用的路由器，它会实行差异的 NAT 转换。 有四种差异的 NAT 转换方法：

• 一对一 NAT
  
• 将一个外部 IP 地点和端口（通常是公共的）映射到一个内部 IP 地点和端口（通常是私有的）。 在上面的示例中，如果路由器在端口 8830 和外部 IP 86.88.71.25 上收到相应，它会将其转发到当地装备 192.168.1.50，由于这是发出哀求的当地装备（从 NAT 表中检索的信息 ). 路由器不关心目的 IP 或相应的泉源。 如果它在特定的外部端口上，它将转到该当地装备。
  
• 地点限定 NAT
  
• 仅当当地装备先前已将数据包发送到长途 IP 地点时，长途装备才华将数据包发送到当地装备。 总之，我们只有在之前与该主机通讯过的情况下才答应它。 在上面的例子中，只答应来自 86.88.71.25 的数据包
  
• 端口限定 NAT
  
• 与地点限定 NAT 雷同，但限定还包罗端标语。 如果内部装备先前已将数据包发送到 IP 地点 X 和端口 P，则长途装备只能将数据包发送到内部装备。在上面的示例中，仅答应来自 86.88.71.25 和端口 80。
  
• 对称 NAT
  
• 限定最严。 为此，外部 IP、外部端口、目的 IP 和目的端口都必须与 NAT 表中的内容相匹配。 这意味着数据包只能发送到当地装备的特定端口，条件是该装备是哀求目的 IP 和端口的装备。
  

WebRTC 不能在对称 NAT 上工作，要明白为什么我们必要明白什么是 STUN 服务器。
NAT 的会话遍历实用步调 (STUN)

STUN 是一种协议，可通过 NAT 告诉您您的公共 IP 地点/端口，并确定您的路由器中会制止与对等方直接毗连的任何限定。 STUN 服务器是一种机制，供客户端发现 NAT 的存在以及 NAT 的范例，并确定 NAT 的外部 IP 地点和端口映射。
一个 STUN 哀求的目的是确定你的公开存在，如许这个公开存在就可以与其他人互换，就可以与你接洽——这种互换被称为信号，我们将在反面详细讨论。
它实用于一对一、地点受限和端口受限的 NAT。 但不实用于对称 NAT。 由于当您向 STUN 服务器哀求您的公共信息时，该通讯对是专门为发出哀求的客户端创建的。 使用对称 NAT 不大概涉及另一个对等点——通过当地装备端口的通讯仅限于 STUN 服务器。
STUN 服务器重量轻，维护资源低。 有公共的 STUN 服务器可以免费查询。
下图阐明白 STUN 何时工作以及何时可以创建对等毗连。

另一方面，如果无法创建点对点毗连，比方，当对等点位于对称 NAT 之后时——那么第三步中的终极毗连将不会被答应。 由于初始毗连是与 STUN 服务器创建的，没有其他对等方可以使用该毗连信息。在无法创建直接毗连的情况下，我们必要使用 TURN 服务器。
使用中继绕过 NAT 的遍历（TURN）

TURN 是一种协议，用在无法在两个对等点之间创建直接毗连时中继网络流量。 比方，如果一个对等点位于对称 NAT 之后，则必要一台专用服务器来中继对等点之间的流量。 在那种情况下，您将创建一个与 TURN 服务器的毗连，并告诉全部对等方将数据包发送到该服务器，然后这些数据包将转发给您。
这会带来开销，而且 TURN 服务器的维护和运行资源大概很高。下图阐明白怎样使用 TURN 服务器在两个或多个对等点之间中继消息。

交互式毗连创建（ICE）

ICE 使用 STUN 和 TURN 协议的组合，为主机提供一种机制来发现相互的公共 IP 地点并创建直接毗连。 如果无法直接毗连，ICE 将使用 TURN 在两台主机之间创建中继毗连。
全部这些大概创建毗连的大概方式都称为 ICE 候选者。 全部网络到的地点都通过 SDP 发送到长途对等方，我们将在接下来举行探究。 WebRTC 在每个客户端上使用此信息来确定毗连到另一个对等点的最佳方式。 大概是两个对等点都在同一个 NAT 上而且可以创建当地毗连，大概大概是两个对等点都在对称 NAT 反面而且必要使用 TURN 服务器的中继。
会话形貌协议 (SDP)

SDP 本质上是一种形貌媒了解话的数据格式，用于会话公告、会话约请和其他情势的会话发起。 它是形貌毗连的多媒体内容的尺度，比方分辨率、格式、编解码器和加密。
紧张的是，它还用于形貌 ICE 候选人和其他网络选项。 当对等点 A 想要毗连到对等点 B 时，他们必要共享 SDP 信息才华毗连。 这个 SDP 怎样共享完全取决于——这被称为信令，我们将在接下来探究它。
Signaling-创建毗连

信令是在两个装备之间发送控制信息以确定通讯协议、信道、媒体编解码器和格式、数据传输方法以及任何所需路由信息的过程。 关于 WebRTC 的信令过程，最紧张的是要知道：它没有在规范中界说。
对等毗连处置惩罚毗连差异盘算机上的两个应用步调。 毗连是通过称为信令的发现和协商过程创建的。
一个紧张的告诫是 WebRTC 没有内置信号作为规范的一部分，由于两个装备不大概直接相互接洽，我们之前详细探究过这一点。 对于使用 WebRTC 毗连的两个对等点，它们必要相互的 SDP 数据。
因此，作为开辟职员，您有责任为两个装备创建一种共享此信息的方式。 一个盛行的选项是 WebSockets，大概可以通过电子邮件来回发送信令信息或步行转达并手动输入以创建毗连。
一旦共享了此信息，您就拥有了两个对等点创建 WebRTC 毗连所需的齐备，它大概是直接毗连，也大概是通过 TURN 服务器。
什么时间应该使用 WebRTC？

你乃至大概会问：我为什么要使用 WebRTC？ 明白起来好像很复杂，设置起来更复杂。但有许多利益：

• API 易于使用，可直接在您的欣赏器中使用。
  
• 它具有良好的性能，可以传输高带宽内容，比方视频或音频。
  
• 可以轻松实现更多高级功能，比方屏幕共享和文件共享。
  
• 支持镌汰延伸的点对点毗连。
  
• 免费和开源。
  

但是 WebRTC 也有缺点：

• 没有内置信号。
  
• 您必要维护 STUN 和 TURN 服务器。
  
• 对于群组毗连（比方群组视频通话），大概必要 SFU。
  
• 设置和明白起来很复杂。
  

HTTP、WebSockets、gRPC、WebRTC 怎样选择？

详细选择哪个协议要视情况而定，没有一个同一的答案，但是可以从宏观上对比下几种协议。
HTTP：使用 HTTP/2 可以在客户端和服务器之间举行双向通讯。 对于某些应用步调，您大概不必要全双工通讯，像 SSE 如许的东西就充足了。 我们在本文中也发现 WebSockets 和 gRPC 依赖于 HTTP，而 WebRTC 也必要一些其他的信令通道。 在深入研究这些其他协议之前，值得起首探索 HTTP 是否能满足您的实际需求。
WebSockets： 最适当必要双向通讯的及时应用步调，比方谈天应用步调， WebSockets 也相对轻易设置和使用。 但是，WebSockets 的服从不如 gRPC 或 WebRTC，它们不太适当必要发送大量数据的应用步调。
gRPC： 是一种比 WebSockets 更高效的协议，更适当必要发送大量数据的应用步调。 但是，gRPC 的设置和使用比 WebSockets 更复杂。 如果你必要举行许多小的 API 调用，gRPC 是一个不错的选择。 大概，当你用各种必要通讯的编程语言实现微服务时，那么 gRPC 的序列化布局化数据和代码天生会为你节流大量时间。 值得注意的是，您无法在欣赏器端轻松使用 gRPC，固然您可以手动引入 grpc-web。
WebRTC： 是欣赏器和装备之间低延伸及时通讯的最有用协议，非常适当必要发送大量数据的应用步调。 WebRTC 还提供了简朴易用的 API，可直接在欣赏器中使用，从而轻松共享您的相机、音频、屏幕或其他文件。 但是，WebRTC 的设置和使用大概很复杂，由于它必要您实行信号发送，维护 TURN 和 STUN 服务器。
结论

将来将会看到更多的协议、变革和进一步的改进。现在 HTTP/3 已经发布，尚有一个名为 WebTransport 的新通讯协议，它有大概替换 WebSockets。
翻译自：https://getstream.io/blog/communication-protocols/