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