FTP上传大文件失败案例
一、拓扑图
AF路由模式部署,出口负载均衡设备,做了FTP的DNAT到AF WAN口,然后AF再做了一次DNAT到内网的FTP服务器。
二、问题 外网电脑连接FTP服务器后,无法将大于2M的文件上传到FTP服务器。
三、问题分析和排查 第一步:首先肯定是开启AF的直通功能,发现故障照样存在;
第二步:用内网电脑直接连接FTP服务器,发送可以成功上传大于2M的文件,说明FTP 服务器本身是正常的;
第三步:在AF WAN,LAN 和PC上分别同时抓包,重现问题过程:eth1wan.cap eth2lan.cap pc.cap (这一步需要注意的一点,由于这台FTP服务器是被动模式的,所以抓包的时候不能只指定20,21端口,否则你会丢失数据连接过程的数据包)
第四步:逐步分析数据包 先分析eth1wan.cap,如下图所示FTP命令连接是正常建立的。
再分析数据连接过程,从下图可以看到FTP服务器被动打开的端口是45101,所以我们在WIRESHARK里面就先过滤tcp.port==45101
如下图所示eth1wan.cap的数据连接过程的数据包出现了异常,可以看到有数据包分片丢失和重复的ACK。 可以看到FTP服务器一直在发送重复的ACK给外网的客户端电脑
那么问题来了,什么是ACK,为什么要一直重复发送ACK呢?
先来学习一下正常的TCP SYN ACK的流程,如下图所示: 其实ACK就是对对方发过来的数据包的一个确认,并期待下一个数据包的序列号。
之所有FTP服务器一直在发送这个重复的ACK,就是因为FTP服务器没有收到客户端发送过来的sequence number:388883456的这个数据包。
那么问题现在就明确啦,这个sequence number:388883456到底去哪里了呢?我们在PC.CAP和ETH1WAN.CAP分别过滤一下这个序列号tcp.seq == 388883456
PC.CAP如下图所示,可以看到PC发送了2个数据包,第二个是因为FTP服务器一直在发送重复的ACK触发的快速重传。
再看看ETH1WAN.CAP,如果所示AF的WAN口只收到了第二个快速重传的数据包。
四、结论 AF WAN口方向存在丢包,由于WAN口方向只有一台负载均衡设备,所以问题很有可能出现在这台设备上面。后面负载均衡的工程师过来检查了他们的设备,说问题不是他们导致的,于是我让客户直接AF WAN口接一台PC连接内网FTP测试,发现上传没有任何问题。那么至少可以证明问题确实不在我们AF设备。
五、知识点 1.理解SYN ACK的全过程 2.TCP为什么会知道丢包了? 3.什么是快速重传? |