专属程序员的西游记,不是程序员读不懂哦?



这是一个有关计算机网络协议的故事java

1、我佛造经传极乐

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

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

我佛所在西牛贺洲,是主站点。算法

在每一个区域Region,为保证真经永固,设置多个藏经楼,称为可用区(Available Zone)。数据库

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

在藏经楼中,柜子根据经文分门别类的组织起来,由不一样的神仙进行管理,管理一个柜子的经文的神仙,访问这里面经文的钥匙就在他手里,称为接入层神仙(接入层交换机)。后端


小编分类整理了许多java进阶学习材料和BAT面试题,须要资料的请加JAVA高阶学习Q群:8515318105;就能领取2019年java架构师进阶学习资料和BAT面试题。浏览器


多个接入层神仙被一组汇聚层神仙(汇聚层交换机)管着,多个汇聚层的神仙被一组核心层神仙(核心交换机)管着。缓存

神仙体系组织严格,井井有条,不一样的接入层神仙交换经文,要经过汇聚层神仙赞成,不一样的汇聚层神仙交换经文,须要核心层神仙赞成。安全

经文的看守要万无一失,于是每一层都是分组看护,互相监督,互相备份,称为堆叠。

虽然说每一个柜子里面放满了经文,为了防止经文被偷听偷看,经文的内容是被仙术封装在一个虚拟的私密空间里面,虽然有人可能会偷到物质的经文,可是没有仙术打开这个私密空间,看到的经文如同空白的同样。这个虚拟的私密空间称为VPC。

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

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

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

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

看来已经前中后台分离,分为基础服务层,组合服务层,Controller层,共三十五个模块,一万五千多个服务,真是微服务架构啊。

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

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

因为前来取经的人不少,同时经文也不少,因此金顶大仙多起到负载均衡的做用,将不一样的取经人引领到不一样的藏经楼,访问不一样的经文。

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

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

2、观音奉旨上长安

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

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

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

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

外网IP是放在虚拟网关的外网网口上的,这个IP如何让全世界知道呢?在核心交换外面是安全设备,而后就是边界路由器。边界路由器会和多个运营商链接,从而每一个运营商都可以访问到这个网站。边界路由器能够经过BGP协议,将本身数据中内心面的外网IP向外广播,也就是告诉全世界,若是要访问这些外网IP,都来我这里。

每一个运营商也有不少的路由器、不少的点,因而就能够将如何到达这些IP地址的路由信息,广播到全国乃至全世界。

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

就是说你去东土的路上,通过了哪些道路,要记住路径,要记住远近,才能告诉取经人这一路应该怎么走。

3、玄奘秉诚建大会

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

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

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

这种模式,称为CDN。

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

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

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

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

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

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

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

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

然而缓存的佛经固然是比不上西天取到的经文更新,因此东土因为离西天较远,缓存的仍是小乘佛教,要读大乘佛教,就要去西天取经,称为回源。

4、观音显像化金蝉 小编分类整理了许多java进阶学习材料和BAT面试题,须要资料的请加JAVA高阶学习Q群:8515318105;就能领取2019年java架构师进阶学习资料和BAT面试题。

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

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

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

这个过程称为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的消息试试。

当双方握手结束以后,就能够经过对称密钥进行加密传输了。

5、唐王素酒送三藏

玄奘这个网络包要发出了。

太宗设朝,汇集文武,要去送行。李世民送给玄奘三个东西。

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

李世民给的第一个东西是通关文牒,这个是IP层的,未来要经过这个文牒经过一个个城关。

第二个东西是紫金钵盂,这个用于玄奘法师到了某个城市里面化斋,同时打听路的时候使用,这个是一个MAC层的。

第三个东西是白马一匹,做为远程脚力,这个是物理层的。

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

当客户端和服务端之间创建了链接后,接下来就要发送下单请求的网络包了。

在用户层发送的是HTTP的网络包,由于服务端提供的是RESTful API,于是HTTP层发送的就是一个请求。

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地址。

            在手机运营商的网络里面,网络情况是比较好的。

            对于玄奘法师,在大唐国境以内,仍是比较平安的。原文说:们行了很多天,到了巩州城。早有巩州合属官吏人等,迎接入城中。安歇一晚上,次早出城前去。一路饥餐渴饮,夜住晓行,两三日,又至河州卫。早有镇边的总兵与本处僧道,闻得是钦差御弟法师上西方见佛,无不恭敬,接至里面供给了,着僧纲请往福原寺安歇。本寺僧人,一一参见,安排晚斋。斋毕,吩咐二从者饱喂马匹,天不明就行。

            真的是有接有送。

            行经半日,只见对面处,有一座大山,真个是高接青霄,崔巍险峻。此山唤作两界山,东半边属我大唐所管,西半边乃是鞑靼的地界。过了这座山,就不是大唐的土地了。

            6、历经千山与万险

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

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


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

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

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

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

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

            菩萨的法术是什么呢?我们在大学里面学习计算机网络与数据结构的时候,知道求最短路径经常使用的有两种方法,一种是 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层的缓存就空了出来,这会致使上面图中的大三角,也即接收方可以容纳的总缓存,总体顺时针滑动。小的三角形,也即接收方告知发送方的窗口总大小,也即尚未彻底确认收到的缓存大小,若是把这些填满了,就不能再发了,由于没确认收到,因此一个都不能扔。

              7、功成行满见真如

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

              网络包从手机端经历千难万险,终于到了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请求,内容是下单购买一个课程。


                      小编分类整理了许多java进阶学习材料和BAT面试题,须要资料的请加JAVA高阶学习Q群:8515318105;就能领取2019年java架构师进阶学习资料和BAT面试题。


                      8、取得真经成金身

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

                      佛祖愿意传经给玄奘,因而让玄奘去藏经楼取经文,谁知道西天也有西天的规矩,若是不懂这里的规矩,就很难和管理经文的人沟通,取不到真经。

                      同理,在电商服务里面,每每在组合服务层会有一个专门管理下单的服务,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同时更新同一个变量时,只有其中一个线程能更新变量的值,而其它线程都失败,失败的线程并不会被挂起,而是被告知此次竞争中失败,并能够再次尝试。

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

                      固然,这个下单调用要返回一个结果。

                      咱们下单成功啦!!!!!!


                      小编分类整理了许多java进阶学习材料和BAT面试题,须要资料的请加JAVA高阶学习Q群:8515318105;就能领取2019年java架构师进阶学习资料和BAT面试题。

                      相关文章
                      相关标签/搜索