## 1、[ARP](https://so.csdn.net/so/search?q=ARP&spm=1001.2101.3001.7020)表

  提起ARP表必然先想起ARP（address resolution protocol）协议，地址解析协议。
  在实际应用中，我们经常遇到这样的问题：已知一个机器的IP地址，但在实际网络的链路上传送数据帧时，最终还是必须使用该网络的硬件地址，需要知道其MAC地址。如果两个都需要去记忆或输入，大大增加了其繁琐程度。地址解析协议ARP就是用来解决这样的问题的。
  由于IP协议使用了ARP协议，因此通常把ARP协议划归到[网络层](https://so.csdn.net/so/search?q=网络层&spm=1001.2101.3001.7020)。但ARP协议的用途是为了从网络层使用IP地址，解析出在链路层使用的硬件地址。
  每一台主机都设有一个ARP高速缓存，里面有本局域网上的各种主机和[路由器](https://so.csdn.net/so/search?q=路由器&spm=1001.2101.3001.7020)的IP地址到硬件地址的映射表，表里面的内容由ARP协议进行动态更新。表内的数据会老化，达到老化时间会自动删除，在此通信时，由ARP协议重新添加。
**通信过程**
有PC0，PC1两台主机
使用思科的仿真模拟器能直观的看出通信过程
![在这里插入图片描述](http://pic.nexopera.tech/636866f249ce9.png)
  PC0向PC1发送一个ping报文，向PC0输入1.1.1.3 然后开始发送，PC0先查询本地APR表查询1.1.1.3对应MAC地址，但并没查到，这种情况PC0在本局域网上广播发送一个ARP请求分组。ARP请求分组的主要内容是：

> 我的IP地址是1.1.1.2，硬件地址是xx-xx-xx-xx-xx-xx。我想知道IP地址为1.1.1.3的主机的硬件地址。

  在本局域网上的所有主机上运行的ARP进程都会收到此ARP请求分组。PC1的IP地址与ARP请求分组中要查询的IP地址一致，就收下ARP请求分组，并向PC0发送ARP响应分组，同时在这个ARP响应分组中写入自己的硬件地址。其余主机ip地址都与ARP请求要查询的ip地址不一致，不做任何回应。
响应内容为：

> 我的ip地址是1.1.1.3，我的硬件地址是xx-xx-xx-xx-xx-xx

虽然ARP请求分组是广播发送的，但ARP响应分组是普通的单播，即从一个原地址发送到一个目的地址。
接下来PC0就可以使用刚获取的PC1MAC地址，进行icmp数据发送。
![在这里插入图片描述](http://pic.nexopera.tech/636866f287b22.png)

## 2、MAC表

  说到MAC表，就不得不说一下交换机的工作原理，因为交换机是根据MAC地址转发数据帧的。
![在这里插入图片描述](http://pic.nexopera.tech/636866f26a67d.png)
  当PC0发送ARP数据包，交换机会把数据包发往PC0之外的所有主机，并在相应包中记录下相应Mac地址与接口数据。
  当PC0向PC1发送一帧数据，从1口进到交换机。交换机收到帧后，根据帧中的目的MAC先查本地MAC表，没有查到应从哪个接口转发这个帧。
  接着，交换机把这个帧的源MAC和接口1写入交换表中，并向除1以外的所有接口广播这个帧，PC2将此广播帧丢弃，因为目的地址不对。PC1收下这个目的地址是自己MAC的数据，并回应数据包，此时交换机会把PC1的MAC和对应接口2写入表中。然后当PC0与PC1再次发送数据交换机可以根据目的MAC查表找出对应的接口，将数据包直接送达对应的主机。
  考虑到有可能在交换机的接口更换主机，或者主机要跟换主机更换网卡，这时交换机中MAC表也是动态的、有自己的老化时间，会自动删除相关数据。
  当交换机中一台主机突然从**2口**切换到**3口**，交换机收到的**此主机**的数据仍然会发送到**原端口**2口就会出现超时情况，直到Mac中数据更新，或者手动把交换机断电重启重更新Mac表数据。
![在这里插入图片描述](http://pic.nexopera.tech/636866f288cd3.png)

## 3、[路由表](https://so.csdn.net/so/search?q=路由表&spm=1001.2101.3001.7020)

  说起路由表，就不得不提起**路由器**。（此处的路由器与家用路由器略有不同，家用路由器集成了路由器和交换机的功能为了更方便用户使用）路由器是一种具有多个输入端口和多个输出端口的专用设备也可称为计算机。其任务是转发分组。路由器结构由两部分组成：**路由选择**部分和**分组转发**部分。
  路由器工作在网络层，主要功能就是实现跨网段传输数据。
![在这里插入图片描述](http://pic.nexopera.tech/636866f257304.png)

> 如上图：一网段的主机要与其他网段的主机通信，则数据会先发送给指定的网关，也就是路由器，由路由器选择网段继续通信，所以发送的数据包起始中网络层的ip地址不变，源ip地址就是当前主机的ip地址，目的ip地址就是不同网段的主机的ip地址，但是链路层由于数据要先发给路由器，那么目的mac就是路由器的mac地址，然后路由器选择其他网段，则源mac变成路由器另一个网口的mac地址，目的mac就是目标主机的mac地址，所以整个过程网络层的一直不变，但是链路层一直再变

![在这里插入图片描述](http://pic.nexopera.tech/636866f293c15.png)

> 如上图： 由于现在是两台路由器和两个网段的主机，所以需要构成三个局域网，当源主机跨网段与目标主机通信时，由于网段不同，数据会先发送给路由器，然后路由器再选择对应的目的网段，但是此时路由器另一端所在的网段与之目标主机的网段不同，所以无法继续向下发送，此时需要设置下一跳，下一跳的目的就是指定当前自己网段的主机要访问其他网段的主机时从这个路由器应该跳到哪个路由器，只要设置了，就可以直接发送数据到指定的路由器，整个过程就完成
> 1、 当网络中有多个路由器是，两个主机需要通信路由器需要记录下一跳信息，下一跳的目的就是指定当前自己网段的主机要访问其他网段的主机时从这个路由器应该跳到哪个路由器
> 2、 路由表记录着下一跳。

  路由表中记录着不同网段的信息。路由表中记录的信息有的需要手动添加（称为静态路由表），通过路由协议自动获取的（称为动态路由表），我们的主机直接连到路由器上（中间无三层网络设备）这种情况是直连路由，属于静态路由。
  路由选择处理机的任务是根据所选定的路由选择协议（路由协议后续在做总结）构造出**路由表**，同时经常或定期和相邻路由器交换路由信息而不断地跟新和维护路由表。
![在这里插入图片描述](http://pic.nexopera.tech/636866f3995d4.png)


网络中的三张表

网络端口大全

### 一、TCP

- TCP 首部
- 流量控制
- 拥塞控制
- 三次握手，四次挥手
- tcp 怎样保证数据正确性？

> 流量控制是为了让接收方能来得及接收，而拥塞控制是为了降低整个网络的拥塞程度

1、TCP 首部

![image-20221028143413512](http://pic.nexopera.tech/635b77e60eb32.png)

- 源端口号
- 目标端口号
- 32 位序列号
- 32 位确认号
- 首部长度（单位为 4 字节，默认为 5，即 20 字节）
- 保留位（6 位）
- 6 个控制位（SYN、ACK、FIN、PUSH、URG、RST） SYN：同步序号位，TCP 建立连接时要将这个值设为 1 ACK：为 1 表示确认号 FIN：发送端完成位，提出断开连接的一方把 FIN 置为 1 表示要断开连接 PUSH：急迫位，缓存区将满，立刻传输速度 RST：重置位，连接断了重新连接 URG：紧急信号
- 16 位窗口大小：接收窗口大小，流量控制使用，如果窗口大小为 0，可以发送窗口探测
- 16 位校验和：校验和用来做差错控制，TCP 校验和的计算包括 TCP 首部、数据和其它填充字节。在发送 TCP 数据段时，由发送端计算校验和，当到达目的地时又进行一次检验和计算。如果两次校验和一致，说明数据是正确的，否则将认为数据被破坏，接收端将丢弃该数据
- 16 位紧急指针：仅在 URG 控制位为 1 时有效。表示紧急数据的末尾在 TCP 数据部分中的位置。通常在暂时中断通信时使用（比如输入 Ctrl + C）

2、流量控制

![image-20221028143504929](http://pic.nexopera.tech/635b78195763b.png)

> 流量控制，就是让发送方的发送速率不要太快，要让接收方来得及接收

> 利用滑动窗口机制可以很方便地在 tcp 连接上实现对发送方的流量控制

TCP 接收方利用自己的接收窗口的大小来限制发送方发送窗口的大小

- 重传计时器
- TCP 发送方收到接收方的零窗口通知后，应启动持续计时器。持续计时器超时后，向接收方发送零窗口探测报文
- 即使接收窗口为 0，接收方也会接收：零窗口探测报文段、确认报文段、携带紧急数据的报文段

TCP 发送方的发送窗口大小 = Math.min(自身拥塞窗口大小, TCP 接收方的接收窗口大小)

3、拥塞控制

什么是拥塞

![image-20221028143511601](http://pic.nexopera.tech/635b78202df9e.png)

假定条件

> 数据是单方向发送，而另一方向只传送确认 接收方总是有足够大的缓存空间，因而发送方发送窗口的大小由网络的拥塞程度来决定 以最大报文段 MSS 的个数为讨论问题的单位，而不是以字节为单位

慢开始 + 拥塞避免算法

> MSS：TCP 最大报文段 ssthresh：慢开始门限 cwnd：拥塞窗口 swnd：发送窗口 rtt：每次往返时间

![image-20221028143518190](http://pic.nexopera.tech/635b7826c6043.png)

快重传

![image-20221028143523296](http://pic.nexopera.tech/635b782bc6f69.png)

慢开始 + 拥塞避免算法中，发送方把拥塞窗口 cwnd 又设置为 1，并错误地启动慢开始算法，降低了传输效率

![image-20221028143526757](http://pic.nexopera.tech/635b782f4514d.png)

收到 3 个重复确认

- 接收方收到失序的报文段，立即发出重复确认
- 发送方收到 3 个连续的重复确认，立即重传

![image-20221028143531165](http://pic.nexopera.tech/635b7833ab25c.png)

快恢复

![image-20221028143534251](http://pic.nexopera.tech/635b7836d0897.png)

慢开始 + 拥塞避免 + 快重传 + 快恢复结合

![image-20221028143537909](http://pic.nexopera.tech/635b783a79d0c.png)

4、三次握手，四次挥手

4.1 三次握手

1. 发送端：SYN=1、seq=x
2. 接收端：ACK=1、ack=x+1、SYN=1、seq=y
3. 发送端：ACK=1、ack=y+1、seq=x+1

------

- TCP 规定：SYN 被设置为 1 的报文段不能携带数据，但要消耗掉一个序号
- TCP 规定：普通的确认报文段如果不携带数据，则不消耗序号

![image-20221028143541614](http://pic.nexopera.tech/635b783e2be14.png)

4.2 四次挥手

1. 发送端：FIN=1，ACK=1，seq=u，ack=v（u 等于发送端已传送过的数据的最后一个字节序号 + 1，v 等于发送端之前已收到的数据的最后一字节序号 + 1）
2. 接收端：ACK=1，ack=u+1，seq=v
3. 接收端：FIN=1，ACK=1，ack=u+1，seq=w（w：半关闭情况下，可能收到了数据）
4. 发送端：ACK=1，ack=w+1，seq=u+1

------

- TCP 规定：终止位 FIN 等于 1 的报文段，即使不携带数据，也要一个消耗掉一个序号
- MSL：最长报文段寿命，建议为 2 分钟

> 为什么要等待 2MSL？
>
> 如果接收端发送 FIN 连接释放，发送端接收后发送 ACK，如果丢失，会导致接收端超时重传，而无法进入 CLOSED 状态

![image-20221028143546190](http://pic.nexopera.tech/635b7842c445f.png)

4.3 保活计时器

![image-20221028143549647](http://pic.nexopera.tech/635b78462af13.png)

4.4 半连接队列

> 服务器第一次收到客户端的 SYN 之后，就会处于 SYN_RCVD 状态，此时双方还没有完全建立其连接，服务器会把此种状态下请求连接放在一个队列里，我们把这种队列称之为半连接队列。

4.5 三次握手能不能改成两次握手？

- 不能
- TCP 发送连接请求，但长时间没到达，然后触发了超时重传
- 又发送了一次，后建立连接，数据传输，并断开了连接
- 但此时之前没达到的请求报文段突然又到了接收端服务器，接收端服务器变成了 ESTABLISHED 状态
- 接收端一直在等发送端发送数据，白白浪费了主机很多资源，导致了错误

![image-20221028143553275](http://pic.nexopera.tech/635b7849c9b6a.png)

4.6 四次挥手能不能改成三次挥手？

- 不能
- 接收端可能还有数据没有发送
- 需要等待一段时间，发送完数据，才会发送 FIN

4.7 SYN 攻击

> 服务器端的资源分配是在二次握手时分配的，而客户端的资源是在完成三次握手时分配的，所以服务器容易受到 SYN 洪泛攻击。SYN 攻击就是 Client 在短时间内伪造大量不存在的 IP 地址，并向 Server 不断地发送 SYN 包，Server 则回复确认包，并等待 Client 确认，由于源地址不存在，因此 Server 需要不断重发直至超时，这些伪造的 SYN 包将长时间占用未连接队列，导致正常的 SYN 请求因为队列满而被丢弃，从而引起网络拥塞甚至系统瘫痪。SYN 攻击是一种典型的 DoS/DDoS 攻击。

5、tcp 怎样保证数据正确性？

> 差错控制 发送的数据包的二进制相加然后取反，检测数据在传输过程中的任何变化，如果收到段的检验和有差错，TCP 将丢弃这个报文段和不确认收到此报文段。编号 + 排序 TCP 给发送的每一个包进行编号，接收方对数据包进行排序，把有序数据传送给应用层 确认 + 超时重传的机制 当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。流量控制

> TCP 连接的每一方都有固定大小的缓冲空间，TCP 的接收端只允许发送端发送接收端缓存区能接纳的数据。当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。TCP 使用的流量控制协议是可变大小的滑动窗口协议。

**拥塞控制**

> 当网络拥塞时，减少数据的发送。发送方有拥塞窗口，发送数据前比对接收方发过来的接收窗口，取两者的最小值 --- 慢启动、拥塞避免、拥塞发送、快速恢复

### 二、UDP

![image-20221028143558750](http://pic.nexopera.tech/635b784f4458c.png)

### 三、TCP/UDP 对比

TCP/IP 协议架构

![image-20221028143602705](http://pic.nexopera.tech/635b7853415e6.png)

对比

![image-20221028143606829](http://pic.nexopera.tech/635b785773f8a.png)

1、是否面向连接

- UDP：无连接
- TCP：面向连接（三次握手，四次挥手）

![image-20221028143609990](http://pic.nexopera.tech/635b785a796bc.png)

2、是否支持广播和多播

- UDP：支持一对一，一对多，多对一和多对多交互通信
- TCP：只能一对一通信

![image-20221028143613065](http://pic.nexopera.tech/635b785d928d7.png)

3、对应用层报文的处理

- UDP：面向报文（对应用层交付的报文直接打包）
- TCP：面向字节流（是 tcp 实现可靠传输，流量控制，拥塞控制的基础）

![image-20221028143616912](http://pic.nexopera.tech/635b786177a13.png)

4、是否提供可靠传输

- UDP：向上提供无连接不可靠服务
- UDP：适用于实时应用（IP 电话、视频会议等）
- TCP：向上提供面向连接的可靠服务
- TCP：适用于要求可靠传输的应用，例如文件传输

![image-20221028143621303](http://pic.nexopera.tech/635b7865d1a6d.png)

5、首部开销

- UDP：8 个字节
- TCP：最小 20 字节，最大 60 字节

![image-20221028143625212](http://pic.nexopera.tech/635b77cf7a21a.png)



图解TCP,UDP,流量控制,拥塞控制

DNS 是互联网核心协议之一。不管是上网浏览，还是编程开发，都需要了解一点它的知识。

本文详细介绍DNS的原理，以及如何运用工具软件观察它的运作。我的目标是，读完此文后，你就能完全理解DNS。

![img](http://pic.nexopera.tech/62db53aa63f87.png)

## 一、DNS 是什么？

DNS （Domain Name System 的缩写）的作用非常简单，就是根据域名查出IP地址。你可以把它想象成一本巨大的电话本。

举例来说，如果你要访问域名`math.stackexchange.com`，首先要通过DNS查出它的IP地址是`151.101.129.69`。

如果你不清楚为什么一定要查出IP地址，才能进行网络通信，建议先阅读我写的[《互联网协议入门》](https://blog.nexopera.tech/post/52)。

## 二、查询过程

虽然只需要返回一个IP地址，但是DNS的查询过程非常复杂，分成多个步骤。

工具软件`dig`可以显示整个查询过程。

 ```bash
$ dig math.stackexchange.com
 ```

上面的命令会输出六段信息。

![img](http://pic.nexopera.tech/62db53ab2df8e.png)

第一段是查询参数和统计。

![img](http://pic.nexopera.tech/62db53abcb1c0.png)

第二段是查询内容。

![img](http://pic.nexopera.tech/62db53aa6a7ba.png)

上面结果表示，查询域名`math.stackexchange.com`的`A`记录，`A`是address的缩写。

第三段是DNS服务器的答复。

![img](http://pic.nexopera.tech/62db53aa696af.png)

上面结果显示，`math.stackexchange.com`有四个`A`记录，即四个IP地址。`600`是TTL值（Time to live 的缩写），表示缓存时间，即600秒之内不用重新查询。

第四段显示`stackexchange.com`的NS记录（Name Server的缩写），即哪些服务器负责管理`stackexchange.com`的DNS记录。

![img](http://pic.nexopera.tech/62db53aa67a96.png)

上面结果显示`stackexchange.com`共有四条NS记录，即四个域名服务器，向其中任一台查询就能知道`math.stackexchange.com`的IP地址是什么。

第五段是上面四个域名服务器的IP地址，这是随着前一段一起返回的。

![img](http://pic.nexopera.tech/62db53ac01747.png)

第六段是DNS服务器的一些传输信息。

![img](http://pic.nexopera.tech/62db53abb9fdd.png)

上面结果显示，本机的DNS服务器是`192.168.1.253`，查询端口是53（DNS服务器的默认端口），以及回应长度是305字节。

如果不想看到这么多内容，可以使用`+short`参数。

 ```bash
$ dig +short math.stackexchange.com

151.101.129.69
151.101.65.69
151.101.193.69
151.101.1.69
 ```

上面命令只返回`math.stackexchange.com`对应的4个IP地址（即`A`记录）。

## 三、DNS服务器

下面我们根据前面这个例子，一步步还原，本机到底怎么得到域名`math.stackexchange.com`的IP地址。

首先，本机一定要知道DNS服务器的IP地址，否则上不了网。通过DNS服务器，才能知道某个域名的IP地址到底是什么。

![img](http://pic.nexopera.tech/62db53abd428c.jpg)

DNS服务器的IP地址，有可能是动态的，每次上网时由网关分配，这叫做DHCP机制；也有可能是事先指定的固定地址。Linux系统里面，DNS服务器的IP地址保存在`/etc/resolv.conf`文件。

上例的DNS服务器是`192.168.1.253`，这是一个内网地址。有一些公网的DNS服务器，也可以使用，其中最有名的就是Google的[`8.8.8.8`](https://developers.google.com/speed/public-dns/)和Level 3的[`4.2.2.2`](https://www.tummy.com/articles/famous-dns-server/)。

本机只向自己的DNS服务器查询，`dig`命令有一个`@`参数，显示向其他DNS服务器查询的结果。

```bash
$ dig @4.2.2.2 math.stackexchange.com
```

上面命令指定向DNS服务器`4.2.2.2`查询。

## 四、域名的层级

DNS服务器怎么会知道每个域名的IP地址呢？答案是分级查询。

请仔细看前面的例子，每个域名的尾部都多了一个点。

![img](http://pic.nexopera.tech/62db53aa6a7ba.png)

比如，域名`math.stackexchange.com`显示为`math.stackexchange.com.`。这不是疏忽，而是所有域名的尾部，实际上都有一个根域名。

举例来说，`www.example.com`真正的域名是`www.example.com.root`，简写为`www.example.com.`。因为，根域名`.root`对于所有域名都是一样的，所以平时是省略的。

根域名的下一级，叫做"顶级域名"（top-level domain，缩写为TLD），比如`.com`、`.net`；再下一级叫做"次级域名"（second-level domain，缩写为SLD），比如`www.example.com`里面的`.example`，这一级域名是用户可以注册的；再下一级是主机名（host），比如`www.example.com`里面的`www`，又称为"三级域名"，这是用户在自己的域里面为服务器分配的名称，是用户可以任意分配的。

总结一下，域名的层级结构如下。

```bash
主机名.次级域名.顶级域名.根域名

# 即

host.sld.tld.root
```

## 五、根域名服务器

DNS服务器根据域名的层级，进行分级查询。

需要明确的是，每一级域名都有自己的NS记录，NS记录指向该级域名的域名服务器。这些服务器知道下一级域名的各种记录。

所谓"分级查询"，就是从根域名开始，依次查询每一级域名的NS记录，直到查到最终的IP地址，过程大致如下。

> 1. 从"根域名服务器"查到"顶级域名服务器"的NS记录和A记录（IP地址）
> 2. 从"顶级域名服务器"查到"次级域名服务器"的NS记录和A记录（IP地址）
> 3. 从"次级域名服务器"查出"主机名"的IP地址

仔细看上面的过程，你可能发现了，没有提到DNS服务器怎么知道"根域名服务器"的IP地址。回答是"根域名服务器"的NS记录和IP地址一般是不会变化的，所以内置在DNS服务器里面。

下面是内置的根域名服务器IP地址的一个[例子](http://www.cyberciti.biz/faq/unix-linux-update-root-hints-data-file/)。

![img](http://pic.nexopera.tech/62db53ac0adcc.png)

上面列表中，列出了根域名（`.root`）的三条NS记录`A.ROOT-SERVERS.NET`、`B.ROOT-SERVERS.NET`和`C.ROOT-SERVERS.NET`，以及它们的IP地址（即`A`记录）`198.41.0.4`、`192.228.79.201`、`192.33.4.12`。

另外，可以看到所有记录的TTL值是3600000秒，相当于1000小时。也就是说，每1000小时才查询一次根域名服务器的列表。

目前，世界上一共有十三组根域名服务器，从`A.ROOT-SERVERS.NET`一直到`M.ROOT-SERVERS.NET`。

## 六、分级查询的实例

`dig`命令的`+trace`参数可以显示DNS的整个分级查询过程。

```bash
$ dig +trace math.stackexchange.com
```

上面命令的第一段列出根域名`.`的所有NS记录，即所有根域名服务器。

![img](http://pic.nexopera.tech/62db53ac778d1.png)

根据内置的根域名服务器IP地址，DNS服务器向所有这些IP地址发出查询请求，询问`math.stackexchange.com`的顶级域名服务器`com.`的NS记录。最先回复的根域名服务器将被缓存，以后只向这台服务器发请求。

接着是第二段。

![img](http://pic.nexopera.tech/62db53ad3338e.png)

上面结果显示`.com`域名的13条NS记录，同时返回的还有每一条记录对应的IP地址。

然后，DNS服务器向这些顶级域名服务器发出查询请求，询问`math.stackexchange.com`的次级域名`stackexchange.com`的NS记录。

![img](http://pic.nexopera.tech/62db53ad3845c.png)

上面结果显示`stackexchange.com`有四条NS记录，同时返回的还有每一条NS记录对应的IP地址。

然后，DNS服务器向上面这四台NS服务器查询`math.stackexchange.com`的主机名。

![img](http://pic.nexopera.tech/62db53ad789d0.png)

上面结果显示，`math.stackexchange.com`有4条`A`记录，即这四个IP地址都可以访问到网站。并且还显示，最先返回结果的NS服务器是`ns-463.awsdns-57.com`，IP地址为`205.251.193.207`。

## 七、NS 记录的查询

`dig`命令可以单独查看每一级域名的NS记录。

```bash
$ dig ns com
$ dig ns stackexchange.com
```

`+short`参数可以显示简化的结果。

```bash
$ dig +short ns com
$ dig +short ns stackexchange.com
```

## 八、DNS的记录类型

域名与IP之间的对应关系，称为"记录"（record）。根据使用场景，"记录"可以分成不同的类型（type），前面已经看到了有`A`记录和`NS`记录。

常见的DNS记录类型如下。

> （1） `A`：地址记录（Address），返回域名指向的IP地址。
>
> （2） `NS`：域名服务器记录（Name Server），返回保存下一级域名信息的服务器地址。该记录只能设置为域名，不能设置为IP地址。
>
> （3）`MX`：邮件记录（Mail eXchange），返回接收电子邮件的服务器地址。
>
> （4）`CNAME`：规范名称记录（Canonical Name），返回另一个域名，即当前查询的域名是另一个域名的跳转，详见下文。
>
> （5）`PTR`：逆向查询记录（Pointer Record），只用于从IP地址查询域名，详见下文。

一般来说，为了服务的安全可靠，至少应该有两条`NS`记录，而`A`记录和`MX`记录也可以有多条，这样就提供了服务的冗余性，防止出现单点失败。

`CNAME`记录主要用于域名的内部跳转，为服务器配置提供灵活性，用户感知不到。举例来说，`facebook.github.io`这个域名就是一个`CNAME`记录。

```bash
$ dig facebook.github.io

...

;; ANSWER SECTION:
facebook.github.io. 3370    IN  CNAME   github.map.fastly.net.
github.map.fastly.net.  600 IN  A   103.245.222.133
```

上面结果显示，`facebook.github.io`的CNAME记录指向`github.map.fastly.net`。也就是说，用户查询`facebook.github.io`的时候，实际上返回的是`github.map.fastly.net`的IP地址。这样的好处是，变更服务器IP地址的时候，只要修改`github.map.fastly.net`这个域名就可以了，用户的`facebook.github.io`域名不用修改。

由于`CNAME`记录就是一个替换，所以域名一旦设置`CNAME`记录以后，就不能再设置其他记录了（比如`A`记录和`MX`记录），这是为了防止产生冲突。举例来说，`foo.com`指向`bar.com`，而两个域名各有自己的`MX`记录，如果两者不一致，就会产生问题。由于顶级域名通常要设置`MX`记录，所以一般不允许用户对顶级域名设置`CNAME`记录。

`PTR`记录用于从IP地址反查域名。`dig`命令的`-x`参数用于查询`PTR`记录。

```bash
$ dig -x 192.30.252.153

...

;; ANSWER SECTION:
153.252.30.192.in-addr.arpa. 3600 IN    PTR pages.github.com.
```

上面结果显示，`192.30.252.153`这台服务器的域名是`pages.github.com`。

逆向查询的一个应用，是可以防止垃圾邮件，即验证发送邮件的IP地址，是否真的有它所声称的域名。

`dig`命令可以查看指定的记录类型。

```bash
$ dig a github.com
$ dig ns github.com
$ dig mx github.com
```

## 九、其他DNS工具

除了`dig`，还有一些其他小工具也可以使用。

**（1）host 命令**

`host`命令可以看作`dig`命令的简化版本，返回当前请求域名的各种记录。

```bash
$ host github.com

github.com has address 192.30.252.121
github.com mail is handled by 5 ALT2.ASPMX.L.GOOGLE.COM.
github.com mail is handled by 10 ALT4.ASPMX.L.GOOGLE.COM.
github.com mail is handled by 10 ALT3.ASPMX.L.GOOGLE.COM.
github.com mail is handled by 5 ALT1.ASPMX.L.GOOGLE.COM.
github.com mail is handled by 1 ASPMX.L.GOOGLE.COM.

$ host facebook.github.com

facebook.github.com is an alias for github.map.fastly.net.
github.map.fastly.net has address 103.245.222.133
```

`host`命令也可以用于逆向查询，即从IP地址查询域名，等同于`dig -x <ip>`。

```bash
$ host 192.30.252.153

153.252.30.192.in-addr.arpa domain name pointer pages.github.com.
```

**（2）nslookup 命令**

`nslookup`命令用于互动式地查询域名记录。

```bash
$ nslookup

> facebook.github.io
Server:     192.168.1.253
Address:    192.168.1.253#53

Non-authoritative answer:
facebook.github.io  canonical name = github.map.fastly.net.
Name:   github.map.fastly.net
Address: 103.245.222.133

> 
```

**（3）whois 命令**

`whois`命令用来查看域名的注册情况。

```bash
$ whois github.com
```

## 十、参考文章

- DNS: The Good Parts, by Pete Keen
- DNS 101, by Mark McDonnell

**附：DNS百科**

DNS（Domain Name System，域名系统），因特网上作为域名和IP地址相互映射的一个分布式数据库，能够使用户更方便的访问互联网，而不用去记住能够被机器直接读取的IP数串。通过主机名，最终得到该主机名对应的IP地址的过程叫做域名解析（或主机名解析）。DNS协议运行在UDP协议之上，使用端口号53。在RFC文档中RFC 2181对DNS有规范说明，RFC 2136对DNS的动态更新进行说明，RFC 2308对DNS查询的反向缓存进行说明。

**DNS功能**

每个IP地址都可以有一个主机名，主机名由一个或多个字符串组成，字符串之间用小数点隔开。有了主机名，就不要死记硬背每台IP设备的IP地址，只要记住相对直观有意义的主机名就行了。这就是DNS协议所要完成的功能。

主机名到IP地址的映射有两种方式：

1）静态映射，每台设备上都配置主机到IP地址的映射，各设备独立维护自己的映射表，而且只供本设备使用；

2）动态映射，建立一套域名解析系统（DNS），只在专门的DNS服务器上配置主机到IP地址的映射，网络上需要使用主机名通信的设备，首先需要到DNS服务器查询主机所对应的IP地址。

通过主机名，最终得到该主机名对应的IP地址的过程叫做域名解析（或主机名解析）。在解析域名时，可以首先采用静态域名解析的方法，如果静态域名解析不成功，再采用动态域名解析的方法。可以将一些常用的域名放入静态域名解析表中，这样可以大大提高域名解析效率。

**DNS安全问题**

1. 针对域名系统的恶意攻击：DDOS攻击造成域名解析瘫痪。
2. 域名劫持：修改注册信息、劫持解析结果。
3. 国家性质的域名系统安全事件：“.ly”域名瘫痪、“.af”域名的域名管理权变更。
4. 系统上运行的DNS服务存在漏洞，导致被黑客获取权限，从而篡改DNS信息。
5. DNS设置不当，导致泄漏一些敏感信息。提供给黑客进一步攻击提供有力信息。


DNS 原理入门指南


[上一篇文章](https://blog.nexopera.tech/post/52)分析了互联网的总体构思，从下至上，每一层协议的设计思想。

这是从设计者的角度看问题，今天我想切换到用户的角度，看看用户是如何从上至下，与这些协议互动的。

![img](http://pic.nexopera.tech/62db55b92ccbd.jpg)

（接上文）

## **七、一个小结**

先对前面的内容，做一个小结。

我们已经知道，网络通信就是交换数据包。电脑A向电脑B发送一个数据包，后者收到了，回复一个数据包，从而实现两台电脑之间的通信。数据包的结构，基本上是下面这样：

![img](http://pic.nexopera.tech/62db551d2c32d.png)

发送这个包，需要知道两个地址：

> 　　  * 对方的MAC地址
>
> 　　  * 对方的IP地址

有了这两个地址，数据包才能准确送到接收者手中。但是，前面说过，MAC地址有局限性，如果两台电脑不在同一个子网络，就无法知道对方的MAC地址，必须通过网关（gateway）转发。

![img](http://pic.nexopera.tech/62db55b9ab742.jpg)

上图中，1号电脑要向4号电脑发送一个数据包。它先判断4号电脑是否在同一个子网络，结果发现不是（后文介绍判断方法），于是就把这个数据包发到网关A。网关A通过路由协议，发现4号电脑位于子网络B，又把数据包发给网关B，网关B再转发到4号电脑。

1号电脑把数据包发到网关A，必须知道网关A的MAC地址。所以，数据包的目标地址，实际上分成两种情况：

| 场景           | 数据包地址                  |
| -------------- | --------------------------- |
| 同一个子网络   | 对方的MAC地址，对方的IP地址 |
| 非同一个子网络 | 网关的MAC地址，对方的IP地址 |

发送数据包之前，电脑必须判断对方是否在同一个子网络，然后选择相应的MAC地址。接下来，我们就来看，实际使用中，这个过程是怎么完成的。

## **八、用户的上网设置**

### **8.1 静态IP地址**

你买了一台新电脑，插上网线，开机，这时电脑能够上网吗？

![img](http://pic.nexopera.tech/62db55b9a4642.jpg)

通常你必须做一些设置。有时，管理员（或者ISP）会告诉你下面四个参数，你把它们填入操作系统，计算机就能连上网了：

> 　　  * 本机的IP地址
> 　　  * 子网掩码
> 　　  * 网关的IP地址
> 　　  * DNS的IP地址

下图是Windows系统的设置窗口。

![img](http://pic.nexopera.tech/62db55b9d8540.png)

这四个参数缺一不可，后文会解释为什么需要知道它们才能上网。由于它们是给定的，计算机每次开机，都会分到同样的IP地址，所以这种情况被称作"静态IP地址上网"。

但是，这样的设置很专业，普通用户望而生畏，而且如果一台电脑的IP地址保持不变，其他电脑就不能使用这个地址，不够灵活。出于这两个原因，大多数用户使用"动态IP地址上网"。

### **8.2 动态IP地址**

所谓"动态IP地址"，指计算机开机后，会自动分配到一个IP地址，不用人为设定。它使用的协议叫做[DHCP协议](https://zh.wikipedia.org/zh/DHCP)。

这个协议规定，每一个子网络中，有一台计算机负责管理本网络的所有IP地址，它叫做"DHCP服务器"。新的计算机加入网络，必须向"DHCP服务器"发送一个"DHCP请求"数据包，申请IP地址和相关的网络参数。

前面说过，如果两台计算机在同一个子网络，必须知道对方的MAC地址和IP地址，才能发送数据包。但是，新加入的计算机不知道这两个地址，怎么发送数据包呢？

DHCP协议做了一些巧妙的规定。

### **8.3 DHCP协议**

首先，它是一种应用层协议，建立在UDP协议之上，所以整个数据包是这样的：

![img](http://pic.nexopera.tech/62db55b9b98c9.png)

　　（1）最前面的"以太网标头"，设置发出方（本机）的MAC地址和接收方（DHCP服务器）的MAC地址。前者就是本机网卡的MAC地址，后者这时不知道，就填入一个广播地址：FF-FF-FF-FF-FF-FF。

　　（2）后面的"IP标头"，设置发出方的IP地址和接收方的IP地址。这时，对于这两者，本机都不知道。于是，发出方的IP地址就设为0.0.0.0，接收方的IP地址设为255.255.255.255。

　　（3）最后的"UDP标头"，设置发出方的端口和接收方的端口。这一部分是DHCP协议规定好的，发出方是68端口，接收方是67端口。

这个数据包构造完成后，就可以发出了。以太网是广播发送，同一个子网络的每台计算机都收到了这个包。因为接收方的MAC地址是FF-FF-FF-FF-FF-FF，看不出是发给谁的，所以每台收到这个包的计算机，还必须分析这个包的IP地址，才能确定是不是发给自己的。当看到发出方IP地址是0.0.0.0，接收方是255.255.255.255，于是DHCP服务器知道"这个包是发给我的"，而其他计算机就可以丢弃这个包。

接下来，DHCP服务器读出这个包的数据内容，分配好IP地址，发送回去一个"DHCP响应"数据包。这个响应包的结构也是类似的，以太网标头的MAC地址是双方的网卡地址，IP标头的IP地址是DHCP服务器的IP地址（发出方）和255.255.255.255（接收方），UDP标头的端口是67（发出方）和68（接收方），分配给请求端的IP地址和本网络的具体参数则包含在Data部分。

新加入的计算机收到这个响应包，于是就知道了自己的IP地址、子网掩码、网关地址、DNS服务器等等参数。

### **8.4 上网设置：小结**

这个部分，需要记住的就是一点：不管是"静态IP地址"还是"动态IP地址"，电脑上网的首要步骤，是确定四个参数。这四个值很重要，值得重复一遍：

> 　　  * 本机的IP地址
> 　　  * 子网掩码
> 　　  * 网关的IP地址
> 　　  * DNS的IP地址

有了这几个数值，电脑就可以上网"冲浪"了。接下来，我们来看一个实例，当用户访问网页的时候，互联网协议是怎么运作的。

## **九、一个实例：访问网页**

### **9.1 本机参数**

我们假定，经过上一节的步骤，用户设置好了自己的网络参数：

> 　　  * 本机的IP地址：192.168.1.100
> 　　  * 子网掩码：255.255.255.0
> 　　  * 网关的IP地址：192.168.1.1
> 　　  * DNS的IP地址：8.8.8.8

然后他打开浏览器，想要访问Google，在地址栏输入了网址：www.google.com。

![img](http://pic.nexopera.tech/62db55baa62c3.png)

这意味着，浏览器要向Google发送一个网页请求的数据包。

### **9.2 DNS协议**

我们知道，发送数据包，必须要知道对方的IP地址。但是，现在，我们只知道网址www.google.com，不知道它的IP地址。

[DNS协议](https://blog.nexopera.tech/post/54)可以帮助我们，将这个网址转换成IP地址。已知DNS服务器为8.8.8.8，于是我们向这个地址发送一个DNS数据包（53端口）。

![img](http://pic.nexopera.tech/62db55ba9a304.png)

然后，DNS服务器做出响应，告诉我们Google的IP地址是172.194.72.105。于是，我们知道了对方的IP地址。

### **9.3 子网掩码**

接下来，我们要判断，这个IP地址是不是在同一个子网络，这就要用到子网掩码。

已知子网掩码是255.255.255.0，本机用它对自己的IP地址192.168.1.100，做一个二进制的AND运算（两个数位都为1，结果为1，否则为0），计算结果为192.168.1.0；然后对Google的IP地址172.194.72.105也做一个AND运算，计算结果为172.194.72.0。这两个结果不相等，所以结论是，Google与本机不在同一个子网络。

因此，我们要向Google发送数据包，必须通过网关192.168.1.1转发，也就是说，接收方的MAC地址将是网关的MAC地址。

### **9.4 应用层协议**

浏览网页用的是HTTP协议，它的整个数据包构造是这样的：

![img](http://pic.nexopera.tech/62db55bad9a9b.png)

HTTP部分的内容，类似于下面这样：

> 　　　　GET / HTTP/1.1
> 　　　　Host: www.google.com
> 　　　　Connection: keep-alive
> 　　　　User-Agent: Mozilla/5.0 (Windows NT 6.1) ......
> 　　　　Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
> 　　　　Accept-Encoding: gzip,deflate,sdch
> 　　　　Accept-Language: zh-CN,zh;q=0.8
> 　　　　Accept-Charset: GBK,utf-8;q=0.7,*;q=0.3
> 　　　　Cookie: ... ...

我们假定这个部分的长度为4960字节，它会被嵌在TCP数据包之中。

**9.5 TCP协议**

TCP数据包需要设置端口，接收方（Google）的HTTP端口默认是80，发送方（本机）的端口是一个随机生成的1024-65535之间的整数，假定为51775。

TCP数据包的标头长度为20字节，加上嵌入HTTP的数据包，总长度变为4980字节。

### **9.6 IP协议**

然后，TCP数据包再嵌入IP数据包。IP数据包需要设置双方的IP地址，这是已知的，发送方是192.168.1.100（本机），接收方是172.194.72.105（Google）。

IP数据包的标头长度为20字节，加上嵌入的TCP数据包，总长度变为5000字节。

### **9.7 以太网协议**

最后，IP数据包嵌入以太网数据包。以太网数据包需要设置双方的MAC地址，发送方为本机的网卡MAC地址，接收方为网关192.168.1.1的MAC地址（通过ARP协议得到）。

以太网数据包的数据部分，最大长度为1500字节，而现在的IP数据包长度为5000字节。因此，IP数据包必须分割成四个包。因为每个包都有自己的IP标头（20字节），所以四个包的IP数据包的长度分别为1500、1500、1500、560。

![img](http://pic.nexopera.tech/62db55bba7bc6.png)

### **9.8 服务器端响应**

经过多个网关的转发，Google的服务器172.194.72.105，收到了这四个以太网数据包。

根据IP标头的序号，Google将四个包拼起来，取出完整的TCP数据包，然后读出里面的"HTTP请求"，接着做出"HTTP响应"，再用TCP协议发回来。

本机收到HTTP响应以后，就可以将网页显示出来，完成一次网络通信。

![img](http://pic.nexopera.tech/62db55bb68796.jpg)

这个例子就到此为止，虽然经过了简化，但它大致上反映了互联网协议的整个通信过程。

互联网协议入门（二）

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