企业网站完整版长沙房地产信息平台

当前位置： 首页 > news >正文

企业网站完整版,长沙房地产信息平台,做旅游网站运营,百度网站建设电话RPC 是什么#xff1f;HTTP 是什么#xff1f; 作为一个程序员#xff0c;假设我们需要从A电脑的进程发送一段数据到B电脑的进程#xff0c;我们一般会在代码中使用 Socket 进行编程。 此时#xff0c;可选性一般就是 TCP 和 UDP 二选一#xff0c;由于 TCP 可靠、UDP 不…RPC 是什么HTTP 是什么 作为一个程序员假设我们需要从A电脑的进程发送一段数据到B电脑的进程我们一般会在代码中使用 Socket 进行编程。 此时可选性一般就是 TCP 和 UDP 二选一由于 TCP 可靠、UDP 不可靠只要对可靠性有要求一般就选 TCP 了。 Socket 本质是个代码库我们需要先创建类似于 其中 SOCK_STREAM是指使用字节流传输数据。说白了就是 TCP 协议。 在定义了 socket 之后我们就可以对这个 socket 进行操作。 比如使用 bind() 方法绑定 IP 端口 用 connect() 方法发起建联里面就包含了常见的 TCP 三次握手流程 在建立连接之后就可以使用 send() 方法发送数据 accept() 方法接收数据。 光这个“纯裸”的 TCP 连接就可以收发数据了那是不是就够了 不行。 八股文常背 TCP 有三个特点面向连接、可靠、基于字节流。 这里关注“基于字节流”字节流可以理解为双向通道里流淌的二进制数据就是一堆“01”串。“纯裸”的 TCP 连接收发的这些“01”串是没有任何边界的你无法知道一条完整消息的起始位置。 由于无边界所以当选择使用 TCP 发送“夏洛特烦恼”时接收端无法区分你想表达的是“夏洛” 和“特烦恼”还是“夏洛特”和“烦恼”。这也就是所谓的“粘包”问题。 既然“纯裸” TCP 是不能直接拿来用的那就需要在这个基础上加入一些自定义规则来区分 消息边界。 于是我们会把每条要发送的消息都包装一下。比如加入消息头消息头中写清楚一个完整的包长度是多少根据这个长度可以继续接收数据截取出来后就是我们真正想传输的消息体。 这里的消息头中还可以放各种规则比如消息体是否压缩、消息体格式之类的。只要上下游都约定好互相能够解析就行了这就是所谓的协议了。 每个使用 TCP 的项目都可能会定义一套类似于这样的协议解析标准它们可能有区别但原理都类似。 于是基于 TCP 就衍生出非常多的协议如 HTTP 和 RPC 。 TCP 是传输层的协议而基于 TCP 造出来的各类协议都是定义了不同规则的应用层协议。 HTTP 协议又叫做“超文本传输协议”我们平时上网在浏览器中敲个网址就能访问网页用到的就是 HTTP 协议。 RPC(Remote Procedure Call) 又叫做“远程过程调用”它本身不是一种具体的协议而是一种调用方式。 RPC 让我们可以像调用本地方法一样调用远端服务器的方法remoteFunc屏蔽掉一些网络细节。 基于这个思路大佬们造成了非常多款式的 RPC 协议如 gRPC、tRPC 等。 虽然大部分 RPC 协议底层使用的是 TCP 协议但也可以改用 UDP 或者 HTTP。 为什么有 HTTP 还要有 RPC? 其实TCP 是 70 年代的产物HTTP 是 90 年代的产物由于直接使用 TCP 会出现粘包问题所以可想而知70~90 年代之间会有很多协议产生其中包含 80 年代产出的 RPC 协议 因此我们该问的不是“为什么有 HTTP 了还要有 RPC”而是“为什么有 RPC 了还要有 HTTP”。 为什么有 RPC 还要有 HTTP 协议 现在电脑上安装的各种软件如xx管家、xx视频它们作为客户端需要与服务端建立连接收发消息都会用到应用层协议。在这种 C/Sclient server架构下他们就能使用自家创造的 RPC 协议因为只需要连接自己公司的服务器。 但是xx浏览器却不同不管是 Chrome 还是 IE它们不仅需要连接自家服务器还需要访问其他公司的网站服务器因此需要一个统一的标准。于是 HTTP 就是当时用来统一 browser server 的协议。 当时 HTTP 主要用于 B/S 架构而 RPC 主要用于 C/S 架构但是现在没有分那么清楚了B/S 和 C/S 在慢慢融合。 很多软件需要支持多端如网页端、PC端、移动端如果通信协议都用 HTTP那么服务器只用一套就够了而 RPC 开始退居幕后一般用于公司内部集群里各个微服务之间的通讯。 那么既然有了 HTTP为啥还要使用 RPC 呢 为什么有了 HTTP 还要用 RPC 这个问题需要从二者的区别说起 首先是服务发现。 服务建立连接的前提是需要知道对方的 IP 地址和端口号寻找对方 IP 端口的过程叫做 服务发现。 在 HTTP 中知道了服务域名就可以通过 DNS 服务器解析 IP 地址端口默认是 80 。 而 RPC 需要专门的中间服务来保存服务名的 IP 信息比如 etcd 甚至是 Redis。 可以看出服务发现方面二者虽有区别但不分高低。 其次是底层连接形式。 以主流的 HTTP1.1 协议为例默认在底层建立 TCP 连接之后会一直保持这个连接Keep alive之后的请求都会复用这条连接。 而 RPC 协议也和 HTTP 协议类似也是通过建立 TCP 长连接进行数据交互。但不同的地方在于RPC 一般还会再建立一个连接池在请求量大的时候建立多条连接放在连接池中需要发数据的时候就从池中取出一条连接用完再放回去。 由于连接池有利于提升网络性能所以有些编程语言的网络库中也会给 HTTP 加个连接池比如 Go。 可以看出这块二者也没有太大区别。 最后是传输的内容 HTTP 和 RPC 传输内容都是基于 TCP 传输的消息包含消息头 header 和 消息体 bodyheader 适合标记一些特殊信息其中最重要的信息就是消息体的长度body 则是放真正需要传输的内容而这些内容只能是二进制数据。 所以 TCP 传输字符串和数字的问题不大因为字符串可以编码再变成二进制而数字本身可以直接转为二进制。 但是结构体呢 需要想办法转为二进制现在的方案主要有 json、protoBuf 等。将这个结构体转为二进制的过程叫做序列化。 对于主流的 HTTP1.1虽然叫做超文本传输协议支持音频视频但是在设计之初是用于做网络文本展示的所以传输内容主要以字符串为主header 和 body 都是如此在 body 这块使用 json 来序列化结构体。 而 RPC 因为定制化程度更高可以采用体积更小的 protobuf 文件或其他序列化协议来保存结构体同时不需要像 HTTP 那样考虑各种浏览器行为如 302 定向跳转因此性能会更好。这也是公司内部抛弃 HTTP 而选择 RPC 的主要原因。 当然上面说的 HTTP 其实特指主流的 HTTP1.1。 HTTP2 在前者的基础上做了很多改进性能可能比 RPC 还好甚至连 gRPC 底层都是用的 HTTP2那么问题又来了“为什么既然有了 HTTP2还要使用 RPC?” 因为 HTTP2 是 2015 年才出来的那时候很多公司内部的 RPC 服务都运行很多年了基于历史原因也就没必要换了。 参考 RPC是什么HTTP是什么RPC和HTTP有什么区别 备注 在 HTTP/1.1 和 RPC远程过程调用中消息头header和消息体body都是以二进制数据的形式在 TCP 连接上进行传输的。然而它们的具体格式和编码方式有所不同。 HTTP/1.1: 消息头HTTP 消息头是以文本格式编码的通常是 ASCII 字符。每个头部字段由字段名和字段值组成字段之间用冒号分隔。头部的结束是通过一个空行即两个连续的换行符来标识的。消息体HTTP 消息体可以是任意类型的二进制数据如图像、视频、JSON、XML 等其内容的类型通常通过 Content-Type 头部字段来指明。消息体的长度可以通过 Content-Length 头部字段来指示或者使用 Transfer-Encoding: chunked 进行分块传输。 RPC: RPC 的实现可以有多种形式如 gRPC、XML-RPC、JSON-RPC 等每种实现的消息格式可能不同。一般来说RPC 的消息头和消息体也可以是二进制数据。在一些 RPC 实现中消息头可能包含一些元数据如方法名、请求 ID、版本信息等而消息体则包含实际的参数或返回值。具体的编码方式如 Protocol Buffers、Thrift 等会影响消息的二进制表示。
总结来说虽然 HTTP/1.1 的消息头是以文本格式传输的但在底层 TCP 连接上它们都是以二进制形式发送的。 而 RPC 的消息头和消息体通常都是以二进制格式传输的具体取决于所使用的协议和编码方式。