wireshark 包 分析 之 ftp 协议 还原 问题

问题：

由 ftp  文件 还原 问题 引出的 包的丢失 进行的 简要分析。

  Understanding [TCP ACKed unseen segment] [TCP Previous segment not captured]

    

That very well may be a false positive. Like the warning message says, it is common for a capture to start in the middle of a tcp session. In those cases it does not have that information. If you are really missing acks then it is time to start looking upstream from your host for where they are disappearing. It is possible that tshark can not keep up with the data and so it is dropping some metrics. At the end of your capture it will tell you if the "kernel dropped packet" and how many. By default tshark disables dns lookup, tcpdump does not. If you use tcpdump you need to pass in the "-n" switch. If you are having a disk IO issue then you can do something like write to memory /dev/shm. BUT be careful because if your captures get very large then you can cause your machine to start swapping.

My bet is that you have some very long running tcp sessions and when you start your capture you are simply missing some parts of the tcp session due to that. Having said that, here are some of the things that I have seen cause duplicate/missing acks.

1. Switches - (very unlikely but sometimes they get in a sick state)
2. Routers - more likely than switches, but not much （路由） 
3. Firewall - More likely than routers. Things to look for here are resource exhaustion (license, cpu, etc)（防火墙）
4. Client side filtering software - antivirus, malware detection etc.（客户端过滤软件防病毒，恶意软件检测）

  

 图：

 

tcp  retransmission 的 tcp  重传。

 

seq 表示 序列号 ， ack 表示 确认收到包的数量， len 表示  此包的 大小。 

seq是序列号，这是为了连接以后传送数据用的，ack是对收到的数据包的确认，值是等待接收的数据包的序列号。

可以看到   图1， seq = 558 ， ack表示确认之前收到的 1812个包。 len的长度表示此包内容长度，  那么下次包的数量应该为558+17 = 575 

图2：

  ack   确认之前收到的575 个包， 然后 序列号为 1812 ， len = 25   那么下个包 照理应该 ack 确认包 长度 为 1837

  

图3：

我们实际看到的，ack = 1854 ， 并不等于 1837  那么 这段 字节就丢失了， 所以报了 （tcp  acked  unseen  segment）。

总结：

     在回顾 sucricate的机制， 包的重组， 应该是在 遇到 包丢失的情况下， 截断了 相应流程 方向的包（response，  request）；所以 会产生一系列的问题， 如ftp；

ftp 的机制， 首先， ftp分为 主动 port，被动pasv 模式， 一般都 采用被动模式， 防止从服务端 到客户端的 入向 被 防火墙 过滤。数据连接和控制连

接 都是由 客户端 发起， 控制端， 通过 pasv 的命令 然后去获取端口，ip  添加 链表， 然后 数据会话 那边 匹配 到合适端口， 然后 开始数据的传输。

如果 出现 了 上述的 情况， 那么 respones 丢失了 ， 那么 包重组的时候，就丢弃了之后的部分， 那么 就不会进入 我们的 ftp  responses 函数， 那么 端口号将获取

不到，但是 数据会话 依然使用的协商好的 端口， 所以会出现 还原不出来的 问题。

#  ADD  BY  LCF  2015-07-01

主动模式    与 被动模式的 流程 概念

1、主动模式 与被动 模式 都是 相对于  ftp 服务端 而言的。

2、 其次ftp 交互模式 是两条 tcp 流，一条用于控制会话的交互，一般传输文件名文件大小，指令等， 另外一条流 用于数据传输，每传一个文件 都会重新创建一条流

3、  被动模式 简单 交互 流程

首先， 

      客户端 发送 一个 PASV指令 给服务端   （控制会话  连接服务器 21端口）

         服务端 接收到了 信息，之后 给客户端 返回一个信息  227 entering pasv mode（172，168,2,105,4,11）

        该信息包含了 端口信息 （4*256 + 11 = 1035） 【一般这个端口处于自增长状态】

客户端     

               收到 该条信息，就由任意端口发起另外一条数据连接  去连接端口 1035   

 

4、主动模式

客户端：

发送 PORT 指令，并提供 端口信息 （表示客户端打开该端口等待 服务端连接）发送 服务端  （控制会话  21 端口）

服务端：

收到该条信息，由20端口发起 像 客户端 端口发起连接 

【因此， 这种方式 ，外部连接 连接内部主机 容易被防火墙 阻塞， 或者 长时间连接不上，客户端 就再次发送端口信息，服务端 再次连接】

2015-07-31

由主动模式  联想到 的一个问题：

假设  目前 我们 局域网 ip：192.168.2.101   外部 ftp 服务器  XXXX

我们客户端 采取 主动模式  连接  外部ftp服务器  匿名成功登陆

交互模式 上面 已经 说清楚了 ：  

        1、首先  客户端 发起向 服务端的 tcp连接，完成三次握手 认证 成功登陆

        2、再由 客户端 发送一条  包含 ip，端口的信息  ：  如：  PORT  192，168，2,101  ， 199,39

               那么 就是告诉 服务端  客户端将 192.168.2.101 将开启 199*256 + 39 的端口 监听

        3、服务端 连接 上述的 端口。

那么问题来了：

        为什么 远端 服务器 能够 连进 我得 内部局域网的 机器呢？  （这边 暂时 不考虑 防火墙 阻塞，端口占用的问题）？？？？

我觉得 应该是这样

      1、 命令会话既  内网机器 和 外网交互， 其中必须经过 网关 这就是我们这边的路由器，将数据由路由转发出去，此间路由处会产生一条nat                转换日志记录下某个ip + 端口 的 snat的 映射关系，那么 外网机器 回复的响应包 会寻找然后 发向指定的 内部机器。

      2、 数据连接既  外网机器 和内网机器的交互， 这是由 外网 发起想内网的连接，由于控制会话已经 建立了一个连接，数据会话应该依旧会使             用之前 控制会话 的记录 原路返回 找到 我们的 路由器， 在通过路由器 连接上  指定的 内网机器。

      3、说的  不是很清楚， 有错误 望留言 赐教！

23:38  2015-07-31

上面的 我认为 是错的  ， 其实 控制回话的 时候 会通过 ALG（应用层网关）处理  现在 上个图 来说明一下

        

2016-4-6

为什么 FTP 需要分两个通道  控制 和命令会话？

以被动模式为例：FTP传输一个文件，需要跟服务器协商一个端口  ，客户端与之相连接，在批量传输文件的过程中，比如拉一个文件夹，则命令会话 逐次执行上传指令 依次上传文件， 等数据回话 传输结束，服务端会告诉客户端 我把文件传输结束了，然后控制会话执行第二个文件的上传命令以此类推？（并非所想的并行传输数据，也许是工具问题） 那么为什么还要区分呢？

纠结了一段时间，摘自qq网友：

 这个问题大了，任何网络协议都可以分为控制信息和数据信息两部分，这两部分实现方式可以同一连接传输（比如http）也可以不同连接传输（比如ftp）。
控制和数据分连接传输的优点，我目前想到的有以下几点：
1、保证控制信息的独立性，精确到达，不受数据流影响，甚至可以控制流走tcp，数据流走udp；

2、控制包格式和数据包格式分别定义分别实现，降低实现逻辑复杂度；

3、一个控制流对应多个数据流进行控制； 

2016-7-19 

关于ftp 数据传输流 的识别方式：

主动模式： 20端口

被动模式：按照控制会话协商好的端口  递增 or 不变 

今天在 ndpi源码里面  又看到了 基于文件本身的判断 匹配固定文件开头，比如rar “”Rar!“” pdf "%PDF"   ....但是 这种识别方式 还是不全面的 ，目前而言还是通过端口 在匹配 实际命令会话的 数据流 比较靠谱！