手机做任务的网站有哪些内容家具网站建设案例

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

手机做任务的网站有哪些内容,家具网站建设案例,个人网站与企业网站区别,企业网络推广方案策划书3.8 既然有 HTTP 协议#xff0c;为什么还要有 RPC 假设我们需要在 A 电脑的进程发一段数据到 B 电脑的进程#xff0c;我们一般会在代码里使用 Socket 进行编程。 这时候#xff0c;我们可选项一般也就 TCP 和 UDP 二选一。TCP 可靠#xff0c;UDP 不可靠。 类似下面这…3.8 既然有 HTTP 协议为什么还要有 RPC 假设我们需要在 A 电脑的进程发一段数据到 B 电脑的进程我们一般会在代码里使用 Socket 进行编程。 这时候我们可选项一般也就 TCP 和 UDP 二选一。TCP 可靠UDP 不可靠。 类似下面这样。 fd socket(AF_INET,SOCK_STREAM,0); 其中 SOCK_STREAM是指使用字节流传输数据说白了就是 TCP 协议。 在定义了 Socket 之后我们就可以愉快的对这个 Socket 进行操作比如用 bind() 绑定 IP 端口用 connect() 发起连接。 在连接建立之后我们就可以使用 send() 发送数据recv() 接收数据。 光这样一个纯裸的 TCP 连接就可以做到收发数据了那是不是就够了 不行这么用会有问题 纯裸TCP问题 TCP是面向连接、基于字节流、可靠的连接 字节流可以理解为一个双向的通道里流淌的数据这个数据其实就是我们常说的二进制数据简单来说就是一大堆 01 串。纯裸 TCP 收发的这些 01 串之间是没有任何边界的你根本不知道到哪个地方才算一条完整消息。 正因为这个没有任何边界的特点所以当我们选择使用 TCP 发送夏洛和特烦恼的时候接收端收到的就是夏洛特烦恼这时候接收端没发区分你是想要表达夏洛特烦恼还是夏洛特烦恼。 这就是所谓的粘包问题 故纯裸TCP是不能直接拿来用的要在这个基础上加入一些自定义的规则用于区分消息边界 比如加入消息头消息头里写清楚一个完整的包长度是多少根据这个长度可以继续接收数据截取出来后它们就是我们真正要传输的消息体。 而这里头提到的消息头还可以放各种东西比如消息体是否被压缩过和消息体格式之类的只要上下游都约定好了互相都认就可以了这就是所谓的协议。 每个使用 TCP 的项目都可能会定义一套类似这样的协议解析标准他们可能有区别但原理都类似。 于是基于 TCP就衍生了非常多的协议比如 HTTP 和 RPC HTTP 和 RPC HTTP 协议Hyper Text Transfer Protocol又叫做超文本传输协议。我们用的比较多平时上网在浏览器上敲个网址就能访问网页这里用到的就是 HTTP 协议。 而 RPCRemote Procedure Call又叫做远程过程调用。它本身并不是一个具体的协议而是一种调用方式。 例如平时调用一个本地方法就像下面这样 res localFunc(req) 但如果现在这个不是一个本地方法而是远端服务器暴露出来的一个方法remoteFunc如果我们还能像调用本地方法那样调用它这样就可以屏蔽一些网络细节 res remoteFunc(req) 基于这个思路大佬们造出了非常多款式的 RPC 协议比如比较有名的gRPCthrift。 虽然大部分 RPC 协议底层使用 TCP但实际上它们不一定非得使用 TCP改用 UDP 或者 HTTP其实也可以做到类似的功能。 TCP 是70年代出来的协议RPC是80年代提出的HTTP是90年代流行的。 既然有 RPC 了为什么还要有 HTTP 呢 现在电脑上装的各种联网软件它们都作为客户端Client需要跟服务端Server建立连接收发消息此时都会用到应用层协议在这种 Client/Server (C/S) 架构下它们可以使用自家造的 RPC 协议因为它只管连自己公司的服务器就 ok 了 但有个软件不同浏览器Browser不管是 Chrome 还是 IE它们不仅要能访问自家公司的服务器Server还需要访问其他公司的网站服务器因此它们需要有个统一的标准不然大家没法交流。于是HTTP 就是那个时代用于统一 Browser/Server (B/S) 的协议 也就是说在多年以前HTTP 主要用于 B/S 架构而 RPC 更多用于 C/S 架构。但现在其实已经没分那么清了B/S 和 C/S 在慢慢融合。*很多软件同时支持多端比如某度云盘既要支持*网页版还要支持手机端和 PC 端 HTTP和RPC区别 服务发现 首先要向某个服务器发起请求你得先建立连接而建立连接的前提是你得知道 IP 地址和端口。这个找到服务对应的 IP 端口的过程其实就是服务发现。 在 HTTP 中你知道服务的域名就可以通过 DNS 服务去解析得到它背后的 IP 地址默认 80 端口。 而 RPC 的话就有些区别一般会有专门的中间服务去保存服务名和IP信息比如 Consul 或者 Etcd甚至是 Redis。想要访问某个服务就去这些中间服务去获得 IP 和端口信息。由于 DNS 也是服务发现的一种所以也有基于 DNS 去做服务发现的组件比如CoreDNS。 底层连接形式 以主流的 HTTP/1.1 协议为例其默认在建立底层 TCP 连接之后会一直保持这个连接Keep Alive之后的请求和响应都会复用这条连接。 而 RPC 协议也跟 HTTP 类似也是通过建立 TCP 长链接进行数据交互但不同的地方在于RPC 协议一般还会再建个连接池在请求量大的时候建立多条连接放在池内要发数据的时候就从池里取一条连接出来用完放回去下次再复用 由于连接池有利于提升网络请求性能所以不少编程语言的网络库里都会给 HTTP 加个连接池比如 Go 传输的内容 基于 TCP 传输的消息说到底无非都是消息头 Header 和消息体 Body。 Header 是用于标记一些特殊信息其中最重要的是消息体长度。 Body 则是放我们真正需要传输的内容而这些内容只能是二进制 01 串毕竟计算机只认识这玩意。所以 TCP 传字符串和数字都问题不大因为字符串可以转成编码再变成 01 串而数字本身也能直接转为二进制。但结构体呢我们得想个办法将它也转为二进制 01 串这样的方案现在也有很多现成的比如 JsonProtobuf。 这个将结构体转为二进制数组的过程就叫序列化反过来将二进制数组复原成结构体的过程叫反序列化。 对于主流的 HTTP/1.1虽然它现在叫超文本协议支持音频视频但 HTTP 设计初是用于做网页文本展示的所以它传的内容以字符串为主。Header 和 Body 都是如此。在 Body 这块它使用 Json 来序列化结构体数据。例如 可以看到这里面的内容非常多的冗余显得非常啰嗦。最明显的像 Header 里的那些信息其实如果我们约定好头部的第几位是 Content-Type就不需要每次都真的把Content-Type这个字段都传过来类似的情况其实在 body 的 Json 结构里也特别明显。 而 RPC因为它定制化程度更高可以采用体积更小的 Protobuf 或其他序列化协议去保存结构体数据同时也不需要像 HTTP 那样考虑各种浏览器行为比如 302 重定向跳转啥的。因此性能也会更好一些这也是在公司内部微服务中抛弃 HTTP选择使用 RPC 的最主要原因 上面说的 HTTP其实特指的是现在主流使用的 HTTP/1.1HTTP/2 在前者的基础上做了很多改进所以性能可能比很多 RPC 协议还要好甚至连 gRPC 底层都直接用的 HTTP/2。 为什么既然有了 HTTP/2还要有 RPC 协议 由于 HTTP/2 是 2015 年出来的。那时候很多公司内部的 RPC 协议都已经跑了好些年了基于历史原因一般也没必要去换了