实验七 UDP和TCP.docx
《实验七 UDP和TCP.docx》由会员分享,可在线阅读,更多相关《实验七 UDP和TCP.docx(26页珍藏版)》请在冰豆网上搜索。
实验七UDP和TCP
南昌大学实验报告
学生姓名:
吴长福学号:
8000114105专业班级:
卓越141班
实验类型:
□验证□综合√设计□创新实验日期:
2016.12.15实验成绩:
实验七
(1)UDP协议
【实验目的】
1.掌握UDP协议的报文格式
2.掌握UDP协议校验和的计算方法
3.了解DNS的工作原理
【实验学时】
建议4学时
【实验环境配置】
采用网络结构一
服务器A
172.16.1.1
【实验原理】
一.UDP报文格式
每个UDP报文称为一个用户数据报(UserDatagram)。
用户数据报分为两个部分:
UDP首部和UDP数据区。
源端口
目的端口
报文长度
校验和
数据
…
二.UDP单播与广播
在UDP单播通讯模式下,客户端和服务端之间建立一个单独的数据通道。
从一台服务端传送出的数据包只能由一个客户端接收。
众所周知,UDP协议是不可靠的,数据包可能在传输过程中丢失、重复、没有按照发送顺序到达,而且作为UDP数据包,其大小还受限于数据包的最大上限。
在UDP广播通讯模式下,一个单独的数据包拷贝发送给网络上所有主机。
当不能明确具体的服务器,而又要求该服务时,UDP广播提供了传输不区分种类的消息的便捷方式。
在多数情况下UDP广播仅仅作为本地网络通信形式。
受限的广播地址是255.255.255.255。
该地址用于主机配置过程中IP数据报的目的地址,此时,主机可能还不知道它所在网络的网络掩码,甚至连它的IP地址也不知道。
在任何情况下,路由器都不转发目的地址为受限广播地址的数据报,这样的数据报仅出现在本地网络中。
已知网络主机的IP地址和子网掩码,可以算得指向主机所在子网的广播。
子网广播地址=(主机IP)“或”(子网掩码取反)。
三.UDP校验和的计算
下图给出了一个计算UDP校验和的例子。
这里假定用户数据报的长度是15字节,因此要添加一个全0的字节。
【实验步骤】
练习一:
编辑并发送UDP数据报
1.主机B编辑发送给主机C的UDP数据报,其中应用选择“DNS”,源端口设为“1025”,报文数据大小设为“0”。
2.设置过滤条件(提取UDP协议),开始捕获数据。
3.停止捕获数据,在捕获到的数据中观察主机B所发送的数据报、以及主机C发出的数据报。
主机B发出去的数据报:
C发出去的数据报:
4.校验和应该为多少?
手工计算校验和。
5.主机B编辑发送给服务器A的UDP数据报,其中应用选择“DNS”,源端口设为“1025”,报文数据大小设为“0”。
6.设置过滤条件(提取UDP协议)开始捕获数据。
7.停止捕获数据,在捕获到的数据中观察主机B所发送的数据报。
练习二:
UDP单播通信
1.服务器A的DNS服务缓存中,添加一条域名解析记录,域名“”,地址“172.16.1.1”。
2.主机B设置DNS为172.16.1.1,使用Web浏览器访问“”。
3.设置过滤条件(提取UDP协议),开始捕获数据。
4.停止捕获数据,在捕获到的数据中观察主机B所发送的数据报,并回答以下问题:
目标IP地址为多少?
172.16.1.1
源端口和目标端口分别为多少?
源端口:
1027
目的端口:
53
5.在捕获到的数据中观察主机B所接收的数据报,并回答以下问题:
源IP地址和目标IP地址为多少?
源:
172.16.1.2目的:
172.16.1.1
源端口和目标端口分别为多少?
6.根据对捕获报文观察,回答以下问题:
UDP是基于连接的协议吗?
UDP报文交互中含有确认报文吗?
不是,没有。
练习三:
UDP广播通信
1.清空主机B的DNS设置,使用Web浏览器访问“”。
3.设置过滤条件(提取UDP协议),开始捕获数据。
4.停止捕获数据,在捕获到的数据中观察主机B所发送的数据报,并回答以下问题:
目标IP地址为多少?
源端口和目标端口分别为多少?
源端口:
1030,目标端口:
53
5.在捕获到的数据中观察主机B所接收的数据报,并回答以下问题:
源IP地址和目标IP地址为多少?
源端口和目标端口分别为多少?
源端口:
1030,目标端口:
53
【思考问题】
1.UDP和IP的不可靠程度是否相同?
为什么是或为什么不是?
UDP和IP的不可靠程度是不相同的,因为IP仅检验首部,而UDP检验整个数据报。
2.UDP协议本身是否能确保数据报的发送和接收顺序?
不能
实验七
(2)传输控制协议TCP
【实验目的】
1.掌握TCP协议的报文格式
2.掌握TCP连接的建立和释放过程
3.掌握TCP数据传输中编号与确认的过程
4.理解TCP重传机制
【实验学时】
建议4学时
【实验环境配置】
采用如下网络结构
【实验原理】
一.TCP报文格式
16位源端口号
16位目的端口号
32位序号
32位确认序号
4位首部长度
保留(6位)
U
R
G
A
C
K
P
S
H
R
S
T
S
Y
N
F
I
N
16位窗口大小
16位校验和
16位紧急指针
选项
数据
二.TCP连接的建立
TCP是面向连接的协议。
在面向连接的环境中,开始传输数据之前,在两个终端之间必须先建立一个连接。
对于一个要建立的连接,通信双方必须用彼此的初始化序列号seq和来自对方成功传输确认的应答号ack(指明希望收到的下一个八位组的编号)来同步,习惯上将同步信号写为SYN,应答信号写为ACK。
整个同步的过程称为三次握手,如图:
三.TCP连接的释放
对于一个已经建立的连接,TCP使用四次握手来结束通话(使用一个带有FIN附加标记的报文段),如图:
四.TCP重传机制
TCP每发送一个报文段,就对这个报文段设置一次计时器。
只要计时器设置的重传时间到期,但还没有收到确认,就要重传这一报文段。
【实验步骤】
练习一:
察看TCP连接的建立和释放
1.进入仿真模式,设置过滤条件(提取TCP协议)。
2.主机B编辑发送给服务器A的TCP数据报,其中应用选择“HTTP”,源端口设为“1025”,报文数据大小设为“0”。
3.在捕获的数据中,查找用于建立TCP连接的三次握手报文,填写下表。
字段名称
报文1
报文2
报文3
源IP
172.16.1.2
172.16.1.2
172.16.1.2
目标IP
172.16.1.1
172.16.1.1
172.16.1.1
SequenceNumber
1395441157
3695045941
1395441158
AcknowledgementNumber
0
1395441158
3695045942
ACK比特位
0
1
1
SYN比特位
1
1
0
4.在捕获的数据中,查找用于断开TCP连接的四次握手报文,填写下表。
字段名称
报文4
报文5
报文6
报文7
源IP
172.16.1.1
172.16.1.1
172.16.1.1
172.16.1.1
目标IP
172.16.1.2
172.16.1.2
172.16.1.2
172.16.1.2
SequenceNumber
1395441158
3695045942
3695045942
1395441159
AcknowledgementNumber
3695045942
1395441159
1395441159
3695045943
ACK比特位
1
1
1
1
SYN比特位
1
0
1
0
结合步骤3、4所填的表,理解TCP的三次握手建立连接和四次握手的释放连接过程,理解序号、确认号等字段在TCP可靠连接中所起的作用。
练习二:
理解TCP数据包的编号与确认
1.主机B使用Web浏览器访问“http:
//172.16.1.1”。
2.设置过滤条件(提取TCP,HTTP协议),捕获数据。
停止捕获数据,在捕获到的数据中观察主机B所发送的报文,并回答以下问题:
目标IP地址为多少?
IP首部的协议字段值为多少?
目的地址为:
172.16.1.1IP首部的协议字段值为:
0x6(代表tcp协议)
源端口和目标端口分别为多少?
源端口:
1026目的端口:
80
TCP首部中SequenceNumber为多少?
AcknowledgementNumber为多少?
哪些控制比特置为了1?
Sequencenum:
0,acknum:
0syn置为了1.
3.在捕获到的数据中观察主机B所接受的报文,并回答以下问题:
目标IP地址为多少?
IP首部的协议字段值为多少?
目的地址为:
172.16.1.2IP协议字段的值为:
0x6(tcp)
源端口和目标端口分别为多少?
源端口:
80目的端口:
1025
TCP首部中SequenceNumber为多少?
AcknowledgementNumber为多少?
哪些控制比特置为了1?
Sequencenum:
0acknum:
1
练习三:
TCP的重传机制
1.关闭服务器A的HTTP服务。
1.主机B编辑发送给服务器A的TCP数据报,其中应用选择“HTTP”,源端口设为“1026”,报文数据大小设为“0”。
2.设置过滤条件(提取TCP协议),捕获数据。
3.停止捕获数据。
查看捕获的报文,是否相同?
为何有这种现象产生?
相同,当服务器没有收到的时候,就会产生重传
【思考问题】
1.试用具体例子说明为什么在运输连接建立时要使用三次握手。
说明如不这样做可能会出现什么情况。
三次握手完成了两个重要的功能,一个是双方做好发送数据的准备工作,即双方都知道彼此已准备好,一个是允许双方就初始序列号进行协商,这个序列号在握手过程中被发送和确认。
假如把三次握手改为两次握手,就会可能出现死锁的情况。
如,计算机A和B之间的通信,假定B给A发送一个连接请求分组,A收到了这个分组,并发送了确认应答分组。
按照两次握手的协定,A认为连接已经成功地建立了,可以开始发送数据分组。
可是,B在A的应答分组在传输中被丢失的情况下,将不知道A是否已准备好,不知道A建议什么样的序列号,B甚至怀疑A是否收到自己的连接请求分组。
在这种情况下,B认为连接还未建立成功,将忽略A发来的任何数据分组,只等待连接确认应答分组。
而A在发出的分组超时后,重复发送同样的分组。
这样就形成了死锁。
2.使用TCP对实时话音数据的传输有没有什么问题?
使用UDP在传送数据文件时会有什么问题?
TCP延时比较大,因为其具有拥塞控制算法,对于实时性要求高的业务来说,有其必然的缺点。
UDP没有拥塞控制,只能提供尽力而为的服务,所以会出现丢包现象,且不重传。
所以不适合传准确性要求比较高的,不允许有错误的等数据文件。