实验六 利用Wireshark分析tcp协议 x10226Word文档格式.docx
《实验六 利用Wireshark分析tcp协议 x10226Word文档格式.docx》由会员分享,可在线阅读,更多相关《实验六 利用Wireshark分析tcp协议 x10226Word文档格式.docx(12页珍藏版)》请在冰豆网上搜索。
显示包含TCPSYN标志的封包。
and
tcp.flags.ack==0显示包含TCPSYN并且不包含ACK标志的封包。
tcp.flags.fin==1
tcp.flags.ack==1显示包含TCPFIN和ACK标志的封包。
tcp.window_size==0&
&
tcp.flags.reset!
=1
三、主要设备、器材
1)已联网且运行Windows操作系统的计算机
2)协议分析软件Wireshark
四、要求
1、结果分析与保存的数据一致,否则没有实验成绩
2、数据保存名称:
tcp数据:
x10226-tcp.pcap
实验结果分析报告名称:
实验六利用Wireshark分析tcp协议_x10226.doc
五、实验步骤:
1)启动WireShark抓包
2)访问学校主页服务器,通过Wireshark捕获通信内容
3)分析TCP连接建立的三次握手和连接释放的四次握手过程
浏览网页,抓取三次握手的包,根据TCP包头格式将各字段取值填下来。
源IP:
10.30.28.13
目的IP:
202.194.104.11
源端口:
1060
目的端口:
80
第一次握手:
找出第一次握手的数据包并截取对该数据包的展开图,根据截图填写横线内容。
序号:
0
确认号:
0
数据偏移:
32
URG:
0
ACK:
PSH:
RST:
SYN:
1
FIN:
窗口:
32767
若只抓取第一次握手的数据包,则显示过滤器的规则为tcp.flags.syn==1
并截图替换下图:
第二次握手:
找出第二次握手的数据包并截取对该数据包的展开图,根据截图填写横线内容。
32
1
0
32767
若只抓取第二次握手的数据包,则显示过滤器的规则为
andtcp.flags.ack==1并截图替换下图:
(提示需要syn字段为1而ack字段为1)
第三次握手:
找出第三次握手的数据包并截取对该数据包的展开图,根据截图填写横线内容。
1
1
20
0
32767
是否可以只抓取第三次握手的数据包,为什么?
若不能,如何确定是第三次握手的数据包。
不可以只抓取第三次握手的数据包,因为只要是确认包,ACK都是1,所以要再根据序号判断
三次握手之后,客户端要请求服务器传送数据
第一次请求数据:
找出第一次请求的数据包并截取对该数据包的展开图,根据截图填写横线内容。
1
20
1
0
你是如何确定是第一次的请求的数据包:
http协议并且push=1
若通过过滤规则如何找出第一次的请求数据包:
tcp.flags.syn==1andtcp.flags.push==1
服务器要传送数据给客户端
第一次回复数据:
找出第一次回复的数据包并截取对该数据包的展开图,根据截图填写横线内容。
305
20
65231
你是如何确定是第一次的回复的数据包:
ACK=1,PUSH=0且报文显示为[TCPsegmentofareassembledPDU]
1、捕捉断开连接的数据包,显示过滤器的规则为tcp.flags.fin==1
tcp.flags.ack==1
根据截图内容填写:
第一次断开:
第二次断开:
3、捕捉RST置位的包,显示过滤器的规则为tcp.flags.reset==1
截图(RST置位)并填写横线
584
2214
0
0
传输层TCP数据报结构详解
选取一条TCP数据包并截图,
填写各项的信息及作用
TCP数据报中依次包括以下信息:
1、SourcePort:
1101,表示目标通过1101端口传送数据。
该部分占16个BIT。
2、DestinationPort:
80,表示本机通过80接口接收数据。
该部分占16个BIT。
3、InitialSequenceNumber:
584,表示每一个字节的编号,即SEQ值。
该部分占32个BIT,值从1到2的32次方减1。
4、NextExpectedSEQNumbe:
2214,表示下一个要接到数据的编号,即对方返回的ACK值。
该部分占32个BIT,值从1到2的32次方减1。
5、DataOffset:
4Bytes,表示报头大小。
该部分占32个BIT。
6、ReservedBites:
保留位,此处不用。
该部分占6个BIT。
7、Flags:
0x0010。
该值用两个十六进制数来表示。
该部分长度为3个BIT,6个标志位的含义分别是:
0,为1表示紧急指针有效。
1,为1表示确认报文。
0,为1表示发送报文。
0。
为1表示TCP出现严重错误必须释放
0。
为1表示一个连接请求。
为1表示随访发送数据已完毕。
8、Window:
0,表示接收方目前允许对方发送的数据量。
9、CheckSum:
0xae1c,表示校验和。
该部分占16个BIT,用十六进制表示。
10、UrgentPointer:
00,表示紧急数据的字节数。
该部分占2个BIT。
11、MaximumSegmentSize:
1514,表示数据字段的最大长度。
【思考问题】
1.试用具体例子说明为什么传输连接建立时要使用三次握手。
如不这样做可能会出现什么情况。
答:
我们知道,3次握手完成两个重要的功能,既要双方做好发送数据的准备工作(双方都知道彼此已准备好),也要允许双方就初始序列号进行协商,这个序列号在握手过程中被发送和确认。
现在把三次握手改成仅需要两次握手,死锁是可能发生的。
作为例子,考虑计算机A和B之间的通信,假定B给A发送一个连接请求分组,A收到了这个分组,并发送了确认应答分组。
按照两次握手的协定,A认为连接已经成功地建立了,可以开始发送数据分组。
可是,B在A的应答分组在传输中被丢失的情况下,将不知道A是否已准备好,不知道A建议什么样的序列号,B甚至怀疑A是否收到自己的连接请求分组。
在这种情况下,B认为连接还未建立成功,将忽略A发来的任何数据分组,只等待连接确认应答分组。
而A在发出的分组超时后,重复发送同样的分组。
这样就形成了死锁。
2.使用TCP对实时话音数据的传输有什么问题?
使用UDP在传送数据文件时会有什么问题?
1.如果语音数据不是实时播放(边接受边播放)就可以使用TCP,因为TCP传输可靠。
接收端用TCP讲话音数据接受完毕后,可以在以后的任何时间进行播放。
但假定是实时传输,则必须使用UDP。
3.UDP不保证可靠交付,但UCP比TCP的开销要小很多。
因此只要应用程序接受这样的服务质量就可以使用UDP。
4.TCP在进行流量控制时是以分组的丢失作为产生拥塞的标志。
有没有不是因拥塞而引起的分组丢失的情况?
如有,请举出三种情况。
当IP数据报在传输过程中需要分片,但其中的一个数据报未能及时到达终点,而终点组装IP数据报已超时,因而只能丢失该数据报;
IP数据报已经到达终点,但终点的缓存没有足够的空间存放此数据报;
数据报在转发过程中经过一个局域网的网桥,但网桥在转发该数据报的帧没有足够的差错空间而只好丢弃。