摘要:

本文主要讲述如何使用Packet Tracer工具正确配置网络参数,通过抓取HTTP数据包,分析TCP连接建立与释放过程。

1.个人信息

  • 姓名:黄勋
  • 学号:201821121104
  • 班级:计算1814

2.建立网络拓扑结构

 网络拓扑结构图如上图所示,该网络拓扑图共由一台PC端(PC0)、一台路由器以及一台服务端(Server0)构成,且三者为连接状态。

3.配置参数

  • 客户端的IP地址为192.168.1.104
  • 服务端的IP地址为192.168.1.105
  • 配置路由器参数:

    • Router>enable             

    • Router#config t     

  • 配置Fa0/0接口:

    • R(config)#interface f0/0

    • R(config-if)#ip address 192.168.1.105 255.255.255.0

    • R(config-if)#no shutdown 

  • 配置Fa0/1接口;

     • R(config)#interface f0/1

    • R(config-if)#ip address 192.168.2.105 255.255.255.0

    • R(config-if)#no shutdown  

  路由器完成配置后输入show ip interface brief检查设置是否正确,如下图所示:

  

 

 

 

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

打开pc端desktop下的Web Browser,输入服务端的ip地址:192.168.2.104开始抓包。如下图所示:

抓取到的报文如下:

 

TCP报文: 

 

 

 

 

 HTTP报文:

 

通过课文给出的TCP报文首部格式图:我们可以对TCP的连接建立进行分析。

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

如下图所示:

 

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

分析图中的1、2、3个序号分别对应书中的三次TCP报文段交换过程即三报文握手:

  1. 首先由PC端创建传输控制模块TCB。然后向Server发送连接请求报文端,这时候首部中的SYN同步位=1,同时该报文段不能携带数据,故seq=0(x),ack=0(x),TCP客户进程进入SYN_SENT状态。
  2. 然后Server接受到请求报文段后,进行回复确认。在确认报文段中把SYN位和ACK位置为1,并把ack值+1(x+1)变为1。
  3. 然后PC端再次确认,ACK=1,ack值不变为1(x+1),seq值+1变为1(x+1)。(SYN=1时,表明这是一个请求连接或接受连接报文)

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

主要是为了防止以及PC失效的连接请求报文段突然又传送到了Server,因而产生错误(Server的许多资源会被失效的连接端口所浪费)

5.分析TCP连接释放

TCP连接释放抓取到的报文如下:

 

 三部分报文分别如下:

 

 同上诉分析TCP连接建立,我们先画出分析图:

 

从TCP报文段中我们可以看到只有三次交换过程:

  1. PC端发出连接释放请求,置ACK,FIN均为1,此时seq=103(即u=103)
  2. Server端收到连接释放请求后,置ACK,FIN为1,将seq=472(即v=472),ack=u+1=103+1=104
  3. PC端在收到Server发出的来连接释放报文后,对此发出确认。在确认报文段中置ACK为1,ack=w+1(不得而知),seq=u+1=103+1=104。

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

TCP是全双工模式,这就意味着,当PC发出FIN报文段时,只是表示PC已经没有数据要发送了,PC告诉Server,它的数据已经全部发送完毕了;只有当Server返回ACK报文段时,表示Server已经知道PC没有数据发送了,但是,这个时候PC还是可以接受来自Server的数据,Server可以继续传输需要传送的数据。当Server也发送了FIN报文段时,这个时候就表示Server也没有数据要发送了,只有这时候才是双方正式开始关闭传输通道,之前只是PC单方面释放连接。因此需要比连接多进行一次握手(连接建立是PC一端开始请求即可,而连接释放则需要双方都释放)。

 

 6.通过该实验产生的新的疑问

实际上,完成了整个实验,实现了TCP连接建立与释放之后,能够发现TCP的连接建立过程与课本中描述的完全相同。但是在完成实验的拓展——TCP连接释放的时候,像上文所述,它的报文交换只有3次,与课本的四报文握手并不一致,其中的一些数据也是不尽相同的。在完成的时候我做出假设是——Server端将第二次和第三次的报文握手过程整合到一个步骤了,这也就是上图中为何一个报文端有两个序号的原因(仅仅是我的大胆假设)。这样似乎能在一定程度上解释与课本不符的原因,但是还遗留了一个问题,在PC端的确认报文中ack=w+1,ack的值是无从得知的(因为并不知道w是之前哪个报文的值),从数据分析是得出了ack=v,也与课文不太一致。总之做完拓展后,我针对TCP连接的释放这方面的理论与实际产生了一定的困惑?

 

 

                                                                                                            2019-10-19     20:45:20