1. 核心網(wǎng)絡研發(fā)考什么先看懂這張卷子的出題邏輯拿到“百度2018校招核心網(wǎng)絡研發(fā)工程師筆試題第三批”這個標題的時候我的第一反應是這屆題目應該挺硬核的。核心網(wǎng)絡研發(fā)工程師這個崗位在百度內(nèi)部對應的大多是基礎設施部門——負責數(shù)據(jù)中心網(wǎng)絡、骨干網(wǎng)、流量調(diào)度、自研網(wǎng)絡設備或者高性能網(wǎng)關這一類方向。和普通后端研發(fā)不一樣這個崗位的筆試題不會讓你寫業(yè)務接口也不會讓你做用戶表設計它考的是你對網(wǎng)絡協(xié)議棧、數(shù)據(jù)轉(zhuǎn)發(fā)路徑、路由控制平面和系統(tǒng)底層能力的綜合理解。我認識不少當年一起投這個崗位的朋友大家的反饋出奇一致這批題的區(qū)分度很高。高在哪里高在它不考死記硬背的協(xié)議細節(jié)而是考你“在一個真實網(wǎng)絡場景里能不能用協(xié)議知識做出正確判斷”。所以如果你打算投遞類似的崗位第一件事不是埋頭背OSI七層模型而是先把這張卷子的出題邏輯摸清楚。從我了解到的信息和多方比對來看第三批筆試題大致覆蓋了四個核心模塊。第一個模塊是網(wǎng)絡基礎與協(xié)議棧主要考察TCP/IP、HTTP、DNS這些日常最常接觸但又最容易被忽視的細節(jié)。第二個模塊是路由與交換技術重點在路由協(xié)議、轉(zhuǎn)發(fā)原理和網(wǎng)絡設計。第三個模塊是系統(tǒng)與編程能力畢竟核心網(wǎng)絡研發(fā)不是純網(wǎng)絡工程你得會寫代碼得理解操作系統(tǒng)底層。第四個模塊是數(shù)據(jù)中心網(wǎng)絡與SDN/NFV相關的前沿技術百度在自研網(wǎng)絡設備、SDN控制器和流量調(diào)度系統(tǒng)上投入很大筆試必然會對這個方向有所傾斜。理解了這張卷子的整體結構你再去看題就不會慌。它其實是在篩選兩類人一類是網(wǎng)絡底子扎實、遇到問題能追到報文級別的工程師另一類是系統(tǒng)能力強、能在高性能網(wǎng)絡場景里寫出可靠代碼的工程師。如果你兩項都占那這張卷子對你來說就是友好且能拉開差距的。2. TCP/IP協(xié)議棧高頻題細節(jié)決定你能不能進下一輪TCP/IP協(xié)議棧是核心網(wǎng)絡研發(fā)崗位的“吃飯本事”這部分題目的特點是看起來簡單一做就錯。我梳理了幾個在第三批題目里出現(xiàn)頻率較高的考點每一個都值得你重新過一遍。2.1 三次握手的邊界條件第三次ACK丟了會怎樣這幾乎是必考題但大多數(shù)人的答案最多得一半分。很多人只記得“客戶端進入ESTABLISHED服務端收不到ACK會重傳SYNACK”但真正值錢的細節(jié)在于如果客戶端在第三次握手ACK發(fā)出后立刻發(fā)送數(shù)據(jù)包服務端在SYN_RCVD狀態(tài)下收到這個數(shù)據(jù)包會怎么處理正確的鏈路是服務端在SYN_RCVD狀態(tài)收到客戶端的數(shù)據(jù)包時如果該數(shù)據(jù)包不帶ACK標志那么根據(jù)RFC 793服務端會把這個數(shù)據(jù)包丟棄并重新發(fā)送SYNACK。但如果這個數(shù)據(jù)包攜帶了ACK標志哪怕它不是純粹的ACK包服務端也會認為握手已經(jīng)完成把狀態(tài)切換為ESTABLISHED同時處理數(shù)據(jù)。這個細節(jié)考的是你對TCP狀態(tài)機和報文交互的理解深度而不僅僅是背一個三次握手流程。還有一個變體如果客戶端的第三次ACK在網(wǎng)絡上延遲了很久才到達服務端在此期間已經(jīng)因為重傳超時關閉了連接那這個遲到的ACK到了之后服務端會回一個RST。這個RST會導致客戶端從ESTABLISHED狀態(tài)直接跳到CLOSED。這種場景在處理高并發(fā)短連接服務時非常常見尤其是客戶端連接池需要大量新建連接時。2.2 擁塞控制的演進別只停留在Reno和CUBIC2018年的校招題已經(jīng)明顯開始考察BBR了。百度這樣的體量帶寬利用率哪怕提升1%節(jié)省的成本都是天量級的所以擁塞控制算法是核心網(wǎng)絡團隊的重點研究方向。題目通常這樣出解釋Reno、CUBIC和BBR在擁塞窗口調(diào)整上的核心差異以及在什么網(wǎng)絡場景下BBR能比CUBIC獲得更好的吞吐。CUBIC是BDP探測型的它通過三次曲線來探測帶寬遇到丟包會乘性減窗。BBR換了一套思路它不再以丟包作為擁塞信號而是通過實時測量最小RTT和最大帶寬來建模網(wǎng)絡管道然后用pacing的方式讓發(fā)送速率貼合帶寬。這里有一個關鍵點值得展開BBR的ProbeRTT階段會周期性把擁塞窗口降到4個MSS目的是重新測量最小RTT。因為路徑上的排隊延遲會隨時間變化如果一直保持一個很大的發(fā)送速率RTT會虛高。這個“故意降速重新測量”的操作和傳統(tǒng)算法“發(fā)送速率越高越好”的直覺完全相反但恰恰是BBR能夠在高丟包鏈路上保持高吞吐的原因。答題時如果能把這個機制解釋清楚面試官對你的評價會直線上升。2.3 HTTP隊頭阻塞從HTTP/1.1到HTTP/2再到HTTP/3這批題里HTTP相關的題目卡了不少人原因在于它考的已經(jīng)超出了“GET和POST的區(qū)別”這個level而是直接問你HTTP/2解決了HTTP/1.1的隊頭阻塞為什么還會出現(xiàn)隊頭阻塞HTTP/1.1的隊頭阻塞發(fā)生在應用層一個TCP連接上只能串行處理請求前面的響應慢了后面的請求全部排隊。HTTP/2引入了多路復用通過stream在一條TCP連接上并發(fā)傳輸多個請求看起來解決了問題。但HTTP/2的底層仍然是TCPTCP保證有序傳輸?shù)臋C制導致如果某個stream的包丟了后續(xù)所有stream的包都不能被應用層處理必須等待重傳。這就是TCP層的隊頭阻塞HTTP/2解決不了。真正的解法是HTTP/3它把傳輸層換成了QUIC基于UDP實現(xiàn)可靠傳輸每個stream獨立有序丟包只影響它自己所在的stream。這個問題在核心網(wǎng)絡研發(fā)面試里幾乎是必問的因為它考察的不是你用過多少HTTP庫而是你對分層模型和傳輸機制之間交互關系的深入理解。3. 路由與轉(zhuǎn)發(fā)題從CIDR聚合到BGP路徑選擇的計算邏輯路由與轉(zhuǎn)發(fā)是核心網(wǎng)絡研發(fā)的“物理基礎”這部分題目通常不是簡單的概念問答而是需要實際計算的。第三批題目里計算題的占比不低而且計算量都不大但思路要清晰。3.1 路由聚合的邊界不是所有地址都能老老實實聚合有一道經(jīng)典題目是這樣的有四個網(wǎng)段192.168.1.0/24、192.168.2.0/24、192.168.3.0/24、192.168.4.0/24要求寫出能覆蓋前三個網(wǎng)段的最小聚合路由以及能覆蓋四個網(wǎng)段的最少路由條目數(shù)。前三個網(wǎng)段聚合很簡單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位相同。如果你強行聚合四個網(wǎng)段得到的是192.168.0.0/20這個路由會覆蓋192.168.0.0到192.168.15.255多覆蓋了12個網(wǎng)段在實際網(wǎng)絡中可能造成路由黑洞或流量被錯誤轉(zhuǎn)發(fā)。所以正確答案是兩條路由192.168.0.0/22和192.168.4.0/24它們才能精確覆蓋四個網(wǎng)段。這個題目的價值不在于計算本身而在于考察你是否明白一個道理路由聚合必須“精確”寧可多一條路由也不能讓聚合后的路由覆蓋到不存在的網(wǎng)段。3.2 OSPF與BGP協(xié)作角色不同路徑選擇邏輯不同另一道?？加嬎泐}是路由優(yōu)先級和選路規(guī)則的混合場景。題目會給你一個網(wǎng)絡拓撲一臺路由器同時運行OSPF和BGPOSPF學習到一條到達目標網(wǎng)段的路徑cost為110BGP學習到同一條路徑local_pref為200MED為50。問你最終優(yōu)選哪條路徑。在華為、思科設備上不同協(xié)議之間比較的是路由優(yōu)先級華為叫preference思科叫administrative distance。OSPF內(nèi)部路由的優(yōu)先級通常是10BGP是255思科eBGP是20iBGP是200。但很多時候題目會故意省略這些默認值而是把比較邏輯放在同一個協(xié)議內(nèi)部。如果是BGP內(nèi)部比較local_pref優(yōu)先然后才是AS路徑長度、MED等。這里真正的考點是跨協(xié)議比的是優(yōu)先級同協(xié)議內(nèi)部才比選路屬性。很多考生把這兩個規(guī)則混在一起結果得出完全相反的答案。題目里還會附帶一個“為什么BGP要有這么多選路屬性”的加分題。這個問題的本質(zhì)是IGPOSPF、IS-IS在同一個AS內(nèi)部已經(jīng)能算出最短路徑了但AS之間的運營商有復雜的商業(yè)關系客戶、上游、對等需要一套可策略化控制的選路機制來體現(xiàn)這些商業(yè)決策。理解了這層邏輯你就懂了為什么BGP的選路規(guī)則不是單純的技術最優(yōu)而是商業(yè)策略驅(qū)動的。3.3 轉(zhuǎn)發(fā)面的最長前綴匹配硬件層面的核心邏輯路由與轉(zhuǎn)發(fā)的計算題有時候也會往硬件方向延伸比如問TCAM如何實現(xiàn)最長前綴匹配。TCAM三態(tài)內(nèi)容尋址存儲器的每個bit都有三個狀態(tài)0、1、X不關心所以它天然適合存儲路由前綴。要匹配時所有表項同時參與比較命中的條目里優(yōu)先級最高的就是最長匹配的那個。這里有一個補充考點因為TCAM貴且功耗高但路由表越來越大所以業(yè)界會有“把路由分級把常用前綴放到DRAM里用算法匹配不常用的才放TCAM”這類思路。這些內(nèi)容在筆試里考得少但如果你面試時能主動提出來會讓面試官覺得你有工程視野。4. 高性能網(wǎng)絡與系統(tǒng)底層DPDK、零拷貝和網(wǎng)卡多隊列的實戰(zhàn)理解核心網(wǎng)絡研發(fā)工程師的工作場景里有相當一部分是高性能網(wǎng)絡轉(zhuǎn)發(fā)比如百度自研的四層負載均衡、流量網(wǎng)關、緩存加速代理等這些系統(tǒng)的核心就是處理海量并發(fā)報文。所以筆試里出現(xiàn)系統(tǒng)與性能類題目一點都不意外。4.1 內(nèi)核協(xié)議棧的瓶頸和DPDK為什么能繞過去題目常常這樣出一臺普通的x86服務器跑Linux內(nèi)核協(xié)議棧處理64字節(jié)小包轉(zhuǎn)發(fā)性能通常只能到幾十萬PPS想提升到千萬PPS甚至更高需要怎么做答案的核心就是“繞過內(nèi)核”或“優(yōu)化內(nèi)核收包路徑”。展開來說內(nèi)核協(xié)議棧的瓶頸有三個。第一系統(tǒng)調(diào)用開銷每個包都要經(jīng)過recvfrom/sendto或read/write用戶態(tài)和內(nèi)核態(tài)頻繁切換。第二數(shù)據(jù)拷貝包從網(wǎng)卡緩沖區(qū)拷貝到內(nèi)核內(nèi)存再從內(nèi)核內(nèi)存拷貝到應用緩沖區(qū)多一次訪存開銷。第三內(nèi)核鎖競爭多核CPU同時處理網(wǎng)絡包時協(xié)議棧里的全局鎖和共享數(shù)據(jù)結構會形成爭搶。DPDK的處理思路是通過UIOUserspace I/O把網(wǎng)卡設備映射到用戶態(tài)用輪詢模式PMD替代中斷通知應用程序直接通過大頁內(nèi)存與網(wǎng)卡交換描述符繞過內(nèi)核協(xié)議棧。這個方案能把單核收包性能從幾十萬PPS提升到上百萬PPS級別在業(yè)界已經(jīng)是非常成熟的實踐。答題時如果能提到“大頁內(nèi)存減少TLB miss”這一層說明你真的看過代碼而不是只背了概念。4.2 零拷貝的幾種實現(xiàn)mmap、sendfile和網(wǎng)卡分片零拷貝是高性能網(wǎng)絡服務里繞不開的話題。題目通常給你一個文件下載服務的場景問你如何減少數(shù)據(jù)在用戶態(tài)和內(nèi)核態(tài)之間的拷貝次數(shù)。傳統(tǒng)方式要經(jīng)歷磁盤到內(nèi)核緩沖區(qū)內(nèi)核到用戶緩沖區(qū)用戶到socket緩沖區(qū)socket緩沖區(qū)到網(wǎng)卡一共四次拷貝四次上下文切換。用sendfile可以達到兩次拷貝用DMA直接內(nèi)存訪問配合網(wǎng)卡Scatter-Gather功能可以做到真正意義上的“零拷貝”——數(shù)據(jù)從磁盤到頁緩存后通過DMA引擎直接描述符指向頁緩存中的數(shù)據(jù)不經(jīng)過CPU拷貝直接發(fā)送到網(wǎng)卡。這里有個細節(jié)很多人會忽略零拷貝的瓶頸不再在CPU拷貝上而是轉(zhuǎn)移到了頁緩存和socket緩沖區(qū)之間的一致性維護上如果頻繁讀寫可能觸發(fā)page fault反而性能下降。實測下來對小文件高并發(fā)的場景用sendfile不一定比精心調(diào)優(yōu)的傳統(tǒng)readwrite快因為DMA描述符的建立和拆除也有開銷。這個反直覺的結論如果在筆試的論述題里寫出來會很加分。4.3 網(wǎng)卡多隊列與RSS讓每個CPU核心都有活干另一個常見考點是網(wǎng)卡多隊列和Receive Side ScalingRSS。單隊列網(wǎng)卡在接收報文時需要靠一個中斷來處理所有包多核CPU無法分攤收包壓力。啟用多隊列后網(wǎng)卡可以根據(jù)四元組或五元組哈希把不同的流分散到不同的RX隊列每個隊列由獨立的CPU核心處理這樣就能并行收包。題目會問RSS的哈希因子有哪些如果哈希因子包含源IP和目的IP來自同一個IP的不同端口連接會被分到多個隊列嗎答案是如果哈希計算包含端口那會分散到不同隊列但如果只基于IP那同一對IP的流會固定在同一個隊列可能在某些負載均衡場景下造成隊頭熱點。這個問題的價值在于它讓你意識到看似“自動分散”的網(wǎng)卡哈希如果不和實際業(yè)務流特征匹配反而會成為性能瓶頸。5. 數(shù)據(jù)中心網(wǎng)絡與SDN/NFV從VXLAN到控制器設計的必考題百度在數(shù)據(jù)中心網(wǎng)絡方向的布局很早從自研交換機、SDN控制器到流量調(diào)度系統(tǒng)都有成熟的落地。這批筆試題里出現(xiàn)數(shù)據(jù)中心相關題目非常合理也代表著國內(nèi)頭部互聯(lián)網(wǎng)公司對這個方向的重視程度。5.1 VXLAN封裝細節(jié)外層UDP的源端口到底怎么選VXLAN幾乎是數(shù)據(jù)中心網(wǎng)絡必考項。題目通常會給你一個虛擬機遷移的場景虛擬機從物理機A遷移到物理機B但IP地址保持不變對端如何通過VXLAN隧道繼續(xù)訪問它VXLAN把二層幀封裝在UDP報文里VTEPVXLAN Tunnel Endpoint負責封裝和解封裝。關鍵點在于外層UDP的源端口它是根據(jù)內(nèi)層MAC、IP、端口等信息哈希計算出來的目的端口固定是4789IANA分配的端口。源端口設計成哈希值的目的是為了在底層網(wǎng)絡上實現(xiàn)負載均衡——ECMP等價多路徑協(xié)議可以根據(jù)外層五元組把流量打散到不同的物理鏈路上。如果不做這個哈希所有VXLAN流量在底層看來都走同一個五元組ECMP會把所有流量都壓到一條鏈路上這就是經(jīng)典的“Hash極化”問題。答題時如果能把這個設計意圖講清楚就不僅僅是答了一道題而是在展示你理解了VXLAN“為什么這么設計”的工程智慧。5.2 SDN控制器集中式優(yōu)于分布式但沒有全局看到底行不行SDN相關題目在第三批里也有一席之地。常見問法是SDN控制器的核心職責是什么為什么數(shù)據(jù)中心網(wǎng)絡要用SDN做流量調(diào)度而不是傳統(tǒng)的分布式路由協(xié)議SDN把網(wǎng)絡控制平面和數(shù)據(jù)轉(zhuǎn)發(fā)平面分離控制器掌握全局拓撲可以用全局視角計算最優(yōu)路徑下發(fā)流表到交換機。相比之下傳統(tǒng)路由協(xié)議是分而治之的每臺設備只知道自己的鄰居關系無法感知全局擁塞情況。數(shù)據(jù)中心網(wǎng)絡流量模型極其復雜流量矩陣動態(tài)變化集中式控制器可以根據(jù)實時負載做全局優(yōu)化。但集中式控制器也帶來可靠性問題——控制器掛了整個網(wǎng)絡的路徑計算就癱瘓了所以實際工程中控制器通常以集群方式部署用分布式數(shù)據(jù)庫同步網(wǎng)絡狀態(tài)。這里有一個容易踩坑的認知很多人以為SDN就是OpenFlow的代名詞但實際工程中OpenFlow只是SDN南向接口的一種實現(xiàn)方式。百度早期的SDN方案里也大量使用了自研的南向協(xié)議或者通過BGP、NETCONF等“傳統(tǒng)”協(xié)議實現(xiàn)控制器的集中控制。SDN的本質(zhì)是“控制與轉(zhuǎn)發(fā)分離”這個思想而不是某一種具體協(xié)議?；卮饡r點出這層才能體現(xiàn)出工程視野。5.3 CLOS架構與ECMP現(xiàn)代數(shù)據(jù)中心網(wǎng)絡的骨架數(shù)據(jù)中心網(wǎng)絡設計題通常圍繞CLOS架構展開。CLOS解決的是“大二層網(wǎng)絡如何擴展”的問題核心層Spine和接入層Leaf之間通過ECMP形成等價多路徑所有Leaf都能通過多條路徑到達任何其他Leaf帶寬可水平擴展。題目會問為什么CLOS架構比傳統(tǒng)三層樹形架構更適合數(shù)據(jù)中心核心原因有兩個。第一樹形架構的匯聚層是瓶頸流量越高匯聚層設備壓力越大而且難以水平擴展。第二CLOS架構下所有路徑都是等價的通過ECMP實現(xiàn)負載均衡鏈路利用率高故障轉(zhuǎn)移也快——一條鏈路斷了流量立刻均勻分攤到其他等價路徑上。這個題目還有一個衍生問法ECMP的哈希因子和前面VXLAN的哈希源端口設計有什么關聯(lián)對的VXLAN外層UDP源端口哈希就是為了解決ECMP哈希極化問題兩道題是一套組合拳。你如果能把它們串起來回答面試官會知道你是真的理解而不是背概念。6. 編程與系統(tǒng)實現(xiàn)題網(wǎng)絡工程師的代碼功底不能拉胯核心網(wǎng)絡研發(fā)工程師的日常不是天天調(diào)路由器而是寫代碼——寫網(wǎng)關、寫轉(zhuǎn)發(fā)面、寫控制面組件、寫網(wǎng)絡監(jiān)控系統(tǒng)。所以卷子里一定有代碼題和系統(tǒng)設計題這些題目的水平和難度和純后端崗位的題風格截然不同。6.1 C語言的字節(jié)序與內(nèi)存對齊最容易栽跟頭的地方第一類高頻題是C語言和操作系統(tǒng)底層細節(jié)。字節(jié)序問題是網(wǎng)絡編程的經(jīng)典陷阱x86機器是小端序網(wǎng)絡字節(jié)序是大端序用htonl/ntohl轉(zhuǎn)換。但如果處理的是一個結構體——比如一個自定義報頭里面有uint8_t、uint16_t、uint32_t混合字段直接強制類型轉(zhuǎn)換再發(fā)送就會因為內(nèi)存對齊產(chǎn)生填充字節(jié)導致接收端解析出錯。正確的做法是用packed結構體__attribute__((packed))或者每個字段單獨序列化。筆試里可能會給你一段代碼問你這個結構體在64位系統(tǒng)上會占用多少字節(jié)如果加了packed又是多少字節(jié)。這種題考察的是你寫網(wǎng)絡協(xié)議代碼時能否處理字節(jié)序和內(nèi)存布局問題這在高性能網(wǎng)絡開發(fā)里非常常見坑很深。6.2 生產(chǎn)者消費者模型從互斥鎖到無鎖隊列的設計取舍題目會給你一個場景多個生產(chǎn)者線程把網(wǎng)絡數(shù)據(jù)包寫入隊列多個消費者線程從隊列中取包處理如何設計這個隊列第一層答案是互斥鎖加條件變量這是教科書方案。第二層答案是讀寫鎖、自旋鎖的取舍在臨界區(qū)極小的情況下自旋鎖比互斥鎖更合適因為它避免陷入內(nèi)核態(tài)。第三層答案才是面試官真正想聽的無鎖隊列。用CASCompare-And-Swap實現(xiàn)lock-free的MPMC隊列或者更務實的SPSC隊列——單生產(chǎn)者單消費者隊列通過ring buffer就能實現(xiàn)無鎖這在DPDK的rte_ring里就是經(jīng)典實現(xiàn)。這里有一個關鍵取舍無鎖隊列在讀多寫少、臨界區(qū)極短的高并發(fā)場景下性能優(yōu)勢巨大但無鎖不等于無坑ABA問題、內(nèi)存序問題memory ordering都可能導致詭異bug。所以筆試答題時最好能說明白什么場景選什么隊列以及為什么而不是一味追求花哨的無鎖實現(xiàn)。6.3 多線程并發(fā)中的原子操作與內(nèi)存屏障再往后有一類題圍繞多線程同步的正確性展開兩個線程一個寫一個讀都操作同一個變量如何保證讀到的一定是最新值答案是volatile?錯。在C/C里volatile只能告訴編譯器不要優(yōu)化不能保證多核間的可見性也不提供原子性。正確做法是用C11的atomic、std::mutex或者提供內(nèi)存屏障的原子操作。進一步會問為什么CPU會亂序執(zhí)行為什么需要內(nèi)存屏障現(xiàn)代CPU為了性能會進行指令重排多核之間還有緩存一致性協(xié)議比如MESI帶來的偽共享問題。cache line是64字節(jié)如果兩個線程頻繁修改同一cache line上不同變量會因為偽共享導致性能雪崩。用__attribute__((aligned(64)))把變量對齊到cache line邊界可以規(guī)避這個問題。這類題考的是你對系統(tǒng)底層的理解一個合格的核心網(wǎng)絡研發(fā)工程師必須能寫出“確定性強”的高并發(fā)代碼。7. 綜合設計題實戰(zhàn)模擬從零設計一個高可用四層接入網(wǎng)關網(wǎng)絡方向的綜合設計題通常是卷子的壓軸大題分值高、難度大。它往往不以“寫代碼”的形式出現(xiàn)而是要求你畫架構圖、說清楚關鍵模塊和容災方案。這里我結合網(wǎng)絡上找到的類似題型和崗位要求還原了一道比較有代表性的設計題并附上完整的解題思路筆試面試都能用得上。題目大意公司需要設計一個高可用的四層接入網(wǎng)關承接所有外部流量并轉(zhuǎn)發(fā)到后端服務集群要求支撐10萬QPS、可用性99.99%請設計整體架構并說明關鍵設計點。這道題想拿高分需要從四個層面去回答。第一層是整體架構接入網(wǎng)關采用集群部署多臺機器通過ECMP等價路由對外提供服務使用BGP與上層交換機互通任何一臺機器故障流量自動被ECMP重新哈希到其他機器。在網(wǎng)關機器內(nèi)部使用DPDK接管網(wǎng)卡業(yè)務邏輯全部在用戶態(tài)實現(xiàn)。四層轉(zhuǎn)發(fā)不做太多復雜邏輯只做DNAT和SNAT所以可以做到很高吞吐。第二層是會話一致性四層網(wǎng)關必須保證同一個客戶端的連接五元組始終落在同一臺后端機器上否則TCP連接會斷開。用一致性哈希表保存會話狀態(tài)會話表需要定期同步或者將狀態(tài)存到分布式KV里保證故障切換時會話不丟。但分布式KV帶來的延遲在數(shù)據(jù)路徑上不可接受所以實踐中會在每臺機器本地保存會話表配合主備同步極少數(shù)情況下故障會導致連接重建這是99.99%可用性可以容忍的。第三層是健康檢查與故障剔除網(wǎng)關需要定期探測后端服務的健康狀態(tài)探測失敗要自動摘除該后端并重新建立會話同時不能影響現(xiàn)有連接。這里要考慮“探活頻率”和“誤判”之間的權衡探得太頻繁會對后端產(chǎn)生額外壓力探得太慢故障轉(zhuǎn)移時間過長。一般會設計成TCP連接探測和HTTP探測的雙層機制。第四層是安全與防洪作為公網(wǎng)入口網(wǎng)關必須能抵抗SYN Flood。解法是開啟SYN Cookie或者用硬件卸載卡做DDoS清洗只有通過驗證的流量才進入內(nèi)核態(tài)處理。這個問題在百度真實場景里是繞不開的所以出現(xiàn)在筆試里非常合理。這道題的完整回答至少要涵蓋ECMP接入、DPDK轉(zhuǎn)發(fā)、會話一致性、健康檢查、故障轉(zhuǎn)移、DDoS防護、安全隔離、監(jiān)控和日志統(tǒng)計這幾個模塊答得越全越接近核心網(wǎng)絡研發(fā)工程師的真實工作畫像。8. 備考與答題策略筆試里的時間管理同樣決定成敗最后聊點實際的這部分是我和幾個參加過百度校招的朋友交流后總結出的經(jīng)驗不一定寫在任何帖子里的但非常關鍵。8.1 時間分配和答題順序這套筆試題給人的體感是“時間不夠”。我有朋友當年在這套題上有些題目只能留空白原因不是不會做而是前面在二叉樹、哈希表這類基本功題目上花了太久后面的大題反而沒時間展開。我個人的建議是先做綜合設計題和論述題再做計算題最后做選擇題和填空題。為什么綜合設計題是開放性的只要你框架清晰、要點齊全即使細節(jié)不夠完美也能拿到大部分分數(shù)。計算題如果思路錯了可能什么都得不到但如果是列了步驟但算錯結果通常還能拿到過程分。選擇填空是純客觀題一題就一兩分占比不大放在最后反而不會心慌。8.2 答題時的表述技巧請用“工程師的語言”而非“課本的術語”筆試答題尤其是簡答和設計題極其看表述方式。舉個例子同樣的意思“TCP的擁塞窗口會減小”和“窗口大小根據(jù)當前鏈路的RTT和丟包率動態(tài)調(diào)整丟包時進入擁塞避免階段通過乘性減窗降低發(fā)送速率以緩解鏈路擁塞”給閱卷人的專業(yè)程度印象完全不同。再一個細節(jié)設計題里圖要畫關鍵模塊的名稱要寫清楚接口要標注箭頭方向不要只寫一堆文字。閱卷人和面試官都偏好“能一眼看到架構全貌”的答案。畫圖不需要多精美但核心鏈路和容災鏈路必須用不同顏色或線型區(qū)分開。8.3 結合個人經(jīng)驗談談這套題的復習方向如果你正打算投遞核心網(wǎng)絡研發(fā)崗我建議你按照“基礎協(xié)議棧-路由交換-高性能轉(zhuǎn)發(fā)-數(shù)據(jù)中心網(wǎng)絡-SDN/NVF-系統(tǒng)編程”的順序系統(tǒng)復習。但要注意不要停留在背概念每學一個協(xié)議問自己三個問題——它解決什么問題、它的報文格式里每個字段為什么存在、它在真實網(wǎng)絡里有哪些常見的坑。把這三個問題想清楚無論是筆試還是面試你都能對答如流。我當年復習TCP時用一個笨方法用Wireshark抓自己機器上瀏覽網(wǎng)頁的包跟著TCP流看三次握手、窗口變化、重傳超時再對照RFC看報文頭。這個過程看起來慢但對建立“報文級直覺”特別有效。筆試里有些題是“紙上談兵”考不出來的但你如果見過真實的報文交互一眼就能看穿考點在哪里。9. 寫在最后幾個容易被忽略但考試高頻的“邊角料”這些內(nèi)容我在前面沒有具體展開但它們出現(xiàn)的概率極高而且一旦考到如果沒看過就是完全空白所以我單獨拉出來講一下。9.1 DNS解析細節(jié)遞歸、迭代與緩存TTL的坑DNS相關題目在網(wǎng)絡崗筆試里很少缺席。常見問法是用戶在瀏覽器輸入一個域名完整解析過程是怎樣的這里要答清遞歸查詢和迭代查詢的區(qū)別、本地hosts文件、系統(tǒng)resolver、客戶端本地DNS緩存、運營商LocalDNS、根服務器、頂級域服務器、權威服務器以及每個環(huán)節(jié)的緩存TTL機制。有意思的考點是TTL過短會導致DNS查詢爆量TTL過長會導致域名切IP后客戶端不生效。2018年前后正是各家互聯(lián)網(wǎng)大廠開始大規(guī)模使用HTTPDNS的年代原理就是繞過運營商LocalDNS避免被劫持和調(diào)度不精準所以題目也有概率延展到HTTPDNS的優(yōu)缺點——相比傳統(tǒng)DNSHTTPDNS是應用層通過HTTP接口直接拿到IP列表避免中間環(huán)節(jié)的污染和緩存問題但需要客戶端SDK配合。這題考的是你對“域名解析鏈路”的完整理解。9.2 BGP路由振蕩正則表達式和route-map實際怎么用BGP的題目有時候會出一些實操向的給出幾條BGP路由填寫正則表達式匹配特定前綴或者設計route-map完成基于AS路徑的選路控制。這類題要求你真用過BGP知道AS_PATH里各種字符的含義。正則表達式里有一個坑^192_和_192_的區(qū)別。前者匹配的是以192開頭的AS路徑后者匹配路徑中包含192的任意位置。如果只是求包含某個AS號的所有路由用后者如果限定起源AS用前者。這種題目答案很明確但很多沒實操經(jīng)驗的人會混淆。我建議備考時在模擬器里建一個BGP環(huán)境手動配幾條route-map把正則表達式和過濾邏輯親手跑幾遍記憶會牢固很多。9.3 網(wǎng)絡質(zhì)量觀測RTT、抖動、丟包率到可用性的推導關系最后一類容易被忽略的題目是網(wǎng)絡質(zhì)量觀測類。它會給你一組數(shù)據(jù)某條鏈路的RTT是20ms抖動5ms丟包率0.1%問這條鏈路的可用性是多少這里“可用性”的定義不是簡單的1減去丟包率而是要看業(yè)務模型。比如嚴格依賴TCP傳輸?shù)臉I(yè)務0.1%的丟包率會導致大量TCP重傳和擁塞窗口退化實際吞吐可能下降超過5%可用性遠低于99.9%。這個問題的深層考點是網(wǎng)絡質(zhì)量指標不能只看單個值需要結合協(xié)議行為和應用場景做聯(lián)合分析。核心網(wǎng)絡研發(fā)工程師在真實工作中就是干這個的——接報警、看指標、定位鏈路瓶頸、優(yōu)化轉(zhuǎn)發(fā)路徑每一步都需要這套分析能力。我把這些“邊角料”單獨拎出來是因為它們在我的經(jīng)驗里恰恰是拉開分差的地方?；A題大家都會協(xié)議細節(jié)背一背也能過關但能把DNS解析、BGP實操、鏈路質(zhì)量分析這些細碎知識融會貫通的人才是真正適合核心網(wǎng)絡研發(fā)崗位的人。這套筆試的第三批題目本質(zhì)上就是在篩選這批人。