Java TCP延迟

我正在开发一个Android应用程序，通过WLAN连接与TCP Java服务器通信。Android应用程序是一款在屏幕上移动精灵的游戏。每当精灵移动时，AndroidClient将其坐标发送到Java服务器，然后Java服务器将数据发送到其他客户端（最多4个客户端）。服务器在单独的线程上处理每个客户机，大约每20毫秒发送一次数据更新，每个数据包由大约1-10个字节组成。我在一个70Mbit的网络上（在我的无线网络上大约15Mbit有效）

我遇到了连接不稳定的问题，每10-30个数据包就有50-500毫秒的延迟。我已经将tcpNoDelay设置为true，它停止了一致的200ms延迟，尽管它仍然滞后很多。由于我对Android和网络都是新手，我不知道这是否是意料之中的事。我还想知道UDP是否适合我的程序，因为我感兴趣的是快速发送更新，而不是每个数据包都正确到达

---

对于如何避免/解决此延迟问题，如有任何指导，我将不胜感激。关于如何实现这种客户机-服务器体系结构的一般提示也值得称赞。

在无线局域网上，您偶尔会看到丢弃的数据包，这会导致数据包在延迟后重新传输。如果您想在重新传输之前控制延迟，几乎可以肯定必须使用UDP。

您肯定要使用UDP。对于一个游戏来说，你不在乎精灵的位置在短时间内是否不正确。因此，UDP在这种情况下是理想的

另外，如果您可以控制服务器代码，我不会为客户端使用单独的线程。如果您需要调用无法控制且可能被阻止的库（例如，因为它们接触文件或试图执行额外的网络通信），则线程非常有用。但是它们很贵。它们消耗了大量的资源，因此它们实际上使事情变得比可能的慢

因此，对于延迟和性能绝对关键的网络游戏服务器，我只需要使用一个线程来处理具有状态的命令队列，然后确保您永远不会执行阻塞的操作。因此，每个命令都是按顺序处理的，它的状态被评估和更新（就像激光爆炸与另一个对象相交一样）。如果命令需要阻塞（如从文件读取），则需要执行非阻塞读取并相应地设置该命令的状态，以便命令处理器不会阻塞。关键是命令处理器永远不会阻塞。它只是在循环中运行，但您必须以适当的方式调用Thread.sleep（x），以免浪费CPU

---

至于客户端，当客户端提交命令（比如他们发射了激光或其他类似的命令）时，客户端将生成一个响应对象，并将其插入一个以序列id为键的映射中。然后它将发送带有序列id的请求，当服务器用该id响应时，您只需在映射中查找响应对象并将响应解码为该对象。这意味着您可以执行并发操作。

UDP显然是更好的选择。对于游戏，您可能需要添加一些预测（您可能已经看到预测失误对某些游戏的影响）。使用wireshark或tcpdump捕获网络活动并将其发布到此处。听起来您的协议不适合在低延迟的TCP上工作。你能解释一下它是怎么工作的吗？例如，它如何确保背驮？事实上，将tcpNoDelay设置为true会有所帮助，而这本应会造成伤害，这有力地表明您的协议从来都不是为TCP上的低延迟而设计的。我的猜测是：1）您编写的代码可能很糟糕，会将部分应用程序级消息推送到传输层。2） 您的协议可能很糟糕，没有应用程序级别的确认，而这些确认是减少延迟所必需的。