前言

这是一个无关计算机网络协定的故事。一家之言，不用当真，欢送进群973961276交换，并且每个礼拜都会有抽奖送书的流动哦！

-

一、我佛造经传极乐

话说我佛如来为度化天下苍生，有三藏真经，可劝人为善。

就如图中所示，真经所藏之处，在于云端。佛祖所管辖之下，有四个区域Region，称为四大部洲， 一是东胜神洲，二是南赡部洲，三是西牛贺洲，四是北俱卢洲。

我佛所在西牛贺洲，是主站点。

在每个区域Region，为保障真经永固，设置多个藏经楼，称为可用区（Available Zone）。

每个藏经楼外面是一排一排的柜子，称为机柜，外面有一排一排的格子，称为服务器，经文就摆放在格子中。

在藏经楼中，柜子依据经文分门别类的组织起来，由不同的神仙进行治理，治理一个柜子的经文的神仙，拜访这外面经文的钥匙就在他手里，称为接入层神仙（接入层交换机）。

多个接入层神仙被一组汇聚层神仙（汇聚层交换机）管着，多个汇聚层的神仙被一组核心层神仙（外围交换机）管着。

神仙体系组织严格，层次分明，不同的接入层神仙替换经文，要通过汇聚层神仙批准，不同的汇聚层神仙替换经文，须要核心层神仙批准。

经文的看管要十拿九稳，因此每一层都是分组看护，互相监督，相互备份，称为重叠。

虽说每个柜子外面放满了经文，为了避免经文被偷听偷看，经文的内容是被仙术封装在一个虚构的私密空间外面，尽管有人可能会偷到物质的经文，然而没有仙术关上这个私密空间，看到的经文如同空白的一样。这个虚构的私密空间称为VPC。

要解读经文，须要应用每一格中一个不起眼的法宝，就是称为Openvswitch的虚构交换机，顾名思义就是起到经文在虚构私密空间和物理空间之间的转换作用。

Openvswitch如何转换呢？应用的是一种称为VXLAN的封装技术，然而必须要当时晓得芝麻开门的ID，也即VXLAN ID，能力看到经文的真正内容。

在虚构的空间中，放着真正能够解读的真经。

真经有法一藏，谈天；论一藏，说地；经一藏，度鬼；三藏共计三十五部，该一万五千一百四十四卷，乃是修真之径，正善之门。

看来曾经前中后盾拆散，分为根底服务层，组合服务层，Controller层，共三十五个模块，一万五千多个服务，真是微服务架构啊。

如何可能不要迷失在这个一万五千卷经文中，也是很有挑战的事件，须要一个索引和指南，这就是常说的RPC框架和服务注册与发现核心。

为了不便诸多僧侣前来取经，灵山脚下会有一个对立的入口地址，这里有一个神仙，称为金顶大仙，专门来接应取经人的。

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

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

真经曾经筹备好，就差东土取经人了。

-

二、观音奉旨上长安

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

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

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

方才那张图画的是一个可用区的状况，对于多个可用区的状况，咱们能够隐去计算节点的状况，将外网拜访区域放大。

外网IP是放在虚构网关的外网网口上的，这个IP如何让全世界晓得呢？在外围替换里面是安全设备，而后就是边界路由器。边界路由器会和多个运营商连贯，从而每个运营商都可能拜访到这个网站。边界路由器能够通过BGP协定，将本人数据中心外面的外网IP向外播送，也就是通知全世界，如果要拜访这些外网IP，都来我这里。

每个运营商也有很多的路由器、很多的点，于是就能够将如何达到这些IP地址的路由信息，播送到全国乃至全世界。

厉害吧，这是我佛如来通知观音菩萨的：“这一去。要踏看路道，不许在霄汉中行，须是要半云半雾；目过山水，谨记程途远近之数，叮咛那取经人。“

就是说你去东土的路上，通过了哪些路线，要记住门路，要记住远近，能力通知取经人这一路应该怎么走。

-

三、玄奘秉诚建大会

当观音菩萨来到东土大唐，正看到玄奘法师正坐在高台上，率领众人诵经，念一会《受生度亡经》，谈一会《安邦天宝篆》，又宣一会《劝修功卷》。

菩萨近前来，叫道：“那和尚，你只谈判小乘教法，可谈判大乘么？”玄奘闻言，心中大喜，翻身跳上台来，对菩萨起手道：“老师父，弟子失瞻，多罪。见前的盖众僧人，都讲的是小乘教法，却不知大乘教法如何。”菩萨道：“你这小乘教法，度不得亡者超升，只可浑俗和光而已。我有大乘佛法三藏，能超亡者升天，能度难人脱苦，能修无穷寿身，能作无来无去。”

你看，在西方极乐净土，我佛曾经有了更牛的佛经，边远的西方，还在读外乡的僧人晚期从东方传过来的经。

这种模式，称为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地址，就是金顶大仙所在的地位。其实这个时候，金顶大仙曾经在期待了。

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

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

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

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

其实这里的对话是很有意思的，玄奘法师回复李世民的和回复观音菩萨的不同。

这个时候，李世民作为世俗的君王，曾经想求取真经了，也就是东土大唐作为客户端，要发动对于服务端的申请了。然而玄奘法师晓得，唐王李世民去取经，求的是江山永固。所以李世民的申请是应用层的，发动的是HTTP的协定，在HTTP的申请注释中，怕是写的“江山永固”四个字。

而玄奘法师回复观音菩萨的时候，说的就不同了，是一种对于真经和佛法自身的保持。所以玄奘法师是TCP层的，TCP是面向连贯的，TCP 是靠谱的协定，然而这不能阐明它面临的网络环境好。从 IP 层面来讲，如果网络情况确实那么差，是没有任何可靠性保障的，而作为 IP 的上一层 TCP 也无能为力，惟一能做的就是更加致力，一直重传，通过各种算法保障。也就是说，对于 TCP 来讲，IP 层你丢不丢包，我管不着，然而我在我的层面上，会致力保障可靠性。

这一点在流沙河有了验证。观音菩萨度化沙悟净的时候，沙悟净说：“菩萨，我在此间吃人有数，向来有几次取经人来，都被我吃了。凡吃的人头，抛落流沙，竟沉水底(这个水，鹅毛也不能浮)，惟有九个取经人的骷髅，浮在水面，再不能沉。我认为异物，将索儿穿在一处，闲时拿来顽耍，这去，但恐取经人不失去此，却不是反误了我的前程也？”菩萨日：“岂有不到之理？你可将骷髅地挂在头顶下，等待取经入，自有用途。”

所以沙悟净脖子上这九个骷髅，是唐三藏的前九辈子，一旦吃了，就一直的重试。

为了可能实现重试，实现TCP的可靠性，客户端和服务器须要建设连贯。

HTTPS协定是基于TCP协定的，因此要先建设TCP的连贯。在这个例子中，TCP的连贯是从手机上的App和负载均衡器SLB之间的。也就是唐僧和金顶大仙之间，到了金顶大仙，就不怕了，会指引到佛祖那里的。

只管两头要通过很多的路由器和交换机，然而TCP的连贯是端到端的。TCP这一层和更下层的HTTPS无奈看到两头的包的过程。只管建设连贯的时候，所有的包都逃不过在这些路由器和交换机之间的转发，转发的细节咱们放到那个下单申请的发送过程中具体解读，这里只看端到端的行为。

对于TCP连贯来讲，须要通过三次握手建设连贯，为了保护这个连贯，单方都须要在TCP层保护一个连贯的状态机。

一开始，客户端和服务端都处于CLOSED状态。服务端先是被动监听某个端口，处于LISTEN状态。而后客户端被动发动连贯SYN，之后处于SYN-SENT状态。服务端收到发动的连贯，返回SYN，并且ACK客户端的SYN，之后处于SYN-RCVD状态。

客户端收到服务端发送的SYN和ACK之后，发送ACK的ACK，之后处于ESTABLISHED状态。这是因为，它一发一收胜利了。服务端收到ACK的ACK之后，处于ESTABLISHED状态，因为它的一发一收也胜利了。

当TCP层的连贯建设结束之后，接下来轮到HTTPS层建设连贯了，在HTTPS的替换过程中，TCP层始终处于ESTABLISHED。

对于HTTPS，客户端会发送Client Hello音讯到服务器，用明文传输TLS版本信息、加密套件候选列表、压缩算法候选列表等信息。另外，还会有一个随机数，在协商对称密钥的时候应用。

而后，服务器会返回Server Hello音讯，通知客户端，服务器抉择应用的协定版本、加密套件、压缩算法等。这也有一个随机数，用于后续的密钥协商。

而后，服务器会给你一个服务器端的证书，而后说：“Server Hello Done，我这里就这些信息了。”

客户端当然不置信这个证书，于是你从本人信赖的CA仓库中，拿CA的证书外面的公钥去解密电商网站的证书。如果可能胜利，则阐明电商网站是可信的。这个过程中，你可能会一直往上追溯CA、CA的CA、CA的CA的CA，反正直到一个授信的CA，就能够了。

其实观音菩萨手里的锡杖和袈裟，就相当于佛祖方法的证书，保障西行路上的平安，玄奘法师这个网络包别被他人吃了，或者篡改。

就像误入小雷音一集中，白眉老佛想吃了唐僧肉，本人披上袈裟，西天取经，求得正果。

当然，一开始观音菩萨拿出锡杖和袈这个证书的时候，大家也不置信，所以须要观音菩萨现出真身，作为CA，证实给客户端，唐王李世民和玄奘法师才下拜。

证书验证结束之后，感觉这个服务端是可信的，于是客户端计算产生随机数字Pre-master，发送Client Key Exchange，用证书中的公钥加密，再发送给服务器，服务器能够通过私钥解密进去。

接下来，无论是客户端还是服务器，都有了三个随机数，别离是：本人的、对端的，以及刚生成的Pre-Master随机数。通过这三个随机数，能够在客户端和服务器产生雷同的对称密钥。

有了对称密钥，客户端就能够说：“Change Cipher Spec，咱们当前都采纳协商的通信密钥和加密算法进行加密通信了。”

而后客户端发送一个Encrypted Handshake Message，将曾经约定好的参数等，采纳协商密钥进行加密，发送给服务器用于数据与握手验证。

同样，服务器也能够发送Change Cipher Spec，说：“没问题，咱们当前都采纳协商的通信密钥和加密算法进行加密通信了”，并且也发送Encrypted Handshake Message的音讯试试。

当单方握手完结之后，就能够通过对称密钥进行加密传输了。

-

五、唐王素酒送三藏

玄奘这个网络包要收回了。

太宗设朝，汇集文武，要去送行。李世民送给玄奘三个货色。

上一节说了太宗是应用层，关注保大唐江山永固，玄奘是TCP层，要通过动摇的意志达到西天。

李世民给的第一个货色是通关文牒，这个是IP层的，未来要通过这个文牒通过一个个城关。

第二个货色是紫金钵盂，这个用于玄奘法师到了某个城市外面化斋，同时打听路的时候应用，这个是一个MAC层的。

第三个货色是白马一匹，作为近程脚力，这个是物理层的。

最初，太宗敬了玄奘一杯素酒，言道：宁恋本乡一捻土，莫爱他乡万两金。三藏方悟捻土之意，复谢恩饮尽，辞谢出关而去。

当客户端和服务端之间建设了连贯后，接下来就要发送下单申请的网络包了。

在用户层发送的是HTTP的网络包，因为服务端提供的是RESTful API，因此HTTP层发送的就是一个申请。

POST /purchaseOrder HTTP/1.1 Host: www.geektime.com Content-Type: application/json; charset=utf-8 Content-Length: nnn { "order": { "date": "2018-07-01", "className": "趣谈网络协议", "Author": "刘超", "price": "68" } }

HTTP的报文大略分为三大部分。第一局部是申请行，第二局部是申请的首部，第三局部才是申请的注释实体。

在申请行中，URL就是 www.geektime.com/purchaseOrder ，版本为HTTP 1.1。

申请的类型叫作POST，它须要被动通知服务端一些信息，而非获取。须要通知服务端什么呢？个别会放在注释外面。注释能够有各种各样的格局，常见的格局是JSON。

申请行上面就是咱们的首部字段。首部是key value，通过冒号分隔。

Content-Type是指注释的格局。例如，咱们进行POST的申请，如果注释是JSON，那么咱们就应该将这个值设置为JSON。

接下来是注释，这里是一个JSON字符串，外面通过文本的模式形容了，要买一个课程，作者是谁，多少钱。

这样，HTTP申请的报文格式就拼凑好了。接下来浏览器或者挪动App会把它交给下一层传输层。

怎么交给传输层呢？也是用Socket进行程序设计。如果用的是浏览器，这些程序不须要你本人写，有人曾经帮你写好了；如果在挪动APP外面，个别会用一个HTTP的客户端工具来发送，并且帮你封装好。

HTTP协定是基于TCP协定的，所以它应用面向连贯的形式发送申请，通过Stream二进制流的形式传给对方。当然，到了TCP层，它会把二进制流变成一个的报文段发送给服务器。

在TCP头外面，会有源端口号和指标端口号，指标端口号个别是服务端监听的端口号，源端口号在手机端，往往是随机调配一个端口号。这个端口号在客户端和服务端用于辨别申请和返回，发给那个利用。

在IP头外面，都须要加上本人的地址（即源地址）和它想要去的中央（即指标地址）。当一个手机上线的时候，PGW会给这个手机调配一个IP地址，这就是源地址，而指标地址则是云平台的负载均衡器的外网IP地址。

在IP层，客户端须要查看指标地址和本人是否是在同一个局域网，计算是否是同一个网段，往往须要通过CIDR子网掩码来计算。

对于这个下单场景，指标IP和源IP不会在同一个网段，因此须要发送到默认的网关。个别通过DHCP调配IP地址的时候，也会同时配置默认网关的IP地址。

然而客户端不会间接应用默认网关的IP地址，而是发送ARP协定，来获取网关的MAC地址，而后将网关MAC作为指标MAC，本人的MAC作为源MAC，放入MAC头，发送进来。

一个残缺的网络包的格局是这样的。

接下来，网络包就正式收回了。

如果你是用手机关上APP，下单购物发送网络包，个别通过手机运营商的网络。

客户的手机开机当前，在左近寻找基站eNodeB，发送申请，申请上网。基站将申请发给MME，MME对手机进行认证和鉴权，还会申请HSS看有没有钱，看看是在哪里上网。

当MME通过了手机的认证之后，开始建设隧道，建设的数据通路分两段路，其实是两个隧道。一段是从eNodeB到SGW，第二段是从SGW到PGW，在PGW之外，就是互联网。

PGW会为手机调配一个IP地址，手机上网都是带着这个IP地址的。

对于手机来讲，默认的网关在PGW上。在挪动网络外面，从手机到SGW，到PGW是有一条隧道的。在这条隧道外面，会将下面的这个包作为隧道的乘客协定放在外面，里面SGW和PGW在核心网机房的IP地址。网络包直到PGW（PGW是隧道的另一端）才将外面的包解进去，转发到内部网络。

所以，从手机发送进去的时候，网络包的构造为：

  • 源MAC：手机也即UE的MAC；
  • 指标MAC：网关PGW下面的隧道端点的MAC；
  • 源IP：UE的IP地址；
  • 指标IP：SLB的公网IP地址。

进入隧道之后，要封装外层的网络地址，因此网络包的格局为：

  • 外层源MAC：E-NodeB的MAC；
  • 外层指标MAC：SGW的MAC；
  • 外层源IP：E-NodeB的IP；
  • 外层指标IP：SGW的IP；
  • 内层源MAC：手机也即UE的MAC；
  • 内层指标MAC：网关PGW下面的隧道端点的MAC；
  • 内层源IP：UE的IP地址；
  • 内层指标IP：SLB的公网IP地址。

当隧道在SGW的时候，切换了一个隧道，为从SGW到PGW的隧道，因此网络包的格局为：

  • 外层源MAC：SGW的MAC；
  • 外层指标MAC：PGW的MAC；
  • 外层源IP：SGW的IP；
  • 外层指标IP：PGW的IP；
  • 内层源MAC：手机也即UE的MAC；
  • 内层指标MAC：网关PGW下面的隧道端点的MAC；
  • 内层源IP：UE的IP地址；
  • 内层指标IP：SLB的公网IP地址。

在PGW的隧道端点将包解进去，转发进来的时候，个别在PGW出内部网络的路由器上，会部署NAT服务，将手机的IP地址转换为公网IP地址，当申请返回的时候，再NAT回来。

因此在PGW之后，相当于做了一次欧洲十国游型的转发，网络包的格局为：

  • 源MAC：PGW进口的MAC；
  • 指标MAC：NAT网关的MAC；
  • 源IP：UE的IP地址；
  • 指标IP：SLB的公网IP地址。

在NAT网关，相当于做了一次玄奘西游型的转发，网络包的格局变成：

  • 源MAC：NAT网关的MAC；
  • 指标MAC：A2路由器的MAC；
  • 源IP：UE的公网IP地址；
  • 指标IP：SLB的公网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层的缓存就空了进去，这会导致下面图中的大三角，也即接管方可能包容的总缓存，整体顺时针滑动。小的三角形，也即接管方告知发送方的窗口总大小，也即还没有齐全确认收到的缓存大小，如果把这些填满了，就不能再发了，因为没确认收到，所以一个都不能扔。

-

七、功成行满见真如

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

网络包从手机端经验千难万险，终于到了SLB的公网IP所在的公网网口。因为匹配上了MAC地址和IP地址，因此将网络包收了进来。

到了西天，唐僧度过最初一条河凌云仙渡的时候，发现滚浪飞流，约有八九里宽敞，四无人迹。好不容易盼来一条船，还没有底。原来驾船的是接引佛祖，玄奘法师的精神随着河水飘走，从而本性难移，成就金身。

在虚构网关节点的外网网口上，会有一个NAT规定，将公网IP地址转换为VPC外面的私网IP地址，这个私网IP地址就是SLB的HAProxy所在的虚拟机的私网IP地址。

从而网络包也本性难移，实现公网IP到公有网络IP的转换。

当然为了承载比拟大的吞吐量，虚构网关节点会有多个，物理网络会将流量散发到不同的虚构网关节点。同样HAProxy也会是一个大的集群，虚构网关会抉择某个负载平衡节点，将某个申请分发给它，负载平衡之后是Controller层，也是部署在虚拟机外面的。

当网络包外面的指标IP变成公有IP地址地址之后，虚构路由会查找路由规定，将网络包从下方的私网网口收回来。这个时候包的格局为：

  • 源MAC：网关MAC；
  • 指标MAC：HAProxy虚拟机的MAC；
  • 源IP：UE的公网IP；
  • 指标IP：HAProxy虚拟机的私网IP。

在第一局部，咱们 说佛经是寄存在一个虚拟空间外面的，要关上这个虚拟空间，解读经文，须要一个芝麻开门的ID。接引佛祖会给玄奘法师一个ID。

在虚构路由节点上，也会有OVS，将网络包封装在VXLAN隧道外面，VXLAN ID就是给你的租户创立VPC的时候调配的。VXLAN ID就是VPC虚拟空间的ID，OVS就是那个可能封装和解开私密空间的法宝。

包的格局为：

  • 外层源MAC：网关物理机MAC；
  • 外层指标MAC：物理机A的MAC；
  • 外层源IP：网关物理机IP；
  • 外层指标IP：物理机A的IP；
  • 内层源MAC：网关MAC；
  • 内层指标MAC：HAProxy虚拟机的MAC；
  • 内层源IP：UE的公网IP；
  • 内层指标IP：HAProxy虚拟机的私网IP。

在物理机A上，OVS会将包从VXLAN隧道外面解进去，发给HAProxy所在的虚拟机。HAProxy所在的虚拟机发现MAC地址匹配，指标IP地址匹配，就依据TCP端口，将包发给HAProxy过程，因为HAProxy是在监听这个TCP端口的。因此HAProxy就是这个TCP连贯的服务端，客户端是手机。对于TCP的连贯状态，滑动窗口等，都是在HAProxy上保护的。

在这里HAProxy是一个四层负载平衡，也即他只解析到TCP层，外面的HTTP协定他不关怀，就将申请转发给后端的多个Controller层的一个。

HAProxy收回去的网络包就认为HAProxy是客户端了，看不到手机端了。网络包格局如下：

  • 源MAC：HAProxy所在虚拟机的MAC；
  • 指标MAC：Controller层所在虚拟机的MAC；
  • 源IP：HAProxy所在虚拟机的私网IP；
  • 指标IP：Controller层所在虚拟机的私网IP。

当然这个包收回去之后，还是会被物理机上的OVS放入VXLAN隧道外面，网络包格局为：

  • 外层源MAC：物理机A的MAC；
  • 外层指标MAC：物理机B的MAC；
  • 外层源IP：物理机A的IP；
  • 外层指标IP：物理机B的IP；
  • 内层源MAC：HAProxy所在虚拟机的MAC；
  • 内层指标MAC：Controller层所在虚拟机的MAC；
  • 内层源IP：HAProxy所在虚拟机的私网IP；
  • 内层指标IP：Controller层所在虚拟机的私网IP。

在物理机B上，OVS会将包从VXLAN隧道外面解进去，发给Controller层所在的虚拟机。Controller层所在的虚拟机发现MAC地址匹配，指标IP地址匹配，就依据TCP端口，将包发给Controller层的过程，因为他是在监听这个TCP端口的。

在HAProxy和Controller层之间，保护一个TCP的连贯。

Controller层收到包之后，他是关怀HTTP外面是什么的，于是解开HTTP的包，发现是一个POST申请，内容是下单购买一个课程。

-

八、获得真经成金身

玄奘法师终于达到西天大雷音寺，见到了我佛如来。

佛祖违心传经给玄奘，于是让玄奘去藏经楼取经文，谁晓得西天也有西天的规矩，如果不懂这里的规矩，就很难和治理经文的人沟通，取不到真经。

同理，在电商服务外面，往往在组合服务层会有一个专门治理下单的服务，Controller层尽管对外裸露的是规范的RESTful协定，然而对内会通过RPC协定调用这个组合服务层。如果不懂这个协定，就没法通信。

假如咱们应用的是Dubbo，则Controller层须要读取注册核心，将下单服务的过程列表拿进去，选出一个来调用。

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

Netty是一个非阻塞的基于事件的网络传输框架。Controller层和下单服务之间，应用了Netty的网络传输框架。有了Netty，就不必本人编写简单的异步Socket程序了。Netty应用的形式，就是咱们讲Socket编程的时候，一个项目组撑持多个我的项目（IO多路复用，从派人盯着到有事告诉）这种形式。

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

在Netty的服务端，也即下单服务中，收到申请后，先用Hessian2的格局进行解压缩。而后将申请散发到线程中进行解决，在线程中，会调用下单的业务逻辑。

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

下单的业务逻辑比较复杂，往往要调用根底服务层外面的库存服务、优惠券服务等，将多个服务调用结束，才算下单胜利。下单服务调用库存服务和优惠券服务，也是通过Dubbo的框架，通过注册核心拿到库存服务和优惠券服务的列表，而后选一个调用。

调用的时候，对立应用Hessian2进行序列化，应用Netty进行传输，底层如果跨物理机，依然须要通过VXLAN的封装和解封装。

咱们以库存为例子的时候，讲述过幂等的接口实现的问题。因为如果扣减库存，仅仅是谁调用谁减一。这样存在的问题是，如果扣减库存因为一次调用失败，而屡次调用，这里指的不是TCP多次重试，而是应用层调用的多次重试，就会存在库存扣减屡次的状况。

这里罕用的办法是，应用乐观锁（Compare and Set，简称CAS）。CAS要思考三个方面，以后的库存数、预期原来的库存数和版本，以及新的库存数。在操作之前，查问出原来的库存数和版本，真正扣减库存的时候，判断如果以后库存的值与预期原值和版本相匹配，则将库存值更新为新值，否则不做任何操作。

这是一种基于状态而非基于动作的设计，合乎REST的架构设计准则。这样的设计有利于高并发场景。当多个线程尝试应用CAS同时更新同一个变量时，只有其中一个线程能更新变量的值，而其它线程都失败，失败的线程并不会被挂起，而是被告知这次竞争中失败，并能够再次尝试。

最终，当下单更新到分布式数据库中之后，整个下单过程才算真正告一段落。

当然，这个下枯燥用要返回一个后果。

咱们下单胜利啦！！！！！！