FTP 通信抓包

继上一篇《CentOS 6.5 手动搭建FTP服务器--vsftpd》，我们再来看一下FTP通信的过程是怎么样的。这里我们使用了最流行的网络抓包工具：Wireshark，版本是2.4.2。我们把它安装在了client端，也就是实验机上的Windows虚拟机。我们把整个操作过程所触发的所有通信包都抓了下来，从底层来窥探下FTP实现机制 -- 登录FTP服务器，运行ls命令查看文件列表，并用get命令下载服务器上的一个文件，最后退出FTP登录。

FTP Server IP： 192.168.111.15

FTP Client IP： 192.168.111.13

分析之前还要免费做个安利，公司内的网络大牛的一本抓包分析图书《Wireshark网络分析就是这么简单》，本文从中受到了很大启发也做了些借鉴，侵权即删。

1. ARP

同一网段内的主机在二层网络需要Mac地址来通信，client端发起了ARP广播查询，查询server的mac地址。Server响应正确的mac地址

2. TCP 三次握手

Client端发起与Server的TCP通信

3. FTP 服务器应答FTP请求，并与client交互识别身份完成登录

上述三个包展现的是TCP连接建立完成后，FTP server返回的应答以及client的ACK。透过wireshark的解析，我们看到Response 220的具体含义是：Service ready for new user（220）

以上是身份识别过程的包，到此为止这也是TCP登录过程中所有的通信包，前提是你输入完用户名密码后没有做其他的操作，比如ls查看文件列表。可以看到，每一个TCP请求或者应答都会伴随一个TCP的ACK包

4. 用户请求文件列表

18 - 20:

client和server交互通信所有的端口， client端口的计算方法为192x256+42 = 49194。这里没有协商任何有关server端口的信息，那么server端口是怎么来的呢？答案在FTP server的配置文件中(/etc/vsftpd/vsftpd.conf)：

connect_from_port_20=YES

21:

Client 发出ls命令

22 - 24:

Server发起与client的三次握手

25 - 26:

Server应答FTP请求，返回ls命令的data

27,28,31,32:

Server应答完成立即断开TCP连接，这里是4次挥手的过程

29 - 30:

这里是client返回ACK应答Server发来的文件列表数据，包括了FTP和TCP两个ACK包。值得注意的是，虽然这两个包出现在TCP4次挥手过程中，并不代表这两个包和TCP断开连接有关系，实际上，TCP server发送完数据后会立刻断开连接。这里的两个包实际上是“控制连接”的两个包，仔细观察可以看到，通信端口是49131->21。而“数据连接”通信是在49194和20之间。

可能到了这里读者也已经看了出来，FTP的工作方式分为两部分，一部分是控制链接，用于传输控制信息，具体工作在建立链接过程；而另一个部分则是数据链接，每当client请求数据，client和server就会重新建立一个TCP链接用于数据传输，数据传输完成后，这个TCP链接就会被断开。其中，控制链接的TCP通信是由client发起，而数据链接的FTP通信则又server端发起。而每次数据传输，都需要控制链接和数据链接的共同协作完成，数据链接完成数据交互，控制链接也要做传输完成应答。

5. 用户请求文件

这三个包体现的是用户切换至binary传输模式发生的网络通信。client请求，server应答，client返回ACK。

同上面第四部分用户执行ls命令相同，当用户发出 get b.txt命令后，首先是client和server交互通信端口信息(38-40)。然后是server利用协商出的新端口发起和client的新的TCP链接(41-43)，并传输数据(44-45)。数据传输完成后断开这个TCP数据链接(46-47, 50-51)。而TCP的控制链接也对传输完成做了确认(48-49)。

6. Client断开FTP链接

当用户在终端敲出bye命令后，我们看到client发出了一个FTP包，请求QUIT FTP链接，随即server友好地回应了一句Goodbye。之后又是sever发起的TCP四次挥手断开控制链接。所以，控制链接是伴随整个FTP链接生命周期的。至此，整个FTP通信过程分析完毕，是不是感觉FTP是个比较简洁的协议呢？