路径MTU发现

Winsock不支持报告发现的MTU,即使其他TCP/IP堆栈也支持(例如,通过socket选项ip_getpmtu的AIX)。因为winsock不能报告,.net不能提供API(必须在winsock之上)。

我建议以64kib为单位发送数据。这是最大的IP包大小,可能大于MTU,因此堆栈将发送几个完整的段。最后一个片段可能更小,但随后,系统可能会延迟发送它(因为它仍然需要接收对早期数据的确认),因此如果您快速跟进下一个64kib的发送,系统将使用路径mtu将这些块再次组合成包。

如果您使用的是TCP,这不是您必须自己做的事情。此外,与发送缓冲区的大小没有关系。可以有多个数据包在传输中(最大为TCP窗口大小),但它们将不再位于您维护的缓冲区中。

如果您使用的是UDP,那么您可能会关心碎片化,但是如果是这样,为什么要实现自己的协议来传输大型文件?改用TCP,不用担心。如果您正在使用拥塞控制和所有其他需要的东西在UDP上实现自己的协议,那么在包上设置df位并处理响应。

如果您使用的是TCP,那么您根本不需要担心碎片问题,堆栈会为您做到这一点。

使用 FtpWebRequest 和 FtpWebResponse . 问题是这些类不使用大型缓冲区,而是使用流(使用最佳大小的缓冲区实现)。内存使用将非常少。

数据包大小不受您的控制,而是由网络驱动程序控制。

如果您需要最快的速度,则通过执行数据发送/接收 TcpClient 在服务器和客户端上都是类。

upd:以下是有关如何上载文件的示例: http://msdn.microsoft.com/en-us/library/system.net.ftpwebrequest.aspx 参见 class AsynchronousFtpUpLoader .

还有一件事。一段时间前,我在试验MTU。我所有的更改都降低了数据传输速度。Windows网络驱动程序足够智能,可以使用最佳的MTU。

PMTU发现被您的TCP堆栈用于在发送时优化包大小。在您的级别上,您只看到流(即甚至在进行打包之前,更不用说碎片化)。你的问题听起来真的像是你在尽可能地发送数据,但是你的TCP/IP连接速度较慢,所以这会导致RAM中所需的空间增加。既然您使用的是ftp,我希望您使用的ftp实现已经支持并理解了这一点????既然你在请求缓冲区,听起来就像是一个基于套接字的滚动,或者类似的东西。如果您使用的是同步发送方法,那么当套接字缓冲区满时,它应该阻止您发送,直到它有缓冲区空间为止。

你能提供更多关于你用来发送文件的API的细节吗,内置的还是滚动的?是否为socket、networkstream等?