共计 14418 个字符，预计需要花费 37 分钟才能阅读完成。
前言
这是一个无关计算机网络协定的故事。一家之言，不用当真，欢送进群 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 同时更新同一个变量时，只有其中一个线程能更新变量的值，而其它线程都失败，失败的线程并不会被挂起，而是被告知这次竞争中失败，并能够再次尝试。
最终，当下单更新到分布式数据库中之后，整个下单过程才算真正告一段落。
当然，这个下枯燥用要返回一个后果。
咱们下单胜利啦！！！！！！
