wiresharkTcpUdp抓包分析Word下载.docx

上传人:b****6 文档编号:22084486 上传时间:2023-02-02 格式:DOCX 页数:8 大小:374.62KB
下载 相关 举报
wiresharkTcpUdp抓包分析Word下载.docx_第1页
第1页 / 共8页
wiresharkTcpUdp抓包分析Word下载.docx_第2页
第2页 / 共8页
wiresharkTcpUdp抓包分析Word下载.docx_第3页
第3页 / 共8页
wiresharkTcpUdp抓包分析Word下载.docx_第4页
第4页 / 共8页
wiresharkTcpUdp抓包分析Word下载.docx_第5页
第5页 / 共8页
点击查看更多>>
下载资源
资源描述

wiresharkTcpUdp抓包分析Word下载.docx

《wiresharkTcpUdp抓包分析Word下载.docx》由会员分享,可在线阅读,更多相关《wiresharkTcpUdp抓包分析Word下载.docx(8页珍藏版)》请在冰豆网上搜索。

wiresharkTcpUdp抓包分析Word下载.docx

6.2流媒体播放时传输层报文分析

5.1TCP协议的格式及特点

图1TCP协议报头格式

源端口:

数据发起者的端口号;

目的端口:

数据接收方的端口号;

32bit序列号,标识当前数据段的唯一性;

32bit的确认号,接收数据方返回给发送方的通知;

TCP头部长度为20字节,若TCP头部的Options选项启用,则会增加首部长度,因此TCP是首部变长的传输层协议;

Reserved、Reserved、Nonce、CWR、ECN-Echo:

共6bit,保留待用。

URG:

1bit紧急指针位,取值1代表这个数据是紧急数据需加速传递,取值0代表这是普通数据;

ACK:

1bit确认位,取值1代表这是一个确认的TCP包,取值0则不是确认包;

PSH:

1bit紧急位,取值1代表要求发送方马上发送该分段,而接收方尽快的将报文交给应用层,不做队列处理。

取值0阿迪表这是普通数据;

RST:

1bit重置位,当TCP收到一个不属于该主机的任何一个连接的数据,则向对方发一个复位包,此时该位取值为1,若取值为0代表这个数据包是传给自己的;

SYN:

1bit请求位,取值1代表这是一个TCP三次握手的建立连接的包,取值为0就代表是其他包;

FIN:

1bit完成位,取值1代表这是一个TCP断开连接的包,取值为0就代表是其他包;

WindowSize:

16bit窗口大小,表示准备收到的每个TCP数据的大小;

Checksum:

16bit的TCP头部校验,计算TCP头部,从而证明数据的有效性;

UrgentPointer:

16bit紧急数据点,当功能bit中的URG取值为1时有效;

Options:

TCP的头部最小20个字节。

如果这里有设置其他参数,会导致头部增大;

Padding:

当TCP头部小于20字节时会出现,不定长的空白填充字段,填充容都是0,但是填充长度一定会是32的倍数;

Data:

被TCP封装进去的数据,包含应用层协议头部和用户发出的数据。

5.2请求网页文件时传输层报文分析

下面结合具体的Wireshark的抓包分析TCP报文的特点。

如图2所示。

图2TCP协议中请求建立连接

首先,注意到该报文的SYN字段为1,因此该报文为建立连接的报文。

窗口个数为8192。

Option字段中指明了最长字段长度为1460字节。

图3服务器返回请求建立连接的确认

图3表示出了服务器向用户返回请求建立连接报文的确认字段,其中SYN为1,ACK为1。

传送的数据序列号为0。

窗口大小仍然为8192。

图3即为TCP协议建立连接过程中的三次握手中的第二次握手。

图4建立连接的“第三次握手”

上图中,图2、图3、图4代表了TCP协议建立连接时的三次握手。

同时,从图4中可以看出窗口长度是一个变量。

并且首部长度字段为20,没有option字段。

图5TCP关闭连接的过程

图6TCP关闭连接时的第三次握手

图5,图6分别是TCP关闭连接时的三次握手。

图5中上半部分是用户发起结束TCP连接的请求报文,同时用户对收到的服务器数据做出响应,并返回服务器的请求容。

图5中下半部分为服务器的结束连接部分,其余响应与用户相同。

图6中用户返回最终确认报文,结束连接。

6.1UDP报文格式及特点

图7中给出了UDP报文格式。

可以看出,UDP是一种固定格式的协议,其头部共64bit,包含4个等长的部分,分别表示原端口号、目的端口号、UDP报文段长度以及校验和。

图7UDP协议格式

利用Wireshark抓取流媒体播放时的UDP报文协议如图8所示。

协议头部包含4部分,其中目的端口号为13777,源端口号为:

13000,校验和为0x989e,整个协议长度为:

43字节,从数据部分的长度为35字节也可以看出头部为8字节,刚好是16*4bits。

校验和后面[validationdisaled]部分意思不明确。

图8WiresharkUDP抓包结果

根据UDP首部固定长度的特点,其长度字段最大能表示65536字节,那么一个UDP协议最多能够包含的数据长度即为65528字节。

6.2流媒体播放时传输层报文分析

图9为使用千千静听播放歌曲时Wireshark所抓数据包的UDP部分。

图9“千千静听”Wireshark抓包结果

观察图10,不难发现一个奇怪现象,在前面几个UDP协议时本地IP地址是变动的。

同时SSDP以及不知名协议在传输层均是使用UDP协议。

SSDP协议具体容如图10。

图10SSDP协议

根据SSDP协议的具体容,除了看出其应该是应用层协议以外,没有其他的额外信息。

但是值得注意的是,UDP长度字段指示为154字节,出去8字节的首部长度还应该有146字节的数据部分,说明HTP部分就是整个数据字段。

同时还有一个值得注意的现象,如图11所示。

图11奇怪的现象

图11中奇怪之处已用红色椭圆标出。

首先上面的报文是接收报文,下面的报文是发送报文。

首先,就数据部分而言,上下报文只有一个字符的差异e和f,即1110和1111。

同时UDP协议中长度字段之差为8字节刚好为UDP首部长度。

不得不使人猜想,用户又将服务器发送来的数据加上头部打包发回给服务器。

但是UDP是无确认机制的服务,如果报文错误,将被直接丢弃不会返回错误的响应。

上图中的现象还有待进一步确认。

总结

通过抓包分析,加深了对TCP建立连接以及关闭连接时三次握手的认识。

但是TCP传输层协议的具体实现过程,由于抓的包太多没有能够具体分析,因此对课本的理解还有待加强。

关于UDP协议,其校验和后的[validationdisabled]是否能够说明其快速的传输是建立在舍弃最大正确概率的基础上,这一点仍不是很清楚。

但是在TCP协议抓包时校验和后也出现了同样的字段,是否又说明是计算机设置的问题。

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 高等教育 > 农学

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1