企业官网建设流程全解析

面试网络岗这么多年，我发现一个很有意思的现象：大部分候选人对网络知识的掌握停留在“背诵八股文”的阶段。问你三次握手能背得滚瓜烂熟，但一追问“为什么不是两次”、“最后一次ACK丢了会怎样”，就开始含糊其辞。这其实暴露了一个核心问题——很多人没搞懂面试官问网络题到底在考察什么。

这篇文章不打算罗列一份所谓的“标准答案清单”，而是想从一个面试官同时也是从业者的角度，聊聊网络面试题背后真正值得深挖的东西。我会把高频考点拆开揉碎，讲清楚每个知识点背后的“为什么”，再穿插一些实际排查中才会遇到的坑。无论你是准备校招的应届生，还是想查漏补缺的职场老手，这篇内容应该都能帮你在下一次面试前把网络知识体系梳理得更扎实。

1. 网络面试题全景拆解：面试官到底在考察什么

1.1 从一道送命题看面试官的出题逻辑

先来看一道我在面试中几乎必问的题：“在浏览器输入一个网址，按回车后发生了什么”。很多候选人听到这题就开始默背OSI七层模型，从应用层一路背到物理层，背完就停下来等我反应。说实话，这种回答我只能给个及格分。

为什么？因为这道题的真正考点不是背诵，而是考察你能否把一个完整链路串起来，并且在每个环节说出可能出现的异常。比如DNS解析失败怎么办、TCP连接超时怎么判断、HTTPS握手证书校验失败会怎样、服务端返回5xx和4xx分别意味着什么。一个真正有排查经验的工程师，回答这个问题时会自然带出这些分支，因为他在实际工作中都遇到过。

面试官出网络题，核心是在考察三件事：基础理论的扎实程度、理论与实践的连接能力、以及遇到问题时的排查思路。纯粹的概念背诵只能证明你背过书，只有能把概念落地到真实场景里，才说明你真正理解了这个东西。

1.2 高频考点分布地图

我梳理了近几年面试中反复出现的网络考点，大致可以分成五个梯队：

第一梯队是TCP/UDP协议细节，包括三次握手、四次挥手、拥塞控制、流量控制这些，基本属于必考范围。第二梯队是HTTP/HTTPS协议体系，涵盖请求响应结构、状态码语义、缓存策略、HTTPS握手流程，这个板块现在越来越受重视。第三梯队是DNS解析过程和CDN加速原理，云原生时代这块出现频率明显上升。第四梯队是网络排查工具链，ping、traceroute、curl、dig、tcpdump这些工具的正确使用姿势。第五梯队是网络分层模型和基础概念，看起来简单，但很多人在深挖时会露馅。

从通过率来看，第一梯队和第二梯队是区分度最高的部分。能把TCP状态迁移说清楚、能把HTTPS握手每一步的密钥协商过程讲明白的候选人，通常整体网络基础都不会差。反之，如果在这两个板块含糊其辞，其他部分大概率也是靠短期突击背下来的。

2. TCP协议核心面试题精讲：那些容易被追问卡壳的细节

2.1 三次握手：为什么不是两次或四次

TCP三次握手的过程本身不难描述：客户端发送SYN，服务端回复SYN+ACK，客户端再回ACK，连接建立。但在面试实践中，追问环节才是真正的分水岭。

先看“为什么不能两次握手”。这个问题的标准回答是防止历史重复SYN报文建立无效连接。假设客户端发送的SYN报文因为网络拥堵被延迟，客户端超时后重发SYN并成功建立了连接、完成了数据传输、关闭了连接。此时之前那个延迟的旧SYN报文才到达服务端，如果采用两次握手，服务端就会直接建立一条新的连接，但此时客户端根本没有这个连接诉求，于是这条连接白白占用了服务端资源。有了第三次握手，服务端收到旧SYN后会回复SYN+ACK，客户端发现自己并没有发起新的连接请求，就会回复RST报文来终止这个无效连接。

这个解释本身没问题，但很多候选人答到这里就停了。如果再追问一句“三次握手有没有什么缺陷”，很多人就愣住了。实际上三次握手最典型的问题就是SYN Flood泛洪攻击——服务端收到SYN后需要分配传输控制块等资源，如果攻击者只发SYN不回ACK，服务端资源会被快速耗尽。所以现代操作系统都引入了SYN Cookie机制，不直接分配资源，而是通过编码计算生成一个Cookie放在SYN+ACK中回复，等客户端真正回ACK时才验证并分配资源。这个细节在面试中主动讲出来，会明显加分。

另外一个容易被忽略的点是握手报文里的序列号初始值问题。三次握手最重要的作用之一其实是同步双方的初始序列号，而初始序列号并非固定值，而是随时间动态生成的。TCP要求每个报文段都有序列号，目的是让接收方能够去重、排序并实现可靠传输。为什么初始序列号不能固定为0？因为如果每次都用固定值，旧连接残留的报文很可能被新连接当作有效数据接收，造成数据错乱。

2.2 四次挥手：TIME_WAIT为什么是2MSL

四次挥手的过程比握手更复杂，因为涉及半关闭状态。主动关闭方发送FIN，被动关闭方回ACK，此时被动关闭方还可以继续发送数据，直到它也要关闭时再发FIN，主动方回ACK，连接才真正关闭。

面试时最容易翻车的点是TIME_WAIT状态。主动关闭方在发送最后一个ACK后会进入TIME_WAIT，持续2MSL时间才能完全关闭。这里至少要讲清楚三层逻辑。

第一层，为什么要有TIME_WAIT。最后一个ACK可能丢失，如果直接关闭连接，被动方收不到ACK会重发FIN，此时主动方已经关闭就无法响应，被动方会一直停留在LAST_ACK状态并反复重传。保持TIME_WAIT可以让主动方有能力重发最后的ACK，确保对端正常关闭。

第二层，为什么是2MSL。MSL是报文在网络中的最大生存时间，2MSL能保证一个方向上的报文和对应ACK都自然消亡，防止干扰新连接。

第三层，TIME_WAIT过多会带来什么后果。在高并发短连接场景下，比如大量请求由同一台服务器发出，TIME_WAIT连接会占用大量本地端口和内存，可能导致端口资源耗尽。常见优化方案包括调整TCP参数允许TIME_WAIT复用、开启快速回收（但某些系统上会有副作用）、或者改用长连接从根上减少连接创建次数。这里我不建议一上来就激进调参，先想清楚业务是不是真的适合长连接，再决定怎么处理。

还有一个容易混淆的点：主动关闭方和被主动关闭方在挥手过程中状态迁移完全不同。主动方要经历FIN_WAIT_1、FIN_WAIT_2、TIME_WAIT，被动方要经历CLOSE_WAIT、LAST_ACK。如果服务端大量连接停留在CLOSE_WAIT状态，通常说明服务端应用程序没有正确关闭socket，代码里有连接泄漏，这时候排查方向应该去看应用层，而不是调内核参数。

2.3 拥塞控制与流量控制：别把两个“控制”搞混

流量控制解决的是收发双方处理能力不匹配的问题，通过滑动窗口机制实现。接收方在ACK中通告自己的可用窗口大小，发送方根据这个窗口来控制发送速率，防止把接收方缓冲区打爆。

拥塞控制解决的是整个网络链路承载能力不匹配的问题，需要发送方主动探测网络状态并动态调整发送速率。TCP的拥塞控制经历了多个阶段：慢启动、拥塞避免、快速重传、快速恢复。面试时至少要能把慢启动阶段拥塞窗口的指数增长过程说清楚，把ssthresh的作用讲明白，并且说明快速重传怎么通过重复ACK触发而不是依赖超时。

这里我建议再深挖一个点：BDP（带宽延迟积）问题。传统TCP的拥塞窗口上限受接收窗口限制，但在高带宽长延迟链路（典型如跨地域传输）中，带宽与RTT的乘积可能远大于默认窗口大小，导致TCP吞吐量上不去。这时候需要启用窗口缩放选项才能突破64KB窗口上限。这类问题在实际业务里经常出现，你能主动提到窗口缩放和BDP的概念，面试官对你的评价会明显不一样。

3. HTTP与HTTPS协议面试题实战：从请求到安全握手

3.1 HTTP请求与响应全景：状态码、方法、头字段

HTTP协议这块，面试官通常不会只问“GET和POST有什么区别”这种入门题，而是会围绕一个完整请求生命周期展开。你需要能把请求的构成拆开：请求行、请求头、请求体，以及响应里的状态行、响应头、响应体，每个部分各司其职。

状态码的考察频率很高，建议把常见的几个语义搞清楚，而不是只背数字。2xx代表成功，但201和204语义不同；3xx代表重定向，301是永久重定向、302是临时重定向，这两个在SEO和实际业务中有明显区别；400和422的区别在于语法错误与语义错误；401和403的本质区别是“未认证”和“无权限”；502和504分别代表网关收到了无效响应和网关超时。我见过太多候选人把502和504搞混，这两个在实际排查中完全是两个方向。

头字段方面，Host头在HTTP/1.1中为什么是必选字段？因为一台服务器可以托管多个域名，虚拟主机技术依赖Host头来区分请求属于哪个站点。这个点答得好不好，直接反映你是否理解HTTP/1.1引入虚拟主机的背景。

再说一个容易被忽略的细节：HTTP/1.1的Keep-Alive机制。它允许在一个TCP连接上连续发送多个请求，但是存在队头阻塞问题——同一个连接上的请求必须按顺序处理，前一个请求响应慢了，后面的请求就得排队。这也是推动HTTP/2多路复用出现的核心动力之一。面试时如果能把这个演进逻辑串起来讲，比单独背每个版本的特性要强得多。

3.2 HTTPS握手深入：TLS每次协商到底做了什么

HTTPS的面试题密度近几年明显上升，尤其是TLS握手过程。很多候选人能说出“客户端发ClientHello，服务端回ServerHello、证书，然后双方交换密钥”这种概要，但一旦追问密钥交换的具体步骤就卡住了。

我建议把TLS1.2的完整握手流程按角色拆开记忆。客户端先发送ClientHello，携带支持的TLS版本、加密套件列表和一个随机数。服务端回复ServerHello，选择加密套件和协议版本，下发自己的证书，同时携带另一个随机数。客户端验证证书合法性，然后生成预主密钥，用服务端公钥加密后发送给服务端。双方用两个随机数加上预主密钥，通过PRF算法生成会话密钥。之后双方发送ChangeCipherSpec通知对方后续通信将使用协商好的密钥加密，最后发送Finished消息验证握手是否成功。

这里面试官大概率会追问两个点。第一个是证书校验到底校验了什么。证书链追溯、有效期检查、域名匹配、吊销状态检查，每一步都不能少。很多自建CA的公司在部署HTTPS时最容易踩的坑就是证书链不完整，服务端只发了叶子证书没有发中间证书，导致部分客户端校验失败。第二个是为什么TLS握手过程中既有非对称加密又有对称加密。非对称加密用于安全地协商对称密钥，因为性能差；一旦对称密钥协商完成，后续业务数据都用对称加密，因为性能好很多。这个设计思路是整个HTTPS体系的基石。

TLS1.3相比TLS1.2最大的变化是把RTT从两次降到一次，首次握手只需要一个往返就能完成密钥协商，而且移除了很多不安全的加密套件。如果候选人能主动提一句TLS1.3的1-RTT特性，说明你对协议演进有持续关注。

3.3 HTTP缓存体系：强缓存与协商缓存如何协同

HTTP缓存是实际业务中直接影响性能的环节，面试频率一直不低。核心要理解两套缓存机制配合工作的方式。

强缓存通过Cache-Control的max-age指令控制，在缓存有效期内浏览器不会发任何请求，直接从本地读取。协商缓存则是在强缓存失效后，浏览器带着If-Modified-Since或If-None-Match请求头问服务器资源有没有变化，服务端返回304表示没变，复用本地缓存；返回200表示有变化，用新资源。

这里有一个很实用的经验：ETag的优先级高于Last-Modified。因为Last-Modified只能精确到秒级，如果资源在同一秒内被修改多次，或者被修改后又改回原样，Last-Modified就无法准确判断是否需要重新拉取。ETag基于内容生成指纹，能更精确地判断资源是否真的变化。实际配置时建议两个头都返回，让ETag处理精确判断、Last-Modified作为兜底。

还有一个容易被忽略的坑：Cache-Control的public和private语义。CDN缓存通常只能缓存public响应，如果接口返回了private或者Set-Cookie头，CDN默认不会缓存该响应。很多业务方发现CDN命中率上不去，排查半天最后发现是响应头里带了Set-Cookie导致CDN放弃缓存。这类问题在面试中讲出来，会显得你实践经验非常扎实。

3.4 HTTP/2与WebSocket：长连接时代的两种典型方案

HTTP/2的核心是多路复用，在同一个TCP连接上可以同时交叠多个请求和响应流，解决了HTTP/1.1的队头阻塞问题。它的头部压缩使用HPACK算法，通过静态表和动态表减少头字段传输开销。服务端推送允许服务端主动发送客户端可能需要的资源，减少页面加载往返次数。

但HTTP/2有一个值得深挖的缺陷：虽然解决了应用层的队头阻塞，TCP层的队头阻塞依然存在。因为TCP是顺序字节流协议，一个数据包丢失会导致后续所有数据包等待重传，即使它们属于不同的流。这个问题的彻底解决要依赖HTTP/3基于UDP的QUIC协议，QUIC在传输层实现了多路复用，丢包只影响特定流。

WebSocket和HTTP/2解决的是不同问题。WebSocket提供全双工实时通信能力，适合服务端主动推送消息的场景，比如聊天、行情、协同编辑。它通过HTTP升级机制建立连接，之后双方可以直接发送帧数据。面试中如果被问到“WebSocket和普通HTTP请求有什么区别”，核心就落在“服务端能否主动推送”和“连接是否保持”这两个点上。要注意WebSocket的帧类型里，Ping/Pong帧是实现心跳保活的关键机制，实际部署时为了防止中间设备断开空闲连接，客户端需要定时发送Ping帧。

4. DNS、CDN与网络基础高频题：容易被忽略的送分题与陷阱题

4.1 DNS解析全链路：从浏览器缓存到根服务器

DNS这块，面试官考察的重点是递归查询与迭代查询的区别，以及各级缓存的生效顺序。

完整链路大致是：浏览器发起解析请求后，先查自身DNS缓存，再查操作系统级缓存并检查hosts文件，之后向配置的本地DNS服务器发起递归查询请求。本地DNS服务器如果没有缓存，会从根域名服务器开始迭代查询——先问根服务器"com域的权威服务器是谁"，再问com域服务器"example.com的权威服务器是谁"，逐级往下直到拿到A记录。

面试中容易卡壳的点有两个。第一，DNS记录类型。A记录解析域名到IPv4，AAAA记录解析到IPv6，CNAME记录做别名指向，MX记录用于邮件路由，NS记录指定域名服务器，TXT记录常用于验证域名所有权或SPF邮件防伪。第二，DNS污染或缓存问题怎么排查。工作里最常见的现象是域名解析到了错误IP，这时候先确认本机hosts文件有没有被改过，再检查操作系统DNS缓存，然后用dig直接向指定的可信DNS服务器发起查询，看返回结果是否一致。逐层排查能快速定位是本地缓存问题还是权威DNS配置问题。

还有一个更有区分度的延展题：DNS解析中CNAME和A记录的使用场景差异。CNAME的好处是当目标IP变更时，只需修改CDN厂商侧映射，业务方不需要改动DNS记录。所以CDN接入通常都是配置CNAME。但A记录在性能上少一次解析跳转，适用于直接指定固定IP的场景。业务规模小、IP稳定时用A记录更简单；需要接入CDN或者IP会频繁变动的场景，CNAME是更合适的方案。

4.2 CDN加速原理：边缘节点怎么提升访问速度

CDN面试题往往从“为什么能加速”切入。核心逻辑有三条：一是把内容缓存在离用户更近的边缘节点，缩短网络传输距离；二是通过DNS调度将用户引导到最优节点，一般是网络跳数最少或延迟最低的节点；三是源站仅在缓存未命中或者内容过期时才回源拉取，大幅减少源站压力。

深入一点的问题往往集中在缓存命中与回源策略。CDN边缘节点根据缓存规则决定哪些资源可以缓存、缓存多久。动态请求通常不缓存，需要直接回源；静态资源缓存时间可以设置得很长。这个环节有个常见坑：当源站更新了资源但CDN缓存未过期，用户访问到的仍然是旧版本。解决办法是更新资源时使用版本号或内容hash作为文件名，引导CDN将其视为新资源重新缓存，而不是强行刷新。

面试中还有一个加分点，是CDN如何识别不同用户的地域。通过用户源IP解析归属地，然后结合边缘节点的健康状态和负载情况，DNS调度系统可以返回最优节点IP。如果候选人能主动补充Explain访问日志里的X-Forwarded-For头如何传递用户真实IP，就能进一步证明你对CDN链路有实操认知。

4.3 网络分层模型：不止背七层，更要理解“隔壁层”的协作

OSI七层模型和TCP/IP四层模型是基础中的基础，但面试时提问方式可以很灵活。比如“TCP协议工作在哪一层，为什么UDP不提供可靠性”、“路由器和交换机分别工作在哪一层”、“HTTP和TCP之间还有什么协议”。

我的建议是不要孤立地背每一层的名字，而是按数据的封装与解封装过程来串联。发送端从应用层产生数据，逐层向下添加头信息：传输层加TCP头、网络层加IP头、链路层加以太网头，最后变成比特流传输。接收端反向逐层剥头。这个过程能把各层职责、各层协议、以及数据流向全部串起来，比单独背“应用层是HTTP，传输层是TCP”这种碎片知识有效得多。

常见陷阱题是“TCP和UDP的区别”，除了可靠性、连接状态、传输效率这些标准维度，最好还能补一个场景维度的阐述：视频通话为什么用UDP，因为它可以容忍少量丢包，但必须实时；文件传输为什么用TCP，因为它要求数据完整无损。这种从场景出发的答案，比罗列特性表更显功力。

4.4 短连接、长连接与连接池：性能优化绕不开的基层概念

很多人不知道，面试官问“HTTP keep-alive和TCP长连接有什么区别”时，想要的不是单纯定义，而是两者之间的关系。HTTP keep-alive是应用层协商机制，靠Connection: keep-alive头告知对端这个TCP连接可以被复用；而TCP长连接是传输层的连接状态保持。HTTP keep-alive建立在TCP长连接之上，没有传输层连接保持，应用层的keep-alive无从谈起。

连接池是另一个高频优化点。数据库连接池、HTTP连接池、Redis连接池，本质上都是为了复用昂贵的连接资源、避免每次请求都经历完整的连接建立与断开过程。连接池的核心参数包括最小连接数、最大连接数、空闲超时、获取连接超时等。面试如果被问到“怎么排查连接池耗尽”，排查路径通常是：先看监控确认活跃连接数和空闲连接数，再看慢查询或第三方接口耗时是否过长，最后检查代码里有没有连接泄漏——比如从连接池拿连接后没有正确归还。这类问题常出现在并发高的服务中，候选人能讲出实际排查经历会非常有说服力。

5. 网络排查实战经验：不会这些工具和技术，面试过不了最后一关

5.1 必备排查工具链：ping、traceroute、curl、dig、tcpdump

网络面试最后通常会落到“你怎么排查网络问题”上，这时候工具使用的熟练度就是重要的判断依据。工具本身简单，难的是在合适的场景选对工具，并读懂输出结果。

ping是最基础的连通性检查工具，基于ICMP协议。它能确认目标主机是否可达、网络延迟大致多少。但要注意，很多云厂商的安全组默认丢弃ICMP报文，导致ping不通但业务却正常。所以“ping不通”不能直接等同“服务不可用”。

traceroute用于排查路径问题，它利用TTL逐跳增加来探路，可以看数据包从本机到目标经过了哪些路由节点，以及每一跳的延迟情况。排查“跨地域访问慢”的问题时，traceroute能帮你判断瓶颈是在骨干网、运营商互通还是最后一公里。

curl是排查HTTP问题最顺手的工具。加-v参数可以看完整的请求头、响应头和TLS握手信息；加-w参数可以输出耗时拆解，包括DNS解析耗时、TCP连接耗时、TLS握手耗时、首字节耗时、总耗时等。我遇到接口变慢的问题，第一步就是用curl的-w参数看耗时分布，快速定位瓶颈是DNS、连接还是应用处理。

dig是DNS排查利器。dig domain A可以查默认解析结果，指定@8.8.8.8可以绕开本地缓存直接向指定服务器查询，+trace可以完整展示从根到权威的递归迭代全过程，+short只输出结果。排查DNS生效或污染问题时，这几个参数组合起来基本够用。

tcpdump是深度排查的终极大招。它能在网卡层面抓包，看到真正的报文交互。排查TCP重传问题时，tcpdump -i eth0 tcp port 80抓到的是整个交互过程，再结合-w参数保存为pcap文件用Wireshark分析。生产环境一般不允许随便抓包，所以更需要你能通过抓包结果反推问题。

5.2 实际案例复盘：一次跨地域接口超时到底怎么定位

说一个模拟场景，A同学负责的某服务反馈说从另一个地域调用过来经常超时。他用curl的-w参数做了耗时拆解，发现TCP连接建立这一阶段的耗时异常，经常超过1秒。

正常来说，同地域内网调用TCP握手应该在毫秒级。于是他先ping对端地址验证基础网络延迟，发现ping很稳定只有几毫秒，说明网络链路是通的。接着他本地的tcpdump抓包，同时也让对端同事同步抓包，发现客户端在发送SYN之后会等很久才收到SYN+ACK，中间还有大量SYN重传。

这时候瓶颈就不在客户端和服务端应用，而更可能在中间链路。用traceroute逐跳检查后发现，从客户端到服务端需要经过某一个安全设备节点，该节点转发延迟明显异常，而在其他时间段复测又恢复正常。进一步排查确认是该安全设备在特定流量特征下触发了深度检测，导致转发性能下降。最后通过调整安全策略白名单，问题解决。

这个案例的价值在于展示了正确的排查路径：从应用层耗时拆解，到传输层连通性验证，再到路径逐跳排查，最后定位到设备策略问题。面试如果能把这种排查思路讲清楚，比单纯背工具参数有用得多。

5.3 高频面试问题快查表

整理一张面试前可以快速过一遍的快查表，覆盖最常被问到的点。

6. 面试表达技巧与复习建议：把知识转化为面试官听得懂的语言

6.1 用"链路思维"回答问题：让面试官觉得你懂网络

我面试过很多候选人，有的技术深度不差，但表达方式非常吃亏。最常见的问题是把答案拆成碎片，问什么答什么，缺少串联。其实面试官自己心里有一张网络知识地图，他每次追问都是在检查你脑子里有没有这张地图。

我建议在面试中养成一种回答习惯：先给结论，再展开链路，最后落回场景。举例来说，被问到HTTPS时，先概括说HTTPS是在HTTP和TCP之间加了一层TLS，用于加密传输，然后展开说TLS握手过程，最后补充说实际部署中要注意证书链完整性和TLS版本兼容性。这样回答层次清晰，有深度有广度，面试官想追问也能找到切入点。

另一个值得注意的表达技巧是主动承认边界。被问到自己确实不了解的领域时，与其强行编造，不如坦诚说这块没有深入实践过，同时说明如果遇到这个问题你会用什么样的排查路径去定位。面试官看重的往往不是你什么都会，而是面对未知问题时你的学习方法论和分析框架。

6.2 面试复习路线图：三个月打牢网络基本功

准备网络面试不建议临时抱佛脚啃大部头，而是要有节奏地分层推进。

第一个月打地基，目标是建立起完整的网络分层认知。这段时间不要急着背面试题，而是要把每一层协议的核心机制弄清楚，尤其是TCP的连接管理、可靠传输、流量控制、拥塞控制四大机制，以及HTTP从1.0到1.1到2到3的演进主线。

第二个月做实践连接，目标是让自己具备基本的排查能力。建议自己在本地搭几个实验环境，用curl加-v观察HTTP交互，用dig观察DNS响应，用tcpdump抓一次TCP握手包和挥手包，对照Wireshark看序列号、确认号、标志位的变化。亲手抓到包看过之后，很多概念就变成了肌肉记忆。

第三个月刷题巩固，针对高频考点做输出训练。建议不要只看答案，而是模拟面试场景开口讲，每个问题控制在两分钟左右，讲完回头看有没有把核心机制说清楚。这个阶段也可以找朋友互相提问，你会发现听别人描述和自己组织语言是完全不同的体验。

6.3 一些踩过坑之后才明白的心得

最后分享几个我在实际面试和工作中积累的教训。

第一个是别在简历上写“精通TCP/IP”。这个话一旦写上去，面试官就会默认你可以应对所有协议细节的追问，而大部分候选人其实达不到这个标准。踏实写“熟悉TCP/IP协议栈，具备网络问题排查经验”反而更稳妥。

第二个是面试里如果被要求画图，比如画TCP状态迁移图或HTTPS握手流程图，尽量先在草稿纸上理清顺序再动手画。画图的过程本身就是在考察你的逻辑是否清晰，画歪了比不画印象更差。

第三个是养成看RFC的习惯。很多面试题的争议点，比如TIME_WAIT到底是主动关闭方还是被动关闭方进入的，不同文章说法不一。这种时候直接翻RFC 793看原始定义，比看二手资料可靠得多。当然面试时候不用背RFC原文，但你要能确保自己理解的依据是可靠的。

网络知识体系庞大且环环相扣，准备面试的过程其实也是重新夯实基本功的过程。相比背熟答案，我更建议你理解这背后的运行逻辑，把这些协议当成一个个解决实际问题的方案来学习。真到了面试现场，你脑子里有一张完整的链路图，任何追问都不会把你带偏。