python - 使用不是 2 的幂的 bufsize 调用 socket.recv 的实际影响是什么？

Question

要从 python 中的套接字读取数据，请调用 socket.recv，它具有以下签名:

socket.recv(bufsize[, flags])

python docs for socket.recv含糊地说:

Note: For best match with hardware and network realities, the value of bufsize should be a relatively small power of 2, for example, 4096.

问题:“与硬件和网络现实最匹配”是什么意思？将 bufsize 设置为非二次方的实际影响是什么？

我见过 many other recommendations使其读取 2 的幂。我也很清楚将数组长度作为 2 的幂通常有用的原因(对长度的位移/屏蔽操作、最佳 FFT 数组大小等)，但这些是应用依赖。我只是没有看到 socket.recv 的一般原因。当然不是 specific recommendation在 python 文档中。我也没有在 underlying python code 中看到任何二次幂优化。使其成为特定于 python 的推荐

例如...如果您有一个确切知道传入数据包长度的协议(protocol)，显然最好只读取“最多”您正在处理的数据包所需的内容，否则您可能会吃掉下一个数据包，那会很烦人。如果我当前正在处理的数据包只有 42 个字节待处理，我只会将 bufsize 设置为 42。

我错过了什么？当我必须选择任意缓冲区/数组大小时，我通常(总是？)将长度设为 2 的幂，以防万一。这只是多年养成的习惯。 python 文档也只是习惯的受害者吗？

这不是 python 独有的，但由于我专门引用了 python 文档，所以我会这样标记它。

---

更新:我刚刚检查了系统内核级别的缓冲区大小(或者至少我认为我做了...我做了 cat/proc/sys/net/core/rmem_default)，它是 124928。不是 2 的幂。 rmem_max 是 131071，显然也不是 2 的幂。

在进一步研究这一点时，我真的看不出两个推荐的力量有什么好处。我准备把它称为虚假推荐......

我还添加了 tcp 和 C 标签，因为它们也很相关。

Answer 1

我很确定“2 的幂”建议是基于编辑错误，不应被视为要求。

那条具体的建议是added to the Python 2.5 documentation (和 backported to Python 2.4.3 docs )，响应 Python issue #756104 .报告者为 socket.recv() 使用了不合理的大缓冲区，导致更新。

是 Tim Peters 提出了“2 的力量”概念:

I expect you're the only person in history to try passing such a large value to recv() -- even if it worked, you'd almost certainly run out of memory trying to allocate buffer space for 1.9GB. sockets are a low-level facility, and it's common to pass a relatively small power of 2 (for best match with hardware and network realities).

(我的粗体强调)。我和 Tim 一起工作过，他在网络编程和硬件方面拥有丰富的经验，所以一般来说，当我发表这样的评论时，我会相信他的话。他特别“喜欢”Windows 95 堆栈，他称其为煤矿中的金丝雀，因为它能够在压力下失败。但请注意，他说这是常见的，而不是必须使用 2 的幂。

正是这种措辞导致了文档更新:

This is a documentation bug; something the user should be "warned" about.

This caught me once, and two different persons asked about this in #python, so maybe we should put something like the following in the recv() docs.

"""
For best match with hardware and network realities, the
value of "buffer" should be a relatively small power of 2,
for example, 4096.
"""

If you think the wording is right, just assign the bug to me, I'll take care of it.

这里没有人挑战“2 的幂”断言，但编辑从 it is common 移动到 should be 在几个回复的空间中。 p>

对我来说，那些提议更新文档的人更关心的是确保您使用一个小缓冲区，而不是它是否是 2 的幂。这并不是说它不好建议 但是；任何与内核交互的低级缓冲区都受益于与内核数据结构的对齐。

但是，虽然很可能存在一个深奥的堆栈，其中大小为 2 的幂的缓冲区更为重要，但我怀疑 Tim Peters 是否曾为他的经验所指(这是常见的做法)以这种铁定的方式类型转换。如果不同的缓冲区大小对您的特定用例更有意义，请忽略它。