厦门大学实验五：运输层和应用层协议分析

实验目的

学习传输层应用层协议

实验内容

任务一： TCP与拥塞控制

1.1 TCP连接观察

1. 在pc2打开一个监听端口
2. PC1 curl成功
3. 生成Flow Graph
4. 时序图
5. 分析报文段，我分析的是服务器传回的SYN,ACK包。
   • 可以看到两个机子发送的端口分别为80和59500
   • 序列号为0，标志从远端想目的端的数据流，表示报文第一个数据字节的顺序号
   • 确认号为1，包含了发送确认一段所期望收到的序列号
   • 首部长度为40bytes
   • 标志为6位，可以同时为1，如图图
   • TCP选项。至少1个字节的可变长字段，标识哪个选项有效。Kind=0:选项表结束， Kind=1:无操作， Kind=2：最大报文段长度，Kind=3:窗口扩大因子， Kind=8:时间戳。如图为2

1.2 异常传输分析

1. 尝试连接未存活的主机或对未监听端口。

   1. 访问不存在主机，抓包结果，总共发送了五次syn报文。可以看到重新传送时间为2的指数倍数增长，开始为1然后是2，4，8

   2. linux主机系统TCP参数为为6

   3. 更改SYN重传送次数后，再次抓包

   4. 关闭服务器端的httpserver后，再次curl服务器ip地址得到应答报文为一个RST/ACK报文，不是SYN/ACK。TCPsocket在收到RST后就立刻关闭。所以通信就终止了。

      • 分析如图收到了一个RST，ACk报文

   5. 运行 nmap -sS <PC2 的 IP> 扫描服务器，并抓包

   6. SYN扫描原理

      -sS参数表示使用TCP SYN方式扫描TCP端口，是一种半开放扫描。发送一个SYN然后等待回应，若收到SYN/ACK表示端口开放，若RST表示没有监听者。如果数次重发后仍没响应， 该端口就被标记为被过滤。如果收到ICMP不可到达错误 (类型3，代码1，2，3，9，10，或者13)，该端口也被标记为被过滤。

      • 如果端关闭放则server端回复RST,ACK
      • 如果端口关闭则server端发送SYN/ACK,Clinet再发送RST断开
      • 如下服务器端22号端口返回SYN,ACK，客户端立刻发送一个RST断开连接

2. 客户端发送了第一个 SYN 连接请求，服务器无响应的情景

   1. telnet服务器可以看到连接已经建立

   2. 防火墙拦截服务器的SYN ACK

   3. 再次尝试连接，观察TCP状态。客户端处于SYN-SENT状态

      服务器端处于SYN-RECV状态

   4. wireshark捕获异常报文

   5. 服务器端在一段时间后的SYN-RECV后自动释放端口，大概有一分钟时间

   6. SYN/ACK重传送了7个包，间隔时间呈现指数增长。间隔为1，2，4，8

   7. 修改服务器端SYN ACK 重传次数后收到6个包，观察每个包间隔时间可以发现，这六个包分三批发送的没批发送两个

3. SYN 洪泛。在服务器端 sudo echo “0”>/proc/sys/net/ipv4/tcp_syncookies 禁用 syn- cookies，通过 sudo sysctl -w net.ipv4.tcp_max_syn_backlog = 6 指定所能接受 SYN
   同步包的最大客户端数量为 6；在客户端运用 netwox 工具对服务器监听的端口产生大量 SYN
   连接请求 (如 sudo netwox 76 -i 192.168.100.144 -p 23)，再使用正常的连接工具 (如
   telnet) 尝试连接，观察交互情况 (特别是服务器端的 TCP 连接状态)，抓包分析，解释 SYN 洪
   泛攻击原理与对策。

   1. 攻击过程中服务器端许多接口都处于SYN-RECV状态
   2. telnet观察服务器状态，可以看到一个服务处于TIME-WAIT的状态
   3. 洪泛攻击原理：attacker发送tcp到server,当server返回ACk后,不尽兴确认。此时两节就处于把半挂起的状态，由于服务器在处理TCp请求是,会在协议栈留缓冲区来存储握手过程,当许多请求发出却不连接确认,服务端就会被耗尽资源.
   4. 观察wireshark抓包发现，发送了许多的SYN请求
   5. 防御对策
      • 增加TCP backlog队列
      • 减少SYN-RECEIVED的时间
      • SYN缓存
      • SYN Cookies

1.3 拥塞控制

1. 任一端限制网卡传入/传出带宽为10Mbps 以下：使用虚拟机作为实验机，可在VMWare Player
   中的虚拟机设置→网络适配器→高级中设置；物理机可使用wondershaper 命令进行限速。
   再启动应用(可以是http wget，也可以ftp 下载/上传) 传输大文件观察。

2. Wireshark 捕捉全部传输过程数据，找出该网络活动的拥塞点，并结合Analyze→Expert Infor-
   mation、Statistic→IO Graphs、Statistic→TCP Stream Graphs(如图1.3–5)，分析此传输过程中的
   慢启动、拥塞避免、快速恢复等阶段。

   • 捕获报文段

   • IOgraph如图

   • 放大详细讲解如下是一个很经典的慢启动，逐步填充网络容量

     

   • 经过一段时间进入快速还原阶段，队列长度快速变大

   • 

   • 之后随着传输时间延长，最终会处于一个稳态，拥塞避免。发生拥塞之后会快速提高消息队列长度，知道一个稳态值之后会缓慢增加。

3. TCP 竞争观察：类似以上试验，我们在一个大文件传输过程中，迅速启动另一应用，双向进
   行大文件传输，观察两路（或两路以上）TCP 连接的速率变化

   • 我在两个机子上同时传输大文件，并且都设置了带宽限制得到结果都IO GRAPH
   • 之前是只有一台机子下载的情况，后半段是两台机子同时下载时候。可以看到双向传输时，单位时间的发包速度提高了一倍，但是发生拥塞的可能性也增大了。可以发现后半段一直都有TCPerrors

任务2：FTP协议分析

1. 实验步骤：

• 在Linux下使用命令行访问ftp://ftp.rfc-editor.org

• 下载legal目录下的任一文件

• 期间运行Wireshark，捕获并过滤FTP访问所生成的TCP流

2. 要求

• 这次访问一共生成多少个TCP流？每个流做了哪些事情？在哪些端口号上工作？

• 切换FTP工作模式（主动PORT和被动PASV），重复上述捕获，比较两种模式的区别，并说明各自适用于什么场景?

• 被动模式

1. TCP流有几个?

   • 首先有服务器端口21打开，与客户端沟通信息
   • 当服务器客户端下载上传文件时，生成一个随机端口号与客户端传输数据，而客户端也生成一个心得端口号与之通信
   • 总结一下服务器端有21和30074（随机端口）客户端有52944和46272（随机）工作

2. 两种模式的区别

   1. FTP主动模式
      主动模式的FTP工作原理：客户端从一个任意的非特权端口N连接到FTP服务器的命令端口，也就是21端口。然后客户端开始监听端口N+1，并发送FTP命令“port N+1”到FTP服务器。接着服务器会从它自己的数据端口（20）连接到客户端指定的数据端口（N+1）。

   2. FTP被动模式：这就是所谓的被动方式，或者叫做PASV，当客户端通知服务器它处于被动模式时才启用。在被动方式FTP中，命令连接和数据连接都由客户端发起，这样就可以解决从服务器到客户端的数据端口的入方向连接被防火墙过滤掉的问题。

3. 分别应用场景

   主动模式传送数据时是“服务器”连接到“客户端”的端口；被动模式传送数据是“客户端”连接到“服务器”的端口。 主动模式需要客户端必须开放端口给服务器，很多客户端都是在防火墙内，开放端口给FTP服务器访问比较困难。 被动模式只需要服务器端开放端口给客户端连接就行了。

实验总结

1. 问题1：开始复制老师的虚拟机，直接解压打开，遇到了两台虚拟机的mac地址一致的情况。有一台虚拟机无法上网。
2. 解决方法：使用txt方式打开虚拟机vmx文件，修改mac地址。
3. 问题2： 拥塞控制传输过程现象一直不明显，是了很多次，还是没办法。
4. 解决方法： 没有根本解决，但是我选取了现象最为明显的IO Graphs进行分析，还是能够观察到慢启动，拥塞避免等过程的。
   虚拟机无法上网。
5. 解决方法：使用txt方式打开虚拟机vmx文件，修改mac地址。
6. 问题2： 拥塞控制传输过程现象一直不明显，是了很多次，还是没办法。
7. 解决方法： 没有根本解决，但是我选取了现象最为明显的IO Graphs进行分析，还是能够观察到慢启动，拥塞避免等过程的。
8. 实验心得：实验没有上一次那么难，总体上还可以接受。但是还是需要话很多时间抓包，配置，再抓包分析。增强了我对TCp连接和SYN的理解。