第三次实验报告:使用Packet Tracer分析TCP连接建立过程

0 个人信息

  • 姓名:罗廷杨
  • 学号:201821121013
  • 班级:计算1811

1 实验目的

  • 使用路由器连接不同的网络
  • 使用命令行操作路由器
  • 通过抓取HTTP报文,分析TCP连接建立的过程

2 实验内容

使用Packet Tracer,正确配置网络参数,通过抓取HTTP数据包,分析TCP连接建立过程。

  • 建立网络拓扑结构
  • 配置参数
  • 抓包
  • 分析数据包

3. 实验报告

3.1 建立网络拓扑结构

网络拓扑图如下图所示:

第三次实验报告:使用Packet Tracer分析TCP连接建立过程_第1张图片

3.2 配置参数

( 1 ) 客户端参数配置:

第三次实验报告:使用Packet Tracer分析TCP连接建立过程_第2张图片

 ( 2 ) 服务器参数配置:

第三次实验报告:使用Packet Tracer分析TCP连接建立过程_第3张图片

 ( 3 ) 路由器参数配置:

第三次实验报告:使用Packet Tracer分析TCP连接建立过程_第4张图片

( 4 ) 路由器参数配置命令说明:

配置并激活端口

Router>enable     #进入特权模式

Router#configure terminal   #进入全局配置模式

a.配置F0/0接口:

Router(config)#interface F0/0   #进入接口F0/0

Router(config-if)#ip address 192.168.1.80 255.255.255.0  #为F0/0接口配置IP

Router(config-if)#no shutdown #激活接口

b.配置F0/1接口:

Router(config)#interface F0/1   #进入接口F0/1

Router(config-if)#ip address 192.168.2.80 255.255.255.0  #为F0/1接口配置IP

Router(config-if)#no shutdown #激活接口

配置路由算法

a.启用动态路由

Router(config)#router rip   #配置rip协议

Router(config-router)#version 2 #使用rip2版本

b.指定网络

Router(config-router)#network 192.168.1.0

Router(config-router)#network 192.168.2.0

补充说明:

Router#erase startup-config  #清除路由器上的现有配置

Router(config)#no ip domain-lookup  #禁用DNS查找

在实验环境中禁用DNS查找的目的是提高操作响应时间,因为键入错误的命令,路由器会把错误命令当成域名进行查找。

Router(config)#hostname R  #将路由器名称配置为R

R(config-router)#no auto-summary  #关闭自动路由汇总

Router#show ip interface brief  #查看接口配置的ip信息

Router#show ip route    #查看路由信息

3.3 抓包,分析TCP连接建立过程

(1)画出TCP连接建立示意图

如下图所示:

第三次实验报告:使用Packet Tracer分析TCP连接建立过程_第5张图片

(2)分析序号和确认号的变化

  三次报文握手中客户端先向服务端发送连接请求报文,让同步位SYN=1,此时需要选择一个初始序号(seq=x)seq=0,因为SYN报文段不能携带数据,但要消耗掉一个序号;Server端收到请求报文后,如果同意建立连接,则向PC端发送确认,确认报文段中,SYN=1,ACK=1,确认号ack=0+1(ack=x+1),此时需要选择一个初始序号(seq=y)seq=0,因为此报文段也不能携带数据,但要消耗掉一个序号;客户端收到服务端的确认后,需要再给服务端发送确认报文,其中,ACK=1,确认号ack=0+1(ack=y+1),seq=0+1(seq=x+1),因为ACK报文段可以携带数据,所以如果携带了数据就要消耗掉一个序号,若没有携带数据则下一数据报文段的序号仍然是seq=1(seq=x+1)。

(3)为什么连接建立需要第三次握手

  这主要是为了防止已失效的连接请求报文段突然又传送到了服务端,因而产生错误。

  所谓“已失效的连接请求报文段”是这样产生的。考虑一种正常情况。客户端发出连接请求,但因连接请求报文丟失而未收到确认。于是客户端再重传一次连接请求。后来收到了确认,建立了连接。数据传输完毕后,就释放了连接。客户端共发送了两个连接请求报文段,其中第一个丢失,第二个到达了服务端。没有“已失效的连接请求报文段”。

  现假定出现一种异常情况,即客户端发出的第一个连接请求报文段并没有丢失,而是在某些网络结点长时间滞留了,以致延误到连接释放以后的某个时间才到达服务端。本来这是一个早已失效的报文段。但服务端收到此失效的连接请求报文段后,就误认为是客户端又发出一次新的连接请求。于是就向客户端发出确认报文段,同意建立连接。假定不采用三次握手,那么只要服务端发出确认,新的连接就建立了。

  由于现在客户端并没有发出建立连接的请求,因此不会理睬服务端的确认,也不会向服务端发送数据。但服务端却以为新的运输连接已经建立了,并一直等待A发来数据。服务端的许多资源就这样白白浪费了。

  采用三次握手的办法可以防止上述现象的发生。例如在刚才的情况下,客户端不会向服务端的确认发出确认。服务端由于收不到确认,就知道客户端并没有要求建立连接。

4. 拓展 

(1)分析TCP连接释放

TCP连接释放示意图:

第三次实验报告:使用Packet Tracer分析TCP连接建立过程_第6张图片

 

 

为什么图和课本不一样?

  课本上的连接释放过程,在客户端发出连接释放请求后,服务端又发送了一个确认报文,然后进入CLOSEWAIT(半关闭状态),等服务端没有数据要传送后才会发送连接释放报文给客户端。而本例中客户端发送了连接释放请求后,服务端就立刻发送连接释放响应,没有经过半关闭状态。 

为什么连接释放需要四次握手?

  因为当Server端收到Client端的SYN连接请求报文后,可以直接发送SYN+ACK报文。其中ACK报文是用来应答的,SYN报文是用来同步的。但是关闭连接时,当Server端收到FIN报文时,很可能并不会立即关闭SOCKET,所以只能先回复一个ACK报文,告诉Client端,"你发的FIN报文我收到了"。只有等到我Server端所有的报文都发送完了,我才能发送FIN报文,因此不能一起发送。故需要四步握手。

 为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态?

  答:虽然按道理,四个报文都发送完毕,我们可以直接进入CLOSE状态了,但是我们必须假象网络是不可靠的,有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。

参考文章

【1】https://blog.csdn.net/daocaoren1543169565/article/details/80535949

 

你可能感兴趣的:(第三次实验报告:使用Packet Tracer分析TCP连接建立过程)