网络协议栈和tcpdump抓包练习

转载 2015年01月13日 00:52:32

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)

加密方式-非对称加密(RSA加密与签名)

上一篇讲到了对称加密,本文主要讲非对称加密。 非对称加密就是指加密解密使用不同的密钥。 经常有人问我公钥私钥到底哪个用来加密哪个用来解密,哪个用来加签,哪个验签。 今天就讲一个比较通俗易懂的方法...

常用的openssl函数

常用的openssl函数base64解编码 依次调用EVP_DecodeInit(), EVP_DecodeUpdate(), EVP_DecodeFinal(),与md5和sha1类似,适用于数据量...

linux:dropwatch 网络协议栈丢包检查利器

原创文章,转载请注明: 转载自系统技术非业余研究 本文链接地址: dropwatch 网络协议栈丢包检查利器 在做网络服务器的时候,会碰到各种各样的网络问题比如说网络超时,通常一般...
  • scdxmoe
  • scdxmoe
  • 2014年09月05日 09:47
  • 1383

dropwatch 网络协议栈丢包检查利器

在做网络服务器的时候,会碰到各种各样的网络问题比如说网络超时,通常一般的开发人员对于这种问题最常用的工具当然是tcpdump或者更先进的wireshark来进行抓包分析。通常这个工具能解决大部分的问题...

网络协议栈指纹原理

  • 2012年03月07日 09:12
  • 7KB
  • 下载

linux网络协议栈(UDP收发)

  • 2013年06月12日 22:03
  • 153KB
  • 下载

Linux内核--网络协议栈深入分析(四)--套接字内核初始化和创建过程

本文分析基于Linux Kernel 3.2.1原创作品,转载请标明http://blog.csdn.net/yming0221/article/details/7984238更多请查看专栏http:...

linux网络协议栈源码实现

  • 2012年03月12日 23:05
  • 478KB
  • 下载

VxWorks网络协议栈的MUX接口

  • 2012年01月04日 23:19
  • 86KB
  • 下载

linux内核网络协议栈学习笔记(1)

这个系列内容会有点杂,会涉及tcp/ip, netfilter, lvs, 网卡驱动等各个方面。。下半年准备把内核网络这一块好好研究下。。好吧从第一篇开始 这篇介绍内核网络中最重要的数据结构,大部...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:网络协议栈和tcpdump抓包练习
举报原因:
原因补充:

(最多只允许输入30个字)