Question

我在一些代码here中多次看到TCP通信的行如下：

byte[] bytesFrom = new byte[10025];

因此，我想知道这个10025值是否有特殊原因，或者它是否只是任意选择。

由于

Answer 1

据我所知，10025没有任何具体含义。这可能是由于不了解如何使用缓冲区的人随机调整的结果（嘿，我收到了10000 B数据包，我没想到，让我增加缓冲区大小......）。

较少的任意值将是：

经常使用两种语言，因为它们在计算方面非常方便（基于二进制数）。因此，您经常会看到256或4096等缓冲区大小。
65536 - 除了是2的幂之外，它还是没有窗口缩放的TCP有效载荷的最大大小（可以将可能的有效载荷大小增加到1 GiB的疯狂值 - 这是一个大数据包）
有效负载的实际已知最大大小。如果有效负载大小明显小于通常的缓冲区大小，这可能很有用。例如，如果您知道可以接收的最大有效负载为100 B，则可以使用100 B的字节数组，甚至可以重复使用它而不会出现问题（前提是您没有引用在任何地方缓冲，但你不应该真的这样做。）
1460 - 这通常是默认的TCP发送缓冲区大小（如果发送的内容少于此值，TCP将在发送“不完整”缓冲区之前等待一段时间（比如200ms）;这样可以使TCP工作如果您将单个字节写入网络流而不首先缓冲它们，则相对较好。因此，发送4 kiB数据包意味着将立即发送第一个2920 B，而剩余的1176 B将等待说200ms“超时”。即使网络实际上并不忙，也不会考虑到这一点会导致严重的延迟。

在更具体的环境中还有一些额外的可能原因。例如，在.NET上，您可能希望强制字节数组最终在大对象堆上。虽然不完全可靠，但它应该可以在LOH上存储大于85,000 B的物体（如果能以某种方式强制实施，那将是很好的）。如果您真的知道自己在做什么，这可能很方便，特别是如果您需要在阵列（或其部件）上保留固定手柄，这通常就是例如。异步网络 - 固定句柄可能会导致主要托管堆上的重大问题，因为它依赖于压缩工作（它总是在最后分配，而LOH有一个可用空间表）。

在更低级别上，您可能希望例如限制数组大小以适应CPU缓存，或者单个内存页面以提高性能（这对于.NET数组来说也很重要，.NET数组将数组大小存储在数组的开头 - 这意味着当访问数组的项时，边界检查将需要加载数组的开头，而不仅仅是请求的项目）。但是，当你开始这样的优化时，你可能有点像专家:)

换句话说，精心选择的缓冲区大小可能只是一种很好的做法，可以减少问题。但最后，它是关于性能分析的 - 如果您在网络代码中发现性能问题，那么选择错误的缓冲区大小就是可能的罪魁祸首之一。

另外：哇。 new byte[10025]代码段上有很多谷歌搜索结果。我想知道这个价值来自哪里，因为显而易见的是，很多的人只是盲目地复制它而根本不理解它，最好用这样的片段来证明：

byte[] inStream = new byte[10025];
bufferSize = clientSocket.ReceiveBufferSize;
serverStream.Read(inStream, 0, bufferSize);

为什么你会分配一个10 025字节的缓冲区然后只读取ReceiveBufferSize个字节？更不用说如果ReceiveBufferSize（其中没有与发送的数据有关）大于10 025 B，则可能会出现越界错误。如果你完全关心ReceiveBufferSize（你可能不应该），为什么不首先创建一个new byte[clientSocket.ReceiveBufferSize]缓冲区呢？

10025是分配byte []的特殊值

1 个答案: