第三次作业:使用Packet Tracer分析TCP连接的建立与释放过程

0 个人信息

  • 张樱姿
  • 201821121038
  • 计算1812

1 实验目的

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

2 实验内容

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

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

3 实验报告

本实验使用Cisco Packet Tracer这个平台来对网络环境进行模拟。

3.1 建立网络拓扑结构

网络拓扑图如下图所示:

分析:由于客户端和服务器不在同一网段,因此需要配置路由器将这两者联系起来才能互相通信。

3.2 配置参数

3.2.1 配置客户端

客户端的IP地址为192.168.1.38 , 子网掩码为255.255.255.0 , 默认网关为192.168.1.100

3.2.2 配置客户端

服务端的IP地址为192.168.2.38 , 子网掩码为255.255.255.0 , 默认网关为192.168.2.100

3.2.3 配置路由器

  • 路由器激活配置:

配置命令解释:

Router>                          (处于用户模式下)

Router>enable                 (进入特权模式)

Router#                                  (特权模式)

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

Router(config) #               (全局配置模式) 

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

Router(config)#hostname R                (设置路由器主机名)

  • G0/0/0及G0/0/1端口配置:

 

 

配置命令解释:

R(config)#interface G0/0/0                        (进入端口配置模式)

R(config-if)#ip address 192.168.1.100 255.255.255.0 (配置端口)

     R(config-if)#no shutdown             (激活端口)

  • 路由协议配置:

  

配置命令解释:

R(config)#router rip                       (进入rip路由协议配置模式)

R(config-router)#                           (rip路由协议配置模式

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

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

R(config-router)#network 192.168.1.0 (设置参与RIP协议的网络地址)

  • 查看已配置参数:

  

   

配置命令解释:

R#show ip interface brief       (查看ip地址和端口状态)

R#show ip route      (查看路由表)

  • 测试客户端与服务器间能否正常通信:

  在客户端上ping服务器:

  

   在服务器上ping客户端:

  

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

3.3.1 开启仿真模式,用客户端的浏览器访问服务器:

   3.3.2 抓到的包:

  

   

  3.3.3 画TCP连接建立示意图(三次握手):

  

  3.3.4 分析序号和确认号的变化:

       (1)第一次握手:客户端发送一个TCP的SYN标志位为1的包表明客户打算连接服务器的端口,以及初始序号X,保存在包头的序列号           (Sequence Number)字段里,此处seq=0即X=0。

  (2)第二次握手:服务器发回确认包(ACK)应答。即SYN标志位和ACK标志位均为1同时,将确认序号(Acknowledgement Number)设置为客户的ISN加1,即X+1,此处ack为1。

  (3)第三次握手:客户端再次发送确认包(ACK) ,SYN标志位为0,ACK标志位为1。并且把服务器发来ACK的序号字段+1,即seq=1,放在确定字段中发送给对方。

  3.3.5 TCP连接建立需要第三次握手的原因:

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

如果使用的是两次握手建立连接,当客户端发送了第一个请求连接并且没有丢失,只是因为在网络结点中滞留的时间太长了,由于TCP的客户端迟迟没有收到确认报文,以为服务器没有收到,此时重新向服务器发送这条报文,此后客户端和服务器经过两次握手完成连接,传输数据,然后关闭连接。此时此前滞留的那一次请求连接,网络通畅了到达了服务器,这个报文本该是失效的,但是,两次握手的机制将会让客户端和服务器再次建立连接,这将导致不必要的错误和资源的浪费

如果采用的是三次握手,就算是那一次失效的报文传送过来了,服务端接受到了那条失效报文并且回复了确认报文,但是客户端不会再次发出确认。由于服务器收不到确认,就知道客户端并没有请求连接。

3.4 分析TCP连接释放过程

 3.4.1 画TCP连接释放示意图(四次挥手):

 

3.4.2 分析示意图为何与课本不一样的原因:

示意图中,最后一次挥手的ack值应该为第三次的seq值加1,但是却没有。个人认为是此时FIN=0,即使确认号不加一,此时也能达到释放连接的效果。另一方面是,此时TCP连接处于半关闭状态,因为数据仍可以从被动关闭一方向主动关闭方发送。

3.5 Q&A

  Q:为什么连接的时候是三次握手,关闭的时候却是四次挥手?

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

4 Reference

 

猜你喜欢

转载自www.cnblogs.com/MilkoSilver/p/11678050.html