当下载速度相对于封包来说比较大，即封包的大小相对于下载速度来说算是比较大的时候就会出现当filezilla client的进度篮还显示在下载的时候，调试信息已经输出平均速度。
下列以100kb/s的限制速度下载一个1MB的封包就出现了这个问题。

分析：主要原因在FTP的下载数据通路和命令的数据通路是分开的，应该是在proxy已经接受完毕server所传的数据，server发送传送完毕的226FTP信息。而此时数据还没有从proxy传完回client。使得当下载速度相对封包来说比较大的时候，误差会很明显。误差的值基本就取决于proxy接受server封包的window size

这个问题非常的tricky，如果window size调的太小，又会出现文件传不动的情况。TCP速度下降太多，使速度不可调。

存在问题: socket缓存区过大，客户端数据过早发送完毕，导致转发超时
客户端在上传文件的时候，很快就通过socket把文件都写到了proxy的socket层，存在socket层的缓存上，socket read是一个读缓存的过程。这就导致客户端认为已经传完了，但是实际proxy还有没转发完，client在传完20秒之后，没有收到服务器的响应，导致超时重连。而此时服务器还没有收完数据，所以当然不会反馈。
解决方法：把socket的缓存区调小，就会将数据阻塞在网络外面。客户端的socket的缓存区就会很快满，然后write就会阻塞。

1. 问题描述:
   通过FileZilla，连接到proxy的时候，有几率会出现服务器连接失败。而且在第一次切换目录，或者创建多个下载任务的时候出现错误的几率增大。

2. 错误信息:
   问题出现时，proxy的日志及FileZilla的信息如下：

只能通过客户端响应超时，与proxy进行重连来等待回复，且可能需要重连多次才会成功。