尽量简短
我使用 c# .net 3.5 编写了自定义 FTP 实现。系统使用 TcpClient(主动模式下的 TcpListener)来管理连接。在单个实例中出现奇怪的行为，我想询问可能的原因。
客户本身在内部工作得很好，我们的很大一部分客户对此感到满意。但是，我们有一个我无法弄清楚。我已经收到了 wireshark 的痕迹，但没有真正的快乐。客户端机器在我认为(根据客户端描述)是一个大型网络基础设施的背后。从网络外部，连接到同一台服务器就像一个魅力。这是我所看到的。
我的客户端在被动模式下运行，发送 tcp 握手请求以进行数据连接(服务器进入被动模式并指定端口)，但从未得到确认。这会导致重试并最终超时。
使用 Filezilla(以及 Windows 资源管理器和 IE...)客户端，再次使用被动模式，连接顺利通过。令人恼火的是，这导致客户和我的老板指责代码。
通过 wireshark 跟踪，我看不到 TCP 帧之间的任何差异。所有控制连接都命中端口 21，并在两种情况下均得到确认。标志是相似的。这同样适用于数据连接，除了在这种情况下它是一个高数字端口 52000+(但在我的跟踪中不一样)。
当我们开始涉及较低级别的协议(protocol)问题时，我不是网络编程方面的专家，而且我对较大的网络警告的理解非常有限。作为开发人员，我立即大喊“防火墙问题”，但这并不能真正解决任何人的问题。
最后，有人知道什么样的硬件/防火墙会导致这种行为吗？我怀疑某些东西在应用程序级别阻塞了流量，但你永远不知道。
感谢阅读。
最佳答案
擦亮我的鞋子。你相信吗，事实证明这毕竟可能是用户错误。
悬而未决的一个大问题是“为什么 filezilla 和 Windows 可以工作，而您的软件却不能”。好吧，我终于从服务器端获得了跟踪信息，告诉我发生了什么。
似乎 filezilla 和 windows 退回到事件模式但没有告诉你。由于端口 20(被动模式，控制主机端口)和 21(主动模式，客户端数据端口)众所周知，网络硬件可能允许它(并且经常允许，无论防火墙设置如何)。
然而，我们的软件不会自动退回到事件模式，因为作为一项功能，FTP 圈子不推荐它。相反，事件模式是一个单独的选项，可以在设置连接时选择。奇怪的是，防火墙正在阻止传出的客户端握手请求，但奇怪的事情发生了。我打算放弃这一点，并可能将自动回退到我们的客户端。
编辑:是的，用户在他们的网络上有一个他们没有告诉我们的代理。发出 pebcak 警报!
关于c# - 自定义 FTP 客户端 PASV 数据连接被拒绝，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/8154803/