后端面試?yán)镉?jì)算機(jī)網(wǎng)絡(luò)幾乎是繞不開的一塊硬骨頭。我自己備考那會(huì)兒就發(fā)現(xiàn)不管面初級(jí)還是高級(jí)崗位面試官只要想快速驗(yàn)證候選人是不是具備合格的工程思維第一個(gè)切入點(diǎn)往往就是網(wǎng)絡(luò)問題小到“輸入網(wǎng)址后發(fā)生了什么”大到“服務(wù)間調(diào)用超時(shí)、連接池報(bào)錯(cuò)怎么排查”。網(wǎng)絡(luò)協(xié)議不是孤立的面試題它直接決定了你理解 RPC、消息隊(duì)列、分布式事務(wù)這些后端主線知識(shí)的深淺。所以我把這個(gè)“后端面試系列”的第一大塊給了計(jì)算機(jī)網(wǎng)絡(luò)并且會(huì)持續(xù)更新爭(zhēng)取把每個(gè)高頻考點(diǎn)拆到讓基礎(chǔ)薄弱的讀者也能照著復(fù)述、照著實(shí)戰(zhàn)。這個(gè)系列不是寫給網(wǎng)絡(luò)工程崗的教材而是專門面向后端開發(fā)的面試知識(shí)圖譜與實(shí)踐心得。我會(huì)沿著“面試官最常問、生產(chǎn)環(huán)境最常用”兩條主線展開覆蓋 TCP/UDP、HTTP/HTTPS、DNS、WebSocket、網(wǎng)絡(luò)排查工具和答題套路。每講一個(gè)知識(shí)點(diǎn)我會(huì)補(bǔ)上它在真實(shí)業(yè)務(wù)中對(duì)應(yīng)的問題場(chǎng)景以及我已經(jīng)打磨過的“面試話術(shù)”。適合誰看準(zhǔn)備校招的應(yīng)屆生、想跳槽的初中級(jí)后端以及帶團(tuán)隊(duì)想給成員做網(wǎng)絡(luò)基礎(chǔ)梳理的資深開發(fā)應(yīng)該都能從里面拿走一些東西。1. 先畫考點(diǎn)地圖計(jì)算機(jī)網(wǎng)絡(luò)在后端面試?yán)锞烤箍际裁?.1 面試官考察網(wǎng)絡(luò)知識(shí)的三個(gè)深層動(dòng)機(jī)很多人以為面試官問網(wǎng)絡(luò)題只是“八股文考背功”這個(gè)想法會(huì)害了你。我后來作為面試官參與過幾次招聘發(fā)現(xiàn)大家問網(wǎng)絡(luò)題的真實(shí)動(dòng)機(jī)其實(shí)很集中。第一個(gè)動(dòng)機(jī)是想判斷你能不能理解“服務(wù)間通信的本質(zhì)”。后端開發(fā)每天都在寫接口、調(diào)數(shù)據(jù)庫、連緩存這些動(dòng)作背后都是一次次網(wǎng)絡(luò)傳輸。如果你只懂 API 層面的參數(shù)和返回值卻不理解 TCP 連接如何建立、HTTP 請(qǐng)求為什么失敗遇到線上問題就只能靠重啟和試定位效率極低。第二個(gè)動(dòng)機(jī)是考察你的知識(shí)是否成體系。網(wǎng)絡(luò)知識(shí)不是一條條孤立結(jié)論而是一層疊一層的協(xié)議棧。面試官從“TCP 三次握手”問到“HTTP 為什么基于 TCP 而不是 UDP”再問到“WebSocket 和 HTTP 什么關(guān)系”其實(shí)是在驗(yàn)證你腦子里有沒有一張完整的分層地圖。第三個(gè)動(dòng)機(jī)最容易被忽略網(wǎng)絡(luò)題是壓力測(cè)試的絕佳素材。因?yàn)榫W(wǎng)絡(luò)協(xié)議細(xì)節(jié)多、邊界多面試官可以一層層追問下去看你在被連續(xù)追問時(shí)是慌亂瞎編還是能坦誠邊界。很多人掛在最后不是因?yàn)椴粫?huì)而是因?yàn)楸粏柤绷碎_始胡謅。1.2 考點(diǎn)優(yōu)先級(jí)與復(fù)習(xí)路線表后端崗位的計(jì)算機(jī)網(wǎng)絡(luò)考點(diǎn)非常多但出題頻率差異巨大。我根據(jù)自己和身邊朋友的面經(jīng)整理了一張優(yōu)先級(jí)表格你也可以按這個(gè)順序安排復(fù)習(xí)時(shí)間。優(yōu)先級(jí)考點(diǎn)出現(xiàn)頻率典型問法P0TCP 三次握手、四次揮手、可靠性機(jī)制幾乎必問為什么是三次不是兩次P0HTTP/HTTPS 核心機(jī)制與狀態(tài)碼幾乎必問502 和 504 有什么區(qū)別P0輸入 URL 到頁面展示的完整過程高頻從輸入網(wǎng)址到看到頁面經(jīng)歷了什么P1TCP 擁塞控制、流量控制高頻慢啟動(dòng)和擁塞避免有什么區(qū)別P1TCP 與 UDP 對(duì)比高頻直播場(chǎng)景為什么用 UDPP1Cookie、Session、Token 對(duì)比高頻分布式下 Session 怎么共享P2DNS 解析過程中頻瀏覽器怎么找到服務(wù)器 IPP2WebSocket 握手與場(chǎng)景中頻WebSocket 和 HTTP 有什么關(guān)系P2HTTP 版本演進(jìn)1.1/2.0/3.0中頻HTTP/2 解決了什么問題P3網(wǎng)絡(luò)排查命令與工具低頻但在簡歷里很加分線上接口超時(shí)你怎么查這張表不是讓你按順序從 P0 背到 P3而是提示你優(yōu)先級(jí)高的部分要能扛住追問。P0 的內(nèi)容至少要能流暢講五分鐘以上P1 要能講清楚原理和場(chǎng)景P2 要能說出關(guān)鍵流程P3 要有真實(shí)操作經(jīng)驗(yàn)。下面我從 P0 的 TCP 開始一節(jié)一節(jié)拆。2. 必考基石TCP/IP 從三次握手到擁塞控制2.1 三次握手少一次都不行多一次也尷尬TCP 三次握手是面試中出鏡率最高的問題幾乎沒有任何一場(chǎng)后端面試會(huì)放過它。標(biāo)準(zhǔn)流程大家都能背客戶端先發(fā) SYN服務(wù)端回 SYNACK客戶端再回 ACK。但如果面試官繼續(xù)追問“為什么偏偏是三次能不能兩次”很多人的回答就開始含糊了。要答好這個(gè)問題得從兩個(gè)角度理解。第一個(gè)角度是“能力確認(rèn)”第一次握手服務(wù)端確認(rèn)了客戶端的發(fā)送能力和自己的接收能力第二次握手客戶端確認(rèn)了自己的發(fā)送接收能力和服務(wù)端的發(fā)送能力第三次握手服務(wù)端確認(rèn)了客戶端能正常接收。只有三次才能讓雙方都確認(rèn)“我能發(fā)你也能收”這個(gè)事實(shí)。第二個(gè)角度是“防止歷史連接”如果只有兩次握手一個(gè)在網(wǎng)絡(luò)里滯留的舊 SYN 請(qǐng)求可能被服務(wù)端當(dāng)成新連接建立起來導(dǎo)致資源浪費(fèi)。第三次握手讓客戶端有機(jī)會(huì)告訴服務(wù)端“我根本沒想連這個(gè)舊的”服務(wù)端收到確認(rèn)后才會(huì)放棄。我建議大家準(zhǔn)備一個(gè)直觀類比兩個(gè)人打電話A 說“喂能聽到嗎”B 說“聽到聽到你能聽到我嗎”A 再說“能聽到開始說正事”。這三次交互不只是禮貌而是為了確認(rèn)雙向通道都是通的。面試中還經(jīng)常連帶著問 SYN Flood。原理很好理解攻擊者只發(fā)第一次 SYN 握手包不回第三次 ACK服務(wù)端會(huì)一直維持半連接隊(duì)列等待確認(rèn)內(nèi)存和連接資源被耗盡。常見緩解手段有 SYN Cookie服務(wù)端在收到 SYN 后不直接分配資源而是把狀態(tài)編碼進(jìn)響應(yīng)包的序號(hào)里等收到 ACK 再真正建立連接。這個(gè)細(xì)節(jié)在面試?yán)镏v出來會(huì)明顯拉開和只會(huì)背三步流程的人的差距。握手成功率還會(huì)受全連接隊(duì)列影響這里有個(gè)容易踩的坑如果應(yīng)用層的 accept 處理慢全連接隊(duì)列被打滿就算三次握手流程走完了內(nèi)核也會(huì)丟包或者延遲握手客戶端表現(xiàn)就是“連接超時(shí)但 ping 得通”。后文排查部分我會(huì)再展開。2.2 四次揮手TIME_WAIT 為什么值得單獨(dú)追問四次揮手也是必背題但這塊面試官通常不只是問“誰先關(guān)閉”而是會(huì)追問 TIME_WAIT 狀態(tài)。先記住標(biāo)準(zhǔn)流程主動(dòng)關(guān)閉方發(fā) FIN被動(dòng)方回 ACK被動(dòng)方繼續(xù)發(fā)數(shù)據(jù)發(fā)完再發(fā) FIN主動(dòng)方回 ACK 后進(jìn)入 TIME_WAIT等待 2MSL報(bào)文最大生存時(shí)間的兩倍后連接才徹底消失。為什么 TIME_WAIT 要等 2MSL兩個(gè)核心原因。一是保證最后一個(gè) ACK 能到達(dá)被動(dòng)關(guān)閉方如果 ACK 丟了被動(dòng)方會(huì)重發(fā) FIN主動(dòng)方要靠 TIME_WAIT 狀態(tài)里的殘留信息再回一次 ACK否則被動(dòng)方會(huì)一直等。二是讓本連接中所有延遲的報(bào)文在網(wǎng)絡(luò)里自然消亡避免它們混入相同四元組的新連接造成數(shù)據(jù)錯(cuò)亂。TIME_WAIT 的“壞名聲”在于大量短連接場(chǎng)景下會(huì)出現(xiàn)幾萬個(gè) TIME_WAIT 連接堆在主動(dòng)關(guān)閉方。有人會(huì)直接去改內(nèi)核參數(shù) tcp_tw_reuse 或 tcp_tw_recycle我的建議是謹(jǐn)慎。tcp_tw_recycle 開啟后對(duì) NAT 環(huán)境很不友好容易導(dǎo)致部分用戶連不上Linux 新版本也把它移除了。tcp_tw_reuse 配合時(shí)間戳選項(xiàng)可以在新連接上用但依賴對(duì)端也開啟時(shí)間戳。最穩(wěn)妥的做法是先從應(yīng)用層改用連接池復(fù)用連接、降低請(qǐng)求頻次、避免頻繁創(chuàng)建銷毀連接。我見過很多“TIME_WAIT 一堆”的告警最后查下來根本不是內(nèi)核參數(shù)問題而是調(diào)用方每次請(qǐng)求都 new 一個(gè) HTTP Client。與之對(duì)應(yīng)的 CLOSE_WAIT 也是后端排查重災(zāi)區(qū)。CLOSE_WAIT 是被動(dòng)關(guān)閉方收到 FIN 后沒有調(diào)用 close 導(dǎo)致的狀態(tài)本質(zhì)是代碼里連接沒釋放。如果 ss 看到大量 CLOSE_WAIT正確答案不是調(diào)內(nèi)核參數(shù)而是去查哪個(gè)線程沒執(zhí)行 close、任務(wù)隊(duì)列是不是堆積了。這條經(jīng)驗(yàn)在面試中說出來會(huì)讓人知道你真正處理過線上問題。2.3 可靠傳輸與流量控制滑動(dòng)窗口在實(shí)戰(zhàn)中的存在感TCP 的可靠性建立在序號(hào)、確認(rèn)號(hào)、超時(shí)重傳和滑動(dòng)窗口這幾個(gè)機(jī)制上。面試官常問的是“TCP 怎么保證數(shù)據(jù)不丟”你要能完整回答發(fā)送方會(huì)給每個(gè)字節(jié)編號(hào)接收方收到后返回確認(rèn)號(hào)表示期望的下一個(gè)字節(jié)發(fā)送方維護(hù)一個(gè)滑動(dòng)窗口在不等待單個(gè)確認(rèn)的情況下連續(xù)發(fā)送窗口內(nèi)的數(shù)據(jù)同時(shí)啟動(dòng)重傳計(jì)時(shí)器如果超時(shí)或者收到三次重復(fù)確認(rèn)就重新發(fā)送?；瑒?dòng)窗口的另一個(gè)名字是流量控制。接收方會(huì)在 TCP 頭部里告訴發(fā)送方自己的接收窗口 rwnd 還有多大發(fā)送方的發(fā)送窗口不能超過這個(gè)值。這個(gè)機(jī)制解決的是“發(fā)送太快把接收方緩沖區(qū)塞爆”的問題。實(shí)際開發(fā)中如果你寫個(gè)程序往對(duì)端狂塞數(shù)據(jù)對(duì)端處理不過來TCP 會(huì)自動(dòng)幫你降速應(yīng)用層根本感知不到這就是流量控制在背后的作用。面試?yán)锶菀妆蛔穯柕氖恰袄塾?jì)確認(rèn)”的概念接收方不需要對(duì)每個(gè)包單獨(dú)確認(rèn)而是確認(rèn)到某個(gè)連續(xù)序列為止比這個(gè)序號(hào)小的所有字節(jié)都認(rèn)為已收到。這樣實(shí)現(xiàn)簡單、開銷小代價(jià)是如果中間的包丟了后面的包即使到了也只能等重傳這又引出了 TCP 的隊(duì)頭阻塞問題。這里可以順帶提一句正因?yàn)?TCP 有這種按序交付的強(qiáng)約束HTTP/2 在 TCP 之上做多路復(fù)用仍然無法徹底解決隊(duì)頭阻塞才會(huì)有人推動(dòng)基于 UDP 的 QUIC。2.4 擁塞控制四算法背結(jié)論更要懂行為差異擁塞控制和流量控制經(jīng)常被搞混面試時(shí)你先說清楚區(qū)別就能加分流量控制是考慮接收方承受能力擁塞控制是考慮網(wǎng)絡(luò)鏈路承受能力。TCP 發(fā)送方維護(hù)一個(gè)擁塞窗口 cwnd和接收方通告的 rwnd 取較小值作為實(shí)際發(fā)送窗口。四個(gè)算法需要按順序記憶。慢啟動(dòng)連接剛建立時(shí) cwnd 很小每收到一個(gè)確認(rèn) cwnd 翻倍所以叫“指數(shù)增長”直到達(dá)到慢啟動(dòng)閾值 ssthresh。擁塞避免超過 ssthresh 后 cwnd 每輪只加 1線性增長避免快速塞爆網(wǎng)絡(luò)?？熘貍靼l(fā)送方收到三個(gè)重復(fù) ACK 時(shí)就立即重傳不用等超時(shí)?？旎謴?fù)發(fā)生快重傳后把 ssthresh 減半、cwnd 減半然后進(jìn)入擁塞避免階段。面試官最愛問“慢啟動(dòng)為什么慢”你回答時(shí)不要只說“它增長慢”。慢啟動(dòng)的增長在一開始其實(shí)是很快的1、2、4、8 這樣翻倍它的“慢”是相對(duì)于直接以一大塊數(shù)據(jù)沖入網(wǎng)絡(luò)而言。目的是探測(cè)鏈路容量避免一開始就造成擁塞。還有一個(gè)容易被追問的細(xì)節(jié)是 TCP 的 AIMD 原則加法增大、乘法減小。平時(shí) cwnd 線性增遇到擁塞就減半甚至降到 1這種“和善地探測(cè)、激烈地退避”的設(shè)計(jì)是 TCP 能在復(fù)雜互聯(lián)網(wǎng)環(huán)境下存活的關(guān)鍵。2.5 UDP 這邊也要會(huì)答實(shí)時(shí)場(chǎng)景和 QUIC面試不會(huì)只考 TCPUDP 的對(duì)比題出現(xiàn)頻率也很高。最經(jīng)典的問法是“視頻直播延遲高為什么不用 TCP 而用 UDP”。答案主干有三點(diǎn)TCP 的可靠重傳和按序交付在丟包時(shí)會(huì)引入延遲和卡頓實(shí)時(shí)媒體可以容忍少量丟包但不能容忍延遲UDP 頭部開銷小、無連接能快速傳輸。還要補(bǔ)充一句現(xiàn)在很多直播和實(shí)時(shí)通信做了應(yīng)用層補(bǔ)償比如 FEC 前向糾錯(cuò)、插幀、客戶端緩沖這些都是為了在 UDP 之上緩解丟包?，F(xiàn)在面試越來越喜歡追問 QUIC因?yàn)樗褪恰坝?UDP 實(shí)現(xiàn)可靠傳輸”的代表。你可以說 QUIC 在用戶態(tài)實(shí)現(xiàn)了類似 TCP 的可靠性、流量控制、擁塞控制并且解決了一個(gè)關(guān)鍵痛點(diǎn)連接遷移。TCP 連接由四元組標(biāo)識(shí)手機(jī)切換 WiFi 時(shí) IP 變了連接就斷了QUIC 用連接 ID 標(biāo)識(shí)連接網(wǎng)絡(luò)切換后連接依然可以繼續(xù)這也是 HTTP/3 選擇它的重要原因。3. HTTP/HTTPS 高頻題從狀態(tài)碼到 TLS 握手3.1 狀態(tài)碼別只背 404后端要能講清 5xx 的排查方向HTTP 狀態(tài)碼數(shù)量很多我不建議死背。面試官真正想聽到的是你看到一個(gè)狀態(tài)碼能說清楚業(yè)務(wù)側(cè)該往哪個(gè)方向排查。按類區(qū)分2xx 表示成功注意 201 表示創(chuàng)建成功、204 表示無內(nèi)容很多同學(xué)只認(rèn)識(shí) 200。3xx 是重定向301 是永久重定向302 是臨時(shí)重定向304 Not Modified 表示資源未修改可以使用緩存。4xx 是客戶端問題400 請(qǐng)求參數(shù)錯(cuò)誤、401 未認(rèn)證、403 已認(rèn)證但沒權(quán)限、404 資源不存在、429 請(qǐng)求太頻繁觸發(fā)限流。5xx 是服務(wù)端問題500 服務(wù)器內(nèi)部異常、501 未實(shí)現(xiàn)、502 Bad Gateway 一般是網(wǎng)關(guān)拿不到上游有效響應(yīng)、503 服務(wù)暫時(shí)不可用通常和過載、熔斷有關(guān)、504 網(wǎng)關(guān)等待上游超時(shí)。面試中區(qū)分度最高的問答是“502 和 504 的區(qū)別”。502 的本質(zhì)是上游沒有返回可用的響應(yīng)比如上游進(jìn)程直接崩了、連接被拒絕、響應(yīng)格式不對(duì)504 的本質(zhì)是請(qǐng)求發(fā)出去了但上游在設(shè)定時(shí)間內(nèi)沒處理完比如后端線程池滿了、慢 SQL 拖垮了接口。解答方向完全不同502 優(yōu)先查進(jìn)程存活、端口監(jiān)聽、部署發(fā)布狀態(tài)504 優(yōu)先查超時(shí)配置、接口耗時(shí)、數(shù)據(jù)庫慢日志。我自己的面試話術(shù)是先說狀態(tài)碼屬于哪個(gè)類別再給一個(gè)生產(chǎn)環(huán)境場(chǎng)景最后補(bǔ)一句“我會(huì)先看網(wǎng)關(guān)日志和后端日志的時(shí)間差再?zèng)Q定是查網(wǎng)絡(luò)還是查應(yīng)用”。這句話雖然簡單但能讓面試官覺得你真在線上處理過問題。3.2 HTTP 版本演進(jìn)從短連接到多路復(fù)用HTTP 版本演進(jìn)是近幾年的熱門考點(diǎn)核心是理解每個(gè)版本解決了什么問題。HTTP/1.0 默認(rèn)短連接每次請(qǐng)求都要新建 TCP 連接請(qǐng)求結(jié)束后立即斷開開銷大。HTTP/1.1 引入了持久連接Connection: keep-alive多個(gè)請(qǐng)求可以復(fù)用同一條 TCP 連接還增加了 Host 頭讓一臺(tái)服務(wù)器可以托管多個(gè)域名。但 HTTP/1.1 有個(gè)致命缺陷同一連接上的多個(gè)請(qǐng)求必須排隊(duì)前一個(gè)沒響應(yīng)完后一個(gè)就不能發(fā)這就是隊(duì)頭阻塞。實(shí)際緩解手段是瀏覽器開多個(gè) TCP 連接、域名分片但這些都是繞過問題而不是解決問題。HTTP/2 的做法是把請(qǐng)求和響應(yīng)拆成更小的二進(jìn)制幀在一條 TCP 連接里交錯(cuò)傳輸這就是多路復(fù)用。它還做了頭部壓縮HPACK避免每次請(qǐng)求都重復(fù)攜帶大量 Cookie 和 User-Agent。HTTP/2 解決了應(yīng)用層的隊(duì)頭阻塞但沒有解決 TCP 層的隊(duì)頭阻塞底層 TCP 一旦丟包所有幀都要等重傳多路復(fù)用的優(yōu)勢(shì)被拉平。這也是 HTTP/3 轉(zhuǎn)向基于 UDP 的 QUIC 的直接原因。面試時(shí)如果你能說出“HTTP/2 的多路復(fù)用是在一條 TCP 連接內(nèi)字節(jié)層面交錯(cuò)HTTP/3 則是在無連接的 UDP 上自己實(shí)現(xiàn)連接管理”基本已經(jīng)超過大多數(shù)候選人了。還可以補(bǔ)一句實(shí)際經(jīng)驗(yàn)升級(jí) HTTP/2 后如果遇到瀏覽器證書告警、不兼容的老環(huán)境需要做好降級(jí)方案我的做法是邊緣網(wǎng)關(guān)根據(jù)客戶端握手能力動(dòng)態(tài)協(xié)商版本。3.3 HTTPS 握手到底怎么完成密鑰協(xié)商HTTPS 等于 HTTP 加 TLS核心是加密和身份驗(yàn)證。面試高頻問法是“HTTPS 的握手過程是什么”我建議你按“非對(duì)稱交換密鑰、對(duì)稱加密傳輸數(shù)據(jù)”這個(gè)主線來講。簡化版流程客戶端發(fā)送 ClientHello攜帶支持的 TLS 版本和加密套件服務(wù)端回復(fù) ServerHello選定加密套件同時(shí)下發(fā)自己的數(shù)字證書客戶端驗(yàn)證證書的合法性包括證書是否過期、域名是否匹配、簽發(fā)鏈?zhǔn)欠窨尚膨?yàn)證通過后客戶端生成一個(gè)隨機(jī)預(yù)主密鑰Pre-Master Secret用服務(wù)端證書里的公鑰加密發(fā)送過去服務(wù)端用私鑰解密得到預(yù)主密鑰雙方用預(yù)主密鑰和各自隨機(jī)數(shù)派生出對(duì)稱會(huì)話密鑰之后應(yīng)用數(shù)據(jù)都用對(duì)稱加密傳輸。這里要能回答“為什么不用非對(duì)稱加密所有數(shù)據(jù)”。非對(duì)稱加密雖然安全但性能開銷比對(duì)稱加密高幾個(gè)數(shù)量級(jí)不適合大量業(yè)務(wù)數(shù)據(jù)。所以方案的實(shí)質(zhì)是“用非對(duì)稱加密安全地交換對(duì)稱密鑰”之后用對(duì)稱加密保證性能。另一個(gè)常問問題是“證書怎么防偽造”。證書里有域名、公鑰、簽發(fā)者、有效期和簽名。瀏覽器驗(yàn)證時(shí)用內(nèi)置的根證書公鑰去驗(yàn)證簽發(fā)者簽名形成一條信任鏈。如果某個(gè)中間證書泄露或被惡意簽發(fā)瀏覽器會(huì)拒絕信任。我遇到過不少服務(wù)端證書過期導(dǎo)致客戶端大面積報(bào)錯(cuò)的事故教訓(xùn)就是給證書加上監(jiān)控和提前續(xù)期提醒最好做成自動(dòng)輪轉(zhuǎn)。3.4 Cookie、Session、Token登錄態(tài)設(shè)計(jì)的基礎(chǔ)這個(gè)題目幾乎每次面試都會(huì)出現(xiàn)但很多人的回答停在“Cookie 存客戶端、Session 存服務(wù)端”這個(gè)層面。要拔高需要從“狀態(tài)放在哪”這個(gè)本質(zhì)去講。HTTP 是無狀態(tài)協(xié)議它不認(rèn)識(shí)“誰是誰”。為了標(biāo)識(shí)用戶服務(wù)端可以生成一個(gè) Session ID存到服務(wù)端內(nèi)存或 Redis 里然后讓客戶端通過 Cookie 帶上這個(gè) ID這叫做服務(wù)端會(huì)話。優(yōu)點(diǎn)是可控性強(qiáng)、能主動(dòng)失效缺點(diǎn)是分布式環(huán)境下多個(gè)服務(wù)節(jié)點(diǎn)必須共享 Session 存儲(chǔ)否則請(qǐng)求被負(fù)載均衡到另一臺(tái)機(jī)器就找不到會(huì)話了。常見解法是把 Session 集中到 Redis或者做粘性會(huì)話但粘性會(huì)話會(huì)給負(fù)載均衡帶來壓力和隱患。Token 方式的思路是“不存服務(wù)端”把用戶信息、過期時(shí)間用簽名封裝成一個(gè)字符串發(fā)給客戶端服務(wù)端驗(yàn)簽通過就信任。JWT 就是這種無狀態(tài)方案的代表。優(yōu)點(diǎn)是好擴(kuò)展、天然適合移動(dòng)端和跨域缺點(diǎn)是難以主動(dòng)失效除非引入黑名單或縮短過期時(shí)間還有泄露后風(fēng)險(xiǎn)非常大。我做過一次對(duì)賬系統(tǒng)改造就是因?yàn)閾?dān)心 Token 續(xù)期和過期的邊界問題最終選擇了“短期 Token 加刷新 Token”的雙 Token 方案。面試時(shí)你可以給出一個(gè)選型觀點(diǎn)如果業(yè)務(wù)純?cè)跒g覽器環(huán)境下、設(shè)備少先用 Session 加 Redis 最簡單如果要做多端、跨域、開放接口平臺(tái)再考慮 Token。不要只說“都差不多”面試官想聽的正是你做過的取舍。4. 應(yīng)用層補(bǔ)充考點(diǎn)DNS、WebSocket 與完整訪問鏈路4.1 一次 DNS 解析的完整路徑很多人覺得 DNS 簡單但其實(shí)它能撐起一輪完整的技術(shù)面試。經(jīng)典問法是“瀏覽器輸入域名后是怎么找到 IP 的”。解析路徑大致是瀏覽器先查本地 DNS 緩存再查操作系統(tǒng) hosts 文件沒有命中就發(fā)給本地 DNS 服務(wù)器運(yùn)營商或公司內(nèi)網(wǎng) DNS本地 DNS 會(huì)先問根域名服務(wù)器“com 域名在哪里管”根服務(wù)器指向頂級(jí)域名服務(wù)器頂級(jí)域名服務(wù)器再指向這個(gè)域名的權(quán)威服務(wù)器權(quán)威服務(wù)器給出最終的 A 記錄或 CNAME 記錄。實(shí)際過程中本地 DNS 通常替客戶端完成了完整的遞歸查詢把最終結(jié)果緩存起來并按 TTL 控制有效期。能加分的點(diǎn)有三個(gè)。第一是“遞歸查詢和迭代查詢的區(qū)別”客戶端到本地 DNS 是遞歸給我最終答案本地 DNS 到根/頂級(jí)/權(quán)威服務(wù)器是迭代不斷被指點(diǎn)去下一級(jí)問。第二是 DNS 緩存和 TTL 的實(shí)際影響發(fā)布域名切換后如果老記錄 TTL 設(shè)置得很大上次修改要等很久才全部生效最好的做法是提前把 TTL 調(diào)小切換完再調(diào)回去。第三是負(fù)載均衡權(quán)威服務(wù)器可以針對(duì)同一域名返回多個(gè) IP或者返回 CNAME 指向 CDNCDN 再根據(jù)用戶地理位置返回最近的邊緣節(jié)點(diǎn) IP。CDN 能加速的核心就是這一層。4.2 WebSocket 建立連接的過程與心跳重連WebSocket 也是高頻考點(diǎn)但考察點(diǎn)集中在“和 HTTP 的關(guān)系”以及“為什么不用輪詢”。你可以從需求出發(fā)HTTP 是請(qǐng)求-響應(yīng)模式服務(wù)器不能主動(dòng)給客戶端推送消息只能靠客戶端不斷輪詢延遲和開銷都很大。WebSocket 在一條 TCP 連接上建立全雙工通道服務(wù)器隨時(shí)可以把數(shù)據(jù)推給客戶端適合聊天、實(shí)時(shí)通知、游戲?qū)?zhàn)、行情推送。建立連接的關(guān)鍵是利用了 HTTP 的升級(jí)機(jī)制客戶端發(fā)一個(gè)包含Upgrade: websocket和Sec-WebSocket-Key的 GET 請(qǐng)求服務(wù)端驗(yàn)證通過后計(jì)算一個(gè) Sec-WebSocket-Accept 值返回 101 Switching Protocols之后這條 TCP 連接就切換到 WebSocket 協(xié)議雙方可以雙向發(fā)幀。面試中值得說的實(shí)踐細(xì)節(jié)是“心跳與重連”因?yàn)?WebSocket 是長連接中間任何一層網(wǎng)絡(luò)設(shè)備都可能因?yàn)榭臻e把連接斷了。所以客戶端要定時(shí)發(fā) ping 幀服務(wù)端回 pong 幀超過閾值沒收到就主動(dòng)斷開重連重連還要配合指數(shù)退避和隨機(jī)抖動(dòng)避免服務(wù)端在斷網(wǎng)恢復(fù)時(shí)被瞬時(shí)連接風(fēng)暴打垮。這些細(xì)節(jié)是我做推送網(wǎng)關(guān)時(shí)的真實(shí)經(jīng)驗(yàn)面試?yán)镏v出來比“前端會(huì)用 WebSocket 對(duì)象”有價(jià)值得多。4.3 面試經(jīng)典綜合題瀏覽器輸入 URL 后發(fā)生了什么這道題幾乎是后端面試的“送分題”和“送命題”結(jié)合體說送分是因?yàn)槊總€(gè)人都能說兩步說送命題是因?yàn)樽穯柶饋頉]底。完整鏈路建議按時(shí)間順序分七個(gè)環(huán)節(jié)回答URL 解析、DNS 查找、TCP 連接、HTTP 請(qǐng)求發(fā)送、服務(wù)器處理與響應(yīng)、瀏覽器解析渲染、資源加載與頁面展示。每個(gè)環(huán)節(jié)都可以被拆開追問。URL 解析要說明協(xié)議、域名、端口、路徑DNS 查找要說明緩存層級(jí)和遞歸過程TCP 連接要回到三次握手HTTP 請(qǐng)求要說明請(qǐng)求頭、Cookie、緩存協(xié)商服務(wù)器處理要講負(fù)載均衡、后端服務(wù)、數(shù)據(jù)庫響應(yīng)階段要講狀態(tài)碼和響應(yīng)頭渲染階段要區(qū)分首字節(jié)時(shí)間、白屏?xí)r間、DOM 構(gòu)建和資源加載。面試官的幾個(gè)常見追問點(diǎn)我都遇到過“Cookie 在哪個(gè)階段帶上”、“DNS 解析失敗會(huì)看到什么錯(cuò)”、“如果服務(wù)器返回 304 代表什么”這些問題都能在本系列其他章節(jié)里找到對(duì)應(yīng)答案。我自己的經(jīng)驗(yàn)是回答這道題時(shí)不要背成流水賬要主動(dòng)說出“我會(huì)先看有沒有本地緩存再講網(wǎng)絡(luò)通信再講服務(wù)端處理如果面試官想看深度我再展開某一部分”。這樣既展示全局觀又給了自己主動(dòng)權(quán)。5. 生產(chǎn)環(huán)境排查網(wǎng)絡(luò)工具與典型故障定位5.1 四個(gè)命令走天下ping、curl、nc、ss后端面試中有一個(gè)隱形考點(diǎn)你平時(shí)怎么排查網(wǎng)絡(luò)問題。哪怕面試官不直接問聊項(xiàng)目時(shí)提到“接口超時(shí)”也一定會(huì)追問具體排查動(dòng)作。我常用的四個(gè)命令在這里一次性列出來。ping 用來判斷主機(jī)是否可達(dá)、鏈路延遲多大基于 ICMP 協(xié)議。注意 ping 通不代表 TCP 端口可用因?yàn)槟繕?biāo)主機(jī)可能禁 ping 或無 ICMP 響應(yīng)實(shí)際通信卻正常所以要配合第二件工具。curl 是 HTTP 接口排查神器常用參數(shù)-v顯示詳細(xì)握手和請(qǐng)求頭、-I只拿響應(yīng)頭、-d帶 POST 數(shù)據(jù)、-x走代理。排查 HTTP 問題時(shí)我通常先curl -v看 TLS 握手日志和響應(yīng)耗時(shí)再?zèng)Q定往下走網(wǎng)絡(luò)層還是應(yīng)用層。nc 用來測(cè)試端口連通性nc -vz host port比 telnet 更常見許多服務(wù)器沒裝 telnetnc 基本都在。ss 是看本機(jī) TCP 連接狀態(tài)的利器ss -antp能列出所有連接、狀態(tài)和進(jìn)程比 netstat 更快更方便。排查順序我總結(jié)成了口訣先 ping 通不通再 nc 端口連不連然后 curl 看 HTTP 狀態(tài)最后 ss 看連接狀態(tài)。很多問題到不了抓包那一步用這四個(gè)工具就能解決八成。5.2 抓包工具的基本用法與過濾思路如果四個(gè)命令還定位不了就需要抓包了。服務(wù)端最常用的是 tcpdump它的核心不是看著一大堆報(bào)文而是用過濾表達(dá)式快速縮小范圍。常見過濾有幾種按主機(jī)過濾用host按端口過濾用port按協(xié)議過濾用tcp或udp組合條件用and、or。例如tcpdump -i eth0 -nn tcp port 8080 and host 10.0.0.8能只看指定網(wǎng)卡上目標(biāo)端口為 8080 的 TCP 報(bào)文。-nn參數(shù)不要省略否則會(huì)做反向解析主機(jī)名又慢又亂。抓到包之后我會(huì)先看 TCP 握手是否完成、有沒有大量重傳、RST 從哪來的。比如客戶端報(bào)連接超時(shí)抓包發(fā)現(xiàn)所有 SYN 發(fā)出去沒有回應(yīng)說明服務(wù)端根本沒有響應(yīng)這個(gè)來源 IP可能是防火墻攔截、源地址策略丟棄或者服務(wù)器負(fù)載已滿如果三次握手都完成了但應(yīng)用層沒數(shù)據(jù)問題基本就在應(yīng)用代碼。Wireshark 適合在測(cè)試環(huán)境做深分析有圖形界面、能自動(dòng)分析重傳、可以按流過濾。但生產(chǎn)環(huán)境很多情況不適合直接抓包我一般用 tcpdump 抓完后把 pcap 文件下載到本地再用 Wireshark 打開。抓包是核武器不要一上來就抓先用輕量工具定位到大致范圍。5.3 高頻故障場(chǎng)景排查速查表我把后端實(shí)際遇到的網(wǎng)絡(luò)故障整理成一張速查表面試和實(shí)戰(zhàn)都直接可用。故障表現(xiàn)可能原因首選排查手段連接超時(shí)ping 不通防火墻攔截、路由不可達(dá)、對(duì)端宕機(jī)分段 ping 網(wǎng)關(guān)和目標(biāo)查防火墻規(guī)則連接超時(shí)ping 通端口未監(jiān)聽、全連接隊(duì)列滿、負(fù)載高nc 測(cè)端口ss 看隊(duì)列查應(yīng)用日志大量 TIME_WAIT短連接頻繁創(chuàng)建、連接未復(fù)用ss 統(tǒng)計(jì)狀態(tài)檢查客戶端連接池大量 CLOSE_WAIT服務(wù)端收到 FIN 沒 closejstack 查線程棧定位未釋放連接代碼間歇性連接失敗連接池耗盡、半連接隊(duì)列滿看線程池和連接池監(jiān)控ss 看 SYN 隊(duì)列接口偶發(fā) 502上游進(jìn)程掛、發(fā)布重啟、響應(yīng)格式錯(cuò)查網(wǎng)關(guān)日志和后端日志時(shí)間戳接口偶發(fā) 504上游超時(shí)、慢 SQL、線程池阻塞查接口耗時(shí)看數(shù)據(jù)庫慢日志首字節(jié)時(shí)間很長跨機(jī)房公網(wǎng)不穩(wěn)、DNS 解析慢curl -w 分階段計(jì)時(shí)檢查 DNS 耗時(shí)這張表的重點(diǎn)是“原因”和“手段”必須配套。很多人只會(huì)說“查日志”但在網(wǎng)絡(luò)問題上先確認(rèn)是網(wǎng)絡(luò)層、傳輸層還是應(yīng)用層再?zèng)Q定看什么日志效率會(huì)高很多。我經(jīng)常舉的一個(gè)例子線上偶發(fā)超時(shí)看業(yè)務(wù)日志全是網(wǎng)絡(luò)異常但應(yīng)用日志沒報(bào)錯(cuò)結(jié)果一抓包發(fā)現(xiàn)跨區(qū)域公網(wǎng)鏈路丟包率高達(dá) 2%。這種問題不用調(diào)代碼靠發(fā)布鏈路優(yōu)化解決。5.4 一個(gè)跨環(huán)境調(diào)用的排查案例分享一個(gè)我做過的真實(shí)定位過程所有敏感信息都替換掉了。某服務(wù) A 調(diào)用服務(wù) B 的接口業(yè)務(wù)方反饋經(jīng)常超時(shí)但偶爾又能成功。一開始我以為是代碼問題先加了耗時(shí)日志、連接池參數(shù)調(diào)優(yōu)結(jié)果毫無改善。后來換了一個(gè)思路用 curl 直接打 B 的接口從 A 所在機(jī)器上測(cè)發(fā)現(xiàn)平均耗時(shí)要 800ms但在另一臺(tái)機(jī)器上測(cè)只要 20ms。差異立刻鎖定了網(wǎng)絡(luò)鏈路。繼續(xù)排查發(fā)現(xiàn)這兩臺(tái)機(jī)器處在不同的網(wǎng)段請(qǐng)求走了不同的出口網(wǎng)關(guān)問題大概率在某個(gè)交換機(jī)或防火墻。我用 ping 測(cè)延遲也正常但用大包測(cè)延遲時(shí)發(fā)現(xiàn)跨網(wǎng)段的鏈路延遲明顯偏高最終定位是某條鏈路的 MTU 配置不一致導(dǎo)致大包被分片重傳性能驟降。調(diào)整 MTU 后問題徹底消失。這個(gè)案例說明一個(gè)關(guān)鍵方法論遇到網(wǎng)絡(luò)問題不要把目光一開始就鎖死在應(yīng)用代碼里先做好二分法——同一請(qǐng)求從不同節(jié)點(diǎn)發(fā)起對(duì)比結(jié)果就能快速劃分出是代碼問題、網(wǎng)絡(luò)鏈路問題還是對(duì)端服務(wù)問題。這就是資深開發(fā)和初級(jí)的核心區(qū)別。6. 面試答題框架與持續(xù)更新計(jì)劃6.1 萬能答題框架結(jié)論、原理、場(chǎng)景三步走技術(shù)面試和筆試最大不同是你說什么、怎么說面試官都在觀察你的思維過程。我練習(xí)后總結(jié)出一套“三步答題法”幾乎適用于所有網(wǎng)絡(luò)題。第一步先給結(jié)論一句話說清楚“是什么”或“為什么”。比如問“TCP 和 UDP 區(qū)別”第一句就說“TCP 是面向連接、可靠、按序的字節(jié)流傳輸協(xié)議UDP 是無連接、盡力而為、面向報(bào)文的數(shù)據(jù)報(bào)協(xié)議?！苯Y(jié)論要簡短有力不要一開始就鋪背景。第二步講原理拆開核心機(jī)制按順序描述可以加一點(diǎn)協(xié)議流程。第三步落到場(chǎng)景說“這個(gè)特性在 XX 場(chǎng)景下選擇它是因?yàn)椤比绻约号挪檫^就補(bǔ)一句真實(shí)案例。這個(gè)方法的意義在于控制回答節(jié)奏。先給結(jié)論即使后面展開得不夠好面試官也能抓到你的主線場(chǎng)景收尾能把理論拉到工程實(shí)踐讓面試官知道你不僅看書還真的干活。我建議每一個(gè) P0 考點(diǎn)都按照這個(gè)框架寫一遍逐字稿背熟節(jié)奏而不是背整段內(nèi)容。6.2 被追問時(shí)的三個(gè)錯(cuò)誤示范面試中大概率會(huì)被連續(xù)追問而追問恰恰是區(qū)分“背題”和“理解”的時(shí)間。這里我總結(jié)三個(gè)最常見的錯(cuò)誤說話方式都是我踩過的坑。錯(cuò)誤一是直接否定問題“這個(gè)沒什么用、一般不這么用?！蹦呐聠栴}冷門它也是面試官想確認(rèn)你知識(shí)邊界的窗口。正確的做法是承認(rèn)不足但盡量接住“這一塊我了解不深我理解它大概是……如果能給我一點(diǎn)提示我可以繼續(xù)往下分析?！卞e(cuò)誤二是假裝懂現(xiàn)場(chǎng)編細(xì)節(jié)。網(wǎng)絡(luò)協(xié)議細(xì)節(jié)容不得編一旦后續(xù)追問對(duì)不上信譽(yù)會(huì)大打折扣比直接說不會(huì)嚴(yán)重得多。錯(cuò)誤三是只講結(jié)論不講推導(dǎo)過程比如被問“為什么 TIME_WAIT 要 2MSL”只回答“為了確保安全”等于沒說必須把兩個(gè)原因拆開講最好帶著邏輯推演。被追問到底的底線策略是向上抽象一層把問題引導(dǎo)到自己熟悉的范圍里。比如面試官往加密算法數(shù)學(xué)細(xì)節(jié)上追問你不熟悉可以說“我研究更多是應(yīng)用層面的對(duì)稱與非對(duì)稱密鑰交換流程困擾我更多的時(shí)候是證書鏈的問題有沒有興趣聽聽我線上遇到的一個(gè)證書告警”。主動(dòng)引導(dǎo)話題不是狡辯是把對(duì)話拉回自己的優(yōu)勢(shì)區(qū)間。6.3 本系列的更新節(jié)奏與建議的復(fù)習(xí)方法這篇是“計(jì)算機(jī)網(wǎng)絡(luò)”主題的開篇框架后續(xù)我會(huì)按負(fù)責(zé)拆解每個(gè)大考點(diǎn)TCP 的每個(gè)機(jī)制做獨(dú)立專題、HTTP 全線版本對(duì)比、HTTPS 的證書體系、分布式會(huì)話與 Token 實(shí)戰(zhàn)、網(wǎng)絡(luò)排查案例合集以及專門的高頻面試問答題庫。每篇會(huì)保持同樣的風(fēng)格原理講透、場(chǎng)景落到工程、面試話術(shù)可直接背。復(fù)習(xí)建議方面我給自己的要求是“先建地圖、再填磚塊”先看懂這篇文章的考點(diǎn)優(yōu)先級(jí)表填空一樣的復(fù)習(xí)每復(fù)習(xí)一個(gè)考點(diǎn)就問自己三個(gè)問題——它解決什么問題、它的代價(jià)是什么、它在我做過的哪個(gè)項(xiàng)目里出現(xiàn)過。如果第三個(gè)問題答不上來說明這個(gè)知識(shí)點(diǎn)還沒有內(nèi)化成你的經(jīng)驗(yàn)?zāi)蔷腿フ乙粋€(gè)真實(shí)場(chǎng)景做一次實(shí)驗(yàn)。這套方法陪我走過了從“死背八股文”到“能現(xiàn)場(chǎng)推理網(wǎng)絡(luò)問題”的轉(zhuǎn)變。說句實(shí)在話我做現(xiàn)在這個(gè)系列最大的動(dòng)力就是看見太多候選人明明基礎(chǔ)不錯(cuò)卻因?yàn)闆]有系統(tǒng)的復(fù)習(xí)框架在“三次握手為什么不能兩次”這類問題上栽跟頭。網(wǎng)絡(luò)協(xié)議值得你花時(shí)間因?yàn)槟阃笥龅降乃泻蠖藛栴}最終都會(huì)繞回這些看似基礎(chǔ)的細(xì)節(jié)上。