百度核心网络研发校招笔试题解析：TCP/IP、epoll与网络底层考点

这份2018年的百度核心网络研发校招笔试题，放到今天来看依然很有参考价值。核心网络研发岗不像普通后端，它不看你会不会调接口，考的是你对网络协议栈、内核收包路径、高性能网络编程和规模化的网络架构有没有体系化的理解。这篇文章我结合自己多年做网络研发和带校招的经验，把这类卷子背后的考点和答题思路拆开讲一遍，重点不是给你背答案，而是告诉你每道题为什么这么考、应该怎么答才能踩到点上。

1. 先看懂这份卷子的筛选逻辑，再谈做题

1.1 核心网络研发工程师和业务后端，笔试考的不是一类东西

很多人第一次看到"核心网络研发工程师"这个岗位名，下意识会把它当成"后端开发的一个分支"。这个认知偏差在笔试里会吃大亏。普通后端笔试的题面经常是某个业务场景——比如设计一个订单系统、写个接口、聊聊数据库索引；但核心网络研发的卷子，题面会直接落在协议、内核和流量调度这些基础设施层。

我记得当时拿到卷子的第一感觉是：它不太问"你怎么用网络"，而是问"网络本身是怎么工作的"。比如一个HTTP请求从客户端发出到服务端收到，中间要经历哪些协议封装、哪些内核处理、哪些队列缓冲；这些内容在业务开发里通常被框架屏蔽掉了，但在网络研发岗就是基本功。

这个岗位做的东西，说白了就是替整个公司扛住流量：接入层的负载均衡、网关、DNS调度、内核协议栈优化、网络故障排查、甚至自研网络硬件加速。笔试题自然围绕这几个方向展开——TCP/IP协议栈的深度理解、Linux下数据包的收发路径、高并发网络编程模型、网络系统的容量估算和异常排查。

所以你在复习时先要转换心态：不需要再纠结Spring或者业务架构，重点要往底层走。卷面上考的不是"知识面广不广"，而是"网络这一个方向的纵向深度有多深"。

1.2 "第一批"笔试传递的筛选信号

这题还有一个容易被忽略的细节：标题里写了"第一批"。校招笔试分批次发放，通常第一批是最早开放投递的一批候选人，可能对应提前批或者第一波集中笔试。这个时间点意味着什么？意味着岗位还在做海量筛选，题目的设计会更偏向"通用基础能力"而非"特定项目经验"。

也就是说，这一批题不会拿某个具体业务来考你，而是用一套相对标准化的网络知识体系来过滤人。它希望筛选出具备这种能力画像的人：协议栈理论基础扎实、对Linux网络实现有深入理解、能上手写高性能网络代码、具备故障排查的工程直觉。

这个筛选逻辑决定了你的复习策略不能只靠刷LeetCode式的题目。算法题可能有，但占比不会大，核心还是网络本身的专业深度。后面几个章节，我按这份卷子最可能涉及的六个知识板块，逐一拆解考点和答题要点。

2. 传输层必考题：TCP状态机、拥塞控制、QUIC

2.1 三次握手与四次挥手：能写状态迁移才算真会

传输层是网络研发笔试的绝对重点。它最爱考的一道题，就是让考生画TCP三次握手和四次挥手的过程。但这里的"画"不是把那张经典的时序图画出来就完了，关键要看你能不能把每个阶段的状态迁移写全、写准。

我开始看卷子的时候有个发现：很多人能画出一个连接从建立到释放的完整序列，但一旦问到细节就撑不住了。比如：客户端发送SYN之后处于SYN_SENT，服务端收到SYN回复SYN+ACK后进入SYN_RCVD，客户端再回复ACK后进入ESTABLISHED，服务端收到ACK后也进入ESTABLISHED——这套流程大多数人没问题。但只要改问"如果客户端的ACK丢了会怎样"，很多人就开始含糊了。

这类追问背后的真实需求，是判断你是否有能力处理线上的连接异常。SYN Flood攻击靠的就是不回复ACK，让服务端堆积半连接；TIME_WAIT过高会耗尽四元组导致连接建立失败；大量CLOSE_WAIT说明服务端业务一直没关闭连接。这些已经不是单纯的概念，而是实打实的故障场景。

答题建议是：不要只默画时序图，要额外标注状态迁移边界。比如客户端主动关闭连接后会进入FIN_WAIT_1、FIN_WAIT_2、TIME_WAIT，其中TIME_WAIT要等待2MSL的原因——保证最后一个ACK能重发，同时让旧连接的报文在网络中自然消亡。能答出这层，说明你理解的是为什么，而不只是是什么。

2.2 拥塞控制算法：别只背慢启动，比较题才是拉分点

拥塞控制在网络研发笔试里属于必考但很容易答浅的模块。经典的四件套——慢启动、拥塞避免、快重传、快恢复——几乎所有人都能说出大概。但这类卷子不会满足于让考生背名词，它更可能出比较题：Reno、CUBIC、BBR之间有什么区别？各自的适用场景是什么？

Reno是最经典的基于丢包的拥塞控制，把丢包当作拥塞信号，一旦检测到丢包就减半拥塞窗口。它在低带宽、低时延的网络上够用，但在长肥网络（高带宽高时延）里有个致命问题：因为TCP的窗口增长是加性的，在BDP很大的链路上，窗口要很久才能恢复，带宽利用率很低。

CUBIC是Linux的默认算法，它改成了三次函数增长窗口，在丢包发生后能用更快的速度恢复窗口，在高带宽链路上比Reno激进得多。而BBR则是从根上换了思路：不再把丢包看作唯一信号，而是实时测量瓶颈带宽和最小RTT，用这两个参数直接计算发送速率。它最大的价值是在有buffer膨胀的网络里表现更好，因为丢包不等于链路满了，可能是buffer把包缓冲了。

答这类题时，要给面试官传递一个信号：你读过RFC、了解算法演进的历史逻辑，而不只是用过Linux默认配置。能说出"BBR适合在浅buffer环境下避免排队时延增长""CUBIC在高带宽下恢复更快但容易造成burst"这种细节，得分会完全不一样。

2.3 UDP与QUIC：可靠传输不是只有TCP一条路

传输层还有一个高频考点是UDP，以及建立在UDP之上的QUIC。很多校招生对UDP的理解仅停留在"不可靠、无连接、性能好"这九个字上，这在网络研发笔试里是不够的。

笔试偏爱问UDP，不是问UDP本身多简单，而是问：如果要在不可靠的UDP之上做可靠传输，需要补齐哪些机制？这就把考卷从"背概念"推向了"做设计"。答案其实就是把TCP的可靠传输要素列一遍：序列号、确认应答、超时重传、滑动窗口、拥塞控制，缺一不可。

再往前一步，QUIC就是这种思想在真实世界的工程实现。它基于UDP，在用户态实现了可靠传输和拥塞控制，又因为工作在用户态而获得了快速迭代的能力。HTTP/3跑在QUIC上，解决了HTTP/2的队头阻塞问题。

为什么网络研发岗会关心这个？因为大厂的基础网络设施里，UDP承载的流量比重越来越高——自研的可靠UDP协议、音视频传输、QUIC接入层优化都是重要方向。笔试里出现QUIC相关的选择题或简答题其实是在试探你对新协议栈的敏感度。建议复习时至少把QUIC的连接建立（0-RTT/1-RTT）、队头阻塞解决方案、和TCP+TLS的对比这几个点搞清楚。

3. Linux协议栈专题：数据包是怎么从网卡到应用的

3.1 完整收包路径：这张图要刻进脑子里

第二类必考内容是Linux内核网络协议栈。这也是"核心网络研发"区别于普通后端最明显的地方。

笔试最常见的问法：一个数据包从网卡到达用户态进程，完整经过哪些环节？要求按顺序写出来，越细越好。一个合格的答案大致是这样的：网卡收到数据帧，通过DMA把数据写入Ring Buffer，触发硬中断；CPU执行中断处理程序，把数据从Ring Buffer取出，调用NAPI机制调度软中断；软中断运行在ksoftirqd进程或当前进程上下文中，进行协议栈处理——依次是链路层（剥掉以太网帧头）、网络层（IP校验、路由查找）、传输层（TCP/UDP头部解析、找到对应socket）；最终数据被放入socket接收队列，用户态进程通过read/recv系统调用把数据拷贝到用户空间。

这个链路里有大量容易被追问的细节。比如DMA和CPU拷贝的区别，硬中断为什么不能做太多事（会阻塞其他中断处理），软中断里为什么要运行在特意调度的上下文中，以及最终从内核态到用户态的那次拷贝能不能省掉。这些细节不用全答，但答得越全，笔试分数越高。

我当时复习时的一个技巧是：把这条路径画成一张大图贴在自己眼前，每天对着它复述一遍。不是背，而是每讲一遍就尝试追问自己"这一步如果出问题会怎样"。比如Ring Buffer满了会触发丢包？丢包时网卡有没有计数寄存器？这种追问会把知识从线性记忆变成网状理解，面试问到就不会慌。

3.2 中断、软中断与NAPI：CPU为什么会被"打满"

上面收包路径里提到的软中断和NAPI，本身就是独立的考点。笔试会绕开"常规操作"，直接考机制背后的权衡。

先看中断的问题：网卡每来一个包就触发一次硬中断，如果包速率很高，CPU会疲于响应中断，根本没有时间去消费队列里的数据，反而造成吞吐下降。这就是所谓的"中断风暴"。所以内核引入了软中断机制：硬中断里只做最少的必要动作，把耗时的协议栈处理下沉到软中断。这样在一次硬中断中，可以连续处理多个包（NAPI），减少中断次数，提高吞吐。

NAPI的核心逻辑是：网卡收到包时不是每次都主动发中断，而是先通知内核"我这里有一批包要处理"，内核在处理完这一批包后可以继续轮询网卡队列，直到队列为空或达到预算（budget）才重新开启中断。这样在高速收包场景下，CPU从被动响应中断变成了主动轮询，性能提升非常明显。

笔试考这个点，通常给一个现象让你分析：某台服务器网络吞吐很低，top命令看到si（软中断）占用率几乎100%，但网卡流量并不高。原因是什么？典型的答案方向是：网卡队列和CPU中断没有做亲和性绑定，所有包都打到了同一个CPU核上；或者开启了RPS/RFS但配置不当，导致软中断负载不均。这种题考察的已经不只是书本知识，而是你是否理解软中断在真实服务器上的运维表现。

3.3 零拷贝和DPDK：高性能网关的必经之路

内核协议栈专题里还有一个非常能拉开分差的考点：零拷贝与内核旁路技术。

零拷贝要解决的问题很直接——传统收发路径里数据要在内核态和用户态之间搬运多次（DMA、内核拷贝、用户态拷贝），这对高吞吐低延迟场景是很大的损耗。经典的零拷贝方案有mmap和sendfile：mmap让用户态直接映射内核缓冲区，省去一次读拷贝；sendfile在文件到socket的传输上直接由内核完成数据搬运，用户态根本不接触数据。这类知识在网络研发岗的笔试里经常以"有哪些减少数据拷贝的手段"形式出现。

DPDK则是更彻底的内核旁路方案。它绕过内核协议栈，让应用在用户态直接通过轮询模式从网卡取包，配合大页内存和CPU亲和性，把包处理能力推到千万级PPS以上。笔试考DPDK时，最常见的切入点是让它和传统内核协议栈做对比：为什么内核协议栈达不到线速？有哪些瓶颈？DPDK为此做了哪些优化？

坦白说，DPDK对校招生来说偏深，但正因为偏深，它在笔试中一旦出现，答好的人就很容易脱颖而出。如果你有余力，至少把"DPDK为什么能更快——轮询vs中断、用户态驱动vs内核驱动、免拷贝vs逐次拷贝"这个逻辑链捋清楚。

4. 高性能网络编程：epoll题目怎么答才不丢分

4.1 select、poll、epoll：从使用到原理的横向对比

网络研发笔试里，网络编程模型基本是必考的，核心就是I/O多路复用。选择题里最常出现的就是select、poll、epoll的对比，很多考点其实是"原理层面"的。

先说select，它的问题非常明显：fd_set是位图结构，单个进程能监听的fd数量被FD_SETSIZE限制（通常是1024）；每次调用select都要把整个fd_set从用户态拷贝到内核态；内核通过线性扫描全部fd来找出就绪事件，fd数量多起来后效率线性下降。

poll解决了数量限制，它用链表（实际上是一个pollfd数组）代替位图，不再受1024上限的限制。但每次调用还是要全量拷贝、全量扫描，所以只是从"受数量限制"变成了"受性能限制"epoll则彻底换了一套思路。它在内核中维护一棵红黑树来管理所有被监听的fd，通过回调机制只把真正有事件发生的fd放入就绪链表，用户态通过epoll_wait获取事件时，只需要从就绪链表里取，不用再全量遍历。

这个"就绪事件通知"和"只返回活跃fd"的思想，是区别平庸答案和优秀答案的分水岭。答题时不能只说"epoll是事件驱动、性能好"，要说清楚它是通过红黑树+回调的方式避免了全量扫描。

4.2 水平触发与边缘触发：笔试最容易被追问的细节

epoll的细节里最容易被反复追问的就是水平触发（LT）和边缘触发（ET）的区别。这也是一个容易让考生出错的点。

简单说，LT模式下，只要fd还有数据可读，每次epoll_wait都会返回该fd；ET模式下，只有当fd状态发生改变（比如从无数据变成有数据）时才会返回，而且只返回一次。ET模式下你必须一次把数据读完，否则剩下的数据可能再也不会触发事件，导致数据滞留半程。

笔试最常见的陷阱题是：在LT模式下，用阻塞socket在循环里recv，会有什么问题？答案是：如果缓冲区已经读完，下一次recv会阻塞住整个线程。所以高并发服务器一般要用非阻塞socket，配合ET或自己控制好读取时机。这个看似只有一句话的结论，背后是对I/O模型的综合理解。

我当时复习时总结了三条答题要点：第一，ET是边界触发，靠状态变化通知；第二，ET配合非阻塞socket可以显著减少epoll_wait的重复唤醒次数；第三，ET模式下必须循环读取直到EAGAIN。能把这三条讲清楚，epoll相关的简答题基本就拿下了。

4.3 从Reactor到百万连接：线程模型怎么设计

除了多路复用的API，笔试还喜欢考网络服务的线程模型，最经典的就是Reactor模式。问法通常是：设计一个高并发的网络服务端，你会怎么组织线程？要求画出模型图并解释。

一个标准的答案是：主线程只跑event loop，负责accept新连接。连接建立后注册到epoll里，由一组工作线程（或者叫子Reactor）共同承担这些连接的I/O事件分发。收到I/O事件后，再由线程池里的业务线程去处理具体逻辑。这就是单Reactor多线程、或者多Reactor多线程的经典形态。

如果是多Reactor模型，通常用一个Main Reactor专门负责accept，再把连接分发给多个Sub Reactor，每个Sub Reactor有独立的epoll实例和线程，负责批量连接的读写事件。这种设计能解决单线程event loop带来的CPU瓶颈，是Nginx、Netty等框架普遍采用的模型。

笔试如果考到这个点，建议在答题时画出清晰的线程模型图，并用一句话点出每种模型的取舍：单Reactor单线程简单但不能充分利用多核；单Reactor多线程解决了业务处理慢的问题，但event loop本身可能成为瓶颈；多Reactor多线程把accept和读写分离，是高性能服务的主流选择。这套话术在笔试和面试里都非常通用。

这里也可以给一个小型epoll服务端的核心框架，方便你在卷面上展示代码能力：

epoll_fd = epoll_create(MAX_EVENTS); struct epoll_event ev; ev.events = EPOLLIN; // 默认LT模式 ev.data.fd = listen_fd; epoll_ctl(epoll_fd, EPOLL_CTL_ADD, listen_fd, &ev); while (1) { int n = epoll_wait(epoll_fd, events, MAX_EVENTS, -1); for (int i = 0; i < n; i++) { if (events[i].data.fd == listen_fd) { conn_fd = accept(listen_fd, ...); set_nonblocking(conn_fd); ev.events = EPOLLIN | EPOLLET; // ET模式 ev.data.fd = conn_fd; epoll_ctl(epoll_fd, EPOLL_CTL_ADD, conn_fd, &ev); } else { // 已就绪的socket，循环读取直到EAGAIN handle_event(events[i].data.fd); } } }

这段代码里的关键点就是accept后设置非阻塞、ET模式、循环读取，我在前面都讲过了。笔试现场能写出这样一段结构完整的伪代码，是很加分的。

5. 系统设计题：负载均衡、DNS与容量估算

5.1 设计一个四层/七层负载均衡，答题框架是什么

网络研发岗位笔试的简答题部分，一定会出现系统设计题。最常见的题面是：设计一个大规模流量下的负载均衡系统。这类题表面上是开放设计，实际上有相对固定的答题框架。

首先需要区分四层负载（L4）和七层负载（L7）。四层负载工作在网络层/传输层，基于IP和端口转发，性能极高，典型的实现是LVS、DPDK转发；七层负载工作在应用层，能把HTTP请求拆开看URL、Header、Cookie等来做更细粒度的路由，典型实现是Nginx、Envoy。笔试时最好先明确自己设计的是哪一层，再往下展开。

答题框架我建议四步走。第一，数据流：一个请求从客户端进来，经过负载均衡器，如何转发到后端RS（Real Server），是否需要做NAT，源IP怎么保留，回程流量怎么走。第二，后端管理：健康检查怎么做（主动探测端口还是被动摘除异常节点），服务发现如何感知后端变化。第三，调度策略：轮询、最少连接、一致性哈希分别适用什么场景。第四，可用性：负载均衡器自身挂了怎么办，如何做到主备切换或集群化。

这四步写完，一道负载均衡设计题基本就稳了。尤其是"一致性哈希"这一点，在会话保持（session sticky）场景下几乎是必答项。如果读者对一致性哈希不熟，可以这样理解：普通取模哈希在后端节点变化时会导致大量key重新映射，而一致性哈希让每个key只沿哈希环向后找最近的节点，节点增减只影响很小的范围，会话不会大面积失效。

5.2 全局链路题：一个域名访问背后的网络调度

除了单机负载均衡，笔试还喜欢从全局视角出题，最常见的是DNS与接入层调度。题面可能是：用户输入一个域名，请求经过了哪些环节才到达后端服务器？如果某个机房的机器故障，流量怎么自动切换？

这种题考察的是全链路理解能力。完整链路是：用户浏览器本地DNS缓存、操作系统DNS缓存、本地递归DNS（通常由运营商提供）、根DNS、顶级域DNS、权威DNS——最终返回域名对应的IP。而这个IP很可能是CDN节点的IP、或者GSLB（全局负载均衡）分配的最优机房IP。GSLB会根据用户来源地区、机房负载、链路质量，把不同用户调度到不同机房。

后面接的就是我在上一小节说过的负载均衡层：四层VIP接入、七层路由、服务发现、后端实例处理。这里要格外注意每个环节的"失效转移"：递归DNS缓存了某个IP，但该机房整体故障了怎么办？这就需要在权威DNS层面配置短TTL，或者用GSLB结合健康探测把故障机房的IP从解析结果里剔除。

笔试答题时，不用太纠结于某个细节，但要体现"链路思维"：从客户端到服务端的每一跳，都涉及协议解析、缓存查找、健康检查和流量调度。把这条链讲完整，就已经比大多数只盯着TCP三次握手的考生高一个层次了。

5.3 容量估算：笔试题里的"硬算"关卡

网络方向的笔试卷子里，计算题一定有且不止一道。最常见的就是容量估算：一个网卡千兆、万兆，一个包长1500字节，包处理能力上限是多少？一台服务器能支持多少并发连接？一个4层负载均衡集群能扛多大流量？

这类题不难，考的是基本功和单位换算。我举一个最典型例子：千兆网卡，满载（1Gbps）下，如果全是64字节小包，每秒最多能收多少个包？计算过程是：1Gbps = 10^9 bit/s（在运营商语境里按十进制），一个包有64字节数据加8字节前导码加12字节帧间隙（通常简化为84字节），但考试时一般只算64字节本身加上TCP/IP头部开销。更严格的算法是算上以太网帧头、CRC、前导码和帧间隙。

简化版本：10^9 / (64 * 8 + 96 * 8 之类) 约等于每秒148万PPS。如果连IP头部（20字节）和TCP头部（20字节）也算进用户数据里，那纯用户数据吞吐会再打折。笔试里这类题目不会让你写完整程序，但你会不会把bit/s和B/s换算对、会不会把帧间隙和最小帧长算进去，非常能看出工程基本功。

我比较推荐做题时把公式和单位写清楚，比如"先计算单包处理耗时，再换算PPS"，不要在卷面上只写结果。因为笔试阅卷时，批改人对"思路完整但答案算错"的容忍度，远高于"直接给一个数字但没有过程"。

6. 故障排查题：抓包输出与指标解读是考察重点

6.1 典型故障场景：从现象到根因的书面推演

网络研发岗的笔试，后面部分通常会有1~2道故障排查题。这类题不给真实的线上环境，而是给一段文字描述或者一张抓包截图的文字化表达，让你分析根因。它考察的不是你能不能当场修好，而是有没有形成规范化的排查思路。

我见过最典型的题面是：某服务对外表现正常，但内网调用另一个服务偶发超时，且超时频率随流量增加而上升。给了简单的网络指标——丢包率0.1%、TCP重传率上升、P99时延和P50时延差距拉大。让考生分析可能的根因。

这种题没有唯一答案，但高分答案通常有一个共同特点：按"现象→假设→验证"的结构来答。先归纳现象是"低频超时、重传增多"，再提出若干个假设：网络设备buffer打满导致丢包、后端线程池饱和导致accept队列溢出、两台机器之间的链路存在偶发故障。最后针对每个假设写出验证方式——分别用ss看接收队列长度、用抓包看重传的模式是周期性还是突发性、看服务端监控里是否出现大量TIME_WAIT或拒绝连接。

答题时千万不能只丢一句话"可能是网络抖动"。要展开成上面这样的完整链路，阅卷人才会认为你具备独立排查线上问题的能力。

6.2 tcpdump与ss：笔试会怎么考工具

故障排查题和工具使用是绑定的，笔试卷子里几乎不会让你写出完整命令，但会在选择题或简答题里考关键参数。最常涉及的是tcpdump和ss/netstat。

tcpdump的核心参数基本是：-i指定网卡、-n不要做DNS反解、-s指定抓包长度、-w写文件、-c抓取包数。笔试爱考的还有抓包过滤表达式，比如tcp port 80、src host 10.0.0.1、tcp[13] & 2 != 0表示SYN包。其中"tcp[13] & 2 != 0"这种表达式能看懂的人比例很低，一旦出现就能拉开差距。TCP头部第13个字节（相对于TCP头起点）是控制标志位，SYN标志位对应0x02（第二位）。

ss命令会考怎么看连接状态：ss -t看TCP连接、ss -l看监听、ss -s看汇总、ss -tnp带进程信息。笔试中可能会给一个"服务器上有大量TIME_WAIT"的监控截图，问你怎么确认、怎么处理。这时除了用ss看到具体数量，最好还能说出调整内核参数，比如tcp_tw_reuse（在客户端场景下复用TIME_WAIT连接）和tcp_max_tw_buckets等。能答到这里，说明你真的处理过类似问题，而不是只背过概念。

6.3 读抓包信息的三个关键点

如果笔试给了抓包输出的文本（tcpdump打印的包头信息），你需要从里面快速读懂三段关键内容：第一，TCP标志位（SYN、ACK、RST、FIN）；第二，序列号和确认号；第三，重传包和时间戳。

看标志位很容易判断连接阶段。比如连续出现多个SYN但没有对应ACK，基本可以判断有连接建立失败或者被防火墙丢弃。看到RST，说明某一端根本不想继续这个连接，常见原因是端口未监听或者应用层异常。大量重复的Seq号加上"TCP Retransmission"，说明网络在丢包、或者接收端处理不过来导致缓冲被丢弃。

这些读包能力在笔试里很难临时准备，建议考前用Wireshark或tcpdump亲自抓一次本机访问某个网站的完整包，自己对着抓包文件走一遍三次握手和HTTP请求。这是我个人觉得性价比最高的复习方式，因为书本上的很多概念，只有你在真实抓包里看到过一遍，才会在笔试时快速反应。

7. 三个月备考路线和阅卷人视角的答题技巧

7.1 时间线：基础、专项、模考三阶段怎么分配

如果你在准备这类网络研发岗的笔试，我建议按三个月左右的时间铺开，不要上来就刷题，因为这套知识体系必须按层次建立。

第一个月是打基础和补盲区。目标是啃完一本体系化的计算机网络教材（TCP/IP详解卷一的经典内容、或者更工程化的《Unix网络编程》卷一），把前面说的TCP状态机、拥塞控制、I/O多路复用这些核心概念全部吃透。这一阶段不要贪快，每学完一部分就找相关真题做自测，确认自己是"真懂了"而不是"看懂了"。

第二个月做专项深挖。按传输层、Linux协议栈、网络编程、系统设计、故障排查五个大方向各花一周左右。这一阶段要主动往深处问"为什么"。会答三次握手还不够，要追问如果SYN丢了会怎样、半连接队列满会怎样、全连接队列满会怎样。只有把这些问题一个个逼问完，才算过关。

第三个月进入真题模拟。严格按照考试时间做套题，做完整理错题对应的知识盲区，回到教材和RFC里补。这个阶段要多写"完整答案"，不要只看正确答案然后觉得"我会了"。网络笔试的简答题很多，别人写得长不代表分数高，但你写得短而散基本不可能拿高分。

7.2 阅卷人视角：哪些答案一眼就是背的

我实际接触过笔试阅卷，可以分享一下阅卷人的直觉。一份卷子，从答法上基本能判断出考生是理解的还是背诵的。

背出来的答案有个典型特征：概念名词全部正确，但逻辑链条缺失。比如写TCP快重传，能写出"收到3个重复ACK立即重传"，但问为什么是3个而不是1个，就答不出来。这种答卷在一堆卷子里非常容易被识别——因为网络方向的题几乎都是"原理可推导"的。理解的人能从"网络中的报文可能乱序推迟到达"推出"需要多个重复ACK来抵消乱序带来的误判"，才能推导出"3"这个数。

另一类低分答案是什么都往上堆。一道关于拥塞控制的简答题，把慢启动、线性增长、快恢复全都写上去，但没有回答题目真正问的"为什么要快速恢复"。写得多不代表答得准。答题时先判断考点，再围绕考点组织答案，把"定义+机制+原因"这个三段结构保持住，比堆砌知识点要有效得多。

我给一些可以加分的细节：在状态迁移图的每个箭头旁边标注触发条件，在Reactor设计题的图上标注每条连接上的数据流方向，在容量估算题里写出单位换算的中间过程。这些都不是炫技，而是让阅卷人感觉到"这个人确实动过手"。

7.3 写给网络方向同学的个人建议

最后一个部分，我想说点个人体会。这些年看下来，能通过核心网络研发笔试的候选人，往往不是在考前突击背了最多概念的人，而是那些平时就喜欢折腾网络的人：自己用虚拟机搭过三层网络、在服务器上抓包分析过一次连接异常、试过修改内核参数看效果、对tcpdump输出的每一行都有真实认知。

笔试只是个筛选入口，它考的所有内容，本质上是希望捕捉到你对网络基础设施的热情和敏感度。如果你在复习时觉得某个知识点"非常枯燥"，不妨停一下，去找一个对应的实验来验证它。把三次握手抓一次包、把TIME_WAIT调一次参数、用epoll写一个带ET模式的回显服务器，这些动手体验会比你多看十遍课本更有用。

最后再分享一个小技巧：做笔试题时，碰到不会的简答题，先把题目里提到的所有实体列出来，然后从"数据的流向"开始描述。比如问到"一个客户端连接在服务器上经历了哪些队列"，你可以从accept队列讲到socket接收队列，再讲到用户态缓冲区。就算最终答案不完整，这条完整的流水线也会给阅卷人留下结构清晰的印象。网络题目最大的特点就是数据是有路径的，你顺着路径走，答案自然就铺开了。