linux - TCP 套接字发送缓冲区大小效率

Question

当使用 WinSock 或 POSIX TCP 套接字(在 C/C++ 中，因此没有额外的 Java/Python/等包装)时，在用户中建立更大的缓冲区(例如最多 4KB)是否有任何效率优势/劣势space 然后尽可能少地调用发送以发送该缓冲区 vs 直接使用数据位(比如 1-1000 字节)进行多个较小的调用，其他事实是对于非阻塞/异步套接字，单个缓冲区可能是对我来说更容易管理。

我知道不建议使用 recv 小缓冲区，但我找不到要发送的内容。

例如公共(public)平台上的每个发送调用都会进入内核模式吗？在正常情况下，1 字节的发送实际上会导致 1 字节的数据包被传输吗？

Answer 1

正如 Richard Stevens 在 TCP Illustrated Vol I 中所解释的那样，TCP 将发送缓冲区划分为接近最佳的段，以适应到其他 TCP 对等方路径上的最大数据包大小。这意味着它永远不会尝试发送将被 ip 沿路由分段到目的地的段(当数据包在某个 ip 路由器上分段时，它会发回一个 IP 分段 ICMP 数据包，TCP 将考虑它以减少此连接的 MSS)。也就是说，不需要比沿路径的链路级接口(interface)的最大数据包大小更大的缓冲区。有一个，比方说，两倍或三倍的时间，可以确保 TCP 在收到远程对等点的确认后不会立即停止发送，因为它的缓冲区没有填充数据。

认为正常的接口(interface)类型是以太网，它的最大数据包大小为 1500 字节，所以通常 TCP 不会发送大于此大小的数据段。而且它通常每个连接都有一个 8Kb 的内部缓冲区，因此在内核空间添加缓冲区大小没有什么意义(如果这是在内核空间有一个缓冲区的唯一原因).

当然，还有其他因素迫使您在用户空间中使用缓冲区(例如，您想要存储数据以发送到某处的对等进程，因为只有 8Kb 数据在内核空间中进行缓冲，并且您将需要更多空间才能执行其他一些进程)例如:ircd(Internet 中继聊天守护程序)在断开连接之前使用高达 100Kb 的写入缓冲区，因为另一方没有接收到/确认该数据。如果您只对连接写入(2)，一旦内核缓冲区已满，您将被置于等待状态，也许这不是您想要的。

在用户空间有缓冲区的原因是因为 TCP 也进行流量控制，所以当它不能发送数据时，它必须放在某个地方来应对。您必须决定是否需要您的进程将数据保存到一个限制，或者您可以阻止发送数据，直到接收方能够再次接收。内核空间中的缓冲区大小是有限的，通常是用户/开发人员无法控制的。用户空间中的缓冲区大小仅受允许的资源限制。

在 TCP 连接中接收/发送小块数据是不推荐的，因为 TCP 握手和 header 强加的开销增加了。假设一个 telnet 连接，其中对于发送的每个字符，添加一个 TCP header 和其他 IP header (TCP 最少 20 字节，IP 最少 20 字节，以太网帧 14 字节和 4 字节以太网 CRC) 最多 60 个字节 + 仅传输一个字符。通常每个 tcp 段都是单独确认的，因此发送一个段并获得确认需要一个完整的往返时间(只是为了能够释放缓冲区资源并假定此字符已传输)

那么，最后，限制是什么？这取决于您的应用程序。如果您可以处理可用的内核资源并且不需要更多缓冲区，则可以在用户空间中没有缓冲区的情况下通过。如果您需要更多，您将需要实现缓冲区并能够在可用时将缓冲区数据提供给内核缓冲区。