6.1 Wireshark高級功能

本章將介紹Wireshark的一些高級功能。

6.1.1 Following Protocol Streams

以應用程序層的方式查看協議可能非常有幫助。也許您正在尋找Telnet流中的密碼，或者您試圖弄清數據流。也許您只需要一個顯示過濾器即可僅顯示TLS或SSL流中的數據包。如果是這樣，Wireshark遵循協議流的功能將對您有用。

要過濾到特定的流，請在您感興趣的流/連接的數據包列表中選擇一個TCP，UDP，TLS或HTTP數據包，然后選擇菜單項Analyze →Follow TCP Stream （或使用上下文菜單數據包列表）。Wireshark將設置一個合適的顯示過濾器，并顯示一個對話框，其中顯示了來自流的數據，如圖6.1““跟隨TCP流”對話框”所示。

• tip
  在協議流之后，應用顯示過濾器，該過濾器選擇當前流中的所有數據包。有些人打開“關注TCP流”對話框，然后立即將其關閉，以隔離特定的流。如果不需要此行為，則使用“返回”按鈕關閉對話框將重置顯示過濾器。

圖6.1。“跟隨TCP流”對話框

流內容的顯示順序與網絡上顯示的順序相同。不可打印的字符由點代替。從客戶端到服務器的流量顯示為紅色，而從服務器到客戶端的流量顯示為藍色。可以通過打開Edit → Preferences并在Apperance →Font and Colors下，為Sample "Follow Stream" client text和Sample "Follow Stream" server text選項選擇不同的顏色。

進行實時捕獲時，流內容不會更新。要獲取最新內容，您必須重新打開對話框。

您可以選擇以下操作：

Help

顯示此幫助。

Filter out this stream

應用顯示過濾器，從顯示中刪除當前流數據。

Print

以當前選定的格式打印流數據。

Save as…

以當前選擇的格式保存流數據。

Back

關閉此對話框并還原以前的顯示過濾器。

Close

關閉此對話框，使當前顯示過濾器生效。

默認情況下，Wireshark同時顯示客戶端和服務器數據。您可以選擇Entire conversation 以在客戶端到服務器或服務器到客戶端數據兩者之間切換。

您可以選擇以下列格式之一查看數據：

ASCII

在此視圖中，您可以看到每個方向的ASCII數據。顯然最適合基于ASCII的協議，例如HTTP。

C Arrays

這使您可以將流數據導入到自己的C程序中。

EBCDIC

對于那里的大鐵怪胎。

HEX Dump

這使您可以查看所有數據。這將需要大量的屏幕空間，最好與二進制協議一起使用。

UTF-8

類似于ASCII，但將數據解碼為UTF-8。

UTF-16

類似于ASCII，但將數據解碼為UTF-16。

YAML

這使您可以將流作為YAML加載。

Raw

這使您可以將未更改的流數據加載到其他程序中以進行進一步檢查。顯示內容將與ASCII設置相同，但是“Save As”將生成一個二進制文件。

您可以使用“Stream”選擇器在流之間切換。

您可以通過在“Find”輸入框中輸入文本并按Find Next來搜索文本。

圖6.2。“跟隨HTTP / 2流”對話框

除了附加的”Substream” 對話框字段外，“ HTTP / 2流”對話框類似于 “Follow TCP Stream” 對話框。HTTP/2 Stream由HTTP/2 Stream索引（字段名http2.streamid）標識，該索引在TCP連接中是唯一的。“Stream” 選擇器確定TCP連接，而“Substream” 選擇器用于選擇HTTP/2 Stream ID。

QUIC協議類似，第一個數字選擇UDP流索引，而“ Substream”字段選擇QUIC Stream ID。

6.1.2 顯示數據包字節

如果選定的數據包字段未顯示所有字節（即顯示時被截斷），或者顯示為字節而不是字符串，或者由于它們包含圖像或HTML而需要更多格式，則可以使用此對話框。

此對話框還可用于解碼來自base64，zlib壓縮或帶引號的可打印字段的字段字節，并將解碼后的字節顯示為可配置輸出。也可以選擇設置開始字節和結束字節的字節子集。

您可以選擇以下操作：

Help

顯示此幫助。

Print

以當前選定的格式打印字節。

Copy

以當前選定的格式將字節復制到剪貼板。

Save As

將字節保存為當前選定的格式。

Close

關閉此對話框。

您可以選擇從以下格式之一解碼數據：

None

這是默認設置，不解碼任何內容。

Base64

這將從Base64解碼。

Compressed

這將使用zlib解壓縮緩沖區。

Quoted-Printable

這將從帶引號的字符串解碼。

ROT-13

這將解碼ROT-13編碼的文本。

您可以選擇以下列格式之一查看數據：

ASCII

在此視圖中，字節顯示為ASCII。所有控制字符和非ASCII字節均由點代替。

ASCII & Control

在此視圖中，所有控制字符均使用UTF-8符號顯示，并且所有非ASCII字節均由點代替。

C Array

這使您可以將字段數據導入到自己的C程序中。

EBCDIC

對于那里的大鐵怪胎。

Hex Dump

這使您可以查看所有數據。這將需要大量的屏幕空間，最好與二進制協議一起使用。

HTML

這使您可以查看所有格式化為HTML文檔的數據。Qt QTextEdit類支持HTML。

Image

這將嘗試將字節轉換為圖像。支持大多數流行的格式，包括PNG，JPEG，GIF和BMP。

ISO 8859-1

在此視圖中，字節顯示為ISO 8859-1。

Raw

這使您可以將未更改的流數據加載到其他程序中以進行進一步檢查。顯示屏將顯示十六進制數據，但“另存為”將生成一個二進制文件。

UTF-8

在此視圖中，字節顯示為UTF-8。

UTF-8

在此視圖中，字節顯示為UTF-16。

YAML

這會將字節顯示為YAML二進制轉儲。

您可以通過在 “Find”輸入框中輸入文本并按Find Next來搜索文本。

6.1.3 專家資訊

Wireshark會跟蹤在捕獲文件中發現的任何異常和其他感興趣的項目，并將其顯示在“專家信息”對話框中。目的是讓您更好地了解不常見或值得注意的網絡行為，并使新手和專家用戶比手動掃描數據包列表更快地發現網絡問題。

Expert information is only a hint
專家信息是調查的起點，而不是終點。每個網絡都不盡相同，您有責任驗證Wireshark的專家信息是否適用于您的特定情況。專家信息的存在不一定表示問題，專家信息的缺乏不一定表示一切正常。

專家信息的數量在很大程度上取決于所使用的協議。盡管某些常見協議（如TCP和IP）的解剖器將顯示詳細信息，而其他解剖器將顯示很少或沒有。

下面介紹單個專家信息條目的組件以及專家用戶界面。

6.1.3.1 專家信息條目

專家信息條目按嚴重性級別（如下所述）分組，并且包含以下內容：

表6.1。專家信息項示例

6.1.3.1.1 嚴重程度

每個專家信息項都有一個嚴重性級別。從最低到最高使用以下級別。Wireshark使用不同的顏色標記它們，這些顏色顯示在括號中：

Chat (blue)

有關常規工作流程的信息，例如設置了SYN標志的TCP數據包。

Note (cyan)

值得注意的事件，例如，應用程序返回了常見的錯誤代碼，例如HTTP 404。

Warn (yellow)

警告，例如應用程序返回了異常錯誤代碼，例如連接問題。

Error (red)

嚴重的問題，例如格式錯誤的數據包。

6.1.3.1.2 摘要

每個專家信息項的簡短說明文字。

6.1.3.1.3 組

除嚴重性級別外，專家信息項也按組進行分類。當前實現了以下組：

Assumption

協議字段的數據不完整，已根據假設值進行了剖析。

Checksum

校驗和無效。

Comment

數據包注釋。

Debug

調試信息。在Wireshark的發行版本中，您不應看到此組。

Decryption

解密問題。

Deprecated

協議字段已棄用。

Malformed

格式錯誤的數據包或解剖器存在錯誤。對該數據包的解剖中止。

Protocol

違反協議規范（e.g. invalid field values or illegal lengths）。對該包的解剖可能仍在繼續。

Reassemble

重新組裝時出現問題，e.g. not all fragments were available or an exception happened during reassembly。

Request Code

一個應用程序請求（e.g. File Handle == x）。通常指定聊天嚴重性級別。

Response Code

應用程序響應代碼指示潛在的問題，e.g. HTTP 404 page not found。

Security

安全問題，e.g. an insecure implementation。

Sequence

協議序列號可疑，e.g. it wasn’t continuous or a retransmission was detected。

Undecoded

解剖不完整或由于其他原因無法解碼數據。

將來可能會添加更多組。

6.1.3.1.4 協議

創建專家信息項的協議解剖器。

6.1.3.2 “Expert Information” 對話框

您可以通過選擇Analyze → Expert Info或單擊主狀態欄中的專家級別指示器來打開專家信息對話框。

右鍵單擊某個項目，將允許您基于該項目應用或準備過濾器，復制其摘要文本以及執行其他任務。

圖6.3。“專家信息”對話框

您可以選擇以下操作：

Limit to display filte

僅顯示與當前顯示過濾器匹配的數據包中存在的專家信息項。

Group by summary

通過摘要將項目分組，而不是上述分組。

Search

僅顯示與搜索字符串匹配的項目，例如“ dns”。支持正則表達式。

Show…

用于顯示或隱藏每個嚴重性級別。例如，如果需要，您可以取消選擇“聊天和筆記”嚴重性。

Help

帶您進入用戶指南的本部分。

Close

關閉對話框。

6.1.3.3 “Colorized” 協議詳細信息樹

圖6.4。“彩色”協議詳細信息樹

數據包詳細信息樹根據其嚴重性級別顏色用專家信息標記字段，例如，“Warning” 嚴重性為黃色背景。該顏色會傳播到樹中的頂級協議項目，以便輕松查找創建專家信息的字段。

對于上面的示例屏幕截圖，IP“Time to live” 值非常低（僅為1），因此相應的協議字段用青色背景標記。為了更輕松地在數據包樹中找到該項目，IP協議頂級項目也標記為青色。

6.1.3.4 “Expert” 數據包列表列

圖6.5。“專家”數據包列表列

可選的“Expert Info Severity” 數據包列表列可用，顯示數據包的最高嚴重性，如果一切正常，則保持為空。該列默認情況下不顯示，但可以使用8.1.4 首選項所述的“ 首選項列”頁面輕松添加。

6.1.4 TCP分析

默認情況下，Wireshark的TCP Dissector跟蹤每個TCP會話的狀態，并在檢測到問題或潛在問題時提供其他信息。首次打開捕獲文件時，對每個TCP數據包進行一次分析。數據包按照在數據包列表中出現的順序進行處理。您可以通過“分析TCP序列號” TCP Dissector首選項啟用或禁用此功能。

有關分析位于TCP之上的數據或協議（例如HTTP）的信息，請參見 6.1.7.3 TCP 重組。

圖6.6。“ TCP分析”包詳細信息

TCP分析標記被添加到 “SEQ/ACK analysis”下的TCP協議樹中。每個標志描述如下。“next expected sequence number”和 “next expected acknowledgement number” 等術語指的是以下內容：

Next expected sequence number

最近看到的序列號加上段長度。當沒有分析標志且窗口探針為零時設置。最初為零，并基于同一TCP流中的先前數據包進行計算。請注意，這可能與tcp.nxtseq協議字段不同。

Next expected acknowledgement number

段的最后看到的序列號。當沒有分析標志且窗口探針為零時設置。

Last-seen acknowledgment number

始終設置。請注意，這與下一個預期的確認號不同。

Last-seen acknowledgment number

始終為每個數據包更新。請注意，這與下一個預期的確認號不同。

TCP ACKed unseen segment

當將期望的下一個確認號設置為反向并且小于當前確認號時設置。

TCP Dup ACK <frame>#<acknowledgement number>

滿足以下所有條件時設置：

• 段大小為零。
• 窗口大小非零且未更改。
• 下一個預期的序列號和最后看到的確認號不為零（即，連接已建立）。
• 未設置SYN，FIN和RST。

TCP Fast Retransmission

滿足以下所有條件時設置：

• 這不是保持活動的數據包。
• 在正向，段大小大于零或設置了SYN或FIN。
• 下一個預期的序列號大于當前的序列號。
• 我們在反向方向上有兩個以上的重復ACK。
• 當前序列號等于下一個預期的確認號。
• 我們在不到20毫秒前看到了最后一個確認。

取代“Out-Of-Order”，“Spurious Retransmission”和“Retransmission”。

TCP Keep-Alive

當段大小為零或一時設置，當前序列號比下一個預期序列號小一個字節，并且設置了SYN，FIN或RST中的任何一個。

取代“ “Fast Retransmission”, “Out-Of-Order”, “Spurious Retransmission”, and “Retransmission”。

TCP Keep-Alive ACK

滿足以下所有條件時設置：

• 段大小為零。
• 窗口大小非零且未更改。
• 當前序列號與下一個預期序列號相同。
• 當前的確認號與上次看到的確認號相同。
• 相反方向上最近看到的數據包是保持活動狀態。
• 數據包不是SYN，FIN或RST。

取代 “Dup ACK” and “ZeroWindowProbeAck”。

TCP Out-Of-Order

滿足以下所有條件時設置：

• 這不是保持活動的數據包。
• 在正向，段長度大于零或設置了SYN或FIN。
• 下一個預期的序列號大于當前的序列號。
• 下一個預期序列號和下一個序列號不同。
• 最后一個分段到達Out-Of-Order RTT閾值內值可以是“SEQ/ACK analysis” 下的“ iRTT”(tcp.analysis.initial_rtt) 字段中顯示的值（如果存在）或默認值（3ms）。

取代 “Spurious Retransmission” and “Retransmission”。

TCP Port numbers reused

當設置了SYN標志（不是SYN + ACK）時設置，我們有一個使用相同地址和端口的現有會話，并且序列號不同于現有會話的初始序列號。

TCP Previous segment not captured

當前序列號大于下一個預期序列號時設置。

TCP Spurious Retransmission

根據反方向的分析數據檢查重傳。滿足以下所有條件時設置：

• 設置了SYN或FIN標志。
• 這不是保持活動的數據包。
• 段長度大于零。
• 該流的數據已被確認。即，已經設置了最后一次看到的確認號碼。
• 下一個序列號小于或等于上次確認的編號。

取代“Retransmission”。

TCP Retransmission

滿足以下所有條件時設置：

• 這不是保持活動的數據包。
• 在正向，段長度大于零或設置了SYN或FIN標志。
• 下一個預期的序列號大于當前的序列號。

TCP Window Full

當段大小為非零時設置，我們知道反向的窗口大小，而我們的段大小超過反向的窗口大小。

TCP Window Update

滿足以下所有條件時設置：

• 段大小為零。
• 窗口大小不為零，并且不等于上次看到的窗口大小。
• 序列號等于下一個預期序列號。
• 確認號等于最后一次看到的確認號。
• 沒有設置SYN，FIN或RST。

TCP ZeroWindow

當接收窗口大小為零且未設置SYN，FIN或RST時設置。

每個TCP標頭中的window字段通告接收方可以接受的數據量。如果接收方不能再接收任何數據，它將窗口值設置為零，這將通知發送方暫停其傳輸。在某些特定情況下，這是正常現象，例如，打印機在裝入或翻轉紙張時可能使用零窗口來暫停打印作業的傳輸。但是，在大多數情況下，這表明接收端存在性能或容量問題。即使可能導致零窗口的基本狀況迅速清除，也可能需要很長時間（有時是幾分鐘）來恢復暫停的連接。

TCP ZeroWindowProbe

當序列號等于下一個預期序列號，段大小為1，反方向上次看到的窗口大小為零時設置。

如果接收器丟棄了來自零窗口探測器的單個數據字節（未確認），則如果該段的以下所有條件均成立，則不應將該后續段標記為重傳：*The segment size is larger than one. *下一個預期序列號比當前序列號少一個。

這會影響“Fast Retransmission”, “Out-Of-Order”, or “Retransmission”。

TCP ZeroWindowProbeAck

滿足以下所有條件時設置：

• 段大小為零。
• 窗口大小為零。
• 序列號等于下一個預期序列號。
• 確認號等于最后一次看到的確認號。
• 反方向上最后看到的數據包是零窗口探針。

取代“ TCP Dup ACK”。

6.1.5 時間戳

本部分將為您提供有關Wireshark處理時間戳時發生的情況的信息。

捕獲數據包時，每個數據包都帶有時間戳記。這些時間戳記將保存到捕獲文件中，因此它們也可用于（以后）分析。

那么這些時間戳記從何而來？捕獲時，Wireshark從libpcap（Npcap）庫獲取時間戳，該時間戳又從操作系統內核獲取。如果從捕獲文件加載捕獲數據，則Wireshark顯然會從該文件獲取數據。

6.1.5.1 Wireshark內部

Wireshark用于保留數據包時間戳的內部格式包括日期（自1970年1月1日以來的天數）和一天中的時間（自午夜以來的納秒數）。您可以調整Wireshark在數據包列表中顯示時間戳數據的方式，有關詳細信息，請參見3.2.3 “View” 菜單的“時間顯示格式”項 。

在讀取或寫入捕獲文件時，Wireshark根據需要在捕獲文件格式和內部格式之間轉換時間戳數據。

捕獲時，Wireshark使用支持微秒分辨率的libpcap（Npcap）捕獲庫。除非您使用專門的捕獲硬件，否則此分辨率應該足夠。

6.1.5.2 捕獲文件格式

Wireshark知道的每種捕獲文件格式都支持時間戳。特定捕獲文件格式支持的時間戳精度差異很大，范圍從一秒“ 0”到一納秒“ 0.123456789”。大多數文件格式以固定的精度（例如，微秒）存儲時間戳，而某些文件格式甚至能夠自身存儲時間戳精度。

Wireshark（和許多其他工具）使用的通用libpcap捕獲文件格式僅支持固定的微秒分辨率“ 0.123456”。

將數據寫入無法提供實際精度存儲功能的捕獲文件格式將導致信息丟失。例如，如果加載具有納秒分辨率的捕獲文件并將捕獲數據存儲在libpcap文件（具有微秒分辨率）中，則Wireshark顯然必須將精度從納秒降低到微秒。

6.1.5.3 準確性

人們經常問“ Wireshark提供哪個時間戳精度？”Wireshark本身不會創建任何時間戳，而只是從“其他地方”獲取它們并顯示它們。因此，準確性將取決于您使用的捕獲系統（操作系統，性能等）。因此，上述問題通常難以回答。

6.1.6 包重組

6.1.6.1 什么是包重組

網絡協議通常需要傳輸本身完整的大量數據，例如在傳輸文件時。基礎協議可能無法處理該塊大小（例如，網絡數據包大小的限制），或者像TCP這樣基于流的協議，根本不知道數據塊。

在那種情況下，網絡協議必須自己處理塊邊界，并將數據分布在多個數據包上。顯然，它還需要一種機制來確定接收方的塊邊界。

盡管特定的協議規范可能為此使用不同的術語（例如，分段，碎片整理等），但Wireshark稱這種機制為重組。

6.1.6.2 Wireshark如何處理它

對于Wireshark知道的某些網絡協議，實現了一種機制來查找，解碼和顯示這些數據塊。Wireshark將嘗試查找此塊的相應數據包，并將合并的數據顯示為“數據包字節”窗格中的其他頁面（有關此窗格的信息。請參見3.4.3 “Packet Bytes” 窗格）。

圖6.7。“ Packet Bytes”窗格具有重新組合的選項卡

重組可能會在幾個協議層進行，因此有可能在“Packet Bytes”窗格中顯示多個選項卡。

例如，在HTTP GET響應中，返回所請求的數據（例如HTML頁面）。Wireshark將在 “Packet Bytes” 窗格的新選項卡“Uncompressed entity body”中顯示數據的十六進制轉儲。

默認情況下，在首選項中啟用了重組，但可以在相關協議的首選項中禁用重組。啟用或禁用協議的重組設置通常需要兩件事：

1. 下層協議（例如TCP）必須支持重組。通常，可以通過協議首選項啟用或禁用此重組。
2. 更高級別的協議（例如HTTP）必須使用重組機制來重組分段的協議數據。通常也可以通過協議首選項啟用或禁用此功能。

較高級別協議設置的工具提示將通知您是否以及必須考慮哪個較低級別協議設置。

6.1.6.3 TCP重組

諸如HTTP或TLS之類的協議可能跨越多個TCP段。TCP協議首選項“允許子分解器重組TCP流”（默認情況下啟用）使Wireshark可以收集連續的TCP段序列并將其移交給更高級別的協議（例如，重建完整的HTTP消息） 。包列表中除最后一段外的所有段都將標有“ [重組后的PDU的TCP段]”。

如果只對TCP序列號分析（6.1.4 TCP 分析）感興趣，請禁用此首選項以減少內存和處理開銷。但是請記住，高層協議可能會被錯誤地剖析。例如，HTTP消息可以顯示為“ Continuation”，而TLS記錄可以顯示為“ Ignored Unknown Record”。如果您在TCP連接已經啟動時開始捕獲，或者TCP段丟失或無序發送時，也可以觀察到這種結果。

要重新組裝無序的TCP段，除了先前的首選項外，還必須啟用TCP協議首選項“重新組裝無序段”（默認情況下當前禁用）。如果按順序接收了所有數據包，則此首選項將沒有任何效果。否則（如果在順序處理數據包捕獲時遇到丟失的段），則假定新段和丟失的段屬于同一PDU。注意事項：

• 假定丟失的數據包亂序接收或稍后重傳。應用程序通常會重新傳輸段，直到這些段被確認為止，但是如果數據包捕獲丟棄了數據包，則Wireshark將無法重建TCP流。在這種情況下，您可以嘗試禁用此首選項，并希望進行部分剖析，而不是僅對每個TCP段看到“ [重組后的PDU的TCP段]”。
• 在監視器模式（IEEE 802.11）中進行捕獲時，由于信號接收問題，數據包更有可能丟失。在這種情況下，建議禁用該選項。
• 如果新的和丟失的段實際上是不同PDU的一部分，則當前將延遲處理，直到不再丟失任何段為止，即使丟失段的開頭完成了PDU。例如，假定形成兩個PDU ABC和的六個段DEF。收到后ABECDF，應用程序可以在收到后開始處理第一個PDU ABEC。但是，Wireshark要求也D接收丟失的段。將來將解決此問題。
• 在GUI中以及兩次通過（tshark -2）期間，前一種情況將在最后一個段（F）的數據包中顯示兩個PDU，而不是在最后一個缺少PDU的段的第一個數據包中顯示它。將來將解決此問題。
• 啟用后，smb.time如果請求遵循其他無序段，則SMB“Time from request” (smb.time) 之類的字段可能會較小（這反映了應用程序的行為）。但是，如果發生了先前的情況，則請求的時間取決于接收所有丟失段的幀。

無論這兩個與重組相關的首選項如何設置，您都可以始終使用“遵循TCP流”選項（6.1.1 Following Protocol Streams）來按預期順序顯示段。

6.1.7 名稱解析

名稱解析試圖將某些數字地址值轉換為人類可讀的格式。取決于要執行的分辨率，有兩種可能的方式來進行這些轉換：調用系統/網絡服務（如gethostname（）函數）和/或從Wireshark特定的配置文件中解析。有關Wireshark用于名稱解析等的配置文件的詳細信息，請參見附錄B Wireshark文件和文件夾。

可以分別為以下各節中列出的協議層啟用名稱解析功能。

6.1.7.1 以太網名稱解析（MAC層）

嘗試將以太網MAC地址（例如00：09：5b：01：02：03）解析為易于理解的名稱。

ARP名稱解析（系統服務）：Wireshark將要求操作系統將以太網地址轉換為相應的IP地址（例如00：09：5b：01：02：03→192.168.0.1）。

以太網代碼（ethers文件）：如果ARP名稱解析失敗，Wireshark嘗試將以太網地址轉換為已知的設備名稱，該名稱已由用戶使用* ethers*文件分配（例如00：09：5b：01：02： 03→家庭路由器）。

以太網制造商代碼（manuf文件）：如果ARP或以太均未返回結果，Wireshark嘗試將以太網地址的前3個字節轉換為由IEEE分配的縮寫制造商名稱（例如00：09：5b： 01:02:03→Netgear_01：02：03）。

6.1.7.2 IP名稱解析（網絡層）

嘗試將IP地址（例如216.239.37.99）解析為易于理解的名稱。

DNS名稱解析（系統/庫服務）：Wireshark將使用名稱解析器將IP地址轉換為與其關聯的主機名（例如216.239.37.99→www.1.google.com）。

大多數應用程序同步使用DNS名稱解析。例如，您的Web瀏覽器必須先解析URL的主機名部分，然后才能連接到服務器。捕獲文件分析是不同的。給定的文件可能具有數百，數千或數百萬個IP地址，因此出于可用性和性能的原因，Wireshark使用異步解析。兩種機制都將IP地址轉換為人類可讀的（域名）名稱，并且通常使用不同的來源，例如系統主機文件（/ etc / hosts）和任何已配置的DNS服務器。

由于Wireshark不會等待DNS響應，因此，第一次查看給定數據包時，給定地址的主機名可能會丟失，但隨后查看時會出現。

您可以在“ 8.1.4 首選項的“名稱解析”部分中調整名稱解析行為。您可以通過將主機文件添加到B.3。配置文件來控制分辨率本身。您也可以編輯系統主機文件，但是通常不建議這樣做。

6.1.7.3 TCP / UDP端口名稱解析（傳輸層）

嘗試將TCP / UDP端口（例如80）解析為易于理解的名稱。

TCP / UDP端口轉換（系統服務）：Wireshark將要求操作系統將TCP或UDP端口轉換為其眾所周知的名稱（例如80→http）。

6.1.7.4 VLAN ID解析

要獲得VLAN標簽ID的描述性名稱，可以使用vlans文件。

6.1.7.5 SS7點碼解析

要獲得SS7點代碼的節點名稱，可以使用ss7pcs文件。

6.1.8 校驗和

幾種網絡協議使用校驗和來確保數據完整性。如此處所述，應用校驗和也稱為redundancy checking。

校驗和是做什么用的？

校驗和用于確保用于數據傳輸或存儲的數據部分的完整性。校驗和基本上是這種數據部分的計算摘要。

網絡數據傳輸通常會產生錯誤，例如切換，丟失或重復的位。結果，接收到的數據可能與發送的數據不同，這顯然是一件壞事。

由于這些傳輸錯誤，網絡協議非常經常使用校驗和來檢測此類錯誤。發送器將計算數據的校驗和，并將數據與校驗和一起發送。接收器將使用與發送器相同的算法來計算接收到的數據的校驗和。如果接收到的和計算出的校驗和不匹配，則發生傳輸錯誤。

一些校驗和算法能夠通過計算預期錯誤必須在哪里并進行修復來恢復（簡單）錯誤。

如果存在無法恢復的錯誤，則接收方會丟棄該數據包。根據網絡協議，可以簡單地忽略此數據丟失，或者發送方需要以某種方式檢測到此丟失并重新傳輸所需的數據包。

使用校驗和可以大大減少未檢測到的傳輸錯誤的數量。但是，通常的校驗和算法不能保證100％的錯誤檢測，因此可能仍然沒有檢測到非常少的傳輸錯誤。

有幾種不同的校驗和算法；經常使用的校驗和算法的一個示例是CRC32。為特定網絡協議實際選擇的校驗和算法將取決于網絡介質的預期錯誤率，錯誤檢測的重要性，執行計算的處理器負載，所需的性能以及許多其他因素。

6.1.8.1 Wireshark校驗和驗證

Wireshark將驗證許多協議的校驗和，例如IP，TCP，UDP等。

它將執行與 “normal receiver” 相同的計算，并在數據包詳細信息中顯示校驗和字段并帶有注釋，例如[correct]或[invalid, must be 0x12345678]。

可以在Wireshark協議首選項中針對各種協議關閉校驗和驗證，例如（以非常輕微的方式）提高性能。

如果啟用了校驗和驗證，并且檢測到無效的校驗和，則將不會處理數據包重組之類的功能。可以避免這種情況，因為不正確的連接數據可能會 “confuse” 內部數據庫。

6.1.8.2 校驗和卸載

校驗和計算可以由網絡驅動程序，協議驅動程序甚至在硬件中完成。

例如：以太網發送硬件計算以太網CRC32校驗和，接收硬件驗證此校驗和。如果接收到的校驗和錯誤，Wireshark甚至不會看到該數據包，因為以太網硬件會在內部丟棄該數據包。

協議實現會 “traditionally” 計算出更高級別的校驗和，然后將完整的數據包移交給硬件。

最近的網絡硬件可以執行高級功能，例如IP校驗和計算，也稱為校驗和卸載。網絡驅動程序不會自行計算校驗和，而只會將空（zero or garbage filled）校驗和字段移交給硬件。

校驗和卸載可能會造成混亂，并且屏幕上顯示很多[invalid]消息可能會很煩人。如上所述，無效的校驗和可能導致未重組的數據包，從而使數據包數據的分析更加困難。

您可以做兩件事來避免此校驗和卸載問題：

• 如果此選項可用，請關閉網絡驅動程序中的校驗和卸載。
• 在Wireshark首選項中關閉特定協議的校驗和驗證。由于現代硬件和操作系統中普遍存在卸載問題，因此最新版本的Wireshark默認情況下會禁用校驗和驗證。