看到2018年百度核心网络研发工程师校招笔试题第三批的时候我第一反应是挺感慨的。虽然这已经是几年前的题目了但“核心网络”这四个字所代表的岗位方向——偏底层的网络协议栈、高性能网络框架、分布式的负载均衡体系——在校招笔试里考来考去主线其实一直没变。TCP状态机的细节、epoll的触发模式、HTTPS握手过程的RTT计算、四层和七层负载均衡的取舍放到今天依然是网络研发岗面试的高频考法。所以我更愿意把这份题单看作一套“网络研发岗考点地图”结合我自己备考时刷题、做实验、复盘错题的经验把里面最值得展开的几类问题拿出来拆一遍。这篇文章适合两类人看一类是正在准备大厂校招、目标岗位是网络研发或者后端基础设施方向的同学另一类是已经在做业务开发、但想往底层网络方向走的工程师。文章不按原题逐题给答案而是把“这一批题背后真正想考察的能力”提炼出来再配合可复现的排查命令、代码片段和架构对比来展开。毕竟笔试题可以忘但出题人想考察的思维方式才是值得沉淀的东西。1. 先看懂这一批题的出题意图核心网络研发岗到底在考什么1.1 从岗位定位反推考点“核心网络研发工程师”这个岗位名称就已经透露了很多信息。它不像业务后端那样侧重业务建模、数据库设计也不像纯算法岗那样暴力堆动态规划和图论。它的核心工作场景是设计高并发接入网关、优化数据包在内核中的转发路径、维护四层/七层负载均衡集群、排查线上TCP连接异常、以及处理跨地域机房间的网络调度问题。所以笔试题目一定会围绕这几个方向展开。我复盘时把这批题涉及的考点分了四层第一层是TCP/IP协议栈细节这是地基。三次握手为什么是三次、TIME_WAIT为什么要等2MSL、拥塞控制里快重传和快恢复的触发条件这些问题几乎每年都考只不过换着角度出。第二层是应用层协议重点是HTTP和HTTPS。HTTP/1.1到HTTP/2的演进逻辑、HTTPS握手的RTT计算、DNS递归和迭代的流程都是高频题。第三层是Linux网络编程和内核网络路径比如select/poll/epoll的对比、LT和ET模式的选择、数据包从网卡到应用进程的完整路径、零拷贝的实现原理。第四层是分布式架构视角下的网络问题包括四层/七层负载均衡选型、一致性哈希原理、连接管理、高并发下文件描述符和端口耗尽等问题。如果你把这一批题目打印出来对照这四层去看会发现大部分题都落在这些框架里。这也是网络研发岗笔试的一个规律它不追求偏题怪题而是讲究基础和深度并重很多题目看似是八股但实际考察的是你有没有真正在Linux环境下排查过网络问题。1.2 试卷整体结构与答题策略这一批题的整体结构大概分三块选择题、简答题和在线编程题。选择题覆盖的协议范围最广但难度相对温和主要考察概念辨析简答题通常是给一个线上故障场景比如大量TIME_WAIT、连接超时、握手重传让你分析原因并给出解决方案编程题一般是两道一道偏数据结构比如手写LRU一道偏网络编程或者系统设计比如实现一个简易的高并发网关。做这类题有一个很实际的策略先快速扫一遍所有题目把有把握的题先做掉给自己建立信心然后再去啃那些需要推导和计算的题。选择题不要在单个题上恋战最多两分钟想不出来就标记跳过。简答题要留意题干里的关键词——它说的是“客户端大量TIME_WAIT”还是“服务端大量CLOSE_WAIT”原因和排查方向是截然不同的。编程题如果时间紧张也要先把思路写出来让阅卷人看到你具备基本的算法和工程素养步骤分往往比一行完美代码值钱得多。2. TCP细节是重头戏三次握手、四次挥手与状态机2.1 三次握手为什么必须是三次SYN Flood的防御思路这一批选择题里几乎必有一道关于三次握手的题。常见问法是“TCP建立连接为什么需要三次握手两次行不行”。很多人的回答是“防止旧连接请求到达服务端导致错误”这个说法方向对但不够精准。如果只有两次握手服务端无法确认客户端的接收能力是否正常。考虑一个场景客户端发送的第一个SYN报文因为网络拥塞被延迟了很久客户端等不到SYNACK就超时重传了于是新旧两个SYN报文都能到达服务端。如果只有两次握手服务端收到第一个SYN就会建立连接并分配资源白白等着一个根本不会来的客户端。而三次握手里客户端收到服务端的SYNACK后还要回一个ACK服务端收到这个ACK后连接才建立。如果客户端压根没有收到SYNACK说明客户端接收可能有问题或者客户端根本不打算建立这个连接服务端就收不到最后的ACK连接自然不会建立资源也就不会白白浪费。更本质的理解是三次握手让通信双方都确认了“自己发报文的能力”和“对方收报文的能力”都是正常的。第一次握手客户端确认服务端在收第二次握手服务端确认客户端在发、客户端也确认服务端能发能收第三次握手服务端确认客户端能收。这个对称性的角度在简答题里写上去会比只背结论得分高。SYN Flood攻击也是围绕这个机制展开的。攻击者伪造大量源IP发送SYN报文服务端回复SYNACK后进入半连接队列等待最后的ACK却永远等不到内存和连接表资源被快速耗尽正常用户就无法建立连接了。防御思路通常会考这几个方向调整半连接队列大小、用SYN Cookie机制收到SYN时不给半连接分配完整结构而是通过编码生成一个cookie放进SYNACK的序号里收到ACK后再校验、配合iptables限制单位时间单IP的SYN速率。这些思路理解起来不难但需要你动手在服务器上看过半连接队列的溢出数据才能真正理解为什么TCP的backlog参数和somaxconn参数在高并发场景下如此重要。2.2 四次挥手与TIME_WAIT线上故障排查的硬功夫三次握手考理解四次挥手一般就会结合故障排查来考。TCP是全双工协议两个方向的关闭是独立的所以需要四次交互。我复盘题目时看到一类典型问法服务端某个端口出现大量TIME_WAIT连接是正常现象还是需要处理如果是客户端主动关闭连接大量TIME_WAIT其实是正常且必要的。TIME_WAIT的作用有两个一是保证最后的ACK能重传防止对端因为没收到ACK而重发FIN导致死等二是让旧连接的报文在网络中完全消逝避免复用相同四元组的新连接收到旧连接的残留报文。它必须等待2MSL报文最大生存时间的两倍这个时长在Linux上默认是60秒。如果线上出现TIME_WAIT过多导致端口耗尽通常发生在短连接场景下比如压测工具用短连接疯狂请求Nginx。解决办法有几个角度如果是在客户端可以开tcp_tw_reuse前提是连接是安全的出方向连接如果是服务端配合LVS/Nginx这类负载均衡尽量用长连接来降低连接建立频率同时调大本地端口范围net.ipv4.ip_local_port_range让更多的四元组可用。比TIME_WAIT更需要警惕的是CLOSE_WAIT它代表对端关闭了连接但本地应用没有调用close()去关闭对应的socket。这个问题跟内核参数没关系纯粹是应用代码漏关了socket。常见原因包括处理请求时抛异常没有走到close、将socket对象保存到集合里没有清理、或者用了连接池但没有及时检测失效连接。排查命令很简单netstat -ant | awk {print $6} | sort | uniq -c | sort -rn如果CLOSE_WAIT的数量持续增长且不下降基本可以确定是应用层泄漏而不是系统参数能救的。这种场景在笔试简答题里很常见答题时先说清楚状态含义再给排查命令最后给解决方案逻辑链完整就能拿高分。2.3 拥塞控制家族从Reno到BBR的演进逻辑拥塞控制的题在2018年这批卷子里也有而且考得更细比如“快重传和快恢复分别在什么场景下触发”“绘制TCP拥塞窗口随时间变化的曲线并标注事件”“RTO重传超时时间是怎么计算的”。这类题单靠背诵很难全对最好理解一遍演进逻辑。经典的Reno算法有四个阶段慢启动、拥塞避免、快重传、快恢复。慢启动阶段拥塞窗口从1个MSS开始每个RTT指数增长直到达到ssthresh进入拥塞避免后线性增长发生超时说明网络严重拥塞ssthresh降为当前窗口的一半窗口归1重新慢启动如果收到三个重复ACK说明还能收到数据网络可能只是轻微拥塞就进入快重传和快恢复ssthresh减半窗口直接降为ssthresh而不是归1。Reno的问题在于丢包后窗口减半的激进策略导致带宽利用率下降尤其是在高带宽高延迟的链路上。后来出现了CUBIC把窗口增长函数改成了三次函数适应高带宽长距离网络。再到BBR思路完全变了——它不再以丢包作为拥塞信号而是通过实时测量带宽和往返时延计算出最优发送速率。BBR在长肥网络上有明显优势笔试如果问“为什么BBR适合高RTT链路”你要能说出它摆脱了丢包即拥塞的旧假设。理解这段演进过程比死记硬背几个参数有意义得多也是我看完整批题后觉得性价比最高的复习区域。3. HTTP/DNS/HTTPS应用层那些必考的“常识”3.1 HTTP/1.1 Keep-Alive 到 HTTP/2多路复用的进化逻辑应用层协议里HTTP相关问题几乎是每张卷子的标配。2018年这个时间点HTTP/2已经普及了一段时间所以题里很自然会考到HTTP/1.1和HTTP/2的差异尤其是队头阻塞问题。HTTP/1.1引入了Keep-Alive机制解决了TCP连接每次请求都重新建立的问题但它的模型还是一个连接同一时刻只能处理一个请求后一个请求必须等前一个响应返回。如果前一个响应特别慢后面排队的请求全被卡住这就是HTTP层的队头阻塞。浏览器为了绕开这个限制只能对同一域名开多个并发连接一般6个左右但连接数总有上限治标不治本。HTTP/2的核心改进是引入了二进制分帧层。请求和数据被拆分成帧同一个TCP连接上可以同时传输多个stream每个stream承载一个请求响应。这样HTTP层不再需要排队多个请求可以交错传输。笔试常考的一个坑是HTTP/2解决了HTTP层的队头阻塞但TCP层的队头阻塞依然存在——因为TCP保证数据有序如果某个TCP段丢失了后续所有数据都要等它重传即使那些数据属于其他stream。直到HTTP/3改用基于UDP的QUIC协议才真正把传输层的队头阻塞也解决了。答题时要能把这个链条说清楚HTTP/1.1排队模型到HTTP/2多路复用再到HTTP/3脱离TCP的底层原因。这个过程本质上就是“应用层需求倒逼传输层变革”的活教材。做题时看到“HTTP/2真的彻底解决队头阻塞了吗”这种判断题心里有数就不会掉坑。3.2 HTTPS建连过程的常见计时题与考点HTTPS的握手题属于“算RTT”的经典题型。以TLS 1.2为例完整握手大概是这样的客户端先发ClientHello服务端回ServerHello、证书、密钥交换参数客户端再发自己的密钥交换参数和Finished服务端最后发Finished。加上底层的TCP三次握手总共需要2个RTT才能开始发HTTP数据TCP握手1个RTTTLS握手2个RTT加一起其实是3个RTT。笔试题经常给一个场景——“用户在4G网络下访问HTTPS页面RTT为50ms忽略处理时间从建立TCP连接到收到第一个HTTP响应需要多久”答案就是这个RTT的倍数。TLS 1.3把握手压缩到了1-RTT客户端用之前协商好的密钥直接发送应用数据并支持0-RTT模式会话恢复时客户端第一次发包就可以带业务数据所以如果题干里明确写了TLS 1.3计算方式就变了。连接建立之外HTTPS的性能优化还涉及会话复用Session ID/会话票据、OCSP装订、证书链优化等。笔试如果考到“如何降低HTTPS的建连耗时”几个方向要答全一是升级TLS 1.3减少握手RTT二是配置会话复用让老访客跳过完整握手三是用OCSP Stapling代替客户端自行查询证书吊销状态。这些都是可以在线上实际配置的手段。3.3 DNS流程与递归/迭代不只是“域名转IP”DNS的题在应用层题目里属于送分题但送分题也有人丢分。常见的考法是“描述浏览器输入www.baidu.com后发生什么”你要能分层次回答先查浏览器缓存再查本机hosts文件再查本地DNS解析器缓存然后向本地DNS服务器发起递归查询本地DNS服务器如果没有命中就会迭代地从根域名服务器查到顶级域名服务器再查到权威域名服务器拿到记录后返回给客户端。这里关键是理解递归和迭代的区别。主机到本地DNS服务器之间是递归查询本地DNS服务器代替客户端去一层层查而DNS服务器之间是迭代查询根服务器告诉它“你去问com服务器”com服务器告诉它“你去问baidu.com的权威服务器”。这个“踢皮球”的过程就是迭代。笔试里另一个高频考点是DNS用的是UDP 53端口但传输大响应时可能切换到TCP。排查域名解析慢的场景可以用dig命令看每一级的耗时重点看权威服务器的响应时间。如果本地DNS缓存了过期记录导致域名切换到新IP不生效还要理解DNS的TTL机制。这些知识放到现在依然实用尤其是依赖外部API的线上服务DNS问题常常是“服务偶发超时”的隐藏元凶。4. Linux网络编程从epoll到零拷贝网络研发的硬功夫4.1 select/poll/epoll三兄弟怎么选LT与ET的坑网络研发岗的笔试题里IO多路复用几乎必考而且通常以选择题的形式出现让你对比select、poll、epoll。下表是这类题的标准对比维度维度selectpollepoll最大连接数FD_SETSIZE限制通常1024无上限链表存储无上限红黑树就绪链表效率每次调用遍历全部fd集合每次调用遍历全部fd只返回就绪的fdO(就绪数)数据传递内核态和用户态之间拷贝整个fd集合同左利用mmap减少拷贝事件回调触发模式仅水平触发仅水平触发支持水平触发LT和边缘触发ET要特别注意LT和ET的区别这是真正区分有没有写过高性能网络服务的问题。水平触发是只要缓冲区有数据就持续通知边缘触发是只有状态发生变化从无到有才通知一次。ET模式下因为只通知一次你在read时必须用非阻塞IO循环读到返回EAGAIN为止否则剩下的数据就可能永远不再触发事件造成“卡死”。我见过好多人在理解这个点时翻车他们说“ET模式效率高”但让他手写一个epoll_wait循环时却忘了设置非阻塞flag。为什么说ET效率高是因为它在高并发下可以减少系统调用次数。LT模式如果某种极端场景下每次只读一个字节就绪事件会反复触发造成惊群和无效读。但ET模式对编写者要求更高事件处理必须一次处理干净不然就丢数据。笔试答题时把两种模式的坑说清楚比单纯背“epoll性能好”更让面试官印象深刻。4.2 数据包在内核里的完整旅程与零拷贝这个知识点经常以简答题的形式出现请描述一个数据包从网卡到达用户态进程的完整路径。看起来像八股但背后考察的是对Linux内核网络协议栈的理解。完整路径大概是网卡收到数据后通过DMA写入内存中的环形缓冲区ring buffer网卡触发中断通知CPU中断处理程序快速将数据帧加入软中断队列然后软中断处理NET_RX_SOFTIRQ调用协议栈函数。数据帧依次经过链路层判断以太网协议类型、网络层IP解析、路由查找、防火墙过滤、传输层TCP/UDP端口匹配、校验和验证、TCP状态机更新最后放入socket的接收队列。用户态进程通过系统调用read/recvfrom把数据从内核缓冲区拷贝到用户空间缓冲区。整个路径上最费劲的部分是数据从内核态到用户态的多余拷贝。传统的readwrite流程数据要经历“网卡DMA到内核buffer再从内核buffer拷贝到用户buffer再从用户buffer拷贝到socket发送buffer最后DMA拷贝到网卡”期间还伴随着多次用户态/内核态切换。零拷贝的思路就是想办法让数据尽量不经过用户态直接在内核态完成转发。比如sendfile数据从磁盘或内核buffer直接通过DMA引擎发到网卡全程不经过应用层的用户态缓冲区。mmapwrite的方式则是通过内存映射减少一次显式拷贝。笔试一旦考到这类题答题时把“DMA、内核态、用户态、上下文切换、拷贝次数”这几个词用好再画一个简单的路径图文字描述就行考试用纸笔画没问题基本就能拿满分。做网络研发岗这部分属于必修课因为nginx、kafka这些基础设施组件的高性能很大一部分就来自对零拷贝和事件驱动的极致使用。4.3 手写题方向线程安全LRU与一致性哈希编程题部分需要单独说。这一批题目的编程题不会太难出题人很清楚校招笔试时间有限要在短时间内写出的重点不是复杂的算法而是工程感。所以出现频率最高的是两类线程安全的LRU缓存和一致性哈希。线程安全LRU标准解法是哈希表加双向链表哈希表用来O(1)定位节点双向链表用来维护访问顺序。关键点有三个一是访问时要把节点移动到链表头部二是容量满时删除尾部节点三是加锁时尽量用细粒度锁而不是直接锁整个数据结构。下面是一个简化但完整的版本class LRUCache: def __init__(self, capacity: int): self.capacity capacity self.dict {} self.head Node(0, 0) self.tail Node(0, 0) self.head.next self.tail self.tail.prev self.head def get(self, key: int) - int: if key not in self.dict: return -1 node self.dict[key] self._move_to_head(node) return node.value def put(self, key: int, value: int) - None: if key in self.dict: node self.dict[key] node.value value self._move_to_head(node) else: node Node(key, value) self.dict[key] node self._add_to_head(node) if len(self.dict) self.capacity: tail self._pop_tail() del self.dict[tail.key]一致性哈希的编程题则更偏向设计类让你实现一个对节点增删友好的哈希环。核心点有三个哈希环、虚拟节点、顺时针查找。普通哈希取模在节点变化时会导致几乎所有key都重新映射而一致性哈希只影响环上该节点附近的key。虚拟节点是为了解决节点数量少时哈希环上的数据倾斜问题比如只有两台物理机时每台机器虚拟成200个虚拟节点都能均匀分布。我在笔试时看到这道题的思路是先说明为什么要用一致性哈希解决扩容缩容时的缓存雪崩问题再给一个支持虚拟节点和顺时针查找的版本最后说清楚复杂度——查找O(logN)可以用哈希表加排序虚拟节点环实现。写代码的时候注意处理环的边界条件也就是查找时要从hash(key)的位置在环上找第一个虚拟节点如果找到末尾都没有就回到环的起点。这个逻辑不复杂但比较容易在边界条件下漏写。5. 高性能架构与负载均衡核心网络研发的上层视野5.1 四层/七层负载均衡怎么选从LVS到Nginx当题目从单机网络编程上升到系统架构时最常见的考点就是负载均衡选型。四层负载均衡工作在传输层只认IP和端口不关心HTTP头代表是LVS七层负载均衡工作在应用层能解析协议内容做更精细的路由比如按URL转发、按Cookie保持会话、HTTPS卸载代表是Nginx和HAProxy。四层与七层的选择逻辑不是“谁更好”而是“谁更适合场景”。四层负载均衡的转发性能极高转发时基本不修改数据内容适合处理海量TCP/UDP接入层流量但它的灵活性差无法基于URL做业务路由。七层负载均衡可以做内容交换但吞吐量比四层低适合需要业务区分的场景。线上部署时往往是分层组合最外层用LVS/DPVS扛海量流量内层用Nginx做七层路由到具体服务。这种“四层先行、七层收尾”的架构考察的就是你对流量模型的判断能力。笔试有个容易被忽略的考点LVS的三种工作模式——NAT、DR直接路由、TUN隧道。DR模式下请求和响应都直接绕过了负载均衡器只在请求时修改MAC地址响应直接从RS返回给客户端所以性能最好NAT模式要双向经过LB容易成为瓶颈TUN模式将IP报文封装传送到远端RS适合物理分散的机房。答题能把DR模式下为什么响应不需要经过LB说清楚分数基本就拿到了。5.2 一致性哈希缓存和网关都必须懂的原理一致性哈希在第五部分的架构题里也经常串场。举个典型场景有一个Redis集群对某个key做读写时通常用hash(key) % 节点数来确定该key落在哪台机器。节点数一旦变化几乎全部key都会重新映射到新节点这对缓存服务来说是灾难——所有请求都会穿透到数据库造成缓存雪崩。一致性哈希的解决办法是把所有节点哈希到一个2^32的环上每个key也哈希到环上然后顺时针找到第一个大于等于该key哈希值的节点。节点变更时只有环上该节点逆时针方向的相邻区间里的key会受影响其他key的映射保持不变。为了防止节点少时数据倾斜还得加虚拟节点每台物理机在环上放多个位置。这与我在4.3里提到的一致性哈希编程题是同一个知识点只是从不同角度考一边是手写实现一边是架构场景分析。答题时如果能补充一个实际调优经验更好虚拟节点数量如何确定。太少解决不了倾斜太多占用内存我见过的实践是每台物理机200个左右的虚拟节点比较平衡当然也要看总节点数和key数量。这个数字是调出来的不是背出来的。5.3 连接管理与高并发下的常见坑连接管理是网络研发岗非常接地气的考点。这里的“连接”不只是TCP连接还包括HTTP连接池、数据库连接池、上游服务的长连接复用。笔试常问的一个问题就是为什么高并发短连接场景下性能上不去短连接每次请求都要走TCP三次握手和四次挥手每一次挥手都可能产生TIME_WAIT并且四次挥手的开销比三次握手翻了一倍。服务端如果每秒钟接收几千个短连接光是在内核里维护连接状态就已经消耗了大量CPU。解决方向包括客户端改用连接池复用服务端调大backlog和somaxconn参数限制半连接队列被塞爆。另外一个深坑是accept惊群——多个进程/线程同时阻塞在accept上有连接到达时多个进程都被唤醒但只有一个能accept成功其余全部空转。现在的解法是用SO_REUSEPORT结合多进程模型让每个进程独立监听同一个端口内核把连接均匀分发到各个进程或者在Nginx里用EPOLLEXCLUSIVE标志来减少唤醒竞争。这些点如果作为简答题答出两三个主流方案就能体现工程经验了。还有文件描述符耗尽的问题net.core.somaxconn、net.ipv4.tcp_max_syn_backlog、fs.file-max、ulimit -n这些参数之间的关系和适用场景也属于高频考点。对网络研发岗来说线上调优必备的命令——ss、netstat、sar、tcpdump——虽然笔试不一定会写但准备时如果自己动手抓包看过TCP握手失败后的重传序列做选择题和简答题时会更有把握。6. 在线笔试的实操经验与错题复盘6.1 限时做题的节奏控制与取舍在线笔试和面试最大的不同在于时间压力。我当时做这类试卷时给自己定的策略是这样的拿到题目先花两分钟浏览全部内容把题目按信心程度分成三个梯队。第一梯队是概念题比如TCP状态和HTTP状态码这部分务必在前20分钟内做完而且正确率要保底。第二梯队是计算题和简答题比如RTT计算、拥塞窗口画图、负载均衡选型分析每道题控制在5到8分钟写到要点就往下走不要追求把所有细节都铺满。第三梯队是两道编程题留出40分钟先写思路再写代码如果第一道题卡在某个边界条件超过10分钟立刻换第二道简单的先拿分。最忌讳的是在第一道编程题上死磕到结束。笔试里编程题的分值比例通常不会超过40%即使你把一道写出来了如果前面简答题大段空白总分依然不够用。遇到完全不会的简答题宁可写一句“这个问题的排查思路是先用ss观察连接状态再结合tcpdump看握手重传”这类半开放答案也比空着强。阅卷时能看到你的排查思维。6.2 几个我踩过的坑和习惯性错误我在刷2018年这批题时自己踩过几个比较典型的坑写出来给你们做个参考。第一个是TIME_WAIT的用途答反了。很多人只记得TIME_WAIT要多占用连接资源觉得它是“垃圾状态”实际上它是保证可靠关闭和防止旧报文串扰的机制。有一道题问“为什么TIME_WAIT要等待2MSL而不是一个固定的小数值”我一开始只知道背诵没有想清楚背后的两个原因。后来配合wireshark抓包观察了一下重传场景才真正把这个知识点锁死。第二个是epoll的ET模式居然忘了配非阻塞IO。笔试有一道选择题问“ET模式下read返回EAGAIN表示什么”我一开始选成了“连接已关闭”。好在后来刷题复盘看到了这个误区。ET模式下read返回EAGAIN意思是当前没有数据可读不代表EOF断连。EOF在read返回0时才能判定。这两个状态在生产代码里如果不注意很容易写出把正常空闲连接当成断开连接的bug。第三个坑是七层负载均衡不需要关心TCP层。其实七层负载均衡工作在应用层但它依然要建立TCP连接才能拿到请求内容而且它还面临与后端TCP断开时数据不一致的问题。Nginx做七层代理时如果开启了缓存对上游连接的管理也很讲究。这类题提醒我不能因为层数高就忽略传输层。6.3 为“核心网络研发”岗位做的准备清单如果一个月后要参加这个方向的校招笔试我会按这个顺序准备先过一遍《TCP/IP详解》里TCP状态机、超时重传、拥塞控制的章节这部分是选择题和简答题的基石然后看Linux网络编程相关的知识重点把select/poll/epoll的差异、LT/ET模式、socket选项这些必考清单拉一遍配合自己在Linux上用netstat、tcpdump命令做几次实验再刷一遍HTTPS握手、DNS解析、负载均衡选型这类应用层和架构层的高频题最后做几套完整的模拟卷掐时间练节奏重点练编程题在40分钟内的完成度。另外建议把线上故障排查的思路背熟遇到丢包、延迟、连接建立失败、连接异常断开、端口耗尽这五类问题分别用什么命令、看什么指标、预设哪些根因都能形成一套条件反射。这样即使笔试问一个你没见过的场景题也能从“看连接状态、抓包、看内核参数、查应用日志”的框架里找到切入点。网络研发岗考到最后考的其实就是一个人的排查思路——这一点在笔试和面试里都是一样的。我个人备考这套题时最深的体会是网络笔试考的不是记忆而是能不能在纸上把一条数据流的路径讲清楚。从网卡到协议栈从握手到挥手从一台机器的epoll再到一群机器的负载均衡每个环节都不是孤立的知识点。把这条主线串起来远远比单独背下来几十个参数有用得多。如果你也在准备这个方向建议别急着刷题先打开wireshark抓一个访问网页的包把三次握手和HTTP请求一行行对一遍再回头看这些题你会觉得它们全都变得亲切了。