本文假定的基礎是閱讀者會使用Wireshark了，這裡就對一些應用的場景以及一些不正常的網路環境來進行分析的案例~

這裡先列一下篩選器的語法：

過濾語法：

邏輯運算子：&&、||、！等

操作符：==、！=、>、<、>=、<=等

Wireshark的資訊統計（Statistics）

每次檢視大量資料包流量時，建議從Wireshark的資訊統計部分開始進行總的檢視，往往能夠了解到大體的一些資訊，對後續具體的流量分析作用很大。

檢視端點（Endpoints），往往可以觀察到該資料包中哪些地址的流量較多等資訊，可以判斷出哪些地址比較可疑等資訊，如下：

如圖可知哪些IP地址的流量較多。

檢視會話（Conversations），會話跟端點的區別在於會區別顯示哪兩個IP在通訊，且各自都發送多大的資料等，如下：

協議分層（Protocol Hierarchy Statistics），從該視窗中可看出是哪些協議的流量比較多，如下：

每次進行流量檢查的時候最好先開啟這個視窗，方便進行總的流量檢視，若不常用的協議流量較多時則可能存在一些異常行為。

資料包長度（Packet Lengths），可以檢視資料包的大小所佔百分比，如果存在著很多的較大的資料包，則很可能是在傳輸資料，如下：

檢視IO圖（IO Graphs），顯示下載量和下載速度，如下分別為下載慢的和快的：

雙向時間圖（TCP Stream Graph>Round Trip Time Graph），確定是否存在延遲，延遲點的檢視即檢視峰值較高的點，如下：

專家資訊（Analyze>Expert Info Composite），在Analysis中，如下：

可知道這個協議的資料包的狀態，其中有四類狀態：對話chat（關於通訊的基本資訊）、注意note（正常通訊中的異常資料包）、警告warn（不是正常通訊中的異常資料包）、錯誤error（資料包中的錯誤，或者解析器解析時錯誤）。

一些常見的協議包

IPv4頭存活時間TTL：TTL值規定了資料包在丟棄之前所能經歷的時間或者能夠經過的最大的路由數目。通常在建立時就有初始值。如下圖：

TCP三次握手：

TCP終止FIN：

TCP重置RST：

ICMP網際網路控制訊息協議Ping功能：

Type為8、Code為0意味著這是一個echo請求，Type為0、Code為0意味著這是一個echo響應：

DNS查詢（資源記錄型別A-IPv4主機地址，NS-權威域名伺服器，CNAME-規範別名，MX-郵件交換，TXT-文字字串，AAAA-IPv6主機地址，IXFR-增量區域傳送，AXFR-完整區域傳送）：

實戰案例

1、Wireshark嗅探分別ncat和nc流量來進行無加密和加密傳輸的對比

nc無加密傳輸：

開啟BT5和Kali，在BT5上輸入：nc -lp 1234 -c bash

接著在Kali輸入：nc -nv BT5的IP 1234

然後進行遠端命令互動，如下：

全程用Wireshark抓包分析，直接追蹤TCP流檢視得到兩者之間的通訊內容：

可見，通訊內容是明文傳輸的，容易被嗅探到。

ncat使用--ssl引數進行加密傳輸：

同樣在BT5和Kali上，在BT5上輸入：ncat -nvl 1234 -c bash --ssl

接著在Kali輸入：ncat -nv BT5的IP 1234 --ssl

然後兩者進行簡單的通訊，內容如下：

全程用Wireshark抓包分析，直接追蹤TCP流檢視得到兩者之間的通訊內容：

會發現通訊內容被加密了，即使嗅探了也無法得到明文內容。值得注意的是必須在此使用--ssl引數進行加密，否則還是進行明文傳輸。

2.TCP的錯誤恢復和流量控制機制以及識別、診斷網路慢的問題

1)TCP重傳

重傳資料包是TCP最基本的錯誤恢復特性之一。當資料包傳送出去但是接收方並沒有傳送ACK時，傳送方會認為原來的資料包已經丟失然後再重傳，期間RTO（重傳超時）的值會翻倍。整個過程會持續收到接收方傳送的ACK或者是傳送方重傳次數達到最大值為止。

下面的例子中，隨機開啟兩個連續的包檢視RTO值，後者的大約為前者的兩倍：

2)TCP重複確認和快速重傳

當接收方收到亂序的資料包時，便傳送重複的ACK，且TCP在其頭部使用序號和確認號欄位來確保資料被可靠接受並以傳送順序重組。

接收資料的序號+接收資料的位元組數=發出的確認號

當接收方接收到與計算不一樣的序號的時候會假設有資料包丟失了，從而會向傳送方傳送一個包含丟失的資料包序號的ACK資料包讓傳送方重傳資料包。而當傳送方收到3個來自接收方的重複ACK時會立刻傳送一個快速重傳。重傳其間其他所有的正在傳輸的都停止下來等重傳資料包完成傳輸才能繼續傳輸。

如下：

3)TCP滑動視窗機制

TCP滑動視窗機制用於檢測何時發生了資料包丟失並調整資料傳輸速率加以避免。

視窗大小：伺服器會計算客戶端在此前傳送資料包的速率並計算按如此速率下去接受是否會發生資料包丟失，若可能會發生丟失時，伺服器會根據能夠接受的速率進行調整返回的ACK資料包的TCP頭部視窗大小值來實現資料的正常接受。另外，視窗大小值遞減，是主機延遲增加的一個典型指標。

零視窗：有時候伺服器會沒辦法處理客戶端傳送過來的資料，這是伺服器會發送一個數據包指明視窗大小是零，讓客戶端停止所有的資料傳輸。但客戶端依然會通過傳送“保活資料包”來保持和伺服器的連線以便確認伺服器接受視窗的狀態。

例項：

視窗大小逐漸減小至零視窗大小之後恢復：

視窗大小減少至零視窗後無法恢復：

小結：

若客戶端檢測到伺服器沒有接收到它傳送的資料的話就會發生重傳；

當接收到重複ACK時肯定是因為接收到亂序的資料包才引發的；

滑動視窗與伺服器的接受、處理資料的故障直接相關。

4)網路高延遲

正常通訊

整個通訊過程是相當迅速的，即每個資料包傳送的時間不會隔很久：

線路延遲

第二個資料包SYN/ACK的傳送存在延遲，這是客戶端和伺服器之間的裝置導致的。因為當伺服器收到一個SYN資料包時，它不涉及任何傳輸層以上的處理，是隻需要很小的處理量就能夠進行傳送一個響應的，即使是在承受巨大的流量負載的時候也一樣能迅速響應，從而排除了伺服器的可能性。另外，客戶端也是理所當然地排除在外，因為它除了之前傳送一個SYN之後就沒做過啥了。因而推敲是線路的問題。

第五個資料包也存在高延遲現象，是在資料包4即HTTP的GET請求從客戶端正常傳送給伺服器之後的，而同樣，伺服器在傳送資料之前先發送一個ACK是不會耗費很多處理資源的，因而這也是線路延遲的一個標誌。

線路延遲說明了問題並不是出在客戶端或者伺服器中，而是線路中的某些裝置中，可能是防火牆、代理伺服器之類的問題等等。

客戶端延遲

三次握手正常，到資料包4即進行HTTP的GET請求時存在延時。檢視資料包3和4之間，資料包3是客戶端傳送ACK給伺服器進行三次握手的最後一步，接著再資料包4也是客戶端傳送HTTP的GET請求給伺服器，所以可以確定和伺服器無關而問題是出在客戶端，即其中傳送ACK之後並沒有快速地切換到GET，因而導致了高延遲。

伺服器延遲

直到最後一個數據包才出現高延遲的現象。

例子中，資料包5是伺服器響應客戶端GET請求的ACK，在其之後，伺服器應當立即開始傳送資料給客戶端而不是延遲了一段時間。這說明了伺服器沒能夠及時地處理好這些資料，即可判定是伺服器存在延遲現象。

延遲定位框架

下圖總結一下對於網路延遲問題的定位，對於任何基於TCP的通訊都幾乎可用：

①線路延遲

②客戶端延遲

③伺服器端延遲

3.抓包分析NMAP工具進行SYN掃描

TCP SYN掃描是依賴於三次握手來確定目標主機上哪些埠是開放的。攻擊者會發送TCP SYN資料包到目標主機的一個範圍的埠上，假裝是要進行建立正常的通訊連線，這也是TCP三次握手的第一次。若目標機器回覆了TCP SYN/ACK資料包，則表明該埠是開啟的，且這時候攻擊者是不進行任何回覆的，這樣導致目標主機會進行3次重傳SYN/ACK；若攻擊者收到相應的RST資料包，表明埠已經關閉了；若攻擊者沒有收到任何響應，則意味著埠被某個中間裝置過濾了，可能是防火牆或者主機本身。

示例：

可以通過“統計”>“會話”中的資料來快速識別哪些埠是開放的或者是關閉的：

其中點選Conversations視窗內的TCP：1994，讓packets按從大到小的順序排序，其中5個包（SYN、SYN/ACK、三次重傳SYN/ACK）的埠就是開放的，2個包（SYN、RST）的埠就是關閉的，剩下的都是一個包（SYN）的都是不確定的。

4.被動式作業系統指紋術

“作業系統指紋術”是指在無物理接觸的情況下，來確定目標主機執行的作業系統的一組技術，分為主動式和被動式。

主動式主要為使用Nmap發起主動的掃描，然後再與指紋資料庫進行對比後確認。而被動式則主要是根據不同作業系統實現的TCP/IP協議棧都必須為這些域定義它自己的預設值來實現識別的原理。

可以參考下圖直接進行識別：