HTTPWebSocketgRPC或WebRTC哪种协议最适

　　大家好，很高兴又见面了，我是高级前端进阶，由我带着大家一起关注前端前沿、深入前端底层技术，大家一起进步，也欢迎大家关注、点赞、收藏、转发！
　　高级前端进阶前言
　　在为您的应用程序选择通信协议时，有很多不同的选择。本文将了解四种流行的解决方案：HTTP、WebSocket、gRPC和WebRTC。我们将通过深入学习其背后原理、最佳用途及其优缺点来探索每个协议。
　　通信方式在不断改进：变得更快、更方便、更可靠，从使用信鸽发送信息，发展到邮政邮件，再到固定电话的发明，再到便携式移动设备。未来，甚至可能将会议和生日派对过渡到VR（但愿这只是个玩笑！）。
　　当然，最好的沟通方式总是要视情况而定。快速的短信有时比长的电子邮件更好。其他时候，与团队进行视频通话是交流信息的最佳方式，相比之下，重要的保险文件必须通过普通邮件发送并以纸质形式交付。而使用的网络技术和协议也是如此，不同的应用程序有不同的通信需求。1。概述
　　在本文中，我们将介绍一些可以作为开发人员使用的流行通信协议，并探讨不同协议的优缺点。正如开头所说，没有比另一个更好的解决方案，只有一些解决方案更适合特定的应用程序或问题。
　　一些应用程序需要点对点连接，具有低延迟和高数据传输，并且可以接受一些数据包（信息）丢失。有些应用程序可以根据需要轮询服务器，而不需要获取被轮询方的同等数据，有些应用程序需要具有数据可靠性的实时通信，诸如此类。
　　在线多人游戏、消息传递应用程序、博客网站、媒体库应用程序和视频会议软件都有不同的通信和数据需求。如果您正在构建视频流解决方案，那可能还有其他注意事项。2。什么是通信协议？
　　在计算机网络中，协议是一组规则，用于管理数据在设备之间的交换方式。该协议定义了通信的规则、语法、语义和同步以及可能的错误恢复方法。本文中讨论的协议定义了应用层软件如何相互交互。不同的协议遵循不同的规则，了解每个协议的优势和局限性至关重要。
　　在本文中，您将了解以下协议：HTTP（超文本传输协议）：是分布式协作和超媒体信息系统的应用协议。HTTP是万维网数据通信的基础，超文本是在包含文本的节点之间使用逻辑链接（超链接）的结构化文本。HTTP是交换或传输超文本的协议。HTTP2：旨在解决原始HTTP协议的缺点并提高性能。HTTP2比HTTP1。1更快、更高效，它支持多路复用，允许多个请求和响应在单个连接上进行多路复用。其他值得注意的功能包括标头压缩和服务器推送，它正逐渐成为网络流量的默认协议。WebSocket：是一种允许客户端和服务器之间进行双向通信的协议。它是处理实时数据应用程序的热门选择，例如聊天应用程序、在线游戏和实时数据流。gRPC：是一个使用HTTP2进行传输的现代开源RPC框架。对于需要进行大量小而快的API调用的应用程序来说，这是一个很好的选择。gRPC为多种语言生成跨平台的客户端和服务器绑定，使客户端应用程序可以直接调用不同机器上的服务器应用程序的方法，就好像它是本地方法一样。WebRTC：是一种允许客户端之间进行实时通信，并使得建立直接对等连接成为可能的技术。它用于视频、聊天、文件共享和实时视频流应用程序。3。了解TCP和UDP
　　在深入研究上述应用层之前，重要的是要对TCP和UDP有一个基本的了解，这两个底层传输层以根本不同的方式促进数据传输。TCP（传输控制协议）：是定义如何通过Internet建立和维护网络对话的标准。TCP是Internet和任何面向连接的网络上最常用的协议。当您浏览网页时，您的计算机会向网络服务器发送TCP数据包。Web服务器通过将TCP数据包发送回您的计算机来响应。在交换任何数据之前，首先在两个设备之间建立连接，并且TCP使用纠错来确保所有数据包都成功传递。如果数据包丢失或损坏，TCP将尝试重新发送它。UDP（用户数据报协议）：是一种无连接、不可靠的传输层协议。它不需要建立或维护连接，也不保证消息将按顺序传递。这意味着如果数据包未发送或损坏，可能会丢失一些数据。UDP通常用于流媒体或实时应用程序，在这些应用程序中，丢失数据包的问题比确保交付要少。4。HTTP1
　　对应用层所有基于互联网的通信和数据传输的基础HTTP（超文本传输协议）有一个基本的了解是很重要的。在更详细地探索其他协议并充分理解它们提供的功能之前，了解HTTP1及其局限性也很重要。
　　使用HTTP，客户端和服务器通过交换单独的消息进行通信。客户端发送的消息称为请求，服务器发送的消息称为响应。这些消息作为常规文本消息通过TCP连接发送。它们也可以使用TLS加密并使用HTTPS协议发送。
　　客户端通常是在用户手机或计算机上运行的Web浏览器或应用程序，但从技术上讲，它可以是任何东西，例如，抓取网站的脚本。HTTP请求只能沿一个方向流动，即从客户端到服务器。服务器无法发起与客户端的通信，它只能响应请求。
　　HTTP非常适合传统的Web和客户端应用程序，在这些应用程序中，信息是按需获取的。例如，你刷新了一个页面，向服务器发出了获取最新信息的请求。
　　在接下来的部分中，我们将探讨HTTP1的一些限制。4。1。HTTP1实时传输
　　当消息需要从客户端实时发送到服务器时，HTTP1效率低下。例如，如果服务器上有新信息需要与客户端共享，则此事务只能在客户端发起请求后发生。当然，也有一些解决方法，例如使用称为HTTP短轮询和长轮询以及服务器发送事件的技术。4。1。1短轮询
　　HTTP短轮询是一种客户端重复向服务器发送请求直到它响应新数据的技术。一旦它接收到数据，它就会再次启动该过程并反复询问，直到有其他可用的数据为止。
　　这是一种低效的实时通信策略，因为它通过持续传输和解析HTTP请求响应浪费了大量资源。4。1。2长轮询
　　使用HTTP长轮询，从客户端发出单个请求，然后服务器保持该连接打开，直到有新数据可用并且可以发送响应。客户端收到响应后，立即再次建立新的连接。
　　长轮询比短轮询更有效，但不是实时通信的最佳解决方案。4。1。3服务器发送的事件（SSE）
　　服务器发送的事件允许客户端保持打开的连接并实时从服务器接收推送消息，而不必不断地轮询服务器以获取新数据。这是一种单向连接，因此您无法将事件从客户端发送到服务器。
　　SSE是一种标准，描述了一旦建立了初始客户端连接，服务器如何启动向客户端的数据传输。4。2HTTP1的性能问题
　　大多数HTTP数据流由小的、密集的数据传输组成，而TCP针对长期连接和批量数据传输进行了优化。在大多数情况下，网络往返时间是TCP吞吐量和性能的限制因素。因此，延迟是性能瓶颈，大多数Web应用程序都可以克服它。
　　上面的意思是HTTP使用的TCP是为处理长期连接和传输大量数据而构建的。另一方面，HTTP1会打开一堆短暂的TCP连接，并且通常只发送小块数据。4。2。1队首阻塞
　　HTTP1。0的一个性能问题是您必须为每个请求响应打开一个新的TCP连接。对于HTTP最初发明的目的而言（获取超文本文档），这不是问题。文档部分很重要，因为HTTP并不意味着超媒体。
　　随着网络的发展，为每个请求打开一个新的TCP连接成为一个问题。我们开始构建完整的应用程序而不是简单的网页，浏览器需要检索的媒体和文件的数量变得更多。设想一个典型的Web应用程序需要HTML、CSS和JavaScript文件，以及各种图像和其他资产。对于每个文件，都必须建立一个新的连接。
　　随之而来的是HTTP1。1，它具有持久连接，它定义了可以在同一个TCP连接上有多个请求或响应。这个解决方案绝对是一个改进，但它不允许服务器同时返回多个响应。这是一个序列化协议，您必须在其中发送请求并等待响应，然后发送第二个请求，依此类推。这称为队头阻塞。
　　然而，实现某种并行性是可能的，因为浏览器最多可以打开六个（不同浏览器有差异）同一来源的TCP连接（其中来源被定义为主机和端口号的唯一组合）。
　　例如，如果您有一个需要加载12张图像的照片库应用程序，那么将发出六个请求来加载前六张图像，并且每个请求都会在后台打开一个新的TCP连接。其他六个图像将被阻止，直到收到响应并且打开的连接之一可用于加载下一个图像。最初的六个开放的同源TCP连接将在可用时被重用，但您仅限于六个活动连接。
　　很自然地，程序员找到了一个简单的解决方法改变图片源。不是在同一个源上托管所有资产，而是在一个源上托管六个图像，其余的在另一个源上。现在您可以有12个并发请求（或打开TCP连接），这被称为分片。图片16托管在1。images。com上图片712托管在2。images。com上
　　但是，您可以执行此操作的次数是有限制的，而且很难确定最佳的分片数量。在某些时候，添加更多分片会增加复杂性、增加开销，并可能导致链路拥塞和数据包丢失。
　　还有其他问题，因为每个TCP连接都会给服务器增加不必要的开销。连接相互竞争，每次TCP和TLS握手都会增加不必要的成本，并且必须使用其他服务器代理资源来维持活动连接。HTTP1使用底层TCP连接的方式有一个明显的限制。4。2。2标头（Headers）和Cookie爆炸
　　另一个问题是，随着HTTP规范的发展，规范中添加了更多的标头。开发人员还可以选择将cookie添加到标头，这些cookie可以任意大。这增加了很多大小，因为每个请求和响应都需要传输所有这些文本信息，并且HTTP1。1不包含压缩标头和元数据的机制。
　　如果您需要一个高性能的RPC协议，这种开销会变得更大，此时HTTP不再是最佳解决方案。4。2。3优先级（Prioritization）
　　在HTTP1。1中，浏览器通过在客户端持有一个优先级队列来确定资源的优先级，并对如何充分利用可用的TCP连接进行有根据的猜测。浏览器嵌入了启发式方法，用于确定哪些资源比其他资源更有价值。
　　例如，加载CSS将比加载图像具有更高的优先级。问题在于，作为开发人员，您无法确定一个请求的优先级高于另一个请求或更改正在进行的消息的优先级。首先加载什么内容取决于浏览器，您对优先级方案没有发言权。5。HTTP25。1HTTP2的优点
　　HTTP2是HTTP协议的改进版本，解决了上述HTTP1的所有性能问题，并在不改变任何语义（标头等）的情况下添加了其他增强功能。
　　HTTP2中最显着的变化是使用多路复用。通过单个TCP连接同时发送和接收多个HTTP请求和响应。所有HTTP2连接都是持久的，每个源只需要一个连接。这允许更有效地使用网络资源，并可以显着提高应用程序的性能。
　　HTTP2的其他一些好处：使用标头压缩来减小标头的大小，从而避免一遍又一遍地发送相同的纯文本标头。这显着减少了请求响应的开销和发送的数据量。启用优先级，允许客户端（开发人员）指定其所需资源的优先级。也可以更新正在进行的请求的优先级例如，在滚动时，如果图像不再可见，则优先级可以改变。使用服务器推送，在客户端请求之前将数据发送到客户端。这可用于通过消除客户端发出多个请求的需要来缩短加载时间。5。2HTTP2是如何工作的？
　　HTTP2中的基本协议单元是帧。这种新的二进制帧机制改变了客户端和服务器之间的数据交换方式。
　　该标准定义了十种不同的帧类型，每种都有不同的用途。例如，HEADERS和DATA帧构成了HTTP请求和响应的基础：
　　帧是承载特定类型数据的最小通信单位。其他一些帧示例是：设置（SETTINGS）：在开始或连接期间交换设置信息。优先级（PRIORITY）：重新分配消息的优先级。PUSHPROMISE：允许服务器向您推送数据，这是对服务器将发送的内容的承诺。例如，如果您请求index。html，服务器可以创建一个PUSHPROMISE来承诺推送app。js和styles。css，这意味着客户端不需要主动请求这些资源。
　　帧组合在一起形成消息，例如上图中的标题和数据帧。这等同于正常的请求或响应。最后，一系列消息可以成为流的一部分。这允许客户端和服务器之间的双向数据流以及完整的请求和响应多路复用。
　　上图有点误导，给人的印象是客户端和服务器之间打开了多个连接。但它是单个TCP连接，数据以非阻塞方式在客户端和服务器之间自由流动。
　　新的二进制框架层允许客户端和服务器将HTTP消息分解为独立的帧，组合发送，然后在另一端重新组合它们。这只是HTTP2。0工作原理的总结。如果您想了解更多信息并探索优先级排序、服务器推送和标头压缩，请参阅文末资料。5。3HTTP2双向数据流
　　HTTP2规范表明：流是在HTTP2连接中客户端和服务器之间交换的独立地、双向帧序列。
　　流有几个重要的特征：单个HTTP2连接可以包含多个并发打开的流，其中任一端点交错来自多个流的帧。流可以单方面建立和使用，也可以由客户端或服务器共享。流可以被任一端点关闭。
　　服务器推送功能存在很多误解，它允许服务器通过HTTP2主动发送它认为您可能需要的资源，例如。js和。css文件，而无需客户端请求。这与双向流无关，只是一种针对可缓存资源的Web优化技术。
　　事实是，对于HTTP2服务器无法启动流。但是一旦客户端通过发送请求打开一个流，双方就可以随时通过持久套接字发送数据帧。一个很好的例子是gRPC，我们将在后面讨论。
　　使用HTTP2，可以实现双向数据流，你可以争辩说它是比WebSockets之类的东西更优化的解决方案，或者你可以争辩说它不是。我们将在WebSocket部分更详细地讨论这个问题。6。WebSockets6。1WebSockets规范说明
　　来自WebSocket协议规范：该技术的目标是为基于浏览器的应用程序提供一种机制，这些应用程序需要与不依赖于打开多个HTTP连接的服务器进行双向通信（例如，使用XMLHttpRequest或iframe和长轮询）。
　　WebSockets的发明是为了实现客户端和服务器之间的全双工通信，这允许数据立即通过单个打开的连接双向传输。
　　建立WebSocket连接后，客户端无需轮询服务器以获取更新。相反，通信是双向发生的。与HTTP1的原始长轮询和短轮询相比，这提高了速度和实时能力。WebSocket没有特定要遵循的数据格式，您可以使用它发送任何数据、文本或字节，这种灵活性是WebSockets流行的原因之一。
　　其中一些内容听起来可能与我们在HTTP2部分中讨论的内容很熟悉，但重要的是要注意WebSockets是在HTTP2之前很久就发明的。稍后我们将对它们进行更多比较。6。2WebSockets如何工作？
　　WebSockets底层基于TCP的传输层运行。要建立WebSocket连接，客户端和服务器首先需要通过正常的HTTP1。1连接执行握手。此握手是从HTTP升级到WebSockets的桥梁。
　　下面是一个示例客户端握手请求。客户端可以使用称为升级标头的HTTP1。1机制将其连接从HTTP切换到WebSockets：GETchatHTTP1。1Host：example。com：8000Upgrade：websocketConnection：UpgradeSecWebSocketKey：dGhlIHNhbXBsZSBub25jZQSecWebSocketVersion：13
　　然后服务器将用一个特殊的响应结束握手，该响应表明协议将从HTTP更改为WebSocket：HTTP1。1101SwitchingProtocolsUpgrade：websocketConnection：UpgradeSecWebSocketAccept：s3pPLMBiTxaQ9kYGzzhZRbKxOo
　　WebSockets需要具有ws：或wss：方案的统一资源标识符（URI）。ws：方案用于未加密连接，wss：方案用于加密连接，类似于HTTPURL使用http：或https：方案的方式。
　　一旦建立了双向通信通道，客户端和服务器就可以来回发送消息。这些消息可以是从二进制数据到文本的任何内容。WebSocket连接将保持打开状态，直到客户端或服务器断开连接。6。3WebSocket多路复用
　　在撰写本文时，WebSocket协议不支持内置多路复用。我们在HTTP2部分讨论了多路复用，了解到它是HTTP2的内置功能，并且可以在同一连接上多路复用多个流。每个流都有一个唯一的标识符，所有发送的帧都有一个与相应流关联的ID。
　　不支持多路复用意味着WebSocket协议需要为每个WebSocket连接建立一个新的传输连接。例如，在同一浏览器的不同选项卡中运行的多个客户端将使用单独的连接。要在WebSockets上进行多路复用，您通常需要依赖第三方插件或库。6。4WebSocket与HTTP2
　　HTTP2取代了WebSockets了吗？答案是不！
　　HTTP2使双向流成为可能，这使得WebSockets不是唯一最佳选择。与WebSockets相比，HTTP2作为规范为您做了更多的工作。它具有内置的多路复用功能，在大多数情况下，将导致与源站建立的TCP连接更少。另一方面，WebSockets提供了很大的自由度，并且在建立连接后如何在客户端和服务器之间发送数据方面没有限制。但是，您需要自己管理重新连接（或依赖为您执行此操作的库）。
　　至于那个更好，本文不给出答案，每个人有每个人的看法。WebSockets提供了很大的灵活性，并且作为一个既定标准，它得到所有现代浏览器的完全支持，并且围绕客户端和服务器库的生态系统是强大的。有关更详细和自以为是的讨论，请参阅这些StackOverflow问题：HTTP2是否让WebSocket过时了用于低延迟客户端到服务器消息的HTTP2或Websockets用于双向消息流的HTTP2与网络套接字
　　还有一个RFC允许在HTTP2连接的单个流上运行WebSocket协议的机制。能够从HTTP2引导WebSockets，即允许两个协议共享一个TCP连接，并将HTTP2对网络的更有效使用扩展到WebSockets。这已在Chrome和Firefox中实现。您可以在此处阅读Chrome设计文档和动机。6。5什么时候使用WebSocket？
　　Websockets最适合需要实时双向通信的应用程序，以及需要快速传输小块数据的应用程序：聊天应用多人游戏协作编辑应用程序直播体育赛事股票交易应用实时活动提要
　　对于服务器发送事件（SSE），在HTTP2上非常高效且易于使用。SSE不是双向通信系统；服务器单方面向客户端推送数据。但是，如果您所需要的只是服务器向客户端发送数据的一种方式，那么这可能是比使用WebSockets更好的选择。当HTTP2不可用时，SSE也会回退到HTTP1。1。此外，客户端（或浏览器）为您管理连接并支持自动重新连接。
　　如果通过WebSockets的连接丢失，则不包含用于负载平衡或重新连接的机制。这必须手动或由第三方库实现。6。gRPC
　　gRPC是一个现代开源高性能远程过程调用（RPC）框架，可以在任何环境中运行。它可以通过对负载平衡、跟踪、健康检查和身份验证的可插拔支持，有效地连接数据中心内和跨数据中心的服务。它还适用于分布式计算的最后一英里，将设备、移动应用程序和浏览器连接到后端服务。
　　gRPC是一个开源的、基于约定的RPC系统，最初由谷歌开发。gRPC使应用程序能够透明地通信并简化连接系统的构建。它为多种语言生成跨平台的客户端和服务器绑定，使客户端应用程序可以直接调用不同机器上服务器应用程序的方法，就好像它是本地对象一样。
　　gRPC基于HTTP2构建，利用双向流和内置传输层安全性（TLS）等功能。6。1gRPC动机
　　深入了解gRPC背后的动机、发明它的原因以了解其好处非常重要。为什么不使用我们已经拥有的现有技术：例如HTTP2和WebSockets？为什么我们需要在已有的能力之上再抽象一层？
　　可以通过多种方式构建数据并通过Internet发送数据。一些流行的例子是SOAP、REST和GraphQL。您甚至可以创建自己的协议，通过原始TCP发送数据，并根据需要自行处理实现。
　　但无论您选择什么作为您的通信协议，问题在于您需要确保客户端和服务器就该协议达成一致。例如，如果您正在构建RESTAPI，则需要用于发送REST数据的客户端库是HTTP库。HTTP库默认内置于浏览器中，浏览器会为您处理一切：它与服务器建立通信。它处理HTTP2并回退到HTTP1，并且将来需要支持HTTP3。它处理TLS并协商协议。它处理标头、流和其他所有内容。
　　但是，如果您不在浏览器上怎么办？如果您是在某个服务器上运行的Python应用程序、GoLangCLI或在iOS上运行的Flutter应用程序怎么办？所有这些客户端都需要自己的HTTP库，该库可以理解您正在与之通信的协议。
　　幸运的是，许多人正在为所有这些语言和框架开发各种HTTP库。有些语言甚至有多个具有不同特性的HTTP库。然而，所有这一切都是有代价的，那就是维护。
　　如果您要将服务器升级到HTTP2（如果您使用的GoLang库支持它），此成本可能会影响您。但是，在您的前端Python客户端上，等效的HTTP库尚未实现HTTP2，或者可能不再维护。
　　随着HTTP规范的发展，这些库必须同步更新，如安全问题、新功能等。HTTP只是一个例子，对于WebSocket协议或任何其他协议也是如此。有些东西可能在主流浏览器中得到很好的实现，但该功能必须移植到多种不同的语言和框架中。6。2gRPC有何不同？
　　gRPC试图通过维护流行语言本身的库来解决这个问题，这意味着所有这些语言都将支持添加的新功能。
　　gRPC使用HTTP2作为其协议，但是，这个实现对您是无感的。将来，gRPC的维护者可以轻松地将HTTP2替换为HTTP3，您将立即从该更改中受益。
　　gRPC还使用协议缓冲区作为接口定义语言（IDL）及其底层消息交换格式。这种格式是语言中立的，可以轻松地在不同的编程语言之间进行通信。我们将在下一节中更多地探讨这个概念。
　　6。3什么是协议缓冲区？
　　Protocolbuffers是Google设计的语言中立、平台中立、可扩展的结构化数据序列化机制想想XML，但更小、更快、更简单。您一次性定义了数据的结构方式。然后，您可以使用特殊生成的源代码轻松地将结构化数据写入各种数据流并使用各种语言从中读取结构化数据。
　　在API机制的设定中，您通常无需关心协议本身。例如，如果您使用的是REST，您通常只是发送带有键值对的JSON消息，直到消息到达接收端才进行检查。此消息通常可以是任何内容，由您来确保定义了正确的结构。
　　查看以下JSON数据（payload）：｛id：123，name：Gordon，email：gordonsomewhere。io｝
　　在客户端服务器上接收到此数据，就可以将其反序列化为一个对象，例如：classPerson｛intid；Stringname；Stringemail｝
　　但是，作为开发人员，您需要为上述数据实现正确的序列化和反序列化逻辑这可能涉及手动编写toJson和fromJson方法，可以依赖于代码生成，或者它可能是你正在使用的语言。
　　无论您如何序列化此数据，底层代码都需要手动更新，可能在多个环境中，以防模式发生变化。而使用协议缓冲区，您可以创建一个模式来定义字段的对象类型并指定哪些是必需的，哪些是可选的：Therequestmessagecontainingtheperson’sinformationMessagePerson｛optionalint32id1；requiredstringname2；optionalstringemail3；｝TheresponsemessagecontainingthegreetingsmessageHelloReply｛stringmessage1；｝
　　然后您可以指定对外的方法：Thegreetingservicedefinition。serviceGreeter｛SendsagreetingrpcSayHello（Person）returns（HelloReply）｛｝｝
　　一旦您指定了数据结构和模式，您就可以使用协议缓冲区编译器将protoc从您的proto定义中，以您的首选语言生成数据访问类。这些是描述proto文件中概述对象的接口，每个字段都有访问器，以及将整个结构序列化解析为原始字节的方法。6。4gRPC模式
　　gRPC有四种传输方式，这四种模式实现了之前讨论的行为，例如，正常的请求响应、SSE和WebSockets。6。4。1一元RPC
　　一元RPC是简单的请求和响应，类似于调用函数。客户端请求一些数据，服务器进行一些处理并返回该数据。6。4。2服务器流式RPC
　　服务器流式RPC，其中客户端向服务器发送单个请求并期望多个响应或响应流。客户端从返回的流中读取，直到没有更多消息为止。
　　一个例子是视频流，您请求加载视频，服务器响应视频流。6。4。3客户端流式RPC
　　客户端流式RPC，其中客户端写入一系列消息并将它们发送到服务器，再次使用提供的流。客户端完成消息写入后，它会等待服务器读取消息并返回响应。
　　一个例子是将一个大文件上传到服务器，一旦所有数据发送完毕，客户端可以发送最终消息以指示上传完成，并且服务器可以选择响应。6。4。4双向流RPC
　　客户端和服务器流媒体的组合。聊天应用程序或多人视频游戏是数据需要在客户端和服务器之间自由流动的示例。
　　双向流式RPC，双方使用读写流发送一系列消息。这两个流独立运行，因此客户端和服务器可以按照他们喜欢的任何顺序进行读写。
　　在双向流式RPC中，调用由调用方法的客户端发起。客户端和服务器端流处理是特定于应用程序的。由于两个流是独立的，因此客户端和服务器可以按任意顺序读写消息。6。5微服务
　　gRPC强大之处的一个很好的例子是在微服务中。
　　在这个例子中，我们有用Python、Java和GoLang编写的微服务，需要在它们之间发送数据。
　　使用HTTP1。1和JSON将需要您为每种语言实现HTTP连接和序列化。您还需要确保为每种语言正确实施架构，如果API发生变化，则需要手动更新所有服务。
　　另一方面，gRPC为我们处理了HTTP2。0协议的实现。编写单个模式，可以为所有使用的语言生成相应的代码。这种模式可以看作是所有语言都需要遵守的契约，这使这些服务之间的通信更加容易和可靠。6。6gRPC性能
　　gRPC速度很快，通常比REST等价物的性能高得多：协议缓冲区被序列化并作为二进制文件通过网络发送，这比普通的JSON消息小得多。gRPC使用HTTP2。0进一步改进
　　gRPC有效压缩发送的数据具有显著优势，因为传输的数据负载越小，需要的TCP往返次数就越少。最大传输单元（MTU）是表示联网设备将接受的最大数据包的大小，即1，500字节。
　　压缩是自动处理的，你只需使用gRPC就可以从中受益。作为替代方案，可以在通过常规HTTP发送之前使用GZIP之类的东西来压缩JSON消息。然而，这可能会带来不便，并增加了一层复杂性。不同的语言和环境也可能对GZIP和其他等效压缩工具有不同级别的支持。对于您使用的每种语言，您都需要自己重新实现正确的压缩和通信逻辑。这与我们讨论的有关HTTP库的问题类似。6。7什么时候应该使用gRPC？
　　如果您使用多种不同的编程语言，这些语言需要彼此紧密集成，并且需要快速频繁地发送大量数据的通信，那么gRPC将是完美的选择。优点：使用gRPC流式传输，可以轻松确定上传下载进度，无需发出任何不必要的更新请求。可以取消请求。HTTP2的所有优点。如果gRPC支持你的语言，你就不必引入外部库。缺点：gRPC不支持所有语言。该架构可能会让人感到限制和麻烦。与WebSockets相比，它的设置可能很复杂。出现时间较晚，错误可能难以调试。与gRPC的通信本身并不适用于Web浏览器，您需要使用gRPCWeb库。7。WebRTC7。1WebRTC特点
　　WebRTC是一个免费的开源项目，可为基于开放标准运行的应用程序提供实时通信（RTC）功能。它支持在对等点之间发送视频、语音和通用数据。
　　该技术作为一组适用于所有主流浏览器的JavaScriptAPI和适用于Android和iOS应用程序等本机客户端的库提供。WebRTC根本上不同于WebSockets和gRPC，一旦建立连接，数据就可以（在某些情况下）直接在浏览器和设备之间实时传输，而无需接触服务器。
　　这减少了延迟并使WebRTC非常适合音频、视频或屏幕共享，低延迟并且可发送大量数据。7。2WebRTC动机
　　WebRTC旨在标准化媒体（例如音频和视频）如何通过线路进行通信，并通过简单易用的API方便地实现这一目标。
　　其他解决方案，例如WebSockets，确实可以在两个对等点之间传输任何数据；但是，此数据需要通过代理或服务器传输。依赖另一台服务器会增加延迟，因为通过它发送的所有内容都需要接收、处理和解密。对于视频流甚至实时聊天，这种延迟是不可取的。
　　现在的浏览器也比几年前更强大。浏览器可以访问网络摄像头和麦克风，需要内置API和一种简单的方法来传输这些丰富的信息。WebRTC旨在简化整个过程，并公开浏览器本机可用的，易于使用的API。7。3WebRTC问题
　　动机已经明确，WebRTC似乎是一种神奇的解决方案，可以让两个对等方之间的通信更快。但不幸的是，存在一些问题。第一个问题是建立点对点连接并不简单，互联网很复杂。加利福尼亚的Alice和南非的Ben之间有很多路由器、代理和防火墙。在某些情况下，可能无法在两个对等点之间建立直线。两个对等点之间的连接可能需要绕过阻止打开连接的防火墙，您可能没有公共IP地址，或者路由器可能不允许对等点之间的直接连接。第二个问题是需要有一种方法让两个对等点相互发现并确定可以进行通信的最佳路由。这需要在两个客户端知道如何最好地相互通信之前在两个客户端之间共享某些信息，而共享此信息的一种常见方法是使用WebSockets。
　　这有点好笑，一个HTTP连接升级为WebSocket连接只是为了共享建立WebRTC连接的信息。
　　如果您真的想了解WebRTC的功能及其复杂性，您需要熟悉一些可能不熟悉的术语：NAT、STUN、TURN、ICE、SDP和信令。7。4WebRTC是如何工作的？
　　在上面的概述中，我们描述了WebRTC的动机，本节将深入探讨您需要了解的一些底层概念，以充分掌握WebRTC。7。4。1网络地址转换（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和外部IP86。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服务器。7。4。2NAT的会话遍历实用程序（STUN）
　　STUN是一种协议，可通过NAT告诉您您的公共IP地址端口，并确定您的路由器中会阻止与对等方直接连接的任何限制。STUN服务器是一种机制，供客户端发现NAT的存在以及NAT的类型，并确定NAT的外部IP地址和端口映射。
　　一个STUN请求的目的是确定你的公开存在，这样这个公开存在就可以与其他人交流，就可以与你联系这种交流被称为信号，我们将在后面详细讨论。
　　它适用于一对一、地址受限和端口受限的NAT。但不适用于对称NAT。因为当您向STUN服务器请求您的公共信息时，该通信对是专门为发出请求的客户端创建的。使用对称NAT不可能涉及另一个对等点通过本地设备端口的通信仅限于STUN服务器。
　　STUN服务器重量轻，维护成本低。有公共的STUN服务器可以免费查询。
　　下图说明了STUN何时工作以及何时可以建立对等连接。
　　另一方面，如果无法建立点对点连接，例如，当对等点位于对称NAT之后时那么第三步中的最终连接将不会被允许。由于初始连接是与STUN服务器建立的，没有其他对等方可以使用该连接信息。在无法建立直接连接的情况下，我们需要使用TURN服务器。7。4。3使用中继绕过NAT的遍历（TURN）
　　TURN是一种协议，用在无法在两个对等点之间建立直接连接时中继网络流量。例如，如果一个对等点位于对称NAT之后，则需要一台专用服务器来中继对等点之间的流量。在那种情况下，您将创建一个与TURN服务器的连接，并告诉所有对等方将数据包发送到该服务器，然后这些数据包将转发给您。
　　这会带来开销，并且TURN服务器的维护和运行成本可能很高。下图说明了如何使用TURN服务器在两个或多个对等点之间中继消息。
　　7。4。4交互式连接建立（ICE）
　　ICE使用STUN和TURN协议的组合，为主机提供一种机制来发现彼此的公共IP地址并建立直接连接。如果无法直接连接，ICE将使用TURN在两台主机之间建立中继连接。
　　所有这些可能建立连接的可能方式都称为ICE候选者。所有收集到的地址都通过SDP发送到远程对等方，我们将在接下来进行探讨。WebRTC在每个客户端上使用此信息来确定连接到另一个对等点的最佳方式。可能是两个对等点都在同一个NAT上并且可以建立本地连接，或者可能是两个对等点都在对称NAT后面并且需要使用TURN服务器的中继。7。4。5会话描述协议（SDP）
　　SDP本质上是一种描述媒体会话的数据格式，用于会话公告、会话邀请和其他形式的会话发起。它是描述连接的多媒体内容的标准，例如分辨率、格式、编解码器和加密。
　　重要的是，它还用于描述ICE候选人和其他网络选项。当对等点A想要连接到对等点B时，他们需要共享SDP信息才能连接。这个SDP如何共享完全取决于这被称为信令，我们将在接下来探讨它。7。4。6Signaling建立连接
　　信令是在两个设备之间发送控制信息以确定通信协议、信道、媒体编解码器和格式、数据传输方法以及任何所需路由信息的过程。关于WebRTC的信令过程，最重要的是要知道：它没有在规范中定义。
　　对等连接处理连接不同计算机上的两个应用程序。连接是通过称为信令的发现和协商过程建立的。
　　一个重要的警告是WebRTC没有内置信号作为规范的一部分，因为两个设备不可能直接相互联系，我们之前详细探讨过这一点。对于使用WebRTC连接的两个对等点，它们需要彼此的SDP数据。
　　因此，作为开发人员，您有责任为两个设备建立一种共享此信息的方式。一个流行的选项是WebSockets，或者可以通过电子邮件来回发送信令信息或步行传递并手动输入以建立连接。
　　一旦共享了此信息，您就拥有了两个对等点建立WebRTC连接所需的一切，它可能是直接连接，也可能是通过TURN服务器。7。5什么时候应该使用WebRTC？
　　你甚至可能会问：我为什么要使用WebRTC？理解起来似乎很复杂，设置起来更复杂。但有很多好处：API易于使用，可直接在您的浏览器中使用。它具有良好的性能，可以传输高带宽内容，例如视频或音频。可以轻松实现更多高级功能，例如屏幕共享和文件共享。支持减少延迟的点对点连接。免费和开源。
　　但是WebRTC也有缺点：没有内置信号。您需要维护STUN和TURN服务器。对于群组连接（例如群组视频通话），可能需要SFU。设置和理解起来很复杂。8。HTTP、WebSockets、gRPC、WebRTC如何选择？
　　具体选择哪个协议要视情况而定，没有一个统一的答案，但是可以从宏观上对比下几种协议。
　　HTTP：使用HTTP2可以在客户端和服务器之间进行双向通信。对于某些应用程序，您可能不需要全双工通信，像SSE这样的东西就足够了。我们在本文中也发现WebSockets和gRPC依赖于HTTP，而WebRTC也需要一些其他的信令通道。在深入研究这些其他协议之前，值得首先探索HTTP是否能满足您的实际需求。
　　WebSockets：最适合需要双向通信的实时应用程序，例如聊天应用程序，WebSockets也相对容易设置和使用。但是，WebSockets的效率不如gRPC或WebRTC，它们不太适合需要发送大量数据的应用程序。
　　gRPC：是一种比WebSockets更高效的协议，更适合需要发送大量数据的应用程序。但是，gRPC的设置和使用比WebSockets更复杂。如果你需要进行很多小的API调用，gRPC是一个不错的选择。或者，当你用各种需要通信的编程语言实现微服务时，那么gRPC的序列化结构化数据和代码生成会为你节省大量时间。值得注意的是，您无法在浏览器端轻松使用gRPC，当然您可以手动引入grpcweb。
　　WebRTC：是浏览器和设备之间低延迟实时通信的最有效协议，非常适合需要发送大量数据的应用程序。WebRTC还提供了简单易用的API，可直接在浏览器中使用，从而轻松共享您的相机、音频、屏幕或其他文件。但是，WebRTC的设置和使用可能很复杂，因为它需要您执行信号发送，维护TURN和STUN服务器。9。结论
　　未来将会看到更多的协议、变化和进一步的改进。目前HTTP3已经发布，还有一个名为WebTransport的新通信协议，它有可能替代WebSockets。参考资料
　　https：github。comgrpcgrpcweb
　　https：web。devwebtransport
　　https：levelup。gitconnected。comhttpwebsocketgrpcorwebrtcwhichcommunicationprotocolisbestforyourapp1cc5a0786c86
　　https：web。devperformancehttp2
　　https：developer。mozilla。orgenUSdocsWebAPIServersenteventsUsingserversentevents
　　https：medium。comagoraiohowdoeswebrtcwork996748603141
　　https：getstream。ioblogstreamingprotocols
　　https：getstream。ioblogpeertopeervideoconferencing
　　https：www。rfceditor。orgrfcrfc8441
　　https：chromestatus。comfeature6251293127475200
　　https：docs。google。comdocumentd1ZxaHz4j2BDMa1aI5CQHMjtFI3UxGT459pjYv4To9rFYedit
　　https：zhuanlan。zhihu。comp421503695