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

1.我的信息

• 陈韵
• 201821121053
• 计算1812

2.实验目的

• 使用路由器链接不一样的网络
• 使用命令行操做路由器
• 经过抓取HTTP报文，分析TCP链接创建的过程

3.实验内容

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

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

4. 实验报告

4.1 创建网络拓扑结构

　　　

4.2 配置参数

4.2.1 配置客户端

　　客户端的参数配置以下：

　　

4.2.2 配置服务端

　　服务端的参数配置以下：

　　

 

 

4.2.3 配置路由器

　　(1)激活路由器

　　

 

 

　　解释： 　　

　　Router>enable # 进入特权执行模式 

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

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

　　Router(config)#hostname R # 将路由器名称配置为R 

 

　　(2)配置端口 Fa0/0与Fa0/1

 　　

 

 

 　　解释：

　　R(config)#interface Fa0/0 

　　R(config-if)#ip address 192.168.1.80 255.255.255.0 

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

 

　　(3)配置路由器协议

　　

 

 

 　　解释：　

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

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

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

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

 

　　(4)查看是否配置完成

　　

 

 

 

4.3 抓包，分析TCP链接创建过程

4.3.1用客户端的Web Browser访问服务器：

 

 

4.3.2 仿真界面完成抓包

　　　

 

 

 　　

 

 

4.3.3画出TCP链接创建示意图

 

4.3.4分析序列号和确认号的变化

 　   （1）第一次握手:Client将标志位SYN置为1，随机产生一个序列号值seq=x，并将该数据包发送给Serve，PC进入SYN_SENT状态，等待Serve确认

　　（2）第二次握手:Serve收到数据包后由标志位SYN=1知道Client请求创建链接，Serve将标志位SYN和ACK都置为1，ack=x+1，随机产生一个值seq=y，并将该数据包发送给Client以确认链接请求，Server进入SYN_RCVD状态。

　　（3）第三次握手:Client收到确认后，检查ack是否为x+1，ACK是否为1，若是正确则将标志位ACK置为1，ack=y+1，并将该数据包发送给Server，Server检查ack是否为y+1，ACK是否为1，若是正确则链接创建成功，Client和Server进入ESTABLISHED状态，完成三次握手，随后Client与Server之间能够开始传输数据了。

4.3.5解答：为何链接创建须要第三次握手

　　3次握手完成两个重要的功能，既要双方作好发送数据的准备工做，也要容许双方就初始序列号进行协商，这个序列号在握手过程当中被发送和确认。目的是为了解决网络中存在延迟的重复分组问题。

　　只有2 次握手极可能形成“死锁”：假定C给S发送一个链接请求分组，S收到了这个分组，并发 送了确认应答分组。按照两次握手的协定，S认为链接已经成功地创建了，能够开始发送数据分组。但是，C在S的应答分组在传输中被丢失的状况下，将不知道S 是否已准备好，不知道S创建什么样的序列号，C甚至怀疑S是否收到本身的链接请求分组。在这种状况下，C认为链接还未创建成功，将忽略S发来的任何数据分 组，只等待链接确认应答分组。而S在发出的分组超时后，重复发送一样的分组。致使死锁的形成。

5. 拓展

（1）分析TCP链接释放

 

（2）图为何会跟课本不同

　　在半关闭状态，服务器极可能又发送了一些数据。而客户端收到服务器的链接释放报文后，必须发出确认。此时的TCP链接尚未释放。

（3）为何须要第四次握手 

　　关闭链接时，当Server端收到FIN报文时，极可能并不会当即关闭SOCKET，因此只能先回复一个ACK报文，告诉Client端，"你发的FIN报文我收到了"。只有等到我Server端全部的报文都发送完了，我才能发送FIN报文，所以不能一块儿发送。故须要四步握手。

 （4）疑问

若是链接已经创建，但客户端忽然出现故障的话，服务端会立刻终止交易仍是傻傻等下去？又或者机制比较聪明先试探一下确认客户端真的崩溃后才断开链接？？