🔹 基础题
- TCP 三次握手为什么需要三次？如果只有两次会有什么问题？
- TCP 和 UDP 的区别？请分别举一个应用场景。
- OSI 七层模型和 TCP/IP 四层模型之间的对应关系。
- ARP 协议的作用是什么？工作原理是怎样的？
- IP 地址分类（A/B/C 类）和子网掩码的关系是什么？
🔹 进阶题
- 当你在浏览器输入
http://example.com回车后，网络层面发生了什么？ - 如果一个 TCP 连接一方突然宕机，另一方会怎么知道？
- DNS 查询有哪几种方式？迭代查询和递归查询有什么区别？
- TCP 粘包/拆包问题是怎么产生的？常见的解决办法有哪些？
- NAT（网络地址转换）是怎么工作的？有什么优缺点？
🔹 场景题
- 一台服务器可以 ping 通，但 telnet 某个端口却失败，可能有哪些原因？
- 用户说网页加载很慢，你作为网络工程师会怎么排查？
- 如果公司内部用户都能访问内网，但访问外网很慢，可能是哪些环节的问题？
- 如果 TCP 出现大量重传，你会怀疑哪些原因？
答案
-
TCP 三次握手为什么需要三次？如果只有两次会有什么问题？
答： TCP 是一个面向连接的、可靠的传输协议。在正式传输数据前，需要通过三次握手来确保通信双方的发送与接收能力都正常，并且建立初始的序列号，用来保证数据的有序性和可靠性。
-
为什么不是一次？
如果只有一次握手（客户端发 SYN，服务端直接建立连接），那么客户端可能根本收不到服务端的确认，无法确认自己和对方之间的通道是否真正可用。 -
为什么不是两次？
两次握手存在“旧连接请求导致的错误建立”问题：
例如，客户端曾经发送过一个 SYN 包，但因为网络延迟，这个旧包晚很久才到达服务端。如果采用两次握手，服务端收到 SYN 就直接建立连接并分配资源，但此时客户端并没有继续发起通信（因为它已经放弃了这个旧请求）。这样服务端就会白白浪费资源，甚至造成错误的会话。 -
三次握手的好处：
- 客户端确认服务端的 接收和发送能力。
- 服务端确认客户端的 接收和发送能力。
- 双方都确认了初始序列号（ISN），保证数据传输的顺序性和可靠性。
通过第三次确认，可以避免旧的、无效的连接请求导致错误连接，同时触发超时重传机制，确保连接建立可靠。
-
-
TCP 和 UDP 的区别？请分别举一个应用场景。
答：TCP 适合对可靠性要求高的场景，UDP 适合对实时性要求高、能容忍一定丢包的场景。
-
TCP 的特点：
- 面向连接，需要三次握手建立连接、四次挥手断开连接。
- 可靠传输：有确认机制、超时重传、流量控制、拥塞控制。
- 面向字节流，保证数据有序、不丢失、不重复。
- 开销相对较大，效率比 UDP 低。
-
UDP 的特点：
- 无连接，不需要建立连接即可传输数据。
- 不保证可靠性：可能丢包、乱序、重复。
- 面向报文：应用层交给 UDP 的数据会作为一个完整报文发送。
- 开销小、速度快，适合实时性要求高的场景。
-
应用场景：
- TCP 常见场景：网页浏览（HTTP/HTTPS）、文件传输（FTP）、邮件（SMTP/IMAP/POP3）、远程登录（SSH）。
- UDP 常见场景：流媒体（视频直播、语音通话）、在线游戏、DNS 查询、DHCP。
-
-
OSI 七层模型和 TCP/IP 四层模型之间的对应关系。
答：
-
应用层+表示层+会话层 → TCP/IP 应用层
-
传输层 → TCP/IP 传输层
-
网络层 → TCP/IP 网际层
-
数据链路层+物理层 → TCP/IP 网络接口层
-
-
ARP 协议的作用是什么？工作原理是怎样的？
答：
ARP 作用：
ARP（Address Resolution Protocol，地址解析协议）用于在局域网内，根据 IP 地址 获取对应的 MAC 地址。这样才能把数据从网络层交给数据链路层进行正确转发。-
工作原理：
- 查询：当主机 A 要向主机 B 发送数据时，A 知道 B 的 IP 地址，但不知道它的 MAC 地址。
- 广播请求：A 在局域网内广播一个 ARP 请求，内容是“谁是这个 IP？请告诉我你的 MAC 地址”。
- 响应：拥有该 IP 地址的主机 B 收到请求后，发送一个 ARP 响应，告诉 A 它的 MAC 地址。
- 缓存：A 收到响应后，将 IP-MAC 的对应关系缓存到本地主机的 ARP 缓存表，下次通信可以直接使用，避免再次广播。
-
-
IP 地址分类（A/B/C 类）和子网掩码的关系是什么？
答：
IPv4 地址共 32 位，分为 网络号 + 主机号。 A/B/C 类决定了 IP 地址默认的网络号和主机号划分，而子网掩码就是用来实现这种划分的工具。
类别 网络号位数 主机号位数 默认子网掩码 地址范围 A 类 8 位 24 位 255.0.0.0 (/8) 1.0.0.0 – 126.0.0.0 B 类 16 位 16 位 255.255.0.0 (/16) 128.0.0.0 – 191.255.0.0 C 类 24 位 8 位 255.255.255.0 (/24) 192.0.0.0 – 223.255.255.0 示例： 1️⃣ 默认情况：C 类 /24
-
例子 IP：
172.18.10.0/24 -
默认子网掩码：
255.255.255.0 -
含义：前 24 位是网络号，后 8 位是主机号。
也就是说，这个网络有 2^8 = 256 个地址（从 172.18.10.0 到 172.18.10.255），其中：
172.18.10.0→ 网络地址172.18.10.255→ 广播地址- 剩下 254 个地址可以分配给主机（172.18.10.1~172.18.10.254）
所以 /24 是一个单独的子网。
2️⃣ 改成 /26
-
/26 的意思：子网掩码有 26 位是网络位
-
换算成十进制掩码：
11111111.11111111.11111111.11000000 → 255.255.255.192 -
主机位数：32 - 26 = 6 位
-
每个子网的主机数：2^6 = 64 个地址
- 减去网络地址和广播地址 → 62 个可用主机地址
3️⃣ 怎么划分子网
原来的 /24 有 256 个地址（172.18.10.0~172.18.10.255），现在每个 /26 子网有 64 个地址：
子网1：172.18.10.0 - 172.18.10.63 网络号：172.18.10.0 广播号：172.18.10.63 可用主机：172.18.10.1 - 172.18.10.62 子网2：172.18.10.64 - 172.18.10.127 网络号：172.18.10.64 广播号：172.18.10.127 可用主机：172.18.10.65 - 172.18.10.126 子网3：172.18.10.128 - 172.18.10.191 网络号：172.18.10.128 广播号：172.18.10.191 可用主机：172.18.10.129 - 172.18.10.190 子网4：172.18.10.192 - 172.18.10.255 网络号：172.18.10.192 广播号：172.18.10.255 可用主机：172.18.10.193 - 172.18.10.254✅ 所以 256 个原来的地址就被划分成了 4 个子网，每个子网最多 62 台主机。
-
-
当你在浏览器输入
http://example.com回车后，网络层面发生了什么？阶段 0️⃣ 本地准备
-
浏览器/操作系统缓存检查
- 浏览器 DNS 缓存
- 系统 HOSTS 文件
- 如果有缓存，就可以直接跳过 DNS 查询
阶段 1️⃣ DNS 解析 向DNS服务器发送请求
- 应用层：生成 DNS 查询报文
- 传输层：封装 UDP/TCP 数据段
- 网络层：查路由表 → 决定下一跳 IP
- 数据链路层：封装以太网帧 → ARP 查询 MAC
- 物理层：网卡发送
- DNS服务器响应 → 返回 IP
阶段 2️⃣ TCP 连接建立
-
应用层：浏览器准备 HTTP 请求
-
传输层：TCP 三次握手
-
网络层：封装 IP 包，查路由
-
数据链路层：封装以太网帧，ARP 查询 MAC
-
物理层：发送到网络
注意：TCP 三次握手是 HTTP 发送前的前置阶段
阶段 3️⃣ HTTP 请求/响应
- 应用层：发送 HTTP GET/POST 请求
- 传输层：TCP 封装
- 网络层：IP 封装 → 查路由
- 数据链路层：封装 MAC 地址
- 物理层：发送
- 服务器处理请求 → 返回 HTTP 响应
阶段 4️⃣ 浏览器渲染
- 应用层：接收 HTML/CSS/JS → 解析渲染
- 可能触发新请求：加载图片、脚本、CSS 等（重复 DNS 查询 + TCP + HTTP 流程）
-
-
如果一个 TCP 连接一方突然宕机，另一方会怎么知道？
情况 1：正在交互数据时
-
发送方发送了 TCP 数据段
-
对方宕机 → 数据无法被确认 → ACK 收不到
-
TCP 会 重传数据（按照 RTO 超时机制）
-
重传达到系统上限 → TCP 判定连接失败
-
应用层收到错误通知（如
connection reset或timeout）
也就是说，只有在发送数据时，TCP 才能发现对端宕机
情况 2：连接空闲（没有数据传输）
-
TCP 默认不主动检测空闲连接
-
对端宕机时，发送方可能 长时间感知不到
-
解决方法：
- 开启 TCP Keepalive
- 定期发送探测包，如果多次没有回应 → 判定连接失效
-
-
DNS 查询有哪几种方式？迭代查询和递归查询有什么区别？
递归查询（Recursive Query）
-
发起方：通常是客户端（比如浏览器或操作系统的 DNS 解析器）
-
特点：
- 客户端请求 DNS 服务器（通常是本地或 ISP 的递归 DNS 服务器）
- DNS 服务器必须返回最终结果（域名对应的 IP 地址），中间不会返回部分信息
- 如果本地 DNS 服务器不知道 → 它自己向上层 DNS 服务器查询（可以用迭代方式）
-
优点：客户端操作简单，只需一次请求
-
缺点：DNS 服务器负担大，需要自己去解析完整路径
举例：浏览器向 8.8.8.8 请求
example.com，8.8.8.8 最终返回 IP 地址迭代查询（Iterative Query）
-
发起方：通常是 DNS 服务器之间
-
特点：
- DNS 服务器如果不知道答案 → 不直接返回 IP，而是返回 一个参考（比如上级 DNS 或权威 DNS）
- 请求方根据返回的参考继续查询下一跳
- 每次查询只得到下一步的线索，最终自己找到目标 IP
-
优点：每个 DNS 服务器压力小
-
缺点：查询方（如递归 DNS 服务器）需要自己完成整个查询流程
举例：递归 DNS 服务器向根 DNS 查询
example.com→ 根 DNS 返回.com顶级域参考 → 递归 DNS 再向.comDNS 查询 → … → 最终得到example.com的 IP -
-
TCP 粘包/拆包问题是怎么产生的？常见的解决办法有哪些？
🔹 1. 粘包/拆包问题是怎么产生的？
原因本质：
TCP 是 面向字节流 的传输协议，它只保证字节流按顺序、可靠到达，不保证一次send就对应一次recv。所以：
-
粘包
- 应用层连续发送了两条小消息，TCP 为了提高效率，可能把它们合并在一个报文里发送。
- 接收方一次
recv就收到了两条消息连在一起。
-
拆包
- 应用层发送了一条大消息，大于 TCP 的 MSS（最大报文段长度）或者大于发送缓冲区容量。
- TCP 会把它拆成多个报文发送，接收方可能一次
recv只能收到其中一部分。
📌 根本原因：TCP 是“无消息边界”的流式传输，接收端无法天然分辨消息的起止位置。
🔹 2. 常见解决办法
应用层必须自己定义消息边界，常见几种方案：
-
固定长度协议
- 规定每条消息长度固定，比如每次 100 字节。
- 接收方每次读 100 字节即可。
- 缺点：不灵活，可能浪费空间。
-
特殊分隔符
- 在每条消息结尾加一个分隔符，例如
\n或者\r\n。 - 接收方根据分隔符来切分消息。
- 例如：HTTP 请求头就是用
\r\n分隔的。 - 缺点：需要转义处理，避免分隔符出现在正文中。
- 在每条消息结尾加一个分隔符，例如
-
消息头 + 消息体（长度标识） ✅（最常用）
- 每条消息由 头部 和 数据体 组成。
- 头部包含消息体的长度字段，接收方先解析头，再按长度读取完整消息。
- 几乎所有二进制协议（HTTP/2、Thrift、Protobuf、Netty 框架）都采用这种方式。
-
使用成熟框架/协议
- 例如 gRPC、WebSocket、Netty 提供的解码器，内部已经处理了粘包/拆包。
- 开发者无需重复造轮子。
-
-
NAT（网络地址转换）是怎么工作的？有什么优缺点？
NAT 是一种把 私有 IP 地址 ↔ 公有 IP 地址 互相转换的技术。
NAT 的分类
-
静态 NAT
- 一对一映射：一个内网 IP ↔ 一个公网 IP。
- 适合对外需要固定地址的服务器。
-
动态 NAT
- 多对多映射：内网地址池 ↔ 公网地址池，自动分配。
- 公网 IP 资源仍然有限。
-
NAPT（端口地址转换，最常用）
- 又叫 PAT 或 端口复用。
- 多个内网 IP 共享同一个公网 IP，通过 端口号区分不同连接。
NAT 的优点
✅ 节省公网 IP（主要原因）
✅ 隐藏内网结构，提高安全性（外部无法直接访问内网主机）
✅ 管理方便，私网 IP 可以自由规划🔹 4. NAT 的缺点
❌ 打破端到端通信原则（P2P、VoIP、视频会议需要 NAT 穿透）
❌ 性能开销（路由器需要维护转换表，修改报文头部，消耗 CPU/内存）
❌ 某些协议不兼容（例如 FTP、SIP 这类在应用层携带 IP 地址的协议，需要 ALG 或额外处理）
❌ 端口资源有限（NAPT 依赖端口号区分，最多 65535 个并发连接/公网 IP） -
-
一台服务器可以 ping 通，但 telnet 某个端口却失败，可能有哪些原因？
telnet依赖三要素：-
服务进程存在（应用层）。
-
监听在正确的地址和端口（传输层+网络层绑定关系）。
-
防火墙/安全组允许访问（网络访问控制）。
根据这个分析可能的原因：
-
服务未启动或崩溃。
-
服务只绑定到回环地址（
127.0.0.1）或仅绑定 IPv6，而不是绑定到外网接口（0.0.0.0）。 -
本机防火墙（iptables/nftables/ufw/firewalld）阻止了该端口。
-
云平台安全组或边界防火墙拦截端口（外网可达但端口被丢弃）。
-
NAT/端口转发未配置或映射错误（内部能用但外部不可达）。
-
中间网络设备（企业防火墙/ISP）对该端口做了过滤。
-
-
用户说网页加载很慢，你作为网络工程师会怎么排查？
1. 客户端侧排查
-
打开浏览器开发者工具 (F12 → Network/Performance)：
- 判断是否是 渲染慢（前端性能瓶颈），例如 JS 执行时间过长、DOM 节点过多、图片/视频过大。
- 分析资源加载情况，是否存在过多请求、阻塞请求。
2. 网络侧排查
ping：测试延迟与丢包。traceroute：排查路径上是否存在异常节点。iperf3：测试链路可用带宽。iPerf3是用于主动测试IP网络上最大可用带宽的工具- 检查防火墙/ACL/QoS 策略是否影响流量。
- DNS 解析是否正确，是否解析到最近的节点。
- 静态资源是否走 CDN，缓存和加速是否生效。
3. 服务端侧排查
-
查看服务端日志，是否有慢查询、代码逻辑阻塞。
-
检查并发连接数，是否超出服务器或 Web 服务配置限制。
-
系统资源监控：
top/htop：CPU、内存使用情况free：内存瓶颈df -h：磁盘空间iostat/vmstat：IO 性能
-
检查负载均衡策略是否合理，后端节点是否有单点性能瓶颈。
-
-
如果公司内部用户都能访问内网，但访问外网很慢，可能是哪些环节的问题？
- 出口带宽问题
- 公司出口带宽本身不足，或者用户数多时被占满（例如大流量下载/视频/更新占用）。
- 没有 QoS 策略，关键业务和非关键业务争抢带宽。
- 出口设备性能问题
- 出口路由器 / 防火墙 / NAT 网关性能不足，转发延迟高。
- 并发连接数过多，设备 CPU/内存吃紧，导致处理速度慢。
- NAT 表溢出，建立外网连接耗时增加。
- 运营商/链路问题
- 运营商对出口流量进行限速或 QoS。
- DNS 解析问题
- 内网 DNS 解析外网地址慢（递归查询、转发异常）。
- 安全策略/检测设备
- 出口防火墙、IDS/IPS、流量审计设备对外部访问做深度检测，性能不足导致瓶颈。
- 出口带宽问题
-
如果 TCP 出现大量重传，你会怀疑哪些原因？
-
网络层面问题（包丢失 / 抖动）
- 链路质量差 or 链路不稳定：无线网络、跨国链路、长距离传输，光纤损坏、丢包率高。
- 路由/交换设备缓存溢出：在高并发场景下，队列满导致丢包。
- 网络拥塞：TCP 拥塞控制会感知到丢包并触发重传。
-
服务器端问题（接收方）
- 接收端性能不足：CPU 过载、内存不足，内核来不及处理 TCP 包，导致 ACK 延迟甚至丢失。
- 应用层阻塞：应用程序处理不过来，socket 缓冲区满，导致内核丢包。
- 接收端宕机 / 进程挂掉：完全收不到 ACK，发送端只能重传。
-
发送端问题
- 发送端网络接口异常：驱动/网卡缓存问题，导致丢包。
- 发送端 CPU 忙 / 协议栈 bug：不能及时处理 ACK，误判丢包，触发重传。
- 流量突发过大：超出本地网卡或系统处理能力，直接在发送端丢包。
-
网络安全设备
-
防火墙 / IDS / IPS 丢包：安全设备可能丢弃大流量或特定特征的包。
-
负载均衡器问题：转发不稳定，包丢失或乱序，触发重传。
-
-
