利用Wireshark查找進程間網絡通信問題

劉 雋，李 博

（1.中國鐵道科學研究院 通信信號研究所， 北京 100081；2.中國鐵路總公司 科技管理部， 北京 100844）

方法與應用

利用Wireshark查找進程間網絡通信問題

劉 雋1，李 博2

（1.中國鐵道科學研究院 通信信號研究所， 北京 100081；2.中國鐵路總公司 科技管理部， 北京 100844）

本文描述一個在實際應用中遇到的進程間網絡通信問題，介紹利用Wireshark對網絡通信數據進行捕獲、分析，并定位出問題產生原因的過程。

Wireshark；進程間通信；UDP；網絡協議分析

進程間通信有多種機制，其中利用套接字（Socket）實現進程間數據交換是比較通用的一種。由于通信的進程之間隔著多層網絡協議以及設備，如果出現數據發送與接收方面的問題，就需要對網絡數據進行捕獲與分析，弄清楚數據出處。

1 問題描述

在一臺主機上同時運行A、B兩個軟件，A屬于3層架構中的數據訪問層，B屬于業務邏輯層。B將業務邏輯信息發送給A，再由A通過局域網轉發給其它展現層終端軟件。A同時還要對B的運行狀態進行實時監控，在一段時間內，例如5 s，如果無法收到B的任何信息，A將終止B的運行并重新啟動B。A與B的開發及運行環境如表1所示。

在實際運行過程中，A會不定期終止B進程，而且頻率遠超出了設計所允許的范圍。查看A的運行日志，終止B的原因是A的信息接收計時器超時，而B的運行日志則顯示已經按時向A發送心跳信息。在排除了A、B信息發送與接收計時出錯的可能性之后，問題聚焦在A與B兩進程之間的數據通信上。

UDP是一種無連接的傳輸層協議，重效率輕可靠性，不提供數據包分組、組裝，不能對數據包進行排序，因此當報文發送之后，是無法得知其是否安全完整到達的。如此一來，就難以斷定到底是B進程的發送出了問題，還是A進程的接收出了問題，因而需要通過其它方法來獲得A、B之間實際的數據發送與接收情況，也就是要對網絡通信數據包進行截獲與分析。

表1 開發及運行環境

2 Wireshark

Wireshark是一個遵循GNU GPL許可證的開源網絡協議分析軟件。Wireshark利用網卡的混雜模式，通過WinPcap接口直接獲取網絡數據包，不影響正常通信，并以易于理解的方式展現給用戶。

Wireshark能夠在多種UNIX、Linux以及Windows操作系統上運行，它的特點如下。

（1）多協議支持：既支持TCP、UDP、HTTP等通用協議，也支持AppleTalk高級協議。（2）實時網絡數據分析：能夠獲取網絡上的實時數據流，并快速生成與數據相關的協議、傳輸介質、通信通道等信息。（3）友好的用戶界面：具有交互式圖形界面，便于對獲取的數據包進行分析。同時提供數據包過濾、導出、名稱解析等高級選項。（4）開源項目：全球近1 000位程序員參與軟件的開發，每個用戶都可以依據各自的需求編寫代碼并將其加入到項目中。

Wireshark擁有的強大而可靠的功能，利用它來分析A、B進程間的實際通信情況是一個不錯的選擇。

3 本機IP通信問題

在Windows中發送網絡數據時，如果目的地址就是本機的IP地址，數據包經過本機TCP/IP協議棧的傳輸層、互聯網層交給網絡訪問層內的網卡驅動程序處理，隨后通過環回接口再返回到互聯網層，因此數據不會出現在相應的網絡上。本文中A、B進程之間的通信正是通過主機的實際IP地址192.168.1.16進行的，因而正常情況下B發送的數據包不會被Wireshark所獲得。為了確保Wireshark能夠正常發揮作用，需要修改主機的路由表，增加一條從本機IP到默認網關的路由。遵從這條路徑，B進程發送的數據包就會由本機物理網卡發送給網關，經網關中轉回本機后再發給A進程。數據包一經過本機網卡，就能夠被Wireshark輕松獲取。

增加路由的命令格式如下：

route add ＜本機IP＞ mask 255.255.255.255 ＜默認網關IP＞ metric 1

4 使用Wireshark捕獲數據

4.1 選擇目標接口

Wireshark具備同時對一臺主機上的多個不同類型網絡接口進行數據捕獲的能力，為了避免有用的信息被淹沒在海量的數據中，需要將目標接口限定在網卡上，也就是具有192.168.1.16地址的那個網卡。

4.2 設置捕獲過濾器（Capture Filter）

通過捕獲過濾器可以讓Wireshark只捕獲滿足條件的數據包。

本文使用的捕獲過濾器表達式為：udp && host 192.168.1.16。其含義是：只捕獲UDP數據包，并且數據包的地址是192.168.1.16。

4.3 設置顯示過濾器（Display Filter）

通過顯示過濾器可以讓Wireshark對已捕獲的數據進一步篩選，并顯示在用戶界面上。

本文使用的顯示過濾器表達式為：eth.dst == 40:f2:e9:9d:b9:d4 && udp.dstport eq 1024。其含義是：顯示目標網卡的MAC地址是“40:f2:e9:9d:b9:d4”（也就是192.168.1.16對應的MAC地址），并且UDP目標端口是1024的數據包。

4.4 捕獲數據包

Wireshark在執行實時數據捕獲時，會將有效數據顯示在界面的數據包列表、數據包詳情、數據包字節3個區域中。數據包列表區中列出了所有符合過濾條件的數據包，內容為序號、時間、源地址、目標地址、協議類型等；數據包詳情區會將用戶在數據包列表區選中的某數據包的詳細信息展示出來，包括各層協議的字段內容；數據包字節區以16進制形式顯示出選中數據包的全部字節內容。

4.5 創建圖表

本文中關心的是數據發送與時間的關系，數據統計圖能更加直觀的反映通信變化的趨勢。Wireshark提供了IO Graph來繪制這樣的統計圖。IO Graph的參數是可以定制的，例如：將X軸定義為實際時間軸，1 s/刻度，刻度間隔10像素；Y軸定義為數據包數量軸，1包/刻度，最大刻度為10；數據過濾器表達式與顯示過濾器表達式一致。

4.6 完成捕獲

如果捕獲到了足夠多的數據包，可以停止捕獲，并將全部的捕獲數據或者僅數據包列表區的數據保存成捕獲文件，以便于進行后續的離線數據分析。

5 數據分析

通過查看A進程的運行日志，得知B進程在19:06:35出現信息發送超時現象。利用Wireshark繪制的相應時段IO Graph如圖1所示。

圖1 B進程數據發送IO Graph

圖1 中先出現尖峰，隨后進入波谷并探底，最后又恢復正常。再查看對應時間段數據包列表區和數據包詳情區顯示的信息，B進程在19:06:27～19:06:30發送大量的業務信息，1 s后停止發送信息，在大約4 s后的19:06:35恢復正常，繼續發送心跳信息。上述情況在后續長時間的捕獲與分析中也多次反復出現，初步結論是業務信息的發送影響了心跳信息的按時發送。

隨后通過復查B的源代碼印證結論。B采用兩個獨立的線程分別負責發送業務信息和心跳信息，線程間共用一個UdpClient通信對象。雖然在兩個線程間設置了同步鎖，但業務信息發送線程在完成發送任務后沒有及時釋放通信對象和同步鎖，進而造成心跳發送線程等待時間過長，后續心跳發送超時。

問題的根源找到了，解決方法就是在業務信息發送線程完成信息發送后迅速釋放通信對象，解除同步鎖。

6 結束語

Wireshark可以查找網絡通信的問題，本文捕獲、分析同主機進程間網絡數據的過程就是Wireshark的基本應用方法，這套方法同樣可以用來追蹤主機間，基于各種協議的網絡通信問題。

[1]林沛滿. Wireshark網絡分析就這么簡單[M]. 北京：人民郵電出版社，2014.

[2] Singh, Abhinav. Instant Wireshark Starter[M]. Birmingham: Packt Publishing, 2013.

[3] Stevens, W.R. TCP/IP Illustrated, Volume 1: The Protocols[M]. Reading, Mass: Addison-Wesley, 1994.

責任編輯 陳 蓉

Solving inter-process network communication problem via Wireshark

LIU Jun1, LI Bo2
( 1. Signal & Communication Research Institute, China Academy of Railway Sciences, Beijing 100081, China; 2. Department of Science and Technology, China Railway, Beijing 100844, China )

This paper described an inter-process communication problem encountered in practical application scenario, and introduced in detail the trouble-shooting procedure, which included the capture and analysis of network communication data via Wireshark.

Wireshark; inter-process communication; UDP; network protocol analysis

U285.4∶TP39

A

1005-8451（2015）09-0030-03

2015-01-06

劉 雋，副研究員；李 博，工程師。