- 轉自：https://mp.weixin.qq.com/s?__biz=MzAxODI5ODMwOA==&mid=266...~
- .，表示沒有任何標誌~
- 所以，斷開鏈接須要分爲四次~
轉自：https://mp.weixin.qq.com/s?__biz=MzAxODI5ODMwOA==&mid=2666539134&idx=1&sn=5166f0aac718685382c0aa1cb5dbca45&scene=5&srcid=0527iHXDsFlkjBlkxHbM2S3E#rdhtml
轉自：http://www.jianshu.com/p/8d9accf1d2f1linux
1 原由安全
前段時間，一直在調線上的一個問題：線上應用接受POST請求，請求body中的參數獲取不全，存在丟失的情況。這個問題是偶發性的，大概發生的概率爲5%-10%左右，這個機率已經至關高了。在排查問題的過程當中使用到了tcpdump和Wireshark進行抓包分析。感受這兩個工具搭配起來幹活，很是完美。全部的網絡傳輸在這兩個工具搭配下，都無處遁形。服務器
爲了更好、更順手地可以用好這兩個工具，特整理本篇文章，但願也能給你們帶來收穫。爲你們以後排查問題，添一利器。網絡
2 tcpdump與Wireshark介紹併發
在網絡問題的調試中，tcpdump應該說是一個必不可少的工具，和大部分linux下優秀工具同樣，它的特色就是簡單而強大。它是基於Unix系統的命令行式的數據包嗅探工具，能夠抓取流動在網卡上的數據包。less
默認狀況下，tcpdump不會抓取本機內部通信的報文。根據網絡協議棧的規定，對於報文，即便是目的地是本機，也須要通過本機的網絡協議層，因此本機通信確定是經過API進入了內核，而且完成了路由選擇。【好比本機的TCP通訊，也必需要socket通訊的基本要素：src ip port dst ip port】運維
若是要使用tcpdump抓取其餘主機MAC地址的數據包，必須開啓網卡混雜模式，所謂混雜模式，用最簡單的語言就是讓網卡抓取任何通過它的數據包，無論這個數據包是否是發給它或者是它發出的。通常而言，Unix不會讓普通用戶設置混雜模式，由於這樣能夠看到別人的信息，好比telnet的用戶名和密碼，這樣會引發一些安全上的問題，因此只有root用戶能夠開啓混雜模式，開啓混雜模式的命令是：ifconfig en0 promisc, en0是你要打開混雜模式的網卡。curl
Linux抓包原理：socket
Linux抓包是經過註冊一種虛擬的底層網絡協議來完成對網絡報文(準確的說是網絡設備)消息的處理權。當網卡接收到一個網絡報文以後，它會遍歷系統中全部已經註冊的網絡協議，例如以太網協議、x25協議處理模塊來嘗試進行報文的解析處理，這一點和一些文件系統的掛載類似，就是讓系統中全部的已經註冊的文件系統來進行嘗試掛載，若是哪個認爲本身能夠處理，那麼就完成掛載。
當抓包模塊把本身假裝成一個網絡協議的時候，系統在收到報文的時候就會給這個僞協議一次機會，讓它來對網卡收到的報文進行一次處理，此時該模塊就會趁機對報文進行窺探，也就是把這個報文完完整整的複製一份，僞裝是本身接收到的報文，彙報給抓包模塊。
Wireshark是一個網絡協議檢測工具，支持Windows平臺、Unix平臺、Mac平臺，通常只在圖形界面平臺下使用Wireshark，若是是Linux的話，直接使用tcpdump了，由於通常而言Linux都自帶的tcpdump，或者用tcpdump抓包之後用Wireshark打開分析。
在Mac平臺下，Wireshark經過WinPcap進行抓包，封裝的很好，使用起來很方便，能夠很容易的制定抓包過濾器或者顯示過濾器，具體簡單使用下面會介紹。Wireshark是一個免費的工具，只要google一下就能很容易找到下載的地方。
因此，tcpdump是用來抓取數據很是方便，Wireshark則是用於分析抓取到的數據比較方便。
3 tcpdump使用
3.1 語法
類型的關鍵字
host(缺省類型): 指明一臺主機，如：host 210.27.48.2
net: 指明一個網絡地址，如：net 202.0.0.0
port: 指明端口號，如：port 23
肯定方向的關鍵字
src: src 210.27.48.2, IP包源地址是210.27.48.2
dst: dst net 202.0.0.0, 目標網絡地址是202.0.0.0
dst or src(缺省值)
dst and src
協議的關鍵字：缺省值是監聽全部協議的信息包
fddi
ip
arp
rarp
tcp
udp
其餘關鍵字
gateway
broadcast
less
greater
經常使用表達式：多條件時能夠用括號，可是要用轉義
非 : ! or 「not」 (去掉雙引號)
且 : && or 「and」
或 : || or 「or」
3.2 選項
3.3 命令實踐
一、直接啓動tcpdump，將抓取全部通過第一個網絡接口上的數據包
二、抓取全部通過指定網絡接口上的數據包
三、抓取全部通過 en0，目的或源地址是 10.37.63.255 的網絡數據：
四、抓取主機10.37.63.255和主機10.37.63.61或10.37.63.95的通訊：
五、抓取主機192.168.13.210除了和主機10.37.63.61以外全部主機通訊的數據包：
六、抓取主機10.37.63.255除了和主機10.37.63.61以外全部主機通訊的ip包
七、抓取主機10.37.63.3發送的全部數據：
八、抓取主機10.37.63.3接收的全部數據：
九、抓取主機10.37.63.3全部在TCP 80端口的數據包：
十、抓取HTTP主機10.37.63.3在80端口接收到的數據包：
十一、抓取全部通過 en0，目的或源端口是 25 的網絡數據
十二、抓取全部通過 en0，網絡是 192.168上的數據包
1三、協議過濾
1四、抓取全部通過 en0，目的地址是 192.168.1.254 或 192.168.1.200 端口是 80 的 TCP 數據
1五、抓取全部通過 en0，目標 MAC 地址是 00:01:02:03:04:05 的 ICMP 數據
1六、抓取全部通過 en0，目的網絡是 192.168，但目的主機不是 192.168.1.200 的 TCP 數據
1七、只抓 SYN 包
1八、抓 SYN, ACK
1九、抓 SMTP 數據，抓取數據區開始爲」MAIL」的包，」MAIL」的十六進制爲 0x4d41494c
20、抓 HTTP GET 數據，」GET 「的十六進制是 0x47455420
2一、抓 SSH 返回，」SSH-「的十六進制是 0x5353482D
2二、高級包頭過濾如前兩個的包頭過濾，首先了解如何從包頭過濾信息：
2三、抓 DNS 請求數據
2四、其餘-c 參數對於運維人員來講也比較經常使用，由於流量比較大的服務器，靠人工 CTRL+C 仍是抓的太多，因而能夠用-c 參數指定抓多少個包。
3.4 抓個網站練練
想抓取訪問某個網站時的網絡數據。好比網站 http://www.baidu.com/ 怎麼作？
一、經過tcpdump截獲主機www.baidu.com發送與接收全部的數據包
二、訪問這個網站
三、想要看到詳細的http報文。怎麼作？
四、分析抓取到的報文
4 tcpdump抓取TCP包分析
TCP傳輸控制協議是面向鏈接的可靠的傳輸層協議，在進行數據傳輸以前，須要在傳輸數據的兩端（客戶端和服務器端）建立一個鏈接，這個鏈接由一對插口地址惟一標識，便是在IP報文首部的源IP地址、目的IP地址，以及TCP數據報首部的源端口地址和目的端口地址。TCP首部結構以下：
注意：一般狀況下，一個正常的TCP鏈接，都會有三個階段:一、TCP三次握手;二、數據傳送;三、TCP四次揮手
其中在TCP鏈接和斷開鏈接過程當中的關鍵部分以下：
源端口號：即發送方的端口號，在TCP鏈接過程當中，對於客戶端，端口號每每由內核分配，無需進程指定；
目的端口號：即發送目的的端口號；
序號：即爲發送的數據段首個字節的序號；
確認序號：在收到對方發來的數據報，發送確認時期待對方下一次發送的數據序號；
SYN：同步序列編號，Synchronize Sequence Numbers；
ACK：確認編號，Acknowledgement Number；
FIN：結束標誌，FINish；
4.1 TCP三次握手
三次握手的過程以下：
step1. 由客戶端向服務器端發起TCP鏈接請求。Client發送：同步序列編號SYN置爲1，發送序號Seq爲一個隨機數，這裏假設爲X，確認序號ACK置爲0；
step2. 服務器端接收到鏈接請求。Server響應：同步序列編號SYN置爲1，並將確認序號ACK置爲X+1，而後生成一個隨機數Y做爲發送序號Seq（由於所確認的數據報的確認序號未初始化）；
step3. 客戶端對接收到的確認進行確認。Client發送：將確認序號ACK置爲Y+1，而後將發送序號Seq置爲X+1（即爲接收到的數據報的確認序號）；
爲何是三次握手而不是兩次對於step3的做用，假設一種狀況，客戶端A向服務器B發送一個鏈接請求數據報，而後這個數據報在網絡中滯留致使其遲到了，雖然遲到了，可是服務器仍然會接收併發回一個確認數據報。可是A卻由於久久收不到B的確認而將發送的請求鏈接置爲失效，等到一段時間後，接到B發送過來的確認，A認爲本身如今沒有發送鏈接，而B卻一直覺得鏈接成功了，因而一直在等待A的動做，而A將不會有任何的動做了。這會致使服務器資源白白浪費掉了，所以，兩次握手是不行的，所以須要再加上一次，對B發過來的確認再進行一次確認，即確認此次鏈接是有效的，從而創建鏈接。
對於雙方，發送序號的初始化爲什麼值有的系統中是顯式的初始化序號是0，可是這種已知的初始化值是很是危險的，由於這會使得一些黑客鑽漏洞，發送一些數據報來破壞鏈接。所以，初始化序號由於取隨機數會更好一些，而且是越隨機越安全。
tcpdump抓TCP三次握手抓包分析：
sudotcpdump-n-S-ilo0host10.37.63.3andtcpport8080
# 接着再運行：
curlhttp://10.37.63.3:8080/atbg/doc
控制檯輸出：
每一行中間都有這個包所攜帶的標誌：
S=SYN，發起鏈接標誌。
P=PUSH，傳送數據標誌。
F=FIN，關閉鏈接標誌。
ack，表示確認包。
RST=RESET，異常關閉鏈接。
.，表示沒有任何標誌。
第1行：16:00:13.486776，從10.37.63.3（client）的臨時端口61725向10.37.63.3（server）的8080監聽端口發起鏈接，client初始包序號seq爲1944916150，滑動窗口大小爲65535字節（滑動窗口即tcp接收緩衝區的大小，用於tcp擁塞控制），mss大小爲16344（便可接收的最大包長度，一般爲MTU減40字節，IP頭和TCP頭各20字節）。【seq=1944916150，ack=0，syn=1】
第2行：16:00:13.486850，server響應鏈接，同時帶上第一個包的ack信息，爲client端的初始包序號seq加1，即1944916151，即server端下次等待接受這個包序號的包，用於tcp字節流的順序控制。Server端的初始包序號seq爲1119565918，mss也是16344。【seq=1119565918，ack=1944916151，syn=1】
第3行：15:46:13.084161，client再次發送確認鏈接，tcp鏈接三次握手完成，等待傳輸數據包。【ack=1119565919，seq=1944916151】
4.2 TCP四次揮手
鏈接雙方在完成數據傳輸以後就須要斷開鏈接。因爲TCP鏈接是屬於全雙工的，即鏈接雙方能夠在一條TCP鏈接上互相傳輸數據，所以在斷開時存在一個半關閉狀態，即有有一方失去發送數據的能力，卻還能接收數據。所以，斷開鏈接須要分爲四次。主要過程以下：
step1. 主機A向主機B發起斷開鏈接請求，以後主機A進入FIN-WAIT-1狀態；
step2. 主機B收到主機A的請求後，向主機A發回確認，而後進入CLOSE-WAIT狀態；
step3. 主機A收到B的確認以後，進入FIN-WAIT-2狀態，此時即是半關閉狀態，即主機A失去發送能力，可是主機B卻還能向A發送數據，而且A能夠接收數據。此時主機B佔主導位置了，若是須要繼續關閉則須要主機B來操做了；
step4. 主機B向A發出斷開鏈接請求，而後進入LAST-ACK狀態；
step5. 主機A接收到請求後發送確認，進入TIME-WAIT狀態，等待2MSL以後進入CLOSED狀態，而主機B則在接受到確認後進入CLOSED狀態；
爲什麼主機A在發送了最後的確認後沒有進入CLOSED狀態，反而進入了一個等待2MSL的TIME-WAIT主要做用有兩個：
第一，確保主機A最後發送的確認可以到達主機B。若是處於LAST-ACK狀態的主機B一直收不到來自主機A的確認，它會重傳斷開鏈接請求，而後主機A就能夠有足夠的時間去再次發送確認。可是這也只能盡最大力量來確保可以正常斷開，若是主機A的確認老是在網絡中滯留失效，從而超過了2MSL，最後也沒法正常斷開；
第二，若是主機A在發送了確認以後當即進入CLOSED狀態。假設以後主機A再次向主機B發送一條鏈接請求，而這條鏈接請求比以前的確認報文更早地到達主機B，則會使得主機B覺得這條鏈接請求是在舊的鏈接中A發出的報文，並不當作是一條新的鏈接請求了，即便得這個鏈接請求失效了，增長2MSL的時間可使得這個失效的鏈接請求報文做廢，這樣纔不影響下次新的鏈接請求中出現失效的鏈接請求。
爲何斷開鏈接請求報文只有三個，而不是四個由於在TCP鏈接過程當中，確認的發送有一個延時（即經受延時的確認），一端在發送確認的時候將等待一段時間，若是本身在這段事件內也有數據要發送，就跟確認一塊兒發送，若是沒有，則確認單獨發送。而咱們的抓包實驗中，由服務器端先斷開鏈接，以後客戶端在確認的延遲時間內，也有請求斷開鏈接須要發送，因而就與上次確認一塊兒發送，所以就只有三個數據報了。
5 Wireshark分析tcpdump抓包結果
一、啓動8080端口，tcpdump抓包命令以下：
tcpdump-ilo0-s0-n-Shost10.37.63.3andport8080-w./Desktop/tcpdump_10.37.63.3_8080_20160525.cap
# 而後再執行curl
curlhttp://10.37.63.3:8080/atbg/doc
二、使用Wireshark打開tcpdump_10.37.63.3_8080_20160525.cap文件
No. 1-4 行：TCP三次握手環節；
No. 5-8 行：TCP傳輸數據環節；
No. 9-13 行：TCP四次揮手環節；
三、順便說一個查看 http 請求和響應的方法：
彈窗以下圖所示，上面紅色部分爲請求信息，下面藍色部分爲響應信息：
以上是Wireshark分析tcpdump的簡單使用，Wireshark更強大的是過濾器工具，你們能夠自行去多研究學習Wireshark，用起來仍是比較爽的。
推薦幾個關於Wireshark的文章：
一站式學習Wireshark
標籤：部分 cpp 序列 客戶 類型 增長 求和 彈窗 一個
原文地址：http://www.cnblogs.com/jhj117/p/7827331.html
以上就是：轉：tcpdump抓包分析(強烈推薦) 的所有內容。本站部份內容來源於互聯網和用戶投稿，若有侵權請聯繫咱們刪除，謝謝。Email：server@01hai.com