Tcp 10025是分配字节[]的特殊值吗

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

byte[] bytesFrom = new byte[10025];

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

---

谢谢

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

较少的任意值为：

• 通常使用二的幂，因为它们在计算（基于二进制数）时非常方便。因此，您经常会看到缓冲区大小，如

  256

  或

  4096

• 65536

  -除了是2的幂外，它还是TCP有效负载的最大大小，没有窗口缩放（这可能会将有效负载大小增加到1 GiB的疯狂值-这是一个大数据包）
• 有效载荷的实际已知最大尺寸。如果有效负载大小明显小于通常的缓冲区大小，则这可能很有用。例如，如果您知道可以接收的最大有效负载是100B，那么您可以使用100B的字节数组，甚至可以毫无问题地重用它（前提是您不在任何地方引用缓冲区，但无论如何都不应该这样做）

• 1460

  -这通常是默认的TCP发送缓冲区大小（如果发送的数据小于此值，TCP将等待一段时间（比如200ms），然后再发送“不完整”的缓冲区；如果您正在向网络流写入单个字节而不首先对其进行缓冲，则TCP可以相对良好地工作）。因此，发送4kib数据包意味着将立即发送前2920b，而剩余1176b将等待200ms的“超时”。不考虑这一点可能会导致严重的延迟，即使网络实际上根本不忙

在更具体的环境中，还有一些额外的可能原因。例如，在.NET上，您可能希望强制字节数组在大型对象堆上结束。虽然不完全可靠，但它可能应该在LOH上存储大于85000 B的对象（如果能够以某种方式强制执行，那就太好了）。如果您真的知道自己在做什么，这会很方便，特别是如果您需要在阵列（或其部分）上保持固定句柄，这在异步网络中经常发生。固定句柄可能会在主托管堆上造成重大问题，因为它依赖压缩来工作（它总是在末尾分配，而LOH有一个空闲空间表）

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

换句话说，选择好的缓冲区大小可能只是一个很好的实践，可以减少问题。不过，最后，这都是关于分析的——如果您在网络代码中发现性能问题，那么选择不好的缓冲区大小可能是罪魁祸首之一

另外：哇。在

新字节[10025]

代码段上有这么多谷歌搜索结果。我想知道这个值是从哪里来的，因为很明显，很多人只是盲目地复制它，根本不理解它，下面的代码段就是最好的证明：

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

---

为什么要分配一个10 025字节的缓冲区，然后只向其中读取

ReceiveBufferSize

字节？更不用说如果

ReceiveBufferSize

（这与发送的数据无关）大于10 025 B，您可能会得到一个越界错误。如果您根本不关心

ReceiveBufferSize

（您可能不应该这么做），为什么不创建一个

新字节[clientSocket.ReceiveBufferSize]

首先是缓冲区？

在我看来是任意的……但在上下文中它可能是有意义的。这个“一些代码”是从哪里来的？有趣的是，我在谷歌上搜索了一下，有一个同样大小的缓冲区的问题：可能开发人员住在纽约，因为10025是纽约的邮政编码：-）@Sean有更多这样的问题。你认为他们中有多少人是从复制别人的项目开始的@肖恩：这是一段糟糕的网络代码：D这可能是一段又一段被复制的代码，而不了解它的实际功能。@taktak004我在谷歌搜索结果中看到了类似的花絮。我惊呆了：D