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）为什么连接建立需要第三次握手
这主要是为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。
所谓“已失效的连接请求报文段”是这样产生的。考虑一种正常情况。客户端发出连接请求，但因连接请求报文丟失而未收到确认。于是客户端再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接。客户端共发送了两个连接请求报文段，其中第一个丢失，第二个到达了服务端。没有“已失效的连接请求报文段”。
现假定出现一种异常情况，即客户端发出的第一个连接请求报文段并没有丢失，而是在某些网络结点长时间滞留了，以致延误到连接释放以后的某个时间才到达服务端。本来这是一个早已失效的报文段。但服务端收到此失效的连接请求报文段后，就误认为是客户端又发出一次新的连接请求。于是就向客户端发出确认报文段，同意建立连接。假定不采用三次握手，那么只要服务端发出确认，新的连接就建立了。
由于现在客户端并没有发出建立连接的请求，因此不会理睬服务端的确认，也不会向服务端发送数据。但服务端却以为新的运输连接已经建立了，并一直等待A发来数据。服务端的许多资源就这样白白浪费了。
采用三次握手的办法可以防止上述现象的发生。例如在刚才的情况下，客户端不会向服务端的确认发出确认。服务端由于收不到确认，就知道客户端并没有要求建立连接。
4. 拓展
（1）分析TCP连接释放
TCP连接释放示意图：
为什么图和课本不一样？
课本上的连接释放过程，在客户端发出连接释放请求后，服务端又发送了一个确认报文，然后进入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