企业官网建设流程全解析

1. 面试官问网络题，从来不是想听你背协议

网络运维面试题在圈子里的口碑很分裂：一面的人觉得这东西全是背诵，把三次握手、四次挥手、状态机图默写一遍就能过；另一面的人被追问两层就哑火，因为面试官随口一句“那你说说线上为什么会有几万个 TIME_WAIT”，准备好的答案立刻接不上。我带过几轮候选人，也被人面过不少回，最深的感受是：网络运维面试题的真正考点，不在于你记住多少个名词，而在于你能不能把一个抽象协议还原成一条真实的故障链路，然后说出你在哪一层、用什么证据、做了什么动作。

这篇东西是我自己整理的一份“网络篇（一）”复盘，面向三类人：准备跳槽、需要把八股文升级成可讲故事的初中级运维；日常被“网站慢”“连不上”“偶发 502”折磨、想建立排查框架的驻场或应用运维；以及刚转行、看得懂命令但不知道先敲哪个的新人。我会把每道经典题拆成三层——面试官想听什么、真实环境长什么样、你该怎么答才显得干过活。里面涉及的命令、参数、判断依据都可以直接搬到工作里用，包括那些文档里通常不写的坑。

需要先说明一点：下文所有场景都是我基于常见运维实践构造的典型模型，不指向任何具体单位或系统，参数取值以主流 Linux 发行版的默认行为为准，不同内核版本会略有差异，落地前建议先在自己的测试环境验证一遍。

2. 分层模型这道“送分题”，八成人答得没有骨头

2.1 OSI 七层与 TCP/IP 四层，别只报菜名

几乎每场网络运维面试题都会从分层开始，因为这是最好用的探针：让你背七层，谁都能背；让你说“一次网页打不开，你怎么用分层模型缩小范围”，立刻能分出谁真正排过障。

我的答法是这样的：先给对应关系，再给“每层坏了会表现成什么样”。OSI 七层是教学模型，实际工程里用的是 TCP/IP 四层——网络接口层、网络层、传输层、应用层。面试时不要机械地念“物理层、数据链路层……”，而要补一句：分层的价值是故障隔离，每一层只对上一层负责，所以排查时必须自下而上验证连通性，或者自上而下用应用日志反推，不能跳层猜。

这张表是我面试时手边常备的“答题骨架”。它有一个好处：任何题目都能挂上来。比如面试官问“用户说打不开网站”，你可以顺着表从上往下走一遍——DNS 解析出来了吗（应用层）、TCP 端口通吗（传输层）、ICMP 能通吗（网络层）、ARP 有没有（链路层）。这么答，面试官会认为你有方法论，而不是在碰运气。

2.2 一个 HTTP 请求的完整旅程，是最好用的叙事模板

我在面试里最喜欢让候选人讲“从浏览器输入地址到页面出来，中间发生了什么”。这道题信息密度极高，能同时考 DNS、ARP、TCP、HTTP、TLS、负载均衡、缓存。很多人一上来就讲三次握手，把前面 DNS 和 ARP 直接跳过，这就丢了分。

完整的链路我一般这么讲，按顺序不落项：

1. 浏览器查本地缓存、系统 hosts 文件，命中就直接用，没命中才发起 DNS 查询；
2. DNS 递归解析，先问本地 DNS 服务器，逐级向上找到权威服务器，拿到 A 或 AAAA 记录，同时受 TTL 控制缓存时长；
3. 拿到目标 IP 后，判断是否同网段。不同网段就把包交给网关，同网段则先查 ARP 表拿 MAC，没有就发 ARP 广播；
4. 建立 TCP 连接，三次握手，协商 MSS、窗口缩放、SACK 等选项；
5. 如果是 HTTPS，还要做 TLS 握手，校验证书链、协商密钥；
6. 发 HTTP 请求，中间可能经过四层或七层负载均衡，被转发到某一台后端；
7. 后端处理，可能查缓存、查数据库，返回响应；
8. 浏览器解析渲染，再发起对静态资源的并发请求，受同域并发数限制；
9. 连接按 keep-alive 策略复用或关闭，进入四次挥手或 TIME_WAIT。

讲这一段的时候，我建议主动加一句“每一跳都是一个独立的故障点”。这是加分项，因为它把知识变成了排障意识。面试官接下来往往会顺着问“那如果 DNS 慢会怎样”，你已经铺好路了。

提示：讲链路题时不要追求背得全，宁可挑三个环节讲透。比如把 DNS 的 TTL 与递归、TCP 握手选项协商、负载均衡转发模式各讲两句，比流水账更能体现深度。

2.3 分层模型在真实排障中怎么“用起来”

分层不是拿来答题的，是拿来省时间的。我讲一个自己反复用过的套路：接到“某服务访问异常”的报障，先问三个问题——影响范围是单机还是全站、是全新失败还是偶发超时、最近有没有变更。这三个问题直接决定你从哪一层切入。

影响单机，优先看本机网络栈：网卡状态、路由表、防火墙规则、连接数。影响全站，优先看入口：DNS、负载均衡、证书、上游依赖。全新失败通常是配置或链路问题，偶发超时通常是容量、丢包或下游抖动。这套判断不需要任何工具，三十秒就能把范围砍掉一半，比上来就ping高效得多。

我见过不少新人排障时习惯性地从ping开始，ping 通了就不知道下一步。问题在于ping走的是 ICMP，很多环境对 ICMP 有限速甚至直接丢弃，ping 不通不代表业务不通，ping 通也不代表端口可用。真正该先做的是用curl -v或telnet验证应用端口，用ss看本地监听，用tcpdump看包到底有没有出去、有没有回来。分层模型的意义就是把“猜”变成“按层验证”。

3. TCP 连接管理：状态机背后全是线上事故

3.1 为什么是三次握手，而不是两次

这题的标准答案谁都会背：确认双方收发能力、同步初始序列号。但面试官往往接着问“两次为什么不行”，这时候很多人就卡住了。

我的解释方式是构造一个场景：客户端发了一个 SYN，因为网络拥塞在某个节点滞留了很久，客户端超时重发，第二次握手成功、通信结束、连接关闭。接着那个迟到的旧 SYN 终于到达服务端，服务端如果只靠两次握手就认为连接建立，会直接分配资源等待数据，而客户端根本不认这个连接，资源就白占了。这就是历史重复连接的问题。三次握手的第三次 ACK 本质上是让服务端确认“客户端确实收到了我的 SYN+ACK，且此刻还愿意建连”，把过期请求挡在门外。

另一个角度是序列号。TCP 靠序列号保证有序和可靠，双方都必须知道对方的初始序列号（ISN），而这个值不是从 0 开始，是随时间变化的。两次握手只能让客户端知道服务端的 ISN，服务端无法确认客户端是否收到了自己的 ISN，后续数据的确认机制就无从谈起。

面试时我还会补一句 ISN 的生成方式：现代内核用基于时钟的算法，加上每连接的四元组哈希，防止被轻易预测。这属于加分细节，说明你了解的不只是教科书。

3.2 四次挥手与 TIME_WAIT，到底在保护什么

四次挥手之所以是四次，是因为 TCP 是全双工，两个方向要各自关闭。主动关闭方发 FIN，表示“我没数据要发了”；被动方回 ACK，但可能还有数据要发，所以 FIN 和 ACK 不能合并；等被动方数据发完，再发自己的 FIN；主动方回最后一个 ACK，连接才算关完。

关键在最后一步：主动关闭方进入 TIME_WAIT，等待 2MSL 才真正释放。这个等待有两个作用，面试必答：

• 保证最后一个 ACK 能到达对端。如果这个 ACK 丢了，对端会重发 FIN，此时主动方还在 TIME_WAIT，可以重发 ACK；如果直接关了，对端收到的是 RST，属于异常终止。
• 让本次连接产生的滞留报文在网络中消散，避免它们被后续复用相同四元组的新连接误收。

Linux 上 MSL 固定为 30 秒，所以 2MSL 就是 60 秒，这个值不可调，可调的只有是否复用。面试官如果问“TIME_WAIT 能不能消掉”，正确的态度是：不能也不该消掉，只能控制规模和影响。

规模怎么估？一个常被问到的计算题：本机可用临时端口范围默认是net.ipv4.ip_local_port_range = 32768 60999，大约 28232 个端口。作为客户端主动连同一个目标 IP 和端口时，四元组里只有源端口可变，所以理论上 60 秒内最多约 2.8 万个连接会处于 TIME_WAIT。如果你的服务是短连接、QPS 又高，比如每秒 1000 次请求打同一个上游，60 秒就是 6 万个连接，端口直接耗尽，报错是Cannot assign requested address。这个计算过程比背结论有用得多，面试时说出来，对方基本就认可你懂原理。

对应的处置手段我通常按优先级讲：

注意：老资料里常见的net.ipv4.tcp_tw_recycle不要开。它在 NAT 环境下会导致连接失败，新内核已经移除该参数。面试时如果你主动提这一句，是明显的经验信号。

3.3 CLOSE_WAIT 堆积，锅基本不在网络

TIME_WAIT 是“正常但量大”，CLOSE_WAIT 是“不正常，必须查应用”。这两者的区别是网络运维面试题里区分度最高的一问。

CLOSE_WAIT 的含义是：本端收到了对端的 FIN，内核回了 ACK，但本端应用迟迟没有调用close()，所以连接卡在这个状态。也就是说，被动关闭方的应用层没把连接释放掉。堆积几千上万个 CLOSE_WAIT，基本可以判定为连接泄漏——可能是线程池打满、可能是业务代码在异常分支里漏了关闭、可能是下游响应慢导致处理线程长时间阻塞，也可能是连接池借出后没归还。

排查路径我一般这么走：

1. ss -tan state close-wait | wc -l看数量，确认不是瞬时波动；
2. ss -tanp state close-wait看是哪个进程、哪个本地端口、连的哪个对端；
3. 抽样看对端集中度，如果全指向同一个下游地址，问题在下游或调用方式；如果分散，问题在本端资源；
4. 打线程栈，看卡在哪个方法上，是不是在等锁、等 IO；
5. 结合应用日志看有没有异常分支没走到 finally 里的关闭逻辑。

这套流程下来，通常能定位到具体代码路径。面试时把“CLOSE_WAIT 是应用问题，TIME_WAIT 是协议正常行为”这句话说清楚，再补一句“我不会去调内核参数解决 CLOSE_WAIT”，就足够专业了。

3.4 全连接队列与半连接队列，一个容易答错的细节

这题属于进阶，但近几年问得越来越频繁，因为它直接关联“服务看起来活着但请求进不来”的典型故障。

TCP 建连过程中有两个队列。半连接队列（SYN 队列）放的是收到 SYN、回了 SYN+ACK、还没收到最后 ACK 的连接；全连接队列（accept 队列）放的是三次握手完成、等待应用调用accept()取走的连接。

关键点在于全连接队列的长度取min(backlog, net.core.somaxconn)，其中 backlog 是应用调用listen()时传的值。应用如果 accept 得慢，队列满了之后，新完成握手的连接会被丢弃（默认行为），客户端表现为连上了但请求超时，或者直接收到 RST。半连接队列满了则丢弃新 SYN，客户端表现为连接超时并重试。

验证手段很直接：

# 查看监听队列，Send-Q 是队列上限，Recv-Q 是当前排队数 ss -lnt # 看是否有溢出计数 netstat -s | grep -i -E "overflow|SYNs to LISTEN" nstat -az | grep -i -E "ListenOverflows|ListenDrops"

Recv-Q接近Send-Q就是明确的告警信号。处置上，短期调大somaxconn和应用 backlog，长期要查应用为什么 accept 慢——常见原因是业务逻辑在 accept 之后同步处理，或者用了单线程 accept 模型。

4. 排障命令与抓包：让答案落在证据上

4.1 ping、traceroute、mtr，用错场景等于白干

面试官问“网络不通你怎么查”，十个人里九个答 ping。ping 确实该用，但要知道它的边界。

ping验证的是 ICMP 回显，能证明三层可达和大致时延。它的坑有三个：一是很多环境限制 ICMP，通与不通都说明不了业务；二是 ping 通不代表端口开放，防火墙完全可能只放行 ICMP；三是 ping 的 RTT 只是抽样，不能代表持续质量。

traceroute用来看路径，默认走 UDP 高端口，很多防火墙会拦，导致中间显示星号。所以实用技巧是按需换协议：

traceroute -I 目标地址 # 用 ICMP traceroute -T -p 443 目标地址 # 用 TCP，最容易穿过防火墙

mtr是我最推荐的，它把 ping 和 traceroute 合起来做持续探测，能看出是某一跳持续丢包，还是末端才丢。判断技巧：如果某一跳丢包但后面几跳都正常，通常只是那台设备对 ICMP 限速，不是真故障；如果从某一跳开始后面全丢，那一跳之后才是问题区。

4.2 ss 与 netstat，看连接状态该看什么

netstat已经逐步被ss取代，原因是ss直接读内核，连接数上万时不会像netstat那样卡住几十秒。面试时能说清这个差异，说明你真在生产环境用过。

我常用的几个组合：

# 按状态统计连接数，快速看有没有异常堆积 ss -tan | awk 'NR>1{print $1}' | sort | uniq -c | sort -rn # 看某端口是谁在监听、队列情况 ss -lntp 'sport = :8080' # 看某进程的所有连接 ss -tanp | grep 进程名 # 看 socket 内存占用，判断是否缓冲区打满 ss -m

netstat -s则是统计视角的宝库，重传、乱序、丢包、超时都能看到。我排“偶发慢”的时候，第一步往往不是抓包，而是看这几个计数有没有异常增长：

netstat -s | grep -i -E "retrans|timeout|reset|overflow"

重传率高通常意味着链路丢包或对端处理慢；大量 reset 意味着连接被中间设备或对端主动打断；队列溢出则回到上一节的问题。

4.3 tcpdump 抓包，三步走不要乱

抓包是最容易炫技也最容易翻车的环节。我见过候选人上来就tcpdump -i any，然后被问“你这抓出来的包怎么分析”就答不上来。我的固定套路是三步：先定过滤条件，再定抓取范围，最后定分析视角。

第一步，过滤条件要尽可能窄。抓全量包在流量大的机器上会直接把磁盘写满，也会拖慢自身。

# 只抓指定主机和端口的包，不做名称解析，抓完整包长 tcpdump -i eth0 -nn -s0 -w /tmp/conn.pcap 'host 10.0.0.10 and tcp port 8080' # 只看握手和挥手，快速判断连接是否建立成功 tcpdump -i eth0 -nn 'tcp[tcpflags] & (tcp-syn|tcp-fin|tcp-rst) != 0'

第二步，控制范围。加-c 1000限制包数，加-w落盘而不是终端打印，落盘文件用时间戳命名，方便和监控时间对齐。

第三步，分析视角要带着问题去。判断“连不上”看有没有 SYN 发出、有没有 SYN+ACK 回来、有没有 RST；判断“慢”看握手耗时、首包响应时间、重传次数；判断“断”看谁先发的 FIN 或 RST。

我用得最多的判定逻辑是：客户端发出 SYN 但没有收到 SYN+ACK，通常是对端没监听、防火墙拦了，或者路由不通；收到 RST 说明对端明确拒绝，多半是端口没开或队列溢出；SYN 和 SYN+ACK 都有但握手时间很长，说明链路质量差或有设备在做深度检测。这三句话在面试里说出来，比背十个参数管用。

4.4 MTU 与分片，一个高频的“隐形杀手”

这题经常以场景形式出现：小请求正常，大文件上传或者某些接口就卡住。答案往往指向 MTU。

标准以太网 MTU 是 1500，减去 IP 头 20 字节和 TCP 头 20 字节，MSS 是 1460。如果路径中某一段的 MTU 更小（比如隧道封装会额外占字节），而中间设备又把需要分片的包丢掉了（ICMP 被拦，PMTUD 失效），就会出现“小包通、大包不通”的诡异现象。

验证方式：

# 1472 + 8(ICMP头) + 20(IP头) = 1500 ping -M do -s 1472 目标地址 # 逐步减小，找到能通的最大值，反推路径 MTU ping -M do -s 1400 目标地址

-M do表示禁止分片，一旦超过路径 MTU 就会失败。这个操作很直接，面试时能说出“1472 这个数字怎么来的”，基本就过关了。

5. 延伸连环问：DNS、HTTP 与负载均衡

5.1 DNS 解析，慢和错是两种完全不同的故障

DNS 相关的面试题通常分两类：解析慢、解析错。这两者的排查路径完全不同。

解析慢，先看本地 DNS 服务器响应时间，用dig带上耗时：

dig @8.8.8.8 example.com +stats dig +trace example.com

+trace会从根开始逐级展示，能看出是哪一级慢或者超时。常见原因是本地 DNS 递归链路长、上游有丢包、或者被解析的域名权威服务器响应慢。另一个高频原因是resolv.conf里配了多个 nameserver，而 glibc 的默认超时是 5 秒、重试 2 次，第一个不通就要等十几秒才切第二个，业务上表现为“偶发首屏特别慢”。

解析错，通常是缓存、CNAME 链、或者本地 hosts 干扰。检查顺序是：/etc/nsswitch.conf里 hosts 的优先级、/etc/hosts有没有写死、/etc/resolv.conf指向对不对、TTL 是否导致旧记录未过期。多线路解析的场景下，还要确认权威服务器返回的是不是预期线路的地址。

面试时我一般会强调一个观点：DNS 是典型的“配置简单但影响巨大”的组件，改一条记录可能影响全站分钟级不可用，所以 TTL 要提前调低、变更要分批、回滚预案要准备好。

5.2 HTTP 状态码，502 和 504 到底差在哪

运维面试里问状态码，重点不在 200 和 404，而在 5xx 的区分，因为那直接决定你去找谁。

502 Bad Gateway 表示网关从上游收到了无效响应，或者根本连不上上游。常见原因：上游进程挂了、端口没监听、上游返回了不符合 HTTP 规范的内容、上游连接被重置。它强调的是“通信层面出了问题”。

504 Gateway Timeout 表示网关等上游响应超时。上游可能还活着，只是在规定时间内没返回。常见原因：上游处理慢、数据库慢查询、下游依赖阻塞、超时阈值设得太短。

这两个的处置方向完全不同：502 先查上游进程和端口，504 先查上游耗时和超时配置。我在面试里会补一句：如果 502 和 504 交替出现，往往意味着上游在崩溃和恢复之间反复，要优先看 OOM、连接池耗尽这类资源问题。

还有一个常被忽略的是 499，这是 Nginx 侧的“客户端主动断开”，通常说明用户等不及了，根因还是后端慢。看到 499 增多不要只查 Nginx，要往后端追。

5.3 四层与七层负载均衡，选型题怎么答才算懂

这题看起来是架构题，实际上考的是你对转发原理的理解。

四层负载均衡工作在传输层，只看 IP 和端口，把包转出去就完事。优点是性能高、对协议无感知、能承载任意 TCP/UDP 流量；缺点是无法做基于 URL、Header 的路由，也看不到应用层信息。常见实现有 LVS 的 DR、NAT、TUN 模式，以及各种基于 DPDK 的转发方案。

七层负载均衡工作在应用层，会终结连接、解析 HTTP，然后重新向后端发起请求。优点是能做路径路由、灰度、改写、限流、会话保持；缺点是开销大、要处理连接复用、对非 HTTP 协议支持有限。

选型上我的判断标准是：协议是否标准 HTTP、是否需要按内容路由、是否需要 TLS 卸载、性能压力有多大。如果只是四层转发，优先四层，少一层解析就少一堆问题。如果要做灰度发布、A/B 测试、基于 Header 的分流，那只能七层。

健康检查这块也值得说两句。四层健康检查通常只探测端口是否可连，七层可以探测具体路径和返回码。但要注意探测频率和后端承载能力，探测过于频繁本身就会造成压力；还要注意健康检查的判定阈值，连续失败几次才摘除、连续成功几次才恢复，这两个值直接决定故障时的流量切换速度。我见过阈值设得太敏感导致的流量震荡，也见过设得太迟钝导致请求持续打到故障节点。

6. 排查实录与避坑清单

6.1 一张速查表，覆盖八成常见现象

下面这张表是我自己排障时常用的对照表，现象、可能原因、验证手段、处置动作按顺序排好，面试被问到具体场景时可以直接照着讲。

表格只是索引，真正有价值的是判断顺序。我的习惯是：先看时间线对齐（监控、日志、变更记录三条线对一下），再看影响面（单机还是集群），最后才动手敲命令。顺序错了，命令敲得再多也是盲人摸象。

6.2 几个只有踩过才知道的坑

第一个坑：抓包抓到了，但时间对不上。生产环境的机器时间如果没同步，抓包时间和日志时间差几十秒，分析起来能把人逼疯。我的习惯是所有节点统一时间同步，抓包文件命名带时间戳，事后能快速定位。

第二个坑：只看服务端不看客户端。连接建立失败，很多人一头扎进服务端查，其实客户端可能压根没发包——本地路由不对、代理配置错、DNS 解析到错误地址。优先在客户端抓一次包，能省一半时间。

第三个坑：把监控的“平均耗时”当真相。平均值会把长尾掩盖掉，真正影响用户体验的是 P99 和 P999。我排性能问题一定先看分位值分布，如果 P50 正常而 P99 很高，问题往往在少数慢请求、连接池排队或者 GC 停顿上，跟带宽关系不大。

第四个坑：迷信参数调优。somaxconn调大了但应用 accept 慢，队列照样满；端口范围扩了但连接泄漏没修，迟早还是耗尽。参数是缓解，根因永远在应用逻辑或架构设计上。面试时如果你能主动说“这个参数只能缓解，根因要往应用层找”，是很强的加分项。

第五个坑：变更后没有回滚点。网络配置改动的影响面往往比想象中大，改一条路由、加一条防火墙规则，可能十分钟后才暴露问题。我的习惯是改动前记录当前配置、准备好回滚命令、改完立刻验证关键链路，不要等到用户报障。

6.3 面试表达上的几个实用技巧

技术答对只是一半，怎么讲同样重要。我的经验是先给结论再展开，面试官时间有限，你先说“这是 TIME_WAIT 堆积，属于正常现象但量太大会耗尽端口”，他立刻知道你在正确的方向上，后面的细节才有耐心听。

第二个技巧是用数字说话。不要说“可能会很多”，要说“默认端口范围约 2.8 万个，60 秒窗口内打满就会出现地址分配失败”。数字最能体现你真的算过。

第三个技巧是主动暴露边界。比如讲端口复用时补一句“它只对主动发起连接的一方生效，服务端被动连接用不上”。这种边界说明比堆砌优点更能让人信服。

第四个技巧是承认不确定。被问到没做过的场景，直接说“这块我在实际环境里没深入做过，我的理解是……，如果有偏差还请指正”。运维这行没人什么都做过，硬编反而扣分。

最后分享一个我自己的准备方法：把每道经典题都写成“一句话结论 + 三个支撑点 + 一个真实案例”的卡片，反复讲给自己听，讲到能在两分钟内讲完且不跑题为止。网络运维面试题翻来覆去就那些，但能不能讲出层次，取决于是不是真的把协议和现场对上了号。我自己是踩过几次“参数调了但问题复现”的坑之后，才慢慢把注意力从背答案转到看证据上的，这个过程没有捷径，多抓几次包、多对几次日志，感觉自然就有了。