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）疑问
如果连接已经建立，但客户端突然出现故障的话，服务端会马上终止交易还是傻傻等下去？又或者机制比较聪明先试探一下确认客户端真的崩溃后才断开连接？？