講真看到“百度2019校招核心網絡研發工程師筆試題第三批”這個標題我第一反應是——又到了每年被網絡基礎虐一遍的時候了。這個崗位和普通后端不一樣它面向的是百度整個網絡基礎設施從接入層到IDC互聯從四層負載均衡到DNS調度全都在覆蓋范圍內。所以筆試題不是簡單問“TCP三次握手幾次”而是會把協議細節、實現機制、Linux內核行為串起來考。這篇內容我按當年這批題的風格結合我自己復習和帶人時的經驗把題型、考點、解題思路、易錯點一塊兒拆開講。不管你是準備校招還是工作幾年想回頭補基礎都能從中找到值得琢磨的東西。1. 題型全貌與考察邏輯1.1 這張卷子到底在考什么先看整體結構。核心網絡研發工程師的筆試題一般分四個部分計算機網絡基礎、系統與Linux網絡棧、編程與算法、綜合設計與排查。第三批的題目分布也遵循這個框架但有幾個明顯特點。基礎題部分重心放在TCP/IP協議棧尤其TCP的狀態機、擁塞控制、超時重傳這些細節。OSI七層模型這種送分題很少更多是“數據包從A到B經過哪些設備、每一層改了哪些字段”這種鏈路型問題。系統題部分考察Linux內核網絡參數比如半連接隊列、全連接隊列的調優epoll的邊緣觸發與水平觸發區別syncookies的工作原理。這些不是問概念而是給一個實際故障現象讓你反推是哪個參數或哪段邏輯出了問題。編程題部分一般是一道中等偏上的算法題加一道網絡相關的模擬/實現題。算法題不偏但網絡模擬題很有意思比如“實現一個滑動窗口流量控制”或“解析TCP選項字段”既考代碼能力又考協議理解。綜合設計題是拉開差距的關鍵。題目會給出一個具體場景比如“百度首頁從輸入URL到頁面渲染中間經過哪些網絡組件各自的作用是什么”或者“設計一個跨地域的流量調度系統要考慮哪些因素”。這類題沒有標準答案但能給出一套邏輯閉環的方案的候選人很少。1.2 為什么百度網絡崗要這么考說點題外的理解。網絡研發這個崗位在百度內部負責的東西非常底層和關鍵。搜索、Feed、AI服務全跑在這套網絡基礎設施上。一旦網絡出問題不是某個接口超時而是大規模服務不可用。所以筆試必須篩出兩類人一類是基礎扎實、能應對故障排查的人另一類是系統思維強、能設計大規模網絡架構的人。這也解釋了為什么題目會圍繞TCP細節、Linux內核、流量調度來出。這些不是課本上的死知識而是日常工作中真正要打交道的東西。比如BGP路由設計、ECMP負載均衡、DCI數據中心互聯帶寬調度每一塊都需要把協議原理和工程實踐結合起來。所以備考時別只背“三次握手、四次揮手”要往深一層想為什么要這樣設計如果某個環節出問題會有什么現象怎么用工具去驗證這套思維方式才是筆試真正想考察的。2. 核心細節解析與實操要點2.1 TCP狀態機必考但容易翻車TCP狀態機幾乎是必考題但大多數人只背了三次握手和四次揮手的流程一碰到細節就翻車。我挑幾個當年真題中常見的坑點講。第一個坑是TIME_WAIT。四次揮手后主動關閉方會進入TIME_WAIT狀態等待2MSLMaximum Segment Lifetime報文最大生存時間。筆試經常會問“為什么需要TIME_WAIT”或“TIME_WAIT過多怎么辦”。標準答案有兩層一是確保最后的ACK能到達對端如果ACK丟了對端會重發FINTIME_WAIT狀態能處理這種情況二是讓舊連接的報文在網絡中自然消失避免影響新連接。實際工程中TIME_WAIT多的場景一般是高并發的短連接服務調優手段包括開啟tcp_tw_reuse僅對客戶端有效、調整tcp_max_tw_buckets、或者改成長連接避免頻繁建連。但注意很多老書還在講tcp_tw_recycle現在不建議開啟了因為NAT環境下會出大問題內核也默認移除了這個開關。如果你在面試時主動提這個坑反而能加分。第二個坑是半連接隊列溢出。Linux下TCP三次握手客戶端SYN到達后服務端會進入SYN_RECV狀態這個隊列由tcp_max_syn_backlog控制。如果短時間內SYN請求過多隊列滿了新連接會被丟棄。筆試給的場景通常是“服務端連接建立成功率下降但CPU和內存都不高”很多人第一反應是看連接數其實應該先看netstat -s里有沒有SYN dropped的統計。排查命令可以記一下netstat -s | grep -i SYN、ss -lnt查看當前隊列長度、sysctl net.ipv4.tcp_max_syn_backlog查看配置。生產環境一般會配合tcp_syncookies來緩解SYN Flood但syncookies開啟后會影響TCP的一些特性比如時間戳選項取舍要清楚。2.2 HTTP層考點從協議到接入層百度這類體量的公司HTTP層的考題不會只停留在“GET和POST區別”而是會深入到HTTP/1.1、HTTPS、HTTP/2的連接管理和性能優化。一個高頻題是HTTP/1.1的Keep-Alive和HTTP/2的多路復用有什么區別。Keep-Alive解決的是“每次請求都重新建連”的問題但請求-響應依然是串行的隊頭阻塞問題沒有根除。HTTP/2引入二進制分幀層多個stream可以并發在一個TCP連接上傳輸徹底解決了應用層的隊頭阻塞。但HTTP/2的隊頭阻塞只是轉移到了TCP層——TCP丟包重傳仍然會阻塞整個連接的所有stream。所以現在HTTP/3用QUIC改走UDP核心就是繞開TCP的隊頭阻塞。這個問題如果問到能答出“HTTP/2解決了應用層隊頭阻塞但沒解決傳輸層隊頭阻塞”這一層比背概念強得多。接入層的考點也很典型。比如“HTTPS握手流程”“TLS1.2和TLS1.3的握手差異”“如何做HTTPS卸載”。這里的核心思路是在百度這種規模下TLS握手計算量非常大一般會用專用的SSL卸載設備或七層Nginx集群來做把非對稱加密的計算從后端服務器剝離出來。筆試題會考察你是否理解這個架構動機。2.3 Linux網絡棧與epoll必背但要有畫面感系統題里epoll是常客。題目一般給一段代碼或一個場景讓你判斷用LT水平觸發還是ET邊緣觸發合適或者問為什么ET模式必須配合非阻塞IO。關鍵邏輯是LT模式下只要socket緩沖區有數據epoll_wait就會一直返回可讀事件所以就算你不處理完下次還會通知你。ET模式下數據到達只在狀態變化時通知一次如果你沒把數據讀完后續可能沒有新事件觸發數據就滯留在緩沖區里。ET模式因此要求應用層必須一次性把數據讀完否則就“餓死”了。而讀數據又需要循環調用read直到返回EAGAIN如果socket是阻塞模式read會卡住線程所以必須設置成非阻塞。這就是“ET必須配合非阻塞IO”的原因。這個因果關系最好能自己順著邏輯推一遍不要死記結論。再往下深挖epoll的事件復雜度、為什么epoll比poll高效也是考點。核心在于epoll用紅黑樹維護監聽的文件描述符用就緒鏈表記錄有事件發生的fd應用層直接遍歷就緒鏈表復雜度從O(n)降到O(就緒數)。如果有興趣還可以順帶看看內核里eventpoll.c的實現面試時能講出“回調機制”會很加分。關于tcp_max_syn_backlog和somaxconn的配合我放在一個表格里方便對照參數作用對象默認值隊列滿時的表現tcp_max_syn_backlog半連接隊列SYN_RECV128或1024不等丟棄SYN客戶端表現為連接超時somaxconn全連接隊列ESTABLISHED128或4096不等新連接被拒絕或丟棄net.core.somaxconnlisten()的backlog上限128accept()無法及時處理時會溢出如果服務端QPS高但處理慢先看全連接隊列是否溢出如果SYN Flood攻擊半連接隊列會先撐爆。這兩個問題排查方向完全不同別搞混。3. 實操過程與核心環節實現3.1 一道網絡模擬題的完整解法和思路編程題部分我回憶一道比較典型的實現一個TCP發送端的流量控制窗口要求模擬接收方通告窗口和擁塞窗口的變化。題目不用真的收發包只要求維護窗口狀態的轉移邏輯。這類題的套路是——數據結構和狀態機。先定義連接狀態結構體typedef struct { uint32_t snd_una; // 已發送未確認的起始序號 uint32_t snd_nxt; // 下一個要發送的序號 uint32_t rwnd; // 接收方通告窗口 uint32_t cwnd; // 擁塞窗口 uint32_t mss; // 最大段大小 int state; // 慢啟動/擁塞避免/快速重傳 } tcp_sender;發送窗口的大小取min(rwnd, cwnd)這個邏輯一定要寫清楚。很多人直接把cwnd當發送窗口忽略了接收方的通告窗口這是扣分點。然后實現慢啟動和擁塞避免的狀態轉移。慢啟動階段每收到一個ACKcwnd增加MSS指數增長超過ssthresh后進入擁塞避免每輪RTT只增加1個MSS線性增長。如果發生超時ssthresh設為cwnd的一半cwnd重置為初始值。我建議代碼里把三種事件新ACK到達、重復ACK、超時寫成獨立函數這樣邏輯清晰測試也方便void handle_ack(tcp_sender *snd, uint32_t ack, uint32_t advertised_wnd) { if (ack snd-snd_una) { // 新ACK正常推進窗口 snd-snd_una ack; snd-rwnd advertised_wnd; if (snd-state SLOW_START) { snd-cwnd snd-mss; } else { // 擁塞避免每個RTT增加1個MSS這里按ACK次數近似 snd-cwnd snd-mss * snd-mss / snd-cwnd; } } else { // 重復ACK計數超過閾值觸發快速重傳 snd-dup_ack; if (snd-dup_ack 3) { snd-ssthresh snd-cwnd / 2; snd-cwnd snd-ssthresh 3 * snd-mss; snd-state FAST_RETRANSMIT; } } }注意上面這段只是簡化模擬真實TCP的實現還有很多細節比如SACK處理、RTO計算、亂序判斷。但筆試中能寫出“窗口取min(rwnd, cwnd)”和“慢啟動/擁塞避免狀態切換”這兩個核心已經能拿大部分分數了。3.2 協議棧排查題的實操復盤還有一類題目不要求寫代碼而是給一個故障現象讓你給出排查思路。我印象很深的一道某服務反饋跨機房的請求延遲抖動從均值10ms漲到平均200ms但CPU和帶寬都不高。這種題沒有唯一答案但面試官在等一個有序的排查路徑。我的答題框架是從鏈路分層排查先看接入層客戶端到LVS/Nginx、再看內網互聯DCI/交換機、最后看服務端。每一步都要有對應的工具和驗證手段。實際作答時我會說先抓包看TCP往返時間RTT用tcpdump在客戶端和服務端同時抓包對比時間戳確認延遲發生在哪個方向。如果客戶端到接入層RTT正常但進入內網后RTT飆升重點看交換機丟包和ECMP哈希是否不均勻。如果確認在服務端看ss -tin的RTT統計、sar -n DEV看網卡隊列是否滿、dmesg查是否有NIC reset日志。再給一個常見問題Linux默認的tcp_congestion_control是cubic在跨地域高帶寬高延遲鏈路上cubic的特性可能造成帶寬利用率上不去。如果抓包發現RTT正常但吞吐低可以試試調整到bbr策略sysctl net.ipv4.tcp_congestion_controlbbr注意需要內核支持。這種“從現象到根因再到解決方案”的鏈路是面試官最想看到的。3.3 數據包端到端旅程綜合設計題的基本功綜合設計題里“輸入URL到頁面渲染”是高概率題。但網絡研發崗的答案不能只答“DNS解析、TCP連接、HTTP請求”這三板斧要深入到百度這種體量的架構細節。我的答題層級是客戶端DNS解析。這里要擴展DNS是怎么做調度的百度自建DNS和HTTPDNS有什么區別傳統DNS基于LocalDNS遞歸解析容易被緩存和污染HTTPDNS則通過HTTP接口直接返回IP繞開LocalDNS實時性和精確性都更好。接入層調度。用戶的請求到達最近的邊緣節點經過四層負載均衡如BGW再到七層Nginx。四層LB關注的是IP和端口轉發基于DPDK等技術實現高吞吐轉發七層Nginx關注HTTP協議做HTTPS卸載、L7路由、限流。緩存與回源。一部分靜態請求在邊緣節點就被CDN緩存命中了只有動態請求或緩存未命中的請求才會回源到中心集群。為什么這么做一是減少跨骨干網的帶寬消耗二是降低用戶感知延遲。后端服務與數據依賴。請求到達后端的搜索或推薦服務服務之間通過RPC通信底層網絡是Overlay網絡如VxLAN還是傳統VLAN這決定了租戶隔離和網絡規模上限。返回路徑。響應的數據包路徑與請求基本對稱但如果涉及全局負載均衡GSLB返回路徑可能會有調整。這套框架能顯示出你對整個網絡鏈路的全局理解。我在實際面試時還會補一句“每一層的超時設定和重試策略要匹配否則某一層超時重試會導致上游請求放大”這是工程上的點睛之筆面試官一般會追問答得好能進一步加分。4. 高頻考點專項突破與避坑記錄4.1 這道題常考的“微細節”整理有些微細節單獨背不值當但考到就特別容易扣分。我整理了一批高頻且易錯的點每個都是我或周圍人當年真實踩過坑的。第一個是TCP序列號的初始值。ISN不是從0開始而是隨時間遞增的偽隨機數核心目的是防止舊連接的報文被新連接誤接收。如果題目問“兩次握手行不行”答案是不行因為無法確認對方接收能力也容易受到SYN洪泛攻擊影響。第二個是MTU和MSS的關系。MTU是IP層的最大傳輸單元以太網一般是1500MSS是TCP層能承載的數據大小去掉IP頭和TCP頭各20字節后一般是1460。如果TCP的數據包超過MSS會被分片分片會導致性能下降和丟包時重傳成本提高。所以TCP握手時會協商MSS避免分片。第三個是HTTP/1.0和HTTP/1.1的Host字段、Connection字段差異。HTTP/1.1是默認長連接支持Host字段這意味著一個IP上可以部署多個虛擬主機。這些基礎不復雜但一旦和Nginx的server_name配置結合起來考就容易出錯。第四個是路由優先級。Linux下路由查找遵循“最長前綴匹配”原則不是“先添加的先匹配”。如果配了兩條到同一個目標網絡的路由前綴長的會生效。筆試如果給一個路由表題目讓你判斷走哪條記得先比掩碼長度再比metric。4.2 筆試過程中的時間分配策略第三批筆試是限時的一般90分鐘到120分鐘。我見過太多人死磕一道編程題結果后面綜合設計題大片空白。這里分享一個實操策略先快速瀏覽全卷按“會做—能推—可放棄”三檔分類。會做的基礎題控制在每題2分鐘內。這種題大多是概念辨析或簡單計算不需要糾結快速鎖定答案。能推的題目一般是協議狀態機、擁塞窗口計算、路由表分析需要動筆推演每題留8-10分鐘。可放棄的題目主要是完全沒思路的編程題或超長場景題先跳過最后有時間再回來寫思路不要放棄——寫“我會用什么方法分析”也比空白強。編程題建議倒著做。因為編程題是最容易拿分的客觀題只要思路對、代碼能跑過測試用例分數就拿到了。綜合設計題反而是最考驗表達和邏輯的寫個大概框架可能就有不錯的分數不要追求完美答案。4.3 備考階段的實戰項目建議筆試準備不能只刷題最好配合動手實驗。這里推薦幾個可以自己搭的場景具體操作如下場景一在兩臺Linux虛擬機之間用tc命令模擬丟包和延遲然后對比cubic和bbr的吞吐差異。命令是tc qdisc add dev eth0 root netem loss 5% delay 50ms然后用iperf3跑帶寬看兩種擁塞控制算法在相同丟包率下的表現。這個實驗做一次你對擁塞控制的理解就不再是紙上談兵。場景二本地用python3 -m http.server起一個HTTP服務然后用tcpdump抓包分析三次握手、HTTP請求響應、四次揮手。重點看TCP頭部標志位的變化以及序列號如何遞增。建議抓包一次就配合Wireshark的“統計—流量圖”看一遍序列號和時間戳的對應關系一目了然。場景三如果對內核源碼感興趣可以grep -r tcp_v4_do_rcv /usr/src/linux-headers-*/net/ipv4/之類的方式把TCP接收路徑的關鍵函數讀一遍理解數據從網卡中斷到應用層read的完整鏈路。不要求全部讀懂能說出“網卡收到包—硬中斷—軟中斷—內核協議棧—socket隊列—用戶態讀取”這個鏈路再配合一次真實抓包基本就夠面試討論了。5. 這套題背后的行業趨勢與能力要求聊完具體題目說點更高維度的趨勢。2019年這批題放到今天來看考察方向依然不過時甚至更值得關注。網絡研發的核心矛盾從“設備配置”轉向“軟件定義”。這點在筆試題里的體現就是純背路由器交換機的命令題幾乎消失取而代之的是網絡協議與Linux系統、分布式系統、數據中心架構的結合題。現在的核心網絡研發工程師不僅要懂BGP、OSPF這些傳統路由協議還要懂VxLAN、EVPN這些Overlay技術以及SRv6這類新轉發范式。筆試后面再深化大概率會往“數據中心網絡自動化”方向考。另一個趨勢是網絡與應用的融合。以前網絡團隊和應用團隊的分工明確網絡只管連通性應用只管業務邏輯。現在不行了業務對延遲和帶寬極度敏感網絡團隊必須能看懂應用的通聯模式應用團隊也得理解網絡的約束。這套筆試題里那些“HTTP層和TCP層交互”的題本質上就是在篩選這種跨層理解力。還有個變化是網絡可觀測性被提到了前所未有的高度。故障排查能力成為筆試和面試的重頭戲因為網絡故障的定位往往是團隊最大的時間黑洞。誰能快速從海量指標和日志中縮小問題范圍誰就是團隊里的核心成員。建議多練“從現象反推原因”的思維方式平時多看看BGP Flap、TCP重傳、丟包這類實際監控圖積累感性認知。所以如果你正在準備這個崗位的校招別把筆試當一次考試把它當成一次網絡工程師能力模型的體檢。每一道題暴露的短板都是你接下來要補的方向。這套題覆蓋的方向足夠全面能幫你快速定位自己在哪里有盲區。按我個人的習慣筆試結束后會立刻把沒做出來的題整理成一份“知識盲點清單”然后針對每一條做一次“原理實驗驗證”的閉環學習。這個習慣我保持了很多年收獲最大的不是某一次面試通過而是逼著自己把一個又一個模糊的概念徹底打通。這也是我想在最后分享給你的一點別只追求“這道題我會做了”而是要追求“這類問題我有一套分析方法了”。前者能幫你過筆試后者能讓你在這個行業里走得更遠。