1. 核心网络研发考什么先看懂这张卷子的出题逻辑拿到“百度2018校招核心网络研发工程师笔试题第三批”这个标题的时候我的第一反应是这届题目应该挺硬核的。核心网络研发工程师这个岗位在百度内部对应的大多是基础设施部门——负责数据中心网络、骨干网、流量调度、自研网络设备或者高性能网关这一类方向。和普通后端研发不一样这个岗位的笔试题不会让你写业务接口也不会让你做用户表设计它考的是你对网络协议栈、数据转发路径、路由控制平面和系统底层能力的综合理解。我认识不少当年一起投这个岗位的朋友大家的反馈出奇一致这批题的区分度很高。高在哪里高在它不考死记硬背的协议细节而是考你“在一个真实网络场景里能不能用协议知识做出正确判断”。所以如果你打算投递类似的岗位第一件事不是埋头背OSI七层模型而是先把这张卷子的出题逻辑摸清楚。从我了解到的信息和多方比对来看第三批笔试题大致覆盖了四个核心模块。第一个模块是网络基础与协议栈主要考察TCP/IP、HTTP、DNS这些日常最常接触但又最容易被忽视的细节。第二个模块是路由与交换技术重点在路由协议、转发原理和网络设计。第三个模块是系统与编程能力毕竟核心网络研发不是纯网络工程你得会写代码得理解操作系统底层。第四个模块是数据中心网络与SDN/NFV相关的前沿技术百度在自研网络设备、SDN控制器和流量调度系统上投入很大笔试必然会对这个方向有所倾斜。理解了这张卷子的整体结构你再去看题就不会慌。它其实是在筛选两类人一类是网络底子扎实、遇到问题能追到报文级别的工程师另一类是系统能力强、能在高性能网络场景里写出可靠代码的工程师。如果你两项都占那这张卷子对你来说就是友好且能拉开差距的。2. TCP/IP协议栈高频题细节决定你能不能进下一轮TCP/IP协议栈是核心网络研发岗位的“吃饭本事”这部分题目的特点是看起来简单一做就错。我梳理了几个在第三批题目里出现频率较高的考点每一个都值得你重新过一遍。2.1 三次握手的边界条件第三次ACK丢了会怎样这几乎是必考题但大多数人的答案最多得一半分。很多人只记得“客户端进入ESTABLISHED服务端收不到ACK会重传SYNACK”但真正值钱的细节在于如果客户端在第三次握手ACK发出后立刻发送数据包服务端在SYN_RCVD状态下收到这个数据包会怎么处理正确的链路是服务端在SYN_RCVD状态收到客户端的数据包时如果该数据包不带ACK标志那么根据RFC 793服务端会把这个数据包丢弃并重新发送SYNACK。但如果这个数据包携带了ACK标志哪怕它不是纯粹的ACK包服务端也会认为握手已经完成把状态切换为ESTABLISHED同时处理数据。这个细节考的是你对TCP状态机和报文交互的理解深度而不仅仅是背一个三次握手流程。还有一个变体如果客户端的第三次ACK在网络上延迟了很久才到达服务端在此期间已经因为重传超时关闭了连接那这个迟到的ACK到了之后服务端会回一个RST。这个RST会导致客户端从ESTABLISHED状态直接跳到CLOSED。这种场景在处理高并发短连接服务时非常常见尤其是客户端连接池需要大量新建连接时。2.2 拥塞控制的演进别只停留在Reno和CUBIC2018年的校招题已经明显开始考察BBR了。百度这样的体量带宽利用率哪怕提升1%节省的成本都是天量级的所以拥塞控制算法是核心网络团队的重点研究方向。题目通常这样出解释Reno、CUBIC和BBR在拥塞窗口调整上的核心差异以及在什么网络场景下BBR能比CUBIC获得更好的吞吐。CUBIC是BDP探测型的它通过三次曲线来探测带宽遇到丢包会乘性减窗。BBR换了一套思路它不再以丢包作为拥塞信号而是通过实时测量最小RTT和最大带宽来建模网络管道然后用pacing的方式让发送速率贴合带宽。这里有一个关键点值得展开BBR的ProbeRTT阶段会周期性把拥塞窗口降到4个MSS目的是重新测量最小RTT。因为路径上的排队延迟会随时间变化如果一直保持一个很大的发送速率RTT会虚高。这个“故意降速重新测量”的操作和传统算法“发送速率越高越好”的直觉完全相反但恰恰是BBR能够在高丢包链路上保持高吞吐的原因。答题时如果能把这个机制解释清楚面试官对你的评价会直线上升。2.3 HTTP队头阻塞从HTTP/1.1到HTTP/2再到HTTP/3这批题里HTTP相关的题目卡了不少人原因在于它考的已经超出了“GET和POST的区别”这个level而是直接问你HTTP/2解决了HTTP/1.1的队头阻塞为什么还会出现队头阻塞HTTP/1.1的队头阻塞发生在应用层一个TCP连接上只能串行处理请求前面的响应慢了后面的请求全部排队。HTTP/2引入了多路复用通过stream在一条TCP连接上并发传输多个请求看起来解决了问题。但HTTP/2的底层仍然是TCPTCP保证有序传输的机制导致如果某个stream的包丢了后续所有stream的包都不能被应用层处理必须等待重传。这就是TCP层的队头阻塞HTTP/2解决不了。真正的解法是HTTP/3它把传输层换成了QUIC基于UDP实现可靠传输每个stream独立有序丢包只影响它自己所在的stream。这个问题在核心网络研发面试里几乎是必问的因为它考察的不是你用过多少HTTP库而是你对分层模型和传输机制之间交互关系的深入理解。3. 路由与转发题从CIDR聚合到BGP路径选择的计算逻辑路由与转发是核心网络研发的“物理基础”这部分题目通常不是简单的概念问答而是需要实际计算的。第三批题目里计算题的占比不低而且计算量都不大但思路要清晰。3.1 路由聚合的边界不是所有地址都能老老实实聚合有一道经典题目是这样的有四个网段192.168.1.0/24、192.168.2.0/24、192.168.3.0/24、192.168.4.0/24要求写出能覆盖前三个网段的最小聚合路由以及能覆盖四个网段的最少路由条目数。前三个网段聚合很简单192.168.1.0/24的二进制是11000000.10101000.00000001192.168.2.0/24是00000010192.168.3.0/24是00000011。前22位相同所以聚合结果是192.168.1.0/22。但加上192.168.4.0/24就麻烦了它是00000100和前面的公共前缀只有20位相同。如果你强行聚合四个网段得到的是192.168.0.0/20这个路由会覆盖192.168.0.0到192.168.15.255多覆盖了12个网段在实际网络中可能造成路由黑洞或流量被错误转发。所以正确答案是两条路由192.168.0.0/22和192.168.4.0/24它们才能精确覆盖四个网段。这个题目的价值不在于计算本身而在于考察你是否明白一个道理路由聚合必须“精确”宁可多一条路由也不能让聚合后的路由覆盖到不存在的网段。3.2 OSPF与BGP协作角色不同路径选择逻辑不同另一道常考计算题是路由优先级和选路规则的混合场景。题目会给你一个网络拓扑一台路由器同时运行OSPF和BGPOSPF学习到一条到达目标网段的路径cost为110BGP学习到同一条路径local_pref为200MED为50。问你最终优选哪条路径。在华为、思科设备上不同协议之间比较的是路由优先级华为叫preference思科叫administrative distance。OSPF内部路由的优先级通常是10BGP是255思科eBGP是20iBGP是200。但很多时候题目会故意省略这些默认值而是把比较逻辑放在同一个协议内部。如果是BGP内部比较local_pref优先然后才是AS路径长度、MED等。这里真正的考点是跨协议比的是优先级同协议内部才比选路属性。很多考生把这两个规则混在一起结果得出完全相反的答案。题目里还会附带一个“为什么BGP要有这么多选路属性”的加分题。这个问题的本质是IGPOSPF、IS-IS在同一个AS内部已经能算出最短路径了但AS之间的运营商有复杂的商业关系客户、上游、对等需要一套可策略化控制的选路机制来体现这些商业决策。理解了这层逻辑你就懂了为什么BGP的选路规则不是单纯的技术最优而是商业策略驱动的。3.3 转发面的最长前缀匹配硬件层面的核心逻辑路由与转发的计算题有时候也会往硬件方向延伸比如问TCAM如何实现最长前缀匹配。TCAM三态内容寻址存储器的每个bit都有三个状态0、1、X不关心所以它天然适合存储路由前缀。要匹配时所有表项同时参与比较命中的条目里优先级最高的就是最长匹配的那个。这里有一个补充考点因为TCAM贵且功耗高但路由表越来越大所以业界会有“把路由分级把常用前缀放到DRAM里用算法匹配不常用的才放TCAM”这类思路。这些内容在笔试里考得少但如果你面试时能主动提出来会让面试官觉得你有工程视野。4. 高性能网络与系统底层DPDK、零拷贝和网卡多队列的实战理解核心网络研发工程师的工作场景里有相当一部分是高性能网络转发比如百度自研的四层负载均衡、流量网关、缓存加速代理等这些系统的核心就是处理海量并发报文。所以笔试里出现系统与性能类题目一点都不意外。4.1 内核协议栈的瓶颈和DPDK为什么能绕过去题目常常这样出一台普通的x86服务器跑Linux内核协议栈处理64字节小包转发性能通常只能到几十万PPS想提升到千万PPS甚至更高需要怎么做答案的核心就是“绕过内核”或“优化内核收包路径”。展开来说内核协议栈的瓶颈有三个。第一系统调用开销每个包都要经过recvfrom/sendto或read/write用户态和内核态频繁切换。第二数据拷贝包从网卡缓冲区拷贝到内核内存再从内核内存拷贝到应用缓冲区多一次访存开销。第三内核锁竞争多核CPU同时处理网络包时协议栈里的全局锁和共享数据结构会形成争抢。DPDK的处理思路是通过UIOUserspace I/O把网卡设备映射到用户态用轮询模式PMD替代中断通知应用程序直接通过大页内存与网卡交换描述符绕过内核协议栈。这个方案能把单核收包性能从几十万PPS提升到上百万PPS级别在业界已经是非常成熟的实践。答题时如果能提到“大页内存减少TLB miss”这一层说明你真的看过代码而不是只背了概念。4.2 零拷贝的几种实现mmap、sendfile和网卡分片零拷贝是高性能网络服务里绕不开的话题。题目通常给你一个文件下载服务的场景问你如何减少数据在用户态和内核态之间的拷贝次数。传统方式要经历磁盘到内核缓冲区内核到用户缓冲区用户到socket缓冲区socket缓冲区到网卡一共四次拷贝四次上下文切换。用sendfile可以达到两次拷贝用DMA直接内存访问配合网卡Scatter-Gather功能可以做到真正意义上的“零拷贝”——数据从磁盘到页缓存后通过DMA引擎直接描述符指向页缓存中的数据不经过CPU拷贝直接发送到网卡。这里有个细节很多人会忽略零拷贝的瓶颈不再在CPU拷贝上而是转移到了页缓存和socket缓冲区之间的一致性维护上如果频繁读写可能触发page fault反而性能下降。实测下来对小文件高并发的场景用sendfile不一定比精心调优的传统readwrite快因为DMA描述符的建立和拆除也有开销。这个反直觉的结论如果在笔试的论述题里写出来会很加分。4.3 网卡多队列与RSS让每个CPU核心都有活干另一个常见考点是网卡多队列和Receive Side ScalingRSS。单队列网卡在接收报文时需要靠一个中断来处理所有包多核CPU无法分摊收包压力。启用多队列后网卡可以根据四元组或五元组哈希把不同的流分散到不同的RX队列每个队列由独立的CPU核心处理这样就能并行收包。题目会问RSS的哈希因子有哪些如果哈希因子包含源IP和目的IP来自同一个IP的不同端口连接会被分到多个队列吗答案是如果哈希计算包含端口那会分散到不同队列但如果只基于IP那同一对IP的流会固定在同一个队列可能在某些负载均衡场景下造成队头热点。这个问题的价值在于它让你意识到看似“自动分散”的网卡哈希如果不和实际业务流特征匹配反而会成为性能瓶颈。5. 数据中心网络与SDN/NFV从VXLAN到控制器设计的必考题百度在数据中心网络方向的布局很早从自研交换机、SDN控制器到流量调度系统都有成熟的落地。这批笔试题里出现数据中心相关题目非常合理也代表着国内头部互联网公司对这个方向的重视程度。5.1 VXLAN封装细节外层UDP的源端口到底怎么选VXLAN几乎是数据中心网络必考项。题目通常会给你一个虚拟机迁移的场景虚拟机从物理机A迁移到物理机B但IP地址保持不变对端如何通过VXLAN隧道继续访问它VXLAN把二层帧封装在UDP报文里VTEPVXLAN Tunnel Endpoint负责封装和解封装。关键点在于外层UDP的源端口它是根据内层MAC、IP、端口等信息哈希计算出来的目的端口固定是4789IANA分配的端口。源端口设计成哈希值的目的是为了在底层网络上实现负载均衡——ECMP等价多路径协议可以根据外层五元组把流量打散到不同的物理链路上。如果不做这个哈希所有VXLAN流量在底层看来都走同一个五元组ECMP会把所有流量都压到一条链路上这就是经典的“Hash极化”问题。答题时如果能把这个设计意图讲清楚就不仅仅是答了一道题而是在展示你理解了VXLAN“为什么这么设计”的工程智慧。5.2 SDN控制器集中式优于分布式但没有全局看到底行不行SDN相关题目在第三批里也有一席之地。常见问法是SDN控制器的核心职责是什么为什么数据中心网络要用SDN做流量调度而不是传统的分布式路由协议SDN把网络控制平面和数据转发平面分离控制器掌握全局拓扑可以用全局视角计算最优路径下发流表到交换机。相比之下传统路由协议是分而治之的每台设备只知道自己的邻居关系无法感知全局拥塞情况。数据中心网络流量模型极其复杂流量矩阵动态变化集中式控制器可以根据实时负载做全局优化。但集中式控制器也带来可靠性问题——控制器挂了整个网络的路径计算就瘫痪了所以实际工程中控制器通常以集群方式部署用分布式数据库同步网络状态。这里有一个容易踩坑的认知很多人以为SDN就是OpenFlow的代名词但实际工程中OpenFlow只是SDN南向接口的一种实现方式。百度早期的SDN方案里也大量使用了自研的南向协议或者通过BGP、NETCONF等“传统”协议实现控制器的集中控制。SDN的本质是“控制与转发分离”这个思想而不是某一种具体协议。回答时点出这层才能体现出工程视野。5.3 CLOS架构与ECMP现代数据中心网络的骨架数据中心网络设计题通常围绕CLOS架构展开。CLOS解决的是“大二层网络如何扩展”的问题核心层Spine和接入层Leaf之间通过ECMP形成等价多路径所有Leaf都能通过多条路径到达任何其他Leaf带宽可水平扩展。题目会问为什么CLOS架构比传统三层树形架构更适合数据中心核心原因有两个。第一树形架构的汇聚层是瓶颈流量越高汇聚层设备压力越大而且难以水平扩展。第二CLOS架构下所有路径都是等价的通过ECMP实现负载均衡链路利用率高故障转移也快——一条链路断了流量立刻均匀分摊到其他等价路径上。这个题目还有一个衍生问法ECMP的哈希因子和前面VXLAN的哈希源端口设计有什么关联对的VXLAN外层UDP源端口哈希就是为了解决ECMP哈希极化问题两道题是一套组合拳。你如果能把它们串起来回答面试官会知道你是真的理解而不是背概念。6. 编程与系统实现题网络工程师的代码功底不能拉胯核心网络研发工程师的日常不是天天调路由器而是写代码——写网关、写转发面、写控制面组件、写网络监控系统。所以卷子里一定有代码题和系统设计题这些题目的水平和难度和纯后端岗位的题风格截然不同。6.1 C语言的字节序与内存对齐最容易栽跟头的地方第一类高频题是C语言和操作系统底层细节。字节序问题是网络编程的经典陷阱x86机器是小端序网络字节序是大端序用htonl/ntohl转换。但如果处理的是一个结构体——比如一个自定义报头里面有uint8_t、uint16_t、uint32_t混合字段直接强制类型转换再发送就会因为内存对齐产生填充字节导致接收端解析出错。正确的做法是用packed结构体__attribute__((packed))或者每个字段单独序列化。笔试里可能会给你一段代码问你这个结构体在64位系统上会占用多少字节如果加了packed又是多少字节。这种题考察的是你写网络协议代码时能否处理字节序和内存布局问题这在高性能网络开发里非常常见坑很深。6.2 生产者消费者模型从互斥锁到无锁队列的设计取舍题目会给你一个场景多个生产者线程把网络数据包写入队列多个消费者线程从队列中取包处理如何设计这个队列第一层答案是互斥锁加条件变量这是教科书方案。第二层答案是读写锁、自旋锁的取舍在临界区极小的情况下自旋锁比互斥锁更合适因为它避免陷入内核态。第三层答案才是面试官真正想听的无锁队列。用CASCompare-And-Swap实现lock-free的MPMC队列或者更务实的SPSC队列——单生产者单消费者队列通过ring buffer就能实现无锁这在DPDK的rte_ring里就是经典实现。这里有一个关键取舍无锁队列在读多写少、临界区极短的高并发场景下性能优势巨大但无锁不等于无坑ABA问题、内存序问题memory ordering都可能导致诡异bug。所以笔试答题时最好能说明白什么场景选什么队列以及为什么而不是一味追求花哨的无锁实现。6.3 多线程并发中的原子操作与内存屏障再往后有一类题围绕多线程同步的正确性展开两个线程一个写一个读都操作同一个变量如何保证读到的一定是最新值答案是volatile?错。在C/C里volatile只能告诉编译器不要优化不能保证多核间的可见性也不提供原子性。正确做法是用C11的atomic、std::mutex或者提供内存屏障的原子操作。进一步会问为什么CPU会乱序执行为什么需要内存屏障现代CPU为了性能会进行指令重排多核之间还有缓存一致性协议比如MESI带来的伪共享问题。cache line是64字节如果两个线程频繁修改同一cache line上不同变量会因为伪共享导致性能雪崩。用__attribute__((aligned(64)))把变量对齐到cache line边界可以规避这个问题。这类题考的是你对系统底层的理解一个合格的核心网络研发工程师必须能写出“确定性强”的高并发代码。7. 综合设计题实战模拟从零设计一个高可用四层接入网关网络方向的综合设计题通常是卷子的压轴大题分值高、难度大。它往往不以“写代码”的形式出现而是要求你画架构图、说清楚关键模块和容灾方案。这里我结合网络上找到的类似题型和岗位要求还原了一道比较有代表性的设计题并附上完整的解题思路笔试面试都能用得上。题目大意公司需要设计一个高可用的四层接入网关承接所有外部流量并转发到后端服务集群要求支撑10万QPS、可用性99.99%请设计整体架构并说明关键设计点。这道题想拿高分需要从四个层面去回答。第一层是整体架构接入网关采用集群部署多台机器通过ECMP等价路由对外提供服务使用BGP与上层交换机互通任何一台机器故障流量自动被ECMP重新哈希到其他机器。在网关机器内部使用DPDK接管网卡业务逻辑全部在用户态实现。四层转发不做太多复杂逻辑只做DNAT和SNAT所以可以做到很高吞吐。第二层是会话一致性四层网关必须保证同一个客户端的连接五元组始终落在同一台后端机器上否则TCP连接会断开。用一致性哈希表保存会话状态会话表需要定期同步或者将状态存到分布式KV里保证故障切换时会话不丢。但分布式KV带来的延迟在数据路径上不可接受所以实践中会在每台机器本地保存会话表配合主备同步极少数情况下故障会导致连接重建这是99.99%可用性可以容忍的。第三层是健康检查与故障剔除网关需要定期探测后端服务的健康状态探测失败要自动摘除该后端并重新建立会话同时不能影响现有连接。这里要考虑“探活频率”和“误判”之间的权衡探得太频繁会对后端产生额外压力探得太慢故障转移时间过长。一般会设计成TCP连接探测和HTTP探测的双层机制。第四层是安全与防洪作为公网入口网关必须能抵抗SYN Flood。解法是开启SYN Cookie或者用硬件卸载卡做DDoS清洗只有通过验证的流量才进入内核态处理。这个问题在百度真实场景里是绕不开的所以出现在笔试里非常合理。这道题的完整回答至少要涵盖ECMP接入、DPDK转发、会话一致性、健康检查、故障转移、DDoS防护、安全隔离、监控和日志统计这几个模块答得越全越接近核心网络研发工程师的真实工作画像。8. 备考与答题策略笔试里的时间管理同样决定成败最后聊点实际的这部分是我和几个参加过百度校招的朋友交流后总结出的经验不一定写在任何帖子里的但非常关键。8.1 时间分配和答题顺序这套笔试题给人的体感是“时间不够”。我有朋友当年在这套题上有些题目只能留空白原因不是不会做而是前面在二叉树、哈希表这类基本功题目上花了太久后面的大题反而没时间展开。我个人的建议是先做综合设计题和论述题再做计算题最后做选择题和填空题。为什么综合设计题是开放性的只要你框架清晰、要点齐全即使细节不够完美也能拿到大部分分数。计算题如果思路错了可能什么都得不到但如果是列了步骤但算错结果通常还能拿到过程分。选择填空是纯客观题一题就一两分占比不大放在最后反而不会心慌。8.2 答题时的表述技巧请用“工程师的语言”而非“课本的术语”笔试答题尤其是简答和设计题极其看表述方式。举个例子同样的意思“TCP的拥塞窗口会减小”和“窗口大小根据当前链路的RTT和丢包率动态调整丢包时进入拥塞避免阶段通过乘性减窗降低发送速率以缓解链路拥塞”给阅卷人的专业程度印象完全不同。再一个细节设计题里图要画关键模块的名称要写清楚接口要标注箭头方向不要只写一堆文字。阅卷人和面试官都偏好“能一眼看到架构全貌”的答案。画图不需要多精美但核心链路和容灾链路必须用不同颜色或线型区分开。8.3 结合个人经验谈谈这套题的复习方向如果你正打算投递核心网络研发岗我建议你按照“基础协议栈-路由交换-高性能转发-数据中心网络-SDN/NVF-系统编程”的顺序系统复习。但要注意不要停留在背概念每学一个协议问自己三个问题——它解决什么问题、它的报文格式里每个字段为什么存在、它在真实网络里有哪些常见的坑。把这三个问题想清楚无论是笔试还是面试你都能对答如流。我当年复习TCP时用一个笨方法用Wireshark抓自己机器上浏览网页的包跟着TCP流看三次握手、窗口变化、重传超时再对照RFC看报文头。这个过程看起来慢但对建立“报文级直觉”特别有效。笔试里有些题是“纸上谈兵”考不出来的但你如果见过真实的报文交互一眼就能看穿考点在哪里。9. 写在最后几个容易被忽略但考试高频的“边角料”这些内容我在前面没有具体展开但它们出现的概率极高而且一旦考到如果没看过就是完全空白所以我单独拉出来讲一下。9.1 DNS解析细节递归、迭代与缓存TTL的坑DNS相关题目在网络岗笔试里很少缺席。常见问法是用户在浏览器输入一个域名完整解析过程是怎样的这里要答清递归查询和迭代查询的区别、本地hosts文件、系统resolver、客户端本地DNS缓存、运营商LocalDNS、根服务器、顶级域服务器、权威服务器以及每个环节的缓存TTL机制。有意思的考点是TTL过短会导致DNS查询爆量TTL过长会导致域名切IP后客户端不生效。2018年前后正是各家互联网大厂开始大规模使用HTTPDNS的年代原理就是绕过运营商LocalDNS避免被劫持和调度不精准所以题目也有概率延展到HTTPDNS的优缺点——相比传统DNSHTTPDNS是应用层通过HTTP接口直接拿到IP列表避免中间环节的污染和缓存问题但需要客户端SDK配合。这题考的是你对“域名解析链路”的完整理解。9.2 BGP路由振荡正则表达式和route-map实际怎么用BGP的题目有时候会出一些实操向的给出几条BGP路由填写正则表达式匹配特定前缀或者设计route-map完成基于AS路径的选路控制。这类题要求你真用过BGP知道AS_PATH里各种字符的含义。正则表达式里有一个坑^192_和_192_的区别。前者匹配的是以192开头的AS路径后者匹配路径中包含192的任意位置。如果只是求包含某个AS号的所有路由用后者如果限定起源AS用前者。这种题目答案很明确但很多没实操经验的人会混淆。我建议备考时在模拟器里建一个BGP环境手动配几条route-map把正则表达式和过滤逻辑亲手跑几遍记忆会牢固很多。9.3 网络质量观测RTT、抖动、丢包率到可用性的推导关系最后一类容易被忽略的题目是网络质量观测类。它会给你一组数据某条链路的RTT是20ms抖动5ms丢包率0.1%问这条链路的可用性是多少这里“可用性”的定义不是简单的1减去丢包率而是要看业务模型。比如严格依赖TCP传输的业务0.1%的丢包率会导致大量TCP重传和拥塞窗口退化实际吞吐可能下降超过5%可用性远低于99.9%。这个问题的深层考点是网络质量指标不能只看单个值需要结合协议行为和应用场景做联合分析。核心网络研发工程师在真实工作中就是干这个的——接报警、看指标、定位链路瓶颈、优化转发路径每一步都需要这套分析能力。我把这些“边角料”单独拎出来是因为它们在我的经验里恰恰是拉开分差的地方。基础题大家都会协议细节背一背也能过关但能把DNS解析、BGP实操、链路质量分析这些细碎知识融会贯通的人才是真正适合核心网络研发岗位的人。这套笔试的第三批题目本质上就是在筛选这批人。