映雪青帖 – 第 27 页

在前面的一篇文章中（Day#3158），曾经提到本地的内网与放在公网上的某服务器相性不合，被动FTP总是不能正常工作，主要表现为长时间的数据传输（无论上传下载）时，过一段时间（大约30秒至1分钟）速度就会急剧下降，到最后数据连接超时关闭。

曾尝试过许多办法尝试解决这个问题，包括对服务器本身的配置和FTP服务器配置的修改，甚至直接关掉服务器的防火墙，但都没有成功，故而认为问题主要出现在本地内网出口上的设备上。据个人所知，出口上有一个所谓的「上网行为管理系统」，负责管理内网用户的上网行为，还有一个线路自动切换的设备（或策略）来判定对公网的连接应该走电信或者联通（网通）的线路，这些都可能是问题所在，但集团网络中心的人不愿为单个问题去修改设置，所以剩下能修改的地方都已Out of control。

如果说专门的FTP客户端（例如FlashFXP）还能通过一定手段重传的话，那么正在用的一款网站内容采集软件则是主要的障碍之一，这款软件的PORT模式运行正常，但PASV模式就问题百出：一旦遇上数据连接断线，那么重新连接后，就会一个劲的报续传失败，最后整篇文章因为这个而发布失败（因为设定了先上传文件再发布文章，总不能在一篇文章里到处都是×和半截图吧）。

经过与FTP服务器FileZilla Server的作者讨论，并dump了数据包进行分析，发现这款软件有一个很诡异的设定：当在PASV模式下续传文件时，软件的运行过程如下：登录并切换目录后，首先发送SIZE查询已上传的文件大小，然后发送APPE指令通知服务器将要续传文件，但接下来程序没有发送任何文件数据，就以正确的方式（TCP FIN）关闭了数据连接（而不是RST等异常关闭），于是服务器响应226 Successfully appended file，软件会再次使用SIZE查询文件大小，很显然大小与「续传」前相同，于是上传「失败」，重复几次达到最大错误次数后，软件即报上传失败。

与软件作者联系人家不承认，ft。

但是软件还得用，怎么办呢，有的人说换一款软件不就好了，那你帮我重写80多条采集规则谢谢，那么就只能在工作相对正常的PORT模式上下功夫。

经过一段时间的搜索及实验，暂时用Bitvise SSH Server这款SSH服务器解决了问题，使用同一公司出品的Bitvise SSH Client打开SOCKS5代理，在使用FlashFXP试验时，PORT和PASV模式都使用正常。

但某采集软件就是个奇葩：不论如何进行设定，PORT模式向服务器汇报的IP总是127.0.0.1（因为Socks5代理绑定到本地），而PASV数据包的错误一如既往，看来并没有通过SSH通道进行加密（如果加密了理应规避PASV FTP的不正常现象）。

最终的解决方案是：绕过原本部署的FileZilla Server，使用Bitvise SSH Server本身的SFTP功能和Bitvise SSH Client的SFTP-to-FTP Bridge，将采集软件连接的FTP指向本机的SFTP-FTP Bridge并强制使用PORT模式，这下清静了。

因为本Blog没什么人看所以详细的步骤略过（其实配置起来也很容易，另外一点就是感觉写多了好麻烦），如果有需要请于下方评论，我再把详细的步骤写出来。

2014年10月9日

Day 3172 Windows Update出现80200010错误的解决方法

草草笔记 1

首先吐槽下百度的搜索结果……算了我已经懒得吐槽那些知道大神了。

其实微软官方解释的已经很清楚了，但微软的KB一向不好搜，所以还是在这里整理一下：

这个错误代码的含义是后台传输服务（Background Intelligent Transfer Service）与更新服务器通讯时出现了问题。

一、检查网络连接，如果网络是通的，尝试更换本地连接的DNS（有时自动获取的DNS会拒绝解析），如更换为114.114.114.114和114.114.115.115。

二、如果以上步骤没有解决问题，尝试将以下内容存为批处理并执行，注意Windows Update的窗口如果已经开着，要重新打开：

net stop bits
net stop wuauserv
Ipconfig /flushdns
cd “Documents and Settings\All Users\Application Data\Microsoft\Network\Downloader”
del qmgr0.dat
del qmgr1.dat
net start bits
net start wuauserv

以上操作将清除BITS（后台传输服务）的队列，强制系统对Windows Update的补丁重新进行下载而不是续传。

2014年9月25日

Day 3158 被动模式FTP服务器在Windows 2008 R2下数据传输缓慢以致断线的问题改进方法

草草笔记 4

单位从2013年使用自管服务器以来，一直使用FileZilla Server作为FTP服务器。由于单位处于一个大的内网之下，必须使用PASV模式连接公网上的FTP服务（顺便吐槽一下集团的网络中心，只给内网服务器开20、21却不给留几个PASV模式的端口，提出来还被吐槽说我比你懂得多，这台服务器又在配置上与内网隔离，害得我们只能用其它协议向上发送文件），所以将某个范围开启为PASV的预留端口，并在防火墙上打开了20、21和PASV的端口范围，同时允许了服务器主程序与公网通讯。

但问题来了，约两年的时间以来，FTP服务器一直不太好用，尤其是在下载大批小文件的情况下，传上十几二十几个文件数据连接就会开始反应缓慢，掉到没有速度，直到服务器超时自动断开，甚至在绕过防火墙后问题依旧，百思不得其解。

最近在查看FileZilla的Wiki时，发现其中有一个章节「Network Configuration」[1]中提到：

Open a command prompt with administrative rights and execute the following command: netsh advfirewall set global StatefulFTP disable

试之，连接情况有所改善，虽然距离问题解决还有相当的距离（掉线依旧频繁）。

后经查询资料[2]得知，以上命令的作用为：

If you disable the StatefulFTP, the firewall will not inspect any FTP traffic. Any FTP traffic will pass the firewall because of the rule which I mentioned above.

虽然不是很明白为什么允许了FTP服务器的端口范围和程序还是会被过滤。

参考资料：

[1] https://wiki.filezilla-project.org/Network_Configuration

[2] http://social.technet.microsoft.com/Forums/windowsserver/en-US/4ee550ad-3880-49b3-a537-402a52c3d37b/netsh-advfirewall-set-global-statefulftp-disable?forum=winserverNIS

2014-09-28追加：

这件事最终得以解决的方法是在服务器上建立了威批恩服务，然后Tunnel到服务器上再进行下载，速度刷刷的。

被动明文FTP真难用啊。

2014-10-22追加：

威批恩服务（L2TP/IPSec模式）虽好，但出现了难以拨入的情况（不过只要成功拨入一次就能数小时不断线），经抓包检查发现服务器和客户端两边在开始阶段都没有问题，但一旦进入Key Exchange阶段服务器就会失去响应（服务器收到了Key Exchange包，但并没有回应任何数据）。目前此问题尚未解决，而上文提到的FTP已通过SSH SFTP-FTP Bridge解决。

2014年9月19日