摘要:
本文主要讲述如何使用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报文首部格式图:我们可以对TCP的连接建立进行分析。
(1)画出TCP连接建立示意图
如下图所示:
(2)分析序号和确认号的变化
分析图中的1、2、3个序号分别对应书中的三次TCP报文段交换过程即三报文握手:
- 首先由PC端创建传输控制模块TCB。然后向Server发送连接请求报文端,这时候首部中的SYN同步位=1,同时该报文段不能携带数据,故seq=0(x),ack=0(x),TCP客户进程进入SYN_SENT状态。
- 然后Server接受到请求报文段后,进行回复确认。在确认报文段中把SYN位和ACK位置为1,并把ack值+1(x+1)变为1。
- 然后PC端再次确认,ACK=1,ack值不变为1(x+1),seq值+1变为1(x+1)。(SYN=1时,表明这是一个请求连接或接受连接报文)
(3)解答:为什么连接建立需要第三次握手
主要是为了防止以及PC失效的连接请求报文段突然又传送到了Server,因而产生错误(Server的许多资源会被失效的连接端口所浪费)
5.分析TCP连接释放
同上诉分析TCP连接建立,我们先画出分析图:
从TCP报文段中我们可以看到只有三次交换过程:
- PC端发出连接释放请求,置ACK,FIN均为1,此时seq=103(即u=103)
- Server端收到连接释放请求后,置ACK,FIN为1,将seq=472(即v=472),ack=u+1=103+1=104
- 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