**计算机网络体系结构**

> 在计算机网络的基本概念中，分层次的体系结构是最基本的。计算机网络体系结构的抽象概念较多，在学习时要多思考。这些概念对后面的学习很有帮助。

##### 网络协议是什么？

> 在计算机网络要做到有条不紊地交换数据，就必须遵守一些事先约定好的规则，比如交换数据的格式、是否需要发送一个应答信息。这些规则被称为网络协议。

##### 为什么要对网络协议分层？

- 简化问题难度和复杂度。由于各层之间独立，我们可以分割大问题为小问题。
- 灵活性好。当其中一层的技术变化时，只要层间接口关系保持不变，其他层不受影响。
- 易于实现和维护。
- 促进标准化工作。分开后，每层功能可以相对简单地被描述。

网络协议分层的缺点： 功能可能出现在多个层里，产生了额外开销。

> 为了使不同体系结构的计算机网络都能互联，国际标准化组织 ISO 于 1977 年提出了一个试图使各种计算机在世界范围内互联成网的标准框架，即著名的开放系统互联基本参考模型 OSI/RM，简称为 OSI。

> OSI 的七层协议体系结构的概念清楚，理论也较完整，但它既复杂又不实用，TCP/IP 体系结构则不同，但它现在却得到了非常广泛的应用。TCP/IP 是一个四层体系结构，它包含应用层，运输层，网际层和网络接口层（用网际层这个名字是强调这一层是为了解决不同网络的互连问题），不过从实质上讲，TCP/IP 只有最上面的三层，因为最下面的网络接口层并没有什么具体内容，因此在学习计算机网络的原理时往往采用折中的办法，即综合 OSI 和 TCP/IP 的优点，采用一种只有五层协议的体系结构，这样既简洁又能将概念阐述清楚，有时为了方便，也可把最底下两层称为网络接口层。

四层协议，五层协议和七层协议的关系如下：

- TCP/IP 是一个四层的体系结构，主要包括：应用层、运输层、网际层和网络接口层。
- 五层协议的体系结构主要包括：应用层、运输层、网络层，数据链路层和物理层。
- OSI 七层协议模型主要包括是：应用层（Application）、表示层（Presentation）、会话层（Session）、运输层（Transport）、网络层（Network）、数据链路层（Data Link）、物理层（Physical）。

注：五层协议的体系结构只是为了介绍网络原理而设计的，实际应用还是 TCP/IP 四层体系结构。

#### TCP/IP 协议族

##### 应用层

> 应用层 ( application-layer ）的任务是通过应用进程间的交互来完成特定网络应用。应用层协议定义的是应用进程（进程：主机中正在运行的程序）间的通信和交互的规则。

对于不同的网络应用需要不同的应用层协议。在互联网中应用层协议很多，如域名系统 DNS，支持万维网应用的 HTTP 协议，支持电子邮件的 SMTP 协议等等。

##### 运输层

> 运输层 (transport layer) 的主要任务就是负责向两台主机进程之间的通信提供通用的数据传输服务。应用进程利用该服务传送应用层报文。

**运输层主要使用一下两种协议**

- 1.传输控制协议 - TCP：提供面向连接的，可靠的数据传输服务。
- 2.用户数据协议 - UDP：提供无连接的，尽最大努力的数据传输服务（不保证数据传输的可靠性）。

![image-20221103154231035](http://pic.nexopera.tech/636370e7803ec.png)

> 每一个应用层（TCP/IP 参考模型的最高层）协议一般都会使用到两个传输层协议之一：

**运行在 TCP 协议上的协议：**

- HTTP（Hypertext Transfer Protocol，超文本传输协议），主要用于普通浏览。
- HTTPS（HTTP over SSL，安全超文本传输协议）,HTTP 协议的安全版本。
- FTP（File Transfer Protocol，文件传输协议），用于文件传输。
- POP3（Post Office Protocol, version 3，邮局协议），收邮件用。
- SMTP（Simple Mail Transfer Protocol，简单邮件传输协议），用来发送电子邮件。
- TELNET（Teletype over the Network，网络电传），通过一个终端（terminal）登陆到网络。
- SSH（Secure Shell，用于替代安全性差的 TELNET），用于加密安全登陆用。

**运行在 UDP 协议上的协议：**

- BOOTP（Boot Protocol，启动协议），应用于无盘设备。
- NTP（Network Time Protocol，网络时间协议），用于网络同步。
- DHCP（Dynamic Host Configuration Protocol，动态主机配置协议），动态配置 IP 地址。

运行在 TCP 和 UDP 协议上：

- DNS（Domain Name Service，域名服务），用于完成地址查找，邮件转发等工作。

##### 网络层

> 网络层的任务就是选择合适的网间路由和交换结点，确保计算机通信的数据及时传送。在发送数据时，网络层把运输层产生的报文段或用户数据报封装成分组和包进行传送。在 TCP/IP 体系结构中，由于网络层使用 IP 协议，因此分组也叫 IP 数据报 ，简称数据报。

> 互联网是由大量的异构（heterogeneous）网络通过路由器（router）相互连接起来的。互联网使用的网络层协议是无连接的网际协议（Intert Prococol）和许多路由选择协议，因此互联网的网络层也叫做网际层或 IP 层。

##### 数据链路层

> 数据链路层 (data link layer) 通常简称为链路层。两台主机之间的数据传输，总是在一段一段的链路上传送的，这就需要使用专门的链路层的协议。

> 在两个相邻节点之间传送数据时，数据链路层将网络层交下来的 IP 数据报组装成帧，在两个相邻节点间的链路上传送帧。每一帧包括数据和必要的控制信息（如同步信息，地址信息，差错控制等）。

在接收数据时，控制信息使接收端能够知道一个帧从哪个比特开始和到哪个比特结束。

**一般的 web 应用的通信传输流是这样的：**

![image-20221103154309259](http://pic.nexopera.tech/6363710de5913.png)

> 发送端在层与层之间传输数据时，每经过一层时会被打上一个该层所属的首部信息。反之，接收端在层与层之间传输数据时，每经过一层时会把对应的首部信息去除。

##### 物理层

> 在物理层上所传送的数据单位是比特。物理层 (physical layer) 的作用是实现相邻计算机节点之间比特流的透明传送，尽可能屏蔽掉具体传输介质和物理设备的差异。使其上面的数据链路层不必考虑网络的具体传输介质是什么。“透明传送比特流”表示经实际电路传送后的比特流没有发生变化，对传送的比特流来说，这个电路好像是看不见的。

##### TCP/IP 协议族

> 在互联网使用的各种协议中最重要和最著名的就是 TCP/IP 两个协议。现在人们经常提到的 TCP/IP 并不一定是单指 TCP 和 IP 这两个具体的协议，而往往是表示互联网所使用的整个 TCP/IP 协议族。

![image-20221103154338796](http://pic.nexopera.tech/6363712b6083a.png)

> 互联网协议套件（英语：Internet Protocol Suite，缩写 IPS）是一个网络通讯模型，以及一整个网络传输协议家族，为网际网络的基础通讯架构。它常被通称为 TCP/IP 协议族（英语：TCP/IP Protocol Suite，或 TCP/IP Protocols），简称 TCP/IP。因为该协定家族的两个核心协定：TCP（传输控制协议）和 IP（网际协议），为该家族中最早通过的标准。

**划重点：**

TCP（传输控制协议）和 IP（网际协议） 是最先定义的两个核心协议，所以才统称为 TCP/IP 协议族

##### TCP 的三次握手四次挥手

> TCP 是一种面向连接的、可靠的、基于字节流的传输层通信协议，在发送数据前，通信双方必须在彼此间建立一条连接。所谓的 “连接”，其实是客户端和服务端保存的一份关于对方的信息，如 ip 地址、端口号等。

TCP 可以看成是一种字节流，它会处理 IP 层或以下的层的丢包、重复以及错误问题。在连接的建立过程中，双方需要交换一些连接的参数。这些参数可以放在 TCP 头部。

> 一个 TCP 连接由一个 4 元组构成，分别是两个 IP 地址和两个端口号。一个 TCP 连接通常分为三个阶段：连接、数据传输、退出（关闭）。通过三次握手建立一个链接，通过四次挥手来关闭一个连接。

当一个连接被建立或被终止时，交换的报文段只包含 TCP 头部，而没有数据。

##### TCP 报文的头部结构

在了解 TCP 连接之前先来了解一下 TCP 报文的头部结构。

![image-20221103154345461](http://pic.nexopera.tech/6363713303d7d.png)

上图中有几个字段需要重点介绍下：

- 1.序号：seq 序号，占 32 位，用来标识从 TCP 源端向目的端发送的字节流，发起方发送数据时对此进行标记。
- 2.确认序号：ack 序号，占 32 位，只有 ACK 标志位为 1 时，确认序号字段才有效，ack=seq+1。
- 3.标志位：共 6 个，即 URG、ACK、PSH、RST、SYN、FIN 等，具体含义如下：

------

- ACK：确认序号有效。
- FIN：释放一个连接。
- PSH：接收方应该尽快将这个报文交给应用层。
- RST：重置连接。
- SYN：发起一个新连接。
- URG：紧急指针（urgent pointer）有效。

需要注意的是：

- 不要将确认序号 ack 与标志位中的 ACK 搞混了。
- 确认方 ack = 发起方 seq+1，两端配对。

##### 三次握手

三次握手的本质是确认通信双方收发数据的能力

> 首先，我让信使运输一份信件给对方，对方收到了，那么他就知道了我的发件能力和他的收件能力是可以的。

> 于是他给我回信，我若收到了，我便知我的发件能力和他的收件能力是可以的，并且他的发件能力和我的收件能力是可以。

> 然而此时他还不知道他的发件能力和我的收件能力到底可不可以，于是我最后回馈一次，他若收到了，他便清楚了他的发件能力和我的收件能力是可以的。

这，就是三次握手，这样说，你理解了吗？

![image-20221103154352077](http://pic.nexopera.tech/63637138a88c9.png)

- 第一次握手：客户端要向服务端发起连接请求，首先客户端随机生成一个起始序列号 ISN(比如是 100)，那客户端向服务端发送的报文段包含 SYN 标志位 (也就是 SYN=1)，序列号 seq=100。
- 第二次握手：服务端收到客户端发过来的报文后，发现 SYN=1，知道这是一个连接请求，于是将客户端的起始序列号 100 存起来，并且随机生成一个服务端的起始序列号 (比如是 300)。然后给客户端回复一段报文，回复报文包含 SYN 和 ACK 标志 (也就是 SYN=1,ACK=1)、序列号 seq=300、确认号 ack=101(客户端发过来的序列号 + 1)。
- 第三次握手：客户端收到服务端的回复后发现 ACK=1 并且 ack=101, 于是知道服务端已经收到了序列号为 100 的那段报文；同时发现 SYN=1，知道了服务端同意了这次连接，于是就将服务端的序列号 300 给存下来。然后客户端再回复一段报文给服务端，报文包含 ACK 标志位 (ACK=1)、ack=301(服务端序列号 + 1)、seq=101(第一次握手时发送报文是占据一个序列号的，所以这次 seq 就从 101 开始，需要注意的是不携带数据的 ACK 报文是不占据序列号的，所以后面第一次正式发送数据时 seq 还是 101)。当服务端收到报文后发现 ACK=1 并且 ack=301，就知道客户端收到序列号为 300 的报文了，就这样客户端和服务端通过 TCP 建立了连接。

##### 四次挥手

四次挥手的目的是关闭一个连接

![image-20221103154359033](http://pic.nexopera.tech/6363713fb5638.png)

比如客户端初始化的序列号 ISA=100，服务端初始化的序列号 ISA=300。TCP 连接成功后客户端总共发送了 1000 个字节的数据，服务端在客户端发 FIN 报文前总共回复了 2000 个字节的数据。

- 第一次挥手：当客户端的数据都传输完成后，客户端向服务端发出连接释放报文 (当然数据没发完时也可以发送连接释放报文并停止发送数据)，释放连接报文包含 FIN 标志位 (FIN=1)、序列号 seq=1101(100+1+1000，其中的 1 是建立连接时占的一个序列号)。需要注意的是客户端发出 FIN 报文段后只是不能发数据了，但是还可以正常收数据；另外 FIN 报文段即使不携带数据也要占据一个序列号。
- 第二次挥手：服务端收到客户端发的 FIN 报文后给客户端回复确认报文，确认报文包含 ACK 标志位 (ACK=1)、确认号 ack=1102(客户端 FIN 报文序列号 1101+1)、序列号 seq=2300(300+2000)。此时服务端处于关闭等待状态，而不是立马给客户端发 FIN 报文，这个状态还要持续一段时间，因为服务端可能还有数据没发完。
- 第三次挥手：服务端将最后数据 (比如 50 个字节) 发送完毕后就向客户端发出连接释放报文，报文包含 FIN 和 ACK 标志位(FIN=1,ACK=1)、确认号和第二次挥手一样 ack=1102、序列号 seq=2350(2300+50)。
- 第四次挥手：客户端收到服务端发的 FIN 报文后，向服务端发出确认报文，确认报文包含 ACK 标志位 (ACK=1)、确认号 ack=2351、序列号 seq=1102。注意客户端发出确认报文后不是立马释放 TCP 连接，而是要经过 2MSL(最长报文段寿命的 2 倍时长) 后才释放 TCP 连接。而服务端一旦收到客户端发出的确认报文就会立马释放 TCP 连接，所以服务端结束 TCP 连接的时间要比客户端早一些。

#### 常见面试题

##### 为什么 TCP 连接的时候是 3 次？2 次不可以吗？

> 因为需要考虑连接时丢包的问题，如果只握手 2 次，第二次握手时如果服务端发给客户端的确认报文段丢失，此时服务端已经准备好了收发数 (可以理解服务端已经连接成功) 据，而客户端一直没收到服务端的确认报文，所以客户端就不知道服务端是否已经准备好了(可以理解为客户端未连接成功)，这种情况下客户端不会给服务端发数据，也会忽略服务端发过来的数据。

> 如果是三次握手，即便发生丢包也不会有问题，比如如果第三次握手客户端发的确认 ack 报文丢失，服务端在一段时间内没有收到确认 ack 报文的话就会重新进行第二次握手，也就是服务端会重发 SYN 报文段，客户端收到重发的报文段后会再次给服务端发送确认 ack 报文。

##### 为什么 TCP 连接的时候是 3 次，关闭的时候却是 4 次？

> 因为只有在客户端和服务端都没有数据要发送的时候才能断开 TCP。而客户端发出 FIN 报文时只能保证客户端没有数据发了，服务端还有没有数据发客户端是不知道的。而服务端收到客户端的 FIN 报文后只能先回复客户端一个确认报文来告诉客户端我服务端已经收到你的 FIN 报文了，但我服务端还有一些数据没发完，等这些数据发完了服务端才能给客户端发 FIN 报文 (所以不能一次性将确认报文和 FIN 报文发给客户端，就是这里多出来了一次)。

##### 为什么客户端发出第四次挥手的确认报文后要等 2MSL 的时间才能释放 TCP 连接？

> 这里同样是要考虑丢包的问题，如果第四次挥手的报文丢失，服务端没收到确认 ack 报文就会重发第三次挥手的报文，这样报文一去一回最长时间就是 2MSL，所以需要等这么长时间来确认服务端确实已经收到了。

##### 如果已经建立了连接，但是客户端突然出现故障了怎么办？

> TCP 设有一个保活计时器，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为 2 小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔 75 秒钟发送一次。若一连发送 10 个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

TCP三次握手四次挥手

话说，**UDP比TCP快吗？**

相信就算不是八股文老手，也会下意识的脱口而出："**是**"。

这要追问为什么，估计大家也能说出个大概。

![image-20221107093800917](http://pic.nexopera.tech/63686179803ee.png)

但这也让人好奇，**用UDP就一定比用TCP快吗？什么情况下用UDP会比用TCP慢？**

我们今天就来聊下这个话题。



### 使用socket进行数据传输

作为一个程序员，假设我们需要在A电脑的进程发一段数据到B电脑的进程，我们一般会在代码里使用socket进行编程。

socket就像是一个**电话或者邮箱**（邮政的信箱）。当你想要发送消息的时候，拨通电话或者将信息塞到邮箱里，socket内核会自动完成将数据传给对方的这个过程。

基于socket我们可以选择使用TCP或UDP协议进行通信。

对于TCP这样的可靠性协议，每次消息发出后都能明确知道对方收没收到，就**像打电话一样**，只要"喂喂"两下就能知道对方有没有在听。

而UDP就像是**给邮政的信箱寄信一样**，你寄出去的信，根本就不知道对方有没有正常收到，丢了也是有可能的。

> 这让我想起了大概17年前，当时还没有现在这么发达的网购，想买一本《掌机迷》杂志，还得往信封里塞钱，然后一等就是一个月，好几次都怀疑信是不是丢了。我至今印象深刻，因为那是我和我哥攒了好久的钱。。。



回到socket编程的话题上。

创建socket的方式就像下面这样。

```
fd = socket(AF_INET, 具体协议,0);
```

注意上面的"**具体协议**"，如果传入的是`SOCK_STREAM`，是指使用**字节流**传输数据，说白了就是**TCP协议**。

![image-20221107093813106](http://pic.nexopera.tech/6368618594ca8.png)TCP是什么

如果传入的是`SOCK_DGRAM`，是指使用**数据报**传输数据，也就是**UDP协议**。

![image-20221107093821739](http://pic.nexopera.tech/6368618e51dfc.png)UDP是什么

返回的`fd`是指socket句柄，可以理解为socket的**身份证号**。通过这个`fd`你可以在内核中找到**唯一**的socket结构。

如果想要通过这个socket发消息，只需要操作这个fd就行了，比如执行 `send(fd, msg, ...)`，内核就会通过这个fd句柄找到socket然后进行发数据的操作。

**如果一切顺利**，此时对方执行接收消息的操作，也就是 `recv(fd, msg, ...)`，就能拿到你发的消息。

![](http://pic.nexopera.tech/63686232183cd.gif)udp发送接收过程

### 对于异常情况的处理

**但如果不顺利呢？**

比如消息发到一半，丢包了呢?

> 丢包的原因有很多，之前写过的《用了TCP协议，就一定不会丢包吗？》有详细聊到过，这里就不再展开。

那UDP和TCP的态度就不太一样了。



UDP表示，"哦，是吗？然后呢？关我x事"

TCP态度就截然相反了，"啊？那可不行，是不是我发太快了呢？是不是链路太堵被别人影响到了呢？不过你放心，我肯定给你补发"

TCP老实人石锤了。我们来看下这个老实人在背后都默默做了哪些事情。

#### 重传机制

对于TCP，它会给发出的消息打上一个**编号（sequence）**，接收方收到后回一个**确认(ack)**。发送方可以通过`ack`的数值知道接收方收到了哪些`sequence`的包。

如果长时间等不到对方的确认，TCP就会重新发一次消息，这就是所谓的**重传机制**。

![image-20221107093840714](http://pic.nexopera.tech/636861a139551.png)TCP重传



#### 流量控制机制

但重传这件事本身对性能影响是比较严重的，所以是**下下策**。

于是TCP就需要思考有没有办法可以尽量**避免重传**。

因为数据发送方和接收方处理数据能力可能不同，因此如果可以根据双方的能力去调整发送的数据量就好了，于是就有了**发送和接收窗口**，基本上从名字就能看出它的作用，比如**接收窗口的大小**就是指，接收方当前**能接收的数据量大小**，**发送窗口的大小**就指发送方当前能发的数据量大小。TCP根据窗口的大小去控制自己发送的数据量，这样就能大大减少丢包的概率。

![image-20221107093850404](http://pic.nexopera.tech/636861aaf2745.png)流量控制机制



#### 滑动窗口机制

接收方的接收到数据之后，会不断处理，**处理能力也不是一成不变的**，有时候处理的快些，那就可以收多点数据，处理的慢点那就希望对方能少发点数据。毕竟发多了就有可能处理不过来导致丢包，丢包会导致重传，这可是下下策。因此我们需要动态的去调节这个接收窗口的大小，于是就有了**滑动窗口机制**。

看到这里大家可能就有点迷了，**流量控制和滑动窗口机制貌似很像，它们之间是啥关系？**我总结一下。其实现在TCP是**通过滑动窗口机制来实现流量控制机制的**。

![image-20221107093858073](http://pic.nexopera.tech/636861b2aa342.png)滑动窗口机制



#### 拥塞控制机制

但这还不够，有时候发生丢包，**并不是因为发送方和接收方的处理能力问题导致的**。而是跟**网络环境**有关，大家可以将网络想象为一条公路。马路上可能堵满了别人家的车，只留下一辆车的空间。那就算你家有5辆车，目的地也正好有5个停车位，你也没办法同时全部一起上路。于是TCP希望能感知到外部的网络环境，根据网络环境及时调整自己的发包数量，比如马路只够两辆车跑，那我就只发两辆车。但外部环境这么复杂，TCP是怎么感知到的呢？

TCP会先慢慢试探的发数据，不断加码数据量，越发越多，先发一个，再发2个，4个…。直到出现丢包，这样TCP就知道现在当前网络大概吃得消几个包了，这既是所谓的**拥塞控制机制**。

不少人会疑惑流量控制和拥塞控制的关系。我这里小小的总结下。**流量控制**针对的是**单个连接**数据处理能力的控制，**拥塞控制**针对的是**整个网络环境**数据处理能力的控制。

![image-20221107093906380](http://pic.nexopera.tech/636861bad086f.png)1663598420295



#### 分段机制

但上面提到的都是怎么**降低**重传的概率，似乎重传这个事情就是无法避免的，**那如果确实发生了，有没有办法降低它带来的影响呢？**

有。当我们需要发送一个超大的数据包时，如果这个数据包丢了，那就得重传同样大的数据包。但如果我能将其分成一小段一小段，那就算真丢了，那我也就只需要重传那一小段就好了，大大减小了重传的压力，这就是TCP的**分段机制**。

而这个所谓的一小段的长度，在传输层叫**MSS**（**Maximum Segment Size**），数据包长度大于MSS则会分成N个小于等于MSS的包。

![](http://pic.nexopera.tech/636862330553c.gif)MSS分包

而在网络层，如果数据包还大于**MTU（Maximum Transmit Unit）**，那还会继续分包。

![](http://pic.nexopera.tech/636862344d467.gif)MTU分包

一般情况下，`MSS=MTU-40Byte`，所以**TCP分段后，到了IP层大概率就不会再分片了**。

![image-20221107093942865](http://pic.nexopera.tech/636861df4af04.png)MSS和MTU的区别



#### 乱序重排机制

既然数据包会被分段，链路又这么复杂还会丢包，那数据包乱序也就显得不奇怪了。比如发数据包1,2,3。1号数据包走了其他网络路径，2和3数据包先到，1数据包后到，于是数据包顺序就成了2,3,1。这一点TCP也考虑到了，依靠数据包的`sequence`，接收方就能知道数据包的先后顺序。

后发的数据包先到是吧，那就先放到专门的**乱序队列**中，等数据都到齐后，重新整理好乱序队列的数据包顺序后再给到用户，这就是**乱序重排机制**。

![image-20221107093950419](http://pic.nexopera.tech/636861e6eb7ed.png)乱序队列等待数据包的到来



#### 连接机制

前面提到，UDP是无连接的，而TCP是面向连接的。

这里提到的**连接**到底是啥？

TCP通过上面提到的各种机制实现了数据的可靠性。这些机制背后是通过一个个数据结构来实现的逻辑。而为了实现这套逻辑，操作系统内核需要在两端代码里维护一套复杂的状态机（三次握手，四次挥手，RST，closing等异常处理机制），**这套状态机其实就是所谓的"连接"**。这其实就是TCP的**连接机制**，而UDP用不上这套状态机，因此它是"无连接"的。



网络环境链路很长，还复杂，数据丢包是很常见的。

我们平常用TCP做各种数据传输，完全对这些事情无感知。

**哪有什么岁月静好，是TCP替你负重前行。**

这就是TCP三大特性"面向连接、可靠的、基于字节流"中"**可靠**"的含义。

不信你改用UDP试试，丢包那就是真丢了，丢到你怀疑人生。



### 用UDP就一定比用TCP快吗？

这时候UDP就不服了："**正因为没有这些复杂的TCP可靠性机制，所以我很快啊**"

嗯，这也是大部分人认为UDP比TCP快的原因。

**实际上大部分情况下也确实是这样的。这话没毛病。**



那问题就来了。

**有没有用了UDP但却比TCP慢的情况呢？**

其实也有。

在回答这个问题前，我需要先说下**UDP的用途**。

实际上，**大部分**人也不会尝试**直接拿裸udp**放到生产环境中去做项目。

那UDP的价值在哪？

在我看来，UDP的存在，本质是内核提供的一个**最小网络传输功能**。

很多时候，大家虽然号称自己用了UDP，但实际上都很**忌惮**它的丢包问题，所以大部分情况下都会在UDP的基础上做各种不同程度的**应用层**可靠性保证。比如王者农药用的`KCP`，以及最近很火的`QUIC（HTTP3.0）`，其实都**在UDP的基础上做了重传逻辑**，实现了一套**类似**TCP那样的可靠性机制。

教科书上最爱提UDP适合用于**音视频传输**，因为这些场景允许丢包。但其实也不是什么包都能丢的，比如重要的关键帧啥的，该重传还得重传。除此之外，还有一些**乱序处理机制**。举个例子吧。

打音视频电话的时候，你可能遇到过丢失中间某部分信息的情况，但应该从来没遇到过乱序的情况吧。

比如对方打网络电话给你，说了："**我好想给小白来个点赞在看！**"

这时候网络信号不好，你可能会听到"我….点赞在看"。

但却从来没遇到过"在看小白好想赞"这样的**乱序**场景吧？

所以说，**虽然选择了使用UDP，但一般还是会在应用层上做一些重传机制的**。

于是问题就来了，**如果现在我需要传一个特别大的数据包**。

在`TCP`里，它内部会根据`MSS`的大小**分段**，这时候进入到IP层之后，每个包大小都不会超过`MTU`，因此IP层一般不会再进行分片。这时候发生丢包了，只需要**重传每个MSS分段**就够了。

![](http://pic.nexopera.tech/636862359e974.gif)TCP分段

但对于`UDP`，其本身并不会分段，如果数据过大，到了IP层，就会进行分片。此时发生丢包的话，再次重传，就会**重传整个大数据包**。

![](http://pic.nexopera.tech/63686236688e9.gif)UDP不分段

对于上面这种情况，**使用UDP就比TCP要慢**。

当然，解决起来也不复杂。这里的关键点在于是否实现了数据分段机制，**使用UDP的应用层如果也实现了分段机制的话，那就不会出现上述的问题了**。



### 总结

- TCP为了实现可靠性，引入了重传机制、流量控制、滑动窗口、拥塞控制、分段以及乱序重排机制。而UDP则没有实现，因此一般来说TCP比UDP慢。
- TCP是面向连接的协议，而UDP是无连接的协议。这里的"**连接**"其实是，操作系统内核在两端代码里维护的一套复杂状态机。
- 大部分项目，会在基于UDP的基础上，模仿TCP，实现不同程度的可靠性机制。比如王者农药用的KCP其实就在基于UDP在应用层里实现了一套**重传**机制。
- 对于UDP+重传的场景，如果要传**超大数据包**，并且没有实现**分段机制**的话，那数据就会在IP层分片，一旦丢包，那就需要重传整个超大数据包。而TCP则不需要考虑这个，内部会自动分段，丢包重传分段就行了。这种场景下，其实TCP更快。

UDP就一定比TCP快吗？

## CDN简介

CDN的全称是Content Delivery Network，即内容分发网络。CDN是构建在现有网络基础之上的智能虚拟网络，依靠部署在各地的边缘服务器，通过中心平台的负载均衡、内容分发、调度等功能模块，使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度和命中率。CDN的关键技术主要有内容存储和分发技术。

**简而言之,就是将数据部署在各地的服务器中,通过负载均衡技术,让用户就近获取服务器中的数据。**

## CDN原理

CDN的基本原理是广泛采用各种缓存服务器，将这些缓存服务器分布到用户访问相对集中的地区或网络中，在用户访问网站时，利用**全局负载技术**将用户的访问指向距离最近的工作正常的缓存服务器上，由**缓存服务器**直接响应用户请求。

> **全局负载均衡**主要用于在多个区域拥有自己服务器的站点，为了使全球用户只以一个IP地址或域名就能访问到离自己最近的服务器，从而获得最快的访问速度。

CDN的**基本思路是尽可能避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节，使内容传输的更快、更稳定**。通过在网络各处放置节点服务器所构成的在现有的互联网基础之上的一层智能虚拟网络，CDN系统能够实时地根据网络流量和各节点的连接、负载状况以及到用户的距离和响应时间等综合信息将用户的请求重新导向离用户最近的服务节点上。其目的是使用户可就近取得所需内容，解决 Internet网络拥挤的状况，提高用户访问网站的响应速度。

![img](http://pic.nexopera.tech/635b6ee4c29dc.png)

## CDN功能

归纳起来，CDN具有以下主要功能：

1. 节省骨干网带宽，减少带宽需求量；
2. 提供服务器端加速，解决由于用户访问量大造成的服务器过载问题；
3. 服务商能使用Web Cache技术在本地缓存用户访问过的Web页面和对象，实现相同对象的访问无须占用主干的出口带宽，并提高用户访问因特网页面的相应时间的需求；
4. 能克服网站分布不均的问题，并且能降低网站自身建设和维护成本；
5. 降低“通信风暴”的影响，提高网络访问的稳定性。

## CDN服务模式

简单地说，内容分发网络（CDN）是一个经策略性部署的整体系统，包括分布式存储、负载均衡、网络请求的重定向和内容管理4个要件，而内容管理和全局的网络流量管理（Traffic Management）是CDN的核心所在。通过用户就近性和服务器负载的判断，CDN确保内容以一种极为高效的方式为用户的请求提供服务。总的来说，内容服务基于缓存服务器，也称作代理缓存（Surrogate），它位于网络的边缘，距用户仅有"一跳"（Single Hop）之遥。

同时，代理缓存是内容提供商源服务器（通常位于CDN服务提供商的数据中心）的一个透明镜像。这样的架构使得CDN服务提供商能够代表他们客户，即内容供应商，向最终用户提供尽可能好的体验，而这些用户是不能容忍请求响应时间有任何延迟的。

## 全局负载均衡

全局负载均衡（Global Server Load Balance, GSLB）,全局负载均衡是指对分别放置在不同的地理位置的服务器群间作负载均衡。服务器负载均衡是指对本地的服务器群做负载均衡。主要用于在多个区域拥有自己服务器的站点，为了使全球用户只以一个IP地址或域名就能访问到离自己最近的服务器，从而获得最快的访问速度。

### 服务器群选择

对于全局负载均衡而言，其核心就是服务器群的选择。对于某个特定的客户，应该将其定向到哪一个服务群？应该使用什么标准来进行这种选择？一般情况下，主要考虑两个因素：临近程度和负载大小。

临近机制主要考察服务器群与用户之间的物理距离。选择地理位置最接近用户的服务器集群，可以减少服务响应到达用户所经过的中转次数，从而降低中转节点对服务质量的影响。常见的有两种方式，一种是静态配置，例如根据静态的IP地址配置表进行IP地址到服务器群的映射。另一种方式是动态的检测，例如实时地探测到目标IP的距离（可以采用到达目标IP经过的跳数作为度量单位），然后比较探测结果进行选择。

负载机制比较各个服务器群的负载，确定由哪一个服务器群来响应请求。在全局负载均衡中，考察的是服务器群的负载，而不是单个服务器的负载，因此，需要更多地考虑普遍的问题，比如，需要考虑站点的最大连接数、站点的平均响应时间、服务质量等。

常见的GSLB实现方式有三种： DNS轮询、HTTP重定向、IP欺骗（又称三角传输）。这三种实现方式都是在用户通过域名来访问目标服务器时，由GSLB设备进行智能决策，将用户引导到一个最佳的服务IP。

### 基于DNS的GSLB

用户访问某个网站时，需要首先通过域名解析服务（DNS）获得网站的IP。域名解析通常不是一次性完成的，常常需要查询若干不同的域名服务器才能找到对应的IP。如下图所示，用户首先在本地配置一个本地DNS服务器地址，本地DNS服务器收到DNS请求后若不能解析，会将请求转发给更高一级的DNS服务器直到找到域名对应的IP或确定域名不存在。

![2002319-20210202184349930-817718940](http://pic.nexopera.tech/635b6ee4a5824.png)

对于加入了GSLB的情况，一个GSLB设备（可能是一个4层交换机）会最终代替DNS服务器完成域名解析。下图展示两种流程的不同。

![img](http://pic.nexopera.tech/635b6ee4992b8.png)

### 基于DNS的GSLB优缺点

**优点**是：实现简单、实施容易、成本低。

**缺点**是：当GSLB设备采用“用户就近访问”的原则作为选择最优服务器的策略时，会存在判断不准的现象。原因是在这种策略下，GSLB设备是根据用户IP地址和内容服务器IP地址比较来判断其就近性的，但由于DNS响应是通过本地DNS服务器到达用户的，GSLB设备实际上只能得到用户的本地DNS服务器地址，若用户指定的DNS服务器IP不能正确代表用户的实际位置，就会出现判断不准的现象。

### 基于HTTP重定向的GSLB

为了解决基于DNS实现方式判断不准的问题，又出现了基于HTTP重定向的GSLB。这种方案中GSLB使用HTTP重定向技术，将用户访问重定向到最合适的服务器上。

![img](http://pic.nexopera.tech/635b6ee4b07c4.png)

使用基于HTTP重定向方案，首先在DNS中将GSLB设备的IP地址登记为域名的A记录（既域名对应的IP）。如上图所示，用户首先通过DNS得到GSLB设备的IP地址，此时用户以为这就是站点服务器的IP，并向其发送HTTP请求。GSLB设备收到HTTP请求后使用一定策略选择一个最合适的服务器，然后GSLB设备向用户发送一个HTTP重定向指令（HTTP302），并附上选出的服务器的IP地址。最后，用户根据重定向IP访问站点的服务器。

### 基于HTTP重定向的GSLB优缺点

优点：由于直接向用户发送HTTP重定向指令，可以得到用户的真实IP，从而解决了判断不准确的问题。

缺点是只能为HTTP访问重定向。

### 基于IP欺骗的GSLB

HTTP重定向方案解决了判断不准确的问题，但只能针对HTTP协议应用使用。对于HTTP协议以外的访问，就需要使用基于IP欺骗（又称三角传输）的GSLB。

![img](http://pic.nexopera.tech/635b6ee4bc3bc.png)

基于IP欺骗的方案同样需要首先将GSLB设备的IP地址在DNS中登记为域名的A记录，这样用户对该域名的请求包都会先发送到GSLB设备。如上图所示，GSLB设备首次收到服务请求包后，会选择一个最合适的服务器，并将服务请求包发送到该服务器。服务器在向用户发送响应包时，将其源IP地址字段改为GSLB设备的IP，发送给用户。

这样，整个过程对用户来说，感觉到的只是GSLB设备在为其提供服务，并不知道其中经历这样一个三角传输的过程。而且这种方案可以对所有类型的访问如HTTP、FTP等进行重定向，但其速度和效率相对比前两种方案要差一点，因为用户所有的访问请求都通过三个点才能响应，经历了更多的路径和处理，所以其主要作为HTTP重定向方案的补充方案在同一GSLB设备中实现。

## 服务器群选择策略

上文中介绍的三种方案，解决了如何将用户引导到指定服务器群的问题，而在此之前首先需要使用某种方式选出最适合用户的服务器群，也就是GSLB在选择服务器群时所采用的策略。接下来介绍一些常用的GSLB策略。

1)地理区域或用户自定义区域：将若干条IP地址前缀划分一个区域为。根据用户本地DNS的IP地址，将特定IP范围的用户优先分配到某个通过健康检查的站点。

2)IP地址权重：可以为DNS应答中的每个IP地址分配权重，权重决定与其他候选IP相比分配到该IP的流量比例。

3)往返时间（Round Trip Time, RTT）：RTT策略是基于区域之外最常用的策略。有两种模式的RTT测量：Active RTT测量与Passive RTT测量。在实际部署中，由于网络限制和性能原因，Active RTT往往无法使用，Passive RTT更实用一些。

------

a) Active RTT 测量：

当GSLB Controller收到来自LDNS的DNS请求时，GSLB Controller会通知所有站点负载均衡设备对该LDNS进行RTT测量。根据采集到的RTT值，GSLB Controller会选择RTT值最小的站点的VIP返回给LDNS。

由于Active RTT采用DNS Query或ICMP进行RTT测量，在有些网络中可能会被安全策略所过滤而无法工作。

Active RTT测量会产生额外的DNS Query或ICMP流量，在有些网络中用户不希望有太多类似的非用户流量。

b) Passive RTT测量：

Passive RTT测量指从内容站点收到一个用户发出连接请求(发送TCN SYN)到接收到用户的确认(收到TCP ACK)所经历的时间。而不是简单的PING的响应时间，可以更精确的衡量访问最快的站点。

Passive RTT测量不会主动去进行测量，也不会产生额外的数据流量，而是在用户向返回的VIP建立连接时进行采集。

Passive RTT的测量值真正反映了用户的上网感受，在运营商网络中也不会产生额外流量。也不会受到其他运营商或网络的安全策略的影响。

全局负载均衡与CDN内容分发

**实验拓扑**

![图片](http://pic.nexopera.tech/62fdcc8532560.png)



**静态MAC地址简介**

MAC地址表项是交换机通过报文的源MAC地址学习过程而自动生成的，而通过用户手动配置也可以生成静态的MAC地址表项。



手动配置静态MAC，一般是为了防止假冒身份的非法用户骗取数据，由网络管理员手动在MAC地址表中添加合法用户的MAC地址表项。



手动配置静态MAC地址表项的数量比较大时，不便于网络管理员维护，此时可以使用端口安全功能实现MAC地址和接口的动态绑定。



**配置注意事项**

本举例适用于S系列交换机所有产品的所有版本。

**组网需求**

如图1所示，服务器通过GE1/0/2接口连接交换机。为避免交换机在转发目的地址为服务器地址的报文时进行广播，要求在交换机上设置服务器的静态MAC地址表项，使交换机始终通过GE1/0/2接口单播发送去往服务器的报文。为了保证PC用户和服务器的安全通信，同时把PC用户的MAC地址和接口GE1/0/1静态绑定。



**配置思路**

采用如下思路配置静态MAC：

1. 在交换机上创建VLAN，并将接口加入VLAN，实现二层转发功能。

2. 在交换机上配置服务器的静态MAC地址表项。

3. 在交换机上配置PC的静态MAC地址表项。



**操作步骤**

1. 在Switch上创建VLAN 2，并把接口GE1/0/1和GE1/0/2加入VLAN 2

   ```
   <HUAWEI> system-view
   [HUAWEI] sysname Switch
   [Switch] vlan batch 2   //创建VLAN 2
   [Switch] interface gigabitethernet 1/0/1
   [Switch-GigabitEthernet1/0/1] port link-type access   //和接入设备PC相连的接口类型必须是access，接口默认类型不是access，需要手动配置为access
   [Switch-GigabitEthernet1/0/1] port default vlan 2  //接口GE1/0/1加入VLAN 2
   [Switch-GigabitEthernet1/0/1] quit
   [Switch] interface gigabitethernet 1/0/2   //接口GE1/0/2的配置方法和接口GE1/0/1相同
   [Switch-GigabitEthernet1/0/2] port link-type access 
   [Switch-GigabitEthernet1/0/2] port default vlan 2
   [Switch-GigabitEthernet1/0/2] quit
   ```

   

2. 在Switch上添加服务器对应的静态MAC地址表项

   ```
   [Switch] mac-address static 4-4-4 gigabitethernet 1/0/2 vlan 2
   ```

3. 在Switch上添加PC对应的静态MAC地址表项 

   ```
   [Switch] mac-address static 2-2-2 gigabitethernet 1/0/1 vlan 2
   ```

4. 检查配置结果 

   ```
   # 在任意视图下执行display mac-address static vlan 2命令，查看静态MAC表是否添加成功。
   [Switch] display mac-address static vlan 2
   -------------------------------------------------------------------------- 
   MAC Address          VLAN/VSI              Learned-From        Type       
   --------------------------------------------------------------------------
   0002-0002-0002       2/-                   GE1/0/1             static
   0004-0004-0004       2/-                   GE1/0/2             static
   
   --------------------------------------------------------------------------
   Total items displayed  = 2
   ```



**配置文件**



```
Switch的配置文件
#
sysname Switch
#
vlan batch 2
#
interface GigabitEthernet1/0/1
 port link-type access
 port default vlan 2
#
interface GigabitEthernet1/0/2
 port link-type access
 port default vlan 2
#
mac-address static 0002-0002-0002 GigabitEthernet1/0/1 vlan 2
mac-address static 0004-0004-0004 GigabitEthernet1/0/2 vlan 2
#
return
```

配置静态MAC示例

### 什么是 DNS域名解析

> 我们首先要了解域名和 IP 地址的区别。IP 地址是互联网上计算机唯一的逻辑地址，通过 IP 地址实现不同计算机之间的相互通信，每台联网计算机都需要通过 IP 地址来互相联系和分别。

> 但由于 IP 地址是由一串容易混淆的数字串构成，人们很难记忆所有计算机的 IP 地址，这样对于我们日常工作生活访问不同网站是很困难的。基于这种背景，人们在 IP 地址的基础上又发展出了一种更易识别的符号化标识，这种标识由人们自行选择的字母和数字构成，相比 IP 地址更易被识别和记忆，逐渐代替 IP 地址成为互联网用户进行访问互联的主要入口。这种符号化标识就是域名。

> 域名虽然更易被用户所接受和使用，但计算机只能识别纯数字构成的 IP 地址，不能直接读取域名。因此要想达到访问效果，就需要将域名翻译成 IP 地址。而 DNS 域名解析承担的就是这种翻译效果。

### DNS域名解析过程

> 当我们在浏览器地址栏中输入 www.baidu.com 时，DNS 解析将会有将近 10 个步骤，这个过程大体大体由一张图可以表示：

![](http://pic.nexopera.tech/634ca77389f77.png)

> 整个过程大体描述如下，其中前两个步骤是在本地电脑内完成的，后 8 个步骤涉及到真正的域名解析服务器：

**第一步**、

> 本地电脑会检查浏览器缓存中有没有这个域名对应的解析过的 IP 地址，如果缓存中有，这个解析过程就结束。浏览器缓存域名也是有限制的，不仅浏览器缓存大小有限制，而且缓存的时间也有限制，通常情况下为几分钟到几小时不等，域名被缓存的时间限制可以通过 TTL 属性来设置。这个缓存时间太长和太短都不太好，如果时间太长，一旦域名被解析到的 IP 有变化，会导致被客户端缓存的域名无法解析到变化后的 IP 地址，以致该域名不能正常解析，这段时间内有一部分用户无法访问网站。如果设置时间太短，会导致用户每次访问网站都要重新解析一次域名。

**第二步**、

> 如果浏览器缓存中没有数据，浏览器会查找操作系统缓存中是否有这个域名对应的 DNS 解析结果。其实操作系统也有一个[域名解析]的过程，在 Linux 中可以通过 / etc/hosts 文件来设置，而在 windows 中可以通过配置 C:\Windows\System32\drivers\etc\hosts 文件来设置，用户可以将任何域名解析到任何能够访问的 IP 地址。例如，我们在测试时可以将一个域名解析到一台测试服务器上，这样不用修改任何代码就能测试到单独服务器上的代码的业务逻辑是否正确。正是因为有这种本地 DNS 解析的规程，所以有黑客就可能通过修改用户的域名来把特定的域名解析到他指定的 IP 地址上，导致这些域名被劫持。

**第三步**、

> 前两个过程无法解析时，就要用到我们网络配置中的 "DNS 服务器地址" 了。操作系统会把这个域名发送给这个本地 DNS 服务器。每个完整的内网通常都会配置本地 DNS 服务器，例如用户是在学校或工作单位接入互联网，那么用户的本地 DNS 服务器肯定在学校或工作单位里面。它们一般都会缓存域名解析结果，当然缓存时间是受到域名的失效时间控制的。大约 80% 的域名解析到这里就结束了，后续的 DNS 迭代和递归也是由本地 DNS 服务器负责。

> windows 在这配置：控制面板 -》网络和共享中心 -》更改适配器设置 -》选中目标适配器右键选择属性 -》Internet 协议版本 4(TCP/IPv4)-》配置 DNS 地址。

![](http://pic.nexopera.tech/634ca78b5a827.png)

![](http://pic.nexopera.tech/634ca79b8625a.png)

Linux 在这设置：/etc/resolv.conf

![](http://pic.nexopera.tech/634ca7aeab6d0.png)

![](http://pic.nexopera.tech/634ca7bf56d17.png)

**第四步**、

如果本地 DNS 服务器仍然没有命中，就直接到根 DNS 服务器请求解析。

**第五步**、

> 根 DNS 服务器返回给本地 DNS 域名服务器一个顶级 DNS 服务器地址，它是国际顶级域名服务器，如. com、.cn、.org 等，全球只有 13 台左右。

**第六步**、

本地 DNS 服务器再向上一步获得的顶级 DNS 服务器发送解析请求。

**第七步**、

> 接受请求的顶级 DNS 服务器查找并返回此域名对应的 Name Server 域名服务器的地址，这个 Name Server 服务器就是我要访问的网站域名提供商的服务器，其实该域名的解析任务就是由域名提供商的服务器来完成。 比如我要访问 www.baidu.com，而这个域名是从 A 公司注册获得的，那么 A 公司上的服务器就会有 www.baidu.com 的相关信息。

**第八步**、

> Name Server 服务器会查询存储的域名和 IP 的映射关系表，再把查询出来的域名和 IP 地址等等信息，连同一个 TTL 值返回给本地 DNS 服务器。

**第九步**、

> 返回该域名对应的 IP 和 TTL 值，本地 DNS 服务器会缓存这个域名和 IP 的对应关系，缓存时间由 TTL 值控制。

**第十步**、

> 把解析的结果返回给本地电脑，本地电脑根据 TTL 值缓存在本地系统缓存中，域名解析过程结束在实际的 DNS 解析过程中，可能还不止这 10 步，如 Name Server 可能有很多级，或者有一个 GTM 来负载均衡控制，这都有可能会影响域名解析过程。

### 递归查询和迭代查询的区别

> DNS 客户端和本地名称服务器是递归，而本地名称服务器和其他名称服务器之间是迭代。
> **DNS 递归名称解析**：在 DNS 递归名称解析中，当所配置的本地名称服务器解析不了时，后面的查询工作是由本地名称服务器替代 DNS 客户端进行的（以 “本地名称服务器” 为中心），只需要本地名称服务器向 DNS 客户端返回最终的查询结果即可。

**DNS 迭代名称解析**：（或者叫 “迭代查询”）的所有查询工作全部是 DNS 客户端自己进行（以“DNS 客户端” 自己为中心）。在条件之一满足时就会采用迭代名称解析方式：

- 在查询本地名称服务器时，如果客户端的请求报文中没有申请使用递归查询，即在 DNS 请求报头部的 RD 字段没有置 1。相当于说 “你都没有主动要求我为你进行递归查询，我当然不会为你工作了”。
- 客户端在 DNS 请求报文中申请使用的是递归查询（也就是 RD 字段置 1 了），但在所配置的本地名称服务器上是禁用递归查询（DNS 服务器一般默认支持递归查询的），即在应答 DNS 报文头部的 RA 字段置 0。

### 域名解析记录

**主要分为 A 记录、MX 记录、CNAME 记录、NS 记录和 TXT 记录**

1、A 记录

> A 代表 Address，用来指定域名对应的 IP 地址，如将 item.taobao.com 指定到 115.238.23.xxx，将 switch.taobao.com 指定到 121.14.24.xxx。**A\**\**记录可以将多个域名解析到一个 IP 地址，但是不能将一个域名解析到多个 IP 地址**

2、MX 记录

> Mail Exchange，就是可以将某个域名下的邮件服务器指向自己的 Mail Server，如 taobao.com 域名的 A 记录 IP 地址是 115.238.25.xxx，如果将 MX 记录设置为 115.238.25.xxx，即 xxx@taobao.com 的邮件路由，DNS 会将邮件发送到 115.238.25.xxx 所在的服务器，而正常通过 Web 请求的话仍然解析到 A 记录的 IP 地址

3、CNAME 记录

> Canonical Name，即别名解析。所谓别名解析就是可以为一个域名设置一个或者多个别名，如将 aaa.com 解析到 bbb.net、将 ccc.com 也解析到 bbb.net，其中 bbb.net 分别是 aaa.com 和 ccc.com 的别名

4、NS 记录

> 为某个域名指定 DNS 解析服务器，也就是这个域名由指定的 IP 地址的 DNS 服务器取解析

5、TXT 记录

> 为某个主机名或域名设置说明，如可以为 ddd.net 设置 TXT 记录为 "这是 XXX 的博客" 这样的说明

DNS域名详细解析过程

Nexopera是一个专注于Linux、网络和运维等领域的博客网站。将为读者提供广泛的相关文章，涵盖操作系统、服务器管理、网络配置、安全性等多个主题。如果你是初学者，希望这里有适合你的内容。