我目前正在尝试使用我们的一种产品中的FTP上传功能来调试客户的问题。该功能允许客户将文件(<1MB)上传到中央FTP服务器以进行进一步处理。 FTP客户端代码是在VB.NET内部编写的。

客户报告他们尝试上载300KB至500KB范围的文件时收到"远程主机强行关闭连接"错误。但是，我们在内部使用了更大的文件(相对而言)(即3MB及以上)测试了此文件，但从未收到此错误。我们使用相同的FTP登录凭据将客户端上传到相同的FTP服务器，唯一的区别是我们是在办公室完成的。

我知道TCP协议内置了流控制，因此在一个Send调用中发送多少数据无关紧要，因为该协议会相应地调整自身以匹配服务器的内部限制(如果我没记错的话)。 ..)

因此，我唯一能想到的是，客户端和路由器之间的中间主机正在人为地限制客户端的速率并断开客户端的连接(我们以512字节的块为单位循环发送文件数据)。

这是用于发送数据的循环(缓冲区是包含文件数据的Byte数组)：

For i = 0 To buffer.Length - 1 Step 512
                mDataSocket.Send(buffer, i, 512, SocketFlags.None)
                OnTransferStatus(i, buffer.Length)
            Next

客户的ISP(或者他们自己的防火墙)是否有可能对客户代码在给定时间内可以发送多少数据施加人为的速率限制？如果是这样，处理这种情况的最佳方法是什么？我猜最明显的解决方案是在我们的发送循环中引入延迟，除非有某种方法可以在套接字级别执行此操作。

对于我来说，ISP通过终止客户端连接来处理违反速率限制的行为真让我感到奇怪。他们为什么不仅仅依靠TCP / IP的内部流控制/限制机制？

解决方案

我不认为ISP会试图杀死500KB的文件传输。我不是套接字问题或者ISP方面的专家...只是就此事发表自己的看法。

搜索Comcast和BitTorrent。这是一篇文章。

尝试找出问题所在：

• 让客户将同一文件上载到其他服务器。也许问题出在客户端的FTP客户端上。
• 从客户端获取文件，然后将其自己与客户端一起上传，看看是否可以解决该问题。

最后，即使3MB的文件可以正常工作，也不能保证500KB的文件可以正常工作，因为在结束文件传输时，问题可能取决于状态，并且可能会发生。

是的，ISP可以在认为合适的情况下对数据包施加限制(尽管这在道德上是有问题的)。例如，我的ISP在削减其硬件设法嗅探到的任何P2P流量方面没有问题。它称为流量整形。

但是，对于FTP通信来说，这是不太可能的，但我们永远不会知道。关键是，它们永远不会通过流量整形来丢弃套接字，它们只会丢弃数据包。 tcp协议在每个梨侧进行处理，因此我们可以丢弃它们之间的所有数据包，并且套接字保持活动状态。在某些情况下，如果其中一台计算机崩溃，则即使我们不尝试使用它，插座也仍然有效。

我认为我们最好的选择是客户端上的防火墙/代理配置错误。更好的解释在这里。

客户端安装上的路由器或者电缆出现故障或者配置错误。

这些天500k太小了，所以如果他们节流这么小的东西，我会感到有些惊讶。

我知道我们已经在分批处理请求，但是我们可以确定是否传输了任何数据吗？代码是否总是在同一循环点失败？我们能够查看ftp服务器日志吗？整个堆栈跟踪如何？我们是否尝试过联系ISP并询问他们有什么政策？

也就是说，假设有一些数据能够通过，那么一个想法就是ISP进行了流量整形，并且在写入x字节后规则就生效了。可能发生的情况是数据> x套接字超时在数据发送之前到期，并引发异常。

请记住，ftp客户端会创建另一个用于数据传输的连接，但是如果服务器检测到控制连接已关闭，则通常会终止数据传输连接。因此，要检查的另一件事是确保控件连接仍然有效。

最后，ftp服务器通常支持可恢复的传输，因此，如果所有其他补救措施均失败，则恢复失败的传输可能是最简单的解决方案。