趣谈网络协议
刘超
网易研究院云计算技术部首席架构师
立即订阅
39583 人已学习
课程目录
已完结 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 首先满足二进制和跨语言这两条，二进制说明压缩效率高，跨语言说明更灵活。但是又是二进制，又是跨语言，这就相当于两个人沟通，你不但说方言，还说缩略语，人家怎么听懂呢？所以，最好双方弄一个协议约定文件，里面规定好双方沟通的专业术语，这样沟通就顺畅多了。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《趣谈网络协议》，如需阅读全部文章，
请订阅文章所属专栏。
请订阅文章所属专栏。
立即订阅
登录 后留言
精选留言(15)
sam我觉得是极客目前最好的专栏2018-08-08 55
灰灰讲的太棒了，绝对是大师级人物。快结束了，意犹未尽，重新看一遍。2018-08-08 27
Jay题目：在讲述 Service Mesh 的时候，我们说了，希望 Envoy 能够在服务不感知的情况下，将服务之间的调用全部代理了，你知道怎么做到这一点吗？
答：在Service Mesh模式中，每个服务都配备了一个代理sidecar（Envoy代理），用于服务之间的通信。这些代理通常与应用程序一起部署，代理不会被应用程序感知。这些代理组织起来形成服务网格。
Envoy是Service Mesh中一个非常优秀的sidecar的来源实现。2018-08-08 14
HectorEnvoy就是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 2
李博越想问一下老师，GRPC是否支持client通过代理服务器访问到server端？官网上找了半天没有找到相关答案，我这边现在的场景需要经典网络的管控节点访问到vpc中的服务节点，由于vpc中服务节点太多，不可能打太多的洞，所以想在vpc中部署nginx服务作为代理服务器，转发经典网络发来的所有请求到server端作者回复: 试一下envoy
2019-01-09 1
MoFanDon已经完结这么久了，我才终于看到了这里。收获很多。感谢。2018-10-08 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
hhq对grpc有了基本的认识，包括协议定义，传输封装等。2018-08-11
Null服务的注册不感知是因为使用了容器平台的发现能力。服务自身不感知，是因为envoy 作为sidecar 的方式劫持了网络流量。2018-08-09
空档滑行其实也不是完全无感知，服务还是需要知道service mesh的存在，只是一般是sidebar方式的部署，每个服务只需要知道自己的enovy在哪里就可以了，所有网络交互通过它来转发2018-08-08
崔朝普🐳📡赞，干货满满2018-08-08
收起评论