🎬 -> 📝 oQExNITPQAjEQeRCgIfTwACzGNFqUlWhAABqDU.txt

[leeguooooo]

https://v3-web.douyinvod.com/6a26ada6846492072d681e5117a6ee08/6476fe0d/video/tos/cn/tos-cn-ve-15/oQExNITPQAjEQeRCgIfTwACzGNFqUlWhAABqDU/?a=6383&ch=4&cr=3&dr=0&lr=all&cd=0%7C0%7C0%7C3&cv=1&br=293&bt=293&cs=0&ds=4&ft=7yV4ZBo7UUmfTbdPD0PD1YswHAX1tG.6Xbq9eFyXodXr12nz&mime_type=video_mp4&qs=0&rc=Nzs1ZThlaDxnZWZoPDs8ZkBpamR3NDc6ZjZmaDMzNGkzM0AxXjRgYzQxXjQxLS8xNi8uYSM2NjYvcjQwZy5gLS1kLS9zcw%3D%3D&l=20230531145022363F1DD451AB6A07CFBF&btag=e00030000

[github-actions[bot]]

Hi! 👋

Thanks for using my services! ❤️! 🤖 I've received your request and currently working on it.

⚙️ It might take a few minutes 🙏 You can check the progress here

In the meantime, feel free to chat with me ! 😊 I'll notify you as soon as I'm done! 😊

If you find my services helpful, you can support me by buying me a coffee ☕️

[github-actions[bot]]

Mission accomplished! 🥳🥳🥳 Here's the result:

[github-actions[bot]]

oQExNITPQAjEQeRCgIfTwACzGNFqUlWhAABqDU

Summary Text

TCP协议可以使用socket编程进行数据传输，发送和接收二进制数据时存在粘包问题，需要加入规则区分消息边界，因此基于TCP协议诞生了HTTP和RPC协议。HTTP协议用于BS架构，采用DNS进行服务发现，数据传输主要基于字符串，使用JSON对结构体进行序列化。RPC协议用于CS架构，采用中间服务进行服务发现，可使用统一的序列化协议如protobuf，性能更优。虽然HTTP2已经出现，但RPC协议历史悠久，已经在公司内部微服务中广泛使用。

Original text

oQExNITPQAjEQeRCgIfTwACzGNFqUlWhAABqDU: 我刚工作的时候,第一次接触RPC协议,当时就很懵,我http协议用的好好的,为什么还要用RPC协议? 作为一个程序员,假设我们需要在A电脑的进程发一段数据到B电脑的进程,我们一般会在代码里使用socket进行编程。 这时候,我们可选项一般也就tcp和udp二选一,tcp可靠,udp不可靠。 除非是马总这种神级程序员,否则,只要稍微对可靠性有些要求,普通人一般无脑选tcp就对了。 socket本质上就是个代码库,我们需要先创建它。 类似这样,这其中有个sockstream,它是只使用自节流传输数据,说白了就是tcp协议。 在定义了socket之后,我们就可以愉快地对这个socket进行操作,比如用bind方法绑定IP端口,用connect方法发起建联。 这里面其实就包含了我们常见的tcp三次握手流程。 在连接建立之后,我们就可以使用send方法发送数据,receive方法接收数据。 光这样一个纯裸的tcp连接就可以做到收发数据了,那是不是就够了? 不行,这么用会有问题。 八股文常背,tcp是有三个特点,面向连接,可靠,基于自节流。 而今天我们需要关注的是基于自节流这一点。 自节流可以理解为一个双向的通道里流淌的数据,这个数据其实就是我们常说的二进制数据,简单来说就是一大堆01串。 纯裸,tcp收发的这些01串之间是没有任何边界的,你根本不知道到哪个地方才算一条完整的消息。 正因为这个没有任何边界的特点,所以当我们选择使用tcp发送下落和特烦恼的时候,接收端收到的就是下落特烦恼。 这时候接收端没法区分你是想要表达下落和特烦恼,还是下落特和烦恼。 这也就是所谓的粘包问题。 既然纯裸tcp是不能直接拿来用的,我们就需要在这个基础上加入一些自定义的规则用于区分消息边界。 于是,我们会把每条要发送的数据都包装一下,比如加入消息头,消息头里写清楚一个完整的包长度是多少。 根据这个长度可以继续接收数据,接取出来后它们就是我们真正要传输的消息体。 而这里头提到的消息头还可以放各种东西,比如消息体是否被压缩过和消息体格式之类的。 只要上下游都约定好了,互相都认就可以了,这就是所谓的协议。 每个使用tcp的项目都可能会定义一套类似这样的协议解析标准,它们可能有区别,但原理都类似。 于是基于tcp就衍生了非常多的协议,比如http和rpc。 tcp是传输层的协议,而基于tcp造出来的http和各类rpc协议。 说白了,它们都只是定义了不同消息格式的应用层协议而已。 http协议又叫做超文本传输协议。 我们用的比较多,平时上网在浏览器上敲个网址就能访问网页,这里用到的就是http协议。 而rpc,remote procedure call,又叫做远程过程调用。 它本身并不是一个具体的协议,而是一种调用方式。 举个例子,我们平时调用一个本地方法就像这样,使用一个叫local function的函数传入request参数输出response结果。 如果现在这不是个本地方法,而是个远端服务器暴露出来的一个方法remote function, 如果我们还能像调用本地方法那样去调用它,这样就可以屏蔽掉一些网络细节,用起来更方便,岂不美哉。 说白了,rpc就是希望像调用本地方法那样调用远端方法。 基于这个思路,大佬们造出了非常多款式的rpc协议,比如比较有名的grpc,thrift。 值得注意的是,虽然大部分rpc协议底层使用的是tcp协议,但这并不是必选项,即使改用udp或者http也可以做到类似的功能。 到这里,我们回到视频标题的问题,既然有http协议,为什么还要有rpc? 其实,tcp是70年代出来的协议,而http是90年代才开始流行的。 因为直接使用过tcp会有粘包等问题,可想而知,这中间这么多年有多少自定义的协议,而这里面就有80年代出来的rpc。 所以我们该问的不是既然有http协议为什么要有rpc,而是为什么有rpc还要有http协议。 现在电脑上装的各种软件,比如某某管家,某某卫视,他们都作为客户端需要跟服务端建立连接收发消息,此时都会用到应用层协议。 在这种client server架构下,他们可以使用自家造的rpc协议,因为他只管连自己公司的服务器就ok了。 但有个软件却不同,浏览器,也叫browser,不管是chrome还是ie,他们不仅要能访问自家公司的服务器,还需要访问其他公司的网站服务器,因此他们需要有个统一的标准,不然大家没法交流。 于是http就是那个时代用于统一browser server的协议。 也就是说在多年以前,http主要用于bs架构,而rpc更多用于cs架构。 但现在其实已经没分那么清了,bs和cs在慢慢融合。 很多软件同时支持多端,比如某度云盘,既要支持网页版,还要支持手机端和pc端,如果通信协议都用http的话,那服务器只用同一套就够了。 而rpc就开始退居幕后,一般用于公司内部集群里各个微服务之间的通讯。 那这么说的话,都用http得了,还用什么rpc? 仿佛又回到了文章开头的样子,那这就要从他们之间的区别开始说起。 首先是服务发现,要向某个服务器发起请求,你得先建立连接,而建立连接的前提是,你得知道ip地址和端口。 这个找到服务对应的ip端口的过程,其实就是服务发现。 在http中,你知道服务的域名,就可以通过dns服务去解析得到它背后的ip地址,默认80端口。 而rpc的话,就有些区别,一般会有专门的中间服务去保存服务名和ip信息,比如console或者act,甚至是redis。 想要访问某个服务,就去这些中间服务去获得ip和端口信息。 由于dns也是服务发现的一种,所以也有基于dns去做服务发现的组件,比如cordian s。 可以看出,服务发现这一块,两者是有些区别,但不太能分高低。 其次是底层连接形式,以主流的http1.1协议为例,它默认在建立底层tcp连接之后会一直保持这个连接,keepalive之后的请求和响应都会附有这条连接。 而rpc协议也跟http类似,也是通过建立tcp长连接进行数据交互。 但不同的地方在于,rpc协议一般还会在建的连接池,在请求量大的时候,建立多条连接放在池内,要发数据的时候就从池里取一条连接出来,用完放回去,下次再服用,可以说非常环保。 由于连接池有利于提升网络请求性能,所以不少编程语言的网络库里都会给http加个连接池,比如go就是这么干的。 可以看出,这一块两者也没太大区别。 而第三点,也是最重要的一点,传输的内容。 基于tcp传输的消息,说到底,无非都是消息头header和消息体body。 header是用于标记一些特殊信息,其中最重要的是消息体长度,body则释放我们真正需要传输的内容,而这些内容只能是二进制01串,毕竟计算机只认识这玩意。 所以,tcp传字符串和数字都问题不大,因为字符串可以转成编码再变成01串,而数字本身也能直接转为二进制。 但结构体呢,我们得想个办法将它也转为二进制01串,这样的方案现在也有很多现成的,比如json,protobuf。 这个将结构体转为二进制数组的过程就叫序列化,反过来将二进制数组复原成结构体的过程叫反序列化。 对于主流的http1.1,虽然它现在叫超文本协议,支持音频视频,但http设计出是用于做网页文本展示的,所以它传的内容以字符串为主。 header和body都是如此,在body这块,它使用json来序列化结构体数据,而rpc因为它定制化程度更高,可以采用体积更小的protobuf或其他序列化协议去保存结构体数据,同时也不需要像http那样考虑各种浏览器行为,比如302从定向跳转啥的。 因此,性能也会更好一些,这也是在公司内部微服务中抛弃http,选择使用rpc的最主要原因。 当然上面说的http,其实特指的是现在主流使用的http1.1,http2在前者的基础上做了很多改进,所以性能可能比很多rpc协议还要好,甚至连grpc底层都直接用的http2。 那么问题又来了,为什么既然有了http2,还要有rpc协议?这个是由于http2是2015年出来的,那时候很多公司内部的rpc协议都已经跑了好些年了,基于历史原因一般也没必要去换了。 关注小白Dbog一起在知识的海洋里呛水吧。

[github-actions[bot]]

🙌

If you find my services helpful, you can support me by buying me a coffee ☕️ Thanks for using my services! ❤️