计
算
机
网
络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所示。

图6 建立在TCP连接上的http请求报文
对图6中的部分报文容分析如下：
报文容指示源端口号为51329，目的端口号为80，序号为1，期待接收的下一个序号为1.同时发送报文使用了PUSH功能，表示接收方应立即将数据交给上层。

在传输层之下，客户机发送了一个http请求报文。

具体容意义，这里不再赘述。

2.3 关闭TCP连接
关闭一个TCP连接需要经历客户机和服务器间的四次通信。

使用google chrome浏览器访问blog.sina../s/blog_6cd6462d010104av.html，并使用wireshark 抓包，其中一个TCP连接的关闭过程如图7所示。

图7 TCP连接的关闭
分析图7中的TCP报文，首先由客户机192.168.1.102向电信服务器
221.236.31.234发送一个特殊的TCP报文字段。

该报文字段的首部中，FIN比特被置为1，表示请求关闭与服务器间的连接。

ACK=1表示对上一次连接的确认，期待服务器返回的下一字节的序号为1.
然后，服务器在收到请求关闭连接的报文之后，向客户机发送一个确认报文。

可以看到报文第一个字节的序号为1，ACK=2表示服务器期待接收的下一字节的序号为2.
接着，服务器向客户机发送终止报文段，其FIN比特被置为1.ACK=2表示服务器期待接收的下一个字节的序号为2.
最后，客户机向服务器的终止报文进行确认，返回的报文第一个字节的序号为2.并设置定时器，在定时器超时后，关闭连接。

可以看到，整个TCP连接关闭过程，客户机和服务器之间的通信完全符合TCP 报文传输的格式规。

3. 实验心得及总结
在此次wireshark抓包实验中，我更加深刻的理解了UDP和TCP协议的报文格式，传输规和功能作用。

UDP报文结构相当简单，它可以使应用层更好地控制要发送的数据和发送时间，而且无需建立连接。

报文的简单也降低了分组首部的开销。

TCP报文格式相对复杂，它需要建立连接。

可以很有效的实现数据的可靠传输，连接管理、拥塞管理和流量控制等功能。

在抓得的网络协议包中，我发现UDP协议大部分被DNS协议使用，TCP协议大部分被HTTP和FTP协议使用。

流水线机制无处不在。

事实上，分析wireshark抓得的我访问一个的网络协议包，可以看到客户机几乎每次都向服务器发出许多TCP连接请求，由于网络时延，服务器也会在一个时间段集中返回确认报文容。

由于访问一个网页要建立很多TCP连接，所以在关闭连接时，客户机也使用了流水线机制。

这更加充分的利用了计算机资源和网络资源，提高了响应速度。