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

Posted 2020-11-16 lty1661489001

0 个人信息

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

1 实验目的

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

2 实验内容

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

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

3. 实验报告

3.1 建立网络拓扑结构

网络拓扑图如下图所示：

3.2 配置参数

( 1 ) 客户端参数配置：

 ( 2 ) 服务器参数配置：

 ( 3 ) 路由器参数配置：

( 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连接建立示意图

如下图所示：

（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）为什么连接建立需要第三次握手

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

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

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

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

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

4. 拓展 

（1）分析TCP连接释放

TCP连接释放示意图：

 

 

为什么图和课本不一样？

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

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

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

（2）通过该实验如果有产生新的疑问，可以写出来，并尝试自己解决问题

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

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

参考文章

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