網絡協議棧和tcpdump抓包練習

0 網絡協議棧

0.1 協議棧總圖

http://www.cnblogs.com/image-eye/archive/2012/04/06/2434919.html

0.2 協議棧 蛋疼之處

http://blog.sina.com.cn/s/blog_6e7f61f301012j0z.html

協議分層的用意很明確：
讓設備，尤其是路由和防火牆，能夠明白每一個協議單元“是什麼”。
便於開發人員理解協議。

預留了擴展性。
但協議分層也帶來了一些缺陷
不必要的數據包拆分
額外的重複的數據頭
動不動就廢棄的預定義字段
協議分層引來了協議棧，即從裸數據開始，不斷的添加各層協議頭，最後再按相反順序送出整個數據。站在上層開發者角度來說，這是最自然的方式；然而，這樣做，不但引發了多個問題，而且是完全沒有必要的。

先說問題：
許多協議頭都是變長的，因此在構造棧時，必須使用向高地址增長的棧，或者在低地址預留足夠長度的空間供棧的增長用。前者在棧輸出時就會產生性能問題，後者存在風險並且內存開銷高。
許多協議頭不易區分並識別。例如tcp包和udp包是基於ip包的，但在ip包中，協議類型裝在第三個雙字的第二個字節，ip包自身的版本卻裝在了第一個雙字的前半個字節。。。。。。如果你是一個防火牆開發者，會對此無比厭惡。ipv6爲了兼容ipv4，仍然使用了這種佈局，我只能說愚蠢。
許多協議頭的位定義太古老。現代網絡硬件擁有大量的緩衝區和接口位的併發讀寫能力，一次讀取十幾個字節再處理，比一位一位讀取處理要高效得多。然而，爲了兼容，協議中仍然存在這種定義。對於使用32/64位處理器來處理協議的操作系統來說，這非常不經濟。

然後是理想狀況：
協議頭應當是定長的，如果需要變長，則作爲數據內容處理。如果一個包分片，則每個片段的數據內容都應該定長。而且，這個長度最好是存儲設備的物理分塊大小的整數倍/分數。
協議頭應當可以立刻識別，而不論它是哪一層的。很難做到，但是必須做到。
協議頭所有字段只使用字節定義。有可能的話，使用4字節或8字節倍數。

最後說解決方法：
取消鏈路層（不含）以上的分層。那些都是毫無必要的。
使用分配的特徵串來指定協議類型並匹配協議，而不是版本號/協議號這些華而不實的東西。
所有協議頭定長，沒有什麼可選字段。協議參數均按1位定義，每個協議自己去解釋參數作用。
協議兼容性（例如tcp兼容ip）是通過替代，而不是擴展實現的。首先特徵串會保證設備儘快匹配到兼容協議，然後兼容協議的參數位一致。
協議數據長度固定，可以爲128/256/512這樣的長度，缺少補0。
將ip協議的地址概念推廣到其他兼容協議。不需要留空即可。【所有協議自己實現IP協議？】

結果是：
協議分層的問題被徹底避免了。
協議頭被規範化了。對於大部分包，去掉了諸如頭長度、協議子類型、版本號這種字段，改爲一個4字節的特徵串。
參數只用0/1區分，事實上協議參數大部分都只需要true/false或者一個有限範圍內的option/level。如果無法實現，那隻能說該協議太爛。
協議頭大概在8字節（4字節特徵串＋4字節參數）或64字節（4字節特徵串＋4字節參數＋8字節數據內容長度＋16字節source＋16字節dest＋16字節擴展參數），和現有協議相當。但對於應用來說，不要開心死了。

1 抓包

1.1 HTTP 抓包

sudo tcpdump -Av   -c 100 dst 45.56.11.128

00:48:55.309909 IP (tos 0x0, ttl 64, id 8600, offset 0, flags [DF], proto TCP (6), length 1060)
    x-OptiPlex-9020.local.60977 > ec2-54-65-101-218.ap-northeast-1.compute.amazonaws.com.http: Flags [P.], cksum 0x3f97 (incorrect -> 0xc580), seq 0:1008, ack 1, win 115, options [nop,nop,TS val 33291196 ecr 1197678731], length 1008
E..$!.@[email protected]..@.`F....s?......
....Gc .GET /it/category/2 HTTP/1.1
Host: blogread.cn
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
User-Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.71 Safari/537.36
Referer: http://blogread.cn/it/category/4
Accept-Encoding: gzip, deflate, sdch
Accept-Language: zh-CN,zh;q=0.8
Cookie: saeut=58.60.1.60.1420976910277846; viewid=19465678d4de30c1d6ea87c5a52cee85; PHPSESSID=f9dfec13e14b5870fe955ca6962a4a03; AJSTAT_ok_pages=8; AJSTAT_ok_times=4; CNZZDATA2320291=cnzz_eid%3D1357462792-1420973175-http%253A%252F%252Fweibo.com%252F%26ntime%3D1421079841; __utmt=1; __utma=36422131.1073292722.1420976913.1421076882.1421080068.5; __utmb=36422131.3.10.1421080068; __utmc=36422131; __utmz=36422131.1420976913.1.1.utmcsr=weibo.com|utmccn=(referral)|utmcmd=referral|utmcct=/2635728142/profile; Hm_lvt_7d07e17bc73562efebd41b6ddcd5a499=1420976914,1421077204; Hm_lpvt_7d07e17bc73562efebd41b6ddcd5a499=1421081192



00:48:56.978079 IP (tos 0x0, ttl 64, id 43193, offset 0, flags [DF], proto TCP (6), length 419)
    x-OptiPlex-9020.local.60993 > ec2-54-65-101-218.ap-northeast-1.compute.amazonaws.com.http: Flags [P.], cksum 0x3d16 (incorrect -> 0xf4b8), seq 0:367, ack 1, win 115, options [nop,nop,TS val 33291613 ecr 1197679150], length 367
E.....@[email protected].+......s=......
...]Gc".GET /wp-includes/images/smilies/icon_smile.gif HTTP/1.1
Host: www.laruence.com
Connection: keep-alive
Accept: image/webp,*/*;q=0.8
User-Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.71 Safari/537.36
Referer: http://blogread.cn/it/category/2
Accept-Encoding: gzip, deflate, sdch
Accept-Language: zh-CN,zh;q=0.8

 1.2 TCP包的輸出信息：

http://blogread.cn/it/article/7254

?

1 2 3 4

#tcpdump tcp port 11211 .... 17:31:47.143178 IP host1.48232 > host2.11211: S 307816357:307816357(0) win 14600 <mss 1460,sackOK,timestamp 1916733618 0,nop,wscale 7> ....

   17:31:47.143178 是時間

   IP 是協議說明。

   host1.48232 > 是發送端主機和端口。符號 > 表明數據的傳輸方向。

   host2.11211 接收端的主機名和端口。

   S flags是TCP包中的標誌信息(S是SYN標誌，F(FIN)，P(PUSH)，R(RST)，”.”(沒有標記))。

   第五列 ata-seqno是數據包中的數據的順序號。

   第六列 ack是下次期望的順序號。

   第七列 window是接收緩存的窗口大小。

參考資料

   http://www.cnblogs.com/ggjucheng/archive/2012/01/14/2322659.html  輸出格式

   http://wangjunle23.blog.163.com/blog/static/1178381712012724196814/

   http://blog.chinaunix.net/uid-11242066-id-4084382.html

   http://bbs.chinaunix.net/thread-1508322-1-1.html

   http://blog.csdn.net/jiayanhui2877/article/details/5953725

   http://www.360doc.com/content/11/1013/12/1162697_155701557.shtml#

   http://www.startos.com/linux/tips/2010122818605_5.html

   http://albanianwizard.org/how-to-read-tcpdump-output-tcpdump-advanced-use.albanianwizard

   http://blog.csdn.net/chinainvent/article/details/5177877 tcp三次握手

建議繼續學習：

1. 神探tcpdump第一招    (閱讀：5287)
2. 使用wireshark分析網絡報文    (閱讀：3987)
3. 記一次丟包網絡故障    (閱讀：3463)
4. ssldump    (閱讀：3054)
5. 神探tcpdump第六招    (閱讀：2980)
6. 神探tcpdump第三招    (閱讀：2540)
7. 神探tcpdump第五招    (閱讀：2559)
8. 神探tcpdump第四招    (閱讀：2357)
9. tcpdump匹配http頭    (閱讀：1861)