4. 技术面试——Linux与网络基础：Linux命令、网络协议、故障排查、高频问题
本章聚焦面试中最高频的 Linux 操作与网络协议考察。面试官不仅想确认你是否会用 top、tcpdump，更想验证你在故障场景下的排查思维链。结构化回答框架能帮你快速组织逻辑，避开“只背命令”的陷阱。
3 个面试问答卡片
Q1：如何排查服务器 CPU 负载过高？
考察点：是否掌握系统性能分析工具链；能否区分 CPU 密集型、IO 等待、锁竞争等不同原因。
回答框架：
① top / htop 查看整体负载和每个 CPU 使用率；
② ps aux --sort=-%cpu 找出消耗最高的进程；
③ strace -p PID 跟踪系统调用，判断是否是用户态忙等或内核态阻塞；
④ 结合 vmstat 1 观察上下文切换和 mpstat -P ALL 确认各核情况。
简短示例回答：
先 top 发现 us 占 90% 以上，找到 PID 后 ps -p PID -L 看线程。使用 perf top 定位到热点函数是正则解析，确认是新版本日志聚合模块 bug，回滚后恢复正常。可能追问：如果 load average 很高但 CPU 使用率很低，可能是什么原因？如何用 iostat 进一步定位？
Q2：解释 TCP 三次握手和四次挥手，并在 Linux 上用命令观察。
考察点：对 TCP 状态机理解是否扎实；能否活用在排障中（如 TIME_WAIT 过多）。
回答框架：
① 二次握手：SYN → SYN+ACK → ACK，核心是序列号同步和资源预分配；
② 四次挥手：FIN → ACK → FIN → ACK，区别半关闭和全关闭；
③ 用 tcpdump -i eth0 'tcp[tcpflags] & (tcp-syn|tcp-fin) != 0' 抓包观察。
简短示例回答：
TIME_WAIT 2MSL 期间端口被占用。我在 nginx 反向代理高并发场景下，通过调整 net.ipv4.tcp_tw_reuse 和 tcp_tw_recycle（注意 NAT 环境）减少连接释放延迟。可能追问：如果服务端不发送 FIN 怎么办？介绍下 TCP 快速打开（TFO）？
Q3：如何排查网络丢包问题？
考察点：网络协议栈排查路径（物理层→链路层→IP→传输层→应用层）。
回答框架：
① ip -s link 看网卡错误 / 丢包统计（RX-errors / TX-errors）；
② netstat -s 或 nstat 查看 TCP 重传和乱序；
③ ping -f 检测路径延迟和丢包；
④ tcpdump + wireshark 抓包分析重传模式。
简短示例回答：
业务反馈间歇性超时。ip -s link 看到 eth0 RX 丢包率 0.1%，ethtool -S eth0 发现 ring buffer 溢出。增大 rx ring size 并调整中断合并后问题解决。可能追问：如何区分中间路由器丢包还是接收端丢包？traceroute 的局限性？
项目案例模版：高并发微服务网关网络优化
| 维度 | 内容 |
|---|---|
| 项目名称 | 金融核心交易网关的网络延迟优化 |
| 业务背景 | 交易网关承接每日 5000 万笔订单，偶发 200ms 以上的 P99 响应抖动，导致下游超时重试。 |
| 规模指标 | 网关集群 20 台 8C16G 机器；连接数 10 万+；峰值 TPS 5 万；网络延迟基线 < 5ms。 |
| 技术栈 | Linux 5.10、nginx 1.21、epoll、tcpdump、perf、eBPF、Go 服务 |
| 核心难点 | ① 偶发抖动难以复现；② 应用层与内核层延迟交错；③ 优化影响老版本兼容性。 |
| 面试高频追问 | - 为什么用 eBPF 而不是传统 trace？ - 如何排除 GC 停顿干扰？ - 调整 tcp_rmem 前后如何验证？ |
| 可迁移回答话术 | “我使用 eBPF 的 kprobe 跟踪 tcp_v4_do_rcv 函数，发现 sk_rcvtimeo 在执行期间超时。配合 sysctl 调整 net.core.rmem_default 从 212992 到 524288，并启用 tcp_autocorking，最终消除了抖动。” |