套接字缓冲区大小：更大与更小的优缺点答案

【问题标题】：socket buffer size: pros and cons of bigger vs smaller套接字缓冲区大小：更大与更小的优缺点
【发布时间】：2015-02-10 19:09:45
【问题描述】：

我以前从未真正使用过 COM 套接字，现在有一些代码正在侦听相当稳定的数据流 (500Kb/s - 2000Kb/s)。

我尝试了不同的尺寸，但我不确定我在概念上在做什么。

byte[] m_SocketBuffer = new byte[4048];
//vs
byte[] m_SocketBuffer = new byte[8096];

我使用的套接字是 System.Net.Sockets.Socket，这是我的构造函数：

new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp)

我的问题是：

我正在检索这样的数据：

string socketData = Encoding.ASCII.GetString(m_SocketBuffer, 0, iReceivedBytes)
while (sData.Length > 0)
{ //do stuff }

【问题讨论】：

【解决方案1】：

短版：

最佳缓冲区大小取决于很多因素，包括底层网络传输以及您自己的代码如何处理 I/O。
10 的 K 可能适合用于移动大量数据的大容量服务器。但是，如果您知道远程端点不会一次向您发送大量数据，您可以使用更小的数据。
缓冲区在 I/O 操作期间被固定，这可能导致或加剧堆碎片。对于真正大容量的服务器，分配非常大的缓冲区（大于 85,000 字节）以便从大对象堆（没有碎片问题，或者处于永久状态）分配缓冲区可能是有意义的。碎片化，这取决于您如何看待它 :) )，然后将每个大缓冲区的一部分仅用于任何给定的 I/O 操作。

回复：您的具体问题：

大缓冲区和小缓冲区是否存在一般性权衡？

最明显的可能是通常情况：比您实际需要的缓冲区更大只是在浪费空间。

缓冲区太小会强制执行更多 I/O 操作，可能会强制执行更多线程上下文切换（取决于您执行 I/O 的方式），并且肯定会增加必须执行的程序语句的数量。

当然还有其他的取舍，但要深入其中的每一个，对于本论坛来说，讨论的范围太广了。

如何确定缓冲区的大小？您应该使用什么作为量规？

我会从看起来“合理”的尺寸开始，然后从那里开始试验。在各种负载测试场景中调整缓冲区大小，增加和减少，看看对性能有什么影响。

当缓冲区已满时是否会发生读取事件？就像每当套接字缓冲区达到阈值时，我就可以从中读取？

当您从套接字读取数据时，网络层会将尽可能多的数据放入您的缓冲区。如果可用数据多于无法容纳的数据，则会填充缓冲区。如果可用数据少于容量，则操作将在不填充缓冲区的情况下完成（但总是在至少一个字节已放入缓冲区时……读取操作以零长度完成的唯一时间是连接正在关闭）

【讨论】：