内容发布更新时间 : 2024/5/17 19:05:02星期一 下面是文章的全部内容请认真阅读。

图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之间的时间，我们就大

31

约计算出和由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不提供可靠的数据传

32

输，因此并不要求什么数据已经被成功接收的信息。它也不提供任何信息高速发送端降低速率，因为接收端或者网络本身已经淹没。

虽然UDP本身并不提供接收端到发送端的反馈，但是我们确实看到几个从接收端到发送端的ICMP分组（分组12—14）。ICMP是网络层协议（IP）的一个伴随协议，并且有提供一定控制和错误报告的功能。在这种情况下，ICMP分组暗示一些UDP数据报没有被传送到，因为端口不可达。这就意味着当数据报到达那个端口的时候，没有接收端在那个端口监听。我们注意到ICMP分组携带着一些未传递UDP数据报的信息。

当ttcp接收端看到一个只具有4个字节数据的特殊数据报时，它便会知道数据传输是完整的，并且会因此关闭正在监听的端口。事实上ttcp发送端发送5个这样的分组，并且后面的分组到达的时候发现接收端已经没有在监听了。当发送端发送所有的数据而没有相应的接收标志的时候，将会看到相似的行为。

TCP和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﹪。在这个开销中都包括什么？如果没有重传，这个开销是多少？

33

实验七 利用Wireshark分析协议HTTP

一、实验目的

分析HTTP协议 二、实验环境

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

1、利用Wireshark俘获HTTP分组

（1）在进行跟踪之前，我们首先清空Web 浏览器的高速缓存来确保Web网页是从网络中获取的，而不是从高速缓冲中取得的。之后，还要在客户端清空DNS高速缓存，来确保Web服务器域名到IP地址的映射是从网络中请求。在WindowsXP机器上，可在命令提示行输入ipconfig/flushdns完成操作。

（2）启动Wireshrk 分组俘获器。

（3）在Web 浏览器中输入：http://www.google.com （4）停止分组俘获。

图1 利用Wireshark俘获的HTTP分组

34

在URL http://www.google.com中，www.google.com 是一个具体的web 服务器的域名。最前面有两个DNS分组。第一个分组是将域名www.google.com转换成为对应的IP 地址的请求，第二个分组包含了转换的结果。这个转换是必要的，因为网络层协议——IP协议，是通过点分十进制来表示因特网主机的，而不是通过www.google.com这样的域名。当输入URL http：//www.google.com时，将要求Web服务器从主机www.google.com上请求数据，但首先Web浏览器必须确定这个主机的IP地址。

随着转换的完成，Web浏览器与Web服务器建立一个TCP连接。最后，Web 浏览器使用已建立好的TCP连接来发送请求“GET/HTTP/1.1”。这个分组描述了要求的行为（“GET”）及文件（只写“/”是因为我们没有指定额外的文件名），还有所用到的协议的版本（“HTTP/1.1”）。

2、HTTP GET/response交互

（1）在协议框中，选择“GET/HTTP/1.1” 所在的分组会看到这个基本请求行后跟随着一系列额外的请求首部。在首部后的“\\r\\n”表示一个回车和换行，以此将该首部与下一个首部隔开。

“Host”首部在HTTP1.1版本中是必须的，它描述了URL中机器的域名，本例中是www.google.com。这就允许了一个Web服务器在同一时间支持许多不同的域名。有了这个数不，Web服务器就可以区别客户试图连接哪一个Web服务器，并对每个客户响应不同的内容，这就是HTTP1.0到1.1版本的主要变化。

User-Agent首部描述了提出请求的Web浏览器及客户机器。

接下来是一系列的Accpet首部，包括Accept（接受）、Accept-Language（接受语言）、Accept-Encoding（接受编码）、Accept-Charset（接受字符集）。它们告诉Web服务器客户Web浏览器准备处理的数据类型。Web服务器可以将数据转变为不同的语言和格式。这些首部表明了客户的能力和偏好。

Keep-Alive及Connection首部描述了有关TCP连接的信息，通过此连接发送HTTP请求和响应。它表明在发送请求之后连接是否保持活动状态及保持多久。大多数HTTP1.1连接是持久的（persistent）,意思是在每次请求后不关闭TCP连接，而是保持该连接以接受从同一台服务器发来的多个请求。

（2）我们已经察看了由Web浏览器发送的请求，现在我们来观察Web服务器的回答。响应首先发送“HTTP/1.1 200 ok”，指明它开始使用HTTP1.1版本来发送网页。同样，在响应分组中，它后面也跟随着一些首部。最后，被请求的实际数据被发送。

35