mirror of
https://github.com/cheetahlou/CategoryResourceRepost.git
synced 2025-11-16 22:23:45 +08:00
mod
This commit is contained in:
louzefeng
@@ -0,0 +1,93 @@
|
||||
<audio id="audio" title="第37讲 | 知识串讲：用双十一的故事串起碎片的网络协议（上）" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/7c/6a/7c5687c9e0486d2435efe8f0d779e76a.mp3"></audio>
|
||||
|
||||
基本的网络知识我们都讲完了，还记得最初举的那个“双十一”下单的例子吗？这一节开始，我们详细地讲解这个过程，用这个过程串起我们讲过的网络协议。
|
||||
|
||||
我把这个过程分为十个阶段，从云平台中搭建一个电商开始，到BGP路由广播，再到DNS域名解析，从客户看商品图片，到最终下单的整个过程，每一步我都会详细讲解。这节我们先来看前三个阶段。
|
||||
|
||||
## 1.部署一个高可用高并发的电商平台
|
||||
|
||||
首先，咱们**要有个电商平台**。假设我们已经有了一个特别大的电商平台，这个平台应该部署在哪里呢？假设我们用公有云，一般公有云会有多个位置，比如在华东、华北、华南都有。毕竟咱们的电商是要服务全国的，当然到处都要部署了。我们把主站点放在华东。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/ed/20/eddde5929de2a72b197321e5ad87e120.jpg" alt="" />
|
||||
|
||||
为了每个点都能“雨露均沾”，也为了高可用性，往往需要有多个机房，形成多个可用区（Available Zone）。由于咱们的应用是分布在两个可用区的，所以假如任何一个可用区挂了，都不会受影响。
|
||||
|
||||
我们来回想[数据中心](https://time.geekbang.org/column/article/10098)那一节，每个可用区里有一片一片的机柜，每个机柜上有一排一排的服务器，每个机柜都有一个接入交换机，有一个汇聚交换机将多个机柜连在一起。
|
||||
|
||||
这些服务器里面部署的都是计算节点，每台上面都有Open vSwitch创建的虚拟交换机，将来在这台机器上创建的虚拟机，都会连到Open vSwitch上。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/d6/a7/d66c01c39e911e784525a118c37b50a7.jpg" alt="" />
|
||||
|
||||
接下来，你**在云计算的界面上创建一个VPC**（Virtual Private Cloud，虚拟私有网络），指定一个IP段，这样以后你部署的所有应用都会在这个虚拟网络里，使用你分配的这个IP段。为了不同的VPC相互隔离，每个VPC都会被分配一个VXLAN的ID。尽管不同用户的虚拟机有可能在同一个物理机上，但是不同的VPC二层压根儿是不通的。
|
||||
|
||||
由于有两个可用区，在这个VPC里面，要为每一个可用区分配一个Subnet，也就是在大的网段里分配两个小的网段。当两个可用区里面网段不同的时候，就可以配置路由策略，访问另外一个可用区，走某一条路由了。
|
||||
|
||||
接下来，应该**创建数据库持久化层**。大部分云平台都会提供PaaS服务，也就是说，不需要你自己搭建数据库，而是采用直接提供数据库的服务，并且单机房的主备切换都是默认做好的，数据库也是部署在虚拟机里面的，只不过从界面上，你看不到数据库所在的虚拟机而已。
|
||||
|
||||
云平台会给每个Subnet的数据库实例分配一个域名。创建数据库实例的时候，需要你指定可用区和Subnet，这样创建出来的数据库实例可以通过这个Subnet的私网IP进行访问。
|
||||
|
||||
为了分库分表实现高并发的读写，在创建的多个数据库实例之上，会**创建一个分布式数据库的实例**，也需要指定可用区和Subnet，还会为分布式数据库分配一个私网IP和域名。
|
||||
|
||||
对于数据库这种高可用性比较高的，需要进行跨机房高可用，因而两个可用区都要部署一套，但是只有一个是主，另外一个是备，云平台往往会提供数据库同步工具，将应用写入主的数据同步给备数据库集群。
|
||||
|
||||
接下来是**创建缓存集**群。云平台也会提供PaaS服务，也需要每个可用区和Subnet创建一套，缓存的数据在内存中，由于读写性能要求高，一般不要求跨可用区读写。
|
||||
|
||||
再往上层就是**部署咱们自己写的程序**了。基础服务层、组合服务层、Controller层，以及Nginx层、API网关等等，这些都是部署在虚拟机里面的。它们之间通过RPC相互调用，需要到注册中心进行注册。
|
||||
|
||||
它们之间的网络通信是虚拟机和虚拟机之间的。如果是同一台物理机，则那台物理机上的OVS就能转发过去；如果是不同的物理机，这台物理机的OVS和另一台物理机的OVS中间有一个VXLAN的隧道，将请求转发过去。
|
||||
|
||||
再往外就是**负载均衡**了，负载均衡也是云平台提供的PaaS服务，也是属于某个VPC的，部署在虚拟机里面的，但是负载均衡有个外网的IP，这个外网的IP地址就是在网关节点的外网网口上的。在网关节点上，会有NAT规则，将外网IP地址转换为VPC里面的私网IP地址，通过这些私网IP地址访问到虚拟机上的负载均衡节点，然后通过负载均衡节点转发到API网关的节点。
|
||||
|
||||
网关节点的外网网口是带公网IP地址的，里面有一个虚拟网关转发模块，还会有一个OVS，将私网IP地址放到VXLAN隧道里面，转发到虚拟机上，从而实现外网和虚拟机网络之间的互通。
|
||||
|
||||
不同的可用区之间，通过核心交换机连在一起，核心交换机之外是边界路由器。
|
||||
|
||||
在华北、华东、华南同样也部署了一整套，每个地区都创建了VPC，这就需要有一种机制将VPC连接到一起。云平台一般会提供硬件的VPC互连的方式，当然也可以使用软件互连的方式，也就是使用VPN网关，通过IPsec VPN将不同地区的不同VPC通过VPN连接起来。
|
||||
|
||||
对于不同地区和不同运营商的用户，我们希望他能够就近访问到网站，而且当一个点出了故障之后，我们希望能够在不同的地区之间切换，这就需要有智能DNS，这个也是云平台提供的。
|
||||
|
||||
对于一些静态资源，可以保持在对象存储里面，通过CDN下发到边缘节点，这样客户端就能尽快加载出来。
|
||||
|
||||
## 2.大声告诉全世界，可以到我这里买东西
|
||||
|
||||
当电商应用搭建完毕之后，接下来需要将如何访问到这个电商网站广播给全网。
|
||||
|
||||
刚才那张图画的是一个可用区的情况，对于多个可用区的情况，我们可以隐去计算节点的情况，将外网访问区域放大。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/e1/24/e132bc3ba500b1197139f30c02e20124.jpg" alt="" />
|
||||
|
||||
外网IP是放在虚拟网关的外网网口上的，这个IP如何让全世界知道呢？当然是通过BGP路由协议了。
|
||||
|
||||
每个可用区都有自己的汇聚交换机，如果机器数目比较多，可以直接用核心交换机，每个Region也有自己的核心交换区域。
|
||||
|
||||
在核心交换外面是安全设备，然后就是边界路由器。边界路由器会和多个运营商连接，从而每个运营商都能够访问到这个网站。边界路由器可以通过BGP协议，将自己数据中心里面的外网IP向外广播，也就是告诉全世界，如果要访问这些外网IP，都来我这里。
|
||||
|
||||
每个运营商也有很多的路由器、很多的点，于是就可以将如何到达这些IP地址的路由信息，广播到全国乃至全世界。
|
||||
|
||||
## 3.打开手机来上网，域名解析得地址
|
||||
|
||||
这个时候，不但你的这个网站的IP地址全世界都知道了，你打的广告可能大家也都看到了，于是有客户下载App来买东西了。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/85/fc/85c125c225faba29c0f374e18ea8c6fc.jpg" alt="" />
|
||||
|
||||
客户的手机开机以后，在附近寻找基站eNodeB，发送请求，申请上网。基站将请求发给MME，MME对手机进行认证和鉴权，还会请求HSS看有没有钱，看看是在哪里上网。
|
||||
|
||||
当MME通过了手机的认证之后，开始建立隧道，建设的数据通路分两段路，其实是两个隧道。一段是从eNodeB到SGW，第二段是从SGW到PGW，在PGW之外，就是互联网。
|
||||
|
||||
PGW会为手机分配一个IP地址，手机上网都是带着这个IP地址的。
|
||||
|
||||
当在手机上面打开一个App的时候，首先要做的事情就是解析这个网站的域名。
|
||||
|
||||
在手机运营商所在的互联网区域里，有一个本地的DNS，手机会向这个DNS请求解析DNS。当这个DNS本地有缓存，则直接返回；如果没有缓存，本地DNS才需要递归地从根DNS服务器，查到.com的顶级域名服务器，最终查到权威DNS服务器。
|
||||
|
||||
如果你使用云平台的时候，配置了智能DNS和全局负载均衡，在权威DNS服务中，一般是通过配置CNAME的方式，我们可以起一个别名，例如 [vip.yourcomany.com](http://vip.yourcomany.com) ，然后告诉本地DNS服务器，让它请求GSLB解析这个域名，GSLB就可以在解析这个域名的过程中，通过自己的策略实现负载均衡。
|
||||
|
||||
GSLB通过查看请求它的本地DNS服务器所在的运营商和地址，就知道用户所在的运营商和地址，然后将距离用户位置比较近的Region里面，三个负载均衡SLB的公网IP地址，返回给本地DNS服务器。本地DNS解析器将结果缓存后，返回给客户端。
|
||||
|
||||
对于手机App来说，可以绕过刚才的传统DNS解析机制，直接只要HTTPDNS服务，通过直接调用HTTPDNS服务器，得到这三个SLB的公网IP地址。
|
||||
|
||||
看，经过了如此复杂的过程，咱们的万里长征还没迈出第一步，刚刚得到IP地址，包还没发呢？话说手机App拿到了公网IP地址，接下来应该做什么呢？
|
||||
|
||||
欢迎你留言和我讨论。趣谈网络协议，我们下期见！
|
||||
|
||||
|
||||
130
极客时间专栏/趣谈网络协议/第四模块 网络协议知识串讲/第38讲 | 知识串讲：用双十一的故事串起碎片的网络协议（中）.md
Normal file
130
极客时间专栏/趣谈网络协议/第四模块 网络协议知识串讲/第38讲 | 知识串讲：用双十一的故事串起碎片的网络协议（中）.md
Normal file
@@ -0,0 +1,130 @@
|
||||
<audio id="audio" title="第38讲 | 知识串讲：用双十一的故事串起碎片的网络协议（中）" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/6d/e8/6d61c5d70872758beb9c2b1fa3e434e8.mp3"></audio>
|
||||
|
||||
上一节我们讲到，手机App经过了一个复杂的过程，终于拿到了电商网站的SLB的IP地址，是不是该下单了？
|
||||
|
||||
别忙，俗话说的好，买东西要货比三家。大部分客户在购物之前要看很多商品图片，比来比去，最后好不容易才下决心，点了下单按钮。下单按钮一按，就要开始建立连接。建立连接这个过程也挺复杂的，最终还要经过层层封装，才构建出一个完整的网络包。今天我们就来看这个过程。
|
||||
|
||||
## 4.购物之前看图片，静态资源CDN
|
||||
|
||||
客户想要在购物网站买一件东西的时候，一般是先去详情页看看图片，是不是想买的那一款。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/70/69/7023762edeaf4d481bc90331f60db769.jpg" alt="">
|
||||
|
||||
|
||||
|
||||
我们部署电商应用的时候，一般会把静态资源保存在两个地方，一个是接入层nginx后面的varnish缓存里面，一般是静态页面；对于比较大的、不经常更新的静态图片，会保存在对象存储里面。这两个地方的静态资源都会配置CDN，将资源下发到边缘节点。
|
||||
|
||||
配置了CDN之后，权威DNS服务器上，会为静态资源设置一个CNAME别名，指向另外一个域名 cdn.com ，返回给本地DNS服务器。
|
||||
|
||||
当本地DNS服务器拿到这个新的域名时，需要继续解析这个新的域名。这个时候，再访问的时候就不是原来的权威DNS服务器了，而是 cdn.com 的权威DNS服务器。这是CDN自己的权威DNS服务器。
|
||||
|
||||
在这个服务器上，还是会设置一个CNAME，指向另外一个域名，也即CDN网络的全局负载均衡器。
|
||||
|
||||
本地DNS服务器去请求CDN的全局负载均衡器解析域名，全局负载均衡器会为用户选择一台合适的缓存服务器提供服务，将IP返回给客户端，客户端去访问这个边缘节点，下载资源。缓存服务器响应用户请求，将用户所需内容传送到用户终端。
|
||||
|
||||
如果这台缓存服务器上并没有用户想要的内容，那么这台服务器就要向它的上一级缓存服务器请求内容，直至追溯到网站的源服务器，将内容拉到本地。
|
||||
|
||||
## 5.看上宝贝点下单，双方开始建连接
|
||||
|
||||
当你浏览了很多图片，发现实在喜欢某个商品，于是决定下单购买。
|
||||
|
||||
电商网站会对下单的情况提供RESTful的下单接口，而对于下单这种需要保密的操作，需要通过HTTPS协议进行请求。
|
||||
|
||||
在所有这些操作之前，首先要做的事情是**建立连接**。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/70/83/705e4cc5acc7b364bdf015f333d40783.jpg" alt="">
|
||||
|
||||
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，就可以了。
|
||||
|
||||
证书验证完毕之后，觉得这个服务端是可信的，于是客户端计算产生随机数字Pre-master，发送Client Key Exchange，用证书中的公钥加密，再发送给服务器，服务器可以通过私钥解密出来。
|
||||
|
||||
接下来，无论是客户端还是服务器，都有了三个随机数，分别是：自己的、对端的，以及刚生成的Pre-Master随机数。通过这三个随机数，可以在客户端和服务器产生相同的对称密钥。
|
||||
|
||||
有了对称密钥，客户端就可以说：“Change Cipher Spec，咱们以后都采用协商的通信密钥和加密算法进行加密通信了。”
|
||||
|
||||
然后客户端发送一个Encrypted Handshake Message，将已经商定好的参数等，采用协商密钥进行加密，发送给服务器用于数据与握手验证。
|
||||
|
||||
同样，服务器也可以发送Change Cipher Spec，说：“没问题，咱们以后都采用协商的通信密钥和加密算法进行加密通信了”，并且也发送Encrypted Handshake Message的消息试试。
|
||||
|
||||
当双方握手结束之后，就可以通过对称密钥进行加密传输了。
|
||||
|
||||
真正的下单请求封装成网络包的发送过程，我们先放一放，我们来接着讲这个网络包的故事。
|
||||
|
||||
## 6.发送下单请求网络包，西行需要出网关
|
||||
|
||||
当客户端和服务端之间建立了连接后，接下来就要发送下单请求的网络包了。
|
||||
|
||||
在用户层发送的是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头，发送出去。
|
||||
|
||||
一个完整的网络包的格式是这样的。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/99/49/99c282efaca15deb79c7821c9c577349.jpg" alt="">
|
||||
|
||||
|
||||
|
||||
真不容易啊，本来以为上篇就发送下单包了，结果到中篇这个包还没发送出去，只是封装了一个如此长的网络包。别着急，你可以自己先预想一下，接下来该做什么了？
|
||||
|
||||
欢迎你留言和我讨论。趣谈网络协议，我们下期见！
|
||||
301
极客时间专栏/趣谈网络协议/第四模块 网络协议知识串讲/第39讲 | 知识串讲：用双十一的故事串起碎片的网络协议（下）.md
Normal file
301
极客时间专栏/趣谈网络协议/第四模块 网络协议知识串讲/第39讲 | 知识串讲：用双十一的故事串起碎片的网络协议（下）.md
Normal file
@@ -0,0 +1,301 @@
|
||||
<audio id="audio" title="第39讲 | 知识串讲：用双十一的故事串起碎片的网络协议（下）" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/5f/94/5fe9b9e65108cda410e851c60897ea94.mp3"></audio>
|
||||
|
||||
上一节，我们封装了一个长长的网络包，“大炮”准备完毕，开始发送。
|
||||
|
||||
发送的时候可以说是重重关隘，从手机到移动网络、互联网，还要经过多个运营商才能到达数据中心，到了数据中心就进入第二个复杂的过程，从网关到VXLAN隧道，到负载均衡，到Controller层、组合服务层、基础服务层，最终才下单入库。今天，我们就来看这最后一段过程。
|
||||
|
||||
## 7.一座座城池一道道关，流控拥塞与重传
|
||||
|
||||
网络包已经组合完毕，接下来我们来看，如何经过一道道城关，到达目标公网IP。
|
||||
|
||||
对于手机来讲，默认的网关在PGW上。在移动网络里面，从手机到SGW，到PGW是有一条隧道的。在这条隧道里面，会将上面的这个包作为隧道的乘客协议放在里面，外面SGW和PGW在核心网机房的IP地址。网络包直到PGW（PGW是隧道的另一端）才将里面的包解出来，转发到外部网络。
|
||||
|
||||
所以，从手机发送出来的时候，网络包的结构为：
|
||||
|
||||
<li>
|
||||
源MAC：手机也即UE的MAC；
|
||||
</li>
|
||||
<li>
|
||||
目标MAC：网关PGW上面的隧道端点的MAC；
|
||||
</li>
|
||||
<li>
|
||||
源IP：UE的IP地址；
|
||||
</li>
|
||||
<li>
|
||||
目标IP：SLB的公网IP地址。
|
||||
</li>
|
||||
|
||||
进入隧道之后，要封装外层的网络地址，因而网络包的格式为：
|
||||
|
||||
<li>
|
||||
外层源MAC：E-NodeB的MAC；
|
||||
</li>
|
||||
<li>
|
||||
外层目标MAC：SGW的MAC；
|
||||
</li>
|
||||
<li>
|
||||
外层源IP：E-NodeB的IP；
|
||||
</li>
|
||||
<li>
|
||||
外层目标IP：SGW的IP；
|
||||
</li>
|
||||
<li>
|
||||
内层源MAC：手机也即UE的MAC；
|
||||
</li>
|
||||
<li>
|
||||
内层目标MAC：网关PGW上面的隧道端点的MAC；
|
||||
</li>
|
||||
<li>
|
||||
内层源IP：UE的IP地址；
|
||||
</li>
|
||||
<li>
|
||||
内层目标IP：SLB的公网IP地址。
|
||||
</li>
|
||||
|
||||
当隧道在SGW的时候，切换了一个隧道，会从SGW到PGW的隧道，因而网络包的格式为：
|
||||
|
||||
<li>
|
||||
外层源MAC：SGW的MAC；
|
||||
</li>
|
||||
<li>
|
||||
外层目标MAC：PGW的MAC；
|
||||
</li>
|
||||
<li>
|
||||
外层源IP：SGW的IP；
|
||||
</li>
|
||||
<li>
|
||||
外层目标IP：PGW的IP；
|
||||
</li>
|
||||
<li>
|
||||
内层源MAC：手机也即UE的MAC；
|
||||
</li>
|
||||
<li>
|
||||
内层目标MAC：网关PGW上面的隧道端点的MAC；
|
||||
</li>
|
||||
<li>
|
||||
内层源IP：UE的IP地址；
|
||||
</li>
|
||||
<li>
|
||||
内层目标IP：SLB的公网IP地址。
|
||||
</li>
|
||||
|
||||
在PGW的隧道端点将包解出来，转发出去的时候，一般在PGW出外部网络的路由器上，会部署NAT服务，将手机的IP地址转换为公网IP地址，当请求返回的时候，再NAT回来。
|
||||
|
||||
因而在PGW之后，相当于做了一次[欧洲十国游型](https://time.geekbang.org/column/article/8590)的转发，网络包的格式为：
|
||||
|
||||
<li>
|
||||
源MAC：PGW出口的MAC；
|
||||
</li>
|
||||
<li>
|
||||
目标MAC：NAT网关的MAC；
|
||||
</li>
|
||||
<li>
|
||||
源IP：UE的IP地址；
|
||||
</li>
|
||||
<li>
|
||||
目标IP：SLB的公网IP地址。
|
||||
</li>
|
||||
|
||||
在NAT网关，相当于做了一次[玄奘西游型](https://time.geekbang.org/column/article/8590)的转发，网络包的格式变成：
|
||||
|
||||
<li>
|
||||
源MAC：NAT网关的MAC；
|
||||
</li>
|
||||
<li>
|
||||
目标MAC：A2路由器的MAC；
|
||||
</li>
|
||||
<li>
|
||||
源IP：UE的公网IP地址；
|
||||
</li>
|
||||
<li>
|
||||
目标IP：SLB的公网IP地址。
|
||||
</li>
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/58/a0/582c9515a877a6fde85a6180186ba8a0.jpg" alt="">
|
||||
|
||||
出了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的滑动窗口协议**。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/8a/3d/8af90ec349e69f2bf13a565e4179903d.jpg" alt="">
|
||||
|
||||
整个TCP的发送，一开始会协商一个Sequence Number，从这个Sequence Number开始，每个包都有编号。滑动窗口将接收方的网络包分成四个部分：
|
||||
|
||||
<li>
|
||||
已经接收，已经ACK，已经交给应用层的包；
|
||||
</li>
|
||||
<li>
|
||||
已经接收，已经ACK，未发送给应用层；
|
||||
</li>
|
||||
<li>
|
||||
已经接收，尚未发送ACK；
|
||||
</li>
|
||||
<li>
|
||||
未接收，尚有空闲的缓存区域。
|
||||
</li>
|
||||
|
||||
对于TCP层来讲，每一个包都有ACK。ACK需要从SLB回复到手机端，将上面的那个过程反向来一遍，当然路径不一定一致，可见ACK也不是那么轻松的事情。
|
||||
|
||||
如果发送方超过一定的时间没有收到ACK，就会重新发送。只有TCP层ACK过的包，才会发给应用层，并且只会发送一份，对于下单的场景，应用层是HTTP层。
|
||||
|
||||
你可能会问了，TCP老是重复发送，会不会导致一个单下了两遍？是否要求服务端实现幂等？从TCP的机制来看，是不会的。只有收不到ACK的包才会重复发，发到接收端，在窗口里面只保存一份，所以在同一个TCP连接中，不用担心重传导致二次下单。
|
||||
|
||||
但是TCP连接会因为某种原因断了，例如手机信号不好，这个时候手机把所有的动作重新做一遍，建立一个新的TCP连接，在HTTP层调用两次RESTful API。这个时候可能会导致两遍下单的情况，因而RESTful API需要实现幂等。
|
||||
|
||||
当ACK过的包发给应用层之后，TCP层的缓存就空了出来，这会导致上面图中的大三角，也即接收方能够容纳的总缓存，整体顺时针滑动。小的三角形，也即接收方告知发送方的窗口总大小，也即还没有完全确认收到的缓存大小，如果把这些填满了，就不能再发了，因为没确认收到，所以一个都不能扔。
|
||||
|
||||
## 8.从数据中心进网关，公网NAT成私网
|
||||
|
||||
包从手机端经历千难万险，终于到了SLB的公网IP所在的公网网口。由于匹配上了MAC地址和IP地址，因而将网络包收了进来。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/e0/95/e070a0bcbb249c36c80ee1300003f395.jpg" alt="">
|
||||
|
||||
在虚拟网关节点的外网网口上，会有一个NAT规则，将公网IP地址转换为VPC里面的私网IP地址，这个私网IP地址就是SLB的HAProxy所在的虚拟机的私网IP地址。
|
||||
|
||||
当然为了承载比较大的吞吐量，虚拟网关节点会有多个，物理网络会将流量分发到不同的虚拟网关节点。同样HAProxy也会是一个大的集群，虚拟网关会选择某个负载均衡节点，将某个请求分发给它，负载均衡之后是Controller层，也是部署在虚拟机里面的。
|
||||
|
||||
当网络包里面的目标IP变成私有IP地址之后，虚拟路由会查找路由规则，将网络包从下方的私网网口发出来。这个时候包的格式为：
|
||||
|
||||
<li>
|
||||
源MAC：网关MAC；
|
||||
</li>
|
||||
<li>
|
||||
目标MAC：HAProxy虚拟机的MAC；
|
||||
</li>
|
||||
<li>
|
||||
源IP：UE的公网IP；
|
||||
</li>
|
||||
<li>
|
||||
目标IP：HAProxy虚拟机的私网IP。
|
||||
</li>
|
||||
|
||||
## 9.进入隧道打标签，RPC远程调用下单
|
||||
|
||||
在虚拟路由节点上，也会有OVS，将网络包封装在VXLAN隧道里面，VXLAN ID就是给你的租户创建VPC的时候分配的。包的格式为：
|
||||
|
||||
<li>
|
||||
外层源MAC：网关物理机MAC；
|
||||
</li>
|
||||
<li>
|
||||
外层目标MAC：物理机A的MAC；
|
||||
</li>
|
||||
<li>
|
||||
外层源IP：网关物理机IP；
|
||||
</li>
|
||||
<li>
|
||||
外层目标IP：物理机A的IP；
|
||||
</li>
|
||||
<li>
|
||||
内层源MAC：网关MAC；
|
||||
</li>
|
||||
<li>
|
||||
内层目标MAC：HAProxy虚拟机的MAC；
|
||||
</li>
|
||||
<li>
|
||||
内层源IP：UE的公网IP；
|
||||
</li>
|
||||
<li>
|
||||
内层目标IP：HAProxy虚拟机的私网IP。
|
||||
</li>
|
||||
|
||||
在物理机A上，OVS会将包从VXLAN隧道里面解出来，发给HAProxy所在的虚拟机。HAProxy所在的虚拟机发现MAC地址匹配，目标IP地址匹配，就根据TCP端口，将包发给HAProxy进程，因为HAProxy是在监听这个TCP端口的。因而HAProxy就是这个TCP连接的服务端，客户端是手机。对于TCP的连接状态、滑动窗口等，都是在HAProxy上维护的。
|
||||
|
||||
在这里HAProxy是一个四层负载均衡，也即它只解析到TCP层，里面的HTTP协议它不关心，就将请求转发给后端的多个Controller层的一个。
|
||||
|
||||
HAProxy发出去的网络包就认为HAProxy是客户端了，看不到手机端了。网络包格式如下：
|
||||
|
||||
<li>
|
||||
源MAC：HAProxy所在虚拟机的MAC；
|
||||
</li>
|
||||
<li>
|
||||
目标MAC：Controller层所在虚拟机的MAC；
|
||||
</li>
|
||||
<li>
|
||||
源IP：HAProxy所在虚拟机的私网IP；
|
||||
</li>
|
||||
<li>
|
||||
目标IP：Controller层所在虚拟机的私网IP。
|
||||
</li>
|
||||
|
||||
当然这个包发出去之后，还是会被物理机上的OVS放入VXLAN隧道里面，网络包格式为：
|
||||
|
||||
<li>
|
||||
外层源MAC：物理机A的MAC；
|
||||
</li>
|
||||
<li>
|
||||
外层目标MAC：物理机B的MAC；
|
||||
</li>
|
||||
<li>
|
||||
外层源IP：物理机A的IP；
|
||||
</li>
|
||||
<li>
|
||||
外层目标IP：物理机B的IP；
|
||||
</li>
|
||||
<li>
|
||||
内层源MAC：HAProxy所在虚拟机的MAC；
|
||||
</li>
|
||||
<li>
|
||||
内层目标MAC：Controller层所在虚拟机的MAC；
|
||||
</li>
|
||||
<li>
|
||||
内层源IP：HAProxy所在虚拟机的私网IP；
|
||||
</li>
|
||||
<li>
|
||||
内层目标IP：Controller层所在虚拟机的私网IP。
|
||||
</li>
|
||||
|
||||
在物理机B上，OVS会将包从VXLAN隧道里面解出来，发给Controller层所在的虚拟机。Controller层所在的虚拟机发现MAC地址匹配，目标IP地址匹配，就根据TCP端口，将包发给Controller层的进程，因为它在监听这个TCP端口。
|
||||
|
||||
在HAProxy和Controller层之间，维护一个TCP的连接。
|
||||
|
||||
Controller层收到包之后，它是关心HTTP里面是什么的，于是解开HTTP的包，发现是一个POST请求，内容是下单购买一个课程。
|
||||
|
||||
## 10.下单扣减库存优惠券，数据入库返回成功
|
||||
|
||||
下单是一个复杂的过程，因而往往在组合服务层会有一个专门管理下单的服务，Controller层会通过RPC调用这个组合服务层。
|
||||
|
||||
假设我们使用的是Dubbo，则Controller层需要读取注册中心，将下单服务的进程列表拿出来，选出一个来调用。
|
||||
|
||||
Dubbo中默认的RPC协议是Hessian2。Hessian2将下单的远程调用序列化为二进制进行传输。
|
||||
|
||||
Netty是一个非阻塞的基于事件的网络传输框架。Controller层和下单服务之间，使用了Netty的网络传输框架。有了Netty，就不用自己编写复杂的异步Socket程序了。Netty使用的方式，就是咱们讲[Socket编程](https://time.geekbang.org/column/article/9293)的时候，一个项目组支撑多个项目（IO多路复用，从派人盯着到有事通知）这种方式。
|
||||
|
||||
Netty还是工作在Socket这一层的，发送的网络包还是基于TCP的。在TCP的下层，还是需要封装上IP头和MAC头。如果跨物理机通信，还是需要封装的外层的VXLAN隧道里面。当然底层的这些封装，Netty都不感知，它只要做好它的异步通信即可。
|
||||
|
||||
在Netty的服务端，也即下单服务中，收到请求后，先用Hessian2的格式进行解压缩。然后将请求分发到线程中进行处理，在线程中，会调用下单的业务逻辑。
|
||||
|
||||
下单的业务逻辑比较复杂，往往要调用基础服务层里面的库存服务、优惠券服务等，将多个服务调用完毕，才算下单成功。下单服务调用库存服务和优惠券服务，也是通过Dubbo的框架，通过注册中心拿到库存服务和优惠券服务的列表，然后选一个调用。
|
||||
|
||||
调用的时候，统一使用Hessian2进行序列化，使用Netty进行传输，底层如果跨物理机，仍然需要通过VXLAN的封装和解封装。
|
||||
|
||||
咱们以库存为例子的时候，讲述过幂等的接口实现的问题。因为如果扣减库存，仅仅是谁调用谁减一。这样存在的问题是，如果扣减库存因为一次调用失败，而多次调用，这里指的不是TCP多次重试，而是应用层调用的多次重试，就会存在库存扣减多次的情况。
|
||||
|
||||
这里常用的方法是，使用乐观锁（Compare and Set，简称CAS）。CAS要考虑三个方面，当前的库存数、预期原来的库存数和版本，以及新的库存数。在操作之前，查询出原来的库存数和版本，真正扣减库存的时候，判断如果当前库存的值与预期原值和版本相匹配，则将库存值更新为新值，否则不做任何操作。
|
||||
|
||||
这是一种基于状态而非基于动作的设计，符合RESTful的架构设计原则。这样的设计有利于高并发场景。当多个线程尝试使用CAS同时更新同一个变量时，只有其中一个线程能更新变量的值，而其它线程都失败，失败的线程并不会被挂起，而是被告知这次竞争中失败，并可以再次尝试。
|
||||
|
||||
最终，当下单更新到分布式数据库中之后，整个下单过程才算真正告一段落。
|
||||
|
||||
好了，经过了十个过程，下单终于成功了，你是否对这个过程了如指掌了呢？如果发现对哪些细节比较模糊，可以回去看一下相应的章节，相信会有更加深入的理解。
|
||||
|
||||
到此，我带着你用下单过程把网络协议的知识都复习了一遍。授人以鱼不如授人以渔。下一节，我将会带你来搭建一个网络实验环境，配合实验来说明理论。
|
||||
|
||||
欢迎你留言和我讨论。趣谈网络协议，我们下期见！
|
||||
214
极客时间专栏/趣谈网络协议/第四模块 网络协议知识串讲/第40讲 | 搭建一个网络实验环境：授人以鱼不如授人以渔.md
Normal file
214
极客时间专栏/趣谈网络协议/第四模块 网络协议知识串讲/第40讲 | 搭建一个网络实验环境：授人以鱼不如授人以渔.md
Normal file
@@ -0,0 +1,214 @@
|
||||
<audio id="audio" title="第40讲 | 搭建一个网络实验环境：授人以鱼不如授人以渔" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/68/6a/680a1b85738d87a7208e9e386d52286a.mp3"></audio>
|
||||
|
||||
因为这门课是基础课程，而且配合音频的形式发布，所以我多以理论为主来进行讲解。在专栏更新的过程中，不断有同学让我推荐一些网络方面的书籍，还有同学说能不能配合一些实验来说明理论。
|
||||
|
||||
的确，网络是一门实验性很强的学科，就像我在开篇词里面说的一样：**一看觉得懂，一问就打鼓，一用就糊涂。** 在写专栏的过程中，我自己也深深体会到了。这个时候，我常常会拿一个现实的环境，上手操作一下，抓个包看看，这样心里就会有定论。
|
||||
|
||||
## 《TCP/IP详解》实验环境搭建
|
||||
|
||||
对于网络方面的书籍，我当然首推Rechard Stevens的《[TCP/IP illustrated](https://book.douban.com/subject/1741925/)》（《TCP/IP详解》）。这本书把理论讲得深入浅出，还配有大量的上手实践和抓包，看到这些抓包，原来不理解的很多理论，一下子就能懂了。
|
||||
|
||||
这本书里有个拓扑图，书上的很多实验都是基于这个图的，但是这个拓扑图还是挺复杂的。我这里先不说，一会儿详细讲。
|
||||
|
||||
Rechard Stevens，因为工作中有这么一个环境，很方便做实验，最终才写出了这样一本书，而我们一般人学习网络，没有这个环境应该怎么办呢？
|
||||
|
||||
时代不同了，咱们现在有更加强大的工具了。例如，这里这么多的机器，我们可以用Docker来实现，多个网络可以用Open vSwitch来实现。你甚至不需要一台物理机，只要一台1核2G的虚拟机，就能将这个环境搭建起来。
|
||||
|
||||
搭建这个环境的时候，需要一些脚本。我把脚本都放在了[Github](https://github.com/popsuper1982/tcpipillustrated)里面，你可以自己取用。
|
||||
|
||||
### 1.创建一个Ubuntu虚拟机
|
||||
|
||||
在你的笔记本电脑上，用VirtualBox创建就行。1核2G，随便一台电脑都能搭建起来。
|
||||
|
||||
首先，我们先下载一个Ubuntu的镜像。我是从[Ubuntu官方网站](https://www.ubuntu.com/download/alternative-downloads)下载的。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/39/87/390a5bfb153fc95bdac0939194bc7387.jpg" alt="" />
|
||||
|
||||
然后，在VirtualBox里面安装Ubuntu。安装过程网上一大堆教程，你可以自己去看，我这里就不详细说了。
|
||||
|
||||
这里我需要说明的是网络的配置。
|
||||
|
||||
对于这个虚拟机，我们创建两个网卡，一个是Host-only，只有你的笔记本电脑上能够登录进去。这个网卡上的IP地址也只有在你的笔记本电脑上管用。这个网卡的配置比较稳定，用于在SSH上做操作。这样你的笔记本电脑就可以搬来搬去，在公司里安装一半，回家接着安装另一半都没问题。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/ab/ce/ab1974fc25fe902ff8eeda598eb9c3ce.jpg" alt="" />
|
||||
|
||||
这里有一个虚拟的网桥，这个网络可以在管理>主机网络管理里面进行配置。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/49/13/49eea1f000c9a538271d46c25c0a7b13.jpg" alt="" />
|
||||
|
||||
|
||||
|
||||
在这里可以虚拟网桥的的IP地址，同时启用一个DHCP服务器，为新创建的虚拟机配置IP地址。
|
||||
|
||||
另一个网卡配置为NAT网络，用于访问互联网。配置了NAT网络之后，只要你的笔记本电脑能上网，虚拟机就能上网。由于咱们在Ubuntu里面要安装一些东西，因而需要联网。
|
||||
|
||||
你可能会问了，这个配置复杂吗？一点儿都不复杂。咱们讲[虚拟机网络](https://time.geekbang.org/column/article/10742)的时候，讲过这个。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/2d/c4/2dd447992fbf4901f92a3dfdf8086bc4.jpg" alt="" />
|
||||
|
||||
安装完了Ubuntu之后，需要对Ubuntu里面的网卡进行配置。对于Ubuntu来讲，网卡的配置在/etc/network/interfaces这个文件里面。在我的环境里，NAT的网卡名称为enp0s3，Host-only的网卡的名称为enp0s8，都可以配置为自动配置。
|
||||
|
||||
```
|
||||
auto lo
|
||||
iface lo inet loopback
|
||||
|
||||
auto enp0s3
|
||||
iface enp0s3 inet dhcp
|
||||
|
||||
auto enp0s8
|
||||
iface enp0s8 inet dhcp
|
||||
|
||||
```
|
||||
|
||||
这样，重启之后，IP就配置好了。
|
||||
|
||||
### 2.安装Docker和Open vSwitch
|
||||
|
||||
接下来，在Ubuntu里面，以root用户，安装Docker和Open vSwitch。
|
||||
|
||||
你可以按照Docker的[官方安装](https://docs.docker.com/install/linux/docker-ce/ubuntu/)[文档](https://docs.docker.com/install/linux/docker-ce/ubuntu/)来做。我这里也贴一下我的安装过程。
|
||||
|
||||
```
|
||||
apt-get remove docker docker-engine docker.io
|
||||
apt-get -y update
|
||||
apt-get -y install apt-transport-https ca-certificates curl software-properties-common
|
||||
curl -fsSL https://download.docker.com/linux/ubuntu/gpg > gpg
|
||||
apt-key add gpg
|
||||
apt-key fingerprint 0EBFCD88
|
||||
add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"
|
||||
apt-get -y update
|
||||
apt-cache madison docker-ce
|
||||
apt-get -y install docker-ce=18.06.0~ce~3-0~ubuntu
|
||||
|
||||
```
|
||||
|
||||
之后，还需要安装Open vSwitch和Bridge。
|
||||
|
||||
```
|
||||
apt-get -y install openvswitch-common openvswitch-dbg openvswitch-switch python-openvswitch openvswitch-ipsec openvswitch-pki openvswitch-vtep
|
||||
|
||||
apt-get -y install bridge-utils
|
||||
|
||||
apt-get -y install arping
|
||||
|
||||
```
|
||||
|
||||
### 3.准备一个Docker的镜像
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/4c/1e/4c0e633ddc53f3feb98946518c0cf21e.jpg" alt="" />
|
||||
|
||||
每个节点都是一个Docker，对应要有一个Docker镜像。这个镜像我已经打好了，你可以直接使用。
|
||||
|
||||
```
|
||||
docker pull hub.c.163.com/liuchao110119163/ubuntu:tcpip
|
||||
|
||||
```
|
||||
|
||||
当然你也可以自己打这个镜像。Dockerfile就像这样：
|
||||
|
||||
```
|
||||
FROM hub.c.163.com/public/ubuntu:14.04
|
||||
RUN apt-get -y update && apt-get install -y iproute2 iputils-arping net-tools tcpdump curl telnet iputils-tracepath traceroute
|
||||
RUN mv /usr/sbin/tcpdump /usr/bin/tcpdump
|
||||
ENTRYPOINT /usr/sbin/sshd -D
|
||||
|
||||
```
|
||||
|
||||
### 4.启动整个环境
|
||||
|
||||
启动这个环境还是比较复杂的，我写成了一个脚本。在Git仓库里面，有一个文件 [setupenv.sh](http://setupenv.sh) ，可以执行这个脚本，里面有两个参数，一个参数是NAT网卡的名字，一个是镜像的名称。
|
||||
|
||||
```
|
||||
git clone https://github.com/popsuper1982/tcpipillustrated.git
|
||||
cd tcpipillustrated
|
||||
docker pull hub.c.163.com/liuchao110119163/ubuntu:tcpip
|
||||
chmod +x setupenv.sh
|
||||
./setupenv.sh enp0s3 hub.c.163.com/liuchao110119163/ubuntu:tcpip
|
||||
|
||||
```
|
||||
|
||||
这样，整个环境就搭建起来了，所有的容器之间都可以ping通，而且都可以上网。
|
||||
|
||||
不过，我写的这个脚本对一些人来说可能会有点儿复杂，我这里也解释一下。
|
||||
|
||||
首先**每一个节点，都启动一个容器**。使用–privileged=true方式，网络先不配置–net none。有两个二层网络，使用ovs-vsctl的add-br命令，创建两个网桥。
|
||||
|
||||
pipework是一个很好的命令行工具，可以将容器连接到两个二层网络上。
|
||||
|
||||
但是我们上面那个图里有两个比较特殊的网络，一个是从slip到bsdi的P2P网络，需要创建一个peer的两个网卡，然后两个Docker的网络namespace里面各塞进去一个。
|
||||
|
||||
有关操作Docker的网络namespace的方式，咱们在[容器网络](https://time.geekbang.org/column/article/11465)那一节讲过ip netns命令。
|
||||
|
||||
这里需要注意的是，P2P网络和下面的二层网络不是同一个网络。P2P网络的CIDR是140.252.13.64/27，而下面的二层网络的CIDR是140.252.13.32/27。如果按照/24，看起来是一个网络，但是/27就不是了。至于[CIDR的计算方法](https://time.geekbang.org/column/article/7772)，你可以回去复习一下。
|
||||
|
||||
另外需要**配置从sun到netb的点对点网络**，方法还是通过peer网卡和ip netns的方式。
|
||||
|
||||
这里有个特殊的地方，对于netb来讲，不是一个普通的路由器，因为netb两边是同一个二层网络，所以需要配置arp proxy。
|
||||
|
||||
为了所有的节点之间互通，要配置一下路由策略，这里需要通过ip route命令。
|
||||
|
||||
<li>
|
||||
对于slip来讲，bsdi左面13.66这个网口是网关。
|
||||
</li>
|
||||
<li>
|
||||
对于bsdi和svr4来讲，如果去外网，sun下面的网口13.33是网关。
|
||||
</li>
|
||||
<li>
|
||||
对于sun来讲，上面的网口1.29属于上面的二层网络了，它如果去外网，gateway下面的网口1.4就是外网网关。
|
||||
</li>
|
||||
<li>
|
||||
对于aix，solaris，gemini来讲，如果去外网，网关也是gateway下面的网口1.4。如果去下面的二层网口，网关是sun上面的网口1.29。
|
||||
</li>
|
||||
|
||||
配置完了这些，图中的所有的节点都能相互访问了，最后还要解决**如何访问外网**的问题。
|
||||
|
||||
我们还是需要创建一个peer网卡对。一个放在gateway里面，一个放在gateway外面。外面的网卡去外网的网关。
|
||||
|
||||
在虚拟机上面，还需要配置一个iptables的地址伪装规则MASQUERADE，其实就是一个SNAT。因为容器里面要访问外网，因为外网是不认的，所以源地址不能用容器的地址，需要SNAT成为虚拟机的地址出去，回来的时候再NAT回来。
|
||||
|
||||
配置这个环境还是挺复杂的，要用到咱们学到的很多知识。如果没有学习前面那些知识，直接就做这个实验，你肯定会很晕。但是只学理论也不行，要把理论都学过一遍，再做一遍实验，这才是一个不断迭代、更新知识库的过程。
|
||||
|
||||
有了这个环境，《TCP/IP详解》里面的所有实验都能做了，而且我打的这个Docker镜像里面，tcpdump等网络工具都安装了，你可以“为所欲为”了。
|
||||
|
||||
## Open vSwitch的实验
|
||||
|
||||
做了TCP/IP详解的实验之后，网络程序设计这部分，你就有了坚实的基础。但是涉及到数据中心内部的一些网络技术，什么VLAN、VXLAN、STP等偏运维方向的，学习还是会比较困难。好在我们有Open vSwitch，也可以做大量的实验。
|
||||
|
||||
Open vSwitch门槛比较高，里面的概念也非常多，可谓千头万绪。不过，通过我这么多年研究的经验，可以告诉你，这里面有一个很好的线索，那就是Open vSwitch会将自己对于网络的配置保存在一个本地库里面。这个库的表结构之间的关系就像这样：
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/43/d9/439a996b7f8de9477cb00876f13a28d9.jpg" alt="" />
|
||||
|
||||
这个库其实是一个JSON，如果把这个JSON打印出来，能够看到更加详细的特性。按照这些特性一一实验，可以逐渐把Open vSwitch各个特性都掌握。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/f0/a0/f00657f044e5afb07332f7236054b8a0.jpg" alt="" />
|
||||
|
||||
这里面最重要的概念就是**网桥**。一个网桥会有流表控制网络包的处理过程，会有控制器下发流表，一个网桥上会有多个端口，可以对端口进行流控，一个端口可以设置VLAN，一个端口可以包含多个网卡，可以做绑定，网卡可以设置成为GRE和VXLAN。
|
||||
|
||||
我写过一个Open vSwitch的实验教程，也放在了Github里面。这里面有这么几个比较重要的实验，你可以看一看。
|
||||
|
||||
<li>
|
||||
实验一：查看Open vSwitch的架构。我们在讲Open vSwitch的时候，提过Open vSwitch的架构，在这个实验中，我们可以查看Open vSwitch的各个模块以及启动的参数。
|
||||
</li>
|
||||
<li>
|
||||
实验五：配置使用OpenFlow Controller，体验一把作为小区物业在监控室里面管控整个小区道路的样子。
|
||||
</li>
|
||||
<li>
|
||||
实验八：测试Port的VLAN功能。看一下VLAN隔离究竟是什么样的。
|
||||
</li>
|
||||
<li>
|
||||
实验十：QoS功能。体验一把如果使用HTB进行网卡限流。
|
||||
</li>
|
||||
<li>
|
||||
实验十一：GRE和VXLAN隧道功能，看虚拟网络如何进行租户隔离。
|
||||
</li>
|
||||
<li>
|
||||
实验十五：对Flow Table的操作，体验流表对网络包随心所欲的处理。
|
||||
</li>
|
||||
|
||||
好了，关于整个环境的搭建我就讲到这里了。
|
||||
|
||||
其实到这里，对于网络世界的探索才刚刚开始，只有经过你自己动手和思考产生的内容，才是真正属于你的知识！打开你的电脑，上手去实验吧！
|
||||
|
||||
欢迎你留言和我讨论。趣谈网络协议，我们下期见！
|
||||
|
||||
|
||||
Reference in New Issue
Block a user