实验六报告分析示例（508109030137唐韬），仅供参考

[heb...@gmail.com]

I've shared a document with you called "实验六报告分析示例（508109030137唐韬）":
http://docs.google.com/Doc?id=d7zwpr9_137df6b5bfq&invite=498920933

It's not an attachment -- it's stored online at Google Docs. To open this document, just click the link above.
---

实验六报告分析示例，大家需要掌握的是——如何利用wireshark和已有的TCP知识，对捕获的TCP Stream（逐个数据包）进行分析的方法。至于文中的分析内容则不一定完整和全部正确，望大家各抒己见！
特别感谢5081900301班的唐韬同学完成了实验六示例报告。

石家庄经济学院

《计算机网络原理》

实验报告

实验名称 TCP可靠性机制原理

班 级 5081090302

学 号 508109030137

姓 名 唐韬

指导教师 赵建立

1. 实验目的

理解TCP报文格式，理解TCP运输连接管理方法，理解TCP工作原理/标号确认机制/超市重传机制/拥塞控制机制，掌握利用网络协议分析器分析TCP数据包序列的方法。

2. 实验环境

每组配备如下：两台PC/windows OS, 局域网环境/Interner环境，应用服务器/客户端软件（如：FTP/HTTP或其他基于TCP的应用服务）。

3. 实验方法

   1. 安装协议分析器并启动进行捕包:

从网上下载协议分析器 wireshark然后将其解压，按照安装向导点击“Next”，完成安装。

2. 访问Web服务器:

在浏览器的地址栏键入命令“www.google.org”便可访问Web服务器。

3. 停止捕包并对捕获到的数据包进行分析:

当成功登录到服务器后，停止捕包，得到数据包。

4. 实验分析

使用协议分析器捕获数据包，对其中一个TCP数据流进行跟踪(follow TCP stream)得到信息如图1所示。

图1 follow TCP stream后的数据包

对18、19、20号报文进行分析，体现了连接建立时的三次握手（红色方框标记）。如图2所示。

图2连接建立三次握手

21号报文，192.168.0.32=>64.233.189.147，发送序号1，数据长度383，如图3所示。对方如果收到该报文，则应该反馈（依据：TCP数据编号确认机制）的确认序号：384。而观察第22号报文64.233.189.147=>192.168.0.32，发现确认序号确实是：384，如图4所示（红色方框标记），验证了以上的推测；且此报文为纯确认报文（即不携带数据，Len=0，只有TCP首部）。

图3 21号报文头主要字段

图4 22号报文

23号报文，64.233.189.147=>192.168.0.32，发送序号1，数据长度125，携带上次确认序号384，如图5所示。对方如果收到该报文，后反馈的确认序号：126，即25号报文， 192.168.0.32=>64.233.189.147，发送序号384，数据长度363，如图6所示（红色方框标记）。

图5 23号报文头主要字段

图6 25号报文头主要字段

26号报文，64.233.189.147=>192.168.0.32，发送序号126，对25号报文所发数据进行确认384+363=747，如图7所示（红色方框标记）。

图7 26号报文

21、22、23、25、26号报文体现出TCP编号确认机制原理。

27号报文，64.233.189.147=>192.168.0.32，指出有前面的TCP报文段丢失，本机接收到发送序号1855的报文段，暂时缓存下来【注；从26，25，23号报文可知——192.168.0.32已经接收了64.233.189.147发送的126之前的所有报文段，期望接收发送序号是126的报文段，但事与愿违——的确收到了来自64.233.189.147的报文段，不过是发送序号为1855的报文段，因此协议分析器提示：Previous Segment Lost。】，图8所示。

图8 27号报文头主要字段

28号报文，192.168.0.32=>64.233.189.147，发送序号747，确认序号126，对125以前的报文段进行了第一次重复确认【注：192.168.0.32收到了对方发送序号为1855的报文段，且最高报文编号1855+1430-1=3284，则其向对方发送确认信息时，确认序号为多少？3285抑或126？根据：TCP的累积确认机制】，如图9所示（红色方框标记）。由此得知，126~1854报文段没收到。

图9 28号报文

29号报文，64.233.189.147=>192.168.0.32，本机收到发送序号为425，数据长度1430的报文段，不是126报文段，暂时缓存下来，图10所示。

图10 29号报文头主要字段

30号报文，192.168.0.32=>64.233.189.147，发送序号747，确认序号126，对125以前的报文段进行了第二次重复确认，如图9所示（红色方框标记）。由此得知，126~424报文段没收到。

图11 30号报文

31号报文，64.233.189.147=>192.168.0.32，本机收到发送序号为3285，数据长度1236的报文段，不是126报文段，暂时缓存下来，图12所示。

图12 31号报文头主要字段

32号报文，192.168.0.32=>64.233.189.147，发送序号747，确认序号126，对125以前的报文段进行了第三次重复确认，如图13所示（红色方框标记）。由此得知，126~424报文段没收到。

图13 32号报文

33号报文，64.233.189.147=>192.168.0.32，本机收到发送序号为4521，数据长度为577的报文段，不是126报文段，暂时缓存下来，图14所示。

图14 33号报文头主要字段

34号报文，192.168.0.32=>64.233.189.147，发送序号747，确认序号126，对125以前的报文段进行了第四次重复确认，如图15所示（红色方框标记）。由此得知，126~424报文段没收到。

图15 34号报文

35号报文，64.233.189.147=>192.168.0.32，TCP对丢失的报文进行快速重传（TCP fast retransmission）发送序号126，数据长度299，即126~126+299=425报文段。如图16所示。快速重传是收到三个重复ACK即开始重传，此报文为收到第四个重复ACK开始的重传，原因可能为第四个重复ACK后发先至，即当第35号报文快速重传后，本机还未收到，就先收到第四个重复ACK。【注：如何看待4个（或大于4个）重复的ACK的现象？背后的机制，事情的真相到底如何？希望大家讨论！】

图16 35号报文头主要字段

27~35号报文体现重传机制原理。

流量控制机制体现在窗口大小的变化，发送窗口<=min（接收窗口，拥塞窗口），具体体现如图17所示（红色方框标记）。发送方为本机win=8192，接收方为服务器win=5720。

图17报文部分字段

5. 
   
   实验结论

通过观察TCP协议的通信过程，从传输层分析了一个【注：应该是多个】TCP会话的过程，归纳出：

1.编号确认机制的原理：对收到TCP数据报文段的最高序号加1，作为确认序号，向对方反馈，表示确认。

2.累积确认机制原理：当A接收到某确认序号为X的确认报文段时，表示对方B已正确接收完X确认序号以前所有的报文段，并期望接收A发送序号为X的报文段。

3. ……

4. ……