使用TCP时发送1个大块或大块小块是否更好？

在我accept()连接,然后write()到客户端套接字之后,最好是一次写入要发送的所有数据还是以块的形式发送它？

例如:

接受,写1MB,断开连接

…要么…

接受,写入256个字节,写入256个字节,... n,断开连接

我的直觉告诉我,底层协议会自动执行此操作,并进行错误更正等.这是正确的,还是我应该将数据分块？

在你问之前,不,我不确定我在哪里想到数据块 - 我认为这是我从编程C#web服务中获得的本能(为了绕过接收缓冲区限制等,我认为).坏习惯？

注意:我正在使用C.

客户端和服务器会根据需要分解您的数据,因此您可以在一个块中发送尽可能多的数据.查看Von Welch撰写的TCP Windows用户指南.

多年前,我有一个发送二进制数据的应用程序 - 它使用以下缓冲区的大小发送一个,然后另一个发送缓冲区(几百个字节).在分析之后,我们发现我们可以通过将它们放入一个缓冲区并仅发送一次来获得主要的加速.我们感到很惊讶 - 即使每个数据包都有一些网络开销,我们也不认为这是一个值得注意的因素.

从TCP级别开始,是的,当它太大时,你的大缓冲区将被拆分,当它太小时它将被合并.

从应用程序级别,不要让您的应用程序处理无限制的缓冲区大小.在某种程度上,你需要拆分它们.

如果您通过套接字发送文件,并且可能正在处理该文件的某些数据,例如压缩它.然后你需要把它分成几块.否则,当你最终发生在一个大文件上并且你的程序将没有RAM时,你将使用太多RAM.

RAM并不是唯一的问题.如果缓冲区太大,您可能会花太多时间阅读数据或处理数据,而您将不会使用坐在那里等待数据的套接字.因此,最好有一个缓冲区大小的参数,以便您可以确定一个不太小,也不太大的值.

我的主张不是TCP套接字无法处理大量数据,它可以并且我建议在发送时使用更大的缓冲区以获得更高的效率.我的主张是不要在应用程序中处理无限制的缓冲区大小.

该Nagle算法,通常默认的TCP套接字启用,将有可能结合这四个256字节写入相同的数据包.因此,如果您将其作为一个或多个写入发送并不重要,它应该最终会在一个数据包中结束.如果你有一个很大的块,那么将它作为一个块发送会更有意义.