网络协议栈和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..$!.@.@.......6Ae..1.Ps..@.`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.....@.@.U.....6Ae..A.P..U.+......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)