絡(luò)協(xié)議梳理與排障實(shí)戰(zhàn)：HTTP、TCP/IP、DNS、SSH、FTP)
網(wǎng)絡(luò)協(xié)議這東西平時(shí)不接觸的人覺得它高高在上接觸了又覺得知識(shí)點(diǎn)碎得跟散沙一樣。但其實(shí)不管你是做開發(fā)的、搞運(yùn)維的還是偶爾需要自己折騰一下服務(wù)器、翻翻路由器配置的“興趣型工程師”只要能把HTTP、IP、SSH、FTP、DNS、TCP這幾個(gè)核心協(xié)議徹底弄明白整個(gè)網(wǎng)絡(luò)的骨架也就搭起來了。我最早開始系統(tǒng)梳理這些協(xié)議是因?yàn)楸灰粋€(gè)線上的詭異問題折磨了一整晚頁面間歇性打不開看服務(wù)器日志一切正常程序也沒報(bào)錯(cuò)。最后抓包才發(fā)現(xiàn)是TCP握手的重傳機(jī)制在特定網(wǎng)絡(luò)環(huán)境下瘋狂觸發(fā)和HTTP層的請(qǐng)求邏輯完全無關(guān)。那次之后我意識(shí)到不把協(xié)議棧吃透出了問題就只能瞎猜。這篇文章就是基于我個(gè)人踩坑和日常排查經(jīng)驗(yàn)做的一次系統(tǒng)梳理。我不打算按教科書式的“逐層背誦”來寫而是把每個(gè)協(xié)議放到真實(shí)場景里講清楚它解決什么問題、有哪些關(guān)鍵機(jī)制、實(shí)際使用中容易踩哪些坑。無論是剛?cè)腴T的新手還是想補(bǔ)全盲區(qū)的老手都能在里邊找到有用的東西。1. 把這些協(xié)議放回“網(wǎng)絡(luò)分層”里看才不會(huì)迷路剛開始看協(xié)議的時(shí)候最容易犯的錯(cuò)就是“單點(diǎn)學(xué)習(xí)”——今天看TCP明天看HTTP感覺每個(gè)都認(rèn)識(shí)但它們之間怎么協(xié)作、誰在誰的下層、誰為誰服務(wù)腦子里完全沒有概念。所以第一步必須先把網(wǎng)絡(luò)分層這個(gè)基礎(chǔ)框架搭起來否則后面聊的所有細(xì)節(jié)都是空中樓閣。1.1 四層模型和七層模型看哪個(gè)更實(shí)用教科書上最常見的兩個(gè)模型一個(gè)是OSI七層模型一個(gè)是TCP/IP四層模型。很多人糾結(jié)到底學(xué)哪個(gè)我的看法是OSI七層拿來理解“每一層是干嘛的”非常合適因?yàn)樗值眉?xì)概念清楚但實(shí)際工作中所有排障思路和數(shù)據(jù)流轉(zhuǎn)邏輯幾乎都是按TCP/IP四層模型來走的也就是應(yīng)用層、傳輸層、網(wǎng)絡(luò)層、網(wǎng)絡(luò)接口層這四層。舉個(gè)例子你在瀏覽器里輸入一個(gè)網(wǎng)址按下回車的那一刻實(shí)際上經(jīng)歷了一個(gè)完整的“打包”過程應(yīng)用層的HTTP協(xié)議先把你想要的資源請(qǐng)求格式化成一段文本然后傳輸層的TCP協(xié)議給這段數(shù)據(jù)加上端口信息并且為了保證可靠性還會(huì)做分段和編號(hào)接著網(wǎng)絡(luò)層的IP協(xié)議給它加上源地址和目的地址決定怎么在網(wǎng)絡(luò)里找路最后網(wǎng)絡(luò)接口層再把它封裝成能在網(wǎng)線上傳輸?shù)碾娦盘?hào)或光信號(hào)。這就是一次完整的數(shù)據(jù)“裝箱”過程。反過來接收端收到數(shù)據(jù)后每一層再負(fù)責(zé)“拆箱”層層剝開直到應(yīng)用層拿到原始的HTTP請(qǐng)求文本。理解了這個(gè)加減包裝的過程后面每一個(gè)協(xié)議你都能找到它準(zhǔn)確的位置。1.2 各協(xié)議之間的“依賴關(guān)系”到底是什么樣這幾類常用協(xié)議的關(guān)系我用一個(gè)最直白的比喻來概括IP是快遞公司的運(yùn)輸網(wǎng)絡(luò)負(fù)責(zé)把包裹從城市A運(yùn)到城市BTCP是快遞公司內(nèi)部的“簽收確認(rèn)機(jī)制”每一個(gè)包裹都要確認(rèn)收件人簽收沒簽收就重發(fā)HTTP則是包裹里裝的貨本身它是一段有特定格式的業(yè)務(wù)內(nèi)容DNS是快遞公司查地址的電話本你要寄件的時(shí)候先得通過它查到收件人的詳細(xì)地址IPSSH和FTP則是兩種不同規(guī)格的封裝服務(wù)一個(gè)負(fù)責(zé)遠(yuǎn)程安全操作一個(gè)負(fù)責(zé)傳文件。這個(gè)比喻并不完美但足夠幫你在腦子里建立一個(gè)坐標(biāo)系。實(shí)際使用中你會(huì)發(fā)現(xiàn)一個(gè)問題往往要跨多層去排查頁面打不開既可能是應(yīng)用層HTTP配置錯(cuò)了也可能是傳輸層TCP握手超時(shí)還可能是網(wǎng)絡(luò)層路由不可達(dá)。這就是為什么我強(qiáng)烈建議先把分層模型刻在腦子里——它是你排障時(shí)的第一張地圖。2. HTTP協(xié)議你每天都在用卻可能從來沒看透過HTTP大概是普通人最熟悉的協(xié)議了畢竟每次打開網(wǎng)頁、刷手機(jī)App背后都是它在工作。但熟悉不代表理解到位。很多人知道狀態(tài)碼200是成功、404是找不到但再往深一點(diǎn)問HTTP報(bào)文到底長什么樣、長連接和短連接有什么區(qū)別、Keep-Alive到底在做什么就說不清楚了。2.1 HTTP報(bào)文結(jié)構(gòu)拆解請(qǐng)求行、請(qǐng)求頭、請(qǐng)求體一個(gè)標(biāo)準(zhǔn)的HTTP請(qǐng)求報(bào)文分成三大部分請(qǐng)求行、請(qǐng)求頭、請(qǐng)求體。請(qǐng)求行在最前面包含請(qǐng)求方法GET、POST、PUT這些、請(qǐng)求的資源路徑以及協(xié)議版本號(hào)。比如GET /index.html HTTP/1.1就是最典型的一行。請(qǐng)求頭則是用鍵值對(duì)的方式攜帶一堆元信息比如Host訪問哪個(gè)域名、User-Agent你的瀏覽器/客戶端是什么、Content-Type你要發(fā)什么類型的數(shù)據(jù)、Cookie身份憑證等等。請(qǐng)求體一般只有POST類的請(qǐng)求才會(huì)有GET請(qǐng)求通常是沒有請(qǐng)求體的。響應(yīng)報(bào)文的格式也類似只不過請(qǐng)求行換成了狀態(tài)行包含協(xié)議版本、狀態(tài)碼和狀態(tài)描述。響應(yīng)頭里常見的像Content-Type返回內(nèi)容的類型、Content-Length返回體字節(jié)長度、Set-Cookie服務(wù)器要你存的Cookie。實(shí)際排查的時(shí)候看響應(yīng)頭比看狀態(tài)碼有意義得多。我以前遇到過一個(gè)問題接口時(shí)不時(shí)返回200但頁面內(nèi)容卻少了一截。抓包一看Content-Length和實(shí)際返回的響應(yīng)體字節(jié)數(shù)對(duì)不上最后定位到是某個(gè)網(wǎng)關(guān)在做內(nèi)容改寫時(shí)長度算錯(cuò)了。如果我不懂響應(yīng)頭里這些字段的含義這個(gè)問題根本無從下手。2.2 HTTP/1.1、HTTP/2、HTTP/3差異到底在哪HTTP/1.1是目前兼容性最廣的版本特點(diǎn)是每個(gè)請(qǐng)求-響應(yīng)默認(rèn)使用單獨(dú)的TCP連接也就是“短連接時(shí)代”的救星——Keep-Alive機(jī)制被引入了可以讓多個(gè)請(qǐng)求復(fù)用同一個(gè)TCP連接減少頻繁握手的開銷。但它的硬傷是隊(duì)頭阻塞Head-of-Line Blocking同一個(gè)連接里前一個(gè)請(qǐng)求沒返回后面的請(qǐng)求就只能排隊(duì)等。HTTP/2引入了多路復(fù)用可以在一個(gè)TCP連接里并行發(fā)送多個(gè)請(qǐng)求和響應(yīng)從機(jī)制上解決了應(yīng)用層的隊(duì)頭阻塞。同時(shí)它還做了頭部壓縮和二進(jìn)制分幀傳輸效率比HTTP/1.1高不少。但現(xiàn)在HTTP/2完美的落地場景在弱網(wǎng)環(huán)境下也暴露了新的問題——因?yàn)門CP本身丟包重傳的機(jī)制一個(gè)包的丟失會(huì)影響所有復(fù)用的請(qǐng)求這被稱為TCP層隊(duì)頭阻塞。HTTP/3直接換掉了底層傳輸協(xié)議改用基于UDP的QUIC協(xié)議。QUIC天然支持多路復(fù)用并且把加密握手和傳輸建立的過程合并了建連延遲大幅降低?，F(xiàn)在很多大流量場景已經(jīng)逐步切到HTTP/3。從我實(shí)測的情況看弱網(wǎng)環(huán)境下HTTP/3的重連和恢復(fù)速度確實(shí)比HTTP/2好很多尤其是跳網(wǎng)絡(luò)、切換Wi-Fi的場景。但HTTP/3的調(diào)試工具還不夠豐富平時(shí)抓包分析還是以HTTP/1.1和HTTP/2為主。2.3 HTTPS就是在HTTP外面套了一層TLS這個(gè)“套”很關(guān)鍵HTTPS本質(zhì)上就是“HTTP TLS”TLS負(fù)責(zé)加密、身份驗(yàn)證和完整性保護(hù)。從協(xié)議分層的角度看TLS位于HTTP和TCP之間。它的握手流程我已經(jīng)寫過很多次這里只說三個(gè)最容易被忽視的細(xì)節(jié)第一證書鏈校驗(yàn)?？蛻舳嗽谀玫椒?wù)器證書后不是直接信任而是一直向上追溯找到內(nèi)置在系統(tǒng)根證書庫里的根證書才能確認(rèn)這個(gè)證書是可信的。實(shí)際運(yùn)維中常見的報(bào)錯(cuò)“unable to get local issuer certificate”就是證書鏈不完整導(dǎo)致的服務(wù)器只發(fā)了自己的證書沒有把中間證書拼上去。第二會(huì)話復(fù)用。TLS握手費(fèi)用是很高的所以握手時(shí)雙方會(huì)協(xié)商一個(gè)“會(huì)話票據(jù)”下次連接直接復(fù)用會(huì)話密鑰省掉一次全握手。我在Nginx里調(diào)過ssl_session_cache在會(huì)話復(fù)用開啟的情況下短連接請(qǐng)求的握手開銷能降低三分之一左右對(duì)高并發(fā)的接口服務(wù)來說非常明顯。第三TLS握手超時(shí)和 TCP握手超時(shí)要區(qū)分對(duì)待。我踩過一個(gè)坑服務(wù)端負(fù)載高了以后TLS握手超時(shí)的報(bào)錯(cuò)遠(yuǎn)遠(yuǎn)多于TCP握手的報(bào)錯(cuò)。當(dāng)時(shí)一度認(rèn)為是網(wǎng)絡(luò)抖動(dòng)后來才發(fā)現(xiàn)是服務(wù)器的證書驗(yàn)證環(huán)節(jié)在做CPU密集運(yùn)算時(shí)性能下降直接拖慢了握手速度。3. TCP和IP整個(gè)互聯(lián)網(wǎng)的“地基”長什么樣如果說HTTP是快遞包裹上的面單那TCP和IP就是底下跑運(yùn)輸?shù)奈锪骶W(wǎng)絡(luò)。沒有它們面單寫得再漂亮也沒用。絕大多數(shù)網(wǎng)絡(luò)疑難雜癥最終都出在這兩層。3.1 TCP三次握手和四次揮手背后是兩種不同的思路TCP三次握手大家都背過SYN、SYNACK、ACK。但為什么要三次而不是兩次核心原因在于——TCP要保證“雙方都具備收發(fā)能力且彼此確認(rèn)對(duì)方的收發(fā)能力沒問題”。第一次握手客戶端告訴服務(wù)器“我發(fā)消息的能力正常”第二次握手服務(wù)器回應(yīng)“我收到了我的收和發(fā)都正?！钡谌挝帐挚蛻舳嗽倩貞?yīng)“我確認(rèn)你收到了我的發(fā)和收都正?！薄＿@樣雙方就對(duì)齊了一條雙向都可靠的通道。四次揮手更簡單因?yàn)門CP連接是雙向的所以每一方向的關(guān)閉都要單獨(dú)確認(rèn)。A告訴B“我不再發(fā)數(shù)據(jù)了”FINB回復(fù)“知道了”ACK然后B處理完剩余數(shù)據(jù)后也告訴A“我也不發(fā)了”FINA再回復(fù)“知道了”ACK。這樣每個(gè)方向獨(dú)立關(guān)閉是四次而不是三次的根本原因。排障時(shí)你會(huì)發(fā)現(xiàn)一個(gè)規(guī)律如果握手只成功了一半多半是服務(wù)器端有網(wǎng)絡(luò)層的ACL攔截或者防火墻把SYN包丟棄了如果握手完成但馬上斷開則往往是應(yīng)用層服務(wù)主動(dòng)拒絕了連接。這個(gè)經(jīng)驗(yàn)?zāi)軒湍憧焖俣ㄎ环较蚨皇窃谙到y(tǒng)里亂找一通。3.2 滑動(dòng)窗口、擁塞控制這兩個(gè)機(jī)制才是TCP的靈魂很多人學(xué)TCP只知道握手和揮手但TCP真正寶貴的是它如何以“不可靠的IP”為基礎(chǔ)實(shí)現(xiàn)“可靠且盡量高效”的傳輸。核心里就是兩個(gè)機(jī)制流量控制用的是滑動(dòng)窗口擁塞控制用的是慢啟動(dòng)、擁塞避免和快重傳/快恢復(fù)?；瑒?dòng)窗口的意思是接收方會(huì)通過ACK報(bào)文通告自己還剩多少緩沖空間窗口大小發(fā)送方根據(jù)這個(gè)窗口來控制自己能發(fā)多少數(shù)據(jù)不能一次性把數(shù)據(jù)全倒出去否則接收方來不及處理就會(huì)丟包。擁塞控制則是站在整個(gè)網(wǎng)絡(luò)的角度發(fā)送方不能一股腦灌數(shù)據(jù)而是通過“慢啟動(dòng)”逐步增加發(fā)送量探測網(wǎng)絡(luò)能承受的極限碰到丟包再快速收縮重新探測。有一回線上服務(wù)偶發(fā)性延遲升高抓包發(fā)現(xiàn)一個(gè)規(guī)律某個(gè)IP的TCP窗口反復(fù)出現(xiàn)劇烈收縮與此同時(shí)上游交換機(jī)有輕微的廣播風(fēng)暴。我們花了很久調(diào)應(yīng)用參數(shù)都沒用最后定位到是網(wǎng)卡驅(qū)動(dòng)在低隊(duì)列深度下頻繁觸發(fā)擁塞窗口收縮。這就是典型的“窗口機(jī)制問題”和業(yè)務(wù)代碼沒有任何關(guān)系。3.3 IP協(xié)議尋址、子網(wǎng)掩碼和路由三個(gè)詞吃透它IP協(xié)議的核心能力就一句話給每一臺(tái)設(shè)備一個(gè)唯一的邏輯地址并且提供跨網(wǎng)絡(luò)尋路的能力。IPv4地址是32位的寫成點(diǎn)分十進(jìn)制就是大家熟悉的192.168.1.1。IPv6是128位的寫成冒號(hào)分隔的十六進(jìn)制。子網(wǎng)掩碼解決的是“地址里的網(wǎng)絡(luò)部分和主機(jī)部分怎么切分”的問題。比如192.168.1.0/24這個(gè)/24就表示前24位是網(wǎng)絡(luò)部分后8位是主機(jī)部分。路由則是IP包從一個(gè)網(wǎng)絡(luò)跳到另一個(gè)網(wǎng)絡(luò)的尋路過程。你用traceroute可以清楚地看到包經(jīng)過的一個(gè)個(gè)網(wǎng)關(guān)。實(shí)際運(yùn)維時(shí)子網(wǎng)劃分是最容易出低級(jí)錯(cuò)誤的地方。比如A、B兩臺(tái)服務(wù)器地址分別是10.0.8.5和10.0.9.5掩碼都是255.255.255.0那它們分屬兩個(gè)網(wǎng)段需要跨網(wǎng)關(guān)通信。如果把掩碼錯(cuò)配成255.255.255.0去訪問10.0.9.0這個(gè)網(wǎng)段包就會(huì)被送到網(wǎng)關(guān)而不是直接走二層交換就會(huì)出現(xiàn)“ping得通網(wǎng)關(guān)、但業(yè)務(wù)連不上”這種詭異現(xiàn)象。4. 查域名要靠DNS但這個(gè)環(huán)節(jié)的坑遠(yuǎn)比你想象的多我見過很多開發(fā)者在本地調(diào)試HTTP接口時(shí)用IP訪問一切正常換成域名訪問就超時(shí)最后排查半天發(fā)現(xiàn)是DNS解析不穩(wěn)定。DNS看著簡單里面卻藏著一堆容易被忽略的細(xì)節(jié)。4.1 DNS解析的完整路徑遞歸查詢和迭代查詢當(dāng)你在瀏覽器里輸入一個(gè)域名完整的解析過程大概是這樣的瀏覽器會(huì)先查本地DNS緩存沒有就去問操作系統(tǒng)配置的Local DNS服務(wù)器也就是說你填的114.114.114.114或者8.8.8.8Local DNS服務(wù)器如果沒有緩存就會(huì)一級(jí)一級(jí)向上查詢。這個(gè)向上查詢的過程分兩種遞歸查詢和迭代查詢。通常來說客戶端對(duì)Local DNS發(fā)起的查詢是遞歸的你必須給我一個(gè)最終結(jié)果而Local DNS對(duì)根域名服務(wù)器、頂級(jí)域名服務(wù)器、權(quán)威域名服務(wù)器發(fā)起的查詢是迭代的我一次一次地問你們一次一次地指路。根服務(wù)器不會(huì)直接告訴你某個(gè)具體域名的IP它會(huì)告訴你“這個(gè)域名的頂級(jí)域歸誰管”指引你一層層往下走直到找到權(quán)威服務(wù)器拿到真正的解析結(jié)果。4.2 影響性能的TTL和令人頭疼的緩存污染TTLTime To Live是DNS記錄里的“存活時(shí)間”。它決定了這條解析結(jié)果能被子設(shè)備緩存多久。如果TTL設(shè)置太短訪問量大的話Local DNS的壓力會(huì)劇增設(shè)置太長又會(huì)導(dǎo)致你切換服務(wù)器IP之后老解析結(jié)果遲遲不失效用戶一直訪問舊地址。我有一回切換服務(wù)器提前改好了DNS記錄但業(yè)務(wù)方還是反映舊地址能通、新地址訪問不了持續(xù)了將近兩個(gè)小時(shí)。去查才發(fā)現(xiàn)那條A記錄的TTL原來被設(shè)成了7200秒也就是說最長要2小時(shí)才會(huì)全網(wǎng)生效。后來我養(yǎng)成了習(xí)慣做大的IP切換前提前幾天把TTL調(diào)低到300秒等切換完成后再調(diào)回來這個(gè)操作能幫你大幅縮短“切換陣痛期”。4.3 DNS服務(wù)選型和防污染經(jīng)驗(yàn)個(gè)人項(xiàng)目或小型業(yè)務(wù)用系統(tǒng)自帶的systemd-resolved或直接指公共DNS一般就夠用了。到了正式生產(chǎn)環(huán)境我還是建議自建內(nèi)網(wǎng)DNS常見的方案是CoreDNS搭配緩存層。內(nèi)網(wǎng)域名解析走內(nèi)網(wǎng)DNS外網(wǎng)域名解析再轉(zhuǎn)發(fā)到公共DNS這樣既快又可控還可以加一些自定義的解析規(guī)則比如內(nèi)部服務(wù)直接解析到內(nèi)網(wǎng)IP。真正麻煩的是緩存污染問題。公共DNS在極端情況下可能返回不正確的解析結(jié)果導(dǎo)致域名被指向錯(cuò)誤IP。我在本地開發(fā)機(jī)上遇到過一次某個(gè)SaaS平臺(tái)的域名解析到了一個(gè)陌生的IP瀏覽器直接攔截報(bào)警。排查方式很簡單用dig 8.8.8.8 example.com和dig 內(nèi)網(wǎng)DNS example.com對(duì)比解析結(jié)果如果差異明顯基本就能鎖定是誰的解析出了問題。這里也建議生產(chǎn)環(huán)境的服務(wù)器不要混用不同運(yùn)營商的公共DNS解析行為不一致會(huì)浪費(fèi)大量排障時(shí)間。5. SSH遠(yuǎn)程管理的“安全通道”但別只在Login時(shí)才想起它SSHSecure Shell大概是運(yùn)維工具箱里使用率最高的協(xié)議了基本所有服務(wù)器管理都依賴它。但它絕不只是“輸入密碼然后敲命令”這么簡單。5.1 對(duì)稱加密、非對(duì)稱加密和會(huì)話密鑰SSH的連接建立過程完美演繹了三類密碼學(xué)應(yīng)用的配合用非對(duì)稱加密通常是RSA或ECDSA實(shí)現(xiàn)身份認(rèn)證和對(duì)密鑰協(xié)商過程進(jìn)行簽名保護(hù)保證“和我通信的確實(shí)是那臺(tái)服務(wù)器”。用Diffie-Hellman密鑰交換算法在不安全的網(wǎng)絡(luò)上協(xié)商出一個(gè)雙方共享的“會(huì)話密鑰”。后續(xù)所有數(shù)據(jù)都用這個(gè)會(huì)話密鑰進(jìn)行對(duì)稱加密傳輸因?yàn)閷?duì)稱加密速度快適合大數(shù)據(jù)量通信。密鑰交換的算法細(xì)節(jié)很多人覺得枯燥但理解它能幫你解釋不少安全告警。比如你第一次連某臺(tái)服務(wù)器時(shí)會(huì)看到The authenticity of host ... cant be established的警告就是因?yàn)槟氵€沒有保存它的主機(jī)公鑰。如果后期再彈出提示說IP地址對(duì)應(yīng)的主機(jī)密鑰變了那就要立刻警惕是否有中間人劫持了你的連接千萬別習(xí)慣性地點(diǎn)“yes”跳過。5.2 密鑰登錄配置步驟和密碼登錄的風(fēng)險(xiǎn)點(diǎn)生產(chǎn)環(huán)境強(qiáng)烈建議關(guān)閉密碼登錄、改用密鑰對(duì)。我的配置鏈路是這樣的在本地生成密鑰對(duì)ssh-keygen -t ed25519 -C your_comment -f ~/.ssh/id_ed25519現(xiàn)在我都用ed25519替代RSA因?yàn)樗拿荑€短、生成快、安全性夠用。RSA密鑰如果要用建議至少4096位。把公鑰安裝到服務(wù)器目標(biāo)用戶的~/.ssh/authorized_keys文件里ssh-copy-id -i ~/.ssh/id_ed25519.pub userserver_ip修改服務(wù)端配置/etc/ssh/sshd_configPasswordAuthentication no PermitRootLogin no重啟SSH服務(wù)sudo systemctl restart sshd這里有個(gè)致命細(xì)節(jié)很多人改完配置直接斷開當(dāng)前連接結(jié)果密鑰認(rèn)證沒生效密碼又被禁了人直接“失聯(lián)”。我自己的習(xí)慣是先用一個(gè)終端保留現(xiàn)有登錄會(huì)話另外一個(gè)終端用新配置重新連接確認(rèn)新會(huì)話正常成功后再關(guān)掉舊連接。5.3 SSH隧道端口轉(zhuǎn)發(fā)的高級(jí)用法SSH隧道是很多人的“隱藏技能”它可以把一個(gè)不安全的網(wǎng)絡(luò)流量封裝進(jìn)SSH加密通道里。本地轉(zhuǎn)發(fā): 把遠(yuǎn)程服務(wù)器的某個(gè)端口映射到本機(jī)。ssh -L 8080:internal-service:80 userjump-server這樣我訪問本地的8080端口數(shù)據(jù)會(huì)經(jīng)過跳板機(jī)再轉(zhuǎn)發(fā)到內(nèi)網(wǎng)目標(biāo)的80端口。遠(yuǎn)程轉(zhuǎn)發(fā): 把本機(jī)的某個(gè)端口暴露到遠(yuǎn)端。這個(gè)場景適合你把本地的開發(fā)服務(wù)臨時(shí)暴露給遠(yuǎn)程同事訪問。實(shí)際使用中用跳板機(jī)管理多臺(tái)內(nèi)網(wǎng)服務(wù)器時(shí)SSH隧道幾乎是標(biāo)配。但我必須提醒跳躍轉(zhuǎn)發(fā)配置不好容易搞混端口方向建議把常用的隧道配置寫進(jìn)~/.ssh/config文件里用別名調(diào)用比每次敲一長串命令穩(wěn)妥得多。6. FTP文件的“老牌”傳輸協(xié)議它為什么還沒死FTP文件傳輸協(xié)議誕生得非常早在HTTP還沒普及的年代它就是互聯(lián)網(wǎng)上分享文件的主要方式。哪怕到了今天很多老舊系統(tǒng)、打印機(jī)、嵌入式設(shè)備里仍然只認(rèn)FTP。但它的缺點(diǎn)也很致命所有數(shù)據(jù)和控制指令默認(rèn)不加密。6.1 主動(dòng)模式vs被動(dòng)模式連接方向的反直覺之處FTP比HTTP復(fù)雜的地方在于它有兩條連接一條是控制連接走21端口一條是數(shù)據(jù)連接根據(jù)模式走不同端口。初次接觸的人十有八九會(huì)被主動(dòng)模式和被動(dòng)模式繞暈。主動(dòng)模式Active客戶端告訴服務(wù)器“我在聽某個(gè)端口你連過來”。所以數(shù)據(jù)連接由服務(wù)器主動(dòng)發(fā)起方向是服務(wù)器連客戶端的隨緣端口。這在大多數(shù)客戶端處于NAT或防火墻后面的場景下會(huì)失敗。被動(dòng)模式Passive服務(wù)器告訴客戶端“我在聽某個(gè)端口你連過來”。數(shù)據(jù)連接由客戶端發(fā)起方向?qū)ΜF(xiàn)代網(wǎng)絡(luò)環(huán)境友好得多所以現(xiàn)在主流FTP客戶端默認(rèn)都是被動(dòng)模式。這個(gè)知識(shí)點(diǎn)是排查FTP“能登錄但列不出目錄”的關(guān)鍵。很多FTP排障的第一反應(yīng)就是檢查21端口通不通但目錄列表失敗往往發(fā)生在數(shù)據(jù)連接上。如果服務(wù)器防火墻沒放行被動(dòng)模式端口段客戶端能登錄成功卻卡在LIST目錄超時(shí)上。6.2 FTP vs SFTP別把它們搞混了很多人以為SFTP是“FTP的安全版”這個(gè)說法不嚴(yán)謹(jǐn)。準(zhǔn)確地說SFTP是“SSH文件傳輸協(xié)議”SSH File Transfer Protocol它完全運(yùn)行在SSH協(xié)議之上不是傳統(tǒng)FTP加了一個(gè)加密層。這意味著SFTP不需要單獨(dú)的21端口和被動(dòng)模式端口段只占用22端口配置和防火墻策略都簡單得多。所以我在新項(xiàng)目里幾乎不會(huì)主動(dòng)推薦使用FTP除非是為了兼容那批老設(shè)備。如果只是普通服務(wù)器之間的文件傳輸SFTP是更穩(wěn)的選擇如果要傳大量數(shù)據(jù)且要求斷點(diǎn)續(xù)傳、并發(fā)分片那更合適的是專門的文件傳輸工具或?qū)ο蟠鎯?chǔ)方案。FTP的價(jià)值在于它足夠簡單、足夠通用并且很多老牌自動(dòng)化腳本里還有它的位置。6.3 搭建一個(gè)安全的FTP/SFTP服務(wù)的幾個(gè)注意點(diǎn)如果是自建FTP我建議至少做到這幾點(diǎn)使用被動(dòng)模式并把服務(wù)器防火墻和數(shù)據(jù)連接的端口段統(tǒng)一放行。為FTP用戶設(shè)置目錄禁錮chroot避免登錄用戶可以跑到系統(tǒng)其他目錄里。配置文件傳輸日志至少保留上傳、下載、刪除的審計(jì)記錄。如果可以優(yōu)先選擇SFTP替代FTP。我?guī)湍硞€(gè)客戶搭過一套文件交換服務(wù)對(duì)方因?yàn)闅v史原因必須用FTP我就把VSFTPD配成被動(dòng)模式限制端口段在50000-50100然后防火墻只開放21端口和這個(gè)端口段。上線后很穩(wěn)唯一要注意的就是端口段別和別的服務(wù)沖突以及每一個(gè)被動(dòng)連接都會(huì)占用一個(gè)端口端口段大小要按并發(fā)連接數(shù)來規(guī)劃。7. 協(xié)議排障抓包工具實(shí)戰(zhàn)與問題定位思路最后這部分我想把前面說的所有協(xié)議知識(shí)串起來落到一個(gè)最實(shí)際的話題——網(wǎng)絡(luò)出了問題怎么一步步定位這個(gè)過程里最有用的工具就是抓包和分析工具。7.1 幾種常用抓包工具對(duì)比以及什么時(shí)候用誰tcpdump: 命令行抓包工具輕量、適合在服務(wù)器上直接用。我最常的用法tcpdump -i eth0 -nn port 443 -w https.pcap抓完用-r參數(shù)讀回再用Wireshark打開分析。Wireshark: 圖形化分析工具適合看TCP流、TLS握手、HTTP詳情。過濾器語法http.request.method POST或者tcp.analysis.flags能快速定位問題包。瀏覽器的DevTools: 只適合看應(yīng)用層HTTP請(qǐng)求不涉及傳輸層細(xì)節(jié)。排查前后端接口問題時(shí)最方便但不適合深挖鏈路層。ping和traceroute: 不屬于抓包工具但每次排障我開場都要用。它們能快速判定“通不通”以及“走了哪條路”。7.2 經(jīng)典故障實(shí)錄從HTTP超時(shí)到TCP重傳的定位過程這里分享一個(gè)我之前真實(shí)處理過的模擬項(xiàng)目X某跨平臺(tái)系統(tǒng)排障實(shí)錄。現(xiàn)象是某個(gè)接口在高峰期從平均200ms飆升到3秒偶爾直接超時(shí)。我按順序做了這么幾步第一步看是不是后端應(yīng)用慢。在服務(wù)器上直接curl接口返回很快排除應(yīng)用層瓶頸。第二步懷疑是網(wǎng)絡(luò)問題。在客戶端機(jī)器延遲到服務(wù)器發(fā)現(xiàn)延遲并不高但抓包的時(shí)候看到大量TCP重復(fù)ACK和Dup ACK說明傳輸過程中發(fā)生了丟包。第三步用traceroute追蹤路徑發(fā)現(xiàn)某個(gè)中間網(wǎng)關(guān)節(jié)點(diǎn)延遲飆升偶發(fā)丟包。聯(lián)系那個(gè)節(jié)點(diǎn)對(duì)應(yīng)的網(wǎng)絡(luò)方處理同時(shí)調(diào)整了TCP擁塞控制算法從默認(rèn)的cubic換成了bbr問題得到明顯緩解。這個(gè)案例最值得記的是排查順序從上層往下層一層層剝應(yīng)用層沒問題就往傳輸層查傳輸層可疑就往網(wǎng)絡(luò)層查不要一上來就“懷疑代碼”。7.3 常用協(xié)議問題速查表我整理了一張速查表遇到問題時(shí)可以直接對(duì)照定位方向現(xiàn)象可能涉及的協(xié)議層首要排查方向域名解析失敗DNS確認(rèn)DNS服務(wù)器、緩存、域名是否有A記錄頁面能打開但接口超時(shí)HTTP/TCP看接口耗時(shí)、TCP重傳率、后端處理時(shí)長連不上服務(wù)器SSH/TCP/IP確認(rèn)端口放行、IP可達(dá)、防火墻策略FTP能登錄但列舉目錄失敗FTP被動(dòng)模式檢查數(shù)據(jù)連接端口段是否放行瀏覽器報(bào)證書錯(cuò)誤TLS檢查證書鏈?zhǔn)欠裢暾?、證書是否過期訪問很慢但CPU和內(nèi)存都不高TCP擁塞控制/IP路由檢查丟包率traceroute定位中間鏈路域名解析正常但業(yè)務(wù)異常DNS緩存對(duì)比多個(gè)DNS解析結(jié)果、清理本地緩存這張表不是萬能答案但能幫你把“毫無頭緒”收斂成“先查某個(gè)方向”尤其是新手對(duì)著表格一步步來大概率能避免一上來就亂抓瞎。7.4 零散但好用的協(xié)議配置細(xì)節(jié)最后分享幾個(gè)零散但很實(shí)用的配置細(xì)節(jié)都是我實(shí)際工作中攢下來的第一HTTP的Keep-Alive不是沒有代價(jià)的。長連接會(huì)占用連接文件描述符如果服務(wù)端并發(fā)連接數(shù)配置太小小心出現(xiàn)“大量TIME_WAIT連接不釋放”的問題。用ss -s看看當(dāng)前連接狀態(tài)分布如果TIME_WAIT積壓嚴(yán)重可以調(diào)整內(nèi)核參數(shù)net.ipv4.tcp_tw_reuse復(fù)制策略。第二TCP的Nagle算法和延遲ACK機(jī)制在某些小包場景下會(huì)互相“打架”。如果你遇到“發(fā)一個(gè)包要等200ms才能收到響應(yīng)”這種詭異延遲并且確認(rèn)代碼里沒有問題可以考慮在服務(wù)端關(guān)閉Nagle算法也就是設(shè)置TCP_NODELAY。在Nginx配置里對(duì)應(yīng)的是tcp_nodelay on;。第三MTU問題雖然老但從沒消失過。如果發(fā)現(xiàn)“大數(shù)據(jù)包不通、小數(shù)據(jù)包正?！眱?yōu)先懷疑MTU不匹配。常見的鏈路MTU是1500但如果走了某個(gè)隧道或者特殊網(wǎng)絡(luò)環(huán)境MTU可能會(huì)變小導(dǎo)致分片問題。用ping -M do -s 1400這類參數(shù)可以快速測出實(shí)際可用的包大小邊界。第四IPv6在現(xiàn)在的網(wǎng)絡(luò)環(huán)境里已經(jīng)非常普遍了但很多服務(wù)配置時(shí)根本不注意它。如果你的服務(wù)器配置了IPv6地址但防火墻策略只放行了IPv4你會(huì)發(fā)現(xiàn)“4通的域名6完全不通”或者反過來。排障時(shí)記得把兩個(gè)協(xié)議棧分開驗(yàn)證不要籠統(tǒng)地認(rèn)為“通了就行”。寫在最后的小體會(huì)協(xié)議這東西只靠背概念是留不住的。我自己的經(jīng)驗(yàn)是每學(xué)一個(gè)協(xié)議就親手用抓包工具看一眼它的真實(shí)報(bào)文。比如你親眼看過TCP三次握手的三條包長什么樣、親眼看過一次TLS握手交互了哪些證書信息這些知識(shí)就變成你自己的了。尤其是做應(yīng)用開發(fā)的遇到網(wǎng)絡(luò)層面的問題不要急著懷疑“是不是運(yùn)維那邊搞的鬼”也別一上來就改代碼。先靜下心按“應(yīng)用層→傳輸層→網(wǎng)絡(luò)層”的順序逐層確認(rèn)絕大多數(shù)問題都能有一個(gè)清晰結(jié)論。希望這篇梳理能幫你建立起自己的排障地圖下次再遇到網(wǎng)絡(luò)問題腦子里就有畫面感了。 核心網(wǎng)絡(luò)協(xié)議梳理與排障實(shí)戰(zhàn)：HTTP、TCP/IP、DNS、SSH、FTP
網(wǎng)絡(luò)協(xié)議這東西平時(shí)不接觸的人覺得它高高在上接觸了又覺得知識(shí)點(diǎn)碎得跟散沙一樣。但其實(shí)不管你是做開發(fā)的、搞運(yùn)維的還是偶爾需要自己折騰一下服務(wù)器、翻翻路由器配置的“興趣型工程師”只要能把HTTP、IP、SSH、FTP、DNS、TCP這幾個(gè)核心協(xié)議徹底弄明白整個(gè)網(wǎng)絡(luò)的骨架也就搭起來了。我最早開始系統(tǒng)梳理這些協(xié)議是因?yàn)楸灰粋€(gè)線上的詭異問題折磨了一整晚頁面間歇性打不開看服務(wù)器日志一切正常程序也沒報(bào)錯(cuò)。最后抓包才發(fā)現(xiàn)是TCP握手的重傳機(jī)制在特定網(wǎng)絡(luò)環(huán)境下瘋狂觸發(fā)和HTTP層的請(qǐng)求邏輯完全無關(guān)。那次之后我意識(shí)到不把協(xié)議棧吃透出了問題就只能瞎猜。這篇文章就是基于我個(gè)人踩坑和日常排查經(jīng)驗(yàn)做的一次系統(tǒng)梳理。我不打算按教科書式的“逐層背誦”來寫而是把每個(gè)協(xié)議放到真實(shí)場景里講清楚它解決什么問題、有哪些關(guān)鍵機(jī)制、實(shí)際使用中容易踩哪些坑。無論是剛?cè)腴T的新手還是想補(bǔ)全盲區(qū)的老手都能在里邊找到有用的東西。1. 把這些協(xié)議放回“網(wǎng)絡(luò)分層”里看才不會(huì)迷路剛開始看協(xié)議的時(shí)候最容易犯的錯(cuò)就是“單點(diǎn)學(xué)習(xí)”——今天看TCP明天看HTTP感覺每個(gè)都認(rèn)識(shí)但它們之間怎么協(xié)作、誰在誰的下層、誰為誰服務(wù)腦子里完全沒有概念。所以第一步必須先把網(wǎng)絡(luò)分層這個(gè)基礎(chǔ)框架搭起來否則后面聊的所有細(xì)節(jié)都是空中樓閣。1.1 四層模型和七層模型看哪個(gè)更實(shí)用教科書上最常見的兩個(gè)模型一個(gè)是OSI七層模型一個(gè)是TCP/IP四層模型。很多人糾結(jié)到底學(xué)哪個(gè)我的看法是OSI七層拿來理解“每一層是干嘛的”非常合適因?yàn)樗值眉?xì)概念清楚但實(shí)際工作中所有排障思路和數(shù)據(jù)流轉(zhuǎn)邏輯幾乎都是按TCP/IP四層模型來走的也就是應(yīng)用層、傳輸層、網(wǎng)絡(luò)層、網(wǎng)絡(luò)接口層這四層。舉個(gè)例子你在瀏覽器里輸入一個(gè)網(wǎng)址按下回車的那一刻實(shí)際上經(jīng)歷了一個(gè)完整的“打包”過程應(yīng)用層的HTTP協(xié)議先把你想要的資源請(qǐng)求格式化成一段文本然后傳輸層的TCP協(xié)議給這段數(shù)據(jù)加上端口信息并且為了保證可靠性還會(huì)做分段和編號(hào)接著網(wǎng)絡(luò)層的IP協(xié)議給它加上源地址和目的地址決定怎么在網(wǎng)絡(luò)里找路最后網(wǎng)絡(luò)接口層再把它封裝成能在網(wǎng)線上傳輸?shù)碾娦盘?hào)或光信號(hào)。這就是一次完整的數(shù)據(jù)“裝箱”過程。反過來接收端收到數(shù)據(jù)后每一層再負(fù)責(zé)“拆箱”層層剝開直到應(yīng)用層拿到原始的HTTP請(qǐng)求文本。理解了這個(gè)加減包裝的過程后面每一個(gè)協(xié)議你都能找到它準(zhǔn)確的位置。1.2 各協(xié)議之間的“依賴關(guān)系”到底是什么樣這幾類常用協(xié)議的關(guān)系我用一個(gè)最直白的比喻來概括IP是快遞公司的運(yùn)輸網(wǎng)絡(luò)負(fù)責(zé)把包裹從城市A運(yùn)到城市BTCP是快遞公司內(nèi)部的“簽收確認(rèn)機(jī)制”每一個(gè)包裹都要確認(rèn)收件人簽收沒簽收就重發(fā)HTTP則是包裹里裝的貨本身它是一段有特定格式的業(yè)務(wù)內(nèi)容DNS是快遞公司查地址的電話本你要寄件的時(shí)候先得通過它查到收件人的詳細(xì)地址IPSSH和FTP則是兩種不同規(guī)格的封裝服務(wù)一個(gè)負(fù)責(zé)遠(yuǎn)程安全操作一個(gè)負(fù)責(zé)傳文件。這個(gè)比喻并不完美但足夠幫你在腦子里建立一個(gè)坐標(biāo)系。實(shí)際使用中你會(huì)發(fā)現(xiàn)一個(gè)問題往往要跨多層去排查頁面打不開既可能是應(yīng)用層HTTP配置錯(cuò)了也可能是傳輸層TCP握手超時(shí)還可能是網(wǎng)絡(luò)層路由不可達(dá)。這就是為什么我強(qiáng)烈建議先把分層模型刻在腦子里——它是你排障時(shí)的第一張地圖。2. HTTP協(xié)議你每天都在用卻可能從來沒看透過HTTP大概是普通人最熟悉的協(xié)議了畢竟每次打開網(wǎng)頁、刷手機(jī)App背后都是它在工作。但熟悉不代表理解到位。很多人知道狀態(tài)碼200是成功、404是找不到但再往深一點(diǎn)問HTTP報(bào)文到底長什么樣、長連接和短連接有什么區(qū)別、Keep-Alive到底在做什么就說不清楚了。2.1 HTTP報(bào)文結(jié)構(gòu)拆解請(qǐng)求行、請(qǐng)求頭、請(qǐng)求體一個(gè)標(biāo)準(zhǔn)的HTTP請(qǐng)求報(bào)文分成三大部分請(qǐng)求行、請(qǐng)求頭、請(qǐng)求體。請(qǐng)求行在最前面包含請(qǐng)求方法GET、POST、PUT這些、請(qǐng)求的資源路徑以及協(xié)議版本號(hào)。比如GET /index.html HTTP/1.1就是最典型的一行。請(qǐng)求頭則是用鍵值對(duì)的方式攜帶一堆元信息比如Host訪問哪個(gè)域名、User-Agent你的瀏覽器/客戶端是什么、Content-Type你要發(fā)什么類型的數(shù)據(jù)、Cookie身份憑證等等。請(qǐng)求體一般只有POST類的請(qǐng)求才會(huì)有GET請(qǐng)求通常是沒有請(qǐng)求體的。響應(yīng)報(bào)文的格式也類似只不過請(qǐng)求行換成了狀態(tài)行包含協(xié)議版本、狀態(tài)碼和狀態(tài)描述。響應(yīng)頭里常見的像Content-Type返回內(nèi)容的類型、Content-Length返回體字節(jié)長度、Set-Cookie服務(wù)器要你存的Cookie。實(shí)際排查的時(shí)候看響應(yīng)頭比看狀態(tài)碼有意義得多。我以前遇到過一個(gè)問題接口時(shí)不時(shí)返回200但頁面內(nèi)容卻少了一截。抓包一看Content-Length和實(shí)際返回的響應(yīng)體字節(jié)數(shù)對(duì)不上最后定位到是某個(gè)網(wǎng)關(guān)在做內(nèi)容改寫時(shí)長度算錯(cuò)了。如果我不懂響應(yīng)頭里這些字段的含義這個(gè)問題根本無從下手。2.2 HTTP/1.1、HTTP/2、HTTP/3差異到底在哪HTTP/1.1是目前兼容性最廣的版本特點(diǎn)是每個(gè)請(qǐng)求-響應(yīng)默認(rèn)使用單獨(dú)的TCP連接也就是“短連接時(shí)代”的救星——Keep-Alive機(jī)制被引入了可以讓多個(gè)請(qǐng)求復(fù)用同一個(gè)TCP連接減少頻繁握手的開銷。但它的硬傷是隊(duì)頭阻塞Head-of-Line Blocking同一個(gè)連接里前一個(gè)請(qǐng)求沒返回后面的請(qǐng)求就只能排隊(duì)等。HTTP/2引入了多路復(fù)用可以在一個(gè)TCP連接里并行發(fā)送多個(gè)請(qǐng)求和響應(yīng)從機(jī)制上解決了應(yīng)用層的隊(duì)頭阻塞。同時(shí)它還做了頭部壓縮和二進(jìn)制分幀傳輸效率比HTTP/1.1高不少。但現(xiàn)在HTTP/2完美的落地場景在弱網(wǎng)環(huán)境下也暴露了新的問題——因?yàn)門CP本身丟包重傳的機(jī)制一個(gè)包的丟失會(huì)影響所有復(fù)用的請(qǐng)求這被稱為TCP層隊(duì)頭阻塞。HTTP/3直接換掉了底層傳輸協(xié)議改用基于UDP的QUIC協(xié)議。QUIC天然支持多路復(fù)用并且把加密握手和傳輸建立的過程合并了建連延遲大幅降低?，F(xiàn)在很多大流量場景已經(jīng)逐步切到HTTP/3。從我實(shí)測的情況看弱網(wǎng)環(huán)境下HTTP/3的重連和恢復(fù)速度確實(shí)比HTTP/2好很多尤其是跳網(wǎng)絡(luò)、切換Wi-Fi的場景。但HTTP/3的調(diào)試工具還不夠豐富平時(shí)抓包分析還是以HTTP/1.1和HTTP/2為主。2.3 HTTPS就是在HTTP外面套了一層TLS這個(gè)“套”很關(guān)鍵HTTPS本質(zhì)上就是“HTTP TLS”TLS負(fù)責(zé)加密、身份驗(yàn)證和完整性保護(hù)。從協(xié)議分層的角度看TLS位于HTTP和TCP之間。它的握手流程我已經(jīng)寫過很多次這里只說三個(gè)最容易被忽視的細(xì)節(jié)第一證書鏈校驗(yàn)?？蛻舳嗽谀玫椒?wù)器證書后不是直接信任而是一直向上追溯找到內(nèi)置在系統(tǒng)根證書庫里的根證書才能確認(rèn)這個(gè)證書是可信的。實(shí)際運(yùn)維中常見的報(bào)錯(cuò)“unable to get local issuer certificate”就是證書鏈不完整導(dǎo)致的服務(wù)器只發(fā)了自己的證書沒有把中間證書拼上去。第二會(huì)話復(fù)用。TLS握手費(fèi)用是很高的所以握手時(shí)雙方會(huì)協(xié)商一個(gè)“會(huì)話票據(jù)”下次連接直接復(fù)用會(huì)話密鑰省掉一次全握手。我在Nginx里調(diào)過ssl_session_cache在會(huì)話復(fù)用開啟的情況下短連接請(qǐng)求的握手開銷能降低三分之一左右對(duì)高并發(fā)的接口服務(wù)來說非常明顯。第三TLS握手超時(shí)和 TCP握手超時(shí)要區(qū)分對(duì)待。我踩過一個(gè)坑服務(wù)端負(fù)載高了以后TLS握手超時(shí)的報(bào)錯(cuò)遠(yuǎn)遠(yuǎn)多于TCP握手的報(bào)錯(cuò)。當(dāng)時(shí)一度認(rèn)為是網(wǎng)絡(luò)抖動(dòng)后來才發(fā)現(xiàn)是服務(wù)器的證書驗(yàn)證環(huán)節(jié)在做CPU密集運(yùn)算時(shí)性能下降直接拖慢了握手速度。3. TCP和IP整個(gè)互聯(lián)網(wǎng)的“地基”長什么樣如果說HTTP是快遞包裹上的面單那TCP和IP就是底下跑運(yùn)輸?shù)奈锪骶W(wǎng)絡(luò)。沒有它們面單寫得再漂亮也沒用。絕大多數(shù)網(wǎng)絡(luò)疑難雜癥最終都出在這兩層。3.1 TCP三次握手和四次揮手背后是兩種不同的思路TCP三次握手大家都背過SYN、SYNACK、ACK。但為什么要三次而不是兩次核心原因在于——TCP要保證“雙方都具備收發(fā)能力且彼此確認(rèn)對(duì)方的收發(fā)能力沒問題”。第一次握手客戶端告訴服務(wù)器“我發(fā)消息的能力正常”第二次握手服務(wù)器回應(yīng)“我收到了我的收和發(fā)都正?！钡谌挝帐挚蛻舳嗽倩貞?yīng)“我確認(rèn)你收到了我的發(fā)和收都正?！薄＿@樣雙方就對(duì)齊了一條雙向都可靠的通道。四次揮手更簡單因?yàn)門CP連接是雙向的所以每一方向的關(guān)閉都要單獨(dú)確認(rèn)。A告訴B“我不再發(fā)數(shù)據(jù)了”FINB回復(fù)“知道了”ACK然后B處理完剩余數(shù)據(jù)后也告訴A“我也不發(fā)了”FINA再回復(fù)“知道了”ACK。這樣每個(gè)方向獨(dú)立關(guān)閉是四次而不是三次的根本原因。排障時(shí)你會(huì)發(fā)現(xiàn)一個(gè)規(guī)律如果握手只成功了一半多半是服務(wù)器端有網(wǎng)絡(luò)層的ACL攔截或者防火墻把SYN包丟棄了如果握手完成但馬上斷開則往往是應(yīng)用層服務(wù)主動(dòng)拒絕了連接。這個(gè)經(jīng)驗(yàn)?zāi)軒湍憧焖俣ㄎ环较蚨皇窃谙到y(tǒng)里亂找一通。3.2 滑動(dòng)窗口、擁塞控制這兩個(gè)機(jī)制才是TCP的靈魂很多人學(xué)TCP只知道握手和揮手但TCP真正寶貴的是它如何以“不可靠的IP”為基礎(chǔ)實(shí)現(xiàn)“可靠且盡量高效”的傳輸。核心里就是兩個(gè)機(jī)制流量控制用的是滑動(dòng)窗口擁塞控制用的是慢啟動(dòng)、擁塞避免和快重傳/快恢復(fù)?；瑒?dòng)窗口的意思是接收方會(huì)通過ACK報(bào)文通告自己還剩多少緩沖空間窗口大小發(fā)送方根據(jù)這個(gè)窗口來控制自己能發(fā)多少數(shù)據(jù)不能一次性把數(shù)據(jù)全倒出去否則接收方來不及處理就會(huì)丟包。擁塞控制則是站在整個(gè)網(wǎng)絡(luò)的角度發(fā)送方不能一股腦灌數(shù)據(jù)而是通過“慢啟動(dòng)”逐步增加發(fā)送量探測網(wǎng)絡(luò)能承受的極限碰到丟包再快速收縮重新探測。有一回線上服務(wù)偶發(fā)性延遲升高抓包發(fā)現(xiàn)一個(gè)規(guī)律某個(gè)IP的TCP窗口反復(fù)出現(xiàn)劇烈收縮與此同時(shí)上游交換機(jī)有輕微的廣播風(fēng)暴。我們花了很久調(diào)應(yīng)用參數(shù)都沒用最后定位到是網(wǎng)卡驅(qū)動(dòng)在低隊(duì)列深度下頻繁觸發(fā)擁塞窗口收縮。這就是典型的“窗口機(jī)制問題”和業(yè)務(wù)代碼沒有任何關(guān)系。3.3 IP協(xié)議尋址、子網(wǎng)掩碼和路由三個(gè)詞吃透它IP協(xié)議的核心能力就一句話給每一臺(tái)設(shè)備一個(gè)唯一的邏輯地址并且提供跨網(wǎng)絡(luò)尋路的能力。IPv4地址是32位的寫成點(diǎn)分十進(jìn)制就是大家熟悉的192.168.1.1。IPv6是128位的寫成冒號(hào)分隔的十六進(jìn)制。子網(wǎng)掩碼解決的是“地址里的網(wǎng)絡(luò)部分和主機(jī)部分怎么切分”的問題。比如192.168.1.0/24這個(gè)/24就表示前24位是網(wǎng)絡(luò)部分后8位是主機(jī)部分。路由則是IP包從一個(gè)網(wǎng)絡(luò)跳到另一個(gè)網(wǎng)絡(luò)的尋路過程。你用traceroute可以清楚地看到包經(jīng)過的一個(gè)個(gè)網(wǎng)關(guān)。實(shí)際運(yùn)維時(shí)子網(wǎng)劃分是最容易出低級(jí)錯(cuò)誤的地方。比如A、B兩臺(tái)服務(wù)器地址分別是10.0.8.5和10.0.9.5掩碼都是255.255.255.0那它們分屬兩個(gè)網(wǎng)段需要跨網(wǎng)關(guān)通信。如果把掩碼錯(cuò)配成255.255.255.0去訪問10.0.9.0這個(gè)網(wǎng)段包就會(huì)被送到網(wǎng)關(guān)而不是直接走二層交換就會(huì)出現(xiàn)“ping得通網(wǎng)關(guān)、但業(yè)務(wù)連不上”這種詭異現(xiàn)象。4. 查域名要靠DNS但這個(gè)環(huán)節(jié)的坑遠(yuǎn)比你想象的多我見過很多開發(fā)者在本地調(diào)試HTTP接口時(shí)用IP訪問一切正常換成域名訪問就超時(shí)最后排查半天發(fā)現(xiàn)是DNS解析不穩(wěn)定。DNS看著簡單里面卻藏著一堆容易被忽略的細(xì)節(jié)。4.1 DNS解析的完整路徑遞歸查詢和迭代查詢當(dāng)你在瀏覽器里輸入一個(gè)域名完整的解析過程大概是這樣的瀏覽器會(huì)先查本地DNS緩存沒有就去問操作系統(tǒng)配置的Local DNS服務(wù)器也就是說你填的114.114.114.114或者8.8.8.8Local DNS服務(wù)器如果沒有緩存就會(huì)一級(jí)一級(jí)向上查詢。這個(gè)向上查詢的過程分兩種遞歸查詢和迭代查詢。通常來說客戶端對(duì)Local DNS發(fā)起的查詢是遞歸的你必須給我一個(gè)最終結(jié)果而Local DNS對(duì)根域名服務(wù)器、頂級(jí)域名服務(wù)器、權(quán)威域名服務(wù)器發(fā)起的查詢是迭代的我一次一次地問你們一次一次地指路。根服務(wù)器不會(huì)直接告訴你某個(gè)具體域名的IP它會(huì)告訴你“這個(gè)域名的頂級(jí)域歸誰管”指引你一層層往下走直到找到權(quán)威服務(wù)器拿到真正的解析結(jié)果。4.2 影響性能的TTL和令人頭疼的緩存污染TTLTime To Live是DNS記錄里的“存活時(shí)間”。它決定了這條解析結(jié)果能被子設(shè)備緩存多久。如果TTL設(shè)置太短訪問量大的話Local DNS的壓力會(huì)劇增設(shè)置太長又會(huì)導(dǎo)致你切換服務(wù)器IP之后老解析結(jié)果遲遲不失效用戶一直訪問舊地址。我有一回切換服務(wù)器提前改好了DNS記錄但業(yè)務(wù)方還是反映舊地址能通、新地址訪問不了持續(xù)了將近兩個(gè)小時(shí)。去查才發(fā)現(xiàn)那條A記錄的TTL原來被設(shè)成了7200秒也就是說最長要2小時(shí)才會(huì)全網(wǎng)生效。后來我養(yǎng)成了習(xí)慣做大的IP切換前提前幾天把TTL調(diào)低到300秒等切換完成后再調(diào)回來這個(gè)操作能幫你大幅縮短“切換陣痛期”。4.3 DNS服務(wù)選型和防污染經(jīng)驗(yàn)個(gè)人項(xiàng)目或小型業(yè)務(wù)用系統(tǒng)自帶的systemd-resolved或直接指公共DNS一般就夠用了。到了正式生產(chǎn)環(huán)境我還是建議自建內(nèi)網(wǎng)DNS常見的方案是CoreDNS搭配緩存層。內(nèi)網(wǎng)域名解析走內(nèi)網(wǎng)DNS外網(wǎng)域名解析再轉(zhuǎn)發(fā)到公共DNS這樣既快又可控還可以加一些自定義的解析規(guī)則比如內(nèi)部服務(wù)直接解析到內(nèi)網(wǎng)IP。真正麻煩的是緩存污染問題。公共DNS在極端情況下可能返回不正確的解析結(jié)果導(dǎo)致域名被指向錯(cuò)誤IP。我在本地開發(fā)機(jī)上遇到過一次某個(gè)SaaS平臺(tái)的域名解析到了一個(gè)陌生的IP瀏覽器直接攔截報(bào)警。排查方式很簡單用dig 8.8.8.8 example.com和dig 內(nèi)網(wǎng)DNS example.com對(duì)比解析結(jié)果如果差異明顯基本就能鎖定是誰的解析出了問題。這里也建議生產(chǎn)環(huán)境的服務(wù)器不要混用不同運(yùn)營商的公共DNS解析行為不一致會(huì)浪費(fèi)大量排障時(shí)間。5. SSH遠(yuǎn)程管理的“安全通道”但別只在Login時(shí)才想起它SSHSecure Shell大概是運(yùn)維工具箱里使用率最高的協(xié)議了基本所有服務(wù)器管理都依賴它。但它絕不只是“輸入密碼然后敲命令”這么簡單。5.1 對(duì)稱加密、非對(duì)稱加密和會(huì)話密鑰SSH的連接建立過程完美演繹了三類密碼學(xué)應(yīng)用的配合用非對(duì)稱加密通常是RSA或ECDSA實(shí)現(xiàn)身份認(rèn)證和對(duì)密鑰協(xié)商過程進(jìn)行簽名保護(hù)保證“和我通信的確實(shí)是那臺(tái)服務(wù)器”。用Diffie-Hellman密鑰交換算法在不安全的網(wǎng)絡(luò)上協(xié)商出一個(gè)雙方共享的“會(huì)話密鑰”。后續(xù)所有數(shù)據(jù)都用這個(gè)會(huì)話密鑰進(jìn)行對(duì)稱加密傳輸因?yàn)閷?duì)稱加密速度快適合大數(shù)據(jù)量通信。密鑰交換的算法細(xì)節(jié)很多人覺得枯燥但理解它能幫你解釋不少安全告警。比如你第一次連某臺(tái)服務(wù)器時(shí)會(huì)看到The authenticity of host ... cant be established的警告就是因?yàn)槟氵€沒有保存它的主機(jī)公鑰。如果后期再彈出提示說IP地址對(duì)應(yīng)的主機(jī)密鑰變了那就要立刻警惕是否有中間人劫持了你的連接千萬別習(xí)慣性地點(diǎn)“yes”跳過。5.2 密鑰登錄配置步驟和密碼登錄的風(fēng)險(xiǎn)點(diǎn)生產(chǎn)環(huán)境強(qiáng)烈建議關(guān)閉密碼登錄、改用密鑰對(duì)。我的配置鏈路是這樣的在本地生成密鑰對(duì)ssh-keygen -t ed25519 -C your_comment -f ~/.ssh/id_ed25519現(xiàn)在我都用ed25519替代RSA因?yàn)樗拿荑€短、生成快、安全性夠用。RSA密鑰如果要用建議至少4096位。把公鑰安裝到服務(wù)器目標(biāo)用戶的~/.ssh/authorized_keys文件里ssh-copy-id -i ~/.ssh/id_ed25519.pub userserver_ip修改服務(wù)端配置/etc/ssh/sshd_configPasswordAuthentication no PermitRootLogin no重啟SSH服務(wù)sudo systemctl restart sshd這里有個(gè)致命細(xì)節(jié)很多人改完配置直接斷開當(dāng)前連接結(jié)果密鑰認(rèn)證沒生效密碼又被禁了人直接“失聯(lián)”。我自己的習(xí)慣是先用一個(gè)終端保留現(xiàn)有登錄會(huì)話另外一個(gè)終端用新配置重新連接確認(rèn)新會(huì)話正常成功后再關(guān)掉舊連接。5.3 SSH隧道端口轉(zhuǎn)發(fā)的高級(jí)用法SSH隧道是很多人的“隱藏技能”它可以把一個(gè)不安全的網(wǎng)絡(luò)流量封裝進(jìn)SSH加密通道里。本地轉(zhuǎn)發(fā): 把遠(yuǎn)程服務(wù)器的某個(gè)端口映射到本機(jī)。ssh -L 8080:internal-service:80 userjump-server這樣我訪問本地的8080端口數(shù)據(jù)會(huì)經(jīng)過跳板機(jī)再轉(zhuǎn)發(fā)到內(nèi)網(wǎng)目標(biāo)的80端口。遠(yuǎn)程轉(zhuǎn)發(fā): 把本機(jī)的某個(gè)端口暴露到遠(yuǎn)端。這個(gè)場景適合你把本地的開發(fā)服務(wù)臨時(shí)暴露給遠(yuǎn)程同事訪問。實(shí)際使用中用跳板機(jī)管理多臺(tái)內(nèi)網(wǎng)服務(wù)器時(shí)SSH隧道幾乎是標(biāo)配。但我必須提醒跳躍轉(zhuǎn)發(fā)配置不好容易搞混端口方向建議把常用的隧道配置寫進(jìn)~/.ssh/config文件里用別名調(diào)用比每次敲一長串命令穩(wěn)妥得多。6. FTP文件的“老牌”傳輸協(xié)議它為什么還沒死FTP文件傳輸協(xié)議誕生得非常早在HTTP還沒普及的年代它就是互聯(lián)網(wǎng)上分享文件的主要方式。哪怕到了今天很多老舊系統(tǒng)、打印機(jī)、嵌入式設(shè)備里仍然只認(rèn)FTP。但它的缺點(diǎn)也很致命所有數(shù)據(jù)和控制指令默認(rèn)不加密。6.1 主動(dòng)模式vs被動(dòng)模式連接方向的反直覺之處FTP比HTTP復(fù)雜的地方在于它有兩條連接一條是控制連接走21端口一條是數(shù)據(jù)連接根據(jù)模式走不同端口。初次接觸的人十有八九會(huì)被主動(dòng)模式和被動(dòng)模式繞暈。主動(dòng)模式Active客戶端告訴服務(wù)器“我在聽某個(gè)端口你連過來”。所以數(shù)據(jù)連接由服務(wù)器主動(dòng)發(fā)起方向是服務(wù)器連客戶端的隨緣端口。這在大多數(shù)客戶端處于NAT或防火墻后面的場景下會(huì)失敗。被動(dòng)模式Passive服務(wù)器告訴客戶端“我在聽某個(gè)端口你連過來”。數(shù)據(jù)連接由客戶端發(fā)起方向?qū)ΜF(xiàn)代網(wǎng)絡(luò)環(huán)境友好得多所以現(xiàn)在主流FTP客戶端默認(rèn)都是被動(dòng)模式。這個(gè)知識(shí)點(diǎn)是排查FTP“能登錄但列不出目錄”的關(guān)鍵。很多FTP排障的第一反應(yīng)就是檢查21端口通不通但目錄列表失敗往往發(fā)生在數(shù)據(jù)連接上。如果服務(wù)器防火墻沒放行被動(dòng)模式端口段客戶端能登錄成功卻卡在LIST目錄超時(shí)上。6.2 FTP vs SFTP別把它們搞混了很多人以為SFTP是“FTP的安全版”這個(gè)說法不嚴(yán)謹(jǐn)。準(zhǔn)確地說SFTP是“SSH文件傳輸協(xié)議”SSH File Transfer Protocol它完全運(yùn)行在SSH協(xié)議之上不是傳統(tǒng)FTP加了一個(gè)加密層。這意味著SFTP不需要單獨(dú)的21端口和被動(dòng)模式端口段只占用22端口配置和防火墻策略都簡單得多。所以我在新項(xiàng)目里幾乎不會(huì)主動(dòng)推薦使用FTP除非是為了兼容那批老設(shè)備。如果只是普通服務(wù)器之間的文件傳輸SFTP是更穩(wěn)的選擇如果要傳大量數(shù)據(jù)且要求斷點(diǎn)續(xù)傳、并發(fā)分片那更合適的是專門的文件傳輸工具或?qū)ο蟠鎯?chǔ)方案。FTP的價(jià)值在于它足夠簡單、足夠通用并且很多老牌自動(dòng)化腳本里還有它的位置。6.3 搭建一個(gè)安全的FTP/SFTP服務(wù)的幾個(gè)注意點(diǎn)如果是自建FTP我建議至少做到這幾點(diǎn)使用被動(dòng)模式并把服務(wù)器防火墻和數(shù)據(jù)連接的端口段統(tǒng)一放行。為FTP用戶設(shè)置目錄禁錮chroot避免登錄用戶可以跑到系統(tǒng)其他目錄里。配置文件傳輸日志至少保留上傳、下載、刪除的審計(jì)記錄。如果可以優(yōu)先選擇SFTP替代FTP。我?guī)湍硞€(gè)客戶搭過一套文件交換服務(wù)對(duì)方因?yàn)闅v史原因必須用FTP我就把VSFTPD配成被動(dòng)模式限制端口段在50000-50100然后防火墻只開放21端口和這個(gè)端口段。上線后很穩(wěn)唯一要注意的就是端口段別和別的服務(wù)沖突以及每一個(gè)被動(dòng)連接都會(huì)占用一個(gè)端口端口段大小要按并發(fā)連接數(shù)來規(guī)劃。7. 協(xié)議排障抓包工具實(shí)戰(zhàn)與問題定位思路最后這部分我想把前面說的所有協(xié)議知識(shí)串起來落到一個(gè)最實(shí)際的話題——網(wǎng)絡(luò)出了問題怎么一步步定位這個(gè)過程里最有用的工具就是抓包和分析工具。7.1 幾種常用抓包工具對(duì)比以及什么時(shí)候用誰tcpdump: 命令行抓包工具輕量、適合在服務(wù)器上直接用。我最常的用法tcpdump -i eth0 -nn port 443 -w https.pcap抓完用-r參數(shù)讀回再用Wireshark打開分析。Wireshark: 圖形化分析工具適合看TCP流、TLS握手、HTTP詳情。過濾器語法http.request.method POST或者tcp.analysis.flags能快速定位問題包。瀏覽器的DevTools: 只適合看應(yīng)用層HTTP請(qǐng)求不涉及傳輸層細(xì)節(jié)。排查前后端接口問題時(shí)最方便但不適合深挖鏈路層。ping和traceroute: 不屬于抓包工具但每次排障我開場都要用。它們能快速判定“通不通”以及“走了哪條路”。7.2 經(jīng)典故障實(shí)錄從HTTP超時(shí)到TCP重傳的定位過程這里分享一個(gè)我之前真實(shí)處理過的模擬項(xiàng)目X某跨平臺(tái)系統(tǒng)排障實(shí)錄。現(xiàn)象是某個(gè)接口在高峰期從平均200ms飆升到3秒偶爾直接超時(shí)。我按順序做了這么幾步第一步看是不是后端應(yīng)用慢。在服務(wù)器上直接curl接口返回很快排除應(yīng)用層瓶頸。第二步懷疑是網(wǎng)絡(luò)問題。在客戶端機(jī)器延遲到服務(wù)器發(fā)現(xiàn)延遲并不高但抓包的時(shí)候看到大量TCP重復(fù)ACK和Dup ACK說明傳輸過程中發(fā)生了丟包。第三步用traceroute追蹤路徑發(fā)現(xiàn)某個(gè)中間網(wǎng)關(guān)節(jié)點(diǎn)延遲飆升偶發(fā)丟包。聯(lián)系那個(gè)節(jié)點(diǎn)對(duì)應(yīng)的網(wǎng)絡(luò)方處理同時(shí)調(diào)整了TCP擁塞控制算法從默認(rèn)的cubic換成了bbr問題得到明顯緩解。這個(gè)案例最值得記的是排查順序從上層往下層一層層剝應(yīng)用層沒問題就往傳輸層查傳輸層可疑就往網(wǎng)絡(luò)層查不要一上來就“懷疑代碼”。7.3 常用協(xié)議問題速查表我整理了一張速查表遇到問題時(shí)可以直接對(duì)照定位方向現(xiàn)象可能涉及的協(xié)議層首要排查方向域名解析失敗DNS確認(rèn)DNS服務(wù)器、緩存、域名是否有A記錄頁面能打開但接口超時(shí)HTTP/TCP看接口耗時(shí)、TCP重傳率、后端處理時(shí)長連不上服務(wù)器SSH/TCP/IP確認(rèn)端口放行、IP可達(dá)、防火墻策略FTP能登錄但列舉目錄失敗FTP被動(dòng)模式檢查數(shù)據(jù)連接端口段是否放行瀏覽器報(bào)證書錯(cuò)誤TLS檢查證書鏈?zhǔn)欠裢暾?、證書是否過期訪問很慢但CPU和內(nèi)存都不高TCP擁塞控制/IP路由檢查丟包率traceroute定位中間鏈路域名解析正常但業(yè)務(wù)異常DNS緩存對(duì)比多個(gè)DNS解析結(jié)果、清理本地緩存這張表不是萬能答案但能幫你把“毫無頭緒”收斂成“先查某個(gè)方向”尤其是新手對(duì)著表格一步步來大概率能避免一上來就亂抓瞎。7.4 零散但好用的協(xié)議配置細(xì)節(jié)最后分享幾個(gè)零散但很實(shí)用的配置細(xì)節(jié)都是我實(shí)際工作中攢下來的第一HTTP的Keep-Alive不是沒有代價(jià)的。長連接會(huì)占用連接文件描述符如果服務(wù)端并發(fā)連接數(shù)配置太小小心出現(xiàn)“大量TIME_WAIT連接不釋放”的問題。用ss -s看看當(dāng)前連接狀態(tài)分布如果TIME_WAIT積壓嚴(yán)重可以調(diào)整內(nèi)核參數(shù)net.ipv4.tcp_tw_reuse復(fù)制策略。第二TCP的Nagle算法和延遲ACK機(jī)制在某些小包場景下會(huì)互相“打架”。如果你遇到“發(fā)一個(gè)包要等200ms才能收到響應(yīng)”這種詭異延遲并且確認(rèn)代碼里沒有問題可以考慮在服務(wù)端關(guān)閉Nagle算法也就是設(shè)置TCP_NODELAY。在Nginx配置里對(duì)應(yīng)的是tcp_nodelay on;。第三MTU問題雖然老但從沒消失過。如果發(fā)現(xiàn)“大數(shù)據(jù)包不通、小數(shù)據(jù)包正?！眱?yōu)先懷疑MTU不匹配。常見的鏈路MTU是1500但如果走了某個(gè)隧道或者特殊網(wǎng)絡(luò)環(huán)境MTU可能會(huì)變小導(dǎo)致分片問題。用ping -M do -s 1400這類參數(shù)可以快速測出實(shí)際可用的包大小邊界。第四IPv6在現(xiàn)在的網(wǎng)絡(luò)環(huán)境里已經(jīng)非常普遍了但很多服務(wù)配置時(shí)根本不注意它。如果你的服務(wù)器配置了IPv6地址但防火墻策略只放行了IPv4你會(huì)發(fā)現(xiàn)“4通的域名6完全不通”或者反過來。排障時(shí)記得把兩個(gè)協(xié)議棧分開驗(yàn)證不要籠統(tǒng)地認(rèn)為“通了就行”。寫在最后的小體會(huì)協(xié)議這東西只靠背概念是留不住的。我自己的經(jīng)驗(yàn)是每學(xué)一個(gè)協(xié)議就親手用抓包工具看一眼它的真實(shí)報(bào)文。比如你親眼看過TCP三次握手的三條包長什么樣、親眼看過一次TLS握手交互了哪些證書信息這些知識(shí)就變成你自己的了。尤其是做應(yīng)用開發(fā)的遇到網(wǎng)絡(luò)層面的問題不要急著懷疑“是不是運(yùn)維那邊搞的鬼”也別一上來就改代碼。先靜下心按“應(yīng)用層→傳輸層→網(wǎng)絡(luò)層”的順序逐層確認(rèn)絕大多數(shù)問題都能有一個(gè)清晰結(jié)論。希望這篇梳理能幫你建立起自己的排障地圖下次再遇到網(wǎng)絡(luò)問題腦子里就有畫面感了。