wireshark使用教程中文

流的內(nèi)容出現(xiàn)的順序同他們?cè)诰W(wǎng)絡(luò)中出現(xiàn)的順序一致。從 A 到 B 的通信標(biāo)記為紅色，從 B 到 A 的通信標(biāo)記為藍(lán)色。當(dāng)然，

如果你喜歡的話(huà)你可以從"Edit/Preferences"菜單項(xiàng)的"Colores"修改顏色。

非打印字符將會(huì)被顯示為圓點(diǎn)。XXX - What about line wrapping (maximum line length) and CRNL conversions?

在捕捉過(guò)程中，TCP 流不能實(shí)時(shí)更新。想得到最近的內(nèi)容需要重新打開(kāi)對(duì)話(huà)框。

你可以在此對(duì)話(huà)框執(zhí)行如下操作：

Save As以當(dāng)前選擇格式保存流數(shù)據(jù)。

Print 以當(dāng)前選擇格式打印流數(shù)據(jù)。

Direction 選擇流的顯示方向("Entire conversation", "data from A to B only" or "data from B to A only").

Filter out thistr

應(yīng)用一個(gè)顯示過(guò)濾，在顯示中排除當(dāng)前選擇的 TCP 流。

Close關(guān)閉當(dāng)前對(duì)話(huà)框。移除對(duì)當(dāng)前顯示過(guò)濾的影響。

你可以用以下格式瀏覽流數(shù)據(jù)。

AsCII。在此視圖下你可以以 ASCII 凡是查看數(shù)據(jù)。當(dāng)然最適合基于 ASCII 的協(xié)議用，例如 HTTP.

EBCDIC。For the big-iron freaks out there.（不知道這句是什么意思，EBCDIC是 IBM 公司的字符二進(jìn)制編碼標(biāo)準(zhǔn)。）

HEX Dump.允許你查看所有數(shù)據(jù)，可能會(huì)占用大量屏幕空間。適合顯示二進(jìn)制協(xié)議。

C Arrays.允許你將流數(shù)據(jù)導(dǎo)入你自己的 C 語(yǔ)言程序。

RAW。 允許你載入原始數(shù)據(jù)到其他應(yīng)用程序做進(jìn)一步分析。顯示類(lèi)似與 ASCII 設(shè)置。但“save As”將會(huì)保存為二進(jìn)制文件。

7.3.時(shí)間戳

時(shí)間戳，時(shí)間戳的精度，等等是在讓人感到困惑。本節(jié)將向你介紹介紹 Wireshark 處理時(shí)間戳?xí)r都發(fā)生了什么。

在包被捕捉時(shí)，每個(gè)包在進(jìn)入時(shí)都被加上時(shí)間戳，這個(gè)時(shí)間戳將會(huì)保存在捕捉文件中，所以他們也可以在以后分析時(shí)使用。

那么說(shuō)，時(shí)間戳是從哪里來(lái)的呢？是捕捉的時(shí)候產(chǎn)生的。

Wireshark 從libpcap(WinPcap) libraray(庫(kù)) 中獲得時(shí)間戳。 而

libpcap(winpcap)又是從操作系統(tǒng)內(nèi)核獲得的時(shí)間。如果捕捉數(shù)據(jù)是從捕捉文件載入的，很顯然Wireshark 從文件中獲得時(shí)

間戳數(shù)據(jù)。

7.3.1. Wireshark內(nèi)置

Wireshak 內(nèi)置的格式使用的時(shí)間戳格式由日期 (從1.1.1970 開(kāi)始)和時(shí)間（從凌晨起，納秒(10億分之一秒)為單位）組成。你

可以調(diào)整 Wireshark 在包列表的時(shí)間戳顯示方式。見(jiàn)第3.7節(jié)“"View"菜單”的"Time Display Format"項(xiàng)。

當(dāng)讀取或?qū)懭氩蹲轿募䲡r(shí)，Wireshark 按需要在內(nèi)置格式和其他捕捉文件格式間進(jìn)行時(shí)間戳轉(zhuǎn)換。

捕捉時(shí)，Wireshark 使用 libpcap(WinPcap)捕捉庫(kù)（支持納秒精度）。除非你在專(zhuān)用的捕捉硬件上進(jìn)行捕捉，一般這樣的精度

已經(jīng)足夠了。

7.3.2.捕捉文件格式

Wireshark 支持的捕捉文件格式都帶有時(shí)間戳。不同的捕捉文件格式的時(shí)間戳精度有很大不同，從秒

"0" 到納秒

"0.123456789"都有。大多數(shù)格式捕捉文件存儲(chǔ)的時(shí)間戳都是固定精度的，些捕捉文件格式甚至存儲(chǔ)了時(shí)間戳精度本身（可

能是出于方便）。

大多數(shù)被 Wireshark(和或多其他工具)使用的 libpcap 捕捉文件格式都僅支持固定的百萬(wàn)分之一固定精度"0.123456"

注意

寫(xiě)入數(shù)據(jù)到一個(gè)實(shí)際支持精度比你寫(xiě)入數(shù)據(jù)精度低的格式文件中，可能會(huì)導(dǎo)致數(shù)據(jù)丟失。

例如：如果你載入一個(gè)納秒精度的捕捉文件，然后將其存儲(chǔ)為 libpcap 文件(百萬(wàn)分之一秒

精度)。Wireshark 很明顯會(huì)將時(shí)間精度調(diào)整為百萬(wàn)分之一秒。

7.3.3.準(zhǔn)確性

經(jīng)常有人問(wèn)："Wireshark 的時(shí)間戳的準(zhǔn)確性如何？ "。實(shí)際上， Wireshark 自身不會(huì)創(chuàng)建時(shí)間戳，而是通過(guò)其他的地方得到

時(shí)間并顯示他們。所以，準(zhǔn)確性取決于你實(shí)用的捕捉系統(tǒng)(操作系統(tǒng)，性能。。。)。因此以上問(wèn)題很難通過(guò)通常的途徑回答。

注意

通常 USB 連接的網(wǎng)絡(luò)適配器提供的精度非常差。入口的實(shí)際上“占用很長(zhǎng)的時(shí)間和走很曲

折的路”才能穿過(guò) USB 數(shù)據(jù)線(xiàn)到系統(tǒng)內(nèi)核。而數(shù)據(jù)包只有被系統(tǒng)內(nèi)核處理過(guò)以后才會(huì)打上

時(shí)間戳，這種時(shí)間戳機(jī)制將會(huì)導(dǎo)致準(zhǔn)確性大大降低。

結(jié)論：如果你需要精確的時(shí)間戳，請(qǐng)不要使用 USB 連接的網(wǎng)卡！(筆者的注腳：有沒(méi)有網(wǎng)

卡在 USB 硬件上提前加上時(shí)間戳的？)[17]

side bar ceshi

[17]譯者注: 前文提到，時(shí)間戳是 Wireshark 用庫(kù)獲取的時(shí)間加在包上的，不知為何有此一問(wèn)。難道以后要識(shí)別硬件是否有時(shí)

間戳功能。

7.4.時(shí)區(qū)

當(dāng)你在各地旅行時(shí)，會(huì)碰到時(shí)區(qū)的困擾。如果你從其他時(shí)區(qū)得到捕捉文件，時(shí)區(qū)問(wèn)題會(huì)給你帶來(lái)更大的困擾:-)

首先，下面有兩個(gè)原因說(shuō)明你為什么完全不需要考慮時(shí)區(qū)問(wèn)題：

你僅對(duì)兩個(gè)包的時(shí)間戳的差別有興趣，你并不需要了解捕捉包的實(shí)際的日期和時(shí)間(通常是這樣)。

很可能你不會(huì)得到不同與你所在時(shí)區(qū)的包文件，所以你基本上碰不到時(shí)區(qū)問(wèn)題。例如：你的團(tuán)隊(duì)的所有都和你工作在一個(gè)

時(shí)區(qū)。

表7.1.

什么是時(shí)區(qū)?

人們希望時(shí)間和日升日落對(duì)應(yīng)。早成應(yīng)該是 6點(diǎn)鐘，天黑應(yīng)該在 20：00.這些時(shí)間又隨著四季

變化。如果地球上每個(gè)人使用同樣的全局時(shí)間，將只有一小部分人的日落和時(shí)間對(duì)應(yīng)，這將

會(huì)導(dǎo)致混亂。

因此，人們將地球劃分為不同的區(qū)域，每個(gè)區(qū)域都有一個(gè)本地時(shí)間對(duì)應(yīng)本地的日升日落。

時(shí)區(qū)基于 UTC(Coordinated Universal Time)或者 Zulu時(shí)間(軍事和航空)。舊有的 GTM(格林尼

治時(shí)間)已不再使用，因?yàn)樗猩僭S誤差 (與 UTC 相比達(dá)到0.9秒)。UTC 起始時(shí)區(qū)等于0(位于

格林威治，英格蘭)，所有的時(shí)區(qū)和它的偏在在-12~+14小時(shí)之間！

例如：如果你住在柏林，你的時(shí)區(qū)將比UTC 早1小時(shí)，所以你的時(shí)區(qū)應(yīng)該是 "+1"(與 UTC 時(shí)

間比較的差別，以小時(shí)為單位)。柏林的3點(diǎn)和 UTC 的兩點(diǎn)鐘表示同一個(gè)時(shí)刻。

有些地區(qū)要加以注意，因?yàn)槟抢锏臅r(shí)區(qū)不是用整小時(shí)的。(比如：新德里的時(shí)區(qū)是UTC+05:30)

見(jiàn)息信關(guān)相多更

http://en.wikipedia.org/wiki/time_zone

和

http://en.wikipedia.org/wiki/Coordinated_Universal_Time。

表7.2.

什么是時(shí) DST?

Daylight Saving Time(DST),又稱(chēng)為夏令時(shí)，目的是在夏天的幾個(gè)月里 “拯救 ”白天的時(shí)間 (夏季

白晝較長(zhǎng)，如果按照傳統(tǒng)的作息時(shí)間，比較可惜，不過(guò)我不認(rèn)為)。為了達(dá)到這個(gè)目的，很多

國(guó)家（但不是所有的）增加一個(gè) DST 小時(shí)到 UTC 中。所以你還得加個(gè)小時(shí)(極少數(shù)地方甚至

是2小時(shí))的時(shí)差來(lái)計(jì)算你的時(shí)區(qū)。

不幸的是，DST 并未在全世界范圍內(nèi)被啟用。你可能同樣注意到，北半球和南半球的夏令時(shí)

是剛好相反的（比如：歐洲是夏季時(shí)，澳大利亞則是冬季）。

注意：不管 DST 怎樣，UTC 在全年都是一致的。

更多相關(guān)信息見(jiàn) http://en.wikipedia.org/wiki/Daylight_saving.

7.4.1.正確設(shè)置你的計(jì)算機(jī)的時(shí)區(qū)

7.4.2. Wireshark和時(shí)區(qū)的關(guān)系

7.5.合并包

7.5.1.什么是合并包

網(wǎng)絡(luò)協(xié)議經(jīng)常需要傳輸較大的數(shù)據(jù)塊，在傳輸時(shí)，底層協(xié)議可能不支持這樣大的數(shù)據(jù)塊(比如網(wǎng)絡(luò)包大小的限制 )，或者是

像像 TCP 一樣的流數(shù)據(jù),TCP 流完全不知道數(shù)據(jù)分塊情況。(原文為:or is stream-based like TCP,which doesn't know data chunks

at all.)

在這種情況下，網(wǎng)絡(luò)協(xié)議必須確定數(shù)據(jù)塊分段的邊界，并 (如果有必要)將數(shù)據(jù)塊分割為多個(gè)包。很明顯在接受端也需要有

找到數(shù)據(jù)塊分段邊界的機(jī)制。

提示

在 Wireshark 里面，這個(gè)機(jī)制/方法被稱(chēng)為合并/reasembling，在特定協(xié)議的描述可能

不盡相同(例如：desegmentation, defragmentation, ...)

7.5.2.如何用 Wireshark 合并包

對(duì)那些可以被 Wireshark 識(shí)別的協(xié)議，Wireshark 通常處理過(guò)程為：查找、解碼、顯示數(shù)據(jù)塊。Wireshark 會(huì)嘗試查找數(shù)據(jù)塊

對(duì)應(yīng)的包，在"Packet Bytes"面板的附加頁(yè)面顯示合并以后的數(shù)據(jù)。(關(guān)于“Packet B ytes”面板的詳細(xì)介紹，見(jiàn)第4.7節(jié)“"View"

菜單”)

圖7.2.帶有合并包附加選項(xiàng)卡"Packet Bytes 面板 "

注意

合并可能發(fā)生在多個(gè)協(xié)議層，所以在"Packet Bytes"面板可能會(huì)見(jiàn)到多個(gè)附加頁(yè)選項(xiàng)

卡

注意

你會(huì)在數(shù)據(jù)塊的最后一個(gè)包看到合并后的數(shù)據(jù)。

以 HTTP Get 應(yīng)答為例：請(qǐng)求數(shù)據(jù)(例如一個(gè) HTML 頁(yè)面)返回時(shí)。Wireshark 會(huì)顯示一個(gè)16進(jìn)制轉(zhuǎn)儲(chǔ)數(shù)據(jù)在"Packet Bytes"面

板的一個(gè)名為"Uncompressed entity body"新選項(xiàng)卡。

默認(rèn)情況下，首選項(xiàng)中合并功能被設(shè)置為允許。在2005年9月之前默認(rèn)值是不允許。如果你的首選項(xiàng)是在200年9月之前設(shè)置

的，你得確認(rèn)一下，合并包選項(xiàng)的設(shè)置。合并包對(duì)分析網(wǎng)絡(luò)包作用非常大。

允許和禁止合并包設(shè)置對(duì)協(xié)議來(lái)說(shuō)還有兩項(xiàng)要求。

下層的協(xié)議(如：TCP)必須支持合并。通常協(xié)議支持合并與否都是通過(guò)協(xié)議的參數(shù)設(shè)置的。

高層協(xié)議協(xié)議(如:HTTP)必須使用合并機(jī)制來(lái)合并分片的數(shù)據(jù)。這些也同樣可以通過(guò)協(xié)議參數(shù)來(lái)允許或禁止。

在設(shè)置高層協(xié)議的時(shí)候 tooltip 會(huì)提醒你同樣需要考慮低層的協(xié)議設(shè)置。

7.6.名稱(chēng)解析

名字解析嘗試將數(shù)字地址解析成適合人們閱讀格式。有兩種方法可以完成這項(xiàng)工作：通過(guò)系統(tǒng)/網(wǎng)絡(luò)服務(wù)(例如獲取主機(jī)名)

和/或Wireshark 指定的賦值文件。關(guān)于通過(guò)賦值文件進(jìn)行解析的詳情，可以參見(jiàn)???

名字解析可以分協(xié)議層進(jìn)行允許，禁止設(shè)置。

7.6.1.名字解析的流弊

名字解析在使用 Wireshark 時(shí)有重要價(jià)值，甚至可以節(jié)約大量時(shí)間。不幸的是，名字解析也有它自己的缺點(diǎn)。

名字解析經(jīng)常會(huì)不可用 。服務(wù)器可能不知道需要被解析的名字，或者服務(wù)器不可用。又或者需要解析的名字在賦值配置文

件中找不到。

名字解析并沒(méi)有存儲(chǔ)在捕捉文件或其他什么地方 。因此你以后打開(kāi)捕捉文件或者在其他設(shè)備上打開(kāi)文件有可能發(fā)現(xiàn)名字解

析不可用。每次打開(kāi)捕捉文件可能會(huì)發(fā)現(xiàn)部分地址略微發(fā)生變化，也許僅僅是因?yàn)闊o(wú)法連接到名字解析服務(wù)器(之前還是可

以連接的)

DNS 可能會(huì)增加額外的包到 Wireshark 中。你會(huì)在包文件中看到由 Wireshark 請(qǐng)求 DNS 服務(wù)生成的包進(jìn)出你的機(jī)器。

解析名稱(chēng)被 Wireshark 緩存。這對(duì)設(shè)備性能有一定需求。但是，如果名字解析信息在 wireshark 運(yùn)行時(shí)發(fā)生變化，wireshark

不會(huì)注意到這個(gè)變化，因?yàn)樗菑木彺孢M(jìn)行解析的。如果這些信息在Wireshark 運(yùn)行時(shí)變化了，例如獲取一個(gè)新 DHCP 租

約，Wireshark 不會(huì)注意到。(這些是針對(duì) DNS 還是所有信息？有多少機(jī)器使用動(dòng)態(tài) dns 注冊(cè)？)

提示

名字解析在包列表填入時(shí)已經(jīng)完成。如果一個(gè)包填入包列表以后被解析，包列表的

內(nèi)容不會(huì)立即更改，相反解析結(jié)果會(huì)被緩存，你可以使用"View/Reload"重建包列表，

來(lái)正確顯示名字解析結(jié)果。但在捕捉過(guò)程中這樣做沒(méi)有效果。

7.6.2.以太網(wǎng)名字解析(mac 層)

嘗試將 MAC 地址(e.g. 00:09:5b:01:02:03)解析為適合閱讀的地址（"Human readable"）

ARP名字解析( 系統(tǒng)服務(wù))Wireshark會(huì)向操作系統(tǒng)發(fā)出請(qǐng)求，將以太網(wǎng)地址轉(zhuǎn)換為對(duì)應(yīng)的

00:09:5b:01:02:03->192.168.0.1)

IP地址(e.g.

Ethernet codes(ethers file)如果 ARP 解析錯(cuò)誤，Wireshark 會(huì)嘗試將以太網(wǎng)地址解析為已知設(shè)備名。這種解析需要用戶(hù)指定

一個(gè) ethers 文件為 mac 地址分配名稱(chēng)。(e.g. 00:09:5b:01:02:03 -> homerouter).

Ethernet manufacturer codes (manuf file)如果 ARP 解析和 ethers 文件都無(wú)法成功解析，Wireshark 會(huì)嘗試轉(zhuǎn)換 mac 地址的

前三個(gè)字節(jié)為廠(chǎng)商名的縮寫(xiě)。mac 地址的前三個(gè)字節(jié)是 IEEE 為各廠(chǎng)商分配的獨(dú)立地址(通過(guò)前三個(gè)字節(jié)可以得出每個(gè)網(wǎng)絡(luò)

設(shè)備的供應(yīng)商，當(dāng)然這些也是可以被篡改的。，)(e.g. 00:09:5b:01:02:03 -> Netgear_01:02:03).

7.6.3. IP 地址解析( 網(wǎng)絡(luò)層)

將 IP 地址(e.g. 216.239.37.99)轉(zhuǎn)換為適合閱讀的地址/"Human readable"

DNS/ADNS name resolution(system/library service)Wireshark 會(huì)向操作系統(tǒng)（或 ADSN library地址-名稱(chēng)解析詞典?）請(qǐng)求，

將 IP 地址轉(zhuǎn)換為相關(guān)聯(lián)的主機(jī)名(e.g. 216.239.37.99 -> www.1.google.com).此時(shí) DNS 服務(wù)正在同步請(qǐng)求 DNS 服務(wù)器，所以

Wireshark 會(huì)停止相應(yīng)直到 DNS 請(qǐng)求的響應(yīng)返回。如果可能的話(huà)，你可以考慮使用 ADNS library(這樣可以避免等待網(wǎng)絡(luò)相

應(yīng)。)

警告

如果名稱(chēng)解析服務(wù)器不可用，允許網(wǎng)絡(luò)名稱(chēng)解析使 Wireshark 明顯變慢，因?yàn)?/span>

wireshark 會(huì)等待名字解析結(jié)果直到超時(shí)。在這種情況你應(yīng)該使用 ADNS。

DNS vs. ADNS 這里是一個(gè)簡(jiǎn)短的對(duì)比：兩個(gè)都是用來(lái)轉(zhuǎn)換ip 地址為其他易讀的地址 "Human readable"(域名)。通常 DNS

用 gethostname()將地址轉(zhuǎn)換為名稱(chēng)。通常首先是查詢(xún)hosts 文件 (e.g. /etc/hosts,/windows/system32/drivers/etc/hosts)看能否找

到匹配實(shí)體。如果找不到，會(huì)向指定的 DNS 服務(wù)器查詢(xún)。

DNS 和 ADNS 真正的區(qū)別在于等待 DNS 服務(wù)器名字解析。 gethost() 會(huì)一直等待知道名字被解析或者返回錯(cuò)誤。如果DNS

服務(wù)器不可用，可能會(huì)占用很長(zhǎng)時(shí)間(好幾秒)。ADNS 服務(wù)會(huì)略微有點(diǎn)不同。它也同樣向 DNS 服務(wù)器發(fā)出請(qǐng)求，但不會(huì)等

待服務(wù)器應(yīng)答。它會(huì)立即相應(yīng)Wireshark。此時(shí)的地址（和后續(xù)地址）在ADNS 得到結(jié)果前不會(huì)顯示解析名稱(chēng)。如前文書(shū)

中說(shuō)道，解析結(jié)果被保存在緩存中，你需要使用"View/Reload"菜單更新這些字段來(lái)顯示解析名稱(chēng)。

hosts name resolution(hostsfile)如果 dns 解析不成功，Wireshark 會(huì)嘗試使用用戶(hù)提供的主機(jī)文件將 IP 地址轉(zhuǎn)換為對(duì)應(yīng)的

主機(jī)名。(e.g. 216.239.37.99 -> www.google.com)

7.6.4. IPX 名稱(chēng)解析(網(wǎng)絡(luò)層)

ipxnet name resolution (ipxnets file) (筆者未作解釋)

7.6.5. TCP/UDP 端口名解析( 傳輸層)

翻譯 TCP/UDP 端口(e.g.80)為更加易讀的玩意"human readable"[15]

TCP/UDPport conversion (system service) Wireshark 會(huì)向操作系統(tǒng)發(fā)出請(qǐng)求，轉(zhuǎn)換 TCP/UDP 端口為已知名稱(chēng)(e.g. 80->http)。

XXX - mention the role of the /etc/services file (but don't forget the files and folders section)!

[15]應(yīng)該是指將端口翻譯為服務(wù)名

7.7.校檢和

很多協(xié)議使用校檢和來(lái)驗(yàn)證數(shù)據(jù)的完整性/正確性。

提示

應(yīng)用校檢和在這里也被成為 redundancy check(冗余校檢？)

校檢和是做什么的？

校驗(yàn)和是用來(lái)驗(yàn)證傳輸數(shù)據(jù)或存儲(chǔ)數(shù)據(jù)的數(shù)據(jù)部分的正確性。一個(gè)檢驗(yàn)和是數(shù)據(jù)部分進(jìn)行摘要計(jì)算的出的數(shù)字。

網(wǎng)絡(luò)數(shù)據(jù)在傳輸過(guò)程中經(jīng)常會(huì)產(chǎn)生錯(cuò)誤，例如數(shù)據(jù)錯(cuò)誤，字節(jié)重復(fù)等。數(shù)據(jù)接收方可能。

正因?yàn)閭鬏斶^(guò)程中會(huì)伴隨錯(cuò)誤，網(wǎng)絡(luò)協(xié)議會(huì)經(jīng)常使用校驗(yàn)和檢測(cè)這些錯(cuò)誤。發(fā)送方會(huì)對(duì)數(shù)據(jù)進(jìn)行檢驗(yàn)和計(jì)算，并將數(shù)據(jù)和

檢驗(yàn)和一起發(fā)送。接收方使用同樣的方法計(jì)算數(shù)據(jù)部分的校驗(yàn)和，如果收到的校驗(yàn)和計(jì)算出來(lái)的校驗(yàn)和不匹配，就表示數(shù)

據(jù)有錯(cuò)誤。

有些校驗(yàn)和方法可以通過(guò)計(jì)算得出發(fā)生需要被修復(fù)錯(cuò)誤的數(shù)據(jù)位置，并修復(fù)（簡(jiǎn)單的）錯(cuò)誤。

如果那些錯(cuò)誤無(wú)法修復(fù)，接收方會(huì)丟棄錯(cuò)誤的數(shù)據(jù)包。根據(jù)協(xié)議的不同，數(shù)據(jù)丟失會(huì)僅僅被丟棄，也有可能發(fā)送端會(huì)根據(jù)

數(shù)據(jù)丟失情況重傳需要的數(shù)據(jù)包。

使用校驗(yàn)和可以大量減少傳輸錯(cuò)誤數(shù)量。但任何檢驗(yàn)和算法都無(wú)法確保100%檢測(cè)到所有錯(cuò)誤，依然有少量的錯(cuò)誤會(huì)無(wú)法被

檢測(cè)到。

校驗(yàn)和的算法有很多，例如最經(jīng)常被使用的檢驗(yàn)和算法CRC32（循環(huán)冗余校驗(yàn)）。特的的網(wǎng)絡(luò)協(xié)議選擇的校驗(yàn)算法取決于

希望網(wǎng)絡(luò)媒介達(dá)到的出錯(cuò)率上限、錯(cuò)誤檢測(cè)的重要性，處理載入計(jì)算的性能，其他方面需要的性能。

關(guān)于檢驗(yàn)和的更多信息可以參考：http://en.wikipedia.org/wiki/Checksum

7.7.1. Wireshark校檢和驗(yàn)證

Wireshark 會(huì)對(duì)很多協(xié)議進(jìn)行檢驗(yàn)和驗(yàn)證，如：TCP、IP。。。

它會(huì)和"normal receiver"做一樣的計(jì)算.然后在包詳情面板顯示檢驗(yàn)和字段的內(nèi)容，e.g.:[correct], [invalid, must be 0x12345678]

以及其他類(lèi)似的內(nèi)容。

如果校驗(yàn)和驗(yàn)證選項(xiàng)被打開(kāi)或正在進(jìn)行校驗(yàn)和檢測(cè)，合并包特性不會(huì)被執(zhí)行。這是為了避免錯(cuò)誤的的連接數(shù)據(jù)擾亂內(nèi)部數(shù)

據(jù)。

7.7.2. Checksum offloading

檢驗(yàn)和計(jì)算可能由網(wǎng)絡(luò)網(wǎng)絡(luò)驅(qū)動(dòng)，協(xié)議驅(qū)動(dòng)，甚至是硬件完成。

例如：以太網(wǎng)傳輸硬件計(jì)算以太網(wǎng)循環(huán)容易校驗(yàn)，接受硬件驗(yàn)證這個(gè)校驗(yàn)。如果接受驗(yàn)證發(fā)現(xiàn)錯(cuò)誤，Wireshark 將不會(huì)接收

到這個(gè)包，以太網(wǎng)硬件會(huì)直接丟棄這個(gè)包。

高層校驗(yàn)通常是由協(xié)議執(zhí)行，并將完成后的包轉(zhuǎn)交給硬件。

比較新的網(wǎng)絡(luò)硬件可以執(zhí)行一些高級(jí)功能，如 IP 檢驗(yàn)和計(jì)算，這被成為 checksum offloading。網(wǎng)絡(luò)驅(qū)動(dòng)不會(huì)計(jì)算校驗(yàn)和，

只是簡(jiǎn)單將校驗(yàn)和字段留空或填入無(wú)效信息，交給硬件計(jì)算。

注意

checksum offloading 經(jīng)常會(huì)導(dǎo)致混亂，因?yàn)榫W(wǎng)絡(luò)包在檢驗(yàn)和計(jì)算之前轉(zhuǎn)交給

Wireshark。Wireshark 得到包的檢驗(yàn)和字段是空的，必然會(huì)顯示檢驗(yàn)和錯(cuò)誤，盡管這

個(gè)包在從網(wǎng)絡(luò)硬件發(fā)出的時(shí)候是帶有校驗(yàn)和的。

Checksum offloading會(huì)引起混淆，讓你屏幕上看到大量的 [invalid]信息，引起你的反感。前面提到過(guò)，錯(cuò)誤的檢驗(yàn)和會(huì)導(dǎo)致

包無(wú)法合并，更難進(jìn)行包數(shù)據(jù)分析。

你可以采取兩種方法避免 Checksum offloading問(wèn)題

在驅(qū)動(dòng)程序上關(guān)閉 checksum offloading 選項(xiàng)，如果可用的話(huà)。[16]

通過(guò)首選項(xiàng)關(guān)閉 Wireshark 上特定協(xié)議的校驗(yàn)和驗(yàn)證。

[16]在 Windows 平臺(tái)如果驅(qū)動(dòng)支持，應(yīng)該是計(jì)算機(jī)管理->設(shè)備管理器->網(wǎng)絡(luò)適配器->對(duì)應(yīng)網(wǎng)卡的屬性-高級(jí)選項(xiàng)