应用层

什么是Http？（什么是协议？）

HTTP 是超文本传输协议，也就是HyperText Transfer Protocol。
HTTP 是一个在计算机世界里专门在「两点」之间「传输」文字、图片、音频、视频等「超文本」数据的「约定和规范」。

http常见的状态码？（301， 302，404, 500， 502）

HTTP状态码⾸先应该知道个⼤概的分类：
1XX：信息性状态码
2XX：成功状态码
3XX：重定向状态码
4XX：客户端错误状态码
5XX：服务端错误状态码

⼏个常⽤的，⾯试之外，也应该记住：
image.png
301：永久性移动，请求的资源已被永久移动到新位置。服务器返回此响应时，会返回新 的资源地址。
302：临时性性移动，服务器从另外的地址响应资源，但是客户端还应该使⽤这个地址。
⽤⼀个⽐喻，301就是嫁⼈的新垣结⾐，302就是有男朋友的长泽雅美。

http常见的字段有哪些？（content-Length，content-type，content-Encoding）

Host 字段：客户端发送请求时，用来指定服务器的域名。
Content-Length 字段：服务器在返回数据时，会有 Content-Length 字段，表明本次回应的数据长度。
Connection 字段：_Connection 字段最常用于客户端要求服务器使用 TCP 持久连接，以便其他请求复用。
HTTP/1.1 版本的默认连接都是持久连接，但为了兼容老版本的 HTTP，需要指定 Connection 首部字段的值为 Keep-Alive。
_Content-Type 字段：_Content-Type 字段用于服务器回应时，告诉客户端，本次数据是什么格式。
_Content-Encoding 字段：说明数据的压缩方法。表示服务器返回的数据使用了什么压缩格式

Get和Post的区别？

image.png
1 GET 在 URL中. POST 在 body（请求体） 中.
因此，GET 数据量有限，POST 数据量大小没有限制.
2 GET 符合 幂等性和安全性，POST 不符合.
因为 GET 不改变服务器上的信息，而POST 请求会改变服务器上的信息.
3 GET 请求能被缓存，如保存在浏览器浏览记录中，URL可以存于浏览器书签等.
POST 做不到这些.

：

  • GET 方法就是安全且幂等的，因为它是「只读」操作，无论操作多少次，服务器上的数据都是安全的，且每次的结果都是相同的。所以，可以对 GET 请求的数据做缓存，这个缓存可以做到浏览器本身上（彻底避免浏览器发请求），也可以做到代理上（如nginx），而且在浏览器中 GET 请求可以保存为书签。
  • POST 因为是「新增或提交数据」的操作，会修改服务器上的资源，所以是不安全的，且多次提交数据就会创建多个资源，所以不是幂等的。所以，浏览器一般不会缓存 POST 请求，也不能把 POST 请求保存为书签。

Http的优缺点

  1. http的优缺点？（简单，易学，灵活易于扩展，应用广泛跨平台）（无状态，明文传输，不安全）

    优点：「简单、灵活和易于扩展、应用广泛和跨平台」。

    1. 简单
    HTTP 基本的报文格式就是 header + body，头部信息也是 key-value 简单文本的形式，易于理解，降低了学习和使用的门槛。

2. 灵活和易于扩展
HTTP协议里的各类请求方法、URI/URL、状态码、头字段等每个组成要求都没有被固定死，都允许开发人员自定义和扩充。同时 HTTP 由于是工作在应用层（ OSI 第七层），则它下层可以随意变化。HTTPS 也就是在 HTTP 与 TCP 层之间增加了 SSL/TLS 安全传输层，HTTP/3 甚至把 TCP 层换成了基于 UDP 的 QUIC。

3. 应用广泛和跨平台
互联网发展至今，HTTP 的应用范围非常的广泛，从台式机的浏览器到手机上的各种 APP，从看新闻、刷贴吧到购物、理财、吃鸡，HTTP 的应用遍地开花，同时天然具有跨平台的优越性。

缺点：HTTP 协议里有优缺点一体的双刃剑，分别是「无状态、明文传输」，还有「不安全」。

1. 无状态双刃剑：可以用 Cookie 技术解决
无状态的好处，因为服务器不会去记忆 HTTP 的状态，所以不需要额外的资源来记录状态信息，这能减轻服务器的负担，能够把更多的 CPU 和内存用来对外提供服务。
无状态的坏处，既然服务器没有记忆能力，它在完成有关联性的操作时会非常麻烦。
对于无状态的问题，解法方案有很多种，其中比较简单的方式用 Cookie 技术。

2. 明文传输双刃剑
明文意味着在传输过程中的信息，是可方便阅读的，通过浏览器的 F12 控制台或 Wireshark 抓包都可以直接肉眼查看，为我们调试工作带了极大的便利性。
但是这正是这样，HTTP 的所有信息都暴露在了光天化日下，相当于信息裸奔。在传输的漫长的过程中，信息的内容都毫无隐私可言，很容易就能被窃取，如果里面有你的账号密码信息，那你号没了。

3. 不安全：可以用 HTTPS 的方式解决
HTTP 比较严重的缺点就是不安全：

  • 通信使用明文（不加密），内容可能会被窃听。比如，账号信息容易泄漏，那你号没了。
  • 不验证通信方的身份，因此有可能遭遇伪装。比如，访问假的淘宝、拼多多，那你钱没了。
  • 无法证明报文的完整性，所以有可能已遭篡改。比如，网页上植入垃圾广告，视觉污染，眼没了。

HTTP 的安全问题，可以用 HTTPS 的方式解决，也就是通过引入 SSL/TLS 层，使得在安全上达到了极致。

Http 与 Https

Http与Https有哪些区别？（协议，端口号）

（1）HTTP 是超文本传输协议，信息是明文传输，存在安全风险的问题。
HTTPS 则解决 HTTP 不安全的缺陷，在 TCP 和 HTTP 网络层之间加入了 SSL/TLS 安全协议，使得报文能够加密传输。
（2）HTTP 连接建立相对简单， TCP 三次握手之后便可进行 HTTP 的报文传输。
而 HTTPS 在 TCP 三次握手之后，还需进行 SSL/TLS 的握手过程，才可进入加密报文传输。
（3）HTTP 的端口号是 80，HTTPS 的端口号是 443。
HTTPS 协议需要向 CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的。

https解决了http的哪些问题？（窃听，篡改，冒充）（信息加密 + 校验机制 + 身份证书）

HTTP 由于是明文传输，所以安全上存在以下三个风险：

  • 窃听风险，比如通信链路上可以获取通信内容，用户号容易没。
  • 篡改风险，比如强制植入垃圾广告，视觉污染，用户眼容易瞎。
  • 冒充风险，比如冒充淘宝网站，用户钱容易没。

https是如何解决三个风险的？（混合加密，摘要算法，数字证书）（证书信任链问题）

  • 混合加密的方式实现信息的机密性，解决了窃听的风险。
  • 摘要算法的方式来实现完整性，它能够为数据生成独一无二的「指纹」，指纹用于校验数据的完整性，解决了篡改的风险。
  • 将服务器公钥放入到数字证书中，解决了冒充的风险。

https 是如何建立连接的？其间交互了什么？（四次握手）


SSL/TLS 协议建立的详细流程：
1. ClientHello
客户端产生随机数1，并发送给服务端

2. SeverHello
服务端产生随机数2，并发送给客户端
向客户端发送证书
证书有公钥，服务器存了配套私钥

3.客户端回应
客户端验证证书
从证书拿到了公钥
客户端生成随机数3，并向服务端发送随机数3 ==> 随机数 3 用公钥加密！（体现非对称加密）

服务器和客户端有了这三个随机数（Client Random、Server Random、pre-master key），接着就用双方协商的加密算法，各自生成本次通信的「会话秘钥」。

4. 服务器的最后回应
客户端用私钥解密，得到 第 3 个随机数 ==> 体现非对称加密
客户端，服务端均拥有 3 个随机数，用其产生会话密钥 ==> 用于对称加密
服务器收到客户端的第三个随机数（pre-master key）之后，通过协商的加密算法，计算出本次通信的「会话秘钥」。**随后的信息都将用「会话秘钥」加密通信**。

补充：SSL/TLS的四次握手，目前网上的主流答案都在重复阮一峰老师的博客，属于TLS 1.0版本的答案，使用RSA密钥交换算法。但是现在TLS 1.2已经成为主流，使用ECDHE算法，如果面试可以说出这个版本的答案，应该会更好。

加密算法：RSA 的问题在哪里？ECDHE 是做什么的？

使用 RSA 密钥协商算法的最大问题是 不支持前向保密。
因为客户端传递随机数（用于生成对称加密密钥的条件之一）给服务端时使用的是公钥加密的，服务端收到到后，会用私钥解密得到随机数。所以一旦服务端的私钥泄漏了，过去被第三方截获的所有 TLS 通讯密文都会被破解。
为了解决这个问题，后面就出现了 ECDHE 密钥协商算法，我们现在大多数网站使用的正是 ECDHE 密钥协商算法。

ECDHE 密钥协商算法是 DH 算法演进过来的。DH 算法是非对称加密算法， 因此它可以用于密钥交换，该算法的核心数学思想是离散对数。

Http1.1、Http2、Http3的演变

  1. http1.1相比http1.0性能上的改进？

（两个点：长连接，管道网络传输（请求对头阻塞，响应对头阻塞））

  1. Http2相比Http1.1做了什么优化？

（头部压缩、二进制格式、数据流、多路复用、服务器推送）

  1. Http2有哪些缺陷？Http3做了哪些优化？

（改成UDP，使用QUIC协议）（更快的连接迁移，无对头阻塞问题）

Http 1.1 如何优化

  1. 如何减少Http请求次数？（减少重定向次数，合并请求，延迟发送请求）

传输层

介绍 TCP

  1. TCP头格式 （校验和，紧急指针，可选长度）
  2. 为什么需要TCP协议？TCP工作在哪一层
  3. 什么是TCP？（面向连接，可靠地，基于字节流的）（消息边界，有序，重复丢弃）
  4. 什么是TCP连接？（可靠性和流量控制维护的某些状态信息）（socket，窗口大小，序列号）
  5. 如何唯一确定一个TCP连接？四元组

    TCP 头格式

    序列号：在建立连接时由计算机生成的随机数作为其初始值，通过 SYN 包传给接收端主机，每发送一次数据，就「累加」一次该「数据字节数」的大小。用来解决网络包乱序问题。
    确认应答号：指下一次「期望」收到的数据的序列号，发送端收到这个确认应答以后可以认为在这个序号以前的数据都已经被正常接收。用来解决丢包的问题。
    控制位：
  • ACK：该位为 1 时，「确认应答」的字段变为有效，TCP 规定除了最初建立连接时的 SYN 包之外该位必须设置为 1 。
  • RST：该位为 1 时，表示 TCP 连接中出现异常必须强制断开连接。
  • SYN：该位为 1 时，表示希望建立连接，并在其「序列号」的字段进行序列号初始值的设定。
  • FIN：该位为 1 时，表示今后不会再有数据发送，希望断开连接。当通信结束希望断开连接时，通信双方的主机之间就可以相互交换 FIN 位为 1 的 TCP 段。

计网面试题 - 图3

为什么需要 TCP 协议？ TCP 工作在哪一层？

IP 层是「不可靠」的，它不保证网络包的交付、不保证网络包的按序交付、也不保证网络包中的数据的完整性。
如果需要保障网络数据包的可靠性，那么就需要由上层（传输层）的 TCP 协议来负责。
因为 TCP 是一个工作在传输层的可靠数据传输的服务，它能确保接收端接收的网络包是无损坏、无间隔、非冗余和按序的。

什么是TCP？（面向连接，可靠地，基于字节流的）（消息边界，有序，重复丢弃）

TCP 是面向连接的、可靠的、基于字节流的传输层通信协议。
计网面试题 - 图4

  • 面向连接：一定是「一对一」才能连接，不能像 UDP 协议可以一个主机同时向多个主机发送消息，也就是一对多是无法做到的；
  • 可靠的：无论的网络链路中出现了怎样的链路变化，TCP 都可以保证一个报文一定能够到达接收端；
  • 字节流：用户消息通过 TCP 协议传输时，消息可能会被操作系统「分组」成多个的 TCP 报文，如果接收方的程序如果不知道「消息的边界」，是无法读出一个有效的用户消息的。并且 TCP 报文是「有序的」，当「前一个」TCP 报文没有收到的时候，即使它先收到了后面的 TCP 报文，那么也不能扔给应用层去处理，同时对「重复」的 TCP 报文会自动丢弃。

什么是TCP连接？（可靠性和流量控制维护的某些状态信息）（socket，窗口大小，序列号）

简单来说就是，用于保证可靠性和流量控制维护的某些状态信息，这些信息的组合，包括Socket、序列号和窗口大小称为连接。
所以我们可以知道，建立一个 TCP 连接是需要客户端与服务器端达成上述三个信息的共识。

  • Socket：由 IP 地址和端口号组成
  • 序列号：用来解决乱序问题等
  • 窗口大小：用来做流量控制

如何唯一确定一个TCP连接？四元组

TCP 四元组可以唯一的确定一个连接，四元组包括如下：

计网面试题 - 图5
源地址和目的地址的字段（32位）是在 IP 头部中，作用是通过 IP 协议发送报文给对方主机。
源端口和目的端口的字段（16位）是在 TCP 头部中，作用是告诉 TCP 协议应该把报文发给哪个进程。

对比 TCP 和 UDP

  1. UDP头部格式？（源端口，目的端口，包长度，校验和）
  2. UDP和TCP有什么区别？分布的应用场景？
    1. 连接，服务对象，可靠性，拥塞控制和流量控制，首部开销，传输方式，分片方式
  3. 为什么UDP头部没有首部字段，而TCP头部有首部字段？
  4. 为什么UDP头部有包长度字段，而TCP头部则没有包长度字段？

TCP连接建立：三次握手

TCP三次握手过程和状态变迁

第三次握手是可以携带数据的，前两次握手是不可以携带数据的.
一旦完成三次握手，双方都处于 ESTABLISHED 状态，此时连接就已建立完成，客户端和服务端就可以相互发送数据了。

image.png

如何在Linux中查看tcp状态？

TCP 的连接状态查看，在 Linux 可以通过 netstat -napt 命令查看。

为什么是三次握手？不是两次、四次？（三点原因：历史连接，初始序列号，资源浪费）

TCP 建立连接时，通过三次握手能防止历史连接的建立，能减少双方不必要的资源开销，能帮助双方同步初始化序列号。序列号能够保证数据包不重复、不丢弃和按序传输。
不使用「两次握手」和「四次握手」的原因：

  • 「两次握手」：无法防止历史连接的建立，会造成双方资源的浪费，也无法可靠的同步双方序列号；
  • 「四次握手」：三次握手就已经理论上最少可靠连接建立，所以不需要使用更多的通信次数。

为什么客户端和服务端的初始序列化ISN是不同的？（1、历史报文被下一个相同四元组接受造成数据错误，2、防止黑客伪造相同的序列号报文被接收方接受）

主要原因有两个方面：

  • 为了防止历史报文被下一个相同四元组的连接接收（主要方面）；
  • 为了安全性，防止黑客伪造的相同序列号的 TCP 报文被对方接收；

如果每次建立连接，客户端和服务端的初始化序列号都是一样的话，很容易出现历史报文被下一个相同四元组的连接接收的问题。如果每次建立连接客户端和服务端的初始化序列号都「不一样」，就有大概率因为历史报文的序列号「不在」对方接收窗口，从而很大程度上避免了历史报文

初始序列化ISN是如何随机产生的？（基于时钟每四微妙加一，然后使用hash算法得到一个hash值）

什么是SYN攻击？如何避免SYN攻击？（两种：backlog，syncookie技术）

我们都知道 TCP 连接建立是需要三次握手，假设攻击者短时间伪造不同 IP 地址的 SYN 报文，服务端每接收到一个 SYN 报文，就进入SYNRCVD 状态，但服务端发送出去的 ACK + SYN 报文，无法得到未知 IP 主机的 ACK 应答，久而久之就会占满服务端的半连接队列，使得服务器不能为正常用户服务。
避免 SYN 攻击方式一
其中一种解决方式是通过修改 Linux 内核参数，控制队列大小和当队列满时应做什么处理。
避免 SYN 攻击方式二_
tcp_syncookies 的方式可以应对 SYN 攻击.
当 「 SYN 队列」满之后，后续服务器收到 SYN 包，不进入「 SYN 队列」；

TCP连接断开：四次挥手

TCP四次挥手过程和状态变迁？

你可以看到，每个方向都需要一个 FIN 和一个 ACK，因此通常被称为四次挥手。
这里一点需要注意是：主动关闭连接的，才有 TIME_WAIT 状态。
计网面试题 - 图7

为什么需要四次挥手？（两点：等待数据的处理和发送）

服务端通常需要等待完成数据的发送和处理，所以服务端的 ACK 和 FIN 一般都会分开发送，从而比三次握手导致多了一次。

为什么TIME_WAIT是2MSL？（连续两次丢包概率比较小，并且，如果TIME_WAIT状态过多就会导致端口资源和系统资源占用过高）

MSL 是 Maximum Segment Lifetime，报文最大生存时间，它是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。
MSL 与 TTL 的区别： MSL 的单位是时间，而 TTL 是经过路由跳数。所以 MSL 应该要大于等于 TTL 消耗为 0 的时间，以确保报文已被自然消亡。
TTL 的值一般是 64，Linux 将 MSL 设置为 30 秒，意味着 Linux 认为数据报文经过 64 个路由器的时间不会超过 30 秒，如果超过了，就认为报文已经消失在网络中了。

TIME_WAIT 等待 2 倍的 MSL，比较合理的解释是： 网络中可能存在来自发送方的数据包，当这些发送方的数据包被接收方处理后又会向对方发送响应，所以一来一回需要等待 2 倍的时间。可以看到 2MSL时长 这其实是相当于至少允许报文丢失一次。

为什么需要TIME_WAIT？（不优雅的关闭）

原因一：防止历史连接中的数据，被后面相同四元组的连接错误的接收
足以让两个方向上的数据包都被丢弃，使得原来连接的数据包在网络中都自然消失，再出现的数据包一定都是新建立连接所产生的。
原因二：保证「被动关闭连接」的一方，能被正确的关闭

如果已经建立连接，但是客户端突然出现了故障怎么办？有几种情况？如果服务端崩溃会发生什么？（三种情况，应用层实现一个保活机制，使用保活计时器，联系项目）

TCP 有一个机制是保活机制。这个机制的原理是这样的：定义一个时间段，在这个时间段内，如果没有任何连接相关的活动，TCP 保活机制会开始作用，每隔一个时间间隔，发送一个探测报文，该探测报文包含的数据非常少，如果连续几个探测报文都没有得到响应，则认为当前的 TCP 连接已经死亡，系统内核将错误信息通知给上层应用程序。

如果开启了 TCP 保活，需要考虑以下几种情况：

  • 第一种，对端程序是正常工作的。当 TCP 保活的探测报文发送给对端, 对端会正常响应，这样 TCP 保活时间会被重置，等待下一个 TCP 保活时间的到来。
  • 第二种，对端程序崩溃并重启。当 TCP 保活的探测报文发送给对端后，对端是可以响应的，但由于没有该连接的有效信息，会产生一个 RST 报文，这样很快就会发现 TCP 连接已经被重置。

  • 第三种，是对端程序崩溃，或对端由于其他原因导致报文不可达。当 TCP 保活的探测报文发送给对端后，石沉大海，没有响应，连续几次，达到保活探测次数后，TCP 会报告该 TCP 连接已经死亡。

    Socket编程

    1. 针对TCP应该如何Socket编程？
    2. listen时候参数backlog的意义？（就是全连接队列的大小）
    3. connect和accept发生在三次握手的哪一步？（第二次和第三次）
    4. 客户端调用close了，连接是断开的流程是什么？（EOF）

TCP可靠机制：重传、滑动窗口、流量控制、拥塞控制

TCP是怎么实现可靠传输的：序列号，确认应答，超时重传，滑动窗口，流量控制，拥塞控制等等
1、重传机制 （三种）

  1. 超时重传（数据包丢失、确认应答丢失）
    1. 超时时间应该设置为多少（RTT，RTO）
  2. 快速重传（还存在一个问题，重传多少？）
  3. SACK （TCP头部选项字段中加入一个SACK字段，将缓存的地图发送给发送发，只重传丢失的数据）
  4. D-SACK

2、滑动窗口

  1. 引入窗口概念的原因（效率低，增大吞吐量）（操作系统缓冲区）（累积确认）
  2. 窗口大小由哪一方决定？（接受方窗口大小）
  3. 发送方的滑动窗口？
  4. 程序是如何表示发送方的四个部分？（三个指针）
  5. 接受方的滑动窗口？如何表示？（两个指针）
  6. 接受窗口和发送窗口的大小是相等的吗？（约等于）

3、流量控制

  1. 什么叫做流量控制？（网络流量无端浪费）
  2. 操作系统缓存和滑动窗口的关系？（先收缩窗口，再减少缓冲区大小）
  3. 窗口关闭潜在风险？（窗口探测报文）
  4. TCP是如何解决窗口关闭时，潜在死锁的现象的？
  5. 糊涂窗口综合症？（小数据，小窗口）
  6. 怎么让接受方不通告小窗口呢？怎么让发送方避免发送小数据？（让接收方窗口直接变为0）

4、拥塞控制

  1. 为什么要用拥塞控制，不是有流量控制了吗？目的是什么？（避免发送方的数据填满整个网络）
  2. 什么是拥塞窗口？和发送窗口是什么关系？（发送方为了调剂所要发送的数据量）
  3. 那么怎么知道网络中出现了拥塞呢？（超时重传）
  4. 拥塞控制算法有哪些？（慢启动，拥塞避免，拥塞发生，快速恢复）
  5. 慢启动涨到什么时候是个头？一般ssthresh是多少？
  6. 发生快速重传的拥塞发生算法？

    TCP实战抓包分析

TCP半连接队列和全连接队列

1、什么是TCP半连接队列和全连接队列？（超过最大长度限制之后）
2、实战tcp全连接队列溢出？

  1. Linux有个参数可以指定当TCP全连接队列满了会使用什么策略来回应客户端？tcp_abort_on_overflow？设置成0好还是1好？
  2. 如何增大TCP全连接队列呢？somaxconn和backlog？

3、实战TCP半连接队列溢出？

  1. 如何模拟TCP半连接队列溢出场景？这是什么场景？
  2. 大部分人说tcp_max_syn_backlog是指定半连接队列的大小，这是真的吗？
  3. TCP半连接队列最大值是如何决定的？没有开启tcp_syncookies的时候？
  4. 处于SYN_RECV状态的最大个数是多少？
  5. 如果SYN半连接队列已满，只能丢弃连接吗？开启syncookies功能？有那几个参数？
  6. 如何防御SYN攻击？

网络层

IP基本认识

  1. IP处于哪一层？主要作用？(网络层，实现主机与主机之间的通信，也就是点对点之间的通信）
  2. 网络层和数据链路层有什么关系？（直连和没有直连的两个网络之间进行通信传输）

IP地址的基础知识

  1. IPv4地址？
  2. IP地址分类？（a,b,c,d,e)
  3. A，B，C类地址最大主机个数是如何计算的？(主机号位数-2）
  4. 广播地址用于什么？分为哪两种？（主机号全为1是广播地址，全为0是指定某个特定网络）
  5. 什么是D，E类地址？多播地址用于什么？

  6. IP地址的优点？IP地址的缺点？（不能很好与现实网络匹配）（同一网络下没有地址层次）

    无分类地址CIDR

  7. 怎么划分网络号和主机号？子网掩码划分？

  8. 为什么划分网络号和主机号？

  9. 子网掩码的另一个作用？怎么进行子网划分？（划分子网）

    公有IP地址和私有IP地址

  10. A，B，C类私有IP地址范围？（192.168.0.0 — 192.168.255.255)

  11. 公有IP地址由谁管理呢？

    IP地址与路由控制

  12. 不同网段的路由过程？最长匹配？（路由控制表，最长匹配）

  13. 环回地址是不会流向网络？（127.0.0.1orlocalhost）

    IP分片和重组

  14. 路由器会重组IP的分片吗？引入的MSS是什么？(在TCP层进行分片，不在IP层进行分片）

    IPv6的基本认识 （IPv4地址用完了）

  15. 亮点

  16. 标识方法（共128位，每16位为一组，中间用：隔开，使用十六进制方式）

IP协议相关技术

1、 DNS域名解析

  1. 域名的层级关系？
  2. DNS解析过程？（递归和迭代查询，根，顶级，权威）

2、ARP协议

  1. ARP是如何知道对方的MAC地址的呢？（ARP请求与ARP响应）
  2. RARP协议知道吗？RARP服务器？

3、DHCP协议

  1. DHCP协议工作流程？（0000,255）
  2. DHCP服务器中继代理？（实现路由器不转发广播）

4、NAT网络地址转换

  1. NAPT网络地址与端口转换？转换表在什么创建？（SYN包发出的时候就创建了这个表）（NAT路由器）
  2. NAT那么牛逼，难道就没有缺点了吗？（外部服务器无法主动建立连接，转换表生成与转换有性能开销，NAT路由器重启了，所有的TCP连接就会重置）
  3. NAT穿透技术 （客户端主动从 NAT 设备获取公有 IP 地址，然后自己建立端口映射条目，然后用这个条目对外通信，就不需要 NAT 设备来进行转换了）

5、ICMP互联网控制报文协议

  1. ICMP功能都有哪些？（确认 IP 包是否成功送达目标地址、报告发送过程中 IP 包被废弃的原因和改善网络设置等。）
  2. ICMP类型？

综合