使用 UDP 与 TCP 进行 Wi-Fi 通信 - 电池消耗？

Question

我有几个问题，但 SO 的做法是不要一次问多个，所以我会放相同的介绍并按逻辑顺序编号。

我正在编写一个与 .NET Win-service 通信的商业应用程序。目标受众是在有 Wi-Fi 覆盖的建筑物中工作的员工。该应用程序用于通知某些最终需要接收者接受或拒绝的事件（因此传输必须是双向的）。

我已经通过 TCP 实现了设备注册，然后切换到 UDP 数据通道。 在架构上，有一个启动 Application 类（需要配置一些全局设置），它反过来打开 LogIn 活动，成功注册后打开 Main 活动。启动时，Main 启动一个前台服务 (CommSvc)，该服务启动 UDP-comm 线程。

我正在使用 VisualStudio 2017 15.5.4、Xamarin 4.8.0.757、Xamarin.Android SDK - 8.1.3.0 进行开发。
我的测试设备是 2 部手机 LG Nexus 4 (Android 4.3, API 18), BLU Vivo 5 Mini (6.0, 23),
和三星 SM-T377V (6.0.1, 23) 平板电脑，我正在考虑升级到 7.0。

---

第一季度。我们的内部网络工程师估计，使用 TCP 将导致移动无线电更快地耗尽电池电量（与 UDP 相比）。 真的是这样吗？

TCP 保证字节流的有序传输（假设设备保持在范围内）。 UDP 数据包可能会丢失，因此需要某种 ACK-and-retransmit-on-failure 协议。

由于通道的 Wi-Fi 特性，永远无法保证发送的数据包到达目标设备（例如，超出范围），因此 无论如何都需要 ACK-and-retransmit 协议什么，我说得对吗？ （有责任方面）

Answer 1

由于 TCP 必须做更多的发送和接收来确保数据包的传递，它使用更多的流量和更多的 wifi 时间，因此更多的电池。

如果您想要有保证的交付，您可以使用 TCP，或者在 UDP 之上构建它的类似物，可能效率较低。

如果您不想要保证交货，例如您发布的数据很快就会过时，并且不介意丢失一些中间值，那么 UDP 是一种可行的方法。

如果您发送的数据相当大，我想在发送前对其进行压缩，并在接收时解压缩，将比 CPU 节省更多的无线电功率。

没有及时从接收方获得 ACK 一定是 TCP 流中的错误，可能通过IOException 发出信号，因此您可以检测到不完整的通信。但是，这不会告诉您您发送的内容是否已到达目的地。您的服务器应该准备好检查通信故障，并且可能准备好重新接收（并丢弃）它最近已经接收和执行的命令。序列号，TCP 风格，在这个层面上也有帮助。 OTOH，如果设备在重新连接后总是向服务器询问状态，并且服务器提醒最后接受的命令，则不需要。

在上述情况下，如果您的有效负载足够大，并且您不想重新实现碎片/ooo-reception/恢复逻辑，TCP 仍然有用。对于保证非常小的有效负载（我会说小于 1kb），最小的常用 IP 数据包足够大，因此您可以在应用程序级别重新实现相当简单的同步确认逻辑。

通常，当连接不稳定时（例如 wi-fi 接收不佳），具有相当长值（数十或数百秒）的套接字会很好地工作。不过一定要.SetSoTimeout(something_reasonable)；默认是无限！