UDP SetWriteBuffer 和 SetReadBuffer 如何处理操作系统的缓冲区？

各位小伙伴们，大家好呀！看看今天我又给各位带来了什么文章？本文标题是《UDP SetWriteBuffer 和 SetReadBuffer 如何处理操作系统的缓冲区？》，很明显是关于Golang的文章哈哈哈，其中内容主要会涉及到等等，如果能帮到你，觉得很不错的话，欢迎各位多多点评和分享！

描述

我正忙着用 go 编写一个高频 udp 服务器。我估计双向至少每秒 1000 个数据包。

然而，随着我通过 udp 套接字发送的数据大小的增加，我最终遇到了以下错误： read udp 127.0.0.1:1541->127.0.0.1:9737: wsarecv: a message sent on a数据报套接字大于内部消息缓冲区或其他一些网络限制，或者用于接收数据报的缓冲区小于数据报本身。

我最终只是增加了我正在读取和写入的缓冲区的大小，如下所示：

buffer := make([]byte, 64 * 1024 * 1024) // used to just be 1024
l, err := s.socketsim.read(buffer)

这工作正常，我不再收到错误...但是我可以跨 net 包内的两个函数：

s.socketSim.SetWriteBuffer(64 * 1024 * 1024)
s.socketSim.SetReadBuffer(64 * 1024 * 1024)

我了解到这两个作用于o操作系统的传输缓冲区

问题

我是否需要设置操作系统缓冲区大小？为什么？应用程序缓冲区的大小如何影响操作系统缓冲区的大小？它们应该始终相同吗？它们应该/可以变成多大？

解决方案

首先，不仅设备上的每个接口以及发送/接收的目的地都有一个 MTU 大小，而且中间的每个设备也有一个 MTU 大小。因此，正如其他人所提到的，您可能希望使用普遍接受的 MTU，因为您可能无法控制数据路由中的每个设备。对于 UDP，MTU 实际上只是表示数据报在分段之前可以有多大。

其次，您几乎肯定希望 SND/RCV 缓冲区大于 MTU。这些是内核缓冲区，当您未准备好接收数据时，它们会保留数据。更大的 UDP RCV 缓冲区意味着内核会为您缓冲更多数据包，然后再将它们扔进深渊。也许您需要为每个数据包做一些重要的工作。根据比特率，您可能需要更大或更小的内核缓冲区。

最后，您将使用 UDP。无法保证您会按顺序收到数据包或根本不会收到数据包。您和对等方之间的任何路由器都可能因任何原因决定丢弃数据包。由于您使用的是 UDP，因此您应该为丢弃和乱序数据包做好准备。您可能还需要某种重传机制，这使事情变得更加复杂。

或者，如果丢弃的数据包不可接受，您可能会考虑使用 TCP，因为知道时间是不确定的。

如果您使用的是 Linux，您可以在 /proc/sys/net 中查看当前缓冲区大小。通常内核会加倍你所要求的。

此外，您可以通过观察 /proc/net/udp 中的数据包丢失来调整缓冲区大小。如果看到丢失，您可能需要增大 rcv 缓冲区，尤其是在数据突发且处理密集的情况下。如果数据以一致的速率传入，但仍然丢包，那么说明您处理数据包的速度不够快。

今天带大家了解了的相关知识，希望对你有所帮助；关于Golang的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~