每年秋招季网络方向的同学在笔试这一关挂掉的比例往往比想象中高得多。核心网络研发工程师这个岗位笔试不会只让你填TCP的三次握手状态也不会让你默写socket API——真正拉开差距的是那些把协议、内核、分布式糅在一起出的场景题。我整理了一下百度2019校招核心网络研发工程师笔试题第三批相关的讨论和考生回忆把这些内容涉及的考察逻辑重新梳理了一遍。这篇文章不是给你背答案而是把这类笔试的命题方式拆开帮准备校招或跳槽的朋友建立一套更稳的答题框架。很多人的误区是把“网络研发”等同于“计算机网络”这门课。实际上核心网络研发工程师在笔试题里展现的定位是能搞定数据中心网络、网络性能调优、网络故障排查、网络组件研发的人。你既要懂协议也要懂Linux内核还得明白分布式系统里网络扮演的角色。下面我按这批题目体现出来的考察方向逐个讲讲。1. 这批笔试在筛选什么核心网络研发岗的考点地图1.1 一张卷子覆盖的知识域别指望一张卷子只考一个方向。核心网络研发工程师的笔试通常是想快速判断你是否有“全链路视野”。我从多方面整理到的信息来看考察范围大致可以分为下面几个板块命题形式各有不同。板块高频知识点常见命题方式网络基础TCP/UDP、HTTP/HTTPS、DNS、IP路由选择题、状态机补全、场景判断网络编程socket生命周期、IO多路复用、并发模型读代码找错、设计网络通信模块Linux网络栈收包流程、中断、零拷贝、内核参数调优简答题、性能分析题路由与交换OSPF、BGP、VLAN、SDN路由选路题、协议原理解释数据中心网络负载均衡、容器网络、CDN、高可用架构方案设计题、故障排查题网络与分布式交叉一致性协议、分布式事务与网络时序、RPC综合场景题、角色扮演式提问从这个表能看出来笔试范围其实是“大网络”概念。你只精通TCP协议不理解epoll或者只写过业务代码不懂内核收包路径都可能在某些题目上卡壳。官方不会公布标准答案但考生回忆里的题目分布基本符合这个结构。1.2 为什么“背八股”选手容易在这里栽跟头我见过太多准备面试的人把三次握手、四次挥手倒背如流但一遇到“这台机器访问那台机器不通你怎么排查”这种题目就乱了。原因很简单笔试要的不是单个知识点而是你把这些知识点串成一条排查链或设计链的能力。举个例子“服务器A访问服务器B超时”这种经典题有人上来就说“检查防火墙”。这个回答太跳了阅卷人看不出你的排查逻辑。正常思路应该从物理层、链路层、网络层、传输层、应用层逐层递进——先确认网线/ARP再ping网关、ping对端IP、检查路由表然后telnet端口确认TCP可达性最后才看应用层日志。这种过程不需要你背很多东西但需要你脑子里有一棵完整的协议树。笔试里经常用这种题把你的思考过程压缩到纸面上你平时没有形成自己的排查框架现场很难写得有条理。另外这批题目里还有不少“为什么”层面的深入追问。比如三次握手为什么不是两次TIME_WAIT为什么需要存在SYN队列溢出会发生什么。这些都是在考察你是否理解设计背后的权衡而不只是记住状态名。背八股能让你答出“是什么”但只有真正理解才能在卷面上写出“为什么”。2. TCP/IP的追问方式不止状态机还有计算题和调优题2.1 三次握手与四次挥手背后的“为什么”网络基础题永远不会缺席但命题角度越来越刁。关于三次握手最容易被追问的经典问题包括为什么需要三次握手两次行不行这里需要想清楚握手的目的不只是同步序列号还要防止过期的连接请求突然到达对端。两次握手无法让服务端确认自己发出的SYN-ACK是否被客户端真正收到如果旧包在网络中滞留可能让服务端建立一条脏连接。SYN洪泛是另一个高频考点。大量伪造源IP的SYN报文打过来服务端的半连接队列会被占满正常客户端无法完成握手。解决方案有SYN Cookie机制——在SYN-ACK里编码部分连接信息不占用内存队列或者调整tcp_max_syn_backlog、tcp_syncookies等内核参数。笔试不会让你写内核代码但会问“半连接队列与全连接队列溢出分别有什么表现如何排查”。我建议你把netstat -s里看到的SYNs to LISTEN sockets dropped这类统计项记下来答题时提到这些信息会显得你真有实战感觉。四次挥手也不简单重点在TIME_WAIT状态。为什么主动关闭方要停留2MSL最大报文段生命周期一是保证最后一个ACK能到达对端万一丢了可以重传二是让旧连接的报文在网络中完全消失避免干扰新的同端口连接。高并发场景下大量TIME_WAIT连接占用本地端口就会影响新连接的建立。很多人遇到这类问题第一反应是“调短TIME_WAIT”这属于治标不治本。更稳的方向是用连接池复用连接、开启tcp_tw_reuse内核层面允许复用处于TIME_WAIT的端口或者调整内核参数。笔试时如果出这道题不要只写“改参数”要把为什么会出现大量TIME_WAIT的上下文说清楚。2.2 拥塞控制与带宽时延积一道典型计算题的拆解计算题在这类笔试里很常见也是容易拉开分差的地方。最典型的是求一个TCP连接的理论吞吐上限。公式很简单吞吐上限 ≈ 拥塞窗口大小 / 往返时延RTT更专业的说法是带宽时延积BDPBandwidth-Delay Product。假设RTT是10msTCP窗口是64KB那不管链路带宽是1Gbps还是10Gbps单连接的极限吞吐都只有64KB / 10ms 65536 * 8 / 0.01 52.4Mbps这个数字远低于1Gbps。所以高带宽、长距离的网络环境里必须开启窗口缩放Window Scaling选项才能让窗口超过64KB。有些题目会绕个弯告诉你RTT和带宽问你单连接传一个文件至少需要几个RTT或者需要多大的接收窗口才能跑满带宽。这时候就用BDP公式去算不要凭感觉。拥塞控制算法本身也常考。慢启动、拥塞避免、快重传、快恢复四个阶段要能画出窗口随时间的变化曲线。这里有个容易混淆的点快重传是接收端收到乱序报文时立即回复重复ACK触发发送端重传快恢复是发送端收到3个重复ACK后认为网络还没彻底拥塞把拥塞窗口减半而不是回到1。题目如果给你一组丢包率、RTT的值让你估算某个拥塞控制算法的吞吐你至少能写出关系表达式而不是干瞪眼。我自己的感受是网络研发岗位的笔试对拥塞控制的考察不只是让你背诵算法名而是希望你理解它对实际业务的含义。比如为什么在线视频会卡顿为什么长肥网络高带宽高延迟里传统TCP表现差这就引出了BBR之类的算法。答题时能写出“TCP友好性”“带宽探测”这些词说明你是真的在用它而不是背了名词。2.3 粘包问题笔试里容易被忽略的实战考点很多协议理论很强的同学会在“TCP粘包”这种题目上翻车。原因是课本里不会讲只有写过网络程序的人才会遇到。TCP是字节流协议它不保证应用层消息的边界。发送方两次send的报文接收方可能一次recv就全收到反之一次send的报文也可能被拆成多次recv。这就是粘包和拆包。笔试常见的考法给出一个网络通信模块让你分析为什么收到的数据对不上或者让你设计一个协议解决消息边界。推荐方案有三个方向一是固定消息长度简单但有浪费二是分隔符例如HTTP的换行符风格但正文里也可能出现相同字符需要转义或长度兜底三是长度字段消息体这也是最主流、最稳妥的做法。我建议你在答题时画出消息帧格式[Header: 4字节消息总长度] [Payload: 长度字段指定的消息体]然后解释接收方处理步骤先解析4字节长度再循环读取直到收满整个Payload之后继续读下一条消息。如果笔试给了代码片段大概率会埋“只调用一次recv就当作完整包处理”的坑这时候补上“按长度字段进行拆包缓存”就是关键得分点。3. 网络编程与Linux内核从socket到epoll的交叉命题3.1 socket生命周期与全连接队列溢出网络研发岗位的笔试题里很少让你手写完整socket服务器但会给你一段代码让你挑错。常见考点包括socket()的返回值有没有判断listen()的第二个参数backlog是什么含义accept()返回的fd和监听fd的区别close()之后连接还在不在。这里有个容易忽视的知识点backlog不是简单意义上的“最大连接数”。时代不同内核实现也不一样。在Linux中backlog主要影响全连接队列的长度。如果Nginx或某个服务报“connection refused”或者客户端connect超时你不只要看防火墙还要看应用是否经常调用accept取出连接以及全连接队列是否溢出。排查命令很实用ss -lnt输出里Send-Q那一列在监听socket上就代表全连接队列的最大长度Recv-Q是当前已建立但未被accept的连接数。如果Recv-Q长期接近Send-Q说明应用处理accept的速度跟不上连接建立速度。类似的半连接队列溢出可以看netstat -s里的SYNs to LISTEN sockets dropped。笔试时能写出这种排查路径比空泛地喊“查内核参数”有用得多。3.2 select/poll/epoll的底层差异与工作模式如果说socket是网络编程的骨架IO多路复用就是灵魂。字节笔试里大概率会出现“select、poll、epoll有什么区别”或“为什么高并发服务器都用epoll”这类题。只答“epoll用事件驱动效率高”远远不够你要讲清楚底层机制。select和poll每次调用都要把全部fd集合从用户态拷贝到内核态内核还要线性扫描所有fd复杂度是O(n)。而且select有FD_SETSIZE上限默认1024poll虽然去掉上限但规模大时性能依然不好。epoll解决的核心问题有两个一是用红黑树维护被监控的fd不再每次全量拷贝二是通过就绪链表只返回真正发生事件的那些fd让应用层不用遍历所有fd。epoll还有一个高频追问点水平触发Level Trigger和边缘触发Edge Trigger的区别。水平触发是只要有数据没读完每次epoll_wait都通知边缘触发是只有状态发生变化从无到有才通知一次。边缘触发效率高但如果你没有一次性把数据读完会漏掉后续事件必须搭配非阻塞IO循环读取。笔试如果问你“边缘触发下处理EPOLLIN要注意什么”你要答到“循环read直到EAGAIN”否则就会出现坑。再往上延伸一点就是Reactor模型。很多方案设计题里都要用把IO事件分发到对应处理器主线程只负责监听工作线程处理业务。这个模型的理解能直接帮你在“设计一个高并发网络服务”的题目里拿到加分项。3.3 数据通路视角从网卡中断到用户态零拷贝真正能区分“只懂应用开发”和“懂网络研发”的是看你对整条数据通路有没有概念。网络包从网卡进来要经历硬中断、NAPI轮询、分配sk_buff、经过内核协议栈、唤醒等待数据的进程最后拷贝到用户态缓冲区。每一层都有性能开销也都有对应的优化手段。笔试常见的问法是如何提高大流量下的网络处理性能这个问题最好的切入点不是上来就说DPDK而是先写常规优化开启多队列网卡RSS让不同队列由不同CPU处理调整中断合并参数用epoll替代多线程阻塞IO用sendfile或mmap减少用户态与内核态之间的数据拷贝。这里零拷贝是重点。传统readwrite在传递文件时会发生多次内存拷贝磁盘到内核缓冲区、内核缓冲区到用户态缓冲区、用户态缓冲区到socket缓冲区、socket缓冲区到网卡。sendfile可以让数据在内核态内部完成传输减少两次用户态拷贝。像Nginx处理静态文件就是走这个路子。答题时把“DMA拷贝”“CPU拷贝”分开说会显得你很专业。至于DPDK这类用户态协议栈方案笔试阶段点到即可。能在简答题里写出“通过内核旁路、轮询模式减少中断和上下文切换”这样的方向已经足够证明你有广度。具体细节面试官更可能在后续环节深挖。4. 走向数据中心与云网络路由协议、负载均衡、容器网络4.1 BGP和OSPF路由题往往穿了一层“故障”外衣核心网络研发工程师的字面意思决定了路由交换知识在笔试里占有一定比例。但纯考OSPF区域、LSA类型的题已经比较少了更多是把路由协议放在故障场景里考。比如某两个机房之间通过专线互联跑BGP业务偶尔出现丢包你会怎么排查这时候你要想到BGP的KeepAlive报文、路由收敛、AS_PATH变化、MED属性、ECMP负载不均等问题。如果你想快速应付笔试我建议重点理解几个路由概念OSPF基于链路状态算法收敛快适合数据中心内部网络区域划分Area 0骨干区域能限制LSA泛洪范围。BGP是路径矢量协议核心是AS间路由依靠各种路径属性做选路决策。LOCAL_PREF越高越优先AS_PATH越短越优先MED值越小越优先。路由优先级administrative distance在不同厂商设备上定义不同但整体思路是直连路由、静态路由、动态路由的优先级别要分清楚。实际笔试出现的选择题可能是“一个路由器同时从OSPF和静态路由学到同一目的网段选哪条”答案是“看AD值通常静态路由优先于OSPF除非你配置了特殊策略”。简答题可能问你“BGP为什么比OSPF更适合跨AS传播路由”你需要答到“BGP支持丰富的策略控制可以在AS边界做路由过滤和流量调优OSPF作为IGP更侧重于域内快速收敛”。4.2 四层与七层接入网关高并发架构的必然之问方案设计题里很少让你直接设计BGP网络但经常出现“设计一个高可用的接入网关”或“对比四层和七层负载均衡的适用场景”。这类题目是在考察你对分布式系统入口网络的理解。四层负载均衡工作传输层基于IP和端口转发典型的如LVS它的核心是转发性能高不解析应用层协议。数据进来后用DNAT或隧道方式转发到后端RS。因为处理逻辑简单可以扛很高的并发。但要处理HTTP的URL路由、Cookie会话保持、Header改写它就无能为力了。七层负载均衡工作应用层像Nginx就是典型。它能读懂HTTP协议可以做更细致的路由策略但代价是每一条连接都要经过用户态协议栈解析CPU开销大。针对CPU密集问题通常会采用多进程/多worker模型利用epoll处理并发事件。笔试里如果让你“比较四层与七层”不要只写概念要落到架构设计前端放一个LVS做流量入口中间放Nginx做七层路由和限流后端接服务集群。为什么这么分层因为每一层只做自己擅长的事既保证入口吞吐又保证路由灵活。回答时带上“每层故障可以独立降级”的思想阅卷人会认为你有工程经验。4.3 容器网络与SDN校招题里的新常客最近几年云原生相关技术在校招笔试里出现得越来越频繁。容器网络不再只是加分项已经逐渐变成必备知识。关于容器网络你需要理解几个基础模型。最常见的模式是bridge网络容器通过veth pair连到docker0或CNI网桥网桥再通过NAT/路由与外部通信。另一个常见模式是host网络容器直接共享宿主机的网络命名空间性能好但隔离性弱。再复杂一点就是overlay网络例如VXLAN它把二层报文封装在UDP里在三层网络之上构建虚拟二层网络这让跨主机的容器通信不用依赖底层物理网络改动。笔试如果考“PodA和PodB在不同宿主机上如何通信”正确答案往往离不开VXLAN隧道或直接三层路由。你需要说清楚容器网络接口记录在CNI数据库里节点发现方式、ARP代理、VTEP的映射关系这些是答案的关键词。即便记不全也要能画出“物理网络在上VXLAN隧道在内层”的封装逻辑。SDN相关题目一般不会太深主要考思路控制面与数据面分离集中式控制器统一管理网络视图交换机按流表转发。这背后的价值是让网络变得可编程。答题时把SDN和overlay联系起来说明为什么数据中心需要network virtualization内容会更完整。5. 实战作答故障排查题与方案设计题的表达框架5.1 一台机器ping不通另一台你按什么顺序查故障排查题是核心网络研发岗位笔试的“保命题”几乎不可能不考。回答这类题目时最重要的不是给出“正确答案”而是展示排查的逻辑顺序。千万别一上来就猜原因。我推荐按下面的链路作答先确认问题边界是单向不通还是双向不通是同一网段还是跨网段是ping IP不通还是ping域名不通不同边界对应的排查方向完全不同。从本机回环开始先ping 127.0.0.1确认协议栈正常再ping本机IP确认网卡和IP配置正常。看ARP和链路层同网段通信查ARP表跨网段先查网关ARP是否正常。看路由在源主机查路由表确认到对端网段的下一跳在路由器/交换机上查路由表是否学习到目标网段。看对端确认对端主机防火墙、iptables规则、安全组是否放行了ICMP确认对端服务是否监听。抓包定位沿着数据包路径抓包看ARP请求、ICMP请求、ICMP回复在哪一跳消失了。笔试卷面上你没有设备可以操作但完全可以把这个步骤写成清晰的编号清单。阅卷人一看就知道你有实战排查能力。如果题目里点名“跨机房的机器A访问机器B丢包”你还要加一步查看链路质量丢包率、延迟抖动考虑是否存在路由环路、MTU分片、瓶颈带宽耗尽等问题。5.2 高并发网关方案设计如何把“大而全”拆成“清晰分点”方案设计题通常不是让你写完整代码而是让你表达设计思路。比如“请设计一个支持百万并发连接的接入网关你会考虑哪些方面”很多人的回答是“用epoll、加机器、做集群”——三个词说完就没了。这样拿不到好分数因为阅卷人想看的是你的拆解能力。我会按下面几个维度去展开接入层客户端先连谁的IP用DNS轮询还是VIPKeepalived是否需要全局负载均衡连接管理单机如何支撑百万连接epoll是必然选择但还要考虑内存占用一条TCP连接约消耗几KB内核内存百万连接要预留多少内存。事件处理用多线程还是单线程Reactor各有什么取舍。协议处理网关要不要解析HTTP要不要支持WebSocket是否需要TLS终止解析协议会引入CPU开销必须评估是否能横向扩展。状态管理网关是否保存用户会话如果保存重启后是否丢失通常做法是把session缓存到Redis或者用JWT无状态设计。超时与重试上游服务慢时网关要设置合理的read/write超时重试机制要考虑幂等性否则用户可能被重复扣款。限流与降级接入网关一定要有限流能力防止某个突发流量拖垮后端。令牌桶算法怎么用拒绝策略是丢弃还是排队。可观测性网关是流量的咽喉必须有完善的监控和日志。连接数、QPS、RT、错误率、协议错误分布这些指标都要在方案里提到。如果你能按这种结构作答即使某些细节了解不深整体逻辑也是完整的。方案设计题最怕“只给一堆名词”不怕“层次分明但深度略浅”。5.3 时间分配与答题顺序先保计算题还是先保场景题最后聊聊考场策略。这类笔试题量大知识点跨度大很多人做不完。先做什么后做什么直接影响你最终分数。从我的角度看建议顺序是先扫一遍整张卷子标记出选择题和判断题这些题通常能在短时间内拿到分先做掉保底。再做计算题。像TCP吞吐、子网划分、广播域计算这类题答案唯一算出来就是得分点。计算题容易陷入细节给自己设一个时间上限比如10分钟算不出来就跳过。接着做简答题和场景题。这些题目弹性大只要框架正确、关键词到位阅卷人多少会给分。优先做那些你能画出完整逻辑链的题目。方案设计题留在最后。它不是一蹴而就的需要构思。但即便时间不够也要写出骨架结构哪怕只是“接入层-逻辑层-存储层”几个顶部条目也比交白卷强。还有一个小技巧不要在某道题上死磕“标准答案”。很多场景题根本没有唯一答案阅卷人看的是分析过程。你只要按“边界确认-逐层排查-定位根因-解决思路-验证方案”的顺序写通常都能拿大部分分数。最怕的是你写“可能是网络问题”这种完全无法操作的话那不叫回答叫放弃。我在整理这批笔试相关内容时最大的体会是真正帮助你通过笔试的不是考前突击背下的协议状态表而是平时遇到一个网络问题时的思考路径。哪怕你现在还没有机会处理大型分布式系统的网络故障也可以从自己本机的抓包、虚拟机的网卡配置、容器间的通信问题开始练起。建立一套自己的排查框架比刷十套“真题”都管用。等你在笔试现场看到那些场景题会发现它们不过是在问同一件事你对一条数据从一端到另一端走过的路心里到底有没有一幅完整的图。