计算机网络Reports3.docx
《计算机网络Reports3.docx》由会员分享，可在线阅读，更多相关《计算机网络Reports3.docx（18页珍藏版）》请在冰豆网上搜索。
计算机网络Reports3
计算机网络
第三章
DIY！
now
电子版实验报告
班级：
姓名：
学号：
完成时间：
[注]
1.每个实验问题回答时可以采用截图辅助说明；
2.实验报告（包含数据）打包成rar文件，传到Reports3文件夹，并用学号+姓名+章号命名，如：
********张山-Reports-3.rar
3.请独立完成实验和报告，实验报告分析和数据要一致。
实验
1
2
3
4
5
6
7
8
9
得分
3.1UDP通信过程分析
实验时间：
客户端IP：
RACK编号：
A．上传的文件名是：
Sshendq3.1（1s）。
分别记录下你和合作伙伴所看到的收发信息：
答：
Q1.观察发送端的UDP数据包，在刚才的发送过程中一共有多少个UDP数据包发送？
发送端口是什么？
接收端口是什么？
答：
7个
发送端口：
1238
接收端口：
5001
Q2.观察第1个UDP数据包，其发送的数据长度是多少？
其内容是什么？
观察ethereal在info列中识别出来的协议名称是什么？
在网上搜索一下这个协议是什么作用，和我们的实验有什么关系？
答:
length：
4Data：
50434155没有协议名称
Q3.观察第2个UDP数据包，其UDP协议头部数据部分一共有几个字段，分别是什么？
其值又分别是什么？
这些字段一共占用了多少字节？
答：
1008-1000=8
Q4.继续观察第2个UDP数据包，其发送的数据长度是多少？
这个长度和我们要求发送的1000bytes之间有多少差距？
这次发送的内容是什么？
ethereal将这些数据分析为什么应用层协议？
在网上搜索一下这个协议是什么作用，和我们的实验有什么关系？
答：
1000bytes,没有差距；
Data:
5043415553412050434154544350205061747465726e2021...
Q5.观察第3个UDP数据包，其发送的数据长度是多少，其内容是什么？
观察ethereal在info列中识别出来的协议名称是什么？
结合第一个UDP数据包分析这两个数据包的作用。
答：
4bytes；Data:
50434155
Q6.观察接收方的DOS窗口统计信息和ethereal数据，请问这次试验你和同伴之间的UDP数据包有没有传输成功？
ethereal中的情况和发送方一致吗？
答：
没有成功，一致
Q7.观察DOS窗口中PCATTCP给出的统计信息，发送端的传输时间是多少？
接收端的传输时间是多少？
这两个时间一致吗？
他们会不一致正常吗？
为什么？
答：
一致
Q7.PCATTCP可以工作在你指定的任意端口，请尝试向接收方的8000端口发送UDP数据包，请记录你使用的命令。
请问这次发送端使用的端口是什么？
再重做一次实验看看发送端的端口是什么？
请问你能指定发送端的端口吗？
为什么？
答：
Sourceport:
netbios-dgm（138）;Sourceport:
dnap（1172）;
这两个时间段一致
Q8.和老师一起讨论分析头尾两个UDP数据包的作用是什么？
答：
第一个数据包是建立连接;最后一个数据包是断开连接
B．上传的文件名是：
Sshendq3.1（2s）Rshendq3.1（2r）。
Q9.发送端一共发送了多少个UDP数据包？
分别起了什么作用？
不考虑PCATTCP头尾额外的UDP数据这些包的总流量是多少（包括TCP头部和IP头部）？
答：
19个第一个数据包是建立连接；中间的数据包是数据传输；最后五个是断开连接。
Q10.接收方一共收到多少个UDP数据包？
这次你们的实验中丢失了多少个UDP数据包？
丢失的是什么数据包？
UDP丢失与否发送端能知道吗？
整个过程中有没有看到接收方的确认信息？
答：
0个；10个；能；有
C．上传的文件名是：
Sshendq3.1（3s）。
Q11.接收方一共收到多少个UDP数据包？
这次你们的实验中丢失了多少个UDP数据包？
丢失的是什么数据包？
UDP丢失与否发送端能知道吗？
整个过程中有没有看到接收方的确认信息？
答：
0个；10个；能；有
D．上传的文件名是：
。
Q12.发送端一共发送了多少个UDP数据包？
分别起了什么作用？
答：
16个UDP数据包；第一个数据包是建立连接；中间个数据包是数据传输；最后五个是断开连接。
Q13.接收方一共收到都少个UDP数据包？
这次你们的实验中丢失了多少个UDP数据包？
丢失的是什么数据包？
答：
16个UDP数据包；没有丢失
Q14.发送方的PCATTCP输出的结果说明多少数据发送成功了，耗时多少？
这些数据是否到达了接收方？
到达接收方的这些数据有没有进程接收到？
UDP数据接收端是否存在或接收成功与否发送端能知道吗？
整个过程中有没有看到接收方的确认信息？
答：
Q15.观察ethereal的数据包，看有没有什么包是以前没有看到过的？
分析一下？
答：
没有什么包是以前没的
3.2TCP传输分析
实验时间：
客户端IP：
RACK编号：
A．上传的文件名是：
Sshendq3.2a。
Q1.观察第1个非握手的TCP数据包，其TCP协议头部数据部分一共有几个字段，分别是什么？
其值又分别是什么？
这些字段一共占用了多少字节？
答：
Q2.这个实验是使用TCP传输10个1000字节的数据包，请问用了几个TCP传输这些数据？
和UDP传输时有什么差别？
不考虑重传和确认这些包的总流量是多少（包括TCP头部和IP头部）？
和UDP相比哪个更节约网络资源？
答：
10个；10040；UDP更节约资源。
UDP没有三次握手的延时，没有连接过程
Q3.你的实验中有没有发现数据丢失和重传？
哪几个数据包丢失了？
在什么时候重传的？
重传的数据和原来的数据有什么差别？
答：
没有
Q4.PCATTCP传输TCP和UDP数据有什么不一样？
答：
UDP占用资源少，但是很容易丢失，TCP可以满载（1460bytes）
Time-Sequence-Graph（stevens截图。
答：
B．上传的文件名是：
Sshendq3.2b。
Q5.客户端电脑向gaia.cs.umass.edu传输文件时所用的IP地址和TCP端口号是多少？
答：
IP地址：
10.22.65.198
TCP端口号：
payrouter（1246）
Q6.gaia.cs.umass.edu的IP地址是多少？
该服务器的哪个端口发送和接收TCP片段？
答：
IP地址：
128.119.245.12
端口：
http（80）
Q7.包含HTTPPOST命令的TCP片段是在什么时候收到的？
这时整个HTTP的POST数据已全部上传了吗？
答：
46320:
54:
52.415451128.119.245.1210.22.65.198HTTP772HTTP/1.1200OK（text/html）;
已经全部上传了
Q8.整个过程中有没有重传的片段？
你怎样判断这个问题？
ethereal帮助我们做了什么识别工作吗？
答：
有；重传片段；
快速重传和超时重传；帮助我们识别数据包的
Q9.请记录系统中重传的数据包编号及其重传时间（至少6个包）？
答：
29620:
54:
49.827324；33720:
54:
50.532433；33820:
54:
50.532439；
33920:
54:
50.532464；35720:
54:
50.767996；35920:
54:
50.768006；36920:
54:
51.003724
Q10.分析为什么远程的服务器传输数据出现重传的概率比在本地进行实验要高？
答：
数据链路太长，延时加长，容易造成包的丢失。
3.3TCP序列号管理
实验时间：
客户端IP：
RACK编号：
A．上传的文件名是：
Sshendq3.3（1s）。
Q1.在3次握手后发送的第一个数据包序号SEQ是多少？
长度LEN是多少？
发送时间是什么？
答：
Sequencenumber:
1（relativesequencenumber）;
100;
9220:
27:
14.096196
Q2.对应这个数据包接收端的确认ACK在什么时候到达？
TCP头部的哪个字段说明了这是一个ACK数据？
答：
：
9920:
27:
14.279479;
Sequencenumber:
1（relativesequencenumber）;
Acknowledgmentnumber:
101（relativeacknumber）
Q3.这个片段确认的编号ACK是多少？
和刚才发送的数据起始编号SEQ、长度LEN有什么关系？
这个ACK数值代表的意义是什么？
答：
101等于刚才发送的数据起始编号SEQ，长度LEN之和
Q4.发送端发送的第二份数据起始编号SEQ是多少？
长度LEN是多少？
发送的第二份片段的起始编号SEQ和第一份确认编号ACK的关系是什么？
答：
Sequencenumber:
101（relativesequencenumber）
100；
数值相等
B．上传的文件名是：
Sshendq3.3（2s）。
Q5.找出第一个DOS窗口的一系列TCP数据包及其ACK确认，发送端使用的端口是多少？
答：
Sourceport:
florence（1228）
Q6.找出第二个DOS窗口的一系列TCP数据包及其ACK确认，发送端使用的端口是多少？
答：
Sourceport:
dns2go（1227）
Q7.第一个DOS窗口三次握手后的第一个TCP数据的序号SEQ是多少？
答：
SEQ=1
Q8.第二个DOS窗口三次握手后的第一个TCP数据的序号SEQ是多少？
答：
SEQ=1
Q9.这两个序号是连续的吗？
他们之间有什么关系？
两个TCP序列的序号增长是不是独立的？
答：
连续；交错进行；是独立的
3.4TCP连接管理
实验时间：
客户端IP：
RACK编号：
A．上传的文件名是：
Sshendq3.4（1s）。
Q1.一共有几个TCP连接的发起片段SYN？
这些片段有没有什么应答包？
答：
三个；有应答包
Q2.这些TCP连接的发起片段时间间隔是多少？
这些包的序号分别是多少?
这些包的内容有什么不一样？
答：
；
；
没有什么不同
Q3.在接收端是否也能看到同样的数据片段？
接收端会不会出现和发送端不一致的情况？
答：
能；不会发生
B．上传的文件名是：
Sshendq3.4（2s）。
Q4.一共有几个TCP片段？
有多少是PCATTCP发送端发出的？
有多少个TCP片段中发送了数据？
答：
18个；12个；8个
Q5.第一个TCP片段是否是TCP连接的发起片段SYN？
这个片段的序号SEQ是多少？
长度LEN是多少？
发送时间是多少？
这个片段和普通TCP片段的差别在哪个字段？
答：
是的；SEQ=0；LEN=0；7120:
34:
56.430323；无acknumber
Q6.多久之后接收方回复了针对该TCP片段的确认SYN/ACK？
该TCP片段和普通TCP片段的差别是在哪些字段？
该片段的SEQ是多少？
ACK是多少？
答：
7220:
34:
56.430439；SEQ：
0；ACK：
1；LEN：
0
Q7.第三个TCP片段是由PCATTCP接收方还是发送方发出的？
该片段中是否包含数据？
其SEQ和上面的SYN/ACK有何关系？
答：
发送方；没有；没有关系
Q8.关闭连接FIN是由PCATTCP的发送端还是接收端发起的？
发起的时间是什么时候？
这个时候所有的数据都被确认了吗？
这个关闭连接FIN的TCP片段和普通TCP片段有什么区别？
其序号是多少？
长度是多少？
该TCP片段是否携带了数据？
答：
发送端；8320:
34:
56.431545；是的；没有区别；83；len=240；没有携带数据
Q9.针对该FIN的ACK是在什么时候到达的？
其SEQ是多少？
长度是多少？
该TCP片段是否携带了数据？
答：
SEQ=1；LEN=0
未携带数据
Q10.紧接着另一方向的FIN也发出，该FIN的序号是多少？
长度是多少？
该TCP片段是否携带了数据？
答：
序号：
86；LEN=0
Q11.对应于第二个FIN的ACK是在什么时候到达的？
其SEQ是多少？
长度是多少？
该TCP片段是否携带了数据？
答：
SEQ=10002；LEN=0
C．上传的文件名是：
Sshendq3.4（3s）。
Q12.这次一共有几个TCP片段？
这次的这些TCP片段和刚才有什么差别？
答：
8个；发送端端口不同
Q13.PCATTCP的发送方在FIN中是否携带了数据？
长度是多少？
其序号是多少？
答：
是的，1000，147
Q14.PCATTCP的接受方发出的FIN中是否确认了前面发送方的数据？
答：
没确认
D．上传的文件名是：
Sshendq3.4（4s）。
Q15.和前面的实验不一样的是这次出现了什么数据片段？
这个TCP片段和普通TCP片段有何不同？
答：
没有；
Q16.接收端是否收到了该TCP片段？
在该片段之后发送端和接收端还有数据交互吗？
答：
是的；没有
Q17.分析下如果PCATTCP接收端如果没有收到该数据片段会发生什么事件？
答:
如果PCATTCP接收端如果没有收到该数据片段接收会一直开着
附加联系：
在正常传输过程中通过禁用发送端或接收端网卡产生通信中断后，分别观察和分析发送端和接收端的行为，请注意重传间隔的变
附加联系：
在正常传输过程中通过禁用发送端或接收端网卡产生通信中断后，分别观察和分析发送端和接收端的行为，请注意重传间隔的变化。
答：
3.5TCP确认管理
实验时间：
客户端IP：
RACK编号：
A．上传的文件名是：
。
No
是否重发
数据包序列号
发送时间
ACK时间
RTT
ERTT
LEN
确认
方式
推测
丢失
推测
延迟
1
否
176
20:
54:
47.482374
20:
54:
47.715610
0.233236
0.233236
625
单一确认
否
否
2
否
177
20:
54:
47.486294
20:
54:
47.720625
0.234331
0.1748
1408
单一确认
否
否
3
否
184
20:
54:
47.715646
20:
54:
47.949659
0.234013
0.1237
1408
单一确认
否
否
4
否
185
20:
54:
47.715649
20:
54:
47.949678
0.234029
0.0790
1408
单一确认
否
否
5
否
187
20:
54:
47.720643
20:
54:
47.955127
0.234484
0.0398
1408
单一确认
否
否
6
否
188
20:
54:
47.720646
20:
54:
47.955134
0.234488
0.0055
1408
单一确认
否
否
7
否
193
20:
54:
47.949688
20:
54:
48.184349
0.234661
-0.0245
1152
单一确认
否
否
8
否
197
20:
54:
48.184419
20:
54:
48.417750
0.233331
-0.0506
1408
单一确认
否
否
9
否
198
20:
54:
48.184437
20:
54:
48.418048
0.233611
-0.0735
1408
单一确认
否
否
10
否
199
20:
54:
48.184451
20:
54:
48.418055
0.233604
-0.0935
1408
单一确认
否
否
总间隔时间
2.3398
总发送数据
13041
吞吐率
5573.553295153431917257885289341
注：
1.如果前10个或20个数据片段中没有丢失片段的情况，可以选取任意连续的时间位置进行分析；
2.假设第一个片段EstimatedRTT值和RTT值相同；
3.可以在excel中设计一个计算工具对这些数据分析，省却重复的计算；
4.在ethereal中对每个ACK的分析中有RTT的自动计算，可以用来对比参考，但注意累计确认引起的差异。
5.计算ERTT时请忽略重发的数据包，累计确认时只计算最后一个片段的RTT值；
6.参考的ERTT计算公式如下：
EstimatedRTT=（1-）*EstimatedRTT+*SampleRTT
（假设＝0.125）
3.6TCP快速重传
实验时间：
客户端IP：
RACK编号：
A．上传的文件名是：
。
Q1.这个TCP片段的序号是多少？
答：
296
Q2.第一次发送的时间是多少？
答：
29520:
54:
49.827320
Q3.什么时候重发了这个数据片段？
答：
29620:
54:
49.827324
Q4.重发的时间间隔是多少？
这个时间间隔和上一个实验计算得到的ERTT值有什么关系？
答：
重发的时间间隔是1.785327s;这个时间间隔和上一个实验计算得到的ERTT值相等
s;
Q5.在这个时间间隔里发送端又发送了几个TCP片段？
期间有没有来自接收端的确认？
如果有确认，和这个片段有关系吗？
答：
在这个时间间隔里发送端又发送了2个TCP片段；期间有来自接收端的确认；没关系
Q6.这个TCP片段的序号是多少？
答：
339
Q7.第一次发送的时间是多少？
答：
：
33920:
54:
50.532464
Q8.什么时候重发了这个数据片段？
答：
33920:
54:
50.532464
Q9.重发的时间间隔是多少？
这个时间间隔和上一个实验计算得到的ERTT值有什么关系？
这个时间间隔个前面超时重传的间隔有什么关系？
答：
0.233759
Q10.在这个时间间隔里发送端又发送了几个TCP片段？
期间有没有来自接收端的确认？
如果有确认，和这个片段有关系吗？
答：
5个；没有；没有关系
Q11.是什么触发了这个数据片段的重发？
请详细说明。
答：
由于其前面有两个冗余的ACK;因为发送方经常连续发送大量的报文段，导致数据包的丢失，从而产生一个接一个冗余ACK的产生，一旦出现3个冗余的ACK，就会产生快速重传。
Q12.注意观察是否在确认ACK中有SACK选项数据，如果有的话请记录其数值并分析器作用。
答：
3.7TCP流控和窗口管理
实验时间：
客户端IP：
RACK编号：
A．上传的文件名是：
。
Q1.整个过程中可用的缓冲区窗口的最小数量是多少？
答：
6875
Q2.可用的缓冲区空间有没有影响发送者？
答：
有影响
Q3.请在google中搜索一下windows下默认的TCP窗口值是多少？
答：
：
windows下默认的TCP窗口值是65535
Q4.首先查看Time-sequenceGraph（Steven），我们会发现类似的曲线，可以明显的看到一段斜率的变化，请分析其原因是什么？
答：
Q5.我们也发现中间有停顿的位置，请问这是为什么？
答：
只是交换机的问题,
Q6.在Ethereal的数据中寻找TCPWINDOWFULL或TCPWINDOWUPDATE的消息，该消息出现在什么时候？
分别是发送端窗口问题还是接收端窗口问题？
和上图有何关系？
答：
接收窗口问题
3.8TCP拥塞管理
实验时间：
客户端IP：
RACK编号：
A．上传的文件名是：
Sshendq3.2b。
Q1.慢启动的第一个TCP片段的序号是多少？
发送的时间是多少？
这次同时发送了几个TCP片段？
答：
慢启动的第一个TCP片段的序号是1;发送的时间是1.420598;这次同时发送了2个TCP片段
Q2.第一个TCP片段的确认是在什么时候到达的？
答：
：
是在1.77176到达的
Q3.第二组TCP片段是在什么时候发送的？
是在第一个TCP片段的确认到来之前还是之后？
这次同时发送了几个TCP片段？
答：
第二组TCP片段是在1.771820的时候发送;是在第一个TCP片段的确认到来之后;这次同时发送了4个TCP片段
Q4.记录后续的确认和新的发送过程，这个慢启动的过程一直持续到什么时候？
是别的什么事件终止了慢启动的过程？
答：
这个慢启动的过程一直持续到1.773171;这个慢启动的过程一直持续到发送端发送的数据达到了阈值的时候.
Q5.在整个数据中有没有看到由慢启动进入拥塞避免，是在哪个位置？
进入拥塞避免后发送端的表现有何差别？
答：
第二组TCP片段发送的第四个数据包的时候由慢启动进入拥塞避免;进入拥塞避免后重新开始慢启动.
Q6.确认超时时发送端是在慢启动阶段还是拥塞避免阶段？
确认超时的TCP片段序号是多少？
发生在什么时间？
答：
确认超时时发送端是在慢启动阶段;确认超时的TCP片段序号是22617;发生的时间是3.181564
Q7.发生确认超时后发送端是否重发了TCP片段？
发送的时间是多少？
这个片段被及时确认了吗？
如果有，什么时候确认的？
时间间隔是多少？
是累计确认还是单次确认？
答：
重发了TCP片段;发送的时间是5.311940;是累计确认
Q8.重发该TCP片段后紧接着同时发送了多少数据片段？
这些TCP数据片段在什么时候被确认的？
是累计确认还是单次确认？
答：
6个；35520:
54:
50.767699；有累计，也有单一
Q9.记录后续的确认和新的发送过程，这个过程一直持续到什么时候？
是别的什么事件终止了该过程？
答：
这个过程一直持续到最后的数据包重发以后;超时事件
Q10.重复确认时发送端是在慢启动阶段还是拥塞避免阶段？
重复确认的TCP片段序号是多少？
发生在什么时间？
答：
：
是拥塞避免阶段;重复确认的TCP片段序号是52569;发生时间
Q11.发生重复确认后发送端是否重发了TCP片段？
发送的时间是多少？
这个片段被及时确认了吗？
如果有，什么时候确认的？
时间间隔是多少？
是累计确认还是单次确认？
答：
重发了TCP片段;发送的时间是9.563732;这个片段被及时确认了;在9.915724被确认的;时间间隔是0.351992;是累计确认
Q12.重发该TCP片段后紧接着同时发送了多少数据片段？
这些TCP数据片段在什么时候被确认的？
是累计确认还是单次确认？
答：
紧接着同时发送了3个数据片段;这些TCP数据片段在10.268046的时候被确认的;累计确认.
Q13.记录后续的确认和新的发送过程，这个过程一直持续到什么时候？
是别的什么事件终止了该过程？
答：
这个过程一直持续到66137被重发以后,快速重发事件终止了该过程.
3.9竞争分析
实验时间：
客户端IP：
RACK编号：
Q1.两个TCP同时传输时是否可以友好相处？
从时序图的斜率可以看出什么？
答：
可以友好相处；.两个TCP共享了整个带宽。
从时序图的斜率可以看出两个同时TCP
升级会员 