簡(jiǎn)介這是一份基于Java實(shí)現(xiàn)的跨平臺(tái)網(wǎng)絡(luò)流量實(shí)時(shí)監(jiān)控與分析課程設(shè)計(jì)資源面向計(jì)算機(jī)網(wǎng)絡(luò)相關(guān)專業(yè)學(xué)生及需要遠(yuǎn)程部署流量采集場(chǎng)景的Java開發(fā)者。方案采用Java后端處理數(shù)據(jù)、Web前端展示分析的架構(gòu)在無(wú)圖形界面系統(tǒng)或遠(yuǎn)程目標(biāo)機(jī)環(huán)境下可將流量數(shù)據(jù)安全傳至瀏覽器端進(jìn)行可視化分析并兼顧傳輸加密與運(yùn)行穩(wěn)定性。包內(nèi)共76個(gè)文件核心為27個(gè)Java源碼文件另含15個(gè)JS與9個(gè)JSX前端邏輯、HTML/CSS頁(yè)面、Gradle構(gòu)建配置、可直接運(yùn)行的jar產(chǎn)物及密鑰證書文件整體壓縮包僅11.32MB目錄劃分清晰便于按需檢索與二次開發(fā)。隨包還附有課程設(shè)計(jì)報(bào)告PDF、任務(wù)說(shuō)明文檔和常用配置參考能夠幫助讀者快速?gòu)?fù)現(xiàn)項(xiàng)目環(huán)境理解數(shù)據(jù)采集、傳輸與展示的完整鏈路。目前已有462人學(xué)習(xí)下載作為課程設(shè)計(jì)參考或網(wǎng)絡(luò)流量分析入門實(shí)踐均有較高參考價(jià)值。1. 用 Java 做網(wǎng)絡(luò)流量分析軟件先確認(rèn)它在解決什么問題用 Java 做網(wǎng)絡(luò)流量分析軟件放在五年前會(huì)被人反問“為什么不用 C”現(xiàn)在這個(gè)問題基本可以正面回答了。pcap4j 通過 JNA 把 libpcap/Npcap 的能力搬進(jìn) JVM抓包、BPF 過濾、離線 pcap 回放都能在 Java 里完成。標(biāo)題里那個(gè)【100010394】是倉(cāng)庫(kù)項(xiàng)目編號(hào)源碼怎么組織先不管核心鏈路逃不開這幾段找網(wǎng)卡、開句柄、回調(diào)收包、解析協(xié)議、聚合會(huì)話、輸出指標(biāo)。典型的落地場(chǎng)景是運(yùn)維半夜被告警吵醒一臺(tái)內(nèi)網(wǎng)主機(jī)反復(fù)外連日志看不出名堂只能從網(wǎng)卡上拿原始幀才能定位測(cè)試要統(tǒng)計(jì)一條鏈路上的協(xié)議占比安全基線要記錄每個(gè)會(huì)話的字節(jié)數(shù)。這套方案適合三類人查網(wǎng)絡(luò)問題的運(yùn)維、做基線的測(cè)試以及把流量分析當(dāng)內(nèi)部工具或畢業(yè)設(shè)計(jì)來(lái)做的 Java 工程師。有人喜歡拿 Python 寫抓包腳本但做成要長(zhǎng)期維護(hù)、要并發(fā)、要打包分發(fā)的軟件Java 的線程模型和類庫(kù)生態(tài)更合我口味。2. 抓包引擎怎么選pcap4j 與 jnetpcap 的差距以及依賴和 native 環(huán)境2.1 先對(duì)比再動(dòng)手jnetpcap、jpcap 與 pcap4j 的選型邏輯Java 圈能做抓包的庫(kù)掰著手指頭數(shù)就三個(gè)最早是 jpcap后來(lái) jnetpcap 在它基礎(chǔ)上加了更多 libpcap 結(jié)構(gòu)的映射再后來(lái)才是 pcap4j。很多人教程看多了一上來(lái)就抄 jnetpcap 的樣例代碼結(jié)果在 64 位 JDK 上編不過去或者換了新版本 Npcap 之后句柄打不開。這不是你的代碼問題是選型問題。jnetpcap 的最后一個(gè)活躍版本停留在很多年前它對(duì) Npcap 的適配靠社區(qū)補(bǔ)丁和你安裝時(shí)的“WinPcap 兼容模式”來(lái)兜底64 位環(huán)境下經(jīng)常要自己再編譯一次 dll。pcap4j 不一樣它是純 Java 項(xiàng)目通過 JNA 在運(yùn)行時(shí)動(dòng)態(tài)加載系統(tǒng)里的 libpcap 或 wpcap.dll不依賴預(yù)編譯的 JNI 二進(jìn)制跨平臺(tái)和版本適配都要省心得多。從維護(hù)節(jié)奏、issue 回復(fù)速度和文檔完整度看新項(xiàng)目沒有理由再選 jnetpcap。對(duì)比項(xiàng)jnetpcappcap4j維護(hù)狀態(tài)基本停更持續(xù)活躍native 加載方式自帶 JNI dll平臺(tái)強(qiáng)綁定JNA 動(dòng)態(tài)加載系統(tǒng) pcap 庫(kù)64 位支持需要自己構(gòu)建原生支持離線 pcap 重放支持但接口較原始Pcaps.openOffline 直接可用結(jié)構(gòu)化協(xié)議解析需要自己手工拼字節(jié)內(nèi)置 Ethernet/IP/TCP/UDP 等包對(duì)象學(xué)習(xí)曲線老教程多但坑多文檔齊全坑有跡可循如果你手上恰好有個(gè)基于 jnetpcap 的老項(xiàng)目能跑就繼續(xù)跑不要把線上正在用的東西沖動(dòng)重寫但如果是新起一個(gè)工具我一般直接上 pcap4j。實(shí)際寫的時(shí)候你會(huì)發(fā)現(xiàn)pcap4j 把解析結(jié)果封裝成一層層對(duì)象調(diào)試起來(lái)比對(duì)著原始字節(jié)猜要舒服得多。2.2 用 Maven 把 pcap4j 拉進(jìn)來(lái)最小 pom 與版本選擇pcap4j 不是單包核心分成兩個(gè) artifactpcap4j-core 提供抓包句柄和設(shè)備枚舉pcap4j-packetfactory-static 提供現(xiàn)成的包對(duì)象工廠。之間有個(gè) packetfactory 是因?yàn)閹?kù)本身也允許你自定義工廠但 99% 的場(chǎng)景用 static 就夠了。下面這個(gè) pom 是我常用的最小配置properties !-- 版本號(hào)以 Maven 中央倉(cāng)庫(kù)最新穩(wěn)定版為準(zhǔn) -- pcap4j.version1.7.7/pcap4j.version /properties dependencies dependency groupIdorg.pcap4j/groupId artifactIdpcap4j-core/artifactId version${pcap4j.version}/version /dependency dependency groupIdorg.pcap4j/groupId artifactIdpcap4j-packetfactory-static/artifactId version${pcap4j.version}/version /dependency dependency groupIdorg.slf4j/groupId artifactIdslf4j-simple/artifactId version1.7.32/version !-- pcap4j 內(nèi)部用 slf4j 打日志給一個(gè)實(shí)現(xiàn)不然全是告警 -- /dependency /dependencies版本號(hào)這里給的是 1.7.7 作為示例真正寫工程時(shí)把 pcap4j.version 換成倉(cāng)庫(kù)里的最新版本。pcap4j 2.x 之后包結(jié)構(gòu)調(diào)整過artifactId 可能合并或改名用 Maven 拉依賴時(shí)注意看中央倉(cāng)庫(kù)的實(shí)際發(fā)布列表不要死抄老工程的坐標(biāo)。slf4j-simple 這個(gè)依賴不是必須的但 pcap4j 內(nèi)部用 slf4j 記錄 JNA 加載和設(shè)備枚舉的過程不綁一個(gè)實(shí)現(xiàn)的話你排查問題時(shí)少了一半日志線索。2.3 環(huán)境變量與 native 庫(kù)Windows 裝 Npcap、Linux 裝 libpcap再跑通設(shè)備枚舉pcap4j 本身不攜帶抓包能力它只是把系統(tǒng)里的 libpcap/Npcap 通過 JNA 包裝給你。所以環(huán)境準(zhǔn)備是第一步也是最多人翻車的一步。Windows 上要先裝 Npcap安裝向?qū)Ю镉幸豁?xiàng) “Install Npcap in WinPcap API-compatible Mode”pcap4j 依賴它來(lái)加載 wpcap.dll這個(gè)選項(xiàng)一定要勾。裝完之后 wpcap.dll 會(huì)出現(xiàn)在 System32 下JNA 從系統(tǒng)目錄自動(dòng)加載不需要你把 JAVA_HOME 指向 Npcap 目錄網(wǎng)上有些教程把環(huán)境變量配置講得過于玄乎這里其實(shí)沒那么復(fù)雜。Linux 上更直接Debian/Ubuntu 系裝 libpcap0.8運(yùn)行時(shí)和 libpcap-dev編譯和 tshark 對(duì)照時(shí)用然后確認(rèn)當(dāng)前用戶有沒有打開原始套接字的權(quán)限后面避坑章節(jié)會(huì)專門講。裝完先別急著寫抓包邏輯先用一段極簡(jiǎn)代碼確認(rèn)庫(kù)加載正常import org.pcap4j.core.PcapNetworkInterface; import org.pcap4j.core.Pcaps; // 列出所有網(wǎng)卡驗(yàn)證 native 環(huán)境和 JNA 加載 ListPcapNetworkInterface devices Pcaps.findAllDevs(); if (devices null || devices.isEmpty()) { // 到這里說(shuō)明 wpcap.dll/libpcap 沒加載成功先別往下寫解析代碼 throw new IllegalStateException(no network interface found, check pcap install); } for (PcapNetworkInterface device : devices) { System.out.println(device.getName() : device.getDescription()); device.getAddresses().forEach(a - System.out.println( address a.getAddress())); } System.out.println(total devices devices.size());這段代碼的邏輯很簡(jiǎn)單Pcaps.findAllDevs 返回系統(tǒng)識(shí)別的網(wǎng)卡列表包括虛擬網(wǎng)卡如 VMware 的 VMnet。如果這里拋 PcapNativeException 或者列表為空說(shuō)明 native 層有問題后面所有代碼都跑不動(dòng)。device.getName 是類似 “\Device\NPF_{GUID}” 或 “eth0” 這樣的內(nèi)核名device.getAddresses 會(huì)帶出該網(wǎng)卡綁定的 IP這一步輸出的信息在后續(xù)按 IP 選擇網(wǎng)卡時(shí)會(huì)直接用上。注意虛擬網(wǎng)卡也會(huì)出現(xiàn)在列表里生產(chǎn)環(huán)境抓包時(shí)先搞清楚你要的是物理網(wǎng)卡還是虛擬網(wǎng)卡否則抓半天全是 VM 內(nèi)網(wǎng)流量。3. 從網(wǎng)卡到協(xié)議解析一個(gè)能直接跑的最小抓包鏈路3.1 打開 PcapHandlesnaplen、promiscuous 和 timeoutMillis 三個(gè)參數(shù)怎么定設(shè)備拿得到之后核心對(duì)象是 PcapHandle它對(duì)應(yīng) libpcap 里一個(gè)抓包會(huì)話。pcap4j 推薦用 Builder 來(lái)配置參數(shù)比裸調(diào) openLive 可讀性好// 按 IP 挑網(wǎng)卡避免在多網(wǎng)卡機(jī)器上拿 device 列表第一個(gè) PcapNetworkInterface nif devices.stream() .filter(d - d.getAddresses().stream() .anyMatch(a - a.getAddress() instanceof Inet4Address a.getAddress().getHostAddress().equals(192.168.1.10))) .findFirst() .orElseThrow(() - new IllegalStateException(網(wǎng)卡 192.168.1.10 不存在)); // 抓包句柄snaplen65535 抓完整幀混雜模式10ms 超時(shí) PcapHandle handle new PcapHandle.Builder(nif.getName()) .snaplen(65535) .promiscuousMode(PcapNetworkInterface.PromiscuousMode.PROMISCUOUS) .timeoutMillis(10) .bufferSize(2 * 1024 * 1024) // 內(nèi)核緩沖區(qū)設(shè) 2MB降低重負(fù)載丟包 .build(); // BPF 過濾表達(dá)式只放行 TCP 和 UDP丟棄 ARP/ICMP 等 handle.setFilter(tcp or udp, BpfProgram.BpfCompileMode.OPTIMIZE);三個(gè)參數(shù)各有講究。snaplen 表示每個(gè)包最多截多少字節(jié)65535 能覆蓋以太網(wǎng)幀上限如果你的分析只關(guān)心包頭設(shè) 128 或 256 能省不少內(nèi)存代價(jià)是拿不到應(yīng)用層 Payload。promiscuous 混雜模式讓網(wǎng)卡把不是發(fā)給本機(jī)的包也收上來(lái)這是“旁路分析”的前提關(guān)掉它就只能看到本機(jī)進(jìn)出的流量。timeoutMillis 在 Windows 上特別關(guān)鍵設(shè)成 0 的話WinPcap/Npcap 的線程模型會(huì)讓你等到內(nèi)核緩沖區(qū)攢滿才返回一批包實(shí)時(shí)性很差設(shè) 10ms 是常見的折中Linux 上也適用。bufferSize 是很多人忽略的默認(rèn)值偏小壓測(cè)場(chǎng)景下內(nèi)核緩沖區(qū)一滿pcap 直接丟包統(tǒng)計(jì)結(jié)果就對(duì)不上。3.2 解析以太網(wǎng)幀和 IP/TCP 頭結(jié)構(gòu)化 API 與手動(dòng)字節(jié)解析對(duì)照pcap4j 的包對(duì)象是分層的packet 是最外層調(diào)用 get(EthernetPacket.class) 拿到以太網(wǎng)頭再往下能取到 IP 頭和 TCP 頭。類型不匹配時(shí)返回 null所以每次取層都要判空// 結(jié)構(gòu)化 API適合開發(fā)期快速驗(yàn)證和后期維護(hù) EthernetPacket eth packet.get(EthernetPacket.class); IpV4Packet ip packet.get(IpV4Packet.class); TcpPacket tcp packet.get(TcpPacket.class); if (tcp null) { return; // 非 TCP 包UDP/ICMP或解析失敗直接跳過 } IpV4Header ipHeader ip.getHeader(); TcpHeader tcpHeader tcp.getHeader(); System.out.printf(%s:%d - %s:%d proto%d bytes%d%n, ipHeader.getSrcAddr().getHostAddress(), tcpHeader.getSrcPort().valueAsInt(), ipHeader.getDstAddr().getHostAddress(), tcpHeader.getDstPort().valueAsInt(), ipHeader.getProtocol().value(), packet.getRawData().length);另一條路是手動(dòng)解析原始字節(jié)。結(jié)構(gòu)化 API 方便但每個(gè)包都要構(gòu)建一堆對(duì)象純統(tǒng)計(jì)場(chǎng)景下 JVM 壓力不小。手動(dòng)解析只要拿到 rawData 后按偏移取值省掉對(duì)象分配byte[] raw packet.getRawData(); if (raw null || raw.length 34) { return; // 14 字節(jié)以太網(wǎng) 20 字節(jié) IP 頭是最低要求不夠說(shuō)明包不完整 } // 以太網(wǎng)頭固定 14 字節(jié)偏移 12-13 是 EtherType0x0800 表示 IPv4 if ((raw[12] 0xFF) ! 0x08 || (raw[13] 0xFF) ! 0x00) { return; // 丟棄 ARP、VLAN 標(biāo)簽包VLAN 會(huì)整體偏移 4 字節(jié)這里先不處理 } int ipOff 14; int ihl (raw[ipOff] 0x0F) * 4; // IP 頭長(zhǎng)度單位是 4 字節(jié) int totalLen ((raw[ipOff 2] 0xFF) 8) | (raw[ipOff 3] 0xFF); // 大端拼接總長(zhǎng)度 int protocol raw[ipOff 9] 0xFF; // 6TCP, 17UDP String srcIp String.format(%d.%d.%d.%d, raw[ipOff 12] 0xFF, raw[ipOff 13] 0xFF, raw[ipOff 14] 0xFF, raw[ipOff 15] 0xFF); if (protocol ! 6 || totalLen ihl 20) { return; // 非 TCP或者 IP 頭之后不足 20 字節(jié) TCP 頭 } int tcpOff ipOff ihl; int srcPort ((raw[tcpOff] 0xFF) 8) | (raw[tcpOff 1] 0xFF); int dstPort ((raw[tcpOff 2] 0xFF) 8) | (raw[tcpOff 3] 0xFF); // TCP 頭的第 14 個(gè)字節(jié)低 6 位分別是 URG/ACK/PSH/RST/SYN/FIN int flags raw[tcpOff 13] 0x3F; boolean syn (flags 0x02) ! 0; boolean fin (flags 0x01) ! 0;這里最容易出錯(cuò)的是符號(hào)擴(kuò)展Java 的 byte 是有符號(hào)的0x80 以上的字節(jié)直接 shift 會(huì)帶出符號(hào)位所以每個(gè)字節(jié)都要 0xFF轉(zhuǎn)成 0~255 再拼。ihl 的算法是因?yàn)?IP 頭長(zhǎng)度字段的單位是 4 字節(jié)取低 4 位后乘 4 才是真實(shí)字節(jié)數(shù)跳過去才是 TCP 頭的起點(diǎn)。如果包是 IPv6EtherType 0x86DD偏移完全不一樣這套解析會(huì)錯(cuò)亂所以入口的 EtherType 判斷很重要。3.3 回調(diào)只入隊(duì)、后臺(tái)線程做解析避免抓包線程成為瓶頸PcapHandle.loop 的監(jiān)聽器在一個(gè)抓包線程里串行執(zhí)行回調(diào)里一旦出現(xiàn)耗時(shí)操作比如解析全部字段、打印日志、寫數(shù)據(jù)庫(kù)內(nèi)核緩沖區(qū)很快被占滿pcap 就開始丟包。這個(gè)坑幾乎每個(gè)初寫抓包程序的人都會(huì)踩一次。我的做法是回調(diào)里只做一件最輕的事把包放進(jìn)有界隊(duì)列然后由消費(fèi)者線程池去解析import java.util.concurrent.*; // 有界隊(duì)列容量 5 萬(wàn)防止消費(fèi)者跟不上時(shí)無(wú)限制堆積內(nèi)存 BlockingQueuePacket queue new LinkedBlockingQueue(50_000); AtomicLong dropped new AtomicLong(); // 記錄因隊(duì)列滿而丟棄的包數(shù) // 抓包線程只入隊(duì)不做任何解析 handle.loop(-1, packet - { if (!queue.offer(packet)) { dropped.incrementAndGet(); } }); // 消費(fèi)者線程池4 個(gè)線程做解析和聚合速度跟不上就排隊(duì) ExecutorService workers Executors.newFixedThreadPool(4); for (int i 0; i 4; i) { workers.submit(() - { while (!Thread.currentThread().isInterrupted()) { Packet packet queue.take(); // 這里再調(diào)用前面的結(jié)構(gòu)化解析或手動(dòng)解析邏輯 } }); }loop 的第一個(gè)參數(shù) -1 表示無(wú)限抓下去傳一個(gè)正整數(shù)就只抓指定數(shù)量的包然后自動(dòng)返回這個(gè)語(yǔ)義在做“只抓 1 萬(wàn)個(gè)包做抽樣統(tǒng)計(jì)”時(shí)很好用。隊(duì)列的 offer 方法在滿時(shí)會(huì)立刻返回 false而不是阻塞抓包線程所以用 AtomicLong 把丟棄數(shù)記下來(lái)——在流量分析里丟包率本身也是一個(gè)需要監(jiān)控的指標(biāo)。消費(fèi)者線程數(shù)不用太多解析本身是 CPU 密集任務(wù)開 4~8 個(gè)跟核數(shù)匹配就行開多了反而在鎖競(jìng)爭(zhēng)上浪費(fèi)時(shí)間。程序退出時(shí)記得 handle.close()它底層釋放的是 native 層的 pcap_t 句柄不關(guān)閉的話在 Windows 上會(huì)殘留抓包會(huì)話下次打開同一張網(wǎng)卡可能失敗。4. 協(xié)議識(shí)別與會(huì)話聚合把包變成可統(tǒng)計(jì)的業(yè)務(wù)指標(biāo)4.1 端口、特征碼、行為三招識(shí)別 HTTP/DNS/TLS拿到一條連接記錄后第一個(gè)問題通常是“這是什么協(xié)議”。純端口判斷是基礎(chǔ)53 大概率是 DNS80/8080 是 HTTP443 是 TLS。但端口可以被復(fù)用內(nèi)網(wǎng)里把服務(wù)跑在非標(biāo)準(zhǔn)端口上的情況比比皆是所以我在端口判斷之外加了一層 Payload 特征碼驗(yàn)證。HTTP 的請(qǐng)求行和響應(yīng)行特征非常明顯DNS 的頭部結(jié)構(gòu)固定TLS 的握手記錄首字節(jié)固定為 0x16// 協(xié)議識(shí)別先看端口再看 Payload 特征返回協(xié)議標(biāo)識(shí) static String classify(int srcPort, int dstPort, byte[] payload) { // 端口 53 基本可以斷定 DNSUDP 上尤其可靠 if (srcPort 53 || dstPort 53) { return DNS; } // 80/8080 先標(biāo)記為 HTTP但要用特征碼二次確認(rèn) boolean isHttpPort srcPort 80 || dstPort 80 || srcPort 8080 || dstPort 8080; if (isHttpPort looksLikeHttp(payload)) { return HTTP; } // 443 上大概率是 TLSStartTLS 或非標(biāo)準(zhǔn)端口靠 ClientHello 特征識(shí)別 if (srcPort 443 || dstPort 443 || looksLikeTls(payload)) { return TLS; } return OTHER; } // 檢查 Payload 前 16 字節(jié)是否像 HTTP static boolean looksLikeHttp(byte[] payload) { if (payload null || payload.length 4) { return false; } String head new String(payload, 0, Math.min(16, payload.length), StandardCharsets.ISO_8859_1); return head.startsWith(GET ) || head.startsWith(POST ) || head.startsWith(PUT ) || head.startsWith(DELETE ) || head.startsWith(HEAD ) || head.startsWith(HTTP/); } // TLS 記錄頭0x16 表示握手第 6 個(gè)字節(jié)是握手類型 0x01 表示 ClientHello static boolean looksLikeTls(byte[] payload) { return payload ! null payload.length 6 (payload[0] 0xFF) 0x16 (payload[5] 0xFF) 0x01; }DNS 的判斷其實(shí)還能再細(xì)一點(diǎn)DNS 頭部前 12 字節(jié)是 ID(2)、標(biāo)志(2)、QDCOUNT(2)……把 flags 的 bit15 取出來(lái)能區(qū)分請(qǐng)求和響應(yīng)QDCOUNT 大于 0 的通常是請(qǐng)求。這套特征識(shí)別不是百分之百內(nèi)網(wǎng)有人把 SSH 挪到 443 端口上跑TLS 特征識(shí)別不出來(lái)但它已經(jīng)能覆蓋絕大多數(shù)正常業(yè)務(wù)流量。識(shí)別結(jié)果會(huì)直接影響后面的協(xié)議占比統(tǒng)計(jì)所以要給“OTHER”留一個(gè)可見的檔位不要什么都吞進(jìn)“未知”里否則統(tǒng)計(jì)報(bào)表做出來(lái)沒法解釋。4.2 五元組會(huì)話聚合FlowKey 設(shè)計(jì)與定時(shí)回收流量分析的第二件事是把逐包記錄聚合成會(huì)話。會(huì)話的天然主鍵是五元組源 IP、源端口、目標(biāo) IP、目標(biāo)端口、協(xié)議。但這里有個(gè)細(xì)節(jié)TCP 客戶端端口是隨機(jī)高位端口如果不做方向歸一化同一個(gè) TCP 連接的來(lái)回流量會(huì)被拆成兩條流A→B 一條B→A 一條。我一般做法是把五元組按字典序歸并成一個(gè)方向無(wú)關(guān)的 key雙向字節(jié)合在一起統(tǒng)計(jì)// 會(huì)話 key五元組但方向歸一化雙向流量合并到同一條流 public final class FlowKey { private final String ipA; private final int portA; private final String ipB; private final int portB; private final int protocol; // 工廠方法把 src/dst 按字典序歸并避免雙向拆成兩條流 public static FlowKey of(String ip1, int p1, String ip2, int p2, int proto) { int cmp ip1.compareTo(ip2); if (cmp 0 || (cmp 0 p1 p2)) { return new FlowKey(ip1, p1, ip2, p2, proto); } return new FlowKey(ip2, p2, ip1, p1, proto); } // equals、hashCode 按五個(gè)字段生成這里省略 } // 聚合表ConcurrentHashMap 保證多消費(fèi)者線程寫入安全 ConcurrentHashMapFlowKey, FlowStats flows new ConcurrentHashMap(); // 每個(gè)包到達(dá)時(shí)更新對(duì)應(yīng)會(huì)話的統(tǒng)計(jì) FlowKey key FlowKey.of(srcIp, srcPort, dstIp, dstPort, protocol); FlowStats stats flows.computeIfAbsent(key, k - new FlowStats(System.currentTimeMillis())); stats.packets; stats.bytes packetLength; stats.lastSeen System.currentTimeMillis();為什么用 computeIfAbsent 而不是先 get 再 put多消費(fèi)者線程同時(shí)處理不同包時(shí)check-then-act 會(huì)產(chǎn)生競(jìng)態(tài)同一個(gè)新會(huì)話可能被兩個(gè)線程各建一條記錄后面的流量就會(huì)被分流到兩條流上統(tǒng)計(jì)徹底失真。computeIfAbsent 在 ConcurrentHashMap 上是原子的能保證同一個(gè) key 只會(huì)創(chuàng)建一個(gè) FlowStats 實(shí)例。如果你還要區(qū)分請(qǐng)求和響應(yīng)方向來(lái)分析“誰(shuí)先發(fā)起連接”就在 FlowStats 里加兩個(gè)方向獨(dú)立的計(jì)數(shù)器而不是改 key 結(jié)構(gòu)——改了 key 結(jié)構(gòu)就回到兩條流的老問題上了。會(huì)話不能無(wú)限存活。TCP 的正常關(guān)閉有 FIN 標(biāo)志但一半以上的流量靠超時(shí)消失比如移動(dòng)端斷網(wǎng)、服務(wù)端直接 RST。我會(huì)用一條定時(shí)任務(wù)清掃空閑會(huì)話ScheduledExecutorService scheduler Executors.newSingleThreadScheduledExecutor(); // TCP 空閑 30 秒、UDP 空閑 10 秒后回收 scheduler.scheduleWithFixedDelay(() - { long now System.currentTimeMillis(); flows.entrySet().removeIf(e - { FlowStats s e.getValue(); long idleLimit e.getKey().protocol 6 ? 30_000 : 10_000; return now - s.lastSeen idleLimit; }); }, 30, 30, TimeUnit.SECONDS);定時(shí)任務(wù)不一定非要引 Quartzjava.util.concurrent 自帶的 ScheduledExecutorService 在這個(gè)場(chǎng)景足夠了。清掃周期取 30 秒太頻繁會(huì)白耗 CPU太懶則表里的幽靈會(huì)話太多。注意 removeIf 在 ConcurrentHashMap 上會(huì)逐個(gè)加鎖如果表里有幾百萬(wàn)條流一次清掃可能耗時(shí)幾百毫秒這是可以接受的但不要把清掃和抓包線程放在同一個(gè)池子里否則業(yè)務(wù)線程會(huì)被搶走。4.3 指標(biāo)設(shè)計(jì)和內(nèi)存邊界吞吐量、TopN 與快照落盤會(huì)話表只是中間態(tài)最終要給人的是幾個(gè)能說(shuō)明問題的指標(biāo)。我做流量分析最少會(huì)出這幾項(xiàng)鏈路吞吐量、協(xié)議占比、包長(zhǎng)分布、TopN 會(huì)話。吞吐量用滑動(dòng)窗口算維護(hù)最近 60 個(gè)秒級(jí)計(jì)數(shù)器每秒清空當(dāng)前桶60 秒窗口求和再除以時(shí)長(zhǎng)就是平均吞吐。包長(zhǎng)分布把長(zhǎng)度分桶0-64、65-128、129-512、513-1024、1024掃描和爆破流量的特征都在小包區(qū)域。指標(biāo)計(jì)算方式用途吞吐量60 秒滑動(dòng)窗口字節(jié)和 / 時(shí)長(zhǎng)發(fā)現(xiàn)突發(fā)流量和基線偏離包長(zhǎng)分布按長(zhǎng)度分桶累加計(jì)數(shù)識(shí)別掃描、小包攻擊協(xié)議占比分類計(jì)數(shù)占總包數(shù)比例業(yè)務(wù)流量構(gòu)成基線TopN 會(huì)話按累計(jì)字節(jié)排序取前 N定位流量大頭和異常外連內(nèi)存邊界的控制是一開始就要想好的不然后面必 OOM。兩個(gè)硬性上限隊(duì)列容量已經(jīng)有界會(huì)話表也要有界。我一般給會(huì)話表設(shè)最大值比如 100 萬(wàn)條達(dá)到上限后按 lastSeen 淘汰最舊的。淘汰邏輯放在定時(shí)清掃里一起做把removeIf的條件改成“超時(shí)或超容量”這樣不會(huì)增加額外的遍歷開銷。每 60 秒把當(dāng)前會(huì)話表和 TopN 快照寫一次日志或時(shí)序庫(kù)然后清空統(tǒng)計(jì)桶會(huì)話表保留但不重置——會(huì)話表的生命周期就是會(huì)話本身的生命周期這是它和臨時(shí)統(tǒng)計(jì)桶最大的區(qū)別。5. 避坑清單Java 流量分析最常見的五個(gè)翻車現(xiàn)場(chǎng)5.1 Windows 上打不開句柄先查 Npcap 的 WinPcap 兼容模式現(xiàn)象Pcaps.findAllDevs 返回空列表或者 openLive 拋 PcapNativeException代碼跟教程一模一樣但就是跑不通。換個(gè)同事的機(jī)器又正常。原因本機(jī)裝了 Npcap但安裝時(shí)沒勾選 “Install Npcap in WinPcap API-compatible Mode”。pcap4j 的 JNA 映射依賴 wpcap.dll 提供 WinPcap 兼容層的函數(shù)入口不勾裝出來(lái)的 Npcap 缺少這些入口加載就會(huì)失敗。另外 JDK 是 64 位就裝 64 位 Npcap位數(shù)混了會(huì)出現(xiàn)加載成功但一調(diào)用就崩潰的怪象。解決重裝 Npcap安裝向?qū)Ю锇鸭嫒菽Ｊ焦瓷涎b完重啟終端和 IDE。然后回到 2.3 節(jié)的設(shè)備枚舉代碼確認(rèn)列表能打印出來(lái)再往下走。5.2 Linux 下普通用戶收不到包c(diǎn)apability 與路徑綁定現(xiàn)象程序不報(bào)錯(cuò)handle 也打開了但 loop 一直拿不到包。sudo 跑立刻正常用普通用戶跑就是黑匣子一樣沒反應(yīng)。原因打開 pcap 句柄需要 CAP_NET_RAW 和 CAP_NET_ADMIN 兩個(gè) capability普通用戶默認(rèn)沒有openLive 在某些內(nèi)核和 libpcap 版本下不會(huì)立刻報(bào)權(quán)限錯(cuò)誤而是直接把抓包靜默失效。解決要么開發(fā)時(shí)直接 sudo 跑要么給 Java 二進(jìn)制附加 capability# 給 java 可執(zhí)行文件附加網(wǎng)絡(luò)抓包權(quán)限注意路徑要跟你的 JDK 實(shí)際路徑一致 sudo setcap cap_net_raw,cap_net_admineip /usr/lib/jvm/java-17-openjdk-amd64/bin/java getcap /usr/lib/jvm/java-17-openjdk-amd64/bin/javasetcap 之后用 getcap 確認(rèn)輸出里能看到 cap_net_raw,cap_net_admin 就說(shuō)明加上了?？釉谟谌绻阌?sdkman、jenv 或者 IDE 內(nèi)置 JDK 切換版本capability 是加在具體二進(jìn)制路徑上的一切換路徑就丟表現(xiàn)為“昨天還能抓包今天突然不行”。我后來(lái)統(tǒng)一把抓包程序打成可執(zhí)行 jar用固定路徑的 JDK 啟動(dòng)腳本去跑才徹底躲開這個(gè)玄學(xué)問題。5.3 重負(fù)載丟包回調(diào)里的耗時(shí)操作是隱形殺手現(xiàn)象空載時(shí)一切正常一上壓測(cè)包數(shù)就少了一大截。在回調(diào)里加了 JSON 序列化或者日志輸出之后丟包更明顯。原因handle.loop 的監(jiān)聽回調(diào)在抓包線程里串行執(zhí)行回調(diào)耗時(shí)長(zhǎng)內(nèi)核 pcap 緩沖區(qū)很快寫滿新到達(dá)的包被內(nèi)核直接丟棄。這個(gè)丟包發(fā)生在 native 層JVM 里看不到任何異常只有拿 tshark 同網(wǎng)卡對(duì)照才會(huì)發(fā)現(xiàn)數(shù)量對(duì)不上。解決回調(diào)里只入隊(duì)解析放到消費(fèi)者線程池。隊(duì)列用有界隊(duì)列滿了記 dropped 數(shù)而不是無(wú)限阻塞。真到了連入隊(duì)都跟不上的極端場(chǎng)景寧可丟包也要保住抓包線程不崩再把丟包率作為監(jiān)控項(xiàng)暴露出來(lái)。5.4 端口和包長(zhǎng)解析出來(lái)是天文數(shù)字字節(jié)序與符號(hào)擴(kuò)展現(xiàn)象在實(shí)際設(shè)備上抓包解析出來(lái)的源端口是 13568明明訪問的是 53 端口。包長(zhǎng)字段出現(xiàn) 65535 之類的怪值偶爾還拋 ArrayIndexOutOfBoundsException程序崩掉。原因兩手罪都犯了。第一Java 的 byte 是有符號(hào)類型0x80 以上的字節(jié)直接 8會(huì)帶符號(hào)擴(kuò)展拼出來(lái)的數(shù)完全不對(duì)第二網(wǎng)絡(luò)字節(jié)序是大端x86 內(nèi)存是小端數(shù)值拼接必須按大端順序手工移位。至于數(shù)組越界是沒做長(zhǎng)度校驗(yàn)就取了 raw[20]遇到超短包直接訪問越界。解決所有字節(jié)取值統(tǒng)一寫成(raw[i] 0xFF)再用大端方式組合或者用ByteBuffer.wrap(raw).order(ByteOrder.BIG_ENDIAN)統(tǒng)一讀取。每次解析前先判長(zhǎng)度以太網(wǎng)加 IP 頭加 TCP 頭至少要 54 字節(jié)不足就直接跳過。這一步是血淚經(jīng)驗(yàn)錯(cuò)一兩個(gè)字節(jié)在本地可能看不出來(lái)上了生產(chǎn)流量就原形畢露。5.5 長(zhǎng)時(shí)間運(yùn)行 OOM會(huì)話表無(wú)限增長(zhǎng)和隊(duì)列積壓現(xiàn)象程序跑了幾個(gè)小時(shí)突然 OOM重啟后又復(fù)發(fā)。GC 日志顯示老年代持續(xù)上漲Full GC 越來(lái)越頻繁最后抓包線程卡死。原因網(wǎng)絡(luò)上有掃描器或異常程序在產(chǎn)生大量五元組會(huì)話表無(wú)限膨脹回調(diào)隊(duì)列如果設(shè)計(jì)成無(wú)界隊(duì)列消費(fèi)者線程一慢隊(duì)列也能吃掉全部堆內(nèi)存。解決會(huì)話表加容量上限達(dá)到上限按 lastSeen 淘汰最舊會(huì)話隊(duì)列全部改有界入隊(duì)失敗只計(jì)數(shù)不阻塞另外把-Xmx設(shè)成一個(gè)可控的值而不是放任默認(rèn)比如-Xmx2g。定期快照落盤后主動(dòng)調(diào)用System.gc()并不解決問題真正有效的是把每個(gè)集合的上限都卡死讓內(nèi)存用量和流量大小解耦。6. 上線前的三個(gè)進(jìn)階動(dòng)作離線重放、性能驗(yàn)證與數(shù)據(jù)一致性6.1 把抓包來(lái)源抽象成接口pcap 離線重放先行新需求到手我一般先把“包從哪來(lái)”抽象出來(lái)。LiveSource 和 OfflineSource 都實(shí)現(xiàn)同一個(gè) PacketSource 接口解析層只管拿包不關(guān)心包是網(wǎng)卡來(lái)的還是文件來(lái)的。pcap4j 的離線讀取只需要一行差異// 離線模式讀 pcap 文件同一套解析和聚合邏輯直接復(fù)用 PcapHandle offline Pcaps.openOffline(capture.pcap); offline.loop(-1, packet - queue.offer(packet)); // 進(jìn)同一個(gè)隊(duì)列離線重放的價(jià)值太大了。出問題時(shí)先用 Wireshark 在真機(jī)上抓一份 pcap回到測(cè)試環(huán)境重放問題就能穩(wěn)定復(fù)現(xiàn)不用在生產(chǎn)網(wǎng)卡上反復(fù)折騰。我在 OfflineSource 里還會(huì)加一個(gè)限速參數(shù)控制每秒吐多少包模擬慢速和高壓兩種場(chǎng)景做回歸。6.2 用 tshark 對(duì)照驗(yàn)證統(tǒng)計(jì)結(jié)果再摳兩個(gè)性能點(diǎn)解析和聚合寫完第一件事是驗(yàn)證結(jié)果對(duì)不對(duì)而不是繼續(xù)加功能。抓一份固定流量的 pcap然后用 tshark 出會(huì)話統(tǒng)計(jì)做對(duì)照# 對(duì)比 TCP 會(huì)話數(shù)和字節(jié)量檢驗(yàn)聚合邏輯是否準(zhǔn)確 tshark -r capture.pcap -q -z conv,tcptshark 的 conv 表會(huì)列出每個(gè)會(huì)話的雙向包數(shù)和字節(jié)數(shù)拿它和你的 TopN 輸出比數(shù)量級(jí)誤差在幾 KB 以內(nèi)就說(shuō)明解析和聚合鏈路沒問題。如果差很多多半是方向歸并或超時(shí)回收的口徑不一致先對(duì)齊口徑再談性能。性能上值得摳的點(diǎn)有兩個(gè)一是純統(tǒng)計(jì)場(chǎng)景少用包對(duì)象pcap4j 的 Packet 對(duì)象分層構(gòu)建開銷不小只關(guān)心包頭就手動(dòng)解析 rawData二是 bufferSize 在壓測(cè)環(huán)境調(diào)到 4~8MB減少內(nèi)核丟包。數(shù)據(jù)一致性主要靠 ConcurrentHashMap 的原子方法和 AtomicLong 計(jì)數(shù)器遇到“統(tǒng)計(jì)值時(shí)大時(shí)小”的問題先懷疑是不是多線程下用了普通 HashMap。說(shuō)句實(shí)在的我以前做抓包也愛直接在回調(diào)里一把梭直到被線上丟包教育過一次。現(xiàn)在的習(xí)慣是任何抓包需求都先落一份 pcap離線重放跑通再上生產(chǎn)網(wǎng)卡。有一次半夜線上異常外連就是靠離線重放把解析邏輯調(diào)對(duì)上線后半小時(shí)就定位到是臺(tái)測(cè)試機(jī)的定時(shí)任務(wù)在掃外網(wǎng)端口。這項(xiàng)目做下來(lái)最大的體會(huì)是抓包不難難的是讓解析邏輯在真實(shí)流量下不翻車、不 OOM邊界和上限在一開始就定好。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取