我们决定使用UDP发送大量数据，例如：
之间的坐标我的数据报最多只有512字节，以尽可能避免传输过程中的碎片。
每个数据报都添加了一个标题（里面有一个ID），以便我可以监控：
问题是我们发送的数据报太快了。我们像第一批那样收到然后有很大的损失，然后又得到一些，并且再次遭受重大损失。收到的ID数据报序列类似于[1]，[2]，[250]，[251] ......
问题也发生在本地（使用localhost，仅限1个网卡） 我不关心丢失数据报，但这里并不是因网络造成的简单损失（我可以处理）
所以我的问题是：
如今，当我们要传输~4KB的坐标信息时，我们必须添加睡眠时间以便我们等待5分钟或更长时间才能完成，这对我们来说是一个很大的问题，因为我们知道我们应该每分钟发送一次至少10MB坐标信息。
答案 0 :(得分：1)
如果您想要可靠的传输，则应使用TCP。这将使您发送的速度几乎与网络和客户端的速度一样快，没有任何损失。
如果您需要高度优化的低延迟传输，不需要可靠，则需要UDP。这样可以让您发送的速度与网络可以处理的速度一样快，但您也可以比客户端读取的速度更快或更快，然后您将丢失数据包。
如果您需要具有细粒度控制的可靠高度优化的低延迟传输，您将最终在UDP之上实现TCP的自定义子集。它听起来不像你能做或应该这样做。
...如何获得最佳设置或套接字设置
通常通过实验。
如果丢失数据包的原因是客户端速度慢，则需要更快地启动客户端。较大的接收缓冲区仅购买固定数量的余量（比如吸收爆发），但如果你系统地放慢任何大小合适的缓冲区，最终会填满。
但请注意，这只能治愈过量或可避免的跌落。即使您的客户端可以跟上，各种网络堆栈层（即使不留下一个盒子）也可以丢弃数据包，因此如果没有自定义重新传输逻辑，您仍然无法将其视为可靠（并且我们会重新回复实施TCP）。
...尽可能多地发送信息？
您需要某种ack / nack /背压/节流/拥塞/从接收器返回源的任何消息。这正是TCP免费提供给你的那种东西，而且你自己实现起来相对棘手。
是否有可能达到1MB / s ......
我刚刚看到使用scp over loopback的8MB / s，所以我会说是。这使用TCP并且显然选择了AES128来动态加密和解密文件 - 如果您只是发送明文，那么获得相同的性能应该是微不足道的。
答案 1 :(得分：-1)
只有在不牺牲QoS的情况下丢失任意数量的数据报时，UDP才是可行的选择。我不熟悉Apache MINA，但所描述的场景类似于顺序处理每个数据报的服务器。在这种情况下，所有数据报在服务时都会丢失 - 没有UDP数据报的排队。就像我说的那样，我不知道MINA是否可以针对并行数据报处理进行调整，但如果不能，则只是选择错误的工具。