计算机网络实验ethereal

计算机网络实验ethereal

 直接复制粘贴自己的实验报告，所以没有截图，可自行做实验比对

在电脑的某处保存该文件

 

 

 

在窗口输入文件完整的路径

 

点击“ file”按钮，上传文件，上传成功后，会显示祝贺信息

 

 

 

抓包结果

 

在“Filter”窗口输入“TCP”

可以看到的是我的计算机和gaia.cs.umass.edu之间的一系列TCP和HTTP消息，包含SYN的初始三次握手信息，HTTP POST消息和一系列“HTTP延续”

消息从计算机发送到gaia.cs.umass.edu。

回想一下在之前的HTTP Ethereal实验的讨论中，这不是一个HTTP这样的

延续消息 - 这是Ethereal表示有多个TCP的方式段用于承载单个HTTP消息。 可以看到TCP ACK段从gaia.cs.umass.edu返回到我的计算机。

 

由于本实验是关于TCP而不是HTTP，所以我们来改变Ethereal的“捕获的列表数据包”窗口，以便它显示有关包含的TCP段的信息，而不是关于HTTP消息。 为了让Ethereal做到这一点，选择 分析 - >启用协议。 然后取消选中HTTP框，然后选择确定。 另外在这个实验我们想看到TCP的序列号（而不是相对序列号，

Ethereal可能会显示）。 要查看序列号，请转到

编辑>首选项>协议> IP，并取消选中“相对序列号”。 现在看到一个像Ethereal窗口一样：

 

 

 

 

 

 

TCP三次握手

第一次握手：客户机端的TCP向服务器端的TCP发送一个SYN报文段，seq=0。

第二次握手：一旦包含TCP SYN报文段的IP数据报到达服务器主机，服务器会从该数据报中提取出TCP SYN报文段，为该TCP连接分配TCP缓存和变量，并向客户机TCP发送允许连接的报文段，ack=1表示确认。

第三次握手：在收到SYNACK报文段后，客户机也要给该连接分配缓存和变量，客户机主机还会向服务器发送另外一个报文段，对服务器的允许连接的报文段进行确认，此时seq变为1，ack也为1。

 

 

 

 

1. What is the IP address and TCPport number used by your client computer

(source) to transfer the file togaia.cs.umass.edu? What is the IP address and port

number used by gaia.cs.umass.eduto receive the file.

 

 

 

 

 

 

 

如图所示

Client computer (source)

IP address: 192.168.1.102

TCP port number: 38392

 

Destination computer:gaia.cs.umass.edu

IP address: 128.119.245.12

TCP port number: 80

 

2. What is the sequence number ofthe TCP SYN segment that is used to initiate the

TCP connection between the clientcomputer and gaia.cs.umass.edu? What is it

in the segment that identifiesthe segment as a SYN segment?

如图所示

用于启动TCP客户端计算机与gaia.cs.umass.edu之间的TCP连接的TCP SYN段的序列号值为0。

 

SYN标志设置为1，表示该段为SYN段。

 

 

 

 

 

3. What is the sequence number ofthe SYNACK segment sent by gaia.cs.umass.edu

to the client computer in replyto the SYN? What is the value of the ACKnowledgement field in the SYNACKsegment? How did gaia.cs.umass.edu

determine that value? What is itin the segment that identifies the segment as a

SYNACK segment?

在此跟踪中从gaia.cs.umass.edu发出回复客户端计算机的SYN的SYNACK段的序列号的的值为0。

在SYNACK段中的确认字段的值为1。

该值SYNACK段中的确认字段由gaia.cs.umass.edu确定，通过将来自客户端计算机的SYN段的初始序列号加1来实现。（由客户端计算机启动的SYN段的序列号为0）

 

4. What is the sequence number ofthe TCP segment containing the HTTP POST

command? Note that in order tofind the POST command, you’ll need to dig into

the packet content field at thebottom of the Ethereal window, looking for a

segment with a “POST” within itsDATA field.

如图所示，19号段是包含HTTP POST命令的TCP段。此段的序号为1。

 

 

5. Consider the TCP segmentcontaining the HTTP POST as the first segment in the

TCP connection. What are thesequence numbers of the first six segments in the

TCP connection (including thesegment containing the HTTP POST)? At what

time was each segment sent? Whenwas the ACK for each segment received?

Given the difference between wheneach TCP segment was sent, and when its

acknowledgement was received,what is the RTT value for each of the six

segments? What is the EstimatedRTT value (see page 237 in text)after the

receipt of each ACK? Assume thatthe value of the EstimatedRTT is equal to

the measured RTT for the firstsegment, and then is computed using the

EstimatedRTT equation on page 237 for all subsequent segments.

Note: Ethereal has a nice feature that allows you to plot theRTT for each

of the TCP segments sent. Selecta TCP segment in the “listing of

captured packets” window that isbeing sent from the client to the

gaia.cs.umass.edu server. Thenselect: Statistics->TCP Stream Graph-

>Round Trip Time Graph.

 

HTTP POST段

 

 

ACK段

 

如图所示

HTTP POST段被认为是第一个段。

细分1 - 6分别是第4号,5号,7号,8号，10号，11号。

ACK段1-6分别是6号，9号，12号，14号，15号和16号。

 

Segment 1 sequence number: 1

Segment 2 sequence number: 566

Segment 3 sequence number: 2026

Segment 4 sequence number: 3486

Segment 5 sequence number: 4946

Segment 6 sequence number: 6406

 

 

 

 

 

ACK的发送时间和接收时间如下表所示。

	Send Time	ACK received time	RTT(seconds)
Segment 1	0.026477	0.053937	0.02746
Segment 2	0.041737	0.077294	0.035557
Segment 3	0.054026	0.124085	0.070059
Segment 4	0.054690	0.169118	0.11443
Segment 5	0.077405	0.217299	0.13989
Segment 6	0.078157	0.267802	0.18964

 

 

 

Estimated RTT = 0.875 * Estimated RTT + 0.125 * Sample RTT

 

Estimated RTT after the receipt of the ACK of segment 1:

Estimated RTT = RTT for Segment 1 = 0.02746 seconds

 

Estimated RTT after the receipt of the ACK of segment 2:

Estimated RTT = 0.875 * 0.02746 + 0.125 * 0.035557 =0.0285 seconds

 

Estimated RTT after the receipt of the ACK of segment 3:

Estimated RTT = 0.875 * 0.0285 + 0.125 * 0.070059 =0.0337 seconds

 

Estimated RTT after the receipt of the ACK of segment 4:

Estimated RTT = 0.875 * 0.0337+ 0.125 * 0.11443 = 0.0438 seconds

 

Estimated RTT after the receipt of the ACK of segment 5:

Estimated RTT = 0.875 * 0.0438 + 0.125 * 0.13989 = 0.0558seconds

 

Estimated RTT after the receipt of the ACK of segment 6:

Estimated RTT = 0.875 * 0.0558 + 0.125 * 0.18964 = 0.0725seconds

 

 

 

6. What is the length of each of the first six TCPsegments?

 

如图所示，第一个TCP段的长度（包含HTTP POST）：565个字节

其他五个TCP段的长度：1460字节（MSS）

 

7. What is the minimum amount ofavailable buffer space advertised at the received

for the entire trace? Does thelack of receiver buffer space ever throttle the

sender?

 

如图所示，在gaia.cs.umass.edu的整个跟踪中缓冲区空间（接收窗口）最小量为5840字节，显示在第一个来自服务器的确认。 该接收器窗口稳定增长直到接收缓冲区最大值为62780字节。通过检查此跟踪，由于发送方的数据包一直小于接收缓冲区空间，发送方不会收到限制。

 

 

8. Are there any retransmittedsegments in the trace file? What did you check for (in

the trace) in order to answerthis question?

没有重传的段，经过检查可以知道在数据包列表区没有发现冗余ACK，并且发送的序列号也没有重复的，所以可以判断没有重传的TCP段。

 

 

 

 

 

 

 

 

 

 

 

9. How much data does thereceiver typically acknowledge in an ACK? Can you

identify cases where the receiveris ACKing every other received segment (see

Table 3.2 on page 245 in thetext).

 

如图所示

 

 

ACK的确认序列号如下所示

	Acknowledged Sequence Number	Acknowledged Data
ACK 1	566	565
ACK 2	2026	1460
ACK 3	3486	1460
ACK 4	4946	1460
ACK 5	6406	1460
ACK 6	7866	1460
ACK 7	9013	1147
ACK 8	10473	1460
ACK 9	11933	1460
ACK 10	13393	1460
ACK 11	14853	1460
ACK 12	16313	1460

……

可知，典型确认为1460字节

 

 

累积ACKs（No.80 No.87 No.88等）接收方正在ACK其他接收段

 

如图所示，129541-126621=2920=1460*2

 

 

10. What is the throughput (bytestransferred per unit time) for the TCP connection?

Explain how you calculated this value.

 

如图所示，TCP吞吐量的计算在很大程度上取决于所选择内容的平均时间。在这个问题中，我们选择整个连接时间作为平均时间段。然后，平均吞吐量为该TCP总传输数据和总传输时间之间的比值。

传输的数据总量可以通过差值来计算，在第一个TCP段的序列号（即4号段的1个字节）之间和最后一个ACK的确认序列号（对于202的164091个字节）

因此，总数据为164091-1 = 164090字节。

整体传输时间是第一TCP片段的时刻（即No.4段为0.026477秒）和最后ACK的时刻（即No.202为5.455830秒 ）之间的差值。

因此，总传输时间为5.455830 - 0.026477 =5.4294秒。

计算TCP连接的吞吐量为164090 / 5.4294 = 30.222千字节/秒。

 

 

 

11. Use the Time-Sequence-Graph(Stevens)plotting tool to view the sequence

number versus time plot ofsegments being sent from the client to the

gaia.cs.umass.edu server. Can youidentify where TCP’s slowstart phase begins

and ends, and where congestionavoidance takes over? Note that in this “realworld”

trace, not everything is quite asneat and clean as in Figure 3.51 (also note

that the y-axis labels for the Time-Sequence-Graph(Stevens)plotting tool and

Figure 3.51 are different).

 

 

慢启动阶段即从HTTP POST 报文段发出时开始，但是无法判断什么时候慢启动结束，拥塞避免阶段开始。

慢启动阶段和拥塞避免阶段的鉴定取决于发送方拥塞窗口的大小。拥塞窗口的大小并不能从时间—序号图（time-sequence-graph）直接获得。

然而在一个发送方中未被确认的数据量不会超过拥塞窗口接收窗口中的最小值，即LastByteSend-LastByteAcked≤min{CongWin,RcvWindow}。

同时，在第9题中看到，接收方通告给发送方的窗口大小并没有遏制发送速率。因此，未被确认的数据量，是由拥塞窗口决定的，所以通过发出而未被确认的数据量，我们可以估计拥塞窗口大小的下界。 

下表列出了部分in flight 数据量，从表中可以看出拥塞窗口的下界小于等于8192(因为in flight data 从未超过8192)。

但是，从第10题（即从时间—序号图）得，没有分组丢失（不管是超时，还是三个冗余ACK），因此无法判断什么时候慢启动结束，拥塞避免阶段开始。

 

 

 

 

 

 

 

Type	No.	Seq.	ACKed Seq.	Outstanding Data
Data	4	1		565
Data	5	566		2025
ACK	6		566	1460
Data	7	2026		2920
Data	8	3486		4380
ACK	9		2026	2920
Data	10	4946		4380
Data	11	6406		5840
ACK	12		3486	4380
Data	13	7866		5527
ACK	14		4096	4917
ACK	15		6006	3007
ACK	16		7866	1147
ACK	17		9013	0
Data	18	9013		1460
Data	19	10473		2920
Data	20	11933		4380
Data	21	13393		5840
Data	22	14853		7300
Data	23	16313		8192
ACK	24		10473	6732
ACK	25		11933	5272
ACK	26		13393	3812
ACK	27		14853	2352
ACK	28		16313	892
ACK	29		17205	0

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

12. Comment on ways in which themeasured data differs from the idealized behavior

of TCP that we’ve studied in the text.

 

在本实验中TCP的理想化行为是假定TCP发件人积极地发送数据。流量过多可能使网络拥塞; 因此，TCP发送者应遵循AIMD算法（加性增乘性减），以便在发现网络拥塞时（即分组丢失），它们的发送窗口大小减少。

在实践中，TCP行为也在很大程度上取决于应用程序。 在这个例子中，当TCP发送者可以发送数据，没有数据可用于传输。 在Web应用程序中，一些Web对象非常小。 所以在慢启动阶段结束之前，传输就已经结束 因此，由于TCP的启动阶段缓慢，这些小型Web对象的传输受到不必要的长时间延迟的损失。