计算机网络面试题目

> 考研复习这门课时候，我认为我对计算机网络理解已经比较深了，但是现在回过头来看，随便挑一个概念，让我详细讲解，我也无法**有条理讲的清楚**。于是，有了这篇笔记，就是让自己在理解基础上，直接背下来的。

> 面试提问最多是网络层，其次传输层，最后应用层，最最后数据链路层。物理层问的比较少，都是信号的编码和信道带宽之类问题，比较重要就是香农定理和奈圭斯特定理。下面笔记按照**问题频率**进行排序。

## 综合

### 1. 3种对计算机网络层次的划分

#### 教材上的5层划分

物理层、数据链路层、网络层、传输层、应用层。

#### TCP/IP 4层

把物理层和数据链路层合并成**网络接口层**。
即：网络接口层、网络层、传输层、应用层。

#### OSI 7层

在应用层下面加了两层：会话层、表示层。

**会话层**用来维持、管理双方会话的。
**表示层**就是名字表面的意思，对数据表示，即对数据的格式转换。

即 物理层、数据链路层、网络层、传输层、会话层、表示层、应用层。

### 2. 简单描述网络过程中发送方、接收方各个层的工作

* 发送方
  * **应用层**：客户端通过DNS解析系统获取百度的ip地址`220.181.27.48`，发起http会话，即发送http报文
  * **传输层**：
    * UDP对上层数据不会拆分、合并，只会加上端口号即可。
    * TCP将上层数据看成字节流，根据接收对方的接收窗口，将字节流打包成多个TCP段（把上层数据填入TCP，并填入源端口和目标端口80）
  * **网络层**：IP层将上层留下来的TCP段作为IP报文的数据部分，并填入源ip地址和目标ip地址(`220.181.27.48`)。
  * **数据链路层**：将ip报文段作为数据部分，并填写源mac地址，和目标mac地址(**ARP协议**将目标ip转换成mac地址)，组成mac帧。
  * **物理层**：将mac帧的数字信号进行**编码（转换成另一种形式的）或者调制（转换成模拟信息）**
* 接收方
  * **物理层**：模拟信号/数字信号会转换成比特流。
  * **数据链路层**：**比特流成帧的方法**。
  * **网络层**：去掉下层mac帧的头部，数据部分即为ip数据报。
  * **传输层**：去掉ip数据报头部，数据爆粉即为TCP段/UDP报文，这里可以看到目标端口号，于是把数据传输到指定端口的进程
  * **应用层：**应用程序(服务器)收到数据，进行处理，如果是http，则会根据请求保护返回响应报文。

这里还有一个**路由选择协议**，即发送方发出的包会经过很多路由，这里没有展开。

*可以看到其实接收方发送数据的mac帧的数据部分，其实是上层一层一层封装，里面包含很多信息，比如ip地址、端口号、应用层数据。*

### 3. 梳理所有常见的网络协议

* 数据链路层：ARP MAC PPP
* 网络层 ：ip，路由选择协议（RIP,OSPF,BGP），ICMP协议，IGMP协议(多播路由选择协议)，
* 传输层：TCP UDP
* 应用层：HTTP ，HTTPS ，FTP

## 网络层

### 1.  ip地址分类

#### ip地址

ip地址分类由于历史原因，一开始**固定分类ip**，再变成**子网划分**，再变成**无分类编址**。但是子网划分一开始提出来是和固定分类ip绑定使用的，实际上无分类编址也可以子网划分。

这些不断变化的原因是这样的：

一开始，设计者大脑很简单，没几台电脑。把ip地址分为<网络号，主机号>。设计初衷是我看到一个ip地址，就能直接看出来网络号。怎么实现呢？很简单呀，网络号固定的几种类型，互相不包含就可以了。

> A类：网络号0    ip范围：0.x.x.x ~ 127.x.x.x
> B类：网络号10  ip范围：128.0.x.x ~ 191.255.x.x 
> C类：网络号110 ip范围：192.0.0.x ~ 223.255.255.x
> D类：网络号1110 ip范围：224.0.0.0 ~ 239.255.255.255
> E类：网络号1111 ip范围：240.0.0.0~255.255.255.254 (保留地址)

想法很好，但是每一类网络号包含的主机数目不一样，AB类包含主机数目太多，网络号没几个。C类网络号多，但是大家都是贪心的，大家都想要B类网络号，有备无患嘛。

这还得了，随着网络发展，ip地址一下子不够用了。然后设计者就说，这样吧，你们现在申请网络号，**不再给独立的网络号给你**，而是给你分配独立网络号下面的子网络号。其实就是把主机号拿出几位作为子网络号。但是给我一个ip地址，我看不出来子网号有几位呀。所以才设计了**子网掩码**，子网掩码位数和ip位数一样，主机号前面都是1，主机号对应位置都是0，就是**ip+子网掩码模式**。

---

尽管这样，ip数目还是不够用，根本原因在于**分配方式不灵活，饿的饿死，饱的撑死**。有的人拿着B类有恃无恐，可结果根本主机没几个。

设计者心想，我都设计出子网掩码了，干嘛还是固定网络号的类型呢？当初固定类型不就是为了直接看出网络号位数嘛，现在可以通过子网掩码看出网络位数。

所以，又把ip设计成**无分类编址**，你主机有多少个，我给你网络号分配的就长一点。按需分配。

除了分配更灵活还有一个好处。我们知道我们的互联网，并不是说连到中国电信就完事了，中国电信也要连接到美国的专门互联网组织。所以可想而知，美国互联网组织的路由表项数目有多大。无分类编址可以适当的将多个同一地区的网络号进行聚合，减少表项。(这部分有机会展开写写)

**无分类编址好处有两个**：

* 分配方式更灵活，减少浪费
* 减少路由表的表项，路由聚合

---

#### 特殊ip地址

* 255.255.255.255 当前网络广播

* 0.0.0.0 做目标ip，用在默认路由项中，做源ip用在DHCP获取Ip地址过程中

#### 专用网ip地址

* 10.x.x.x/8

* 172.16.x.x/12 (172.16.x.x ~172.31.x.x)
* 192.168.x.x/16

## 传输层

### 1. TCP和UDP的区别？

* 从定义上看
TCP提供面向连接的、可靠的数据流传输，TCP面向字节流。
而UDP提供的是非面向连接的、不可靠的数据流传输。UDP面向报文。

* 从性能上看
TCP注重数据安全性，数据传输慢
UDP数据传输快，因为不需要连接等待，少了许多操作，但是其安全性却一般。

### 2. 简述TCP3次握手过程

> ⏱ 这个时钟符号表示自动重传计时器，时长为1MSL（最长报文时间）。在计时器时间范围内没有收到确认会再次发起请求。有这个符号的都表示该包为请求包(只有请求包才会要求确认)

**简单描述：- 在吗？⏱ - 在的，你在吗？⏱ - 好的，我也在。建立连接完毕。**

先贴一张TCP段的结构图：

![](https://www.ihewro.com/usr/uploads/sina/5cc07eb1edfa7.jpg)

**简单介绍一些上图相关字段：**

* ACK：为1表明该段是确认段
* SYN：为1表示该段是请求连接(请求连接和确认不冲突的，可以同时为1)
* FIN：为1表示请求终止连接
* seq：序号
* Acknumber：确认序号

> 确认序号和序号关系

A 给 B 发包，序号为x，数据长度为y

那么B的序号为z，确认序号为x+y+1

序号都是自己分配和对方无关

确认序号是对对方发送数据的最后一个字节确认。为什么要加1，这是**规定**，A收到B的确认号为x+y+1确认包，下次A发送给B的序号就是x+y+1。

**序号虽然是发送方自己随心所欲分配的，但是给接收方连续发送数据时，序号必须连续的（A下个包序号是x+y+1的原因），因为发送方的序号作用有两个：一、让接收方标识不同的数据包。二、从序号的连续性知道数据的连续性。**

---

3次握手更准确是**三报文握手**，因为双方一共发了3个报文段。

请求方：发送请求包SYN=1

接收方：发送确认+同样请求包SYN=1 ACK=1

请求方：发送确认包 SYN=0 ACK=1

**请求方最后一次的确认包是可以顺便携带数据的。**

#### 两报文握手可以吗？为什么？

**简单描述：- A在吗？- B在的。建立连接完毕。**

我们聊天中，这种方式显然不行。B回在的，A早下线了，B不是白白在等A说话嘛。

但是TCP建立我们聊天不一样原因，在于A会一直问在吗？直到B回复。**A不会下线**。但是为什么还是不行呢？

原因就在于A一直问在吗，在吗。**有可能某个`在吗`的请求包逗留在网络中**。A、B建立连接成功，传输完成数据并且断开连接了，但是此时这个请求包才被B接收到。这个时候其实A已经下线了。出现我们聊天时候出现的干等的问题。

即为了防止 **已失效的链接请求报文突然又传送到了服务端**，因而产生错误。

### 3. 简述TCP4次挥手过程

**简单描述：- A 我要下线了⏱ - B好的  -B还可以给A发送数据  -B 我也下线了吧，晚安，你也要给我说晚安。 ⏱ -A⏰⏰ 晚安（不是请求包）**

> ⏰⏰表示时间等待计时器，超过时间后，不是重发，而是直接结束自己的连接

请求方：请求终止连接 FIN =1 ACK =0

接收方：发送确认包 FIN = 0 ACK = 1

接收方恬不知耻的发送数据中……

接收方：发送请求终止连接 FIN = 1 ACK = 0

接收方：FIN = 0 ACK = 1

仔细想一下，本来TCP释放连接3报文就可以了，就是因为接收方"恬不知耻"，别人都说要睡觉下线，你直接说你也下线了，再要求一个晚安不就可以了，但是接收方还是要哔哔……

#### 最后发送方为什么要设置时间等待计时器？

B要求A给一个晚安，A说了晚安了就下线了，但是网络不好，B没收到……B还睡不睡觉了！(过分，A又不理我，一定是玩王者荣耀去了！)

所以A就等一下嘛。为什么要等2MSL时间呢？正常情况下1MSL，B能收到A的信息。

但是如果B没收到信息，从A给B发晚安超时(1MSL) 加上 B给A再次请求晚安信息(最多是1MSL) 一共是2MSL，即2MSL，A一定是可以收到B的再次请求信息的。这样的话A就再发一次。

超过2MSL，A都没收到请求信息，说明B肯定是收到晚安了，让他梦里美去吧，A也要下线，打开王者荣耀了。

### 4. 说说TCP拥塞控制

一般网上资料都是说四个算法：慢开始、拥塞控制、快重传、快恢复。

我觉得这种说法让人很迷惑。

实际上**快重传不能算算法**，快重传只是对接收方什么时候发送确认数据做了一个**规定**，事实上在整个拥塞控制中都要求接收方进行快重传。

#### 快重传

快重传要求接收方在收到一个 **失序的报文段** 后就立即发出 **累计确认**（累计确认即发送当前有序序列的最后一个序号）而不要**等到自己发送数据时捎带确认**。

>  为什么要这种规定呢？

就是为了**区分发送方丢失包是因为网络堵塞还是意外丢失的**。

如果网络堵塞就需要切换算法，如果是意外丢失只要重发意外丢失的包就可以了。

>  为什么可以区分呢？

发送方在发送每个包的时候都会设置**重传计时器（ARQ）**，如果ARQ超时则认为网络堵塞导致丢包。

举个例子：

发送方发出了A1A2A3A4A5A6 这5个数据包，但是A3意外丢失了(不是网络堵塞)。接收方接收到了A1A2A4A5A6。接收A4时候此时接受方发现是无序的了，就会发送A2确认包，同理接收A5A6，也会立即发送A2确认包。

接收方在A3的**计时器超时之前**能够收到3个A2确认包（因为网络没堵塞，理论上是可以收到3次确认的），就知道A3丢失了，所以重发A3。然后执行**快恢复算法**。

#### 慢开始

慢开始的慢指的是一开始起始点慢，但它的增长速度却极快。

---

先说明几个概念：

* 发送方的发送窗口swnd = min{拥塞窗口cwnd，接收方的接收窗口rwnd}

我们这里都假设接收窗口无限大，所以发送窗口=拥塞窗口

* **ssthresh**拥塞窗口的门限，超过门限就要切换成**拥塞避免算法**
* **传输轮次**：发送方发送完发送窗口大小的数据到接收到接收方对最后一个字节的累计确认结束。
* 为了简化说明，我们这里**窗口大小单位**是MSS(最大TCP报文段数据部分长度)，而不是字节。

---

一开始cwnd = 1

**每个传输轮次，cwnd = cwnd \*2，直至到达ssthresh拥塞窗口门限。**

#### 拥塞避免算法

名字也能猜到意思了。就是慢开始太快了，TCP害怕照你这么增长速度那还得了，所以放慢速度，即**拥塞避免**。

**每个传输轮次，cwnd = cwnd + 1。**

#### 快恢复

网络传输过程中肯定会发生丢包的情况。

第一种情况就是**快重传**里面说的，意外丢包，这个时候执行快恢复。

即重新开始**拥塞避免算法，ssthresh拥塞门限值 = cwnd/2    cwnd = ssthresh。**

#### 总结

TCP传输数据算法：慢开始+ 拥塞避免

出现丢包：

* 意外丢包：(通过快重传的方式检测到的)快恢复
* 网络堵塞导致丢包：重弄下开始慢开始，ssthresh = cwnd/2   cwnd = 1

## 应用层

### 1. 简单描述HTTP的报文结构

http报文分为**请求报文**和**响应报文**。
两者都分为三个部分：**开始行**、**首部行**、**实体主体行**。

![请求报文](https://www.ihewro.com/usr/uploads/sina/5cc07eb2a4de4.jpg)
*请求报文*

![相应报文](https://www.ihewro.com/usr/uploads/sina/5cc07eb2b3555.jpg)
*响应报文*

#### 开始行

请求报文的开始行重点是**请求方法**
响应报文的开始行重点是**状态码**

> 请求方法[^request]

- GET：对服务器资源的简单请求
- POST：用于发送包含用户提交数据的请求

------------以及------------

- HEAD：类似于GET请求，不过返回的响应中没有具体内容，用于获取报头
- PUT：传说中请求文档的一个版本
- DELETE：发出一个删除指定文档的请求
- TRACE：发送的请求，会经过中间的代理，最终的目标服务器返回响应报文会在响应实体部分填写**它从代理发给他的请求报文内容**[^trace]，并且每经过一个代理，报文的首部部分都会增加`via`字段，标识当前经过的代理地址。**该trace方法可以用来跟踪请求的处理过程。**
- OPTIONS：返回所有可用的方法，检查服务器支持哪些方法
- CONNECT：用于ssl隧道的基于代理的请求

> 状态码[^statuscode]

![](https://www.ihewro.com/usr/uploads/sina/5cc07eb2df596.jpg)

#### 首部行

首部行就是一行就是一个键值对。键名是首部字段名称，值就是首部字段的值。

下图是一个完整的关于所有首部的介绍。[^pic]

![](https://www.ihewro.com/usr/uploads/sina/5cc07eb2ee7d2.jpg)

#### 实体主体行

HTTP 报文的第三部分是可选的实体主体部分。实体的主体是 HTTP 报文的负荷。 就是 HTTP 要传输的内容。

HTTP 报文可以承载很多类型的数字数据:图片、视频、HTML 文档、软件应用程 序、信用卡事务、电子邮件等。[^实体]

### 2. GET和POST区别

从规范上看：

- 根据HTTP规范，GET用于信息获取，而且应该是安全和幂等的
- 根据HTTP规范，POST请求表示可能修改服务器上资源的请求

从安全性看：

- GET请求的数据会附在URL后面，POST的数据放在HTTP包体
- POST安全性比GET安全性高

### 3. 简述DNS解析过程

以解析www.ihewro.com 地址为例：

---

先介绍几个概念：

* 区和域的概念

我们知道域名结构是一个树状结构：

![](https://www.ihewro.com/usr/uploads/sina/5cc07ebbc928d.jpg)

DNS域名服务器最小单位是区，什么意思呢？比如上图中，cn顶级域名有一个DNS服务器，我如果规定tsinghua节点(且包括下属分支节点)为一个区的话，它下面的mail节点就不会设立域名服务器了。

* 域名服务器
  域名服务器存储是就是域名和ip映射的键值对。对域设立的DNS服务器的映射只包括子域/区，对于下一级的下一级节点的映射关系则不用管。**对区设立的DNS服务器要包括下属所有节点的映射。**(因为区是最小的服务器设立单位)
  * 本地域名服务器，
    * 包括**缓存**的域名ip映射和所有的**根域名服务器**的ip(根域名服务器也是很多个)
    * 本地计算机**第一个寻找DNS服务器**，一般计算机网络管理都会设置本地域名服务器的ip（比如`114.114.114.114`）。
  * 根域名服务器：
    * 包括所有的顶级域名的DNS域名服务器ip
  * 顶级域名服务器
    * 包括在该顶级域名服务器下注册的**顶级域名映射关系**，比如com的域名服务器里面就存储了`ihewro->125.21.1.1`这样的键值对
  * 权限域名服务器
    * 包括该域名**下属二级域名的映射关系**，比如`ihewro.com` 权限域名服务器里面就存储了`www->125.21.1.1`这样的映射关系
  * 区域域名服务器
    * 包括该域名下属**三级域名的映射关系**，比如`blog.ihewro.com`区域域名服务器就存储了`image->125.21.1.1`这样的映射关系

但事实上，我们可以只需要`ihewro.com`权限域名服务器就可以了，该权限域名服务器存储下属二级、三级等等所有节点的映射关系，即将`ihewro`这个节点及下属节点设置为一个区。

----

所以访问www.ihewro.com过程如下：

* 递归查询：本地服务器没查到映射，**根域名服务器**向顶级域名服务器请求，**顶级域名服务器**再向权限域名服务器请求，权限域名服务器查到了，再一层层向上返回。
* 迭代查询：本地服务器没查到，根域名服务器向本地服务器返回顶级域名服务器ip，**本地域名服务器**向顶级域名服务器请求，顶级域名服务器返回权限域名服务器ip，**本地域名服务器**再想权限域名服务器请求，查到了直接返回结果。

### 4. TCP和UDP分别对应的常见应用层协议

* TCP对应的应用层协议
  * FTP：定义了文件传输协议，使用21端口。常说某某计算机开了FTP服务便是启动了文件传输服务。下载文件，上传主页，都要用到FTP服务。
  * SMTP：定义了简单邮件传送协议，现在很多邮件服务器都用的是这个协议，用于发送邮件。如常见的免费邮件服务中用的就是这个邮件服务端口，所以在电子邮件设置-中常看到有这么SMTP端口设置这个栏，服务器开放的是25号端口。

* POP3：它是和SMTP对应，POP3用于接收邮件。通常情况下，POP3协议所用的是110端口。也是说，只要你有相应的使用POP3协议的程序（例如Fo-xmail或Outlook），就可以不以Web方式登陆进邮箱界面，直接用邮件程序就可以收到邮件（如是163邮箱就没有必要先进入网易网站，再进入自己的邮-箱来收信）。
  * HTTP：从Web服务器传输超文本到本地浏览器的传送协议。

* UDP对应的应用层协议
  * DNS：用于域名解析服务，将域名地址转换为IP地址。DNS用的是53号端口。
  * TFTP(Trival File Transfer Protocal)：简单文件传输协议，该协议在熟知端口69上使用UDP服务。

## 数据链路层

### 1. ARP协议的原理

ARP协议是ip到mac地址的映射。它是对整个局域网的ip到mac地址的映射。局域网内的每台主机和路由器都有ARP表。

> 那目标ip不是在当前局域网内怎么办？

查询路由表，将mac地址修改为下一跳路由器的mac地址。然后任务就转交给下一跳路由器了嘛。下一条路由器看这个包的目标Ip是不是在当前局域网，如果是，直接插到ARP表即可。不是，再转交给吓一跳路由器。

> 目标ip是在局域网，但是ARP表中没有映射关系怎么办？

当前主机发送广播**ARP请求分组**(目标ip为255.255.255.255，分组内容为要发送的目标ip)，局域网内所有设备，收到这个分组后，比对自己的ip和请求的目标ip，如果相同，则发送**ARP响应分组**（普通单播，分组内容为自己的mac地址）。

## 参考文章

https://blog.csdn.net/justloveyou_/article/details/78303617

[^Pic]: https://www.jianshu.com/p/a2c4ede32d11Pic

[^实体]: https://segmentfault.com/a/1190000014179106#articleHeader6

[^statuscode]: https://segmentfault.com/a/1190000013286569
[^request]: https://zhuanlan.zhihu.com/p/24001696
[^trace]: https://segmentfault.com/a/1190000014179106#articleHeader12

考研复习这门课时候，我认为我对计算机网络理解已经比较深了，但是现在回过头来看，随便挑一个概念，让我详细讲解，我也无法有条理讲的清楚。于是，有了这篇笔记，就是让自己在理解基础上，直接背下来的。
面试提问最多是网络层，其次传输层，最后应用层，最最后数据链路层。物理层问的比较少，都是信号的编码和信道带宽之类问题，比较重要就是香农定理和奈圭斯特定理。下面笔记按照问题频率进行排序。

综合

1. 3种对计算机网络层次的划分

教材上的5层划分

物理层、数据链路层、网络层、传输层、应用层。

TCP/IP 4层

把物理层和数据链路层合并成网络接口层。
即：网络接口层、网络层、传输层、应用层。

OSI 7层

在应用层下面加了两层：会话层、表示层。

会话层用来维持、管理双方会话的。
表示层就是名字表面的意思，对数据表示，即对数据的格式转换。

即物理层、数据链路层、网络层、传输层、会话层、表示层、应用层。

2. 简单描述网络过程中发送方、接收方各个层的工作

发送方
- 应用层：客户端通过DNS解析系统获取百度的ip地址220.181.27.48，发起http会话，即发送http报文
- 传输层：
  - UDP对上层数据不会拆分、合并，只会加上端口号即可。
  - TCP将上层数据看成字节流，根据接收对方的接收窗口，将字节流打包成多个TCP段（把上层数据填入TCP，并填入源端口和目标端口80）
- 网络层：IP层将上层留下来的TCP段作为IP报文的数据部分，并填入源ip地址和目标ip地址(220.181.27.48)。
- 数据链路层：将ip报文段作为数据部分，并填写源mac地址，和目标mac地址(ARP协议将目标ip转换成mac地址)，组成mac帧。
- 物理层：将mac帧的数字信号进行编码（转换成另一种形式的）或者调制（转换成模拟信息）
接收方
- 物理层：模拟信号/数字信号会转换成比特流。
- 数据链路层：比特流成帧的方法。
- 网络层：去掉下层mac帧的头部，数据部分即为ip数据报。
- 传输层：去掉ip数据报头部，数据爆粉即为TCP段/UDP报文，这里可以看到目标端口号，于是把数据传输到指定端口的进程
- 应用层：应用程序(服务器)收到数据，进行处理，如果是http，则会根据请求保护返回响应报文。

这里还有一个路由选择协议，即发送方发出的包会经过很多路由，这里没有展开。

可以看到其实接收方发送数据的mac帧的数据部分，其实是上层一层一层封装，里面包含很多信息，比如ip地址、端口号、应用层数据。

3. 梳理所有常见的网络协议

数据链路层：ARP MAC PPP
网络层：ip，路由选择协议（RIP,OSPF,BGP），ICMP协议，IGMP协议(多播路由选择协议)，
传输层：TCP UDP
应用层：HTTP ，HTTPS ，FTP

网络层

1. ip地址分类

ip地址

ip地址分类由于历史原因，一开始固定分类ip，再变成子网划分，再变成无分类编址。但是子网划分一开始提出来是和固定分类ip绑定使用的，实际上无分类编址也可以子网划分。

这些不断变化的原因是这样的：

A类：网络号0 ip范围：0.x.x.x ~ 127.x.x.x
B类：网络号10 ip范围：128.0.x.x ~ 191.255.x.x
C类：网络号110 ip范围：192.0.0.x ~ 223.255.255.x
D类：网络号1110 ip范围：224.0.0.0 ~ 239.255.255.255
E类：网络号1111 ip范围：240.0.0.0~255.255.255.254 (保留地址)

这还得了，随着网络发展，ip地址一下子不够用了。然后设计者就说，这样吧，你们现在申请网络号，不再给独立的网络号给你，而是给你分配独立网络号下面的子网络号。其实就是把主机号拿出几位作为子网络号。但是给我一个ip地址，我看不出来子网号有几位呀。所以才设计了子网掩码，子网掩码位数和ip位数一样，主机号前面都是1，主机号对应位置都是0，就是ip+子网掩码模式。

尽管这样，ip数目还是不够用，根本原因在于分配方式不灵活，饿的饿死，饱的撑死。有的人拿着B类有恃无恐，可结果根本主机没几个。

所以，又把ip设计成无分类编址，你主机有多少个，我给你网络号分配的就长一点。按需分配。

无分类编址好处有两个：

分配方式更灵活，减少浪费
减少路由表的表项，路由聚合

特殊ip地址

255.255.255.255 当前网络广播
0.0.0.0 做目标ip，用在默认路由项中，做源ip用在DHCP获取Ip地址过程中

专用网ip地址

10.x.x.x/8
172.16.x.x/12 (172.16.x.x ~172.31.x.x)
192.168.x.x/16

传输层

1. TCP和UDP的区别？

从定义上看
TCP提供面向连接的、可靠的数据流传输，TCP面向字节流。
而UDP提供的是非面向连接的、不可靠的数据流传输。UDP面向报文。
从性能上看
TCP注重数据安全性，数据传输慢
UDP数据传输快，因为不需要连接等待，少了许多操作，但是其安全性却一般。

2. 简述TCP3次握手过程

⏱ 这个时钟符号表示自动重传计时器，时长为1MSL（最长报文时间）。在计时器时间范围内没有收到确认会再次发起请求。有这个符号的都表示该包为请求包(只有请求包才会要求确认)

简单描述：- 在吗？⏱ - 在的，你在吗？⏱ - 好的，我也在。建立连接完毕。

先贴一张TCP段的结构图：

简单介绍一些上图相关字段：

ACK：为1表明该段是确认段
SYN：为1表示该段是请求连接(请求连接和确认不冲突的，可以同时为1)
FIN：为1表示请求终止连接
seq：序号
Acknumber：确认序号

确认序号和序号关系

A 给 B 发包，序号为x，数据长度为y

那么B的序号为z，确认序号为x+y+1

序号都是自己分配和对方无关

确认序号是对对方发送数据的最后一个字节确认。为什么要加1，这是规定，A收到B的确认号为x+y+1确认包，下次A发送给B的序号就是x+y+1。

序号虽然是发送方自己随心所欲分配的，但是给接收方连续发送数据时，序号必须连续的（A下个包序号是x+y+1的原因），因为发送方的序号作用有两个：一、让接收方标识不同的数据包。二、从序号的连续性知道数据的连续性。

3次握手更准确是三报文握手，因为双方一共发了3个报文段。

请求方：发送请求包SYN=1

接收方：发送确认+同样请求包SYN=1 ACK=1

请求方：发送确认包 SYN=0 ACK=1

请求方最后一次的确认包是可以顺便携带数据的。

两报文握手可以吗？为什么？

简单描述：- A在吗？- B在的。建立连接完毕。

我们聊天中，这种方式显然不行。B回在的，A早下线了，B不是白白在等A说话嘛。

但是TCP建立我们聊天不一样原因，在于A会一直问在吗？直到B回复。A不会下线。但是为什么还是不行呢？

原因就在于A一直问在吗，在吗。有可能某个在吗的请求包逗留在网络中。A、B建立连接成功，传输完成数据并且断开连接了，但是此时这个请求包才被B接收到。这个时候其实A已经下线了。出现我们聊天时候出现的干等的问题。

即为了防止 已失效的链接请求报文突然又传送到了服务端，因而产生错误。

3. 简述TCP4次挥手过程

简单描述：- A 我要下线了⏱ - B好的 -B还可以给A发送数据 -B 我也下线了吧，晚安，你也要给我说晚安。 ⏱ -A⏰⏰ 晚安（不是请求包）

⏰⏰表示时间等待计时器，超过时间后，不是重发，而是直接结束自己的连接

请求方：请求终止连接 FIN =1 ACK =0

接收方：发送确认包 FIN = 0 ACK = 1

接收方恬不知耻的发送数据中……

接收方：发送请求终止连接 FIN = 1 ACK = 0

接收方：FIN = 0 ACK = 1

最后发送方为什么要设置时间等待计时器？

B要求A给一个晚安，A说了晚安了就下线了，但是网络不好，B没收到……B还睡不睡觉了！(过分，A又不理我，一定是玩王者荣耀去了！)

所以A就等一下嘛。为什么要等2MSL时间呢？正常情况下1MSL，B能收到A的信息。

超过2MSL，A都没收到请求信息，说明B肯定是收到晚安了，让他梦里美去吧，A也要下线，打开王者荣耀了。

4. 说说TCP拥塞控制

一般网上资料都是说四个算法：慢开始、拥塞控制、快重传、快恢复。

我觉得这种说法让人很迷惑。

实际上快重传不能算算法，快重传只是对接收方什么时候发送确认数据做了一个规定，事实上在整个拥塞控制中都要求接收方进行快重传。

快重传

快重传要求接收方在收到一个 失序的报文段 后就立即发出 累计确认（累计确认即发送当前有序序列的最后一个序号）而不要等到自己发送数据时捎带确认。

为什么要这种规定呢？

就是为了区分发送方丢失包是因为网络堵塞还是意外丢失的。

如果网络堵塞就需要切换算法，如果是意外丢失只要重发意外丢失的包就可以了。

为什么可以区分呢？

发送方在发送每个包的时候都会设置重传计时器（ARQ），如果ARQ超时则认为网络堵塞导致丢包。

举个例子：

接收方在A3的计时器超时之前能够收到3个A2确认包（因为网络没堵塞，理论上是可以收到3次确认的），就知道A3丢失了，所以重发A3。然后执行快恢复算法。

慢开始

慢开始的慢指的是一开始起始点慢，但它的增长速度却极快。

先说明几个概念：

发送方的发送窗口swnd = min{拥塞窗口cwnd，接收方的接收窗口rwnd}

我们这里都假设接收窗口无限大，所以发送窗口=拥塞窗口

ssthresh拥塞窗口的门限，超过门限就要切换成拥塞避免算法
传输轮次：发送方发送完发送窗口大小的数据到接收到接收方对最后一个字节的累计确认结束。
为了简化说明，我们这里窗口大小单位是MSS(最大TCP报文段数据部分长度)，而不是字节。

一开始cwnd = 1

每个传输轮次，cwnd = cwnd *2，直至到达ssthresh拥塞窗口门限。

拥塞避免算法

名字也能猜到意思了。就是慢开始太快了，TCP害怕照你这么增长速度那还得了，所以放慢速度，即拥塞避免。

每个传输轮次，cwnd = cwnd + 1。

快恢复

网络传输过程中肯定会发生丢包的情况。

第一种情况就是快重传里面说的，意外丢包，这个时候执行快恢复。

即重新开始拥塞避免算法，ssthresh拥塞门限值 = cwnd/2 cwnd = ssthresh。

总结

TCP传输数据算法：慢开始+ 拥塞避免

出现丢包：

意外丢包：(通过快重传的方式检测到的)快恢复
网络堵塞导致丢包：重弄下开始慢开始，ssthresh = cwnd/2 cwnd = 1

应用层

1. 简单描述HTTP的报文结构

http报文分为请求报文和响应报文。
两者都分为三个部分：开始行、首部行、实体主体行。

请求报文

相应报文
响应报文

开始行

请求报文的开始行重点是请求方法
响应报文的开始行重点是状态码

请求方法¹

GET：对服务器资源的简单请求
POST：用于发送包含用户提交数据的请求

------------以及------------

HEAD：类似于GET请求，不过返回的响应中没有具体内容，用于获取报头
PUT：传说中请求文档的一个版本
DELETE：发出一个删除指定文档的请求
TRACE：发送的请求，会经过中间的代理，最终的目标服务器返回响应报文会在响应实体部分填写它从代理发给他的请求报文内容²，并且每经过一个代理，报文的首部部分都会增加via字段，标识当前经过的代理地址。该trace方法可以用来跟踪请求的处理过程。
OPTIONS：返回所有可用的方法，检查服务器支持哪些方法
CONNECT：用于ssl隧道的基于代理的请求

状态码³

首部行

首部行就是一行就是一个键值对。键名是首部字段名称，值就是首部字段的值。

下图是一个完整的关于所有首部的介绍。⁴

实体主体行

HTTP 报文的第三部分是可选的实体主体部分。实体的主体是 HTTP 报文的负荷。就是 HTTP 要传输的内容。

HTTP 报文可以承载很多类型的数字数据:图片、视频、HTML 文档、软件应用程序、信用卡事务、电子邮件等。⁵

2. GET和POST区别

从规范上看：

根据HTTP规范，GET用于信息获取，而且应该是安全和幂等的
根据HTTP规范，POST请求表示可能修改服务器上资源的请求

从安全性看：

GET请求的数据会附在URL后面，POST的数据放在HTTP包体
POST安全性比GET安全性高

3. 简述DNS解析过程

以解析www.ihewro.com 地址为例：

先介绍几个概念：

区和域的概念

我们知道域名结构是一个树状结构：

域名服务器
域名服务器存储是就是域名和ip映射的键值对。对域设立的DNS服务器的映射只包括子域/区，对于下一级的下一级节点的映射关系则不用管。对区设立的DNS服务器要包括下属所有节点的映射。(因为区是最小的服务器设立单位)
- 本地域名服务器，
  - 包括缓存的域名ip映射和所有的根域名服务器的ip(根域名服务器也是很多个)
  - 本地计算机第一个寻找DNS服务器，一般计算机网络管理都会设置本地域名服务器的ip（比如114.114.114.114）。
- 根域名服务器：
  - 包括所有的顶级域名的DNS域名服务器ip
- 顶级域名服务器
  - 包括在该顶级域名服务器下注册的顶级域名映射关系，比如com的域名服务器里面就存储了ihewro->125.21.1.1这样的键值对
- 权限域名服务器
  - 包括该域名下属二级域名的映射关系，比如ihewro.com 权限域名服务器里面就存储了www->125.21.1.1这样的映射关系
- 区域域名服务器
  - 包括该域名下属三级域名的映射关系，比如blog.ihewro.com区域域名服务器就存储了image->125.21.1.1这样的映射关系

但事实上，我们可以只需要ihewro.com权限域名服务器就可以了，该权限域名服务器存储下属二级、三级等等所有节点的映射关系，即将ihewro这个节点及下属节点设置为一个区。

所以访问www.ihewro.com过程如下：

递归查询：本地服务器没查到映射，根域名服务器向顶级域名服务器请求，顶级域名服务器再向权限域名服务器请求，权限域名服务器查到了，再一层层向上返回。
迭代查询：本地服务器没查到，根域名服务器向本地服务器返回顶级域名服务器ip，本地域名服务器向顶级域名服务器请求，顶级域名服务器返回权限域名服务器ip，本地域名服务器再想权限域名服务器请求，查到了直接返回结果。

4. TCP和UDP分别对应的常见应用层协议

TCP对应的应用层协议
- FTP：定义了文件传输协议，使用21端口。常说某某计算机开了FTP服务便是启动了文件传输服务。下载文件，上传主页，都要用到FTP服务。
- SMTP：定义了简单邮件传送协议，现在很多邮件服务器都用的是这个协议，用于发送邮件。如常见的免费邮件服务中用的就是这个邮件服务端口，所以在电子邮件设置-中常看到有这么SMTP端口设置这个栏，服务器开放的是25号端口。
- POP3：它是和SMTP对应，POP3用于接收邮件。通常情况下，POP3协议所用的是110端口。也是说，只要你有相应的使用POP3协议的程序（例如Fo-xmail或Outlook），就可以不以Web方式登陆进邮箱界面，直接用邮件程序就可以收到邮件（如是163邮箱就没有必要先进入网易网站，再进入自己的邮-箱来收信）。
- HTTP：从Web服务器传输超文本到本地浏览器的传送协议。
UDP对应的应用层协议
- DNS：用于域名解析服务，将域名地址转换为IP地址。DNS用的是53号端口。
- TFTP(Trival File Transfer Protocal)：简单文件传输协议，该协议在熟知端口69上使用UDP服务。

数据链路层

1. ARP协议的原理

ARP协议是ip到mac地址的映射。它是对整个局域网的ip到mac地址的映射。局域网内的每台主机和路由器都有ARP表。

那目标ip不是在当前局域网内怎么办？

目标ip是在局域网，但是ARP表中没有映射关系怎么办？

当前主机发送广播ARP请求分组(目标ip为255.255.255.255，分组内容为要发送的目标ip)，局域网内所有设备，收到这个分组后，比对自己的ip和请求的目标ip，如果相同，则发送ARP响应分组（普通单播，分组内容为自己的mac地址）。

参考文章