实验三-捕获TCP数据包-杨磊.docx

计算机网络与应用实验
实验三 捕获TCP数据包
自94班 杨磊 2009011451
实验目的
通过实验熟悉Wireshark抓包软件的使用方法，理解TCP传输过程，以及慢启动、拥塞避免等相关技术。
实验环境
1. 操作系统：Windows7 网络环境为紫荆2#527A
2. 所用软件：wireshark-win32-1.6.3（最新版）
实验内容
1. 在windows环境进行Wireshark抓包。
2. 在windows环境Wireshark窗口中查看各种协议下的数据包。
3. 在windows环境上传文件到服务器，同时观察TCP传输过程。
实验记录与问题解答
回答以下有关TCP 报文段的问题：
1． 你的客户端电脑传送文件到166.111.180.98的IP地址和端口是什么？从166.111.180.98接收文件的IP地址和端口是什么？
答：建立连接的前两条报文如下：
15 1.656371 59.66.135.82 166.111.180.98 TCP 66 aura > http-alt [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=4 SACK_PERM=1
{
Transmission Control Protocol, Src Port: aura (2066), Dst Port: http-alt (8080), Seq:
0, Len: 0)
}
可见，客户端电脑传送文件到166.111.180.98 的IP 地址是59.66.135.82，
端口是2066，166.111.180.98 接收文件的IP 地址是166.111.180.98，端口是8080。
2． 用来初始化客户端电脑和166.111.180.98的TCP连接的TCP SYN报文段的序号是什么？在报文段中，那个地方表明这是一个SYN报文段？
答：报文如下（同上一报文）
15 1.656371 59.66.135.82 166.111.180.98 TCP 66 aura > http-alt [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=4 SACK_PERM=1
{
Sequence number: 0 (relative sequence number)
Flags: 0x02 (SYN)
}
可见初始化这个报文段的序号是0,Flags字段中SYN位为1，表明了这是一个SYN报文段。
3． 回复SYN报文段时，由166.111.180.98发送的SYNACK报文段的序号是什么？在SYNACK报文段中的ACKnowledgement域的值是什么？166.111.180.98是如何确定这个值的？表明这个段是SYNACK的标志位或者符号是什么？
答：报文如下：
16 1.657163 166.111.180.98 59.66.135.82 TCP 66 http-alt > aura [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460 WS=1 SACK_PERM=1
{
Sequence number: 0 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Flags: 0x12 (SYN, ACK)
}
SYNACK 序号是0，ACK 值为1，其等于SYN 报文段中Seq 值加1，标志位是Flags = 0x12。
4． 包含HTTP POST命令的TCP段的序号是多少？注意，要找到POST命令，你需要在Wireshark窗口的底部发掘这个数据包内容域，找到一个在其DATA域中有标识POST的段。
答：报文如下：
19 1.657804 59.66.135.82 166.111.180.98 TCP 517 aura > http-alt [PSH, ACK] Seq=1 Ack=1 Win=65700 Len=463
{
Sequence number: 1 (relative sequence number)
Next sequence number: 464 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x18 (PSH, ACK)
Data: 504f5354202f75706c6f61642f75706c6f6164746f66696c...
Length: 463
0000 00 01 e8 13 4b a9 00 24 e8 f5 a9 b3 08 00 45 00 ....K..$ ......E.
0010 01 f7 75 eb 40 00 80 06 65 af 3b 42 87 52 a6 6f ..u.@... e.;B.R.o
0020 b4 62 08 12 1f 90 90 56 a3 11 01 e7 35 8c 50 18 .b.....V ....5.P.
0030 40 29 41 70 00 00 50 4f 53 54 20 2f 75 70 6c 6f @)Ap..PO ST /uplo
0040 61 64 2f 75 70 6c 6f 61 64 74 6f 66 69 6c 65 73 ad/uploa dtofiles
0050 65 72 76 65 72 20 48 54 54 50 2f 31 2e 31 0d 0a erver HT TP/1.1..
…………
}
可见，上述包含POST命令的TCP报文段的序号是1。
5． 仔细思考一下作为TCP连接的第一个报文段的包含HTTP POST的TCP报文段。TCP连接（包括包含HTTP POST的报文段）的开头6个报文段的序号是多少？每个报文段都在什么时间发送？每个报文段接收到ACK的时间是多少？假定每个TCP报文段发送事件和收到其确认信息的事件之间存在时间差，那么这6个报文段各自的RTT值是多少？接收到每个ACK之后的EstimatedRTT数值是多少？（参见课本237页）假设第一个报文段的EstimatedRTT值等于其观测到的RTT值，后续报文段的EstimatedRTT均按课本237页方程计算。
注意：Wireshark有一个很好的功能，它允许你画出发送的每一个TCP段的RTT。选择一个在“listing of the captured packets”窗口中的TCP段，此TCP正在从客户端到166.111.180.136，然后选择：Statistics->TCP Stream Graph->Round Trip Time Graph。

答：文件传输开始的6个报文段时间如下表格所示：
Sequence number
发送时间
Ack接收时间
RTT
EstimatedRTT
1
1.657804
1.659676
0.003072
0.003072
464
1.658386
1.661409
0.003023
0.00324512
1924
1.659734
1.663050
0.003316
0.00322398
3384
1.659762
1.663237
0.003475
0.00320036
4844
1.659784
1.664084
0.0043
0.00317481
6304
1.661473
1.665055
0.003582
0.00305408
下面是利用Wireshark做出的RTT变化图：

每个报文相关数据如下：
19 1.657804 59.66.135.82 166.111.180.98 TCP 517 aura > http-alt [PSH, ACK] Seq=1 Ack=1 Win=65700 Len=463
{
Sequence number: 1 (relative sequence number)
Next sequence number: 464 (relative sequence number)
Flags: 0x18 (PSH, ACK)
Window size value: 16425
Checksum: 0x4170 [validation disabled]
Data (463 bytes)
}
22 1.658386 59.66.135.82 166.111.180.98 TCP 1514 aura > http-alt [ACK] Seq=464 Ack=1 Win=65700 Len=1460
{
Sequence number: 464 (relative sequence number)
Next sequence number: 1924 (relative sequence number)
Flags: 0x10 (ACK)
Window size value: 16425
Checksum: 0x828f [validation disabled]
Data (1460 bytes)
}
24 1.659734 59.66.135.82 166.111.180.98 TCP 1514 aura > http-alt [ACK] Seq=1924 Ack=1 Win=65700 Len=1460
{
Sequence number: 1924 (relative sequence number)
Next sequence number: 3384 (relative sequence number)
Flags: 0x10 (ACK)
Window size value: 16425
Checksum: 0x17a1 [validation disabled]
Data (1460 bytes)
}
25 1.659762 59.66.135.82 166.111.180.98 TCP 1514 aura > http-alt [ACK] Seq=3384 Ack=1 Win=65700 Len=1460
{
Sequence number: 3384 (relative sequence number)
Next sequence number: 4844 (relative sequence number)
Flags: 0x10 (ACK)
Window size value: 16425
Checksum: 0x1f3b [validation disabled]
Data (1460 bytes)
}
26 1.659784 59.66.135.82 166.111.180.98 TCP 1514 aura > http-alt [ACK] Seq=4844 Ack=1 Win=65700 Len=1460
{
Sequence number: 4844 (relative sequence number)
Next sequence number: 6304 (relative sequence number)
Flags: 0x10 (ACK)
Window size value: 16425
Checksum: 0x8443 [validation disabled]
Data (1460 bytes)
}
28 1.661473 59.66.135.82 166.111.180.98 TCP 1514 aura > http-alt [ACK] Seq=6304 Ack=1 Win=65700 Len=1460
{
Sequence number: 6304 (relative sequence number)
Next sequence number: 7764 (relative sequence number)
Flags: 0x10 (ACK)
Window size value: 16425
Checksum: 0x2ee7 [validation disabled]
Data (1460 bytes)
}
对应的ack报文如下：
23 1.659676 166.111.180.98 59.66.135.82 TCP 60 http-alt > aura [ACK] Seq=1 Ack=1924 Win=65535 Len=0
{
Sequence number: 1 (relative sequence number)
Acknowledgement number: 1924 (relative ack number)
Window size value: 65535
Calculated window size: 65535
}
27 1.661409 166.111.180.98 59.66.135.82 TCP 60 http-alt > aura [ACK] Seq=1 Ack=4844 Win=65251 Len=0
{
Sequence number: 1 (relative sequence number)
Acknowledgement number: 4844 (relative ack number)
Window size value: 65251
Calculated window size: 65251
}
33 1.663050 166.111.180.98 59.66.135.82 TCP 60 http-alt > aura [ACK] Seq=1 Ack=7764 Win=65535 Len=0
{
Sequence number: 1 (relative sequence number)
Acknowledgement number: 7764 (relative ack number)
Window size value: 65535
Calculated window size: 65535
}
38 1.663237 166.111.180.98 59.66.135.82 TCP 60 http-alt > aura [ACK] Seq=1 Ack=10684 Win=65251 Len=0
{
Sequence number: 1 (relative sequence number)
Acknowledgement number: 10684 (relative ack number)
Window size value: 65251
Calculated window size: 65251
}
44 1.664084 166.111.180.98 59.66.135.82 TCP 60 http-alt > aura [ACK] Seq=1 Ack=13604 Win=65535 Len=0
{
Sequence number: 1 (relative sequence number)
Acknowledgement number: 13604 (relative ack number)
Window size value: 65535
Calculated window size: 65535
}
49 1.665055 166.111.180.98 59.66.135.82 TCP 60 http-alt > aura [ACK] Seq=1 Ack=15064 Win=65535 Len=0
{
Sequence number: 1 (relative sequence number)
Acknowledgement number: 15064 (relative ack number)
Window size value: 65535
Calculated window size: 65535
}
6． 开始的6个TCP报文段的长度各自是多少？
答：从上面的报文段可知，这六个报文段的长度分别是：483（463+20） bytes、1480bytes、1480bytes、1480bytes、1480bytes、1480bytes。
7． 在整个跟踪过程中，在接收端广告（advertise）的可用缓存空间的最小值是多少？接收端有没有因缓存空间不足而限制发送端的发送？
答：在6个ack报文中可以看出，接收端窗口的最小为65251，因此接收端广告的可用缓存空间最小值为64087。发送端窗口一直是16425，小于接收端窗口并保持恒定，因此没有收到这个限制。
8． 在跟踪文件中，有重传的报文段么？回答这个问题，你需要检查哪个地方？
答：在此次跟踪中没有发现重传的报文段。只需要检查客户机发出报文段的sequence number字段即可，如果有重复的sequence number，则证明发生了相同数据的重传。
9． 接收方在一个ACK中，通常确认多少数据？你能辨别出这样一种情形吗：即接收方对收到的报文段，每隔一个确认一次？（参考 教材245页的Table3.2）
答：：接收方在一个ACK 中通常确认1 -2 个报文段数据。
利用Flow Graph 功能，查看相应的发送和ack情况，其中一部分统计如下：

可以看出在这次跟踪过程中通常是每个ACK确认一个报文段。
10． 这个TCP连接的吞吐量（每单位时间传输的字节数）是多少？解释你是如何计算这个数值的？
答：在上传整个文件的过层中，第一个报文段的序号是1，时间是1.657804s，最后一个报文段的序号是152935，时间是1.671106s，这个过程的平均吞吐量为：
152935÷1.671106-1.657804=11497143Bps=1.1MB/s
TCP拥塞控制
回答下面的问题：
11． 用Time-Sequence-Graph(Stevens)中的画图工具观察从客户端发送到166.111.180.98服务器的TCP段的序列号－时间图。你怎样判断TCP的慢启动(slowstart)开始和结束？拥塞避免在什么地方开始起作用的？注意在实际的跟踪中，不是所有的都像教材Figure 3.51那样简单漂亮的形式。同时还要注意在Time-Sequence-Graph(Stevens)中纵坐标所代表的变量与Figure 3.51中是不同的。
总结这次实验中所得到的TCP数据与我们在教材中所学的理想情况有什么不同？
答：TCP 段的序列号-时间图：

对于慢启动过程的特征是发送端的Congestion window 值指数增长。上面的图像中，开头一段发送的报文段数量为1，2，4，6，可以判断前三轮为慢启动；第四轮及以后的发送过程中，发送的数量稳定在一个较稳定的程度，可以大致判断拥塞避免在此时起作用。
不同之处：
（1） 发送过程整体较为稳定，没有出现数据的重传现象。
（2） 基本是每一个ACK确认一个报文段，而不是2个3个居多。
（3） 发送速度较快，没有发现明显的拥塞控制和报文段中的窗口大小变化情况。可能的原因有3个：一是发送的txt文件较小；二是发送在校内的局域网内进行，距离较短，发送速度快；三事在上午的时间段内上网用户较少，没有出现严重的拥塞现象。