FTP協议使用两个连接.doc

FTP协议使用两个连接。一个叫控制连接，另一个叫数据连接。FTP的命令和应答通过控制连接来交换，这个连接会存在于整个FTP会话过程中。另一方面，一个文件（或一个文件列表）通过数据连接来传送，这个连接是当每次文件传输时才新建立的。 ? 通常出于网络安全的考虑，大多数防火墙不允许除FTP控制连接之外的任何连接连到FTP的服务端口（默认是TCP的21端口）。虽然如此，当一个文件传输时，防火墙临时地认可数据连接。为了做到这点，防火墙跟踪控制连接的状态，并检测跟文件传输相关的命令。这就是所谓的状态检测。 ? PORT命令的格式如下： PORTspaceh1,h2,h3,h4,p1,p2CRLF ? 这里字符串“h1,h2,h3,h4”表示点分十进制的客户端的IP地址“h1.h2.h3.h4”。字符串“p1,p2”表示一个数据端口号（= p1 * 256 + p2）。地址和端口号都是十进制数。数据端口由客户端动态指定。另外，命令和应答以CRLF字符序列结尾。 ? Netfilter跟踪一个FTP控制连接，并获取TCP序列号和包含一个FTP命令行（以LF结尾）的数据包的数据长度。然后基于这些信息，它计算出下一个命令数据包的序列号。当一个这样序列号的数据包到达时，Netfilter分析数据包中的数据是否包含一个FTP命令。如果数据的头部是“PORT”，并且数据以CRLF结尾，于是Netfilter认为它是一个有效的PORT命令（实际的代码会更复杂），并从中取出IP地址和端口号。然后，Netfilter“期待”服务器主动建立一个到客户端指定的端口号的数据连接。当数据连接请求确实到达时，它会认可连接，同时连接建立。一个没完成的命令，即所谓的“不完全的”命令，会因为无法真实的跟踪而丢弃。 ? ?从大的方面来说，netfilter就是一张大的流转发表，这个转发表的查找是基于流的五元组（sip/dip/sport/dport/type），流是有方向的，我们分别定义为正向和反向。用一个图更为形象的说明流表的组织形式。 ? 通过上图，我相信一定能够客观真实的反映流表的组织形式了吧，正向流和反向流分别对应两个方向，他们在hash表里面映射不同的表项，但是他们所关联到的是同一个连接跟踪表项。 系统的连接跟踪会在四个地方进行处理，分别是路由前，路由后，本地收以及发。本地收发也不在讨论范围内，需要的自己察看看，关键在于触类旁通。首先说说最简单的，没有动态协议的情况。在路由前接收到一个报文，接着跟踪报文信息调用二层以及三层的回调函数，构造出报文的5元组信息(tuple，后文简称为元组)。接着通过这个5元组即我们上文所说的正向流或者反向流来查找对应的连接跟踪信息（nf_conn）.情况简单的说就是两种，存在或者不存在，存在就返回这个结构。如果不存在就创建连接信息即nf_conn,但是这个时候并没有加入hash表里面去，所以还挂在unconform链上。 因为上文说了我们暂时不讨论动态协议，所以在创建连接信息的时候，查找expectation和helper肯定都没有，所以也就直接返回了。这儿可以看到两者的不同在于创建新的连接与否。有了这个nf_conn连接跟踪表，我们就需要对这个连接的的状态进行调整。具体的状态机可以参考代码，TCP的比较复杂一些，ICMP和UDP的差不多。到此为止，路由前就处理完了，我们可以看到要么查找到简单处理，要么构建一个新连接，但是挂到全局的未决链上。 接下来的处理就是路由后了，在发出报文之前，这个时候主要就是做一些错误检查，然后把前面处理的未决的连接跟踪加入到前面看到的hash表项里，让系统能够检索到。 现在我们加入动态协议再重新看一下这个流程，以tftp或者ftp为例都可以，简单起见，tftp吧。下面这个大的流程很重要，切记切记，不懂也首先记住，然后再分析。在创建新的连接跟踪信息时候，首先判断一下这个连接是不是期望连接，如果是就关联到之前的主链接上面。然后不管是主链接还是期望连接都查找相应的helper函数，当然主连接通过全局表查找，而子连接是在主连接的help创建时候赋的值。对于简单的动态协议，其子连接是没有helper函数的，例如tftp或者ftp。 上面的话记牢了吧，首先查找期望连接，然后查找helper函数。这是因为一些动态协议，其控制协议创建好了expectation后，挂到全局表，接下来就是数据通道，而这个数据通道就是期望连接，所以虽然是新建连接，但是也是我们所预知的，所以和其master关联。 另外就是helper函数，例如tftp在模块加载时候就注册了这个helper，当我们新建一个连接，会查找这个表看是否是其中的一种协议，很幸运，我们就是tftp那么首先把这个helper关联到这个连接。路由器的处理就