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實操、鏈路質量分析這些細碎知識融會貫通的人才是真正適合核心網絡研發崗位的人。這套筆試的第三批題目本質上就是在篩選這批人。