提到大厂校招里的“核心网络研发工程师”，很多人第一反应是：这不就是运维吗？其实完全两码事。这个岗位在百度内部管的是接入层负载均衡、数据中心网络、协议栈优化、流量调度这些基础设施，简单说，用户每一次搜索、每一个视频请求背后，都会经过这些代码和系统。所以这套笔试的题目风格非常鲜明：不考框架、不考SQL，而是把TCP/IP协议栈、Linux内核收包路径、路由查找、拥塞控制这些底层原理往死里挖，还会顺手让你手写一段带边界条件的代码。
这套题不是给“背过OSI七层”的人准备的，而是给真正处理过连接超时、带宽打不满、半连接队列爆掉这些问题的人准备的。如果你正在准备大厂网络方向或基础设施方向的校招，或者你想检验自己对网络底层的理解是不是停留在书本层面，这篇复盘值得认真看一遍。我会按试卷的实际风格，把高频考点、典型计算题、手写题思路、易踩的坑全部展开讲。
1. 内容整体设计与思路拆解
1.1 核心网络研发到底解决什么问题
想理解这套笔试题为什么长这样，先得搞清楚岗位本身是干嘛的。把公司业务比作一个大商场，后端开发是负责每个店铺的收银系统，而核心网络研发负责的是整栋商场的水电管网——所有店铺的客流都要从主管道走，管道堵了、漏水了、压力不够了，不是某一家店的问题，而是全局事故。
落到技术层面，核心网络研发日常工作主要围绕几个方向：
- 四层/七层负载均衡的开发和调优，比如自研的负载均衡网关，要处理每秒百万级的并发连接。
- 内核协议栈和网络性能优化，比如调整TCP参数、优化收包路径、引入DPDK/内核旁路技术。
- 数据中心内部的流量调度与路由策略，比如BGP/OSPF的部署、ECMP等价多路径的负载均衡、拥塞控制算法的调优。
- 网络故障的快速定位与容灾切换，比如某条链路抖动、某个机房出口拥塞时，流量怎么平滑迁移。
正因为岗位性质如此，笔试题目才会集中火力考网络底层。它要筛选的不是“会用Linux配置IP”的人，而是能在包级别、在内核协议栈级别、在算法层面理解网络行为的人。所以试卷里大量出现“为什么”“如何计算”“请设计”这类需要推导和综合分析的题，而不是简单的概念填空。
1.2 试卷的整体气质与考点分布
这批第一批笔试题，从题型上看一般分为单选/多选、填空题、简答题、手写代码题和方案设计题。分值分布通常不成比例地偏向TCP/IP协议族和Linux协议栈，加起来能占到60%-70%的权重，剩下的是路由交换基础、数据中心网络常识，以及少量操作系统和代码题。
这里有个很典型的信号：同样是校招笔试题，后端岗位可能会考MySQL索引结构、Redis持久化策略，但这套卷子基本不会出现这些，取而代之的是MSS与MTU的换算、BDP带宽延迟积的计算、SYN Flood防护方案设计、路由表查找算法的实现。这说明岗位对候选人的要求非常聚焦——你可以不熟悉业务开发的框架，但你必须对“一个数据包从网卡到应用层的完整旅程”烂熟于心。
所以复习这套题的正确思路不是去刷力扣，而是建立一张网络底层知识地图，然后把每个知识点都往“出故障时怎么排查”“性能上不去时怎么优化”这两个方向去延伸。
2. 核心细节解析与实操要点
2.1 TCP拥塞控制：一套卷子里的“送分又送命”题
在整份试卷中，TCP相关的题目几乎年年出现，而且往往是拉开差距的地方。最容易丢分的不是概念记忆，而是计算题，尤其是带宽延迟积（BDP）和理想吞吐量的推算。
举一个很有代表性的例题：
一个TCP连接，RTT（往返时延）为40ms，链路带宽为20Mbps，MSS为1460字节，那么理想的拥塞窗口上限是多少？如果接收窗口固定为64KB，实际可达到的最大吞吐量是多少？
计算过程不复杂，关键是分清楚每个变量的含义。先算BDP，即“带宽和延迟的乘积”，它表示在一个RTT时间内链路上能容纳的数据量：
链路带宽折算成字节：20×10^6 bit/s = 2.5×10^6 字节/s（按1字节=8bit算）。
一个RTT内能填充的数据量：2.5×10^6 × 0.04 = 100,000 字节，也就是约100KB。
在TCP里，发送窗口由min(拥塞窗口, 接收窗口)决定。如果链路带宽20Mbps、RTT 40ms，发送窗口至少要100KB才能把链路打满。但现在接收窗口固定为64KB，小于100KB，所以实际吞吐量被接收窗口卡住了：
最大吞吐量 = 窗口大小 / RTT = 65536 × 8 / 0.04 ≈ 13.1Mbps。
也就是说，虽然链路带宽有20Mbps，实际只能跑到13Mbps出头，利用率只有65%左右。很多人在这里直接用链路带宽去除，或者漏掉单位换算，一步错步步错。
这类题真正的考点不是算术，而是你是否理解“TCP吞吐量受制于最短板”这一思想。实际工程里也经常遇到这种问题：带宽明明很高，但TCP窗口设置不合理，导致单连接怎么都跑不满带宽。解法是开启窗口缩放（Window Scale）选项，让窗口字段从16位扩展到更大的范围，这样在高带宽长RTT链路上才能跑出高吞吐。
2.2 负载均衡与哈希：一算就错的经典场景
负载均衡相关题目在核心网络笔试里也是高频考点。因为接入层负载均衡系统就是这些研发工程师自己维护的，所以考题通常很有代入感。
典型的题目是这样：
一个负载均衡集群后面有8台后端服务器，对每个连接按四元组（源IP、源端口、目的IP、目的端口）做哈希，以决定转发到哪台后端。如果其中一台后端要下线运维，使用简单的取模哈希算法，会有多大比例的连接被重新映射到其他后端？
这里的关键在于“无状态哈希”的特性。如果哈希函数是“hash(四元组) mod 8”，那么后端节点数从8变成7后，绝大多数连接算出来的结果都会变化。计算很直观：8台机器时，某连接哈希值可能落到1号节点；变成7台后，哈希值对7取余的结果大概率不是1，而是别的值。粗略估算，大约7/8，也就是87.5%的连接会被重新映射。
这个结果意味着什么？对四层负载均衡来说，连接一旦被重映射到新后端，这台后端上的TCP连接状态没有上下文，客户端发来的包只能被丢弃，用户侧表现为连接中断、需要重连。如果后端承接的是数据库连接池或长连接服务，代价更高。
那么怎么优化？笔试中更进一步的追问通常是：“如果让你重新设计，如何降低节点变更带来的连接重映射比例？”答案是一致性哈希。用一致性哈希把后端节点映射到一个哈希环上，每个连接的路由结果只取决于它在环上顺时针遇到的第一个节点。当只有一台节点下线时，受影响的连接只包括哈希位置落在该节点和其逆时针相邻节点之间的那些，比例大约是1/N，在8台节点的场景下大约是12.5%，远小于87.5%。
不要小看这道题，它在现实中的直接应用就是灰度发布、节点扩容缩容时如何平滑迁移流量。如果笔试答出“用一致性哈希还不够，还要考虑虚拟节点，避免节点分布不均导致热点”，分数会更高。
2.3 Linux收包路径与NAPI：背了答案也容易漏细节
另一类让不少人头疼的是Linux协议栈收包路径相关的题。这类题往往是这样问的：
“请描述一个数据包从网卡到达应用程序socket的完整路径，指出哪些环节可能导致丢包，并说明如何优化。”
你要能画出这样一条流水线：网卡接收到数据包后，通过DMA把包写入内存中的环形缓冲区（ring buffer），然后网卡触发硬中断；硬中断处理程序里调用napi_schedule，把这个设备加入到软中断轮询队列，触发软中断；ksoftirqd内核线程或当前进程上下文执行软中断处理函数，调用网卡驱动的poll回调，从ring buffer里批量取包；取出的包经过GRO（Generic Receive Offload）合并小包后，进入IP协议栈（ip_rcv）、TCP协议栈（tcp_v4_rcv），根据四元组找到对应的socket，放入接收队列；最后应用程序通过recv/read系统调用把数据从内核缓冲区拷贝到用户态缓冲区。
如果只是背出这条路径，只能拿基础分。真正能拉开差距的是你能否说出丢包可能发生在哪些环节、怎么定位。根据我自己的排查经验，常见的丢包点包括：
- 网卡ring buffer满了，新到的包没有可用描述符，被网卡直接丢弃。看ethtool -S的输出，rx_missed或rx_dropped会增加。
- 硬中断或软中断集中在某个CPU核上，导致单核处理不过来。如果开了RSS（Receive Side Scaling）多队列，但没做CPU绑核，中断分布可能依然不均匀。
- 协议栈的backlog队列（netdev_max_backlog）溢出，数据包在进入协议栈前就被丢弃。
- socket接收缓冲区（tcp_rmem）满了，TCP协议栈只能丢包或者触发对端重传。
- 应用程序处理速度跟不上，接收队列被填满。
对应的优化手段也有清晰的层次：首先通过RSS多队列+CPU亲和性把中断分散到多核；其次调大ring buffer和backlog；再往后可以考虑启用busy poll，甚至用DPDK旁路内核直接收包。
这套链路最核心的设计思想是NAPI（New API）：高流量下不采用“一个包一个硬中断”的方式，免得CPU被中断风暴打垮，而是把收包收敛成“一次中断 + 多次轮询拔包”。这个改进背后的动机、能解决的问题、引入的新问题（比如CPU占用率上升）都要理解，简单背结论在面试官追问下撑不过两轮。
3. 实操过程与核心环节实现
3.1 手写路由表查找：从Trie到边界条件
这套试卷的代码题一般不会只考算法题，而是会把算法揉进网络场景里。比较有代表性的一个题目是：
设计一个IPv4最长前缀匹配的路由查找数据结构，并写出查找函数。要求支持变长子网掩码，查询时要返回最长匹配的下一跳。
如果你只写一个for循环挨个匹配掩码，在LeetCode风格里可能没问题，但网络研发的面试官会认为你不理解大规模路由表的查询效能问题。更好的方案是Trie树，Linux内核里的fib_trie就是这么实现的。
我建议至少能写出这样一个Trie节点：
节点里只有两个子节点指针，对应IP位的0和1；节点上可以挂prefix长度和下一跳信息；查询时从根开始逐位往下走，每当走到一个带有路由信息的节点，就更新“最佳匹配项”，最后返回的是最后一个匹配项，而不是最后一个可达节点。这么做天然满足“最长前缀匹配”。
关键边界条件一般有三个：
- 掩码长度为0，也就是默认路由0.0.0.0/0，必须作为兜底返回。
- 插入时如果新路由的网段是已有网段的子网，需要在树上分裂出子节点，不能直接覆盖父节点。
- 当没有匹配到任何非默认路由时，要返回网关地址，通常是默认网关。
写的时候还要注意IP地址的位序问题。IPv4地址用32位无符号整数存储，判断某一位时建议先右移再与1相与，而不是依赖大小端，否则在面试现场容易出低级bug。
如果在笔试中还能答出“Trie树可以用路径压缩优化成Patricia Trie，减少树深度”，或者“路由数很多时可以考虑用商用算法如DPDK的LPM库”，印象分会明显提升。
3.2 一道SYN Flood防护方案题从零推导
方案设计题是整份试卷中最考验综合能力的部分。一个常见的命题：
你们团队维护的入口网关频繁被SYN Flood攻击，半连接队列经常打满，新用户的正常连接无法建立。请在接入层设计一套防护方案，并解释每项措施的作用。
这类题不要一上来就写“加防火墙”。面试官想看的是你能不能沿着TCP握手原理一步步推导出“为什么会被打满”“怎么从不同层面缓解”。
先定位根因。SYN Flood的原理是攻击者只发SYN包，不发ACK完成握手，服务端会为每个SYN分配一个半连接条目进入SYN_RECV状态，等待超时重传。当半连接队列满时，新的SYN会被丢弃，正常用户也连不进来。因此最直接的调整是增大net.ipv4.tcp_max_syn_backlog和net.core.somaxconn，但这只是把桶做大，攻击流量超过容量后依然无效。
第二层是启用SYN Cookie。内核在SYN队列满时会自动开启这个机制，不维护半连接状态，而是通过加密计算生成一个初始序列号（Cookie）放到SYN+ACK里，等客户端回ACK时再校验Cookie，校验通过才建立连接。这样即使队列被打满，真实用户的握手仍然有机会完成。不过要注意SYN Cookie有个副作用：握手期间无法完全协商TCP选项，比如窗口缩放、SACK等可能要等连接建立后重新协商，所以不能长期依赖这个机制。
第三层才是真正的接入层防护：
- 在网关或LB上做源IP限速，比如令牌桶算法，让单源IP的SYN速率被限制在一定范围内。
- 对首次到来的SYN不做处理，先丢弃并记录源IP，如果该源IP随后重新发送SYN才放行，这能过滤掉大量只发一次SYN的僵尸主机。
- 建立源IP信誉库，对已知攻击源IP段直接拒之门外。
方案设计题拿高分的要点，不是堆砌措施，而是每个措施都要能说清“它作用在哪一层、解决什么问题、代价是什么”。比如SYN Cookie解决了队列被打满的问题，但会牺牲TCP选项，所以只能作为兜底；限速解决了单个源IP搞事情的问题，但对分布式DDoS效果有限。能把优缺点讲清楚，才更像一个有实战经验的研发工程师。
3.3 限时答题的时间分配与踩坑预防
复盘这套试卷的实战节奏，我建议这样分配时间：选择填空控制在40分钟内，简答不超过40分钟，手写代码30分钟，方案设计10分钟，最后留10分钟检查重算。
选择题和填空题往往会在单位换算、术语定义上埋坑。比如“带宽20Mbps”和“MSS 1460字节”同时出现时，必须先把Mbps换算成字节再做下一步，否则差8倍。简答题最忌讳写太多废话，比如让你描述三次握手，你只需要把状态变化、关键字段（SYN、ACK、seq）和异常场景写清楚就行，千万不要把RFC全文默写一遍。
手写代码的题目，建议先写出一个能跑通的朴素实现，然后立刻补充边界条件。如果时间不够，用注释表达“这里需要处理默认路由”也能拿到部分分，因为面试官能看出来你懂。
方案设计题的关键是结构化输出，不要一段话从头写到尾。按“问题定位→当前瓶颈→短期缓解→长期架构”四步来写，逻辑清晰了，评分自然高。
4. 常见问题与排查技巧实录
4.1 读题不仔细：MSS与MTU混用
模拟考试时发现一个频率极高的错误，就是把MSS和MTU混为一谈。MTU是IP层的最大报文长度，以太网标准是1500字节；MSS是TCP载荷的上限，在不含IP和TCP头部时是1460字节。如果题目给的是MTU 1500，默认TCP载荷取的是MTU减去20字节IP头再减去20字节TCP头，即1460字节。IPv6环境下头部变成40字节，MSS就要变成1440字节。
如果题目明确说明“TCP选项占用额外字节”，实际MSS可能还要更低，比如常见的时间戳选项会占12字节，部分环境下MSS就只有1448字节。这些细节虽然在具体计算里影响不大，但出现在填空题里就是标准答案，丢一题很可惜。
4.2 计算不统一：BDP公式与单位换算的坑
BDP计算题里最常见的坑有两个。第一是误用RTO（超时重传时间）代替RTT，RTO一般比RTT大得多，算出来BDP会偏大，题目给的一般是RTT，不要画蛇添足。第二是带宽和窗口单位不统一：带宽常以Mbps给，窗口常以KB给，必须先统一成字节或比特再算。
另一个容易出错的是理想吞吐量的估算公式：在丢包率为p、RTT为R的情况下，TCP单连接吞吐量上限约等于MSS / (RTT × sqrt(p))，这是经典Mathis公式。比如一条丢包率1%的链路，MSS 1460字节，RTT 40ms，算出来的吞吐量大约为1460 / (0.04 × 0.1) = 365,000 字节/s，约2.9Mbps。这个结果在无线网络里非常常见，能帮你解释“为什么明明带宽有100Mbps，实际传文件就只有几M”。
工程上还有一个经验系数：实际TCP吞吐量往往只有理论计算值的70%-80%，因为快速重传、重复ACK、拥塞避免的线性增长阶段都有额外开销。面试时如果能主动说出这个修正，会显得你确实做过实测，而不是单纯背公式。
4.3 丢包定位：不是在应用层瞎猜
Linux收包链路的题和日常排查关系非常大。我建议笔试之后一定要动手做一次实验，才能真正把知识串起来。一个很实用的实验组合是：在Linux机器上启动一个HTTP服务，用ab或wrk压测，同时用netstat -s和ethtool -S观察各层计数器的变化。
如果出现吞吐量上不去，优先看这几个指标：
- netstat -s里的SYN_SENT/SYN_RECV数量，判断握手是否正常。
- ethtool -S里的rx_dropped，判断ring buffer是否溢出。
- cat /proc/net/softnet_stat里的dropped列，判断backlog是否溢出。
- ss -m或者netstat -tm，看socket接收队列是否长期非零。
如果只有某个CPU核的软中断占用特别高，其他核很空闲，说明RSS队列和CPU绑核没配好，调整irqbalance或者手动设置smp_affinity就可以改善。如果所有核都忙，但吞吐还是上不去，再考虑应用层是否频繁系统调用，比如每次只读取很少的字节，导致拷贝开销太大。
我强烈建议备考时搭个虚拟机配合tc命令动手验证：给网卡加netem延迟100ms、丢包1%，用iperf3测吞吐，你会很直观地感受到BDP和丢包对性能的压制。这种体验比看十遍书都管用，笔试的简答题里如果你能写出“我用netem模拟过”这类真实经历，说服力完全不同。
5. 笔试之外的延伸：这套题对实际工作的启发
5.1 从“会做题”到“会排查”的复习优先级
如果距离笔试还有一段时间，复习优先级建议按三层递进：
第一优先级是TCP/IP协议族的完整闭环，包括三次握手四次挥手的状态迁移、拥塞控制与流控的区别、滑动窗口与接收窗口的关系、TIME_WAIT和CLOSE_WAIT的异常场景。这部分是笔试核心，也是工作中排查问题的第一现场。
第二优先级是Linux网络协议栈的接收与发送路径，以及对应的内核参数。比如tcp_rmem/tcp_wmem、tcp_max_syn_backlog、netdev_max_backlog、somaxconn、tcp_tw_reuse、tcp_syncookies这些参数的含义与适用场景。不需要记住全部，但至少能说出每个参数在什么症状下需要调节。
第三优先级才是路由协议和数据中心网络。OSPF/BGP的选路原则、ECMP的哈希原理、VXLAN的基本封装格式，做到能解释、能画图就行，通常不会要求你手写协议报文。
5.2 用实验把知识点变成肌肉记忆
只靠刷题应付这套卷子会比较吃力。从我的经验看，最有性价比的备考方式是搭一个最小实验环境，把每个理论知识点变成一次可复现的观测。
准备一台Linux虚拟机，装好tcpdump、ss、iperf3、iproute2工具集，然后做这几个实验：
- 用netem给回环网卡加100ms延迟，启动iperf3，观察单连接吞吐量变化，然后对照BDP公式验证。
- 给网卡加1%丢包，观察TCP流量如何骤降，再对照Mathis公式估算理论值。
- 把接收窗口调小到64KB，观察RTT对吞吐的限制。
- 用ab压一个本地服务制造大量SYN连接，用watch netstat -s观察半连接队列增长，然后再开启tcp_syncookies观察变化。
做完这些实验之后，笔试里大部分计算题和简答题都不是“回忆知识点”，而是“复述你见过的现象”。这种状态下的答题速度和准确率会明显高出一截。
5.3 一道题目的延伸：把知识点织成网
不要孤立地刷题。同样一个“TCP窗口缩放”的题目，它可以延伸到三个方向：
- CUBIC拥塞控制算法为什么在高带宽长链路上比Reno更优？
- 为什么TIME_WAIT需要等待2MSL而不是更短？
- 为什么Ping通但TCP连不上的场景里，要先查防火墙规则而不是查路由？
每道题考完之后，都花几分钟把它和相邻知识点连接起来，形成一张网。这样笔试遇到没见过的综合题时，就不会慌，可以从熟悉的知识点里找到切入角度。
在我个人复盘这套试卷时，最大的感触是：它考的不是知识的广度，而是你是否具备“从现象推导原因、从数据定位问题”的思维习惯。计算机网络和别的领域不太一样，现实中几乎所有故障都有日志、有计数器、有抓包证据。笔试只是把这些证据用题目形式包装了一下，本质上还是在考察候选人有没有“看到现象→提出假设→验证假设”的闭环能力。
如果你能把日常实验中的异常都记录下来，整理成自己的“事故笔记本”，再回来看这套笔试题，会发现大部分题目都脱胎于真实故障场景。带着这种视角去复习，比单纯刷题要事半功倍得多。
