趣谈网络协议
刘超
网易研究院云计算技术部首席架构师
立即订阅
38011 人已学习
课程目录
已完结 51 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 想成为技术牛人?先搞定网络协议!
免费
第一模块 通信协议综述 (4讲)
第1讲 | 为什么要学习网络协议?
第2讲 | 网络分层的真实含义是什么?
第3讲 | ifconfig:最熟悉又陌生的命令行
第4讲 | DHCP与PXE:IP是怎么来的,又是怎么没的?
第二模块 底层网络知识详解:从二层到三层 (5讲)
第5讲 | 从物理层到MAC层:如何在宿舍里自己组网玩联机游戏?
第6讲 | 交换机与VLAN:办公室太复杂,我要回学校
第7讲 | ICMP与ping:投石问路的侦察兵
第8讲 | 世界这么大,我想出网关:欧洲十国游与玄奘西行
第9讲 | 路由协议:西出网关无故人,敢问路在何方
第二模块 底层网络知识详解:最重要的传输层 (4讲)
第10讲 | UDP协议:因性善而简单,难免碰到“城会玩”
第11讲 | TCP协议(上):因性恶而复杂,先恶后善反轻松
第12讲 | TCP协议(下):西行必定多妖孽,恒心智慧消磨难
第13讲 | 套接字Socket:Talk is cheap, show me the code
第二模块 底层网络知识详解:最常用的应用层 (4讲)
第14讲 | HTTP协议:看个新闻原来这么麻烦
第15讲 | HTTPS协议:点外卖的过程原来这么复杂
第16讲 | 流媒体协议:如何在直播里看到美女帅哥?
第17讲 | P2P协议:我下小电影,99%急死你
第二模块 底层网络知识详解:陌生的数据中心 (6讲)
第18讲 | DNS协议:网络世界的地址簿
第19讲 | HTTPDNS:网络世界的地址簿也会指错路
第20讲 | CDN:你去小卖部取过快递么?
第21讲 | 数据中心:我是开发商,自己拿地盖别墅
第22讲 | VPN:朝中有人好做官
第23讲 | 移动网络:去巴塞罗那,手机也上不了脸书
第三模块 热门技术中的应用:云计算中的网络 (5讲)
第24讲 | 云中网络:自己拿地成本高,购买公寓更灵活
第25讲 | 软件定义网络:共享基础设施的小区物业管理办法
第26讲 | 云中的网络安全:虽然不是土豪,也需要基本安全和保障
第27讲 | 云中的网络QoS:邻居疯狂下电影,我该怎么办?
第28讲 | 云中网络的隔离GRE、VXLAN:虽然住一个小区,也要保护隐私
第三模块 热门技术中的应用:容器技术中的网络 (3讲)
第29讲 | 容器网络:来去自由的日子,不买公寓去合租
第30讲 | 容器网络之Flannel:每人一亩三分地
第31讲 | 容器网络之Calico:为高效说出善意的谎言
第三模块 热门技术中的应用:微服务相关协议 (5讲)
第32讲 | RPC协议综述:远在天边,近在眼前
第33讲 | 基于XML的SOAP协议:不要说NBA,请说美国职业篮球联赛
第34讲 | 基于JSON的RESTful接口协议:我不关心过程,请给我结果
第35讲 | 二进制类RPC协议:还是叫NBA吧,总说全称多费劲
第36讲 | 跨语言类RPC协议:交流之前,双方先来个专业术语表
第四模块 网络协议知识串讲 (4讲)
第37讲 | 知识串讲:用双十一的故事串起碎片的网络协议(上)
第38讲 | 知识串讲:用双十一的故事串起碎片的网络协议(中)
第39讲 | 知识串讲:用双十一的故事串起碎片的网络协议(下)
第40讲 | 搭建一个网络实验环境:授人以鱼不如授人以渔
答疑与加餐 (9讲)
协议专栏特别福利 | 答疑解惑第一期
协议专栏特别福利 | 答疑解惑第二期
协议专栏特别福利 | 答疑解惑第三期
协议专栏特别福利 | 答疑解惑第四期
协议专栏特别福利 | 答疑解惑第五期
加餐1 | 测一测:这些网络协议你都掌握了吗?
加餐2 | 创作故事:我是如何创作“趣谈网络协议”专栏的?
加餐3 | “趣谈网络协议”专栏食用指南
第2季回归 | 这次我们来“趣谈Linux操作系统”
结束语 (1讲)
结束语 | 放弃完美主义,执行力就是限时限量认真完成
趣谈网络协议
登录|注册

第36讲 | 跨语言类RPC协议:交流之前,双方先来个专业术语表

刘超 2018-08-08

到目前为止,咱们讲了四种 RPC,分别是 ONC RPC、基于 XML 的 SOAP、基于 JSON 的 RESTful 和 Hessian2。

通过学习,我们知道,二进制的传输性能好,文本类的传输性能差一些;二进制的难以跨语言,文本类的可以跨语言;要写协议文件的严谨一些,不写协议文件的灵活一些。虽然都有服务发现机制,有的可以进行服务治理,有的则没有。

我们也看到了 RPC 从最初的客户端服务器模式,最终演进到微服务。对于 RPC 框架的要求越来越多了,具体有哪些要求呢?

  • 首先,传输性能很重要。因为服务之间的调用如此频繁了,还是二进制的越快越好。

  • 其次,跨语言很重要。因为服务多了,什么语言写成的都有,而且不同的场景适宜用不同的语言,不能一个语言走到底。

  • 最好既严谨又灵活,添加个字段不用重新编译和发布程序。

  • 最好既有服务发现,也有服务治理,就像 Dubbo 和 Spring Cloud 一样。

Protocol Buffers

这是要多快好省的建设社会主义啊。理想还是要有的嘛,这里我就来介绍一个向“理想”迈进的 GRPC。

GRPC 首先满足二进制和跨语言这两条,二进制说明压缩效率高,跨语言说明更灵活。但是又是二进制,又是跨语言,这就相当于两个人沟通,你不但说方言,还说缩略语,人家怎么听懂呢?所以,最好双方弄一个协议约定文件,里面规定好双方沟通的专业术语,这样沟通就顺畅多了。

© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《趣谈网络协议》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(15)

  • sam
    我觉得是极客目前最好的专栏
    2018-08-08
    52
  • 灰灰
    讲的太棒了,绝对是大师级人物。快结束了,意犹未尽,重新看一遍。
    2018-08-08
    25
  • Jay
    题目:在讲述 Service Mesh 的时候,我们说了,希望 Envoy 能够在服务不感知的情况下,将服务之间的调用全部代理了,你知道怎么做到这一点吗?
    答:在Service Mesh模式中,每个服务都配备了一个代理sidecar(Envoy代理),用于服务之间的通信。这些代理通常与应用程序一起部署,代理不会被应用程序感知。这些代理组织起来形成服务网格。
    Envoy是Service Mesh中一个非常优秀的sidecar的来源实现。
    2018-08-08
    14
  • Hector
    Envoy就是lstio的核心支持,越来越觉得kubernetes真的是集大成者,服务治理,面向未来的声明式API架构,资源调度与编排,网络的多种优秀方案。怪不得可以在极端的时间里力压docker

    作者回复: 是的

    2019-05-07
    4
  • blackpiglet
    对思考题的解答
    容器系统中,是通过 sidecar 模式来解决的,服务容器都是直接和 envoy sidecar 互通,envoy 的配置变化,网络拓扑的改变对服务容器都是不可感知的。service mesh 还更进一步的发展,istio 和 conduit,他们都是在 sidecar 基础上,又加了一个总的数据控制平面,来加强 service mesh 的掌控能力。
    2018-08-09
    4
  • 谢晋
    我觉得是极客目前最好的专栏
    2019-05-12
    1
  • 李博越
    想问一下老师,GRPC是否支持client通过代理服务器访问到server端?官网上找了半天没有找到相关答案,我这边现在的场景需要经典网络的管控节点访问到vpc中的服务节点,由于vpc中服务节点太多,不可能打太多的洞,所以想在vpc中部署nginx服务作为代理服务器,转发经典网络发来的所有请求到server端

    作者回复: 试一下envoy

    2019-01-09
    1
  • jedi knight
    学java的应该可以跳过spring cloud了,感觉envoy + grpc + kubernetes是趋势
    2018-08-09
    1
  • _CountingStars
    通过使用iptables程序配置内核中的netfilter,实现流量劫持转发,把指定入口流量都转发到envoy,出口流量也可以使用两样的方法实现
    2018-08-08
    1
  • 刘哲
    刘超老师,问个问题,如果一个服务在容器中,一个服务在物理机上,怎么进行rpc通信,此时容器是可以调用物理机的,但是物理机是无法调用容器中的服务了,例如dubbo,获取到的是容器中的ip,物理机调用的时候,通过容器中的ip是无法调用到容器中的,这个有什么解决办法么
    2018-12-11
  • MoFanDon
    已经完结这么久了,我才终于看到了这里。收获很多。感谢。
    2018-10-08
  • hhq
    对grpc有了基本的认识,包括协议定义,传输封装等。
    2018-08-11
  • NullPointExcepiton
    服务的注册不感知是因为使用了容器平台的发现能力。服务自身不感知,是因为envoy 作为sidecar 的方式劫持了网络流量。
    2018-08-09
  • 空档滑行
    其实也不是完全无感知,服务还是需要知道service mesh的存在,只是一般是sidebar方式的部署,每个服务只需要知道自己的enovy在哪里就可以了,所有网络交互通过它来转发
    2018-08-08
  • 崔朝普🐳📡
    赞,干货满满
    2018-08-08
收起评论
15
返回
顶部