说实话每年校招季都有不少人私信问我类似的问题“核心网络研发工程师的笔试题到底考什么是不是背熟路由交换就能过”我印象最深的是有次帮部门筛简历看到一份候选人把CCIE的认证编号都写在了项目经历里结果笔试连TCP半关闭的状态迁移都没写对。这不是个例——核心网络研发这个岗位笔试筛人的逻辑和大多数人以为的完全不一样。这篇就借着百度2018校招提前批这套题把核心网络研发工程师笔试的出题逻辑、考点边界和答题套路一次讲透。我先把话说在前面这套题不是让你背八股文的。它考的是两件事——第一你对网络协议的理解是不是“用过”而不是“听过”第二给你一个真实出现的网络故障或架构需求你能不能结构化地拆解和表达。尤其提前批的卷子筛人比正式批更狠因为它要在一张卷子里同时看出你的网络功底、编码能力和系统设计思维。所以别指望临时刷题能突击但如果你知道它的出题惯性完全可以在有限时间内调整复习重心把分拿得更稳。1. 这批笔试题的出题逻辑它不考“网工八股”考的是工程直觉1.1 核心网络研发岗位到底在招什么人先别急着看题把招聘JD里的岗位定位搞明白你才知道这张卷子为什么这么出。在百度这类以搜索为核心业务的公司里核心网络研发工程师并不是传统意义上的“网络运维”或“网络管理员”。这个岗位做的事情是支撑搜索引擎的巨型分布式集群、G级甚至T级流量调度、跨地域数据中心互联、CDN节点规划、以及大规模流量下的网络架构演进。这意味着你面对的不是一台路由器或交换机而是成千上万台设备组成的网络 fabric。你对网络的理解不能停留在“能通”这个层面而必须深入到“在多大规模下还能稳定、低成本、可运维地通”。所以笔试题目不会问你“RIP和OSPF有什么区别”“VLAN是几号标准”这类纯记忆题而是会从以下角度出给你一个真实流量模型让你判断瓶颈在哪。给你一个协议报文让你解释它的选路依据。给你一个故障表现让你反推最可能的原因。给你一个网络架构让你指出它的问题并给出改进思路。给你一个算法场景让你在限定资源下给出可行解。1.2 从卷面结构反推公司的人才画像据我当时对同批题目以及后续面试流程的观察这张卷子的结构基本是基础网络理论约35%、协议与转发细节约25%、Linux网络编程与系统约20%、系统设计综合题约20%。这个比例本身就说明问题——它默认你的网络基础是基本功不需要重点考察它真正想拉开的差距在“协议细节的深度理解”和“系统设计的工程素养”这两块。我把当时复盘整理出的考点分布做成了表这里直接分享出来备考的人可以按这个调整优先级考查板块典型知识点大致占比实际考察目的网络基础TCP/IP状态机、滑动窗口、拥塞控制35%确认你“用过”协议而非只“背过”协议路由与转发BGP选路、OSPF区域设计、转发等价类25%确认你是否理解真实网络的决策逻辑编程与操作系统socket编程、epoll模型、内核参数20%确认你能否把协议落地成代码架构与设计高可用负载均衡、故障排查思路20%确认你有没有全局视角和工程判断力注意基础网络理论虽然只占35%但它是后面所有板块的地基。如果TCP状态机都画不完整后面编程题里关于连接超时、半连接队列的题目基本没戏。2. TCP/IP协议栈的考察深度从状态机到拥塞控制笔试是如何挖坑的2.1 三次握手和四次挥手笔试从来不考“画流程图”几乎所有候选人都能画三次握手和四次挥手的示意图所以这部分笔试根本不会让你画图。它真正喜欢考的是握手和挥手过程中那些“边界情况”。举个例子我记得这套卷子里有一道非常典型的题客户端与服务器建立TCP连接后客户端进程突然崩溃。此时服务器端会感知到什么连接会立即关闭吗如果客户端所在的主机随后断电又会发生什么这里面的考点可太密了。客户端进程崩溃操作系统会回收该进程占用的文件描述符主动发送FIN服务器进入CLOSE_WAIT状态调用read会返回0。但如果是主机断电客户端不会发FIN服务器在短时间内是感知不到的只有当它尝试发送数据并等待ACK超时后才会触发重传重传达到一定阈值后进入CLOSE_WAIT不是进入CLOSE状态并复位连接。这个时间跨度可能是几分钟甚至更久。如果你只是背过“四次挥手”没有经历过真实的连接管理这种题很容易写偏。笔试想看到的答案是你能区分“进程退出”和“主机故障”在网络行为上的不同表现并理解TCP状态机的状态迁移不是靠教科书那根线一步一步走的而是由事件驱动的。2.2 滑动窗口与拥塞控制考题如何把课本知识变成工程问题拥塞控制是另一个高频出题点。但同样它不考你“慢启动是1、2、4、8”而是会给出一个具体的网络场景一条10ms RTT的链路上接收窗口是64KB带宽是10Mbps问你在这个链路上传输一个1MB的文件大概需要多少个RTT瓶颈是带宽还是窗口这类题考的是你能不能算清楚带宽时延积和缓冲区大小的关系本质上是在模拟真实调优场景。按我后来的实际经验这种计算题的底层逻辑很简单带宽时延积就是链路上“在途数据”的上限10ms RTT、10Mbps时带宽时延积为12.5KB而此时接收窗口是64KB远大于链路本身能容纳的在途数据说明瓶颈在带宽而非窗口。但很多人一看到64KB就直觉认为窗口够大就完事了完全没算链路能不能填满这个窗口这就是出题人想筛掉的思维盲区。提示备考这部分时不要只盯概念定义多问自己一个“如果是在真实链路上这个参数会导致什么现象”。TCP细节题几乎都能用这个思路解。3. 路由协议与转发平面笔试中真正拉开差距的硬骨头3.1 BGP选路背优先级列表是没用的得会算网络基础部分有个很残酷的现实大部分候选人都能背出BGP选路的前几条优先级比如“weight最高优先、local-preference最高优先、本地起源优先于IBGP/EBGP……”但笔试的题目往往是反过来的——它给你一个具体的拓扑和路由信息让你判断最终哪条路由被选中并说明为什么。我记得同批考卷里有一道设计得很巧妙的题一个AS内有两条去往同一前缀的路径一条是EBGP学到的附带community属性并做了local-preference调高另一条是从IBGP学到的但MED值更低。问你最终优选哪条为什么。这题坑就在这儿很多人看到MED低就直接选了IBGP路径却忽略了EBGP路由可以通过local-preference调高优先级而BGP选路是在前几条优先级都相同的情况下才会比较MED。所以必须把决策链走完先比local-preference再比AS路径长度最后才轮到MED。这道题给我们的备考启示是BGP的选路原则不是背列表而是学会把它当成一个逐级比较的“决策流水线”。你只有把这个流水线的顺序和每个比较器的条件都刻在脑子里才能在笔试那种高压场景下不出错。3.2 转发平面的核心哈希、等价路径与一致性路由协议之外大厂笔试特别喜欢考转发平面的设计逻辑。原因很简单——在搜索引擎这种超大规模流量场景下单条路由能不能通根本不重要重要的是流量在成千上万条等价链路上是否均衡、是否稳定、是否在设备故障时快速收敛。因此卷子里经常出现这样的开放题假设你有一台负载均衡器后接4台服务器你希望用一致性哈希的方式把请求分散到后端请问当其中一台服务器宕机后哪些请求会受影响你有没有办法把影响降到最低这题不是考哈希函数怎么实现而是考“一致性哈希”这个技术在真实转发场景下减少rehash影响的设计思路。虚拟节点、哈希环、顺时针查找这些概念你得能说清楚并且能把它和“设备故障导致的大量会话重映射”这件事联系起来。我在这类题上吃过亏。当时我笔试时洋洋洒洒写了哈希的原理和实现但没有提到虚拟节点对均衡性的改进也没说明故障时只影响一条弧上的请求。后来面试官反馈说原理都对但没表现出“设计者”的视角。所以这里提醒后来者转发平面相关题目答题时一定要往“设计取舍”上靠而不是背书。3.3 VXLAN/Overlay网络出现的频率越来越高2018年那会儿正是VXLAN和Overlay网络在数据中心火起来的时候。所以这套题里出现VXLAN相关题目一点也不意外。考察的点主要是VXLAN为什么用UDP封装而不是TCP、VTEP的作用、以及VXLAN和VLAN在规模上的差异。备考时可以记一个清晰的类比VLAN像是在一栋楼里分房间最多只能分4094个而且靠广播在二层传播租户一多就乱VXLAN则是在城市里建隧道隧道里面的地址可以自行规划只要隧道两端认识就行可以搞出上千万个隔离网络。这个类比能帮你快速理解VXLAN为什么在云数据中心里是绝对主流也顺便理解了为什么笔试出题人会默认你应该知道这些。这部分的分拿起来相对容易但前提是你真的理解Overlay的概念而不是只看过名词。4. Linux网络编程与系统调优编码能力是网工人的隐形壁垒4.1 socket编程题从代码填空到“找出这段代码的bug”核心网络研发的日常工作离不开网络编程所以笔试考代码几乎是必然的。不过它不考LeetCode那种纯算法而是考socket编程里常见的坑。举个例子考卷里出现过一道bug寻找题给了一段简化的TCP服务端代码代码里设置了几处很隐蔽的问题int listen_fd socket(AF_INET, SOCK_STREAM, 0); setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, opt, sizeof(opt)); bind(listen_fd, (struct sockaddr*)addr, sizeof(addr)); listen(listen_fd, 5); while (1) { int conn_fd accept(listen_fd, (struct sockaddr*)client_addr, client_len); char buf[1024]; int n read(conn_fd, buf, sizeof(buf)); write(conn_fd, hello, 5); close(conn_fd); }这段代码问题其实不少没有处理accept返回-1的情况、没有处理read/ write的返回值、listen的backlog设置过小导致高并发丢连接、单线程顺序处理导致一个客户端不发送数据就会阻塞所有后续连接。笔试的考点不是你能不能跑通这段代码而是你能不能从“代码审查”的角度定位这些问题。如果你平时写网络程序只关注“能通”这些细节很可能注意不到。提示备考网络编程题不要光看《Unix网络编程》前几章就以为够了。把书中关于“僵死进程”“EINTR中断”“半关闭”的章节都当作重点因为笔试命题人尤其喜欢把这几类边界问题编进代码片段。4.2 epoll模型的考察从使用到原理epoll几乎是所有大厂网络编程必考的点没有之一。但2018这套题对epoll的考察已经不是“epoll和select的区别”这种入门级了它直接给了一段基于epoll的服务器代码然后问你当某个连接被对端异常断开时如何检测如果对端是半开连接只断了一方向的链路你的程序会怎样这题背后的知识点链很长epoll的EPOLLIN、EPOLLOUT、EPOLLERR、EPOLLRDHUP事件TCP的连接状态以及用户态缓冲区与TCP接收缓冲区的关系。半开连接场景下对端不可达时如果没有心跳机制你的epoll可能一直不会触发任何事件连接就这么僵死在那里。这背后是TCP协议本身不具备应用层“活性探测”能力。你答这题时如果能主动补充心跳机制与超时清理就能让面试官看到你真实的生产经验。我当时答得中规中矩但后来复盘得到的最大教训是epoll不是一套API而是一种事件驱动模型。你对它的理解停留在“水平触发和边沿触发有啥区别”是不够的要能说清楚在什么场景用LT、什么场景用ET以及为什么ET模式必须配合非阻塞IO和循环读取否则会漏掉数据。这些是生产环境里几乎一定会遇到的问题出题人也心知肚明。4.3 内核网络参数调节不仅仅是sysctl.conf大厂网络研发不可避免要做内核参数调优所以卷子里也有这类题。常考的参数包括net.core.somaxconn、net.ipv4.tcp_tw_reuse、net.ipv4.tcp_max_syn_backlog、net.ipv4.ip_local_port_range等。它不会问“你知道每个参数的作用吗”而是会给一个具体场景假设你维护的服务器上大量连接处于TIME_WAIT状态导致新连接建立变慢你会从哪些参数入手有哪些风险这题有意思的地方在于陷阱。很多人拿到题就写“开启tcp_tw_reuse、tcp_tw_recycle”但实际上tcp_tw_reuse只能作用于客户端连接且要求时间戳选项开启tcp_tw_recycle在内核新版中因为NAT场景的严重问题已经被移除或禁用。笔试出这道题时如果候选人能指出recycle的坑基本就能看出他是否真正管理过生产环境。所以备考时不要只看参数解释还要看它适用于什么场景、会带来什么反作用。5. 系统设计题与故障排查题笔试中的“大题”怎么破5.1 高可用负载均衡架构设计答题顺序就是你的工程思路到了这部分卷子就从知识考察转向能力考察。我记得这套题里有一道很典型的系统设计题设计一个支撑10万QPS的TCP负载均衡系统要求高可用、可扩展、便于运维。这题不要求写出完整代码但要求给出架构图、关键组件和故障切换策略。我当时的答题框架复盘后觉得比较有效分享给需要的人流量入口层DNS轮询或Anycast将流量引入多个接入点。负载均衡层LVS四层DR模式 Nginx七层负载二者结合LVS扛流量Nginx做精细化路由。高可用方案LVS主备用Keepalived做VRRP后端服务器用健康检查实现自动摘除。会话保持通过一致性哈希将同一源IP或session固定到某一后端减少重复登录。容量规划先算单机带宽和并发连接上限再倒推需要多少台机器别拍脑袋。要注意设计题不是考你方案有多炫而是考你思路是否完整、能否自洽。从接入、负载均衡、健康检查、会话保持到容量规划每一步都要有取舍说明。你在“为什么用四层而不用七层”这类问题上给出的理由比方案本身更能让阅卷人看出你的能力。5.2 故障排查题用“现象-假设-验证”链路答题大型网络研发岗绕不开故障排查笔试的最后一类常考题型就长这样一个在线服务最近经常出现请求超时从客户端看是偶发的从服务器端看CPU和内存都不高但网络重传率上升。请列出你排查此问题的思路。这类题没有唯一标准答案但阅卷人有一份比较确定的“考点清单”包括MtU问题、网卡软中断分布不均、交换机端口丢包、应用程序锁竞争导致的accept队列堆积、vCPU抢占、甚至网卡固件bug。你的答案覆盖的假设越多且顺序越合理分就越高。我的建议是按OSI模型自底向上排查物理层看网卡状态有无丢包统计链路层看交换机端口错误计数网络层看是否有IP分片和重传传输层看TCP重传和乱序指标应用层看日志和调用链。把这些步骤写得有条理比直接猜一个“可能是MTU问题”值钱得多。另外网络排查题一定要强调“数据驱动”比如用dmesg查Ring Buffer丢包、用ethtool -S看网卡统计、用netstat -s看协议栈统计。你提到这些具体命令才会显得你真的调过线而不是只会写理论。6. 作为过来人的备考建议与答题教训6.1 复习优先级怎么排这套卷子的考点分布其实已经很清晰地告诉你复习重心了。网络基础部分不要花太多时间背概念把TCP状态机和拥塞控制吃透路由部分重点放在BGP选路逻辑和转发平面的设计思想上Linux网络编程部分用真实代码去验证概念比如亲手写一个非阻塞echo服务器再把故障场景一个一个灌进去观察现象系统设计部分建议找几篇大厂技术博客的负载均衡和网关架构文章拆解它们的设计取舍。坦白讲如果你只有一周时间突击必须优先保基础网络和网络编程代码题这两个板块分数最扎实。路由协议细节和系统设计题拉开差距需要长期积累但基础部分只要肯下功夫一周内完全可以捡起来。6.2 几个让我印象深刻的答题细节笔试答题的“表达方式”本身也能拉开分数。同样一个知识点有些人的答案一眼看去就训练有素有些人的答案则全是零散要点。批改笔试的人其实时间很紧他第一眼扫的就是你有没有结构。我总结了几条我后来改卷子时觉得加分的答题习惯分点作答每个要点先用一句话概括结论再补充解释。不要一大段话里藏三个结论。能画图就画图拓扑图、状态图、时序图都可以。阅卷人对画出正确拓扑的答案天然有好感。原理题主动补充边界条件和适用场景比如回答VXLAN时顺带提一下控制平面BGP EVPN的演进说明你了解相关生态而不是孤立地记了一个协议。代码题注意防御性编程即使题目没要求在读写系统调用时加上对返回值异常的讨论也会让阅卷人看出你有工程经验。不确定的题也不要空着写清假设和思路远胜于空白。设计类题目更是如此它的得分点是推理过程不是最终结论。6.3 最后分享一个我踩过的坑很多人以为提前批的题会比正式批简单其实恰恰相反。提前批的卷子筛选意图更重因为它要快速确定谁能进入面试出题会更“跳”更不按套路来。我当时就是因为大意在基础概念上花的时间太多结果后面的协议细节题和程序设计题时间不够。复盘时最大的教训就是别把时间耗在“已掌握内容的复读”上要把时间留给那些看一眼觉得眼熟、但说不出所以然的薄弱点。如果你现在正在准备这类笔试我建议你把TCP状态机、BGP选路顺序、epoll模型这几个知识点当成“锚点”先用一套模拟卷检验自己能不能讲清楚再针对性补弱。因为这几个点在这类卷子里出现的概率极高而且一旦会了就是稳定拿分。剩下的就靠你对网络本身是否保持敏感了——核心网络研发终究是个工程岗笔试只是第一道门面笔试而准备的每一份深度理解最后都会在真实网络故障排查时连本带利还给你。