簡介圍繞ICMP報文構(gòu)造與驗證整理的一份小型代碼資料適合正在學(xué)習(xí)TCP/IP協(xié)議、網(wǎng)絡(luò)編程及網(wǎng)絡(luò)診斷的初、中級讀者也可供網(wǎng)絡(luò)管理員排查連通性問題時參考。內(nèi)容聚焦ICMP差錯報告與查詢報文的類型、代碼及數(shù)據(jù)字段演示如何將ICMP報文封裝進IP數(shù)據(jù)報并借助抓包工具核對發(fā)送與接收結(jié)果幫助讀者理解ping回顯請求/應(yīng)答在協(xié)議層的實際形態(tài)。壓縮包共3個文件約5KB包含cpp源碼、h頭文件與txt說明文檔分別承載核心實現(xiàn)、結(jié)構(gòu)聲明和閱讀指引體量輕便便于結(jié)合現(xiàn)有工程對照研讀。已有1608人學(xué)習(xí)或下載說明其在小巧示例層面具有一定參考價值讀者可從中獲得報文構(gòu)造思路、字段設(shè)置方法、IP封裝要點以及抓包驗證與排錯線索為后續(xù)網(wǎng)絡(luò)協(xié)議實驗和安全分析打基礎(chǔ)。1. 排障時那行“請求超時”其實值 8 個字節(jié)上周幫朋友看一臺自研網(wǎng)關(guān)ping返回“請求超時”但業(yè)務(wù)端口連通正常日志里也沒有異常。命令行ping只給你一行結(jié)論給不了每跳 RTT、給不了回包里的字段更沒法告訴你對端到底有沒有按協(xié)議填 Type 和 Code。這就是一份 ICMP 數(shù)據(jù)包構(gòu)造的源碼最實在的用處自己把 8 字節(jié) ICMP 頭和載荷拼出來發(fā)出去再把回來的包拆開逐字段看。讀完這份代碼你能拿到一個不依賴系統(tǒng)ping的可運行探針能改 Type/Code 構(gòu)造各種探測報文能順著 TTL 階梯跑一遍路徑也能在沒有第三方 SDK 的環(huán)境里做鏈路質(zhì)量采樣。適合正在寫網(wǎng)絡(luò)診斷工具、做設(shè)備聯(lián)調(diào)、或者想把 TCP/IP 協(xié)議從課本搬到手上的人。2. 報文結(jié)構(gòu)拆解ICMP 頭這 8 個字節(jié)怎么填2.1 Type 與 Code 的組合表先認清自己要發(fā)哪一種ICMP 報文頭固定 8 字節(jié)按順序是 Type1 字節(jié)、Code1 字節(jié)、Checksum2 字節(jié)、后面 4 字節(jié)隨 Type 變化。Echo 類報文這 4 字節(jié)拆成 Identifier2 字節(jié)和 Sequence Number2 字節(jié)Destination Unreachable 類則用來攜帶觸發(fā)該報文的原始 IP 頭和 8 字節(jié)數(shù)據(jù)。字段名背下來不難難的是知道什么時候該填哪個組合下面這張表我一般貼在代碼注釋里。TypeCode名稱實際會遇到的場景00Echo Reply對端回應(yīng)你發(fā)出的 Echo Request30Network Unreachable路由表里沒有到目標(biāo)的路徑31Host Unreachable目標(biāo)網(wǎng)段可達ARP 拿不到對端 MAC33Port UnreachableUDP 打到?jīng)]人監(jiān)聽的端口對端回這個34Fragmentation Needed報文超過 MTU 且置了 DF 位這條最關(guān)鍵50~3Redirect網(wǎng)關(guān)告訴你換一條更優(yōu)路徑80Echo Request你主動發(fā)出去的探測包110Time ExceededTTL中間路由器把 TTL 減到 0回這個111Time Exceeded重組分片重組超時13 / 140Timestamp Request / Reply不帶狀態(tài)的時間探測要留意的點除了 Type 3、5、11 之外絕大多數(shù) Type 的 Code 都固定為 0填錯之后對端不會報錯而是靜默丟棄這是新手最容易誤以為“網(wǎng)絡(luò)不通”的地方。另外 Type 3 的報文里ICMP 頭后面還會跟著觸發(fā)它的那個原始 IP 頭的前 20 字節(jié)加至少 8 字節(jié)數(shù)據(jù)解析時要按ihl跳過 IP 頭再按外層 ICMP 頭長 8 字節(jié)往后偏移才能摸到內(nèi)層內(nèi)容。做 MTU 探測的人得靠這段內(nèi)層信息判斷哪個流被卡住了。2.2 校驗和RFC 1071 的反碼求和與三個易錯點Checksum 覆蓋范圍是整個 ICMP 報文頭 數(shù)據(jù)算法是 16 位反碼求和?？雌饋砗唵螌嶋H寫起來翻車率很高我見過不止一個人在這四行里卡一個下午。def checksum(data: bytes) - int: RFC 1071 的 16 位反碼求和返回值直接填進 Checksum 字段 if len(data) % 2: data b\x00 # 奇數(shù)字節(jié)必須補零不能直接跳過最后一位 total 0 for i in range(0, len(data), 2): total (data[i] 8) | data[i 1] # 按網(wǎng)絡(luò)字節(jié)序取 16 位 total (total 0xFFFF) (total 16) # 每次累加后回卷進位避免溢出 return (~total) 0xFFFF # 取反并截斷到 16 位邏輯說明把數(shù)據(jù)按兩個字節(jié)一組當(dāng)成大端 16 位整數(shù)累加累加過程中一旦超過 0xFFFF就把高位折回低位繼續(xù)加這一步叫回卷最后對結(jié)果取反。參數(shù)只有一個data傳進去的必須是校驗和字段已經(jīng)置 0的完整報文否則算出來的值永遠對不上。三個易錯點挨個說。第一奇數(shù)字節(jié)長度必須補一個\x00不補的話最后一字節(jié)會被漏掉長載荷比如 15 字節(jié)的魔術(shù)字幾乎必錯。第二回卷這一步很多人寫成先全加完再處理溢出遇到大載荷會丟進位正確做法是邊加邊回卷。第三字節(jié)序。struct.pack(!BBHHH, ...)里的!就是網(wǎng)絡(luò)字節(jié)序漏掉它在本機 x86 上跑出來的包 Wireshark 會直接標(biāo) “checksum incorrect”但本機回環(huán)測試可能又“看起來正?！睂儆诘湫偷男W(xué)問題。驗證手段很簡單抓一次系統(tǒng)ping發(fā)出的包把它的 ICMP 段摳出來喂給你的函數(shù)算出來是 0 就說明算法對了含校驗和的報文再算一遍結(jié)果應(yīng)為 0。2.3 載荷設(shè)計時間戳、序列號與魔術(shù)字載荷部分協(xié)議沒規(guī)定內(nèi)容但工程上得放點有用的東西。我一般按三段排開頭 8 字節(jié)放發(fā)送時刻4 字節(jié)秒 4 字節(jié)微秒中間 4 字節(jié)放一個固定的魔術(shù)字剩下的用遞增字節(jié)填充。放時間戳是為了不依賴本地記錄就能算出 RTT——收到回包時用當(dāng)前時間減去載荷里的發(fā)送時刻多進程、多線程并發(fā)跑也不會串賬。放魔術(shù)字是為了識別“這包是不是我發(fā)的”。系統(tǒng)ping也在發(fā) ICMPidentifier 撞車的概率雖然低但在容器共享網(wǎng)絡(luò)命名空間的環(huán)境里并不罕見一個固定魔術(shù)字能省掉大量排查。用遞增字節(jié)填充則是為了做鏈路誤碼檢測某些交換機在極端負載下會把載荷改掉回包里的填充段和發(fā)出的對不上就說明中間設(shè)備出了問題。載荷長度直接影響是否會觸發(fā)分片。默認我寫 56 字節(jié)加上 8 字節(jié) ICMP 頭和 20 字節(jié) IP 頭剛好 84 字節(jié)遠小于 1500 的典型 MTU路徑上不會分片測出來的 RTT 干凈。要做 MTU 探測時再專門放大這一點在第 4 章展開。3. 構(gòu)造鏈路從 raw socket 逐字節(jié)拼裝到 scapy 分層寫法3.1 Linux raw socket 版本內(nèi)核幫你補 IP 頭構(gòu)造 ICMP 最直接的方式是AF_INETSOCK_RAWIPPROTO_ICMP。這里有個必須先說清的坑用IPPROTO_ICMP創(chuàng)建的套接字內(nèi)核會自動幫你補上 IP 頭你只管拼 ICMP 部分長度字段、源地址、TTL 全由內(nèi)核填。只有當(dāng)你用IPPROTO_RAW或者開了IP_HDRINCL時才需要自己拼 IP 頭。網(wǎng)上很多示例把這兩條路混著寫照抄下來要么發(fā)包失敗要么發(fā)出去對端收不到。import os, struct, socket, time ICMP_ECHO_REQUEST 8 ICMP_ECHO_REPLY 0 MAGIC bPRB0 # 魔術(shù)字用來區(qū)分自己的包和系統(tǒng) ping def build_echo(seq: int, payload: bytes, ident: int) - bytes: 拼一個完整的 ICMP Echo Request返回可以直接 sendto 的字節(jié)串 body struct.pack(!d, time.time()) MAGIC payload # 8 字節(jié)時間戳打頭 header struct.pack(!BBHHH, ICMP_ECHO_REQUEST, 0, 0, ident, seq) csum checksum(header body) # 此時校驗和字段是 0 header struct.pack(!BBHHH, ICMP_ECHO_REQUEST, 0, csum, ident, seq) return header body邏輯說明先算載荷再算把頭校驗和位置填 0然后兩次pack——第一次只為拿長度對齊的字節(jié)串去算校驗和第二次把算出來的csum填回去。參數(shù)里ident建議傳os.getpid() 0xFFFFseq從 1 開始單調(diào)遞增payload長度控制在 56 字節(jié)以內(nèi)。權(quán)限是繞不過去的一道坎。raw socket 需要CAP_NET_RAW普通用戶直接跑會拿到PermissionError: [Errno 1] Operation not permitted。開發(fā)階段sudo最省事但交付時我一般用能力位而不是給整個腳本加 sudosudo setcap cap_net_raweip /usr/bin/python3.11 # 驗證能打印出 cap_net_raw 就說明生效了 getcap /usr/bin/python3.11注意這條命令是給解釋器加能力等于這臺機器上所有 Python 腳本都能開 raw socket生產(chǎn)環(huán)境慎用更穩(wěn)妥的做法是打包成獨立可執(zhí)行文件后只給那個文件加能力位。3.2 收發(fā)與匹配identifier 和 sequence 是唯一的后悔藥發(fā)出去只是第一步收回來才是麻煩的開始。raw socket 收到的是帶著 IP 頭的完整數(shù)據(jù)包得先按ihl切片才能看到 ICMP 段。同時因為同一個套接字會收到本機所有 ICMP 流量匹配邏輯必須寫嚴。def ping_once(host: str, seq: int 1, timeout: float 1.0, ttl: int 64): ident os.getpid() 0xFFFF pkt build_echo(seq, b\x00 * 56, ident) with socket.socket(socket.AF_INET, socket.SOCK_RAW, socket.IPPROTO_ICMP) as sock: sock.settimeout(timeout) sock.setsockopt(socket.IPPROTO_IP, socket.IP_TTL, ttl) # 控制跳數(shù)traceroute 靠它 start time.perf_counter() sock.sendto(pkt, (host, 0)) # 端口號對 ICMP 無意義填 0 while True: data, addr sock.recvfrom(2048) ihl (data[0] 0x0F) * 4 # IP 頭長度以 4 字節(jié)為單位 icmp data[ihl:] rtype, rcode, _, rid, rseq struct.unpack(!BBHHH, icmp[:8]) if rtype ! ICMP_ECHO_REPLY: continue # 不是回顯應(yīng)答交給上層別的邏輯 if rid ! ident or rseq ! seq: continue # 別人的回包丟掉 rtt (time.perf_counter() - start) * 1000 return rtt, addr[0], icmp[8:] # 載荷原樣帶回供校驗?zāi)g(shù)字邏輯說明setsockopt里的IP_TTL在 traceroute 場景下會反復(fù)改這里先固定 64。recvfrom拿到的data從第 0 字節(jié)起就是 IP 頭(data[0] 0x0F) * 4取的是 IHL 字段常見值 20帶有選項時會更長寫死 20 是另一個高頻翻車點。匹配條件用了rtype、rid、rseq三重判斷少任何一個都可能拿到系統(tǒng)ping或其他進程的回包表現(xiàn)為 RTT 忽大忽小、時對時錯。參數(shù)含義再強調(diào)一下seq必須和構(gòu)造時一致否則永遠匹配不上timeout是settimeout的秒數(shù)局域網(wǎng) 0.5 秒足夠跨地域建議 2 秒設(shè)太小會把正常的慢回包誤判成丟包。3.3 scapy 版本二十行寫完成同樣的功能如果項目里不介意引入依賴scapy 能把上面這一堆字節(jié)操作壓縮到幾行協(xié)議分層的表達也更直觀。import os from scapy.all import IP, ICMP, Raw, sr1 def ping_scapy(host: str, seq: int 1, ttl: int 64, timeout: float 1.0): ident os.getpid() 0xFFFF pkt IP(dsthost, ttlttl) / ICMP(type8, idident, seqseq) / Raw(loadb\x00 * 56) resp sr1(pkt, timeouttimeout, verbose0) # sr1 send and receive 1只等第一個回包 if resp is None: return None if resp.haslayer(ICMP) and resp[ICMP].type 0: return resp[IP].src, resp[ICMP].payload.load return None/是 scapy 的重載運算符表示協(xié)議分層等價于“把后者的字節(jié)接到前者后面”。sr1會自動處理 IP 頭切片和校驗和計算省掉了手寫checksum的環(huán)節(jié)收包時按層名訪問字段也比struct.unpack可讀。代價是啟動慢導(dǎo)入 scapy 通常要 0.31 秒打包體積大某些精簡鏡像里還會缺依賴。兩條路的對比如下維度raw socketscapy啟動開銷幾乎為零首次導(dǎo)入數(shù)百毫秒依賴標(biāo)準(zhǔn)庫需要額外安裝字段可讀性依賴 struct 格式串按層名訪問直觀精細控制完全可控能構(gòu)造畸形包需要手動改字段或Raw適合場景交付給終端用戶的輕量工具內(nèi)部調(diào)試、教學(xué)、快速驗證我自己的做法是兩套都留核心鏈路用 raw socket保證沒有第三方依賴寫測試用例和抓包對齊時用 scapy 起一個對照實現(xiàn)兩邊 RTT 差在 1 毫秒以內(nèi)基本可以確認構(gòu)造邏輯沒問題。4. 從 echo 到診斷TTL 階梯與 DF 位探測4.1 Traceroute 的 TTL 遞增循環(huán)與 Type 11 解析Echo 只能告訴你“通不通”路徑信息要靠 TTL 一層層往上加。原理不復(fù)雜TTL 減到 0 時中間路由器會回一個 Type 11 的 Time Exceeded把回包源地址記下來就是這一跳的地址直到某一跳回的是 Type 0 Echo Reply說明到終點了。def trace(host: str, max_hop: int 30, timeout: float 1.5): ident os.getpid() 0xFFFF for ttl in range(1, max_hop 1): pkt build_echo(seqttl, b\x00 * 32, ident) with socket.socket(socket.AF_INET, socket.SOCK_RAW, socket.IPPROTO_ICMP) as sock: sock.settimeout(timeout) sock.setsockopt(socket.IPPROTO_IP, socket.IP_TTL, ttl) start time.perf_counter() sock.sendto(pkt, (host, 0)) try: data, addr sock.recvfrom(2048) except socket.timeout: print(f{ttl:2} * request timeout) continue rtt (time.perf_counter() - start) * 1000 ihl (data[0] 0x0F) * 4 rtype, rcode struct.unpack(!BB, data[ihl:ihl 2]) if rtype 11: # Time Exceeded中間跳 print(f{ttl:2} {addr[0]:16} {rtt:6.2f} ms) elif rtype 0: # Echo Reply到終點 print(f{ttl:2} {addr[0]:16} {rtt:6.2f} ms reached) return邏輯說明外層循環(huán)把 TTL 從 1 加到 30每輪新建一個套接字復(fù)用一個套接字也可以但要記得setsockopt在每次發(fā)送前重設(shè)。seq直接用 TTL 值省掉額外的計數(shù)器。收到 Type 11 打印中間跳收到 Type 0 打印終點并返回。超時用*占位和系統(tǒng)traceroute的輸出風(fēng)格一致方便對照。這里有個容易被忽略的細節(jié)Type 11 的報文里ICMP 頭之后還塞著觸發(fā)它的原始 IP 頭 8 字節(jié)數(shù)據(jù)也就是你發(fā)出去的 Echo 報文的前 28 字節(jié)。想確認“這個超時確實是我這輪發(fā)的包觸發(fā)的”得從data[ihl8:]再切一層比對內(nèi)層的 identifier 和 seq。不做這層校驗的話路徑上中間設(shè)備主動發(fā)的 ICMP 超時會被誤記成正常跳輸出里就會冒出莫名其妙的地址。這個血淚經(jīng)驗在跨運營商鏈路上特別值錢。4.2 DF 位與 MTU 探測Type 3 Code 4 才是有效信號MTU 探測的邏輯是發(fā)一個指定長度的 Echo Request把 IP 頭的 DFDont Fragment位置 1中間鏈路 MTU 不夠時路由器不能分片只能回 Type 3 Code 4 告訴你“需要分片但設(shè)了 DF”同時報文里會帶上它這一跳的 MTU 值新版 ICMP 規(guī)范里放在 ICMP 頭后 2 字節(jié)。把長度二分搜索一遍就能測出路徑 MTU。import socket, struct IP_MTU_DISCOVER 10 # Linux 下這兩個常量標(biāo)準(zhǔn)庫沒暴露得自己定義 IP_PMTUDISC_DO 2 def probe_mtu(host: str, low: int 576, high: int 1500) - int: 二分找路徑 MTU返回不觸發(fā)分片的最大載荷長度 while low high: mid (low high 1) // 2 with socket.socket(socket.AF_INET, socket.SOCK_RAW, socket.IPPROTO_ICMP) as sock: sock.settimeout(2.0) sock.setsockopt(socket.IPPROTO_IP, IP_MTU_DISCOVER, IP_PMTUDISC_DO) pkt build_echo(seqmid, b\x00 * (mid - 8 - 20), os.getpid() 0xFFFF) sock.sendto(pkt, (host, 0)) try: data, _ sock.recvfrom(4096) ihl (data[0] 0x0F) * 4 rtype, rcode struct.unpack(!BB, data[ihl:ihl 2]) if rtype 3 and rcode 4: high mid - 1 # 太大被拒 else: low mid # 能過 except socket.timeout: high mid - 1 # 超時也按過大處理保守收斂 return low邏輯說明IP_MTU_DISCOVER設(shè)成IP_PMTUDISC_DO等價于在 IP 頭上置 DF 位這是不自己拼 IP 頭時最省事的做法。載荷長度換算成mid - 8 - 20減掉 ICMP 頭和 IP 頭才是真正的 data 長度。二分區(qū)間從 576IPv4 最小重組緩沖到 1500以太網(wǎng)典型 MTU如果目標(biāo)是 PPPoE 或隧道鏈路實際值可能落在 1400 出頭二分能很快收斂。注意超時的情況我也當(dāng)成“過大”處理這是一種保守策略——丟包和 MTU 超限在客戶端看起來都是沒收到回包不做區(qū)分會讓結(jié)果偏大。要區(qū)分的話得在抓到 Type 3 Code 4 時把內(nèi)層報文的 identifier 和 seq 拿出來比對確認這條錯誤確實是沖著這輪探測來的。5. 避坑與排查構(gòu)造器跑不通時按這五條對表5.1 權(quán)限、防火墻、序列號收發(fā)鏈路上的三條翻車記錄第一條權(quán)限?，F(xiàn)象腳本一跑就拋PermissionError: [Errno 1] Operation not permitted換成sudo就正常。原因創(chuàng)建SOCK_RAW套接字需要CAP_NET_RAW能力普通用戶默認沒有。部分發(fā)行版的ping命令之所以能免 sudo是因為它帶著setuid位或能力位。解決開發(fā)期用sudo快速驗證交付前把腳本打成獨立可執(zhí)行文件再setcap cap_net_raweip別給整個解釋器加能力。容器環(huán)境里除了容器本身的 capability還要確認--cap-addNET_RAW有沒有傳進去這兩層權(quán)限是疊加的。第二條防火墻?，F(xiàn)象sendto返回的字節(jié)數(shù)正常說明包發(fā)出去了但recvfrom一直超時同一臺機器上用系統(tǒng)ping打同一個地址卻通。原因本機iptables/nftables或云上安全組把入向 ICMP 丟了。還有一種情況是ping命令走的是SOCK_DGRAM的 ICMP 套接字某些系統(tǒng)上帶net.ipv4.ping_group_range支持走了不同的路徑所以行為不一致。解決先在發(fā)送端抓包確認包真的出去了再在接收端抓包確認回包到了網(wǎng)卡。兩端都有包而應(yīng)用收不到八成是防火墻規(guī)則只有一端有包問題在路由。排查時順手iptables -L -n -v看一眼 ICMP 相關(guān)的 DROP 計數(shù)比盲猜快得多。第三條序列號與 identifier 撞車?，F(xiàn)象RTT 數(shù)據(jù)忽大忽小偶爾出現(xiàn)幾百毫秒的異常值或者回包的載荷和發(fā)出去的對不上。原因identifier 用了固定值 0或者每次調(diào)用隨機生成同一臺機器上并發(fā)跑多個探測進程時互相串包。系統(tǒng)ping也在發(fā) ICMP撞車概率不低。解決identifier 固定用os.getpid() 0xFFFFsequence 單調(diào)遞增收到包后三重校驗 type、id、seq 全對上才算數(shù)。再加一層魔術(shù)字比對載荷能擋住絕大多數(shù)串包。這個后悔藥必須在第一版就吃上等線上數(shù)據(jù)臟了再回頭改歷史數(shù)據(jù)全得重采。5.2 校驗和、字節(jié)序、IP 頭長度報文內(nèi)容上的兩條翻車記錄第四條校驗和算錯?，F(xiàn)象Wireshark 里 ICMP 那一行標(biāo)紅提示 checksum incorrect但對端有時候居然會回包有時候不回表現(xiàn)非常隨機。原因三種可能——計算校驗和時沒把 Checksum 字段置 0報文長度是奇數(shù)沒補零struct.pack漏了!導(dǎo)致按小端寫入。有些設(shè)備對校驗和不做校驗直接回有些嚴格丟棄所以你看到的現(xiàn)象就是玄學(xué)。解決寫完checksum先單獨測。拿系統(tǒng)ping發(fā)出的包做樣本把 ICMP 段含原校驗和喂進去結(jié)果應(yīng)該是 0。再用自己構(gòu)造的包算一遍然后重新計算同樣應(yīng)該是 0。兩個測試都過算法就沒問題。抓包確認字節(jié)序0800 0000這種才是對的。第五條IP 頭長度寫死 20?，F(xiàn)象解析回包時字段全錯位rtype打印出來是個莫名其妙的數(shù)字有時是 69 有時是 0。原因recvfrom返回的數(shù)據(jù)從 IP 頭開始代碼里寫死了data[20:]。某些路徑上 IP 頭帶選項比如記錄路由長度會變成 24 甚至更長寫死 20 就把 ICMP 頭的中間幾個字節(jié)當(dāng)成了 Type。解決統(tǒng)一用ihl (data[0] 0x0F) * 4動態(tài)計算偏移任何需要切 ICMP 段的地方都用這個變量。調(diào)試期我會在切片前打一行data[:32].hex()肉眼確認前幾個字節(jié)的版本號是 4、IHL 是 5 或更大這個習(xí)慣救過我好幾次。6. 二次開發(fā)把它改成你手上那臺設(shè)備的專用探針這套代碼本身不復(fù)雜價值在于它是個干凈的骨架。真要落到具體項目里我一般按“探針注冊 統(tǒng)一采集”的路子改而不是在主流程里堆 if-else。先加一個極簡的注冊表每個探測能力是一個函數(shù)靠裝飾器掛進去PROBES {} def probe(name: str): def deco(fn): PROBES[name] fn return fn return deco probe(echo) def run_echo(host, **kw): return [ping_once(host, seqi) for i in range(1, 5)] # 連發(fā) 4 個取統(tǒng)計 probe(mtu) def run_mtu(host, **kw): return {path_mtu: probe_mtu(host, highkw.get(high, 1500))}PROBES用字典存函數(shù)引用probe(echo)在模塊導(dǎo)入時自動注冊主流程只認字符串命令名新增探測類型不用改調(diào)度代碼。參數(shù)統(tǒng)一收**kw避免每加一個探針就改一次函數(shù)簽名——這個設(shè)計我是在改到第七個探針時才想明白的前期圖省事直接傳位置參數(shù)后期加個超時選項要動五處調(diào)用。幾個具體擴展點按投入產(chǎn)出排擴展方向改哪里驗證方式加時間戳請求Type 13新增build_timestamp復(fù)用checksum抓包看回復(fù) Type 是不是 14加 IPv6 支持換AF_INET6IPPROTO_ICMPV6校驗和算法含偽首部與系統(tǒng)ping6結(jié)果對齊輸出改成 JSON在run_*返回值上包一層序列化用jq過一遍確認字段完整加丟包率統(tǒng)計在run_echo里統(tǒng)計 None 比例人為丟包 20% 看統(tǒng)計是否吻合接入監(jiān)控把 RTT 推到時間序列庫對比本地抓包時間戳IPv6 那條要特別注意ICMPv6 的校驗和覆蓋范圍包含偽首部源地址、目的地址、長度、下一頭部跟 IPv4 完全不是一回事直接把checksum拿來用會全錯。我一般會為 v6 單獨寫一份別圖省事去復(fù)用。驗證方法上我養(yǎng)成一個固定套路任何新探針先打127.0.0.1這時候 RTT 應(yīng)該在 0.1 毫秒量級Type 和 Code 必然正確排除了鏈路因素再打網(wǎng)關(guān)驗證二層可達和 ARP最后才上真實目標(biāo)。三步都過才認為這個探針寫完了。跳過前兩步直接上真機出問題時根本分不清是自己構(gòu)造錯了還是鏈路不通。從那以后我每次動這套代碼改完都強制拿回環(huán)地址跑一遍全量探針再抓一次包對齊ping的結(jié)果兩個都對上才允許合進去。這個習(xí)慣攔下過至少三次字節(jié)序和切片偏移的低級錯誤。希望幫到你。本文還有配套的精品資源點擊獲取