为什么要在套接字的“ recv”方法上设置保守的最大字节大小？

Question

我正在使用Python的socket.socket类构建客户端，该类接收大小不同的数据（通常在500到5,000字节之间，但从理论上讲，客户端套接字可以接收500,000字节）。 我也在编写将与此客户端套接字通信的服务器。

我很想知道，我可以确定自己永远不会超过的最大字节大小设置有什么风险，例如：

socket.recv(1000000)

即使我知道这远远超过套接字实际使用率的99％。

Answer 1

您要做的只是浪费内存，数量如此之多。

1. 如果您以最大速度阅读，那么您将获得的路径MTU通常不会超过1500字节，并且肯定以千字节而不是兆字节为单位。

2. 如果您不是以最大速度读取，则内核中已经有一个套接字接收缓冲区，根据您的平台，该缓冲区的大小在8-64k范围内，通过TCP的操作，recv（）完全不可能传送的数据比该缓冲区中的要多。

Answer 2

套接字不能像您想象的那样工作。 socket.recv(N)并不意味着您将获得N个字节。 这意味着您最多可以取回N个字节。 这与发送方尝试向您发送多少字节无关。 TCP是面向流的 。 这意味着您将按照发送方发送给您的顺序来获取发送方发送给您的字节。 但是您将不会获得与发送数据时使用的相同的“消息”边界。

您必须编写代码才能多次调用recv，因为众所周知， socket.recv(1000000)将向您返回一个字节。 现在，只要多次调用它，您就不必考虑参数的大小与接收到的消息的大小。 就像其他张贴者所说的那样，您希望传递一个与堆栈其他级别的最大缓冲区大小可比的值。 这些缓冲区之一（路径MTU）可能约为1500（但可以更大或更小）。 但是内核的TCP / IP堆栈中的本地接收缓冲区较大，可能约为64k或128k。 这些可能接近合理的使用值。

不过，我建议不要实际在此级别上编写网络代码。 它已经完成了-或多或少地导致死亡。 将精力集中在应用程序的新颖部分上，并重新使用一些为您处理这些细节的现有库，可能会更好。 我推荐Twisted 。