网络分层 & http && https & arp

😉 本文共8629字，阅读时间约20min

目录

• 网络分层
  • 分层
  • OSI七层协议
    • 数据上下变化
    • 其它模型
  • 设备
• http
  • 常见状态码
  • TCP Keep-Alive和HTTP Keep-Alive
  • http 1.0 -> 1.1 -> 2.0 -> 3.0
    • http 1.0
    • http 1.1
    • http 2.0
    • http 3.0
    • why quic?
      • 流量控制
      • 拥塞控制
      • 重传SACK机制
      • 校验和
      • 重排序
      • 优势
  • 网页解析流程
    • 1. 查询DNS， 获取域名对应的IP地址
    • 2. 发起TCP三次握手
    • 3. 建立连接后，使用HTTP协议访问网页
  • 关于ping某个网站用到了哪些协议的问题
  • HTTP 是不保存状态的协议, 如何保存用户状态?
  • GET和POST区别
• 搞懂https安全原理
  • HTTPS 的核心—SSL/TLS协议
  • 对称/非对称密钥加密
  • SSL/TLS工作原理
  • 公钥传输的信赖性（如何确认A收到的公钥是B的公钥）
  • 如何证明浏览器收到的公钥一定是该网站的公钥？(数字证书)
  • 数字证书
  • 如何防止数字证书被篡改？（数字签名）
  • 怎么证明当前网站的CA机构的公钥是可信的
  • 每次进行HTTPS请求时都必须在SSL/TLS层进行握手传输密钥吗？
  • 为什么制作数字签名时需要hash一次？
  • 总结（https工作流程）
• ARP协议
  • ARP是什么
  • MAC地址
    • ARP协议为什么需要知道MAC地址
    • 什么是RARP协议
  • ARP协议工作原理
    • ARP表
    • 同一局域网内的MAC寻址
    • 不同局域网内的MAC寻址

网络分层

分层

OSI七层协议

• 应用层 ：
  • 为应用提供数据传输服务，例如 HTTP、DNS 等协议。数据单位为报文。
• 表示层：
  • 确保A主机应用层信息可被B主机的应用层读取。
  • 因为编码可能不同，表示层使得应用程序不必关心在各台主机中数据内部格式不同的问题。
• 会话层：
  • 通过运输层（端口号：传输端口与接收端口）建立数据传输的通路
  • 在主机间建立及管理会话（设备需要互相认识可以是IP或MAC或主机名）
• 传输层 ：
  • 提供通用数据传输服务。定义了一些传输数据的协议和端口号（WWW端口80等）
  • 运输层包括两种协议：
    • TCP，提供面向连接、可靠的数据传输服务，数据单位为报文段。提供完整性服务
    • UDP，提供无连接、尽最大努力的数据传输服务，数据单位为用户数据报。提供及时性服务
• 网络层 ：
  • 把传输层的报文段或者用户数据报封装成分组
  • 为位于不同网络位置的主机提供连接和路径选择
  • 该层有IP协议、NAT协议、ARP协议
• 数据链路层 ：
  • 把网络层的分组封装为帧，为链路上的主机提供数据传输服务
  • 帧差错控制：帧错误、帧丢失、帧重复
• 物理层 ：
  • 在传输介质上传输比特流（0/1转化为电流强弱）
  • 屏蔽传输介质和物理设备的差异，使得数据链路层对这种差异无感知

数据上下变化

• 向下的过程中，需要添加下层协议所需要的首部或者尾部
• 向上的过程中不断拆开归属下层的首部和尾部。

其它模型

• TCP/IP模型只有四层，相当于OSI模型中下两层合并为网络接口层，上三层合并为应用层
• 五层协议模型只是OSI和TCP/IP的综合，实际应用还是TCP/IP的四层结构。

设备

七层模型只有最下三层有实体设备，上四层都是软件层面的表示了。

第一层：物理层，代表设备：网卡，网线，光纤，atm线缆等。

第二层：数据链路层，代表设备：二层交换机。 （MAC，ARP ：IP地址->Mac）

第三层：网络层，代表设备：路由器。（IP、ICMP）

第四层：传输层，代表协议：（TCP/UDP）

之后的5-7层就是各种协议的表示了。这个主要是开发人员用的多一些，如http，smtp，ftp等等。

会话层（RPC）、表现层（ASCII、JPEG）、应用层（FTP、DNS、Telnet、SMTP、HTTP）

http

常见状态码

200 成功、201 请求被成功处理并且在服务端创建了一个新资源，如新用户

301 永久重定向、302 临时重定向

400 客户端请求参数问题、401 未认证想要访问认证后的资源、404 在服务端找不到资源

500 服务端错误、502 网关将请求转发到服务端，但是服务端返回的却是一个错误的响应。

TCP Keep-Alive和HTTP Keep-Alive

• HTTP 的 Keep-Alive，是由应用层（用户态） 实现的，称为 HTTP 长连接
  • 使用同一个 TCP 连接来发送和接收多个 HTTP 请求/应答，避免了连接建立和释放的开销
• TCP 的 Keepalive，是由 TCP 层（内核态） 实现的，称为 TCP 保活机制；
  • TCP 的 Keepalive 这东西其实就是 TCP 的保活机制，可以在双方没有数据交互的情况，通过探测报文，来确定对方的 TCP 连接是否存活，这个工作是在内核完成的，决定是否关闭该连接

http 1.0 -> 1.1 -> 2.0 -> 3.0

可以看出，http每一代的改进都是基于上一代的缺点的

http 1.0

默认tcp短连接，每次请求都要重新建立tcp连接。

大量的握手挥手报文占带宽。

http 1.1

http1.0无法复用连接，http 1.1 默认使用tcp长连接。

一个网页打开完成后，客户端和服务器之间用于传输 HTTP 数据的 TCP 连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。

添加了一个Connection字段，设置Keep-Alive来保持连接

http 2.0

支持多路复用（链接共享）

http 1.x 基于文本，导致传输时必须按整体去传

帧代表着最小的数据单位，每个帧会标识出该帧属于哪个流。

流就是多个帧组成的数据流。

• http 2.0基于二进制流，将http消息分解成独立的帧，交错发送，然后在另一端组装
  • 并行交错地发送多个请求，请求之间互不影响。
  • 并行交错地发送多个响应，响应之间互不干扰。
• 简单的来说： 在同一个TCP连接中，同一时刻可以发送多个请求和响应，且不用按照顺序一一对应。之前是同一个连接只能用一次， 如果开启了keep-alive，虽然可以用多次，但是同一时刻只能有一个HTTP请求。

http 3.0

随着 TCP 协议的缺点不断暴露出来，新一代的 HTTP 协议 - HTTP 3.0 毅然决然切断了和 TCP 的联系，转而拥抱了 UDP 协议，这么说不太准确，其实 HTTP 3.0 其实是拥抱了 QUIC 协议，而 QUIC协议是建立在 UDP 协议基础上的。去年6月正式发布。

• 建立在UDP基础上的QUIC协议
• 更低的延迟，更高的效率

why quic?

修改tcp协议，更新阻力太大了。

QUIC 的小写是 quic，谐音 quick，意思就是快。它是 Google 提出来的一个基于 UDP 的应用层协议，所以 QUIC 又被叫做快速 UDP 互联网连接。

• QUIC：一个可靠的基于UDP的安全传输协议。
• 我们知道TCP可靠的原因在于流量控制、拥塞控制、超时重传、校验和、重排序

流量控制

QUIC 的流量控制也是使用了窗口更新 window_update，来告诉对端它可以接受的字节数。

拥塞控制

QUIC协议可以自己设置或实现拥塞控制协议。

QUIC 协议当前默认使用了 TCP 协议的 Cubic 拥塞控制算法。 这个机制还是可插拔的，能够非常灵活地生效，变更和停止，可以根据场景来切换不同的方法。

QUIC协议在用户空间实现，应用程序不需要停机和升级就能实现拥塞控制 的变更，在服务端只需要修改一下配置，reload 一下，完全不需要停止服务 就能实现拥塞控制的切换。甚至可以为每一个请求都设置一种拥塞控制算法。

而TCP在内核态，其拥塞控制难以进行修改和升级。

重传SACK机制

发送端通过包号（PKN）和确认应答（SACK）确认发送数据完整性。

1. 客户端：发送 3 个数据包给服务器（PKN = 1， 2，3）
2. 服务器：通过 SACK 告知客户端已经收到了 1 和 3，没有收到 2
3. 客户端：重传第 2 个数据包（PKN=4）

校验和

QUIC 中的报文头部都是经过认证，报文也经过加密处理。这样只要对 QUIC 的报文有任何修改，接收端都能够及时发现，保证了安全性。

重排序

QUIC每个Stream帧中都有offset字段和StreamID字段，这使得乱序接收的数据能够有序排列。

优势

握手建连更快。QUIC建连时间大约0~1 RTT，在两方面做了优化：

1）传输层使用了UDP，减少了1个RTT三次握手的延迟。

2）加密协议采用了TLS 协议的最新版本TLS 1.3，相对之前的TLS 1.1-1.2，TLS1.3允许客户端无需等待TLS握手完成就开始发送应用程序数据的操作，可以支持1 RTT和0RTT。

对于QUIC协议，客户端第一次建连的握手协商需1-RTT，而已建连的客户端重新建连可以使用之前协商好的缓存信息来恢复TLS连接，仅需0-RTT时间。因此QUIC建连时间大部分0-RTT、极少部分1-RTT，相比HTTPS的3-RTT的建连，具有极大的优势。

避免队首阻塞的多路复用。

QUIC同样支持多路复用，相比HTTP/2，QUIC的流与流之间完全隔离的，互相没有时序依赖。如果某个流出现丢包，不会阻塞其他流数据的传输和应用层处理，所以这个方案并不会造成队首阻塞。

现在流量大, 很多场景无需慢启动.

网页解析流程

从输入网址到获取页面的过程

DNS、TCP、IP、OSPF、ARP、HTTP、TLS

1. 查询DNS， 获取域名对应的IP地址

1. 搜索浏览器的 DNS 缓存，缓存中维护一张域名与 IP 地址的对应表

2. 若没有命中，则继续搜索操作系统的 DNS 缓存，即本地host文件

3. 若仍然没有命中，则操作系统将域名发送至本地域名服务器，本地域名服务器查询自己的 DNS 缓存

4. 本地域名解析器还没有完成解析的话，那么发起一个DNS迭代调用，本地域名解析服务器

   1. (.)将向根域名服务器发起解析请求。根域名服务器返回顶级域名解析服务器地址。
   2. (.com)顶级域名解析服务器根据要解析的域名找到域名对应的权限域名服务器
   3. (baidu.com)权限域名服务器返回值给本地域名服务器。
   4. 本地域名服务器缓存解析后结果，并返回解析结果给用户

2. 发起TCP三次握手

if not http3 的 quic 协议

1. 传输层：TCP传输报文。
2. 网络层：
3. 发送数据在网络层使用IP协议，并且负责寻找传输路线。OSPF协议（开放最短路径优先）负责IP数据包在路由器间的路径选择。
4. 判断目标地址是否与当前地址处于同一网络中，是的话直接根据 Mac 地址发送，否则使用路由表查找下一跳地址，以及使用 ARP 协议查询它的 Mac 地址。

3. 建立连接后，使用HTTP协议访问网页

1. 如果是HTTPS，还需要进行TLS协议握手

   HTTP报文是包裹在TCP报文中发送的，服务器端收到TCP报文时会解包提取出HTTP报文。但是这个过程中存在一定的风险，HTTP报文是明文，如果中间被截取的话会存在一些信息泄露的风险。那么在进入TCP报文之前对HTTP做一次加密就可以解决这个问题了。HTTPS协议的本质就是HTTP + SSL(or TLS)。在HTTP报文进入TCP报文之前，先使用SSL对HTTP报文进行加密。从网络的层级结构看它位于HTTP协议与TCP协议之间。

2. 在建立连接后，浏览器会向目标服务器发起 HTTP-GET 请求，包括其中的 URL，HTTP 1.1 后默认使用长连接，只需要一次握手即可多次传输数据。服务器接收到请求后，根据路径参数映射到特定的请求处理器进行处理，并将处理结果及相应的视图返回给浏览器

3. 浏览器渲染页面，若遇到对js文件、css文件及图片等静态资源的引用，则重复上述步骤并向服务器请求这些资源

关于ping某个网站用到了哪些协议的问题

假设ping www.baidu.com，可能用到DNS协议、ICMP协议、IP协议、ARP协议、RARP协议

1. 首先DNS协议，将网址转为IP地址
2. 其次ping的原理是使用ICMP的回响机制，所以必然用到了网络层的ICMP协议。ICMP是IP层的协议，ICMP报文是装在IP数据报中，作为其中的数据部分。
3. 最后在到达对方局域网的时候需要使用ARP查找mac地址，在发送主机不知道自己IP的时候也会用到RARP协议

HTTP 是不保存状态的协议, 如何保存用户状态?

http是无状态协议，也就是说 HTTP 协议自身不对请求和响应之间的通信状态进行保存。那么我们保存用户状态呢？Session 机制的存在就是为了解决这个问题，Session 的主要作用就是通过服务端记录用户的状态。

典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了（一般情况下，服务器会在一定时间内保存这个 Session，过了时间限制，就会销毁这个 Session。

GET和POST区别

GET从服务器上请求数据（查数据）, POST给服务器提交表单（更改数据）

1. GET不安全，参数在URL后面，容易被攻击者篡改和伪造。POST把参数放在body里，对用户来说不可见。
2. GET请求的URL有长度限制，这个限制是浏览器或者服务器添加的，防止有人发送恶意请求，POST请求会把参数和值放在消息体中，对数据长度无要求
3. get 请求在发送过程中会产生一个 TCP 数据包；post 在发送过程中会产生两个 TCP 数据包。对于 get 方式的请求，浏览器会把 http header 和 data 一并发送出去，服务器响应 200（返回数据）；而对于 post，浏览器先发送 header，服务器响应 100 continue，浏览器再发送 data，服务器响应 200 ok（返回数据）。

其实也可以认为使用上没有区别。

1. 用 POST 方法查询信息也是可以的，GET请求更新信息也是可以的。
2. uri 中的查询参数也不是 GET 所独有的，POST 请求的 uri 中也可以有参数。
3. 而且，协议并没有规定 GET 请求不能带 body 的。理论上，任何请求都可以带 body 的。ElasticSearch 查询的时候使用的方法是 GET，但查询 DSL 却是用 body 传输的。

搞懂https安全原理

HTTPS 的核心—SSL/TLS协议

• HTTPS 之所以安全，就是结合了 SSL/TLS 和 TCP 协议，加密通信数据，而非 HTTP的明文数据
• SSL 和 TLS 没有太大的区别。TLS是基于SSL的，SSL 3.0就是TLS 1.0。

对称/非对称密钥加密

• 对称密钥加密：

  • 发送方和接收方使用相同的密钥，加密和解密明文密文
  • 要求：密钥分发是主要问题。

• 非对称密钥加密：

  • 通信双方，有各自的公钥和私钥。公钥加密的数据，只能用对应的私钥才能解密。
  • 公钥加密，B给A公钥，公钥是用来帮A加密给B的信息的，确保只有B看得懂。
  • 公钥公开，私钥保留。但分发公钥也容易招致中间人攻击。

SSL/TLS工作原理

• 首先对称加密的密钥生成代价比公私钥对的生成代价低得多
• 非对称加密手段传输加密的对称加密密钥，保护该密钥不在网络信道中被窃听。通信双方只需要一次非对称加密，交换对称加密的密钥。

公钥传输的信赖性（如何确认A收到的公钥是B的公钥）

• 中间人攻击

1. 某网站有用于非对称加密的公钥A、私钥A’。
2. 浏览器向网站服务器请求，服务器把公钥A明文给传输浏览器。
3. 中间人劫持到公钥A，保存下来，把数据包中的公钥A替换成自己伪造的公钥B（它当然也拥有公钥B对应的私钥B’）。
4. 浏览器生成一个用于对称加密的密钥X，用公钥B（浏览器无法得知公钥被替换了）加密后传给服务器。
5. 中间人劫持后用私钥B’解密得到密钥X，再用公钥A加密后传给服务器。
6. 服务器拿到后用私钥A’解密得到密钥X。

根本原因是浏览器无法确认收到的公钥是不是网站自己的

如何证明浏览器收到的公钥一定是该网站的公钥？(数字证书)

比如现实生活中，若想证明某身份证号一定是小明的，可以看他身份证，而身份证是由政府作证的，这里的“公理”就是“政府机构可信”，这也是社会正常运作的前提。

CA机构颁发的“身份证”就是数字证书。

CA 会给各个服务器颁发证书，证书存储在服务器上，并附有 CA 的电子签名。

数字证书

网站在使用HTTPS前，需要向CA机构申领一份数字证书，数字证书里含有证书持有者信息、公钥信息等。服务器把证书传输给浏览器，浏览器从证书里获取公钥就行了，证书就如身份证，证明“该公钥对应该网站”。

而这里又有一个显而易见的问题，“证书本身的传输过程中，如何防止被篡改”？即如何证明证书本身的真实性？身份证运用了一些防伪技术，而数字证书怎么防伪呢？解决这个问题我们就接近胜利了！

如何防止数字证书被篡改？（数字签名）

• 我们把证书原本的内容生成一份“签名”，比对证书内容和签名是否一致就能判别是否被篡改。这就是数字证书的“防伪技术”，这里的“签名”就叫数字签名。

数字签名的制作过程：

1. CA机构拥有非对称加密的私钥和公钥。
2. 数字签名 = 证书明文数据hash后的值用CA机构的私钥加密后的值

• 明文和数字签名共同组成了数字证书，这样一份数字证书就可以颁发给网站了。那浏览器拿到服务器传来的数字证书后，如何验证它是不是真的？（有没有被篡改、掉包）
  • 将明文hash后的值 与 签名用CA机构公钥解密后的值比较
• 中间人能否篡改、替换（掉包）该证书？
  • 篡改：中间人无CA的私钥，无法得到明文加密后签名，篡改的证书两值不等。
  • 掉包：中间人用自己合法的CA证书，之后浏览器就会错误地拿到B的证书里的公钥了，这确实会导致上文“中间人攻击”那里提到的漏洞？其实这并不会发生，因为证书里包含了网站A的信息，包括域名，浏览器把证书里的域名与自己请求的域名比对一下就知道有没有被掉包了。（好比你冒充别人，说自己是谁，但递给我你的合法身份证）
  • 会不会存在中间人用真实网站的证书呢？不可能，因为他目的是替换公钥，用真实网站的证书意味着加密后的信息他用自己的私钥读取不了。

怎么证明当前网站的CA机构的公钥是可信的

• 操作系统、浏览器本身会预装一些它们信任的根证书，如果其中会有CA机构的根证书，这样就可以拿到它对应的可信公钥了。
• 实际上证书之间的认证也可以不止一层，可以A信任B，B信任C，以此类推，我们把它叫做信任链或数字证书链。也就是一连串的数字证书，由根证书为起点，透过层层信任，使终端实体证书的持有者可以获得转授的信任，以证明身份。

另外，不知你们是否遇到过网站访问不了、提示需安装证书的情况？这里安装的就是根证书。说明浏览器不认给这个网站颁发证书的机构，那么你就得手动下载安装该机构的根证书（风险自己承担XD）。安装后，你就有了它的公钥，就可以用它验证服务器发来的证书是否可信了。

每次进行HTTPS请求时都必须在SSL/TLS层进行握手传输密钥吗？

显然每次请求都经历一次密钥传输过程非常耗时，那怎么达到只传输一次呢？

服务器会为每个浏览器（或客户端软件）维护一个session ID，在TLS握手阶段传给浏览器，浏览器生成好密钥传给服务器后，服务器会把该密钥存到相应的session ID下，之后浏览器每次请求都会携带session ID，服务器会根据session ID找到相应的密钥并进行解密加密操作，这样就不必要每次重新制作、传输密钥了！

为什么制作数字签名时需要hash一次？

最显然的是性能问题，前面我们已经说了非对称加密效率较差，证书信息一般较长，比较耗时。而hash后得到的是固定长度的信息（比如用md5算法hash后可以得到固定的128位的值），这样加密解密就会快很多。

总结（https工作流程）

1. 客户端发送自己支持的加密规则给服务器，代表告诉服务器要进行连接了
2. 服务器从中选出一套加密算法和数字证书证书发送给浏览器，证书中包含服务器信息，加密公钥，证书的颁发机构。
3. 客户端收到网站的证书之后要做下面的事情：
   1. 验证证书的合法性
   2. 浏览器会生成共享密钥，并用证书中的公钥进行加密，然后发送给服务器
4. 服务器接收到客户端传送来的信息，要求下面的事情：
   1. 用私钥解析出密码
   2. 使用密钥加密消息，回送
   3. 如果计算法hash值一致，握手成功

https绝对安全吗？

由于HTTPS非常的安全，攻击者无法从中找到下手的地方。

但是并非绝对安全。掌握根证书的机构同样可以进行中间人形式的攻击。

https有什么缺点？

1. SSL证书要钱
2. HTTPS协议握手阶段比较费时，影响网站速度，如非必要，没有理由牺牲用户体验。
3. SSL证书通常需要绑定IP，不能在同一IP上绑定多个域名，而一个IP上可能有多个不同网站，IPv4资源不可能支撑这个消耗

ARP协议

ARP是什么

ARP 协议，可以说是在OSI中属于一个偏底层的、非常重要的、又非常简单的通信协议。

1. ARP 协议在协议栈中的位置？ ARP 协议在协议栈中的位置非常重要，在理解了它的工作原理之后，也很难说它到底是网络层协议，还是链路层协议，因为它恰恰串联起了网络层和链路层。国外的大部分教程通常将 ARP 协议放在网络层。

2. ARP 协议解决了什么问题，地位如何？ ARP 协议，全称 地址解析协议（Address Resolution Protocol），它解决的是网络层地址和链路层地址之间的转换问题。因为一个 IP 数据报在物理上传输的过程中，总是需要知道下一跳（物理上的下一个目的地）该去往何处，但 IP 地址属于逻辑地址，而 MAC 地址才是物理地址，ARP 协议解决了 IP 地址转 MAC 地址的一些问题。

3. ARP 工作原理？ 只希望大家记住几个关键词：ARP 表、广播问询、单播响应。

MAC地址

如果说，互联网中每一个资源都由 IP 地址唯一标识（IP 协议内容），那么一切网络设备都由 MAC 地址唯一标识。可以理解为，MAC 地址是一个网络设备真正的身份证号，IP 地址只是一种不重复的定位方式。

MAC 地址具有可携带性、永久性，身份证号永久地标识一个人的身份，不论他到哪里都不会改变。而 IP 地址不具有这些性质，当一台设备更换了网络，它的 IP 地址也就可能发生改变，也就是它在互联网中的定位发生了变化。

最后，记住，MAC 地址有一个特殊地址：FF-FF-FF-FF-FF-FF（全 1 地址），该地址表示广播地址。

ARP协议为什么需要知道MAC地址

因为通过IP地址，这份数据可以到达目的主机所在的局域网，一旦进入了局域网，需要进行数据链路层的转发，那么就需要通过交换机来存储转发了。但是交换机需要利用到MAC地址，没有MAC地址就不知道转给谁了。

其实如果没有填MAC地址的数据是出不去的，第一次发送报文的时候没有填MAC地址是不可能的，如果不知道MAC地址，那么就是全F的广播报文。而且要注意的是每通过一个路由，MAC地址都会改变，但IP地址在传输过程中是永远不改变的。

什么是RARP协议

逆地址解析协议，即RARP，功能和ARP协议相对，其将局域网中某个主机的物理地址转换为IP地址，比如局域网中有一台主机只知道物理地址而不知道IP地址，那么可以通过RARP协议发出征求自身IP地址的广播请求，然后由RARP服务器负责回答。

ARP协议工作原理

ARP表

ARP 协议工作时有一个大前提，那就是 ARP 表。

在一个局域网内，每个网络设备都自己维护了一个 ARP 表，ARP 表记录了某些其他网络设备的 IP 地址-MAC 地址映射关系，该映射关系以 <IP, MAC, TTL> 三元组的形式存储。其中，TTL 为该映射关系的生存周期，典型值为 20 分钟，超过该时间，该条目将被丢弃。

ARP 的工作原理将分两种场景讨论：

1. 同一局域网内的 MAC 寻址；
2. 从一个局域网到另一个局域网中的网络设备的寻址。

同一局域网内的MAC寻址

假设当前有如下场景：IP 地址为137.196.7.23的主机 A，想要给同一局域网内的 IP 地址为137.196.7.14主机 B，发送 IP 数据报文。

再次强调，当主机发送 IP 数据报文时（网络层），仅知道目的地的 IP 地址，并不清楚目的地的 MAC 地址，而 ARP 协议就是解决这一问题的。

1. 主机 A 检索自己的 ARP 表，发现 ARP 表中并无主机 B 的 IP 地址对应的映射条目，也就无从知道主机 B 的 MAC 地址。

2. 主机 A 将构造一个 ARP 查询分组，并将其广播到所在的局域网中。

3. ARP 分组是一种特殊报文，ARP 分组有两类，一种是查询分组，另一种是响应分组，它们具有相同的格式，均包含了发送和接收的 IP 地址、发送和接收的 MAC 地址。

   1. 查询分组中，发送 IP 地址，即为主机 A 的 IP 地址，接收的IP 地址即为主机 B 的 IP 地址
   2. 发送的 MAC 地址也是主机 A 的 MAC 地址，但接收的 MAC 地址绝不会是主机 B 的 MAC 地址（因为这正是我们要问询的！），而是一个特殊值——FF-FF-FF-FF-FF-FF，之前说过，接收的MAC 地址是广播地址，也就是说，查询分组将广播给该局域网内的所有设备。

4. 主机 A 构造的查询分组将在该局域网内广播，理论上，每一个设备都会收到该分组，并检查查询分组的接收 IP 地址是否为自己的 IP 地址，如果是，说明查询分组已经到达了主机 B，否则，该查询分组对当前设备无效，丢弃之。

5. 主机 B 收到了查询分组之后，验证是对自己的问询，接着构造一个 ARP 响应分组，该分组的目的地只有一个——主机 A，发送给主机 A。同时，主机 B 提取查询分组中的 IP 地址和 MAC 地址信息，在自己的 ARP 表中构造一条主机 A 的 IP-MAC 映射记录。

   1. ARP 响应分组具有和 ARP 查询分组相同的构造，不同的是，发送和接受的 IP 地址恰恰相反，发送的 MAC 地址为发送者本身，目标 MAC 地址为查询分组的发送者，也就是说，ARP 响应分组只有一个目的地，而非广播。

6. 主机 A 终将收到主机 B 的响应分组，提取出该分组中的 IP 地址和 MAC 地址后，构造映射信息，加入到自己的 ARP 表中。

1. 主机 A 想要给主机 B 发送 IP 数据报，如果主机 B 的 IP-MAC 映射信息已经存在于主机 A 的 ARP 表中，那么主机 A 无需广播，只需提取 MAC 地址并构造链路层帧发送即可。
2. 目标主机接收到了问询主机构造的问询报文后，将先把问询主机的 IP-MAC 映射存进自己的 ARP 表中，这样才能获取到响应的目标 MAC 地址，顺利的发送响应分组。

总结来说，ARP 协议是一个广播问询，单播响应协议。

不同局域网内的MAC寻址

发送主机 A 和接收主机 B 不在同一个子网中，假设一个一般场景，两台主机所在的子网由一台路由器联通。路由器作为互联设备，具有多个接口，每个接口同样也应该具备不重复的 IP 地址和 MAC 地址。因此，在讨论 ARP 表时，路由器的多个接口都个各自维护一个 ARP 表，而非一个路由器只维护一个 ARP 表。

• 不同点：两次广播问询和单播响应
  • 广播后获得的MAC地址，是本子网内与路由器连接的接口的 MAC 地址。主机 A 将把这个链路层帧，以单播的方式，发送给目标接口。
  • 目标接口接收到了主机 A 发过来的链路层帧，解析，根据目的 IP 地址，查询转发表，将该 IP 数据报转发到与主机 B 所在子网相连的接口上。到此，该帧已经从主机 A 所在的子网，转移到了主机 B 所在的子网了。
  • 路由器接口查询 ARP 表，期望寻找到主机 B 的 MAC 地址。路由器接口如未能找到主机 B 的 MAC 地址，将采用 ARP 协议，广播问询，单播响应，获取到主机 B 的 MAC 地址。
  • 路由器接口将对 IP 数据报重新封装成链路层帧，目标 MAC 地址为主机 B 的 MAC 地址，单播发送，直到目的地。