内容发布更新时间 : 2024/12/25 1:13:40星期一 下面是文章的全部内容请认真阅读。

实验六 使用Wireshark分析UDP

一、实验目的

比较TCP和UDP协议的不同 二、实验环境

与因特网连接的计算机，操作系统为Windows，安装有Wireshark、IE等软件。 三、实验步骤

1、打开两次TCP流的有关跟踪记录，保存在tcp_2transmit.cap中，并打开两次UDP流中的有关跟踪文件udp_2transmit.cap 。如图所示：

图1：TCP 流跟踪记录

图2：UDP流跟踪记录

2、分析此数据包：

（1）TCP传输的正常数据：

tcp_2transmit.cap文件的分组1到13中显示了TCP连接。这个流中的大部分信息与前面的实验相同。我们在分组1到分组3中看到了打开连接的三次握手。分组10到分组13显示的则是连接的终止。我们看到分组10既是一个带有FIN标志的请求终止连接的分组，又是一个最后1080个字节的（序号是3921—5000）的重传。

TCP将应用程序写入合并到一个字节流中。它并不会尝试维持原有应用程序写人的边界值。我们注意到TCP并不会在单个分组中传送1000字节的应用程序写入。前1000个字节会在分组4种被发送，而分组5则包含了1460个字节的数据-----一些来自第二个缓冲区，而另一些来自第三个缓冲区。分组7中含有1460个字节而分组8中则包含剩余的1080个字节。（5000-1000-1460-1460=1080）

我们注意到实际报告上的2.48秒是从初始化连接的分组1开始到关闭连接的分组10结束。分组11—13未必要计入接收端应用程序的时间内，因为一旦接收到第一个FIN，TCP层便马上发送一个关闭连接的信号。分组11—13只可能由每台计算机操作系统得TCP层后台传输。

如果我们注意到第一个包含数据的分组4和最后一个分组8之间的时间，我们就大

约计算出和由UDP接收端所报告的0.01秒相同的时间。这样的话，增加TCP传输时间的主要原因就是分组10中的重传。公平的说，UDP是幸运的，因为它所有的分组都在第一时间被接受了。

在这个跟踪文件中，另一个值得注意的是没有包含数据的分组的数量。所有来自接收端的分组和几个来自发送端的分组只包含了TCP报文段的首部。总的来说（包括重传）一共发送了6822个字节来支持5000个字节的数据传输。这个开销正好36﹪。

(2)UDP正常数据传输

现在我们来观察UDP流，在udp _transmit.cap文件的分组1到分组11中显示。虽然像TCP流那样传输了相同的数据，但是在这个跟踪文件中还是很多的不同。

和TCP不同，UDP是一个无连接的传输协议。TCP用SYN分组和SYN ACK分组来显示地打开一个连接，而UDP却直接开始发送包含数据的分组。同样，TCP用FIN分组和FIN ACK分组来显示地关闭一个连接，而UDP却只简单地停止包含数据的分组的传输。

为了解决这个问题，在文件udp_2transmit.cap俘获的分组中，采取的办法是ttcp发送端发送一个只包含4个字节的特殊UDP 数据报来模拟连接建立和连接终止。在发送任何数据之前，发送端总是发送一个只包含4个字节的特殊数据报（分组1），而在发送完所有的数据之后，发送端又发送额外的5个分组（分组7-11）。

接收端也使用第一个特殊的数据报来启动数据传输的计时器。如果这个特殊的数据报丢失了，它可能用真实数据的第一个分组计时器。不过，如果接收端没有看到这个特殊的数据报，它就不能精确地确定数据传输的开始和传输的所有时间。与TCP不同，UDP 在传输的数据中，不会加上序号，因此对于接收端来说不可能确定丢失和重排序重传的情况。

类似的，接收端根据最后的特殊数据报来停止数据传输计时器。当接收端接收到这5个包中的任一个便停止计时，但是发送5个分组是因为在传输的过程中可能丢失其中的一些。如果5个分组全部丢失了，那么接收端便会无限制的等待更多数据的到来达。

实际数据的传输是在分组2-6里。每一个分组都包含1000个字节。1000个字节的应用程学写入直接转换成UDP数据报。另一方面，TCP并不打算保存应用程序写入边界而只是将它们并入一个字节流中。

与TCP不同，UDP没有提供接收端到发送端的反馈。在TCP的例子里，接收端返回只包含有TCP报文段首部而没有数据的报文段。首部本身则携带着关于哪些数据已经被成功接收以及接收端能够接收多少数据的信息。我们已经知道UDP不提供可靠的数据传