面试网络岗这么多年我发现一个很有意思的现象大部分候选人对网络知识的掌握停留在“背诵八股文”的阶段。问你三次握手能背得滚瓜烂熟但一追问“为什么不是两次”、“最后一次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服务端回复SYNACK客户端再回ACK连接建立。但在面试实践中追问环节才是真正的分水岭。先看“为什么不能两次握手”。这个问题的标准回答是防止历史重复SYN报文建立无效连接。假设客户端发送的SYN报文因为网络拥堵被延迟客户端超时后重发SYN并成功建立了连接、完成了数据传输、关闭了连接。此时之前那个延迟的旧SYN报文才到达服务端如果采用两次握手服务端就会直接建立一条新的连接但此时客户端根本没有这个连接诉求于是这条连接白白占用了服务端资源。有了第三次握手服务端收到旧SYN后会回复SYNACK客户端发现自己并没有发起新的连接请求就会回复RST报文来终止这个无效连接。这个解释本身没问题但很多候选人答到这里就停了。如果再追问一句“三次握手有没有什么缺陷”很多人就愣住了。实际上三次握手最典型的问题就是SYN Flood泛洪攻击——服务端收到SYN后需要分配传输控制块等资源如果攻击者只发SYN不回ACK服务端资源会被快速耗尽。所以现代操作系统都引入了SYN Cookie机制不直接分配资源而是通过编码计算生成一个Cookie放在SYNACK中回复等客户端真正回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记录解析域名到IPv4AAAA记录解析到IPv6CNAME记录做别名指向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之后会等很久才收到SYNACK中间还有大量SYN重传。这时候瓶颈就不在客户端和服务端应用而更可能在中间链路。用traceroute逐跳检查后发现从客户端到服务端需要经过某一个安全设备节点该节点转发延迟明显异常而在其他时间段复测又恢复正常。进一步排查确认是该安全设备在特定流量特征下触发了深度检测导致转发性能下降。最后通过调整安全策略白名单问题解决。这个案例的价值在于展示了正确的排查路径从应用层耗时拆解到传输层连通性验证再到路径逐跳排查最后定位到设备策略问题。面试如果能把这种排查思路讲清楚比单纯背工具参数有用得多。5.3 高频面试问题快查表整理一张面试前可以快速过一遍的快查表覆盖最常被问到的点。问题核心回答要点三次握手为什么不能两次防止历史SYN建立无效连接同时同步初始序列号四次挥手TIME_WAIT原因确保最后的ACK能重发2MSL保证旧报文消亡大量CLOSE_WAIT意味着什么应用层没有正确关闭socket通常是连接泄漏TCP和UDP怎么选可靠性优先选TCP实时性优先选UDP看场景流量控制和拥塞控制区别前者解决双方处理能力不匹配后者解决链路承载问题HTTP/2解决了什么问题多路复用解决队头阻塞HPACK压缩头字段HTTPS证书校验查什么证书链、有效期、域名匹配、吊销状态ETag和Last-Modified怎么选ETag精度更高Last-Modified作为兜底DNS递归和迭代什么区别递归是替客户端完成全部分析迭代是一级级询问DNS缓存顺序是什么浏览器缓存、系统缓存和hosts、本地DNS服务器、根到权威CDN为什么能加速就近分发缩短距离、DNS调度选最优节点、源站压力分担连接池参数要关注哪些最小/最大连接数、空闲超时、获取超时怎么排查接口变慢curl拆耗时、traceroute看路径、tcpdump抓包分析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原文但你要能确保自己理解的依据是可靠的。网络知识体系庞大且环环相扣准备面试的过程其实也是重新夯实基本功的过程。相比背熟答案我更建议你理解这背后的运行逻辑把这些协议当成一个个解决实际问题的方案来学习。真到了面试现场你脑子里有一张完整的链路图任何追问都不会把你带偏。
