计算机网络---基础面试版持续更新

1.IPV4和IPV6的区别：

追问：地址配置的意义是？
答：

• IPv4 依赖 DHCP 服务器
  设备开机后会“喊一声”找DHCP服务器（相当于小区物业），由物业从地址池里临时分配一个空闲地址给你，并告诉你网关、DNS等所有上网信息。这是“集中派发”模式，如果物业（DHCP服务器）宕机，新设备就上不了网。

• IPv6 支持 SLAAC（无状态地址自动配置）
  设备不再完全依赖服务器，而是靠自己“拼凑”出地址。
  它从路由器（相当于小区大门）拿到网络前缀（小区名），再结合自己网卡的MAC地址（你的门牌号），自己组合成一个全球唯一的IP地址。这是“自助生成”模式，设备即插即用，减轻了服务器负担，即使没有DHCP服务器，设备之间也能通信。

追问：NAT技术讲解一下
答：例子：

• 步骤1：发出请求
  电脑生成一个数据包，源IP是 192.168.1.5，源端口是 12345（随机生成），目标IP是百度的 220.181.38.148。数据包首先到达你家路由器。

• 步骤2：NAT转换（关键）
  路由器收到后，会把数据包里的源IP替换成路由器的公网IP（比如 1.2.3.4），并修改源端口（比如把 12345 映射为路由器的 54321）。
  同时，路由器会在内存里记录一张映射表：内网(192.168.1.5:12345) <-> 公网(1.2.3.4:54321)。

• 步骤3：接收响应
  百度服务器回复数据包时，目标IP是 1.2.3.4，目标端口是 54321。路由器收到后，查询映射表，把目标IP改回 192.168.1.5，端口改回 12345，然后转发给你的电脑。

整个过程对电脑和百度服务器来说完全透明——电脑以为自己在和百度直接通信，百度也以为自己在和 1.2.3.4 直接通信。

2.ip寻址全流程
答：

假设数据包要从 你的电脑 发给 北京的百度服务器，路径要经过：你家路由器 -> 省中心 -> 华北枢纽 -> 北京分拨中心 -> 百度服务器。

整个过程是这样的（每一步都包含IP决策 + MAC寻址）：

第1跳（你的电脑 -> 你家路由器）

• 查路由表：你的电脑算出目标IP是外网，决定下一跳IP是 网关（192.168.1.1）。

• MAC寻址：你的电脑在局域网内发ARP广播：“谁是 192.168.1.1？请告诉我你的MAC！”

• 拿到MAC后：电脑把数据帧的目标MAC填成“路由器LAN口的MAC”，发出数据。

第2跳（你家路由器 -> 省中心）

• 查路由表：你家路由器收到包，解封装看到目标IP（百度），查路由表发现下一跳IP是 省中心路由器（比如 10.0.0.1）。

• MAC寻址：你家路由器在它连接的外部广域网链路上发ARP（或类似协议），问：“谁是 10.0.0.1？请告诉我你的MAC！”

• 拿到MAC后：路由器把数据帧的 源MAC改成自己WAN口的MAC，目标MAC改成省中心路由器的MAC，然后发出去。

第3跳（省中心 -> 华北枢纽）

• 查路由表：省中心查表，发现去北京要交给 华北枢纽（下一跳IP 10.0.1.1）。

• MAC寻址：省中心在对应的链路上ARP询问华北枢纽的MAC。

• 拿到MAC后：丢弃旧的MAC头部，重新封装——源MAC改成省中心出口，目标MAC改成华北枢纽入口。

...（中间每一跳都重复上述过程）...

最后一跳（北京分拨中心 -> 百度服务器）

• 查路由表：北京分拨中心查表，发现目标IP 14.215.177.39 属于自己直连的局域网（不需要再转给别的路由器了）。

• MAC寻址：它在内部局域网上广播：“谁是 14.215.177.39？请把你的MAC给我！”

• 拿到MAC后：把数据帧的目标MAC改成百度服务器网卡的MAC，完成最终投递。

这个是与ai对话得到的，比较通俗易懂
追问：讲解一下ARP?
答：

ARP既不是纯粹的IP层协议，也不是链路层协议，它位于网络层（IP）和数据链路层（MAC）之间，充当翻译器。

• 它的任务：将IP地址（逻辑地址）解析为MAC地址（物理地址）。

• 适用范围：仅限同一个广播域（同一网段/同一VLAN），路由器不转发ARP广播。

流程：

一、在发送方（请求者）眼里：如何发起转换？

当你的电脑（IP 192.168.1.5，MAC AA:AA）需要给网关（IP 192.168.1.1）发数据，但本地ARP缓存为空时，转换流程如下：

第1步：构造ARP请求帧（把“我要问”翻译成“硬件帧”）

• 网络层（IP模块） 把“目标IP = 192.168.1.1”这个需求交给ARP模块。

• ARP模块 把需求打包成ARP报文（填入请求帧）：

  • 操作码（op）= 1（表示Request）

  • 发送端IP = 192.168.1.5，发送端MAC = AA:AA

  • 目标IP = 192.168.1.1，目标MAC = 00:00:00:00:00:00（留空占位）

第2步：交给数据链路层封装成帧（套上“信封”）

• 以太网驱动给这个ARP报文套上帧头：

  • 源MAC = AA:AA

  • 目标MAC = FF:FF:FF:FF:FF:FF（广播地址，即发给局域网所有人）

  • 帧类型 = 0x0806（表示“这不是普通IP包，是ARP消息”）

第3步：通过网卡发出去

• 网卡把这个广播帧发到网线上（或Wi-Fi空口）。

二、在接收方（响应者）眼里：如何完成转换？

局域网内所有设备都收到了这个广播帧，但只有网关（192.168.1.1）会做出响应：

第1步：解封并判断“是不是找我的”

• 网关网卡收到帧，剥离以太网帧头，看到帧类型是 0x0806，交给ARP模块处理。

• ARP模块解包报文，看到“目标IP = 192.168.1.1”，发现与自己匹配。

第2步：构造ARP回复帧（把“我是谁”填回去）

• 网关的ARP模块 重新打包成ARP回复报文：

  • 操作码（op）= 2（表示Reply）

  • 发送端IP = 192.168.1.1，发送端MAC = BB:BB

  • 目标IP = 192.168.1.5，目标MAC = AA:AA（即把你之前发来的请求帧里的“发送端MAC”原样抄回去）

第3步：封装成单播帧（直接回给你，不广播）

• 以太网驱动给这个回复报文套上帧头：

  • 源MAC = BB:BB

  • 目标MAC = AA:AA（注意：这里是单播，不是广播）

  • 帧类型 = 0x0806

第4步：发送出去

• 网关网卡将这个单播帧直接发回给你的网卡
   

3.204 409 410状态码的含义
答：204 操作码是HTTP协议中的一个成功状态码，全称是 204 No Content。它最核心的含义就是：服务器已成功处理了你的请求，但不需要返回任何内容，你（客户端）也无需离开当前页面
 

• 409 Conflict (冲突)

  • 含义：请求无法完成，因为它与服务器当前状态的某个规则发生了冲突。服务器通常会在响应体中说明冲突的具体原因。

  • 典型场景：

    1. 版本冲突 (乐观锁)：编辑一个Wiki页面时，你基于V1版本修改，但提交时资源已被其他用户更新为V2。服务器会返回409，提示你先获取最新版本再修改。

    2. 资源状态不允许：尝试删除一个非空的文件夹，或关闭一个已处于“关闭”状态的订单，服务器都会返回409。

    3. 唯一性约束冲突：注册时，你提交的用户名已被他人占用。

  • 客户端应对：你需要读取错误信息，修正请求（如更新本地版本、更改操作）后重试。

• 410 Gone (已消失)

  • 含义：资源曾经存在，但服务器已将其永久删除，并且不会提供任何转发或新地址。这是一个永久性的状态。

  • 典型场景：

    1. 资源被永久清理：用户主动删除了自己的某个数据，且服务端彻底清除了该记录，不保留任何历史版本。

    2. 服务或功能下线：某个API版本（如/api/v1/）被彻底废弃，不再支持，且没有迁移到新地址的计划。

    3. 限时活动资源过期：一个限时促销活动的专属页面，在活动结束后被永久删除。

  • 客户端应对：收到410后，客户端通常应停止自动请求该URI，并直接通知用户或删除本地的相关链接。搜索引擎看到410后也会快速移除该URL的索引。

4.RSA算法
答：

• 核心原理：大数分解难题：RSA的安全性基于一个数学难题：对极大整数进行因数分解极其困难。简单说，你可以轻松算出两个大素数的乘积，但反过来，仅凭这个乘积去找出那两个素数，却几乎是不可能的。

追问:了解SSL/TSL吗 他是什么加密形式，RSA算法被运用到了吗？
答：

这个阶段的目标是在不安全的网络中，安全地协商出一个只有通信双方知道的临时密钥。主要流程如下（以TLS 1.2及更早版本中常见的RSA密钥交换为例）：

1. 客户端发起请求 (ClientHello)：客户端（如浏览器）发送一个“ClientHello”消息，包含它支持的TLS版本、一个客户端随机数，以及它支持的所有加密算法套件列表。

2. 服务器回应 (ServerHello)：服务器从列表中选取一个双方都支持的加密套件，并回复“ServerHello”消息，包含一个服务器随机数，同时附上自己的数字证书。这个证书相当于服务器的“身份证”，里面包含了服务器的公钥。

3. 客户端验证证书并生成预主密钥：客户端验证服务器证书是否由受信任的机构颁发、是否有效。验证通过后，客户端会再生成一个随机数，称为预主密钥，并使用从证书中获取的服务器公钥对其进行加密，然后发送给服务器。这个过程利用了非对称加密：公钥加密的数据，只能用配对的私钥解开。

4. 服务器解密获取预主密钥：服务器收到加密的预主密钥后，使用自己的私钥进行解密。这样，客户端和服务器就都掌握了三个关键信息：客户端随机数、服务器随机数和预主密钥。

5. 生成“会话密钥”：通信双方使用相同的算法，将上述三个随机数作为输入，计算生成一个对称加密的“会话密钥”（Session Key）。至此，用于本次通信的密钥协商完成。
   
   其中 RSA保证的是预主密钥的安全传输，最后得到了会话密钥就开启了对称加密即均使用同一个密钥进行加密解密
   所以SSL/TSL过程是非对称+对称加密两种形式

5.SSL/TSL TSL1.2 TSL1.3的区别
答：

SSL/TLS通常是对整个安全协议体系的统称，而TLS 1.2和TLS 1.3是这个体系中两个具体的、前后承接的版本。目前行业的最佳实践是完全禁用所有版本的SSL及TLS 1.0/1.1，并在服务器上同时启用TLS 1.2和TLS 1.3，以确保安全与兼容。

2. 性能：从2-RTT到1-RTT的跃升

这是两者最直观的区别，直接影响到用户体验。

• TLS 1.2 完整握手 (2-RTT)：需要两次网络往返才能完成密钥协商并开始传输数据。第一次往返交换Hello消息和证书，第二次往返交换密钥并确认，总体延迟较高。

• TLS 1.3 完整握手 (1-RTT)：将密钥交换步骤提前到第一次往返中完成。客户端在ClientHello中直接发送密钥交换参数，服务器在ServerHello中回复。因此，一次往返后，双方就计算出了会话密钥，并可以立即开始传输加密数据，连接速度提升显著。

3. 安全：从“复杂选项”到“默认安全”

这是TLS 1.3最核心的改进，它通过简化设计，从根本上解决了许多因配置错误导致的安全问题。

• 算法与套件：TLS 1.2支持多种算法，但其中不乏不安全的（如RC4、3DES）或因配置不当而存在风险的（如RSA密钥交换、CBC模式）。TLS 1.3则直接移除了所有有问题的算法和模式，只保留了少量现代且安全的密码套件（如TLS_AES_256_GCM_SHA384），强制要求使用AEAD认证加密。

• 前向保密 (PFS)：这是两者的一个关键区别。在TLS 1.2中，是否使用能提供PFS的密钥交换算法（如ECDHE）是可选的；而在TLS 1.3中，PFS成为了强制要求，所有密钥交换都必须使用（EC）DHE算法。这确保了即使服务器的长期私钥泄露，也无法解密过去的通信记录。

• 握手加密：TLS 1.2的握手过程在证书交换前大多是明文传输。TLS 1.3则加密了除ClientHello和ServerHello初始协商之外的所有握手消息，包括服务器的证书，更好地保护了通信双方的隐私。
  
  这部分只要知道性能优化就行，算法套件优化这部分过难，面试不做考虑跳过即可
   

7.http3的流程
答：

1. 首次连接：1-RTT 快速握手

当客户端首次与一个 HTTP/3 服务器建立连接时，整个过程只需要一次网络往返（1-RTT）：

• 第一次往返（1-RTT）：

  1. 客户端 -> 服务器：客户端发送一个 ClientHello 消息，其中同时包含了 QUIC 传输层参数和 TLS 1.3 的密钥交换参数。

  2. 服务器 -> 客户端：服务器收到后，直接回复 ServerHello 以及证书等加密握手消息。此时，双方已经计算出了用于加密数据的密钥。

• 连接完成：自此之后，客户端和服务器就可以立即开始发送加密的 HTTP 请求和响应数据了。

与 TCP + TLS 1.2 需要 2-3 个 RTT 相比，这大大降低了连接建立的延迟。

2. 连接复用：0-RTT 极速恢复

对于曾连接过的服务器，HTTP/3 支持 0-RTT (零往返时间) 连接恢复。客户端可以利用之前协商好的参数，在发送第一个数据包时就直接带上加密的 HTTP 请求，实现了真正的“秒开”，连接耗时几乎为零。

追问：http3不是可以实现切换网络不卡顿吗 为什么
答：

• 问题：TCP连接是由“IP地址+端口号”绑定的。一旦你从Wi-Fi切换到移动网络，IP地址变了，TCP连接就会中断。

• 解决方案：QUIC的连接ID独立于IP地址和端口。当网络切换时，客户端和服务器之间仅需通过新的网络路径发送一个包含原连接ID的包，就能立即将已有连接迁移到新路径上，而无需重新握手。这个过程对应用层完全透明，你可以从Wi-Fi走到4G区域，视频通话或下载任务依然流畅进行，不会中断
   

追问：http3不是可以避免表头阻塞吗 解释一下
答：

🚗 HTTP/1.0：单行道，一个接一个

HTTP/1.0就像一个单行道，特点是每个请求都必须排队，等前一个完全处理完，才能发下一个。

• 阻塞场景：你打开一个包含3张图片的网页。浏览器会先请求HTML，等HTML下载完，才开始请求图片1，图片1下载完，再请求图片2……后面的任务只能干等着。

• 核心问题：这种模式极大地浪费了网络带宽，网页加载缓慢，体验很差。

🏎️ HTTP/1.1：多条单行道，但各自独立

为了解决HTTP/1.0的低效，HTTP/1.1引入了“持久连接”和“管道化”。

• 持久连接：允许在一个TCP连接上发送多个HTTP请求，不必每次请求都重新建立连接。

• 管道化（Pipelining）：更进一步，客户端可以不用等上一个请求的响应，就连续发送多个请求。这就像是开了多个单行道，但问题是每个通道内部还是顺序的。

• 阻塞场景：这好比你在一个窗口排队办事。你一次性把几个待办申请单都递进去，理论上可以节省时间。但问题是，窗口工作人员（服务器）必须按顺序处理。如果第一个申请（比如第一个请求的资源）因为某些原因卡住了，后面所有申请（比如后续的请求）即使已经准备好，也得被堵着，直到第一个搞定。这就是HTTP/1.1的队头阻塞。

🚄 HTTP/2：宽敞大通道，但怕“交通事故”

HTTP/2引入了“多路复用”，从根本上解决了HTTP/1.1的队头阻塞。它不再需要多个“单行道”，而是在一个TCP连接里划分出多个独立的“虚拟通道”，每个请求和响应可以在自己的通道里并行传输。

• 阻塞场景：这好比一条宽敞的大道，被划分出很多车道，不同车辆（不同请求的数据）可以在各自车道上自由并排行驶，互不影响。但问题来了，这条大道仍然是建立在TCP这个单一协议之上的。TCP协议为了保证数据顺序，如果任何一个数据包（比如某辆车）在路上丢失了，它会把整条大道上后续到达的所有车辆（数据包）都拦住，直到丢失的那辆车被重新送过来。 这就是TCP层的队头阻塞，虽然应用层的队头阻塞解决了，但底层的风险依然存在。

✈️ HTTP/3：多条独立航线，互不干扰

HTTP/3引入了基于UDP的QUIC协议，从根本上彻底解决了队头阻塞。

• 解决方案：QUIC协议内部支持多个独立的“流（Stream）”，每个流负责传输一个请求或响应的数据，并且这些流在传输层是彼此隔离的。

• 阻塞场景：这就像建立了多条独立的航线，每架飞机（代表一个请求）都飞在自己的航线上。如果某架飞机（某个数据包）因为天气等原因晚点了（丢失），它只会影响自己这条航线上的货物（该请求），其他航线上的飞机（其他请求）完全可以正常飞行、按时到达，完全不受牵连。
  

8.了解ECDHE吗讲解下 他对比RSA有什么更好之处吗
 

1. 公共参数：首先，通信双方会事先约定好使用哪条椭圆曲线（比如著名的x25519）和一个曲线上的公共基点G。

2. 生成密钥对：通信双方各自生成一个临时的随机数，作为自己的“私钥”（比如 a 和 b）。然后，通过椭圆曲线上的乘法运算，计算出各自的“公钥”：A = a * G 和 B = b * G。这个运算过程很简单，但从公钥 A 反推出私钥 a 在数学上几乎是不可能的，这就是“离散对数难题”的威力所在。

3. 交换公钥：双方在网络中交换自己的“公钥”（A 和 B）。即使黑客截获了公钥和曲线参数，也无法推算出私钥。

4. 计算共享秘密：这是最关键的一步。客户端收到服务器的公钥B后，用自己的私钥a进行计算：S = a * B。服务器收到客户端的公钥A后，用自己的私钥b进行计算：S = b * A。

根据椭圆曲线的数学性质，a * B = a * (b * G) = (a * b) * G = b * (a * G) = b * A。这就意味着，双方计算出的 S 是完全相同的值！这个 S 就是它们共同协商出的“共享秘密”，也就是我们在TLS 1.3中提到的那个“新的预主密钥”。
 

• RSA：客户端生成“预主密钥”，然后用服务器的公钥（长期不变的）加密后发送给服务器。如果未来服务器私钥泄露，所有过去的通信记录都可以被解密。没有前向保密性。

• ECDHE：双方通过计算协商出“预主密钥”，密钥从未在网络上传输。即使未来服务器私钥泄露，也无法解密过去的通信。具备前向保密性。
   

9.RPC讲解一下：
答：RPC（Remote Procedure Call，远程过程调用） 是一个非常经典且重要的概念。你可以把它通俗地理解为：像调用本地函数一样，去调用一台远程服务器上的函数或方法。

一次典型的RPC调用，其内部流程大致如下：

1. 客户端调用：客户端代码调用一个本地“存根”（Stub，可以理解为一个代理对象）。

2. 序列化（编组）：客户端存根将你要调用的函数名和参数，打包成一种可以在网络上传输的格式（即序列化，也称为编组），例如JSON、XML或更高效的Protobuf。

3. 网络传输：客户端存根通过网络（通常是TCP或HTTP）将这个数据包发送到远程服务器。

4. 服务器接收与解包：服务器端也有一个对应的“存根”（或称骨架，Skeleton）。它收到数据包后，进行反序列化，解析出函数名和参数。

5. 执行调用：服务器端骨架根据函数名，调用对应的本地方法，并传入解析出的参数。

6. 返回结果：方法执行完毕后，将结果返回给服务器端骨架。

7. 结果序列化与回传：服务器端骨架将结果同样进行序列化，再通过网络返回给客户端。

8. 客户端接收与解包：客户端存根收到结果，进行反序列化，最终将结果返回给调用方。
    

10.http短连接和长连接的区别
答：

1. 连接建立的“握手成本”
   每次TCP连接建立都需要一次“三次握手”，这至少需要一个网络往返时间（1-RTT）。如果使用短链接，每次请求都要多花这个时间，在高延迟网络下影响尤其明显。

2. 端口资源的“耗尽风险”
   这是短链接最常被提及的问题。一个TCP连接由“源IP、源端口、目标IP、目标端口”四元组唯一标识，而客户端可用的源端口数量有限（约6.5万个）。如果短链接关闭后，端口进入TIME_WAIT状态，会在一段时间内被占用，无法立即复用。高并发场景下可能耗尽端口，导致无法建立新连接。

   而长链接复用同一个连接，就不存在这个问题。

3. 服务器端的“连接管理”
   长链接虽然节省了握手开销，但需要服务器维持大量“睡”着的连接，这会消耗内存和文件描述符等资源。因此，服务端通常会设置Keep-Alive超时时间（如Nginx默认的75秒）和最大请求数，防止空闲连接无限消耗资源。

11.你了解DNS劫持吗
答：

1. 本地劫持：通过病毒、恶意软件或修改用户电脑的hosts文件，直接改变本地的DNS解析结果。

2. 路由器劫持：入侵你的家庭或公司路由器，修改其DNS设置。这样，同一网络下的所有设备都可能被劫持。

3. 中间人攻击：在用户的DNS查询请求到达正规DNS服务器之前，截获并伪造一个假的响应。

4. DNS服务器投毒：攻击正规的DNS服务器，在其缓存中加入错误的记录，影响查询该服务器的所有用户。