程序员必看：当我用“计算机网络协议的方式”打开西游记

程序员必看：当我用“计算机网络协议的方式”打开西游记

这是一个有关计算机网络协议的故事，转载自丨刘超的通俗云计算

一、我佛造经传极乐

Openvswitch如何转换呢？使用的是一种称为VXLAN的封装技术，但是必须要事先知道芝麻开门的ID，也即VXLAN ID，才能看到经文的真正内容。

在虚拟的空间中，放着真正可以解读的真经。

由于前来取经的人很多，同时经文也很多，所以金顶大仙多起到负载均衡的作用，将不同的取经人引领到不同的藏经楼，访问不同的经文。

金顶大仙所在的灵山脚下，是一个世界知名的地址，称为外网IP地址，这个地址是全球可定位的，所有的取经人都先到这个地方，金顶大仙通过NAT规则，将外网IP地址，变成藏经楼的私有IP地址，例如2号藏经楼三楼，4号藏经楼五楼等。在灵山藏经楼里面，是通过私有IP地址定位的。

真经已经准备好，就差东土取经人了。

二、观音奉旨上长安

可是佛祖愁啊，是这样说的：我待要送上东土，叵耐那方众生愚蠢，毁谤真言，不识我法门之要旨，怠慢了瑜迦之正宗。怎么得一个有法力的，去东土寻一个善信．教他苦历千山，远经万水，到我处求取真经，永传东土，劝他众生，却乃是个山大的福缘，海深的善庆、谁肯去走一遭来？

真经就在灵山，可以东土之人愚钝，不知道灵山咋办呢？要一个法力无边的人告诉他们呀。而且最好能够告诉全世界，灵山这里有真经。

好在有观音菩萨，道：“弟子不才，愿上东土寻一个取经人来也。”，观音菩萨有什么法力呢？当然是BGP协议了。

刚才那张图画的是一个可用区的情况，对于多个可用区的情况，我们可以隐去计算节点的情况，将外网访问区域放大。

你看，在西方极乐净土，我佛已经有了更牛的佛经，遥远的东方，还在读本土的僧人早期从西方传过来的经。

这种模式，称为CDN。

我们部署应用的时候，一般会把静态资源保存在两个地方，一个是nginx后面的varnish缓存里面，一般是静态页面；对于比较大的、不经常更新的静态图片，会保存在对象存储里面。这两个地方的静态资源都会配置CDN，将资源下发到边缘节点。

最初佛祖传经，都是口口相传，经文都会记在高僧大德的心里，随着高僧云游天下，随着庙宇遍布天下，佛经从而遍布天下。这就相当于将佛经缓存在边缘节点。

配置了CDN之后，权威DNS服务器上，会为静态资源设置一个CNAME别名，指向另外一个域名cdn.com，返回给本地DNS服务器。

当本地DNS服务器拿到这个新的域名时，需要继续解析这个新的域名。这个时候，再访问的时候就不是原来的权威DNS服务器了，而是 cdn.com 的权威DNS服务器。这是CDN自己的权威DNS服务器。

在这个服务器上，还是会设置一个CNAME，指向另外一个域名，也即CDN网络的全局负载均衡器。

本地DNS服务器去请求CDN的全局负载均衡器解析域名，全局负载均衡器会为用户选择一台合适的缓存服务器提供服务，将IP返回给客户端，客户端去访问这个边缘节点，下载资源。缓存服务器响应用户请求，将用户所需内容传送到用户终端。

如果这台缓存服务器上并没有用户想要的内容，那么这台服务器就要向它的上一级缓存服务器请求内容，直至追溯到网站的源服务器，将内容拉到本地。

CDN的全局负载均衡策略，就相当于当僧人们想读佛经的时候，不必要都去西天，而是可以就近去问，周围有没有庙宇，然后向庙宇的师傅去请教佛经。

然而缓存的佛经当然是比不上西天取到的经文更新，所以东土由于离西天较远，缓存的还是小乘佛教，要读大乘佛教，就要去西天取经，称为回源。

四、观音显像化金蝉

观音菩萨打算度化玄奘法师，回源去西天取经。

可是怎么去呢，地址在哪里呢？玄奘法师只听说西天，不知道具体的地址，这就要问观音菩萨了。

这个时候，大家才知道，西天在灵山大雷音寺，距此十万八千里。

这个过程称为DNS解析。

当在手机上面打开一个App的时候，首先要做的事情就是解析这个网站的域名。

在手机运营商所在的互联网区域里，有一个本地的DNS，手机会向这个DNS请求解析DNS。当这个DNS本地有缓存，则直接返回；如果没有缓存，本地DNS才需要递归地从根DNS服务器，查到.com的顶级域名服务器，最终查到权威DNS服务器。

如果你使用云平台的时候，配置了智能DNS和全局负载均衡，在权威DNS服务中，一般是通过配置CNAME的方式，我们可以起一个别名，例如

vip.yourcomany.com

，然后告诉本地DNS服务器，让它请求GSLB解析这个域名，GSLB就可以在解析这个域名的过程中，通过自己的策略实现负载均衡。

GSLB通过查看请求它的本地DNS服务器所在的运营商和地址，就知道用户所在的运营商和地址，然后将距离用户位置比较近的Region里面，将三个本地负载均衡的公网IP地址，返回给本地DNS服务器。本地DNS解析器将结果缓存后，返回给客户端。

对于手机APP来说，可以绕过刚才的传统DNS解析机制，直接只要HTTPDNS服务，通过直接调用HTTPDNS服务器，得到这三个本地负载均衡的公网IP地址。

这个公网IP地址，就是金顶大仙所在的位置。其实这个时候，金顶大仙已经在等待了。

这个时候，李世民突然开始说话了，曰：“谁肯领朕旨意，上西天拜佛求经？“ 并愿意买下观音手中的两件宝物，“锦澜袈裟”一领，“九环锡杖”一根，佛祖说过：”若有取经人坚心来此，穿我的袈裟，免堕轮回；持我的锡枚，不遭毒害。“

玄奘法师回答：“贫僧不才，愿效犬马之劳，与陛下求取真经，祈保我王江山永固。”

这个时候，菩萨说了：“西天路远，更多虎豹妖魔。只怕有去无回，难保身命。”

玄奘道：“我已发了弘誓大愿，不取真经，永堕沉沦地狱。“

一个完整的网络包的格式是这样的。

六、历经千山与万险

离开大唐的国土，接下来的路应该怎么走呢？

好在此去西天，要经过一个个国家，每个国家有一个个城关，玄奘法师只要到处问路，只要这些城关的守门人知道大概路怎么走，就能一个个国家的走下去，如果遇到国家，还有通关文牒，还能保护玄奘法师在国内的安全。

这里有两个问题要解决，第一个是每个城关的守门人和每个国家，是怎么知道去西天怎么走的。第二个问题是玄奘如何问路，如何走。

我们先第一个问题，这个观音菩萨从西天来东土的时候，已经通过一种法术告诉这些国家和城关了。

菩萨的法术主要分两种情况，一种情况是在一个国家内部如何走，另一种情况在国家之间，在野外如何走的问题。

在一个国家内部，菩萨主要遵循最短路径原则，就是走得路越少越好，道路越短越好。

但是国家之间，菩萨不但要考虑远近的问题，还要考虑政策的问题。例如有的国家路近，但是路过的国家看不惯僧人，见了僧人就抓。例如灭法国，连光头都要抓。这样的情况即便路近，也最好绕远点走。

菩萨的法术是什么呢？咱们在大学里面学习计算机网络与数据结构的时候，知道求最短路径常用的有两种方法，一种是 Bellman-Ford 算法，一种是 Dijkstra 算法。在计算机网络中基本也是用这两种方法计算的。

距离矢量路由（distance vector routing），它是基于 Bellman-Ford 算法的。

链路状态路由（link state routing），基于 Dijkstra 算法。

最常用的两种路由协议：

OSPF（Open Shortest Path First，开放式最短路径优先）就是这样一个基于链路状态路由协议，广泛应用在数据中心中的协议，称为内部网关协议（Interior Gateway Protocol，简称IGP）

BGP 协议使用的算法是路径矢量路由协议（path-vector protocol）。它是距离矢量路由协议的升级版，称为外网路由协议（Border Gateway Protocol，简称BGP）

路由协议是城关之间相互沟通到哪里应该怎么走的协议。

第二个问题，也就是玄奘如何问路，如何走。这就是IP协议。

这就要靠通关文牒了，里面写着贫僧来自东土大唐（就是源IP地址），欲往西天拜佛求经（指的是目标IP地址）。路过宝地，借宿一晚，明日启行，请问接下来该怎么走啊？

这个叫路由表，根据这个表格，可以告诉唐僧怎么走。

接下来我们看完整故事。

出了NAT网关，就从核心网到达了互联网。在网络世界，每一个运营商的网络成为自治系统AS。每个自治系统都有边界路由器，通过它和外面的世界建立联系。

对于云平台来讲，它可以被称为Multihomed AS，有多个连接连到其他的AS，但是大多拒绝帮其他的AS传输包。例如一些大公司的网络。对于运营商来说，它可以被称为Transit AS，有多个连接连到其他的AS，并且可以帮助其他的AS传输包，比如主干网。

如何从出口的运营商到达云平台的边界路由器？在路由器之间需要通过BGP协议实现，BGP又分为两类，eBGP和iBGP。自治系统间，边界路由器之间使用eBGP广播路由。内部网络也需要访问其他的自治系统。

边界路由器如何将BGP学习到的路由导入到内部网络呢？通过运行iBGP，使内部的路由器能够找到到达外网目的地最好的边界路由器。

网站的SLB的公网IP地址早已经通过云平台的边界路由器，让全网都知道了。于是这个下单的网络包选择了下一跳是A2，也即将A2的MAC地址放在目标MAC地址中。

到达A2之后，从路由表中找到下一跳是路由器C1，于是将目标MAC换成C1的MAC地址。到达C1之后，找到下一跳是C2，将目标MAC地址设置为C2的MAC。到达C2后，找到下一跳是云平台的边界路由器，于是将目标MAC设置为边界路由器的MAC地址。

你会发现，这一路，都是只换MAC，不换目标IP地址。这就是所谓下一跳的概念。

在云平台的边界路由器，会将下单的包转发进来，经过核心交换，汇聚交换，到达外网网关节点上的SLB的公网IP地址。

我们可以看到，手机到SLB的公网IP，是一个端到端的连接，连接的过程发送了很多包。所有这些包，无论是TCP三次握手，还是HTTPS的密钥交换，都是要走如此复杂的过程到达SLB的，当然每个包走的路径不一定一致。

当网络包走在这个复杂的道路上，很可能一不小心就丢了，怎么办？这就需要借助TCP的机制重新发送。

既然TCP要对包进行重传，就需要维护一个Sequence Number，看哪些包到了，哪些没到，哪些需要重传，传输的速度应该控制到多少，这就是TCP的滑动窗口协议。

整个TCP的发送，一开始会协商一个Sequence Number，从这个Sequence Number开始，每个包都有编号。滑动窗口将接收方的网络包分成四个部分：

已经接收，已经ACK，已经交给应用层的包；

已经接收，已经ACK，未发送给应用层；

已经接收，尚未发送ACK；

未接收，尚有空闲的缓存区域。

对于TCP层来讲，每一个包都有ACK。ACK需要从SLB回复到手机端，将上面的那个过程反向来一遍，当然路径不一定一致，可见ACK也不是那么轻松的事情。

如果发送方超过一定的时间没有收到ACK，就会重新发送。只有TCP层ACK过的包，才会发给应用层，并且只会发送一份，对于下单的场景，应用层是HTTP层。

你可能会问了，TCP老是重复发送，会不会导致一个单下了两遍？是否要求服务端实现幂？从TCP的机制来看，是不会的。只有收不到ACK的包才会重复发，发到接收端，在窗口里面只保存一份，所以在同一个TCP连接中，不用担心重传导致二次下单。

但是TCP连接会因为某种原因断了，例如手机信号不好，这个时候手机把所有的动作重新做一遍，建立一个新的TCP连接，在HTTP层调用两次RESTful API。这个时候可能会导致两遍下单的情况，因而RESTful API需要实现幂等。

当ACK过的包发给应用层之后，TCP层的缓存就空了出来，这会导致上面图中的大三角，也即接收方能够容纳的总缓存，整体顺时针滑动。小的三角形，也即接收方告知发送方的窗口总大小，也即还没有完全确认收到的缓存大小，如果把这些填满了，就不能再发了，因为没确认收到，所以一个都不能扔。

七、功成行满见真如

唐僧经历九九八十一难，终于到达了西天。发现金顶大仙已经在等他们了。

Dubbo中默认的RPC协议是Hessian2。Hessian2将下单的远程调用序列化为二进制进行传输。

Netty是一个非阻塞的基于事件的网络传输框架。Controller层和下单服务之间，使用了Netty的网络传输框架。有了Netty，就不用自己编写复杂的异步Socket程序了。Netty使用的方式，就是咱们讲Socket编程的时候，一个项目组支撑多个项目（IO多路复用，从派人盯着到有事通知）这种方式。

Netty还是工作在Socket这一层的，发送的网络包还是基于TCP的。在TCP的下层，还是需要封装上IP头和MAC头。如果跨物理机通信，还是需要封装的外层的VXLAN隧道里面。当然底层的这些封装，Netty都不感知，它只要做好它的异步通信即可。

在Netty的服务端，也即下单服务中，收到请求后，先用Hessian2的格式进行解压缩。然后将请求分发到线程中进行处理，在线程中，会调用下单的业务逻辑。

玄奘师徒好在后来碰到了懂得内情的注册中心——弥勒佛，从而会到灵山，还是按照人家的规矩办了，才将无字经文，换成有字经文。

编程学习视频分享：

整理分享（多年学习的源码、项目实战视频、项目笔记，基础入门教程）

欢迎转行和学习编程的伙伴，利用更多的资料学习成长比自己琢磨更快哦！

对于C/C 感兴趣可以关注小编在后台私信我：【编程交流】一起来学习哦！可以领取一些C/C 的项目学习视频资料哦！已经设置好了关键词自动回复，自动领取就好了！