《使用Wireshark分析UDP.pdf》由会员分享，可在线阅读，更多相关《使用Wireshark分析UDP.pdf（4页珍藏版）》请在三一文库上搜索。
1、实验六使用 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 连接。 这个流中的大
2、部分信息与 前面的实验相同。我们在分组1 到分组 3 中看到了打开连接的三次握手。分组10 到分 组 13 显示的则是连接的终止。 我们看到分组 10既是一个带有 FIN 标志的请求终止连接 的分组，又是一个最后1080 个字节的（序号是 39215000）的重传。 TCP 将应用程序写入合并到一个字节流中。它并不会尝试维持原有应用程序写人的 边界值。我们注意到 TCP 并不会在单个分组中传送1000字节的应用程序写入。 前 1000 个字节会在分组 4 种被发送，而分组 5 则包含了 1460个字节的数据 -一些来自第二个 缓冲区，而另一些来自第三个缓冲区。分组7 中含有 1460 个字节而
3、分组 8 中则包含剩 余的 1080 个字节。 （5000-1000-1460-1460=1080 ） 我们注意到实际报告上的2.48 秒是从初始化连接的分组1 开始到关闭连接的分组 10结束。 分组 1113未必要计入接收端应用程序的时间内， 因为一旦接收到第一个FIN， TCP 层便马上发送一个关闭连接的信号。分组1113 只可能由每台计算机操作系统得 TCP 层后台传输。 如果我们注意到第一个包含数据的分组4 和最后一个分组 8 之间的时间，我们就大 约计算出和由 UDP 接收端所报告的 0.01秒相同的时间。 这样的话， 增加 TCP传输时间 的主要原因就是分组10 中的重传。公平的说
4、， UDP 是幸运的，因为它所有的分组都在 第一时间被接受了。 在这个跟踪文件中，另一个值得注意的是没有包含数据的分组的数量。所有来自接 收端的分组和几个来自发送端的分组只包含了TCP 报文段的首部。总的来说（包括重 传）一共发送了 6822 个字节来支持 5000 个字节的数据传输。这个开销正好36。 (2)UDP正常数据传输 现在我们来观察 UDP流，在 udp _transmit.cap文件的分组 1 到分组 11 中显示。 虽然像 TCP流那样传输了相同的数据，但是在这个跟踪文件中还是很多的不同。 和 TCP不同， UDP是一个无连接的传输协议。TCP用 SYN分组和 SYN ACK
5、分组来显 示地打开一个连接，而UDP 却直接开始发送包含数据的分组。同样，TCP用 FIN 分组和 FIN ACK分组来显示地关闭一个连接，而UDP 却只简单地停止包含数据的分组的传输。 为了解决这个问题， 在文件 udp_2transmit.cap俘获的分组中， 采取的办法是 ttcp 发送端发送一个只包含4 个字节的特殊 UDP 数据报来模拟连接建立和连接终止。 在发送 任何数据之前， 发送端总是发送一个只包含4 个字节的特殊数据报 （分组 1） ，而在发送 完所有的数据之后，发送端又发送额外的5 个分组（分组 7-11） 。 接收端也使用第一个特殊的数据报来启动数据传输的计时器。如果这个
6、特殊的数据 报丢失了，它可能用真实数据的第一个分组计时器。不过，如果接收端没有看到这个特 殊的数据报， 它就不能精确地确定数据传输的开始和传输的所有时间。与 TCP不同，UDP 在传输的数据中，不会加上序号，因此对于接收端来说不可能确定丢失和重排序重传的 情况。 类似的，接收端根据最后的特殊数据报来停止数据传输计时器。当接收端接收到这 5 个包中的任一个便停止计时，但是发送5 个分组是因为在传输的过程中可能丢失其中 的一些。如果 5 个分组全部丢失了，那么接收端便会无限制的等待更多数据的到来达。 实际数据的传输是在分组2-6 里。每一个分组都包含1000 个字节。 1000个字节的 应用程学写
7、入直接转换成UDP 数据报。另一方面， TCP并不打算保存应用程序写入边界 而只是将它们并入一个字节流中。 与 TCP不同， UDP 没有提供接收端到发送端的反馈。在TCP的例子里，接收端返回 只包含有 TCP报文段首部而没有数据的报文段。首部本身则携带着关于哪些数据已经被 成功接收以及接收端能够接收多少数据的信息。我们已经知道 UDP 不提供可靠的数据传 输，因此并不要求什么数据已经被成功接收的信息。它也不提供任何信息高速发送端降 低速率，因为接收端或者网络本身已经淹没。 虽然 UDP 本身并不提供接收端到发送端的反馈，但是我们确实看到几个从接收端到 发送端的 ICMP分组（分组 1214）
8、 。ICMP是网络层协议（ IP）的一个伴随协议，并且 有提供一定控制和错误报告的功能。在这种情况下， ICMP分组暗示一些 UDP 数据报没有 被传送到，因为端口不可达。这就意味着当数据报到达那个端口的时候，没有接收端在 那个端口监听。我们注意到ICMP分组携带着一些未传递UDP 数据报的信息。 当 ttcp接收端看到一个只具有4 个字节数据的特殊数据报时，它便会知道数据传 输是完整的，并且会因此关闭正在监听的端口。事实上ttcp发送端发送 5 个这样的分 组，并且后面的分组到达的时候发现接收端已经没有在监听了。当发送端发送所有的数 据而没有相应的接收标志的时候，将会看到相似的行为。 TCP
9、和 UDP 的另外一个不同之处在于TCP连接时点对点的，换句话说，TCP的使用 是在一个连接端和一个发送端之间的。而对于UDP 来说，一个发送端可能发向多个接收 端（例如广播和组播通信）或者多个发送端能够发送给一个接收端。如果多个发送端都 发给这个接收端的话，这个接收端会为每个发送端报告统计信息。 TCP和 UDP 的最后一个不同之处是它们首部的大小。UDP首部总是 8 个字节，而 TCP 首部大小是变化的，但是它绝对不会少于20 个字节。这也就是说传输5000个字节的实 际数据 TCP的开销是 36。 四、实验报告 回答下面的问题： 1、在 udp_2transmit.cap中观察 DUP首部。长度字段是包括首部和数据还是只包 括数据？ 2、我们观察到使用 ICMP报文来报告 UDP 数据报不可达。为什么TCP不用这个来指 示丢失的报文段呢？ 3、我们计算 TCP成功传输 5000 个字节的实际数据的开销是36。在这个开销中都 包括什么？如果没有重传，这个开销是多少？