套接字接收缓冲区大小

Question

我的问题是关于Linux上Python中的sockets编程，但是由于Python的socket模块只是系统调用（recv，recvfrom等）的一个包装器，所以Python不是很重要。

所以，根据docs，当我们调用recv方法时

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

这是什么意思？

best match with hardware and network realities

我最关心的是表演。

如果我把自定义缓冲区（稍后在代码中用作数据容器，如果重要的话，它只是一个内存视图传递给一些而不是2自定义大小到socket.recv_into方法的能力，这会不会成为网络软件的瓶颈？

只需要一行代码，简洁明了。

但我的缓冲区大小可以是17或51或其他，所以我想知道，我是否应该实现一些内部环形缓冲区，大小“良好”（如4096），并使用它从具有如此“良好”大小的socket块中读取数据，然后将其写入那里，然后复制到我的缓冲区？

它在性能方面有意义吗？

或者我目前的方案（当我从一个套接字中以“坏”大小的块读取数据时，这与“2的幂”规则不匹配）可以吗？

换言之：如果我们以1023大小而不是1024大小的块从套接字读取数据，会影响性能吗？

Answer 1

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

您应该考虑以太网数据包的最大大小（~1500字节）和TCP数据包的最大大小（~64K）。你真的想要一个比第一个大的缓冲区（所以1024，可能是不可能的），而且你可能不需要比后者更多的缓冲区。所以选择2K、4K、8K、16K、32K或64K

它们还暗示，内核使用的缓冲区大小为2的幂（可能是64K，因为TCP最大数据包大小），您需要付出努力并匹配它，这样在读取时就不会有中小型的剩余（将数据包大小模化）。

示例：假设您使用的是1023字节的缓冲区，由于发送了大量数据，因此TCP数据包的最大值为64K。您将有1023字节的64次迭代和64字节的浪费性额外迭代。