【八股】计网-计算机网络-秋招

计算机网络

(为什么没有FTP, SMTP, IP, ICMP等协议的内容, 因为这些面试基本不考, 你看了纯纯浪费时间!)

网络基础

OSI和TCP/IP网络分层模型（高）

OSI:应用层，会话层，表示层，传输层，网络层，数据链路层，物理层TCP/IP(4层/5层)：

应用层：通过应用进程交互实现一个特定的网络应用

• 传输层：为网络中的主机提供端到端的数据传输服务（进程之间网络通信）
• 网络层：在多个网络中，分组如何路由和寻址
• 数据链路层：在单个网络的一段链路上如何传输数据帧，以及帧的差错控制
• 物理层：在传输介质上用什么信号传输比特流的问题

数据链路层和物理层又被统称为网络接口层

应用层有哪些常见的协议（高）

HTTP协议（超文本传输协议，网页浏览常用的协议）

• HTTPS协议（HTTP的安全版）
• DHCP 协议（动态主机配置）
• DNS 系统原理（域名系统）
• FTP 协议（文件传输协议）
• SMTP 协议（电子邮件协议）

传输层常见协议 (高)

TCP UDP

网络层协议 (中)

• ARP- IP- ICMP 协议（差错控制）

为何要分层 (高)

• 各层相互独立，只需要关心本层的问题，各层之间不需要关心其他层是如何实现的。类似于做系统也需要分层- 提高了整体的灵活性。类似于高内聚低耦合- 大问题分解化小，类似于做系统进行功能分解

TCP和UDP

TCP和UDP的特点，不同之处？(高)

TCP是面向连接的(传输数据需要建立连接)，UDP是面向无连接的(传输数据不需要建立连接)TCP是可靠传输，传输的数据有序可靠不丢不重。UDP是不可靠传输，只能是最大努力交付。UDP实时性更好，适合高速传输或者对实时性要求比较高的场景TCP适合对可靠性要求较高的场景，如文件传输。TCP传输效率比UDP低，因为TCP传输时需要连接确认重传等机制保证可靠传输。UDP传输效率更高

使用TCP的协议有哪些？使用UDP的协议有哪些？(低)

基于TCP:HTTP,HTTPS,FTP,SMTP,SSH(远程登录会话协议)

基于UDP:DNS,DHCP(动态配置IP地址)

说一下TCP粘包是怎么产生的？怎么解决粘包问题的(中)

TCP传输数据基于字节流，从应用层到TCP传输层的多个数据包是一连串的字节流是没有边界的，而且TCP首部并没有记录数据包的长度，所以TCP传输数据的时候可能会发送粘包和拆包的问题；而UDP是基于数据报传输数据的，UDP首部也记录了数据报的长度，可以轻易的区分出不同的数据包的边界

接下来看下 TCP 传输数据的几种情况，首先第一种情况是正常的，既没有发送粘包也没有发生拆包。

第二种情况发生了明显的粘包现象，这种情况对于数据接收方来说很难处理。

接下来的两种情况发生了粘包和拆包的现象，接收端收到的数据包要么是不完整的要么是多出来一块儿。

造成粘包和拆包现象的原因

• TCP 发送缓冲区剩余空间不足以发送一个完整的数据包，将发生拆包
• 要发送的数据超过了最大报文长度的限制，TCP 传输数据时进行拆包
• 要发送的数据包小于 TCP 发送缓冲区剩余空间，TCP 将多个数据包写满发送缓冲区一次发送出去，将发生粘包
• 接收端没有及时读取 TCP 发送缓冲区中的数据包，将会发生粘包

粘包拆包的解决方法

• 发送端给数据包添加首部，首部中添加数据包的长度属性，这样接收端通过首部中的长度字段就可以知道数据包的实际长度啦
• 针对发送的数据包小于缓冲区大小的情况，发送端可以将不同的数据包规定成同样的长度，不足这个长度的补充 0，接收端从缓冲区读取固定的长度数据这样就可以区分不同的数据包
• 发送端通过给不同的数据包添加间隔符合确定边界，接收端通过这个间隔符合就可以区分不同的数据包。

TCP如何保证可靠性 (中)

• 校验和: TCP报文头有检验和字段，可以用于校验报文是否损坏
• 序列号与确认号: TCP发送端发送数据包的时候会选择一个seq序列号，接收端收到数据包后会检测数据包的完整性与顺序性，可以根据序列号进行排序去重，如果检测通过会响应一个ack确认号表示收到了数据包
• 确认与超时重传机制: 接收方收到报文后就会返回一个确认报文，发送方发送一段时间后没收到确认报文就会进行超时重传。
• 快速重传: 接收方收到比期望序号大的报文段到达时，就会发送一个冗余ACK，指明下一个期待字节的序号，发送端接收到3个以上的重复ACK，TCP就意识到数据发生丢失，需要重传- 流量控制: 当接收方来不及处理发送方的数据，能通过滑动窗口，提示发送方降低发送的速率，防止包丢失- 拥塞控制: 当网络拥塞时，通过拥塞窗口，减少数据的发送，防止包丢失。

TCP流量控制 (中)

TCP利用滑动窗口实现流量控制。流量控制是为了控制发送方发送速率，保证接收方来得及接收。

接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将窗口字段设置为0，则发送方不能发送数据

TCP拥塞控制 (中)

在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。这种情况就叫拥塞。拥塞控制就是为了防止过多的数据注入到网络中，这样就可以使网络中的路由器或链路不致过载。

拥塞控制所要做的都有一个前提，就是网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程，涉及到所有的主机，所有的路由器，以及与降低网络传输性能有关的所有因素。

相反，流量控制往往是点对点通信量的控制，是个端到端的问题。流量控制所要做到的就是抑制发送端发送数据的速率，以便使接收端来得及接收。

为了进行拥塞控制，TCP发送方要维持一个拥塞窗口(cwnd)的状态变量。拥塞控制窗口的大小取决于网络的拥塞程度，并且动态变化。发送方让自己的发送窗口取为拥塞窗口和接收方的接受窗口中较小的一个。

慢开始算法 - Slow Start

所谓慢开始/慢启动，也就是TCP连接刚建立，一点一点地提速，试探一下网络的承受能力，以免直接扰乱了网络通道的秩序。

慢启动算法：

1. 连接建好的开始先初始化拥塞窗口cwnd大小为1，表明可以传一个MSS(最大报文段长度)大小的数据。

2. 每当收到ACK确认报文(每经过一个往返时延RTT)，cwnd大小直接乘以2，呈指数让升，也就是一次发送2^n个报文

3. 还有一个ssthresh，是一个门限值(默认为16)，当cwnd >= ssthresh时，就会进入“拥塞避免算法”

拥塞避免算法 - Congestion Avoidance

如同前边说的，当拥塞窗口大小cwnd大于等于慢启动阈值ssthresh后，就进入拥塞避免算法。算法如下：

1. 让拥塞窗口cwnd缓慢增大，即每经过一个往返时间RTT就把发送放的cwnd加1.加法增大

2. 过了慢启动阈值后，拥塞避免算法可以避免窗口增长过快导致窗口拥塞，而是缓慢的增加调整到网络的最佳值。

快重传与快恢复

1. cwnd大小缩小为当前的一半
2. ssthresh设置为缩小后的cwnd大小
3. 然后进入拥塞避免算法(加法增大)

三次握手（高）

ROUND1:

ROUND1: 客户端发送连接请求报文段，无应用层数据。SYN=1，seq=x(随机)

ROUND2:

服务器端为该TCP连接分配缓存和变量，并向客户端返回确认报文段，允许连接，无应用层数据。

SYN=1，ACK=1，seq=y(随机)，ack=x+1

ROUND3:

ROUND3: 客户端为该TCP连接分配缓存和变量，并向服务器端返回确认的确认，可以携带数据。

SYN=0，ACK=1，seq=x+1，ack=y+1

建立一个TCP连接需要“三次握手”，缺一不可：

• 一次握手:客户端发送带有SYN（SEQ=x）标志的数据包->服务端，然后客户端进入SYN_SEND状态，等待服务器的确认；- 二次握手:服务端发送带有SYN+ACK(SEQ=y,ACK=x+1)标志的数据包->客户端,然后服务端进入SYN_RECV状态。- 三次握手:客户端发送带有带有ACK(ACK=y+1)标志的数据包->服务端，然后客户端和服务器端都进入ESTABLISHED状态，完成TCP三次握手

为什么一定要三次握手，两次不行吗（高）

三次握手的目标是要确认客户端和服务端双方的收发能力没有问题，都能发送接收数据.就好比两个人交流前需要确认，双方都不是聋子，都不是哑巴.如果有一方聋或者哑那就无法交流

第一次握手：客服端发消息给服务端

服务端收到消息，此时服务端确认了自己接收能力没问题，客户端的发送能力没问题

第二次握手：服务端发给客户端

客户端收到消息.此时客户端能收到消息，说明自己之前发消息一定发出去了，说明客户端的发送能力没问题。而现在收到了服务端发的数据，那么说明服务端一定收到了数据.故服务端的接收能力没问题。那此时收到了服务端发送的数据，说明服务端的发送能没问题自己（客户端）的接收能没问题。此时，客户端确认了双发的收发能力都没问题。这也是为什么第三次握手的时间，客户端能够携带数据

第三次握手：客户端发消息给服务端.（客户端可以携带数据）

• 为什么需要第三次握手？因为第二次握手完成后，客户端确认了双发的收发能力都没问题。但是服务端只知道自己能收，对方能发，无法确认双方的收发能力都没问题。
• 当第三次握手完毕，服务端才能确双发的收发能力都没问题。

四次挥手 (高)

为什么要四次挥手？

举个例子：A和B打电话，通话即将结束后。

1. 第一次挥手：A说“我没啥要说的了”

2. 第二次挥手：B回答“我知道了”，但是B可能还会有要说的话，A不能要求B跟着自己的节奏结束通话

3. 第三次挥手：于是B可能又巴拉巴拉说了一通，最后B说“我说完了”

4. 第四次挥手：A回答“知道了”，这样通话才算结束

为什么不能把服务器发送的ACK和FIN合并起来，变成三次挥手？

因为服务器收到客户端断开连接的请求时，可能还有一些数据没有发完，这时先回复ACK，表示接收到了断开连接的请求。等到数据发完之后再发FIN，断开服务器到客户端的数据传送

如果第二次挥手时服务器的ACK没有送达客户端，会怎样？

客户端没有收到ACK确认，会重新发送FIN请求。

为什么要等待2MSL？

因为如果第四次挥手客户端发送的确定报文丢失，服务器就收不到确认报文，会触发超时重传机制，服务器会重传第三次挥手的连接释放报文段。若等待2MSL之后，就能保证服务端收到了确认报文段，关闭了连接。

为什么是两倍的最长报文寿命？

因为客户端第三次挥手发送确认报文段，该报文段到服务器端最长时间是1MSL。若丢失，服务端在1MSL后超时重传第三次挥手的连接释放报文段，这个报文段到客户端的最大时间又是1MSL。所以要等待2MSL，没有收到超时重传的连接释放报文段，就说明确认报文段服务端收到了，连接正确释放了。

HTTP

在浏览器中输入url地址后显示主页的过程？（中）

1. 根据域名，进行DNS域名解析；2. 拿到解析的IP地址，建立TCP连接；3. 向IP地址，发送HTTP请求；4. 服务器处理请求，返回响应结果；5. 关闭TCP连接；6. 浏览器解析HTML；7. 浏览器布局渲染；

什么是跨域，如何解决跨域 (中)

• 跨域来源于浏览器的同源策略，浏览器要检查协议、域名、端口号是否一致，不一致就会跨域。
• 前端一般可以用JSONP或者代理服务器解决- 后端一般可以用设置请求头来解决，Springboot项目中添加一个@CrossOrigin 注解即可

HTTP1.0和HTTP1.1(中)

长连接

• HTTP1.0是短连接：浏览器每次请求都需要和服务器建立一个TCP连接，一次请求，一次响应后，就会断开连接- HTTP1.1是长连接：在一个TCP连接上可以传送多个HTTP请求和响应，这就减少了多次建立和关闭连接的延迟
• 无流水的长连接：客户端收到上一个请求的响应后才能发送下一个请求
• 有流水的长连接：客户端不用等待上一个请求的响应也能发送下一个请求

缓存

• HTTP1.1引入了更多可供选择的缓存头来控制缓存策略

请求头

• HTTP1.0：请求头相对简单，功能有限。它支持的请求方法较少，常见的有GET、POST和HEAD等。
• HTTP1.1：新增了一些请求方法，如PUT、DELETE、OPTIONS、TRACE等

带宽优化及传输

• HTTP 1.0: 不支持请求头压缩和分块传输。当传输大文件时，需要等待整个文件内容全部传输完成后才能进行处理。
• HTTP 1.1: 支持分块传输（Chunked Transfer Encoding）。服务器可以将响应数据分成多个块进行传输，每个块都有一个表示自身长度的头部，客户端可以在接收部分数据后就开始处理，而不必等待整个响应完成。同时，HTTP 1.1 还支持请求头压缩，减少了传输的数据量

HTTP的长连接是什么？ (中)

HTTP协议采用的是请求

• 应答的模式，也就是客户端发起了请求，服务端才会返回响应，一来一回

短连接：一次连接只能请求一次资源

• HTTP是基于TCP传输协议实现的，客户端与服务端要进行HTTP通信前，需要先建立TCP连接- 然后客户端发送HTTP请求，服务端收到后就返回响应，至此请求-应答的模式就完成了，随后就会释放TCP连接- 这就是短连接

长连接：一次TCP连接可以发送多个请求，多次应答

• HTTP长连接的特点是，只要任意一端没有明确提出断开连接，则保持TCP连接状态，可以多次发送请求.

HTTP/2.0和HTTP1.1有什么区别 (低)

传输格式变化，采用了新的二进制格式

• HTTP1.X的解析都是基于文本，文本的表现形式多样，不利于健壮性考虑

• HTTP2.0 采用二进制，只认0/1组合，实现更加快的方法，健壮性更加完善

多路复用连接共享

• HTTP 1.1：虽然支持持久连接，但同一时间一个TCP连接只能处理一个请求，后续请求需要等待前面的请求处理完成才能发送和处理。为了提高并发性能，浏览器通常会同时打开多个TCP连接来处理多个请求，但这会增加服务器的负担和网络拥塞的风险
• HTTP 2.0：引入了多路复用机制，允许在一个TCP连接上同时并行发送多个请求和响应，并且这些请求和响应可以交错进行，互不干扰。每个请求和响应都有一个唯一的流标识符，通过流标识符可以将不同的帧正确地组装成完整的请求和响应。多路复用大大提高了连接的利用率和传输效率，减少了延迟

头部压缩

• HTTP 1.1：请求和响应的头部通常包含大量的重复信息，如User-Agent、Cookie等，而且每次请求都需要重复发送这些头部信息，导致了不必要的带宽浪费
• HTTP 2.0：使用压缩算法对头部信息进行压缩。从而显著减少了头部信息的传输量，降低了带宽消耗和延迟

HTTP为什么不安全？（高）

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

• 窃听风险，比如通信链路上可以获取通信内容
• 篡改风险，比如强制植入垃圾广告
• 冒充风险，比如冒充京东淘宝等网站

HTTP和HTTPS区别 (高)

HTTP和HTTPS区别（高）- HTTP是超文本传输协议，信息是明文传输，存在安全风险的问题- HTTPS则解决HTTP不安全的缺陷，在TCP和HTTP网络层之间加入了SSL/TLS安全协议，使得报文能够加密传输。

• HTTP连接建立相对简单，TCP三次握手之后便可进行HTTP的报文传输。而HTTPS在TCP三次握手之后，还需进行SSL/TLS的握手过程，才可进入加密报文传输
• 两者的默认端口不一样，HTTP默认端口号是80，HTTPS默认端口号是443。
• HTTPS协议需要向CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的

SSL/TLS怎么确保安全通信，HTTPS怎么保证安全？(高)

SSL和TLS协议通过以下方式确保安全通信

• 加密：使用加密算法对传输的数据进行加密，防止第三方截取和读取敏感信息
• 身份验证：使用数字证书验证通信双方的身份，确保数据传输的可信性
• 数据完整性：通过使用消息摘要算法，确保传输的数据在传输过程中没有被篡改或损坏

什么是对称加密和非对称加密 (中)

对称加密也称为私钥加密，使用相同的密钥来进行加密和解密非对称加密：使用一对不同但相关的密钥：公钥和私钥。公钥用于加密数据，私钥用于解密数据

HTTPS是如何建立连接的 (高)

1. 客户端发送连接请求：当客户端想要与服务器建立HTTPS连接时，它会发送一个连接请求到服务器的443端口，表明它想要使用HTTPS进行通信

2. 服务器响应：服务器收到连接请求后，会发送一个CA数字证书给客户端。这个证书包含了服务器的公钥、证书的颁发者信息以及其他相关信息

3. 客户端验证证书：客户端接收到服务器发送的数字证书后，会验证证书的合法性。这个过程包括验证证书的签名、证书是否过期、是否与预期域名匹配等

4. 生成会话密钥：如果证书验证成功，客户端会生成一个用于该连接的随机会话密钥（对称密钥）。这个密钥将用于加密通信数据

5. 用公钥加密会话密钥：客户端使用服务器的公钥，将生成的会话密钥进行加密，并将加密后的会话密钥发送给服务器

6. 服务器解密会话密钥：服务器使用自己的私钥对客户端发送的加密会话密钥进行解密，获得会话密钥

7. 建立安全通信：从此时开始，客户端和服务器都有了相同的会话密钥，他们使用对称加密算法（如AES）来加密和解密通信数据，保证了通信的隐私性和完整性。

DNS

DNS是什么(中)

DNS要解决的是域名和IP地址的映射问题，可以将域名解析为IP地址

DNS解析流程(中)

1. 查询浏览器缓存是否有该域名对应的IP地址

2. 如果浏览器缓存中没有，会去计算机本地的Host文件中查询是否有对应的缓存3.如果Host文件中也没有则会向本地的DNS服务器发送一个DNS查询请求

3. 如果本地DNS解析器有该域名的ip地址，就会直接返回，如果没有缓存该域名的解析记录，它会向根DNS服务器发出查询请求。根DNS服务器并不负责解析域名，但它能告诉本地DNS解析器应该向哪个顶级域（.com/.net/.org）的DNS服务器继续查询

4. 本地DNS解析器接着向指定的顶级域名DNS服务器发出查询请求。顶级域DNS服务器也不负责具体的域名解析，但它能告诉本地DNS解析器应该前往哪个权威DNS服务器查询下一步的信息

5. 本地DNS解析器最后向权威DNS服务器发送查询请求。权威DNS服务器是负责存储特定域名和IP地址映射的服务器。当权威DNS服务器收到查询请求时，它会查找"example.com"域名对应的IP地址，并将结果返回给本地DNS解析器

6. 本地DNS解析器将收到的IP地址返回给浏览器，并且还会将域名解析结果缓存在本地，以便下次访问时更快地响应

7. 浏览器使用该IP地址与目标服务器建立连接

DNS的底层使用TCP还是UDP？(中)

DNS基于UDP协议实现，使用UDP协议进行域名解析和数据传输。因为基于UDP实现DNS能够提供低延迟、简单快速、轻量级的特性，更适合DNS这种需要快速响应的域名解析服务。

• 低延迟：UDP是一种无连接的协议，不需要在数据传输前建立连接，因此可以减少传输时延，适合DNS这种需要快速响应的应用场景
• 简单快速：UDP相比于TCP更简单，没有TCP的连接管理和流量控制机制，传输效率更高，适合DNS这种需要快速传输数据的场景
• 轻量级：UDP头部较小，占用较少的网络资源，对于小型请求和响应来说更加轻量级，适合DNS这种频繁且短小的数据交换

尽管UDP存在丢包和数据包损坏的风险，但在DNS的设计中，这些风险是可以被容忍的。DNS使用了一些机制来提高可靠性，例如查询超时重传、请求重试、缓存等，以确保数据传输的可靠性和正确性。

HTTP到底是无状态的吗/解释一下HTTP的无状态(中)

• HTTP是无状态的，每个请求都是独立的，服务器不会在多个请求之间保留关于客户端状态的信息
• 在每个HTTP请求中，服务器不会记住之前的请求或会话状态，因此每个请求都是相互独立的，这就导致了当用户登录后，再次发起请求，服务不知道该用户是谁，有没有登录。
• 所以http需要通过一些机制来实现状态保持，其中最常见的方式是使用Cookie和Session来跟踪用户状态。
• 通过在客户端存储会话信息或状态信息，服务器可以识别和跟踪特定用户的状态。就能知道用户是否登录，是哪个用户发起了请求。

cookie和session的区别（中）

Cookie和Session都是Web开发中用于跟踪用户状态的技术，但它们在存储位置、数据容量、安全性以及生命周期等方面存在显著差异：

存储位置：Cookie的数据存储在客户端（通常是浏览器）。当浏览器向服务器发送请求时，会自动附带Cookie中的数据。Session的数据存储在服务器端。服务器为每个用户分配一个唯一的SessionID，这个ID通常通过Cookie或URL重写的方式发送给客户端，客户端后续的请求会带上这个SessionID，服务器根据ID查找对应的Session数据。

• 数据容量：单个Cookie的大小限制通常在4KB左右，而且大多数浏览器对每个域名的总Cookie数量也有限制。由于Session存储在服务器上，理论上不受数据大小的限制，主要受限于服务器的内存大小。

• 安全性：Cookie相对不安全，因为数据存储在客户端，容易受到XSS(跨站脚本攻击）的威胁。不过，可以通过设置HttpOnly属性来防止JavaScript访问，减少XSS攻击的风险，但仍然可能受到CSRF(跨站请求伪造)的攻击。Session通常认为比Cookie更安全，因为敏感数据存储在服务器端。但仍然需要防范Session劫持(通过获取他人的SessionID)和会话固定攻击。

• 生命周期：Cookie可以设置过期时间，过期后自动删除。也可以设置为会话Cookie，即浏览器关闭时自动删除。Session在默认情况下，当用户关闭浏览器时，Session结束。但服务器也可以设置Session的超时时间，超过这个时间未活动，Session也会失效。

• 性能：使用Cookie时，因为数据随每个请求发送到服务器，可能会影响网络传输效率，尤其是在Cookie数据较大时。使用Session时，因为数据存储在服务器端，每次请求都需要查询服务器上的Session数据，这可能会增加服务器的负载，特别是在高并发场景下。

JWT令牌和Session方式有什么区别？（低）

JWT

• 无状态性：JWT是无状态的令牌，不需要在服务器端存储会话信息。因为JWT令牌中包含了所有必要的信息，如用户身份、权限等。这使得JWT在分布式系统中更加适用，可以方便地进行扩展和跨域访问

• 安全性：JWT使用密钥对令牌进行签名，确保令牌的完整性和真实性。只有持有正确密钥的服务器才能对令牌进行验证和解析。这种方式比传统的基于会话和Cookie的验证更加安全，有效防止了CSRF攻击

• 跨域支持：JWT令牌可以在不同域之间传递，适用于跨域访问的场景。通过在请求的头部或参数中携带JWT令牌，可以实现无需Cookie的跨域身份验证- 踢人下线：JWT只是一个字符串，颁发后存在客户端，无法立刻销毁，所以无法做到踢人下线的功能

Session

• 有状态：session是有状态的，需要存在服务端.
• 不支持跨域：session需要cookie，跨域请求不携带cookie，所以跨域时session无法使用。一般情况会生成一个唯一token放在请求头中，替代cookie-
• 踢人下线：session在服务端保存，需要踢人下线，直接清除session即可。

ARP

MAC地址，IP地址，ARP协议（中）

IP地址：每一台计算机使用的IP地址，是由ISP（指提供Internet服务的公司，比如电信、网通、移动等）负责分配的。ISP会动态分配一个IP地址。对于目前广泛使用IPv4地址，它的资源是非常有限的，一台计算机一个IP地址是不现实的，往往一个局域网才拥有一个IP地址。计算机之间进行通信，必须要知道对方的IP地址。实际上，计算机发出的数据包中已经附带了IP地址，把数据包发送给路由器以后，路由器会根据IP地址找到位置。通常情况下，一个局

域网才能拥有一个独立的 IP，换句话说，IP 地址只能定位到一个局域网，无法定位到具体的某个设备。

MAC地址：真正能唯一标识设备的是 MAC 地址，也称为局域网地址，以太网地址或物理地址，硬件地址。计算机出厂时，MAC 地址已经被写死到网卡里面了，每个网卡的 MAC 地址在全世界都是独一无二的。局域网中的路由器/交换机会记录每台计算机的 MAC 地址。当一台计算机通过网络向另一台计算机发送数据时，数据包中除了会附带对方的 IP 地址，还会附带对方的 MAC 地址。当数据包达到局域网以后，路由器/交换机会根据数据包中的 MAC 地址找到对应的计算机，然后把数据包转交给它，这样就完成了数据的传递。

总而言之，IP 地址解决的是数据在外网（因特网、互联网）的传输问题，MAC 地址解决的是数据在内网（局域网）中的传输问题。对于一台计算机来说，MAC 地址是必须有的，IP 地址可有可无。如果两台通信的计算机处于同一个局域网，那么理论上只凭借 MAC 地址就可以找到对方；如果两台计算机跨网传输数据，那么 IP 地址和 MAC 地址缺一不可。

ARP 协议解决了什么问题？（低）

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

ARP的过程（低）

ARP(Address Resolution Protocol)协议

• 地址解析协议. 根据IP地址获取物理地址的一个协议。
• 主机发送信息时将包含目标IP地址的ARP请求广播到局域网络上的所有主机，并接收返回消息，以此确定目标的物理地址；
• 收到返回消息后将该IP地址和物理地址存入本机ARP缓存中并保留一定时间，下次请求时直接查询ARP缓存以节约资源。
• 地址解析协议是建立在网络中各个主机互相信任的基础上的，局域网络上的主机可以自主发送ARP应答消息，其他主机收到应答报文时不会检测该报文的真实性就会将其记入本机ARP缓存