2018年的百度校招核心网络研发岗笔试题放到今天来看依然是一份很值得反复咀嚼的考察样本。很多人拿到这类题目第一反应是去背协议、刷题库但真正做过一遍并且通过面试的人会明白这份卷子表面上在考TCP/IP和操作系统实际上在筛两类东西一是你对网络底层原理的理解是不是够硬二是在分布式系统规模面前你有没有工程判断力。我把这套题第二批的考点拆开揉碎逐个知识点聊一遍包括题目背后到底在问什么、解题思路是怎么一步步推出来的、以及我在实际工作中对应这些知识点的体会。文章会比较长但每一段都是干货适合正在准备大厂校招、尤其是网络方向和后端方向的同学慢慢读。1. 先说清楚核心网络研发工程师的笔试到底在筛什么人1.1 这个岗位的工作边界决定了考题方向在聊题目之前必须先把核心网络研发这六个字拆开看。百度当时的网络研发体系覆盖的范围极广从数据中心内部的接入网络到跨地域的骨干网调度再到承载搜索、广告、流量接入的网关系统全部归网络团队管。这决定了笔试题不会只考大学课本里的计算机网络而是会往大规模和高性能两个方向深挖。所谓大规模就是一台服务器撑不住需要考虑集群、负载均衡、分布式路由。所谓高性能就是网卡、内核、用户态之间的每一跳都可能成为瓶颈需要抠细节。所以你看到的题目里既有经典的TCP状态机问题也有epoll、内核协议栈相关的内容——这不是超纲而是岗位的真实需求。1.2 2018年这批题的总体难度画像第二批题给我的整体感觉是基础题占五成进阶题占三成拉开差距的题占两成。基础题覆盖TCP握手挥手、HTTP报文、DNS解析流程这些必须拿分的点进阶题集中在拥塞控制、路由协议、多路复用模型上真正能区分候选人水平的是最后那几道需要结合场景分析的题目比如高并发短连接如何优化、如何设计一套负载均衡策略。没有一句死记硬背能直接抄上去的答案全都要靠理解推导。很多同学复习时喜欢抱着RFC啃甚至把TCP首部每个字节的含义都背下来。我不否认这些有基础价值但笔试和面试考察的是遇到问题能不能找到关键变量而不是记没记住第几个字节叫什么。后面我会结合具体题目讲清楚这个区别。1.3 复习时最容易犯的两个错误第一个错误是只刷题不看原理。网上一搜百度2018校招笔试题能搜出一堆回忆版但大部分只有答案没有推导过程。你背下了快重传是3个重复ACK触发却不知道为什么不是2个也不是4个那题目稍微一变就废了。第二个错误是忽略编码题。网络方向的同学普遍认为笔试重点在网络理论结果考场上遇到算法题直接懵。实际上大厂校招的通用笔试环节算法题占比从来都不低核心网络岗也不例外。我建议把LeetCode上动态规划、字符串处理、哈希表相关的中等题都过一遍后面我会专门用一个章节讲算法题的实战策略。2. 传输层题目从三次握手的为什么到拥塞控制的怎么调2.1 TIME_WAIT和2MSL一道题能拉出多少隐藏考点这套题里有一道关于TIME_WAIT的经典题主动关闭连接的一方为什么需要TIME_WAIT状态为什么等待时间是2MSL相信大部分人能答出确保最后的ACK到达对端和让旧报文在网络中消失但这道题在笔试里经常以变形形式出现比如大量TIME_WAIT出现在客户端还是服务端对高并发短连接服务有什么影响怎么解决先说第一个问题。TIME_WAIT只会出现在主动关闭连接的一端。对于典型的客户端-服务端模型正常关闭时客户端主动close所以TIME_WAIT堆在客户端。但如果服务端设置了SO_LINGER、或者某些协议的交互模式导致服务端先关连接那么服务端也会出现大量TIME_WAIT。关键在于第二个问题为什么需要2MSL。MSL是报文最大生存时间2MSL保证了客户端最后一个ACK如果丢失服务端重传的FIN还在网络里存活期间客户端不会用相同的四元组新建连接避免新旧连接混淆。这是一个从状态设计反推工程取舍的思路——TCP设计者宁可浪费一分钟的端口资源也要保证连接的唯一性和数据的正确性。真实的优化手段通常是三种第一种是调小TIME_WAIT超时时间这在可控内网环境里可以接受但公网场景不建议第二种是打开net.ipv4.tcp_tw_reuse让内核在安全条件下复用TIME_WAIT连接前提是开启tcp_timestamps第三种是从协议层规避比如服务端利用HTTP的keep-alive让长连接复用减少频繁的建连和断连。这些手段不是互相替代的关系而是根据业务特征分层解决。我在实际调优时最深的体会是不要见到TIME_WAIT就反手一个net.ipv4.tcp_max_tw_buckets先判断这些连接是正常业务关闭还是异常半关闭。如果是健康业务导致的TIME_WAIT优先优化连接复用如果是异常流量打过来的调内核参数只是治标。2.2 拥塞控制慢启动到CUBIC再到BBR拥塞控制的题目几乎年年出现2018年这套题也不例外。常见的考法是让候选人描述TCP拥塞控制的四大阶段慢启动、拥塞避免、快重传、快恢复再追问拥塞窗口是怎么增长和下降的。慢启动阶段拥塞窗口指数增长每收到一个ACK窗口加1直到达到慢启动阈值ssthresh。之后进入拥塞避免窗口每轮RTT只增加1个MSS。如果收到3个重复ACK触发快重传同时进入快恢复窗口减半而不是降到1这就是乘法减小、加法增大的AIMD策略。但这些只能算基础分。拉开差距的追问通常是为什么CUBIC是当前Linux默认的拥塞控制算法它比传统的Reno好在哪里更进一步BBR又是怎么工作的和基于丢包的拥塞控制有什么本质区别CUBIC的核心变化是窗口增长函数从线性变成了三次函数。当网络带宽大、RTT也大的时候传统Reno在丢包后窗口增长太慢带宽利用率上不去。CUBIC不管RTT具体多少恢复窗口的速度只跟距离丢包事件的时间有关这对于高带宽长距离链路非常友好。BBR的思路则是绕开了丢包这个指标。它一直在探测带宽和最小RTT用两个状态的交替来逼近最优发送速率丢包不再是直接降低速率的唯一信号。广域网上BBR对带宽的利用有明显提升代价是和传统TCP的公平性需要权衡。如果你能在笔试里把这条演进逻辑讲清楚——从用丢包推断拥塞到直接测量可用带宽面试官基本就能确认你对传输层的理解不是背出来的。2.3 当UDP遇上QUIC为什么连接能搬到应用层2018年的题目没有直接考QUIC但有一道UDP为什么适合游戏音视频传输的题目回答时如果只写无连接、低延迟、不保证可靠只能拿一半分。真正有区分度的回答思路是把UDP当作一个裸管道在应用层自己实现可靠性、拥塞控制和连接迁移。这个思路后来被QUIC大规模验证。QUIC最大的变化是把连接状态从内核搬到了用户态用Connection ID替代四元组连接迁移时IP变了也能保持会话不断。传统TCP连接如果从Wi-Fi切到4GTCP的连接直接断掉必须重新握手。QUIC因为不依赖IP和端口标识连接只要Connection ID不变连接就还在。笔试如果看到这类题目可以往可编程性和部署效率两个方向展开。内核TCP的拥塞控制算法要改一个参数可能得重新编译内核、加载模块而QUIC在用户态实现调整算法直接改代码热更新接入速度完全不同。这个维度在当时的题目里也许不是标准答案但很适合体现你的工程视野。3. 网络编程与内核题目epoll细节决定面试生死3.1 从select到epoll一次系统调用模型的演进逻辑网络研发岗笔试题里select/poll/epoll三者的对比是保留项目。基础答案大家都背过select有FD_SETSIZE限制每次调用要把全部fd集合从用户态拷贝到内核态内核遍历fd的复杂度是O(n)poll解决了fd数量限制但扫描问题依旧epoll通过回调机制只把就绪的fd返回给用户态复杂度降到O(就绪数)。这里我要重点解释epoll高效的本质。select和poll是主动轮询每次调用都要把fd列表重新传给内核内核再遍历所有fd检查事件。epoll则分成了epoll_ctl和epoll_wait两步 epoll_ctl登记fd和感兴趣的事件内核在设备驱动层注册了一个回调函数当fd就绪时回调把该fd挂到就绪队列里epoll_wait只负责把就绪队列里的fd复制到用户态。整个过程避免了每次调用的全量拷贝和遍历。理解了这层机制之后下面几道高频追问也就顺理成章epoll的LT和ET模式分别是怎么工作的为什么ET模式通常要配合非阻塞IO使用为什么一台机器上epoll能支撑百万连接答案分别是就绪事件是否持续上报、ET模式下读数据必须一次性读完、以及一个连接对应一个内核文件描述符并不需要每次扫描。3.2 水平触发还是边缘触发这题不只是背答案水平触发LT模式是指只要fd还有数据可读每次epoll_wait都会返回它边缘触发ET模式是指只有当fd的状态从未就绪变为就绪那一刻才会通知一次。笔试如果只写出这个定义是不够的题目往往会追问实际工程里怎么选。我的经验是绝大多数业务服务器用LT就足够了因为LT模式编程逻辑更简单没有必须一次读完的压力。ET模式的高性能前提是用户态逻辑足够精细能保证每次read或者recv都尽可能把缓冲区数据全部取走避免再次唤醒。但一旦某个包处理慢了或者循环读的条件写错很容易出现数据滞留、事件不再通知的问题排查起来非常头疼。网上很多高性能教程都吹ET我不否认ET的峰值性能上限更高但它带来的是编码复杂度和排查难度。一个稳定、可维护、性能达标的LT模型在绝大多数场景下优于一个写着别扭、偶尔丢事件的ET模型。笔试时你把两种模式的优缺点分析到位比无脑站队ET更能拿分。3.3 数据包全链路从网卡到用户态要过几道门还有一类内核题直接给你一个数据包的路径问沿途经过哪些组件。这类题在核心网络岗笔试里出镜率很高因为它能反映你对现实网络IO的理解深度。一台普通Linux服务器上数据包从网卡到达用户态进程大致路径是网卡收包后把数据写入DMA缓冲区触发硬中断内核的网卡驱动处理中断把数据包封装成sk_buff交给协议栈协议栈依次处理链路层、网络层、传输层最终把数据放入socket接收队列随后内核唤醒等待在socket上的进程用户态通过read或recv把数据从内核缓冲区拷贝到用户态内存。顺着这条链路就能引出零拷贝的问题。传统路径中数据从内核到用户态至少要拷贝一次而sendfile、mmap、io_uring等手段就是试图减少这些拷贝。sendfile适合文件到socket的零拷贝mmap则让用户态直接映射内核缓冲区。我在实际做流量网关时曾经踩过一个很隐蔽的坑某台机器上的大包吞吐始终上不去排查到最后发现网卡的多队列没有打开所有数据包都打到了同一个CPU核上导致单核软中断满载其他核闲着看热闹。这就是很多笔试题目里如何优化数据包处理性能的答案之一——开启RSS多队列、合理设置CPU亲和性、必要时使用DPDK旁路内核。这些不是炫技是真实解决过问题的经验。4. 路由与架构设计题从协议背诵到系统拆解4.1 距离向量与链路状态两种算法思维的工程映射路由算法在核心网络岗笔试里不会缺席。距离向量算法每一位路由器只告诉邻居我到目的地有多远坏消息传播慢容易出计数到无穷的问题RIP就是典型代表。链路状态算法则是每台路由器把自身链路信息广播给全网每台路由器都有完整拓扑图用Dijkstra自己算最短路径OSPF和IS-IS都属于这一类。笔试如果只问区别这是送分题。但如果把场景放大到数据中心网络你会发现现实中的路由设计远比教科书复杂。数据中心里东西向流量巨大、拓扑规则化比如叶脊架构传统IGP要应对三千台设备以上的全互联链路状态数据库会非常大路由收敛时间也会成为瓶颈。业界常见的解法是分层次设计底层用BGP作为underlay每台交换机跑BGP通过BGP的路径属性来控制流量调度上层再用VXLAN这类overlay承载业务网络。BGP原本是自治域间的外部网关协议但在数据中心里它因为无环、支持丰富策略、成熟稳定反而成了underlay路由的首选。笔试如果问到BGP用在数据中心的合理性抓住这三个关键词就行无环、策略丰富、生态成熟。4.2 一致性哈希一个热点问题背后的容量规划思路网络岗位的笔试题里会出现一致性哈希表面上是算法题实际上是系统设计题的开路先锋。最朴素的负载均衡策略是hash(key) % N但当节点数N变化时几乎所有key的映射关系都会改变大量缓存失效、请求回源。一致性哈希把哈希值空间映射成一个环每个节点落在环上每个key顺时针找到最近的节点。当新增节点时只有该节点逆时针方向区间内的key会重新分配其他key不受影响。但节点太少时容易产生数据倾斜这时候虚拟节点就派上用场了——每个物理节点映射出多个虚拟节点让整体分布更均匀。笔试遇到一致性哈希最好主动画一下节点增减影响范围的思路哪怕不画图也要把影响最小化均衡分布这两个核心目标说出来。真实场景里一致性哈希被大量用在缓存集群、网关路由、任务调度里例如Memcached、Cassandra都用了这个思路所以它不是一道孤立的算法题而是分布式系统的通用方案。4.3 设计题如果让你做一个千万级连接的接入层设计题是整张卷子里最考验功力的部分。2018年的设计题背景我印象里是要求设计一个支撑千万级并发连接的接入网关并说明负载均衡策略、连接管理方式和容灾方案。这种题没有标准答案但需要你展示完整的思考链路。我的答题框架是四步先定架构再抠连接管理再谈策略最后考虑故障场景。架构上通常分两层四层LB负责接入流量并做DDoS清洗七层LB根据URL、Cookie、Header做HTTP路由。四层用DPDK收包转发给后端的七层实例集群七层实例再代理到业务服务。这一步要交代清楚每个层面的职责不能混成一团。连接管理的核心问题是如何支撑千万级并发。每一条TCP连接都有对应的fd、发送缓冲区和接收缓冲区内存开销逃不掉。能做的优化是把空闲连接的事件监听交给epoll不占用业务线程连接缓冲区按需分配有数据再申请大块内存必要时启动内核的reuseport让多个进程都能accept同一个端口提高新建连接的速度。负载均衡策略要看业务类型。如果服务是有状态的可以用一致性哈希保证同一用户的请求落到同一台后端如果是对实时性要求高的无状态服务直接加权轮询最合适。容灾层面至少要考虑健康检查、摘除故障节点、自动重拉实例如果要求更高可以提全集群的过载保护例如令牌桶限流和熔断降级。我当时在这类题上吃过亏原因是只堆了很多技术名词却没有讲清楚每个名词在整体链路里解决的是什么问题。现在我的建议是哪怕只写三个组件也要把三者之间的数据流、控制流、故障传递关系描述清楚。面试官要的是系统思维不是词汇量。5. 算法题代码实战笔试里的分分必争5.1 最长上升子序列的两种境界通用算法环节如果出现最长上升子序列LIS至少有两种解法。第一种是O(n^2)的常规动态规划dp[i]表示以第i个元素结尾的最长上升子序列长度转移时遍历之前所有j如果a[j] a[i]就用dp[j]1更新dp[i]。这种代码10分钟就能写完但面对10万级别的输入会超时。第二种是O(n log n)的贪心加二分维护一个tail数组tail[i]表示长度为i1的上升子序列的最小末尾值。遍历每个元素时用二分在tail里找到第一个比它大的位置并替换。这个技巧在笔试里一旦用出来说明你对动态规划的优化有感觉往往能拿下额外印象分。现场写题的时候我会先确认数据范围再决定用哪种解法。如果n小于1000不需要冒险写二分如果n大于10万必须用O(n log n)。这也是一个成熟工程师在压力下的基本素质——不炫技选合适的手段。5.2 字符串处理题用对API还是赢在边界字符串类题目在网络岗笔试里常见因为协议解析本质上就是字符串处理。例如有一个题目要求从一段URL中提取host和端口你当然可以用编程语言自带的方法快速拆但考题想考察的往往是边缘情况URL里有默认端口时要不要保留协议头带不带查询参数会不会污染解析结果大小写要不要统一我看到不少人在这类题上丢分不是不会写而是没考虑到空字符串、非法格式、边界符号这些输入。处理协议或者字符串时把合法输入、非法输入、边界输入三类各准备几组测试用例是保分的通用策略。如果你写的语言是C/C还要额外注意字符串越界和内存管理的问题。笔试环境一般允许你用Python或Java但网络岗的很多老工程师面试官依然欣赏C功底。我个人的选择是快速验证思路用Python需要体现性能和高阶用法时用C具体看题目类型。5.3 考试环境下的答题策略最后聊一下真实笔试环境里的答题顺序。我见过太多同学在一道Hard题上死磕40分钟结果连后面的基础题都没时间写。大厂笔试一般有1.5到2个小时题量和难度都做了一定冗余所以策略性跳题非常重要。我的建议是开考先把所有题扫一遍给每道题标个简单/中等/困难的标签。简单题控制在10分钟以内中等题控制在20到25分钟困难题最多给30分钟做不出来就先把部分通过用例的暴力解交上去。这样能保证基础分拿满。代码层面有一些可以提前准备好的通用模板快排、二分查找、滑动窗口、哈希表、并查集、二叉树遍历、最短路。常用模板烂熟于心等于给做题省出一半思考时间。比如看到最长无重复字符子串你的第一反应应该是滑动窗口哈希表这些都不需要在考场上现场推导。6. 2025年回看这些题现在还能打吗6.1 底层原理的保质期很多人会问2018年的题放到今天还有参考价值吗我的答案是核心原理部分是有的而且价值很高。TCP三次握手的状态变迁、拥塞控制的演进、epoll的事件模型、路由协议的设计思想这些内容过去十年没有本质变化未来十年也不会有颠覆式变化。技术领域很多上层框架半年一小变两年一大变但网络协议栈已经是一个被全球验证过的超稳定系统上层应用可以换代底层的传输和路由逻辑不会轻易重写。你今天理解了为什么TIME_WAIT需要2MSL到了2027年这个知识点依然成立。6.2 新时代的考察重心去哪了当然现在的笔试面试重心确实有偏移。首先是云原生概念变多Kubernetes里的网络模型、服务网格、负载均衡策略越来越常被提及。其次是可观测性网络排障时对链路追踪、Metrics、日志的整合能力成了中高级岗位的考察点。还有一个方向是eBPF和XDP这项技术让内核网络路径上的可编程能力大幅增强很多网络研发JD里已经开始写了。如果现在让我给校招同学一个复习优先级我会说计算机网络的经典原理至少占60%的精力操作系统和网络编程占25%剩下15%留给分布式和云原生场景。原理牢固的人学新框架是不费力的反之则不然。6.3 给今年校招同学的最后几句实话我见过很多人把考进大厂当作终点实际上笔试面试只是职业生涯的开场。把这些网络知识学扎实的意义不只是一张offer而是未来某一天你的服务出了诡异故障时你有能力沿着数据包的轨迹一路排查到问题根源。百度2018年这批笔试题很多细节我现在还记得不是因为题目本身多难而是因为它逼我把零散的知识串成了一张网。如果你正在准备笔试希望你也能带着为什么是这样的心态去复习而不是答案是什么去背题。这套题即使放到2025年也依然是一份能打的教学材料毕竟底层网络世界的逻辑不会因为一年又一年过去就轻易改变。最后再分享一个具体的小技巧不管笔试还是面试当你想表达我对这个技术很熟的时候少用形容词多用具体的数字、路径和边界条件。说我知道epoll很高效不如说我清楚epoll通过回调机制把事件通知复杂度从O(n)降到了O(就绪数)我们在网关里用它扛过百万级长连接。这种具体感才是校招候选人真正稀缺的东西。