【知识拓展】HTTP、WebSocket 和 RPC：区别与使用场景详解

        在工作中，HTTP、WebSocket 和 RPC 是三种常见的协议或通信方式，根据资料查阅，本文主要记录它们的区别及其适用的使用场景

HTTP（超文本传输协议）

概述

HTTP（Hypertext Transfer Protocol）是一种用于分布式、协作、超媒体信息系统的应用层协议。它是万维网（WWW）的基础，通过它，客户端（通常是浏览器）和服务器之间可以进行通信。

特性

• 无状态：每个请求都是独立的，服务器不会保留任何会话信息。
• 请求-响应模式：客户端发起请求，服务器返回响应。
• 文本协议：数据以纯文本形式传输，包括头部和主体。
• 标准端口：默认使用端口80（HTTP）和443（HTTPS）。

使用场景

• 网页浏览：用户通过浏览器请求网页资源（HTML、CSS、JavaScript、图片等），服务器响应这些资源。
• API调用：客户端通过HTTP请求与服务器交互数据（例如RESTful API）。
• 文件下载：用户通过HTTP下载文件，如软件、文档等。

WebSocket协议

概述

WebSocket是一种在单个TCP连接上进行全双工通信的协议。它由HTML5引入，旨在解决HTTP的实时性和效率问题。

特性

• 全双工通信：允许客户端和服务器同时发送和接收消息。
• 持久连接：连接一旦建立，将保持打开状态，直到显式关闭。
• 低开销：较少的头部信息，使得数据传输效率更高。
• 实时性：非常适合需要低延迟和实时更新的应用。

使用场景

• 实时聊天应用：如即时通讯工具（微信、WhatsApp）。
• 在线游戏：需要低延迟和实时交互的多人在线游戏。
• 实时数据推送：如股票行情、体育比分更新。
• 协作编辑工具：如Google Docs，多个用户同时编辑文档时的实时同步。

RPC（远程过程调用）

概述

RPC（Remote Procedure Call）是指远程过程调用，也就是说两台服务器A，B，一个应用部署在A服务器上，想要调用B服务器上应用提供的函数/方法，由于不在一个内存空间，不能直接调用，需要通过网络来表达调用的语义和传达调用的数据。

RPC的核心并不在于使用什么协议。目的是让你在本地调用远程的方法，而对你来说这个调用是透明的，你并不知道这个调用的方法是部署哪里。

通过RPC能解耦服务，这才是使用RPC的真正目的。RPC的原理主要用到了动态代理模式，至于http协议，只是传输协议而已。简单的实现可以参考spring remoting，复杂的实现可以参考dubbo。

特性

• 透明性：调用远程服务的方式与本地调用几乎无异，隐藏了底层通信细节。
• 协议无关：可以基于多种协议实现（如HTTP、TCP、UDP）。
• 同步/异步：可以支持同步调用和异步调用。
• 数据序列化：通常使用JSON、XML或二进制格式进行数据编码和解码。

使用场景

• 分布式系统：如微服务架构中不同服务之间的通信。
• 跨语言调用：不同编程语言编写的服务之间进行通信。
• 高性能服务：需要高效、低延迟的远程服务调用，如金融系统的交易处理。

详细比较

使用场景详解

HTTP 使用场景

HTTP协议是互联网的基石，主要用于浏览器与服务器之间的通信。典型的使用场景包括：

• 网页浏览：用户通过浏览器访问网页，浏览器向服务器发送HTTP请求，服务器返回HTML、CSS、JS等资源。
• RESTful API：在前后端分离的架构中，前端通过HTTP请求与后端API服务器进行数据交互。
• 文件下载：用户通过HTTP协议下载各种类型的文件，如文档、图片、软件等。

WebSocket 使用场景

WebSocket协议适用于需要实时数据传输的应用场景。典型的使用场景包括：

• 即时通讯：如聊天应用和社交媒体消息系统，要求低延迟和实时消息传输。
• 实时更新：如股票市场行情、体育比分更新，需要实时推送数据给用户。
• 在线协作：如多人同时编辑文档、代码，实时同步用户操作。
• 在线游戏：需要低延迟的实时交互游戏，如多人在线竞技游戏。

RPC 使用场景

RPC协议用于分布式系统中远程服务调用。典型的使用场景包括：

• 微服务架构：在微服务架构中，各个服务之间需要通过RPC进行通信和数据交互。
• 跨语言调用：不同语言编写的服务之间可以通过RPC进行通信，如Java服务调用Python服务。
• 高性能计算：在需要高效、低延迟的系统中，RPC用于远程函数调用，如金融交易系统中的交易处理。

一些问题

什么是RPC框架，有哪些好处？

        可以理解为RPC框架是一种软件框架或者库，用于简化在不同计算机或者进程之间进行远程调用的过程。

        如果是一个大型的网站，内部子系统较多、接口非常多的情况下，RPC框架的好处就显示出来了：首先就是长链接，不必每次通信都要像http一样去3次握手什么的，减少了网络开销等。

1. 性能

• HTTP：HTTP请求每次都需要建立连接（除非使用HTTP/1.1的持久连接），并且每次请求和响应都包含较多的头部信息。这些都会带来额外的开销，影响性能。
• RPC：通常使用长连接，减少了连接建立的开销。RPC可以基于更高效的传输协议（如TCP或gRPC），从而降低延迟和提高传输效率。

2. 数据格式

• HTTP：常使用文本格式（如JSON、XML）进行数据传输，解析这些格式需要额外的计算资源，尤其是在高频通信时。
• RPC：可以使用二进制格式进行数据传输（如Protocol Buffers），这不仅节省带宽，还减少了序列化和反序列化的开销。

3. 透明性和易用性

• HTTP：需要开发者手动构建请求和处理响应，这在复杂系统中会增加代码量和维护成本。
• RPC：通过抽象远程调用过程，使得调用远程服务就像调用本地函数一样，隐藏了底层通信细节，提高了代码的可读性和维护性。

4. 功能和特性

• HTTP：主要用于无状态的请求-响应模式，缺乏一些高级特性（如负载均衡、重试机制）。
• RPC：许多RPC框架（如gRPC）内置了丰富的功能，包括负载均衡、重试、超时控制、流式传输等，这些功能对于构建可靠的微服务系统非常重要。

5. 协议和扩展性

• HTTP：是一个通用的应用层协议，虽然可以用于微服务通信，但它的通用性也意味着它可能不够专门化，无法提供某些特定的优化。
• RPC：专为服务间通信设计，可以提供更专门化的优化和扩展，适合高性能、低延迟的服务间通信。