計算機網絡 網絡層

ARP協議

ARP協議概述

ARP（Address Resolution Protocol）即地址解析協議 **， 用於實現從 ** IP 地址到 MAC 地址 的映射，即詢問目標IP對應的MAC地址 。在以太網環境中，數據的傳輸所依懶的是MAC地址而非IP地址，而將已知IP地址轉換為MAC地址的工作是由ARP協議來完成的。

簡單來說，ARP協議 是將IP地址解析為以太網MAC地址(或稱物理地址)的協議。在局域網中，當主機或其他網絡設備有數據要發送給另—個主機或設備時，必須知道對方的IP地址和MAC地址。

ARP出現原因

• 在網絡通信中，主機和主機通信的數據包需要依據OSI模型從上到下進行數據封裝，當數據封裝完整后，再向外發出。所以在局域網的通信中，不僅需要源目IP地址的封裝，也需要源目MAC的封裝。

• 一般情況下，上層應用程序更多關心IP地址而不關心MAC地址，所以需要通過ARP協議來獲知目的主機的MAC地址，完成數據封裝。

ARP工作實例

ARP地址解析協議是如何把目的地址的IP地址轉化為MAC地址的?

1. 首先，主機A向主機B發送消息，但它不知道主機B的MAC地址，只知道主機B的IP地址。此時，主機A會在當前局域網下以廣播的形式 發送ARP請求數據報 ，表示主機A想知道主機B的MAC地址。

2. 局域網中的毎一台主機都會接受並處理這個ARP請求報文，然后進行驗證，查看接收方的IP地址是不是自己的地址，除了主機B外，在這個局域網內的其他主機都會丟棄數據報。驗證成功的主機 會返回—個ARP響應報文 ，這個響應報文包含接收方的IP地址和物理地址 。這個報文以單播的方式 直接發送給ARP請求報文的請求方。

小結 ： ARP協議通過"一問一答 "實現交互，但是"問"和"答"都有講究，"問 "是通過廣播 形式實現，"答 "是通過單播 形式。

ARP緩存表

• 為了實現IP地址與MAC地址的查詢與轉換，ARP協議引入了ARP緩存表的概念。

• 這個表包含IP地址到MAC地址的映射關系，表中記錄了<P地址，MAC地址>對，稱之為ARP表項。

• 當需要發送數據時,主機會根據數據報中的目標I地址信息,然后在ARP緩存表中查找對應的MAC地址，最后通過網卡將數據發送出去。

注意 ：arp緩存表中每—項都被設置了生存時間，一般是20分鍾，從被創建時開始計時，到時則清除。

在我們的windows/macos系統下，可以通過命令行"arp -a "查看具體信息 =>

ARP報文格式

ARP報文分為ARP請求和ARP應答報文兩種，它們的報文格式可以統一為如下圖

字段的說明 :

1. 硬件類型 ：占2字節，表示ARP報文可以在哪種類型的網絡 上傳輸，值為1 時表示為以太網地址。

2. 上層協議類型 ：占2字節，表示硬件地址要映射的協議地址類型 。其中，0x0800 表示IP協議 。

3. MAC地址長度 ：占1字節，標識MAC地址長度。

4. IP地址長度 ：占1字節，標識IP地址長度。

5. 操作類型 ：占2字節，指定本次ARP報文類型。1 表示ARP請求 報文，2 表示ARP應答 報。

6. 源MAC地址 ：占6字節，表示發送方 設備的硬件地址。

7. 源IP地址 ：占4字節，表示發送方 設備的IP地址。

8. 目的MAC地址 ：占6字節，表示接收方 設備的硬件地址，在請求報文 中該字段值全為0 ，即00-00-00-00-00-00 表示任意地址 ，因為現在不知道這個MAC地址。

9. 目的IP地址 ：占4字節，表示接收方 設備的IP地址。

ARP數據包解讀

為了讓大家更好的理解ARP協議以及廣播和單播的概念，我們來看一下用Wireshark抓取到的真實網絡中的ARP過程，通過數據包的方式來呈現，地址信息如下，部分MAC信息隱去。（建議初學者用GNS3配合Wireshark來抓取協議包進行分析，相比真實網絡更加干凈，方便分析）

主機1 <----------> 主機2
主機1： IP1：10.1.20.64 MAC1：00:08:ca:xx:xx:xx
主機2： IP2：10.1.20.109 MAC2：44:6d:57:xx:xx:xx

大家好，我是主機1 <IP1：10.1.20.64，MAC1：00:08:ca:xx:xx:xx>
廣播 詢問 主機2的MAC <IP2：10.1.20.109，你的MAC是多少?>
000000空位(留坑)，表示詢問者不知道，等待接收方回應(填坑)

我是主機2 <IP2：10.1.20.109，MAC2：44:6d:57:xx:xx:xx>
單播 回復 你好主機1 <IP1：10.1.20.64，MAC1：00:08:ca:xx:xx:xx>

ARP數據包字段解讀

字段名稱	說明
Hardware type	硬件類型，標識鏈路層協議
Protocol type	協議類型，標識網絡層協議
Hardware size	硬件地址大小，標識MAC地址長度，這里是6個字節（48bit）
Protocol size	協議地址大小，標識IP地址長度，這里是4個字節（32bit）
Opcode	操作代碼，標識ARP數據包類型，1表示請求，2表示回應
Sender MAC address	發送者MAC
Sender IP address	發送者IP
Target MAC address	目標MAC，此處全0表示在請求
Target IP address	目標IP

ARP欺騙

• ARP地址解析協 議即是根據IP地址獲取物理地址的TCP/IP協議。主機發送消息時會將包含目標IP地址的ARP請求發給廣播地址，廣播地址的MAC為ff:ff:ff:ff:ff:ff，廣播在進行廣播轉發數據包到網段內所有主機，並接收返回的消息，以此來確定目標的物理地址。主機收到的返回的消息后將IP地址和物理地址存入本機ARP緩存中，並保留一定時間，默認是20分鍾，保留一段時間是為了下次請求時直接査詢ARP緩存表節約資源。ARP是建立在網絡中各個主機互相信任的基礎上，局域網的主機可以自主發送arp請求 ，其他主機收到應答報文時不會檢測真實性就將其記入本機ARP緩存 。

• 針對這個特性有一種局域網常見的攻擊手法：ARP欺騙,或者叫ARP毒化，針對這種攻擊kali內的一款圖形化工具可以很方便的做到 —— Ettercap, Ettercap可以用來做arp欺騙，dns欺騙,或者中間人攻擊。這里先講下ARP欺騙，剛才講到主機在收到任何ARP應答報文不會檢測其真實性就會記入本機ARP緩存表。

• arp欺騙分為單向欺騙，雙向欺騙。

• 單向欺騙 ：A、B、C三個人，A與C正常通信，B想知道A給C發的內容，就偽造ARP響應包，更改A的ARP表，所以A發送給C的信息會先傳送到B，B可以丟棄數據包，這樣C就收不到A發的數據了，但是C還是可以正常給A發送數據的，這就是單向欺騙。

• 雙向欺騙 ：同樣是A、B、C三個人，B同時給A、C發送響應包B告訴A它的IP是C的IP，Mac地址還是B的，告訴C它的IP是 A的IP，Mac地址還是是B的，這樣A、C的通信就都會經過B，這就叫雙向欺騙。

• 單向欺騙：欺騙網關；雙向欺騙：欺騙網關和被攻擊的機器。←

• 這類攻擊可以任意截取局域網內的數據包，甚至篡改數據包 。針對此類攻擊，可采用MAC地址綁定和ARP防火牆防止。

IP協議

IP協議原理

IP協議（Internet Protocol，互聯網協議） ，是TCP/IP協議棧中最核心的協議之一，通過IP地址，保證了聯網設備的唯一性，實現了網絡通信的面向無連接和不可靠的傳輸功能。

如上圖所示，當多台接入互聯網的電腦訪問同一台服務器時，服務器如何區分不同電腦的請求，並准確的將資源返回？

只要給每個設備加上"身份證"，並且在通信的時候，將"身份證"嵌入到數據包里面，則整個往返過程可以准確無誤 。

以PC1訪問服務器為例，PC1的地址是12.1.8.66，Server的地址是8.8.4.4，整個通信過程是這樣的：

1. PC1在請求數據包里面封裝源目IP地址，並將帶有IP地址的數據包 發送到互聯網；

2. 互聯網有大量的網絡通信設備（例如路由器），路由器根據數據包的IP地址查找路由表（地圖） ，然后以接力棒的方式逐跳轉發直到目標服務器；

3. 服務器收到請求數據后，將源目IP地址翻轉 ，並封裝回應數據包發送到互聯網。

上述這個IP通信過程，跟我們日常快遞收寄件 的流程是幾乎類似的：

1. 寄快遞的時候，需要先寫快遞單，快遞單要求寫入寄件方和收件方的姓名和聯系信息 （電話號碼、地址），寫完之后，再將快遞單貼在包裹上面 。

2. 物流公司（或快遞員）根據包裹的寄件地址，通過物流平台（飛機、長途貨車、卡車）將包裹在省市中傳輸 ，直到收件方的城市。

3. 收快遞的時候，快遞員根據包裹收件地址，找到對應的街道或小區，然后通過電話聯系 並交付到我們手里。

在這里，快遞單相當於IP地址、快遞包裹相當於數據包，物流公司/快遞員相當於路由器/交換機 。

經過上面這個案例，我們需要更明確這些知識點：

1. IP協議提供了IP地址，並將源目IP地址夾帶在通信數據包里面，為路由器指明通信方向；

2. IP協議只能指明數據包的源目通信方即"這是誰的送給誰的"，但不能保證數據包一定能到達對方，數據是否會被丟棄以及丟棄之后如何處理 。所以，上面才有這句："IP協議提供面向無連接不可靠傳輸功能 "。那么，如果出現丟包且需要重傳時，誰來解決呢？這就需要TCP/IP協議棧另外一個"半壁江山"來實現，大家肯定猜到了：TCP協議能解決以上這些IP協議不能實現的功能。

當然，IP協議不僅僅只有"快遞單"功能，它還能防止數據包環路、為數據打上重要或不重要等標簽實現流量控制、能驗證數據包是否損壞、能實現數據包分片和組裝功能 ；而要深入學習這些功能，必須掌握IP頭部的封裝格式。

IP協議結構

• 在TCP/IP協議中，使用IP協議傳輸數據的包被稱為IP數據包，毎個數據包都包含IP協議規定的內容。

• IP協議規定的這些內容被稱為IP數據報文( IP Datagram)或者IP數據報。

• IP數據報文由首部和數據兩部分組成。首部的前一部分是固定長度,共20字節,是所有I數據報必須具有的。

• 在首部的固定部分的后面是一些可選字段，其長度是可變的。

字段的說明 :

1. 版本 ：占4位 ，表示IP協議的版本，通信雙方使用的IP協議版本必須一致 ，目前廣泛使用的IP協議版本號為4，即IPV4。

2. 首部長度 ：占4位 ，指出數據報首部長度 。

3. 區分服務 ：占8位 ，在區分服務時這個字段才會起作用，實際上沒有用過 。

4. 總長度 ：占16位 ，首部和數據之和 ，單位為字節。總長度字段為16位，因此數據報的最大長度為2^16-1=65535字節，但是受數據鏈路層協議的影響總長度不能超過最大傳送單位MTU為1500字節 。

5. 標識 ：占16位 ，用來標識數據報每產生—個數據報，其值就加1。當數據報的長度超過網絡的MTU，必須分片 時，這個標識字段的值就被復制到所有的數據報 的標識字段中。具有相同的標識字段值的分片報文會被重組成原來的數據報 。

6. 標志 ：占3位 ，目前只有后兩位有意義。表示該IP數據報是否允許分片和是否是最后的一片。最低一位記為MF，如果MF=1 ，表示后面還有分段 ；如果MF=0 表示這已經是某個數據報的最后一個分段 。中間一位記為DF，當DF=1 時，表示不允許分段，DF=0 表示允許分段 。

7. 片偏移 ：占13位 ，標記該分片在原報文中的相對位置。以8個字節為偏移單位 ，除了最后一個分片，其他分片的偏移值都是8字節的整數倍。

8. 生存時間(TTL) ：占8位 ，表示數據報在網絡中的壽命。每經過一個路由器，則TTL減1，當TTL值為0時，就丟棄這個數據報。設置TTL是為了防止數據報在網絡中無限制地循環轉發 。

9. 協議 ：占8位 ，標識此IP數據報在傳輸層所采用的協議類型。區分IP協議的上層協議。ICMP為1、TCP為6、UDP為17。

10. 首部校驗和：占16位 ，檢驗IP數據報的報頭部分，保證首部數據的完整性。數據報毎經過一個路由器，路由器都要重新計算一下報頭檢驗和，不檢驗數據部分可減少計算的工作量。

11. 源地址 ：占32位 ，表示數據報的源IP地址。數據報發送者 的IP地址。

12. 目的地址 ：占32位 ，表示數據報的目的IP地址。數據報接收者 的IP地址，用於校驗發送是否正確

13. 選項 ：可變長的可選信息,最多包含40字節。支持各種選項，提供擴展余地,用來支持排錯、測量以及安全措施。

IP數據報包解讀

【IP協議字段解讀】

字段名稱	說明
Version（版本號）	標識IP協議的版本，目前V4版本地址已經枯竭，V6慢慢成為主流
Header Length（頭部長度）	默認為20字節，最大為60字節
Differentiated Services Field （服務區分符）	用於為不同的IP數據包定義不同的服務質量，一般應用在QOS技術中
Total Length （總長度）	標識IP頭部加上上層數據的數據包大小，IP包總長度最大為65535個字節
Identification （標識符）	用來實現IP分片的重組，標識分片屬於哪個進程，不同進程通過不同ID區分
Flags（標志符）	用來確認是否還有IP分片或是否能執行分片
Fragment offset （分片偏移量）	用於標識IP分片的位置，實現IP分片的重組
Time to live （生存時間）	標識IP數據包還能生存多久，根據操作系統不同，TTL默認值不同，每經過一個三層設備如路由器的處理，則TTL減去1，當TTL=0時，則此數據包被丟棄
Protocol （協議號）	標識IP協議上層應用。當上層協議為ICMP時，協議號為1，TCP協議號為6，UDP的協議號為17
Header checksum （頭部校驗）	用於檢驗IP數據包是否完整或被修改，若校驗失敗則丟棄數據包
Source（源IP地址）	標識發送者IP地址，占用32bit
Destination （目的IP地址）	標識接收者IP地址，占用32bit

我們可以看到IP頭部默認有12個字段，為了方便記憶，可以總結為7個核心知識點：

• Source和Destination即IP源目地址字段，是IP協議最核心的字段；

• Id+Flags+FO三個字段可以實現IP數據分片和重組；

• Total Length和Header Length標記IP頭部和上層數據的邊界；

• TTL生存時間字段可以實現通信防環；

• DSCP服務區分符可以實現流量控制；

• Checksum字段可以數據包完整性校驗；

• Protocol字段標記上層應用；

IP數據包字段解讀

length長度字段

長度字段在大部分協議里面都會出現，例如IP、TCP、UDP協議，功能都是為了"划分界限"：哪里是頭部，哪里是數據。

如上圖所示，通過Header Length我們知道IP協議的頭部是20字節（默認是20字節，最長可以是60個字節），Total Length這里標明是100個字節，所以剩下的數據部分則是80字節。

划清了頭部和數據的界限之后，又有什么用呢？

當收到數據包之后，無論是電腦/手機還是其他聯網設備，網卡模塊會對數據包進行拆分、修改IP頭部信息、重新進行數據封裝等操作，如果沒有"這條線"，那就可能會"越界"，一旦"越界"，則數據包內容可能損壞 。

當沒有長度字段或長度字段標識錯誤時，網卡在進行拆分的時候，錯誤的把數據部分划分到頭部里面，這樣的話，右邊的數據部分就不完整，接收方最終收到的就是一個損壞的數據包。

好比大家用瀏覽器下載一個word文檔，如果這個文檔本來有80字節大小，現在word只能打開后面的60字節，那肯定是無法打開的。

FO片偏移字段解

例：一數據報的總長度為3820字節，其數據部分為3800字節長(使用固定首部)，需要分片為長度不超過1420字節的數據報片。

因固定首部長度為20字節 ，因此每數據報片的數據部分長度不能超過1400字節 。於是分為3 個數據報片，其數據部分的長分別為1400，1400和1000字節 。原始數據報首部被復制為各數據報片的首部，但必須修有關字段的值。圖414給出分片后得出的結果(請注意片偏移的數值)。

首先明確 偏移量以8個字節為偏移單位。

字節0~1399是第一個1400字節，該片首字節是字節0，0/8=0，故偏移量為0；

字節1400~2799是第二個1400字節，該片首字節是字節1400，1400/8=175，故偏移量為175；

字節2800~3799是最后的1000字節，該片首字節是字節2800，2800/8=350，故偏移量為350；

TTL生存時間字段

TTL（Time to live）即生存時間，用於標識IP數據包"還能存活多久"，這個生存值在發送方發送數據時便設置好了。不同電腦/操作系統的初始TTL是不同的，例如上圖，便是我的Mac電腦發出的，默認值是64，其他一些系統是128或255。由於TTL值占用8個bit位，所以最大值是255（二進制11111111）。

IP數據包每經過一個路由器或三層設備，TTL便會被減去1，而當TTL=0的時候，則代表此數據包"死亡"，此時路由器便會向源發送者返回一個"TTL Exceed"的ICMP報錯包 。

上圖中，如果我的電腦到目標服務器超過了64跳，則這個數據包會中途被丟棄，無法到達目標地。

Checksum字段

checksum校驗字段跟長度字段類似，存在於很多協議里面，用於實現數據完整性校驗。

不同協議采用的方法有差異，例如IP協議的checksum值只校驗IP頭部，不包括數據部分，而TCP和UDP的校驗則包括數據部分。

上圖中，PC1發送IP數據包（含checksum1）給PC2，PC2拆開IP頭部，然后進行校驗計算（checksum2），若校驗沒問題則接收並處理，若檢驗有問題則丟棄 。注意，這里采用的是校驗算法，不是簡單的相同對比。

Protocol字段

無論是IT協議的Protocol字段，還是Ethernet以太網協議里面的Type字段，又或者是TCP/UDP協議里面的Port字段，這些字段的功能都是用於標識上層協議或應用 。例如，ICMP協議號為1，TCP協議號為6，UDP的協議號為17 。

對於很多初學者來而，雖然知道了哪些協議號對應哪些上層應用，畢竟只要背熟了就好，但是我們還需要更深入的思考？例如，在IP協議里面加入協議號標識傳輸層協議，意義何在？'

通過上面這張圖我們可以看到，若PC1 PING PC2，則此時會采用ICMP協議，而ICMP協議對應的協議號是1。當PC2收到這個數據包時，拆開IP頭部，則會看到協議號，根據協議號調用對應的上層協議或應用來進行上層數據處理。

以這里例子來看，若PC2采用TCP或UDP來解開ICMP數據包，則無法正常解析，好比用word程序要打開一部mp4電影，肯定會有故障 。而如果這里PC2根據協議號為1，調用ICMP協議來處理ICMP數據包，則可以正常解讀並返回回應包。

所以，協議號（Protocol）、端口號（Port）、類型值（Type）這些的功能都是：標記上層協議/應用，告訴接收方，有正確的協議/應用來打開這個數據，功能相當於電腦文件的后綴名，告訴電腦用哪些應用程序來打開對應的文件。

參考博文：

https://zhuanlan.zhihu.com/p/29287795

ICMP協議

ICMP協議介紹

ICMP（Internet Control Message Protocol）Internet控制報文協議 。它是TCP/IP協議簇的一個子協議，用於在IP主機、路由器之間傳遞控制消息。控制消息是指網絡通不通、主機是否可達、路由是否可用等網絡本身的消息。這些控制消息雖然並不傳輸用戶數據，但是對於用戶數據的傳遞起着重要的作用。

ICMP出現的原因

在IP通信中，經常有數據包到達不了對方的情況。原因是，在通信途中的某處的一個路由器由於不能處理所有的數據包，就將數據包一個一個丟棄了。或者，雖然到達了對方，但是由於搞錯了端口號，服務器軟件可能不能接受它。這時，在錯誤發生的現場，為了聯絡而飛過來的信鴿就是ICMP 報文。在IP 網絡上，由於數據包被丟棄等原因，為了控制將必要的信息傳遞給發信方。ICMP 協議是為了輔助IP 協議，交換各種各樣的控制信息而被制造出來的。

制定萬維網規格的IETF 在1981 年將RFC7922作為ICMP 的基本規格整理出來了。那個RFC792 的開頭部分里寫着“ICMP 是IP 的不可缺少的部分，所有的IP 軟件必須實現ICMP協議。也是，ICMP 是為了分擔IP 一部分功能而被制定出來的。

ICMP的用途

在RFC，將ICMP 大致分成兩種功能：差錯通知 和信息查詢 。

1. 給送信者的錯誤通知 ：在IP 數據包被對方的計算機處理的過程中，發生了什么錯誤時被使用。不僅傳送發生了錯誤這個事實，也傳送錯誤原因等消息。

2. 送信者的信息查詢 ：在送信方的計算機向對方計算機詢問信息時被使用。被詢問內容的種類非常豐富，他們有目標IP 地址的機器是否存在這種基本確認，調查自己網絡的子網掩碼，取得對方機器的時間信息等。

ICMP報頭格式

ICMP 的內容是放在IP 數據包的數據部分里來互相交流的。也就是，從ICMP的報文格式來說，ICMP 是IP 的上層協議。但是，正如RFC 所記載的，ICMP 是分擔了IP 的一部分功能。所以，被認為是與IP 同層的協議。看一下RFC 規定的數據包格式和報文內容吧。

1. 類型字段顧名思義是定義了ICMP報文的類型

2. 代碼字段表示的是發送這個ICMP報文的原因

3. 校驗和字段

4. 標識：占2字節，用於標識本ICMP進程僅適用於回顯請求和應答ICMP報文，對於目標不可達ICMP報文和超時ICMP報文等，該字段值全為0

5. 首部的其余部分對於不同的ICMP是不同的

6. 數據部分對於差錯報告報文是用於找出引起差錯的原始分組的信息, 對於查詢報文是基於查詢類型的額外的信息

可能的消息列表：

常見的ICMP報文

• 響應請求

常用的ping操作中就包括響應請求 （類型是8 ，代碼是0）和應答 （類型是0 ，代碼是0）ICMP報文

• 目標不可到達、源抑制和超時報文

這三種報文格式一樣

1. 目標不可到達報文 （類型值為3 ）在路由器或者主機不能傳遞數據時使用。

2. 源抑制報文 （類型字段值為4 ，代碼字段值為0）則充當一個控制流量的角色，通知主機減少數據報流量。由於ICMP沒有回復傳輸的報文,所以只要停止該報文，主機就逐漸恢復傳輸速率。

3. 超時報文 （類型字段值為11 ）的代碼有兩種取值：代碼字段值為0表示傳輸超時，代碼字段值為1表示重組分段超時。

• 時間戳請求

時間戳請求報文 （類型值字段13）和時間戳應答報文(類型值字段14)用於測試兩台主機之間數據報來回一次的傳輸時間。

ICMP數據包解讀

分析 ：ping 操作的請求報文類型值是 8 ，代碼值為0

分析 ：ping 操作的響應報文類型值是 0 ，代碼值為0

分析 ：設置 TTL =1 ，經過一個路由器時，TTL = 1-1 =0，超時丟棄， ICMP報文，類型值為11 ，代碼值為0

Wireshark抓包對ping報文的解碼顯示（BE與LE）

我們非常熟悉ping報文的封裝結構，但是，在這個報文解碼里，我們發現wireshark的解碼多了幾個參數：Identifier（BE）、Identifier（LE）、Sequence number(BE)、Sequence number(LE)，如下圖所示：

以前一直未注意wireshark是這樣解碼ping報文的，感覺非常奇怪，我們先來仔細的看一下wireshark對ping報文中這幾個參數的解碼情況：

Wireshark解碼顯示，Identifier（BE）與Identifier（LE）都對應“hex 0200”，Sequence number(BE)與Sequence number(LE)都對應“hex 027b”，仔細看的話，我們能夠發現BE值（0x0200）與LE值(0x0002)之間的差別就是順序不一樣。那到底BE、LE是指什么呢？搜遍百度無果，決定還是去wireshark官網看看，結果發現下面鏈接的內容：http://www.wireshark.org/lists/wireshark-bugs/200909/msg00439.html，其中有一段是這樣描述的：

“After I discovered that the Windows ping sends ICMP echo request packets with the sequence number in little-endian byte order, but the Linux ping sends it in proper big-endian format, a discussion about it took place on the mailing list as to how to handle it (refer to http://www.wireshark.org/lists/wireshark-dev/200909/msg00216.html ).  However,to keep things simple and avoid adding any new ICMP preferences and/or trying to guess at the byte order, I thought why not just display the sequence number in both formats, so that‘s what this patch does.”

我來做個總結：wireshark考慮到window系統與Linux系統發出的ping報文（主要指ping應用字段而非包含IP頭的ping包）的字節順序不一樣（windows 為LE：little-endian byte order ，Linux 為BE ：big-endian ），為了體現wireshark的易用性，開發者將其分別顯示出來。

參考博文：

https://www.cnblogs.com/iiiiher/p/8513748.html

http://www.bubuko.com/infodetail-768087.html