以下我们演示一条HTTP请求指令
1 | [root@11c749e93da4 /]# curl www.baidu.com |
接下来是这条指令涉及到的所有TCP以及UDP报文(这篇很难!胆小者勿看)
1 | [root@11c749e93da4 /]# tcpdump -Xvv |
从IP报文开始说起
一般情况下,IPv4头为20字节,
更一般地,版本为4,首部长度为5(5*4=20字节),服务类型为00(代表常规),数据报长度未知,取决于数据,所以前4个字节一般为 4500 xxxx
16位比特标识对于每一个主机发送的IP报文,其数值是递增的,对于IP报文都最后一个分片标志为1,其他分片标志为0,如果路由器不涉及分片,则13位的偏移也为0,故而这四个字节一般为 xxxx,xxxx,xxxx,xxxx 0010 0000,0000,0000
, 也即xxxx 4000
对于8位的寿命,这个是未知的,对于上层协议,UDP为17,TCP为6,故而为11
或者06
,对于首部校验和,这个未知,故而这4个字节一般为 xx11 xxxx
或者 xx06 xxxx
总体上来看:
UDP报文的IP头为 4500 xxxx xxxx 4000 xx11 xxxx xxxx xxxx xxxx xxxx
TCP报文的IP头为 4500 xxxx xxxx 4000 xx06 xxxx xxxx xxxx xxxx xxxx
失败的UDP请求
我们发现前两条中出现了两个UDP报文,这里前10个字节很明显能看到是属于UDP报文被IP封包了。
1 | 07:05:47.059101 IP (tos 0x0, ttl 64, id 10179, offset 0, flags [DF], proto UDP (17), length 59) |
咱们先不管这两个报文是干什么的,不难出现了一个[bad udp cksum 0xb69d -> 0x7fa1!]
,这个意思很明显了,原来这是两个坏的UDP包。我们回顾UDP报文,然后对着两个包进行分析
UDP报文复习
对于第一个报文,我们对他进行如下分解, 其中的 [bad udp cksum 0xb69d -> 0x7fa1!]
指的就是数据部分的校验和不等于b69d所以这个包是一个发生了错误的包,
另一方面我们还能得到一些信息,11c749e93da4.39962 > 183.60.83.19.domain:
代表这个包由11c749e93da4发往183.60.83.19:53, 53是DNS服务器的端口,所以我们猜测这是一个DNS请求
1 | IP 头 |
虽然域名能解析但出现了一些bad udp之类的数据包,很奇怪,后来深入了解了一下网卡的checksum offloading 机制,它是负责计算需要发送或者接收到的TCP/UDP消息的校验和,从而节省CPU的计算开销的一种机制,CheckSum Offload实际上是将传输层的一部分工作交给了硬件完成,以节约系统的CPU资源。微软的测试表明它可以最多节约30%的CPU资源。
————————————————
版权声明:本文为CSDN博主「u010278923」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/u010278923/article/details/81697553
然后后面并没有看到正确的DNS请求报文,笔者还暂未弄清原因
DNS回应
先复习一下DNS协议
1 | 07:05:47.059442 IP (tos 0x0, ttl 60, id 50890, offset 0, flags [DF], proto UDP (17), length 144) |
我们提取DNS回应中第一个UDP报文的数据段
1 | 7149 8180 qI.. |
1 | 事务id: 7149 |
最后,我们发现这就是q: A? www.baidu.com. 4/0/0 www.baidu.com. CNAME www.a.shifen.com., www.a.shifen.com. CNAME www.wshifen.com., www.wshifen.com. A 119.63.197.139, www.wshifen.com. A 119.63.197.151 (116)
PRT
紧接着是一个PRT, IP到域名的逆向查询,这个不知道是干什么的
TCP开始
TCP报文复习
第一次握手
我们的主机发送了第一个TCP链接,(三次握手第一步)
1 | 07:05:47.061686 IP (tos 0x0, ttl 64, id 38458, offset 0, flags [DF], proto TCP (6), length 60) |
我们提取TCP报文
1 | ed98 0050 f8d8 50b8 0000 0000 |
提取TCP报文头部
1 | TCP头 |
解析TCP头
1 | 源端口: ed98 -> 60824 |
第二次握手
百度给我们回应了一个TCP报文(三次握手第二步)
1 | 07:05:47.115732 IP (tos 0x0, ttl 50, id 38458, offset 0, flags [DF], proto TCP (6), length 60) |
提取TCP报文
1 | 0050 ed98 3d15 a71f f8d8 50b9 .....P..=.....P. |
TCP头部
1 | 0050 ed98 3d15 a71f f8d8 50b9 a012 2000 268b 0000 0204 0590 0402 0101 0101 0101 0101 0101 0103 0305 |
解析TCP头部
1 | 源端口: 0050 -> 80 |
第三次握手
我们给百度回复一个TCP报文(三次握手完成)
1 | 07:05:47.115797 IP (tos 0x0, ttl 64, id 38459, offset 0, flags [DF], proto TCP (6), length 40) |
提取TCP报文
1 | ed98 0050 f8d8 50b9 3d15 a720 w?.....P..P.=... |
TCP 头
1 | ed98 0050 f8d8 50b9 3d15 a720 5010 00e5 e8fa 0000 |
解析TCP头
1 | 源端口: ed98 -> 60824 |
发起HTTP请求
紧接着我们发起了一个HTTP请求,这是一个TCP包,包含了我们的整个请求
1 | 07:05:47.115913 IP (tos 0x0, ttl 64, id 38460, offset 0, flags [DF], proto TCP (6), length 117) |
TCP回复
百度对我们的HTTP请求包进行了TCP回复,表示他收到了我们的请求
1 | 07:05:47.170254 IP (tos 0x0, ttl 48, id 24974, offset 0, flags [DF], proto TCP (6), length 40) |
HTTP回复
紧接着就是百度对我们的HTTP回复,以及我们对HTTP回复的TCP回复,并不断重复,直到接受完所有HTTP报文
1 | 07:05:47.236240 IP (tos 0x0, ttl 48, id 24975, offset 0, flags [DF], proto TCP (6), length 1488) |
最后的四次挥手
我们观察最后的六个TCP报文
1 | 07:05:47.236425 IP (tos 0x0, ttl 64, id 38463, offset 0, flags [DF], proto TCP (6), length 40) |
稍作人性化处理
1 | sequenceDiagram |
- 本文作者: fightinggg
- 本文链接: http://fightinggg.github.io/yilia/yilia/QR12J0.html
- 版权声明: 本博客所有文章除特别声明外,均采用 MIT 许可协议。转载请注明出处!