提到大厂校招里的“核心网络研发工程师”很多人第一反应是这不就是运维吗其实完全两码事。这个岗位在百度内部管的是接入层负载均衡、数据中心网络、协议栈优化、流量调度这些基础设施简单说用户每一次搜索、每一个视频请求背后都会经过这些代码和系统。所以这套笔试的题目风格非常鲜明不考框架、不考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链路带宽为20MbpsMSS为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里批量取包取出的包经过GROGeneric Receive Offload合并小包后进入IP协议栈ip_rcv、TCP协议栈tcp_v4_rcv根据四元组找到对应的socket放入接收队列最后应用程序通过recv/read系统调用把数据从内核缓冲区拷贝到用户态缓冲区。如果只是背出这条路径只能拿基础分。真正能拉开差距的是你能否说出丢包可能发生在哪些环节、怎么定位。根据我自己的排查经验常见的丢包点包括网卡ring buffer满了新到的包没有可用描述符被网卡直接丢弃。看ethtool -S的输出rx_missed或rx_dropped会增加。硬中断或软中断集中在某个CPU核上导致单核处理不过来。如果开了RSSReceive Side Scaling多队列但没做CPU绑核中断分布可能依然不均匀。协议栈的backlog队列netdev_max_backlog溢出数据包在进入协议栈前就被丢弃。socket接收缓冲区tcp_rmem满了TCP协议栈只能丢包或者触发对端重传。应用程序处理速度跟不上接收队列被填满。对应的优化手段也有清晰的层次首先通过RSS多队列CPU亲和性把中断分散到多核其次调大ring buffer和backlog再往后可以考虑启用busy poll甚至用DPDK旁路内核直接收包。这套链路最核心的设计思想是NAPINew 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放到SYNACK里等客户端回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超时重传时间代替RTTRTO一般比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连不上的场景里要先查防火墙规则而不是查路由每道题考完之后都花几分钟把它和相邻知识点连接起来形成一张网。这样笔试遇到没见过的综合题时就不会慌可以从熟悉的知识点里找到切入角度。在我个人复盘这套试卷时最大的感触是它考的不是知识的广度而是你是否具备“从现象推导原因、从数据定位问题”的思维习惯。计算机网络和别的领域不太一样现实中几乎所有故障都有日志、有计数器、有抓包证据。笔试只是把这些证据用题目形式包装了一下本质上还是在考察候选人有没有“看到现象→提出假设→验证假设”的闭环能力。如果你能把日常实验中的异常都记录下来整理成自己的“事故笔记本”再回来看这套笔试题会发现大部分题目都脱胎于真实故障场景。带着这种视角去复习比单纯刷题要事半功倍得多。 
长河君 · 2026/8/29 23:16:35 · 阅读 1.2k 大厂核心网络研发校招笔试题复盘：TCP/IP、内核协议栈与负载均衡
提到大厂校招里的“核心网络研发工程师”很多人第一反应是这不就是运维吗其实完全两码事。这个岗位在百度内部管的是接入层负载均衡、数据中心网络、协议栈优化、流量调度这些基础设施简单说用户每一次搜索、每一个视频请求背后都会经过这些代码和系统。所以这套笔试的题目风格非常鲜明不考框架、不考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链路带宽为20MbpsMSS为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里批量取包取出的包经过GROGeneric Receive Offload合并小包后进入IP协议栈ip_rcv、TCP协议栈tcp_v4_rcv根据四元组找到对应的socket放入接收队列最后应用程序通过recv/read系统调用把数据从内核缓冲区拷贝到用户态缓冲区。如果只是背出这条路径只能拿基础分。真正能拉开差距的是你能否说出丢包可能发生在哪些环节、怎么定位。根据我自己的排查经验常见的丢包点包括网卡ring buffer满了新到的包没有可用描述符被网卡直接丢弃。看ethtool -S的输出rx_missed或rx_dropped会增加。硬中断或软中断集中在某个CPU核上导致单核处理不过来。如果开了RSSReceive Side Scaling多队列但没做CPU绑核中断分布可能依然不均匀。协议栈的backlog队列netdev_max_backlog溢出数据包在进入协议栈前就被丢弃。socket接收缓冲区tcp_rmem满了TCP协议栈只能丢包或者触发对端重传。应用程序处理速度跟不上接收队列被填满。对应的优化手段也有清晰的层次首先通过RSS多队列CPU亲和性把中断分散到多核其次调大ring buffer和backlog再往后可以考虑启用busy poll甚至用DPDK旁路内核直接收包。这套链路最核心的设计思想是NAPINew 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放到SYNACK里等客户端回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超时重传时间代替RTTRTO一般比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连不上的场景里要先查防火墙规则而不是查路由每道题考完之后都花几分钟把它和相邻知识点连接起来形成一张网。这样笔试遇到没见过的综合题时就不会慌可以从熟悉的知识点里找到切入角度。在我个人复盘这套试卷时最大的感触是它考的不是知识的广度而是你是否具备“从现象推导原因、从数据定位问题”的思维习惯。计算机网络和别的领域不太一样现实中几乎所有故障都有日志、有计数器、有抓包证据。笔试只是把这些证据用题目形式包装了一下本质上还是在考察候选人有没有“看到现象→提出假设→验证假设”的闭环能力。如果你能把日常实验中的异常都记录下来整理成自己的“事故笔记本”再回来看这套笔试题会发现大部分题目都脱胎于真实故障场景。带着这种视角去复习比单纯刷题要事半功倍得多。