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