wireshark抓包分析报告TCP和UDP
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
计
算
机
网
络Wireshark抓包分析报告
目录
1. 使用wireshark获取完整的UDP报文 (3)
2. 使用wireshark抓取TCP报文 (3)
2.1 建立TCP连接的三次握手 (3)
2.1.1 TCP请求报文的抓取 (4)
2.1.2 TCP连接允许报文的抓取 (5)
2.1.3 客户机确认连接报文的抓取 (6)
2.2 使用TCP连接传送数据 (6)
2.3 关闭TCP连接 (7)
3. 实验心得及总结 (8)
1. 使用wireshark获取完整的UDP报文
打开wireshark,设置监听网卡后,使用google chrome 浏览器访问我腾讯微博的首页
p.t.qq./welcomeback.php?lv=1#!/list/qqfriends/5/?pgv_ref=im.perinfo.perinfo.icon? ptlang=2052&pgv_ref=im.perinfo.perinfo.icon,抓得的UDP报文如图1所示。
图1 UDP报文
分析以上的报文容,UDP作为一种面向无连接服务的运输协议,其报文格式相当简单。第一行中,Source port:64318是源端口号。第二行中,Destination port:53是目的端口号。第三行中,Length:34表示UDP报文段的长度为34字节。第四行中,Checksum之后的数表示检验和。这里0x表示计算机中16进制数的开始符,其后的4f0e表示16进制表示的检验和,把它们换成二进制表示为:0100 1111 0000 1110.
从wireshark的抓包数据看出,我抓到的UDP协议多数被应用层的DNS协议应用。当一台主机中的DNS应用程序想要进行一次查询时,它构成了一个DNS 查询报文并将其交给UDP。UDP无须执行任何实体握手过程,主机端的UDP为此报文添加首部字段,并将其发出。
2. 使用wireshark抓取TCP报文
2.1 建立TCP连接的三次握手
建立TCP连接需要经历三次握手,以保证数据的可靠传输,同样访问我的腾讯微博主页,使用wireshark抓取的TCP报文,可以得到如图2所示的客户机和服务器的三次握手的过程。
图2 建立TCP连接的三次握手
2.1.1 TCP请求报文的抓取
图2中所示的TCP请求连接报文如图3所示。
图3 TCP请求连接报文
分析图3中的请求报文数据可以发现:
第一行,source port指示源端口号为51329
第二行,destination port指示目的端口号为80,这也正是http客户机进程向服务器发起TCP连接的端口号。
第三行,sequence number指示报文的序号为0.
第四行,header length指示报文的长度为28个字节。
第五行表示标志字段,其中有保留未用区,紧急指针,push指针等。标志字段中SYN值为1,表示该报文是一个客户机请求连接的报文。
第六行,window size指示接受窗口的大小为8192个字节。
第七行,checksum指示校验和为0x8591,同样用16进制表示。
第八行是可选字段。一般而言,TCP报文的可选字段为空,所以报头长度为20个字节,这里多出了8个字节,用来表示最大报文段长等容。具体分析其中
容,kind或者type表示options选项的种类。当kind/type为1时,表示NOP——no operation,即无操作。当kind/type为2时,表示Maximum segment size,最大报文段长。这里,MSS为1460个字节。当kind/type为4时,表示SACK permitted,它表示一旦连接建立,发送的TCP请求报文的客户机期待接收到服务器的SACK选项。整个可选字段的长度为8个字节,其中MSS占了4个字节,NOP 占了2个字节,SACK permitted占了2个字节。
仔细分析报文,我们不难发现,TCP请求连接报文中没有ack确认号,同时报文中也没有包含应用层数据。
2.1.2 TCP连接允许报文的抓取
图2中所示的TCP允许连接报文如图4所示。分析图4中的报文信息如下:
图4 TCP连接允许报文
前两行分别表示了源端口号和目的端口号为80和51329.
第三行,sequence number指示服务器返回的报文的序号为0.
第四行,acknowledgment number指示服务器返回报文的确认号为1.
第五行表示报文长度为28字节。
第六行为标志字段,与TCP请求连接报文的标志字段不同的是,这里的ack 值为1,表示服务器成功接收请求连接报文。
第七行至第第九行和TCP请求连接报文的意义相同,这里不再赘述。
分析连接允许报文,发现,报文的最后出现了一个[SEQ/ACK analysis]字段。这回应了客户机的请求连接申请,并指示往返时延RTT为0.005262秒。
2.1.3 客户机确认连接报文的抓取
图2中所示的客户机确认连接报文如图5所示。由于报文部分容和上文的报文容那个意义相同,这里不再赘述。分析图5中的部分报文信息如下:
图5 客户机确认连接报文
第五行,acknowledgment number值为1,表示客户机成功接收到服务器发来的连接允许响应报文。
第六行表示报头的长度为20个字节,这里不再有选项容。
最后,客户机发出的报文中同样有[SEQ/ACK analysis]字段。它说明了此次报文的意义是对服务器发来的报文的确认,并指示往返时延RTT为0.00011秒。
仔细分析客户机的确认连接报文,可以发现,报文中没有数据容。至此,建立TCP连接的三次握手已经完成,客户机和服务器之间可以相互交换数据了。
2.2 使用TCP连接传送数据
在三次连接建立完成过后,客户机便可以利用建立好的TCP连接向服务器发送数据了。通过wireshark抓包发现,此次试验中,客户机在成功建立TCP连接后,马上向服务器发送了一个http的GET请求报文。抓包结果如图6所示。