[面经整理]——计算机网络(不定期更新)

UDP和TCP的区别

• TCP是面向连接的（即通信前需要提前建立连接），UDP是面向无连接的（无需建立连接）。
• UDP程序结构比较简单。
• TCP是面向字节流的，UDP是基于数据报的。
• TCP可以保证数据正确性和顺序，可提供可靠的服务。但UDP无法保证，其只做到尽最大努力交付。
• UDP具有较好的实时性，其工作效率比TCP高，适用于对高速传输和实时性有较高要求的通信或广播通信。
• TCP是一对一的连接，但UDP支持一对多、一对一、多对一和多对多等交互通信。
• TCP对系统资源要i求较多，UDP对系统资源要求较少。

TCP的概念

• TCP是一种面向连接的，提供可靠交付和全双工通信，基于字节流的端到端通信协议；
• TCP在传输数据之前必须优先建立连接，在数据结束之后需要释放连接；
• TCP提供可靠交付，通过TCP连接传输的数据，无差错、不丢失、不重复且按序到达；
• TCP是面向字节流的，虽然应用进程和TCP的交互是一次一个数据块，但TCP将应用程序交付下来的数据堪称仅仅是一连串的无结构的字节流，其不关心传输字节流的含义。

UDP的概念

• UDP是一种无连接的，尽最大努力交付的，基于报文的端到端的传输层通信协议；
• UDP在发送数据之前不需要建立连接；
• UDP不保证可靠的交付，其主机不需要建立复杂的联系状态；
• UDP是面向报文的，其对应用层交下来的报文，不合并、不拆分，而是保留这些报文的边界，每次发送一个报文。在接收端，UDP一次交付一个完整的报文；
• UDP没有拥塞控制，网络出现的拥塞不会使源主机的发送速率降低；
• UDP支持一对一、一对多、多对一、多对多的交互通信；
• UDP的首部开销小，只有8个字节，比TCP的20个字节的首部要短。

---

TCP的粘包问题怎么解决

粘包问题

• TCP粘包问题主要指的是应用层的数据包，指的是发送方发送的若干数据到达接收方时粘成了一个包，从接收缓冲区来看，后一包数据的头紧跟着前一包数据的尾。

解决方法

• 对于定长的包，保证每次按照固定大小读取即可；
• 对于变长的包，在包头的位置约定一个总包长度的字段，从而得知包的结束位置；
• 对于变长的包，可以在包和包之间使用明确的分隔符；
• 可使用TLV格式的数据传输。

---

TCP第四次挥手为什么要等待2MSL

当客户端进入TIME_WAIT抓过你太的时候，需要经过时间计数器设置事件2MSL(最长报文段寿命)后，才会进入关闭状态。

• 保证客户端发送最后一个ACK报文段能够打到服务器，因为这个ACK有可能会丢失，因此会导致在LAST_ACK状态的服务器无法收到FIN_ACK的确认保温。服务器会超时重传FIN_ACK，接着等待客户端崇传一次确认，重新启动时间等待计数器。若客户端不等待2MSL而是发送完ACK直接端口，一旦ACK丢失，则服务器无法正常进入关闭连接状态；
• 可以防止已失效的报文段。客户端在发送最后一个ACK后，在经过2MSL，可以使本连接持续时间内所产生的所有报文段都从网络中小时，保证关闭连接后不会有网络中滞留的报文段反馈骚扰服务器。

---

TCP为什么是可靠连接

• TCP通过校验和、重传机制、序号标识、滑动窗口、确认应答等可实现可靠传输。
• 通过TCP连接传输的数据无差错、不丢失、不重复，且按顺序到达
• TCP报文头里面的序号可以使TCP的数据按序到达
• 报文头里的确认序号可以保证不丢包、累计确认和超时重传机制
• TCP具有流浪控制和拥塞控制机制

具体措施

• 应用数据被分割成TCP认为最适合发送的数据块，而UDP不做任何处理；
• TCP发出一个段后，启动一个定时器，等待目的端口确认收到这个报文段。若无法及时收到一个确认，将重发这个报文段（超时重传）；
• 当TCP收到发自TCP连接另一端的数据，其对包进行完整校验，并发送一个确认；
• TCP将保持其首部和尾部的检验和，其目的是检测数据在传输过程中是否出现变化。若检验和有差错，则TCP丢弃此报文同时不确认收到此报文段（校验机制）；
• TCP对收到的顺序进行重新排序，将收到的数据按照正确的顺序交给应用程；
• TCP接收端会针对重复的数据进行丢失；
• TCP可提供流量控制。TCP连接的每一方都有固定大小的缓冲空间。TCP接收端只允许另一端发送接收端缓冲区所能接纳的数据，防止较快的主机导致较慢主机的缓冲区溢出。

---

TCP和UDP分别对应的协议

TCP对应的协议

• FTP：文件传输协议，使用21端口；
• Telent：一种用于远程登陆的端口，使用23端口，用户可以以自己的身份远程连接到计算机上，可提供基于DOS模式下的通信服务；
• SMTP：邮件传输协议，用于发送邮件，服务器开放的是25端口；
• POP3：与SMTP协议对应，用于接收邮件，使用110端口；
• HTTP：从Web服务器传输超文本到本地浏览器的传送协议，使用80端口。

UDP对应的协议：

• DNS：用于域名解析服务，将域名地址转换为IP地址，使用53号端口；
• SNMP：简单网络管理协议，使用161端口，用于管理网络设备；
• TFTP：简单文件传输协议，在69端口上使用UDP服务

TCP的拥塞控制原理

慢开始、拥塞避免、快重传、快恢复

• 发送放维持一个“拥塞窗口”的变量，该变量与接收窗口共同决定了发送者的发哦那个窗口。发送方的发送窗口上限值应当为接收方窗口rwnd喝拥塞窗口cwnd两个变量中较小的一个；
• **慢开始：**当主机开始发送数据时，为避免一下子将大量字节涌入网络中，造成或增加拥塞，发送方选择发送1字节的试探报文；
• 当收到第一个字节的数据的确认后，就发送2个字节的报文，从此一次递增2的指数级；
• 最后会到达一个提前预设的“慢开始门限sstresh”，此时遵循以下算法:
  若 cwnd < sstresh，停止使用慢开始算法；
  若 cwnd > sstresh，停止使用慢开始算法，改用拥塞避免算法；
  若 cwnd = sstresh，既可以使用慢开始算法，又可以使用拥塞避免算法；
• **拥塞避免算法：**每经过一个往返时间RRT就将发送方的拥塞窗口+1，让拥塞窗口缓慢增大，按照线性规律增长；
• 当出现网络拥塞，将慢开始门限ssthresh设置为出现拥塞时的发送窗口的一半（但不能小于2），然后将cwnd设为1，开始执行慢开始算法；
• 快重传机制：
  1、接收方建立机制：如果一个包丢失，则对后续的包继续发送针对该包的重传请求；
  2、一旦发送方接收三个一样的确认，就知道该报出现了错误，立即重传该包；
  3、此时执行快恢复算法：
    a、慢开始的门限变为出现拥塞时的一半；
    b、拥塞窗口cwnd设为上面变化后的慢开始的门限值；
    c、执行拥塞避免算法（高起点，线性增长）；

---

浏览器输入URL后的流程

1、 在浏览器地址输入url；
2、 浏览器先查看浏览器缓存-系统缓存-路由器缓存，若缓存中存在，则直接在屏幕显示页面内容。若没有，则跳转到步骤三；

• 浏览器缓存：浏览器会记录DNS一段时间，因此只是第一个地方解析DNS请求；
• 操作系统缓存：若浏览器缓存中不包含记录，则调用操作系统，获取操作系统的记录(操作系统会保存最近的DNS查询缓存)；
• 路由器缓存；
• ISP搜索；

3、在发送http请求之前，进行域名解析(DNS解析)，获取相应的IP地址；
4、浏览器向服务器发送TCP连接，与浏览器建立TCP三次握手；

• 第一次握手(发送连接请求)：客户端将标志位SYN置为1，随机产生一个值seg=J的数据包到服务器，客户端进入SYN_SENT状态，等待服务器端确认；
• 第二次握手(回应连接请求)：服务端收到数据包后由标志位SYN=1知道客户端建立请求连接，服务端将标志位SYN和ACK都置为1，ack=J+1，随机产生一个值seq=K并将该数据包发送给客户端以确认连接请求，服务器端进入SYN_RCVD状态；
• 第三次握手(收到回应，最后确认)：客户端收到确认后，检查ack是否为J+1，ACK是否为1。若正确则将标志位ACK置为1，ack=K+1，并将该数据包发送给服务端，服务端检查ack是否为K+1，ACK是否为1。若正确则建立连接，完成三次握手。只有第三次握手可以包含数据。

5、握手成功后，浏览器向服务器发送HTTP请求，请求数据包；
6、服务器处理收到的请求，将数据返回至浏览器；
7、浏览器收到HTTP响应，获取页面内容，浏览器进行渲染，解析html源码；
8、生成Dom树，解析css样式、js交互；
9、客户端与服务器交互；
10、ajax查询；
11、断开TCP连接；

• 第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态；
• 第二次挥手：Server收到FIN后，发送ACK给Client，确认序号为收到序号+1，Server进入CLOSE_WAIT状态；
• 客户端收到服务端的ACK后，进入FIN_WAIT_2状态；
• 第三次挥手：Server处理完数据后，发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态；
• 第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态，接着发送ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手。
• 客户端经过2MSL事件后，自动进入ClOSED状态，客户端关闭连接。

---

DNS解析过程

1、浏览器先检查自身缓存中是否存在被解析过的域名对应的ip地址，若果有，解析结束；
2、如果浏览器缓存中没有，浏览器检查操作系统缓存中有没有对应的已解析的结果；
3、若还未命中域名，则请求本地域名服务器(LDNS)来解析域名；
4、若LDNS未命中，则跳到Root Server域名服务器请求解析；
5、根域名服务器返回给LDNS一个所查询域的主域名服务器(gTLD Server)地址；
6、此时LDNS发送请求给上一步返回的gTLD；
7、请求接受的gTLD查找并返回这个域名对应的Name Server地址，即网站注册的域名服务器；
8、Name Server根据映射关系表找到目标ip，返回给LDNS；
9、LDNS焕春这个域名和对应的ip；
10、LDNS将解析的结果返回给用户，用户根据TTL值缓存到本地系统缓存中，域名解析至此结束。

---

TCP和UDP的区别

1. 连接
   • TCP是面向连接的传输层协议，传输前要先建立连接；
   • UDP是不需要连接，即刻传输数据。
2. 服务对象
   • TCP是一对一的两点服务，即一条连接只有一个端点；
   • UDP支持一对一、一对多、多对对的交互通信。
3. 可靠性
   • TCP是可靠交付数据的，数据可以无差错、不丢失、不重复、按需到达；
   • UDP是金最大努力交付，不保证可靠交付数据。
4. 拥塞控制、流量控制
   • TCP有拥塞控制和流量控制机制，保证数据传输的安全性；
   • UDP则没有，即使网络拥堵，也不会影响UDP的发送速率。
5. 首部开销
   • TCP首部长度较长，会有一定开销，首部在没有使用[选项]字段时是20字节，若使用则会边长；
   • UDP首部只有8字节，而且固定不变开销较小。
6. 传输方式
   • TCP是流式传输，没有边界，但是保证顺序和可靠；
   • UDP是一个包一个包的发送，是有边界的，但可能会丢包和乱序；
7. 分片不同
   • TCP的数据大小如果大于MSS大小，则会在传输层进行分片，目标主机收到后，也同样在传输层组装TCP数据包，如果丢失了一个分片，则需要重新传输这个分片；
   • UDP的数据大小如果大于MTU大小，则会在IP层进行分片，目标主机收到后，则在IP组装完数据，接着在传输给传输层，若途中丢失了一个分片，则需要传输所有的数据包，通常UDP报文应该小于MTU。

---

为什么TCP三次握手才能保证双方具有接受和发送的能力

• 三次握手才可以阻止重复历史连接的初始化
• 三次握手才可以同步双方的初始化序列号
• 三次握手才可以避免资源浪费

1. 避免历史连接

• 客户端连续发送多次SYN建立连接的报文，在网络拥堵情况下：
  • 一个“旧SYN报文”比“最新的SYN报文”早到达了服务端；
  • 此时服务器返回一个 SYN + ACK报文给客户端；
  • 客户端接收后，可以判断这是一个历史连接，此时客户端发送 RST报文给服务端，表示中止这次连接；
• 如果是两次握手链接，则不能判断当前连接是否是历史连接，三次握手则可以在客户都安准备发送第三次报文时，客户端有足够的上下文来判断是否是历史连接：
  • 如果是历史连接，则第三次报文发送 RST报文，以此中止历史连接；
  • 如果不是历史连接，则第三次发送的报文是 ACK报文，通信双方就会成功建立连接；

2. 同步双方初始化序列号

• TCP协议的通信双方，都必须维持一个序列号，序列号是可靠传输的关键因素，其作用为：
  • 接收方可以去除重复的数据；
  • 接收方可以根据数据报的序列号按序接受；
  • 可以标识发哦能够输出取得数据包中，那些事已经被对方收到的；
• 当客户端发送携带“初始序列号”的 SYN报文时，需要服务端返回一个 ACK应答报文，表示客户端的 SYN报文已经被成功接收，当服务端发送“初始序列号”给客户端的时，也要得到客户端的回应，从而确保双方的初始序列号能被可靠的同步。

3. 避免资源浪费

• 如果只有两次握手，若客户端的 SYN报文在网络中阻塞，客户段没有接收到 ACK报文，就会重新发送，若没有第三次握手，则客户端无法确认是否收到了自己发送的链接的 ACK确认信号，所以没收到一个 SYN就只能先主动建立一个连接。若客户端的 SYN被阻塞，重复发送多次 SYN报文，那么服务器在收到请求后会建立多个冗余的无效链接，造成了资源的浪费。
• 三次握手就已经理论上建立了可靠的链接，不需要使用更多的通信次数。

---

Socket编程

• 服务端和客户端初始化socket，得到文件描述符；
• 服务端调用bind，将绑定在IP地址和端口；
• 服务端调用listen，进行监听；
• 服务端带调用accept，等待客户端连接；
• 客户端调用connect，向服务端的地址和端口发送连接请求；
• 服务端accept返回用于传输的socket文件描述符；
• 客户端调用write写入数据，服务端调用read读取数据；
• 客户端断开连接时，会调用close，则服务端read读取数据则读取到EOF，带处理完数据后，服务端调用close，表示连接关闭。

---

HTTP特性

• 优点：
  • 简单：其报文格式是header+body，头部信息是key-value，易于理解；
  • 灵活且易于拓展：HTTP工作应用层，下层可以随意变换，且其请求方法、URI/URL、状态码、头部字段等没有被固定死，允许开发人员自定义和扩充；
  • 应用广泛和跨平台。
• 缺点：
  • 无状态：虽然服务器不会记忆HTTP的状态，因此不需要额外的资源来记录状态信息，可以减轻服务器的负担，但是在完成关联性操作时会非常麻烦。其主要解决方法为Cookie技术：通过请求和响应报文中加入Cookie信息来控制客户端状态。
  • 明文传输虽然易于阅读虽然方便阅读，但是信息容易被窃取。
  • 不安全：这是HTTP最严重的缺点。明文通信会导致内容被窃听、不验证身份会导致伪装、不验证完整性内容容易被修改。可通过引入SSL/TLS层，使用HTTPS保证安全。
• HTTP/1.1关键性能
  • 长连接：HTTP/1.1提出长连接通信方式，保证了持久连接，减少额外开销和服务器负载。
  • 管道网络传输：在同一个TCP连接中，客户端可发起多个请求，只要第一个请求发出去了，不必等其回来即可发送第二个请求。
  • 队头阻塞：由于HTTP是“请求-应答”模式，当顺序发送的请求序列因为某种原因被阻塞时，后面排队的所有请求也会被一同阻塞。

---

HTTP与HTTPS

HTTP与HTTPS的区别

• HTTP是超文本传输协议，信息是明文传输，存在安全问题。HTTPS则是在TCP和HTTP网络层之间加入SSL/TLS安全协议，使得报文加密；
• HTTP通过TCP三次握手即可进行报文传输，HTTPS则是要在TCP三次握手之后进行SSL/TLS握手，才能进行加密报文传输；
• HTTP端口号是80，HTTPS端口号是443；
• HTTPS协议需要向CA(证书权威机构)申请数字证书，保证服务器身份可信。

HTTPS如何保证通信安全

• 信息加密-混合加密：采用对称加密和非对称加密的混合加密方式；
• 校验机制-摘要算法：实现完整性，解决篡改风险；
• 身份证书-数字证书：使用公钥加密信息，使用私钥解密信息。

SSL/TLS协议基本流程

• 客户端向服务器索要验证服务器的公钥；
• 双方协商产生“会话私钥”；
• 双方采用“会话私钥”进行加密通信。

SSL/TLS协议建立详细流程

• ClientHello：客户端向服务器发哦是那个加密通信请求。发送内容有：SSL/TLS版本号、客户端产生随机数、客户端支持的密码套件列表；
• SeverHello：服务器收到客户端请求后，发出响应。响应内容有：SSL/TLS版本号确认、服务器产生随机数、确认密码套件列表、服务器数字证书；
• 客户端回应：客户端收到服务器回应后，确认数字证书真实性，随后使用服务器公钥发送加密报文。发送内容有：一个随机数、加密通信算法改变通知、客户端握手结束通知；
• 服务器回应：服务器收到客户端随机数后，进行解密获得本次通信会话私钥，随后发送响应。响应内容有：加密通信算法改变通知、服务器握手结束通知。

---

HTTP/1.1、HTTP/2、HTTP/3的演变

HTTP/1.1相对于HTTP/1.0：

• 增加长连接；
• 支持管道网络传输。
• 仍有瓶颈：
  • 请求/响应头部未经压缩即发送；
  • 发送冗长的首部，每次发送的首部信息相同；
  • 服务器按顺序相应，容易造成队头阻塞；
  • 没有请求优先级控制；
  • 请求只能从客户端开始，服务器被动响应。

HTTP/2(基于HTTPS)相对于HTTP/1.1

• 头部压缩：若发送多个请求，且头部一样或相似，则会消除重复(HPACK算法：客户端和服务器同时维护一张头部信心表，所有字段在表中生成索引，因此只需发送索引号即可)。
• 二进制格式：头部信息和数据体都是用二进制，且统称为帧。
• 数据流：通过数据包标记确定属于哪个回应，且客户端可以指定数据流的优先级。
• 多路复用：可以在一个连接中发送多个请求或响应，不用按照顺序一一对应，解决队头阻塞问题。
• 服务器推送：服务器可以主动向客户端发送消息。
• HTTP/2仍有缺陷：
  • 多个HTTP请求复用一个TCP连接，若发送丢包现象，TCP会触发重传机制，导致所有HTTP请求必须等待被丢失的包重传。即一旦发生丢包，会阻塞所有的HTTP请求。

HTTP/3主要改动

• HTTP/3将TCP协议改成了UDP协议。
• 基于UDP的QUIC协议保证传输的可靠性。
• 头部算法升级成QPack
• HTTPS需要建立连接需要六次交互，QUIC直接将TCP和TLS/1.3握手合并成了3次。

---

HTTP/1.1如何优化

• 尽量避免发送HTTP请求。解决方法：缓存。
• 在需要发送HTTP请求时，考虑如何减少请求次数。解决方法：减少重定向请求次数、合并请求、延迟发送请求；
• 减少服务器相应的数据大小。解决方法；无损压缩、有损压缩。

---

HTTPS如何优化

• 分析性能损耗：TLS协议握手过程、握手后的对称加密报文传输；
• 硬件优化：选择支持AES-NI特性的CPU(HTTPS是计算密集型)；
• 软件优化：升级Linux内核、升级OpenSSL；
• 会话服用
• 协议优化：密钥交换算法优化-使用ECDHE、TLS升级；
• 证书优化：证书传输优化-使用ECDSA证书、证书验证优化；

---

TCP重传机制

• 超时重传：发送数据时，设定一个定时器，当超过指定时间后，若没有收到对方的ACK确认应答报文，则重新发送该数据。再次超时时，TCP的策略是超时间隔加倍。
• 快速重传：当受到三个相同的ACK报文时，会在定时器过期之前重传丢失的报文段。
• SACK(选择性确认)：在 TCP 头部「选项」字段⾥加⼀个 SACK 的东⻄，它可以将缓存的地图发送给发送⽅，这样发送⽅就可以知道哪些数据收到了，哪些数据没收到，知道了这些信息，就可以只重传丢失的数据。
• D-SACK：使⽤了 SACK 来告诉「发送⽅」有哪些数据被重复接收了。

---

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

在TCP握手的时候，Linux内核会维护两个队列：

• 半连接队列：SYN队列；
• 全连接队列：accepet队列。

服务端在收到客户端发起的SYN请求后，内核会把连接存储到半连接队列，并向客户端响应SYN+ACK，接着客户端返回ACK，服务端收到第三次握手的ACK后，内核会把连接从半连接队列移除，然后创建新的完全的连接，并将其添加到accept队列，等待进程调用accept函数时把连接取出来。

TCP第一次握手在收到SYN包时会被丢弃的三种条件：

• 如果半连接队列满了，并且没有开启tcp_syncookies，则会被丢弃；
• 如果全连接队列满了，且没有重传SYN+ACK包的连接请求多余1个，则会被丢弃；
• 如果没有开启tcp_syncookies且max_syn_backlog减去当前半连接队列长度小于max_syn_backlog>>2，则会被丢弃。

防御SYN攻击的方法：

• 增大半连接队列；
• 开启tcp_syncookies功能；
• 减少SYN+ACK重传次数。

---

提升TCP的策略

TCP三次握手的性能提升

使用netstat命令查看是哪个握手阶段出现问题，对症下药。

• 调整SYN报文重传次数(客户端优化)
• 调整SYN半连接队列长度(服务端优化)：可根据netstat -s命令得到的统计结果确认
• 调整SYN+ACK报文重传次数
• 调整accpet队列长度：可通过ss -ltn命令查看
• 绕过三次握手(TCP Fast Open功能可减少TCP连接建立的时延)

TCP四次挥手的性能提升

• 调整FIN报文重传次数(主动方的优化)
• 调整FIN_WAIT2状态的时间
• 调整孤儿连接的上限个数
• 调整time_wait状态的上限个数
• 调整time_wait状态的连接

TCP数据传输的性能提升

• 扩大窗口大小
• 调整发送缓冲区范围
• 调整接收缓冲区范围
• 接收缓冲区动态调节
• 调整内存范围

---

IPv6相对于IPv4的首部改进

• 取消了首部校验和字段：因为在数据链路层和传输层都会进行校验；
• 取消了分片/重新组装相关字段：IPv6不允许在中间路由器进行分片与重铸，只能在源于目标主机进行；
• 取消选项字段。

---

IP协议相关技术

DNS域名解析

• 客户端⾸先会发出⼀个 DNS 请求，问 www.server.com 的 IP 是啥，并发给本地 DNS 服务器（也就是客户端的 TCP/IP 设置中填写的 DNS 服务器地址）。

• 本地域名服务器收到客户端的请求后，如果缓存⾥的表格能找到 www.server.com，则它直接返回 IP 地址。如果没有，本地 DNS 会去问它的根域名服务器： “⽼⼤， 能告诉我 www.server.com 的 IP 地址吗？ ” 根域名服务器是最⾼层次的，它不直接⽤于域名解析，但能指明⼀条道路。

• 根 DNS 收到来⾃本地 DNS 的请求后，发现后置是 .com，说： “www.server.com 这个域名归 .com 区域管理”，我给你 .com 顶级域名服务器地址给你，你去问问它吧。 ”

• 本地 DNS 收到顶级域名服务器的地址后，发起请求问“⽼⼆， 你能告诉我 www.server.com 的 IP 地址吗？ ”
  顶级域名服务器说： “我给你负责 www.server.com 区域的权威 DNS 服务器的地址，你去问它应该能问到”。

• 本地 DNS 于是转向问权威 DNS 服务器： “⽼三， www.server.com对应的IP是啥呀？ ” server.com 的权威 DNS服务器，它是域名解结果的原出处。为啥叫权威呢？就是我的域名我做主。

• 权威 DNS 服务器查询后将对应的 IP 地址 X.X.X.X 告诉本地 DNS。

• 本地 DNS 再将 IP 地址返回客户端，客户端和⽬标建⽴连接。

ARP 与 RARP 协议

ARP协议

• 主机通过广播发送ARP请求，这个请求包中包含想知道的MAC地址和主机IP地址；
• 当同个链路中所有设备收到ARP请求时，拆解内容，若请求地址于自己的IP地址一致，则将自己的MAC地址塞入ARP响应包返回给主机。

RARP协议(需要RARP服务器)

• 该设备会发送⼀条「我的 MAC 地址是XXXX，请告诉我，我的IP地址应该是什么」的请求信息。
• RARP 服务器接到这个消息后返回「MAC地址为 XXXX 的设备， IP地址为 XXXX」的信息给这个设备。
• 最后，设备就根据从 RARP 服务器所收到的应答信息设置⾃⼰的 IP 地址。

DHCP 动态获取 IP 地址

• 客户端⾸先发起 DHCP 发现报⽂（DHCP DISCOVER） 的 IP 数据报，由于客户端没有 IP 地址，也不知道DHCP 服务器的地址，所以使⽤的是 UDP ⼴播通信，其使⽤的⼴播⽬的地址是 255.255.255.255（端⼝ 67）并且使⽤ 0.0.0.0（端⼝ 68） 作为源 IP 地址。 DHCP 客户端将该 IP 数据报传递给链路层，链路层然后将帧⼴播到所有的⽹络中设备。
• DHCP 服务器收到 DHCP 发现报⽂时，⽤ DHCP 提供报⽂（DHCP OFFER） 向客户端做出响应。该报⽂仍然使⽤ IP ⼴播地址 255.255.255.255，该报⽂信息携带服务器提供可租约的 IP 地址、⼦⽹掩码、默认⽹关、DNS 服务器以及 IP 地址租⽤期。
• 客户端收到⼀个或多个服务器的 DHCP 提供报⽂后，从中选择⼀个服务器，并向选中的服务器发送 DHCP 请求报⽂（DHCP REQUEST进⾏响应，回显配置的参数。
• 最后，服务端⽤ DHCP ACK 报⽂对 DHCP 请求报⽂进⾏响应，应答所要求的参数。

NAT 网络地址转换

ICMP 互联网控制报文协议

• 查询报文类型：用于诊断的查询消息
  • 0：回送应答
  • 8：回送请求
• 差错报文类型：通知出错原因的错误消息
  • 目标不可达
  • 原点抑制
  • 重定向或改变路由
  • 超时

IGMP 因特网组管理协

---

ICMP协议（互联网控制报文协议）

主要功能：

• 确认IP包是否成功送达目标地址；
• 报告发送过程中IP包被废弃的原因
• 改善网络设置

Ping的发送与接收过程

• Ping命令执行时，源主机会构建一个ICMP回送请求消息包；
• ICMP协议将数据包联通地址交给IP层；
• 主机B收到数据帧后，检查MAC地址，若符合则接收，否则就丢弃；
• 主机B提取IP数据包交给IP层次；
• 主机B构建ICMP会送响应消息；
• 在规定时间内，源主机若没收到ICMP应答包，则说明主机不可达。

traceroute作用

• 故意设置特殊TTL，追钟去往目的地时沿途经过的路由器；
• 故意设置不分片，确定路径MTU；