构建套接字通信以最小化数据传输

Question

我正在开发一个项目，该项目将在带宽受限的网络（蜂窝网络）上使用客户端设备。我对套接字通信不太熟悉，但我已经想出如何使用Java作为服务器（来自this教程），而Python是客户端上的语言。

我将从有限数量的命令（少于50个）发送说“执行命令”，但我有时还需要发送一个更长的设置，为客户端提供未来的规则/条件。我的想法是为每个命令发送一个字节，其中一个字节表示还有更多的命令。这是否是正确的方法，或者我应该继续写入套接字输出（我猜它是utf-8，如果我没有弄错的话，这是3bytes / char）。

感谢您的投入， 詹姆斯

Answer 1

UTF-8不是任何固定数量的字节 - UTF-8字符可以是1到16个字节。

不要将您的命令视为文本，将它们视为最多255的整数 - 无编码或字节顺序或任何内容。 chr(command)其中command是此范围内的整数，只要您不尝试显示，就可以正常工作而无需担心编码。

如果要发送最小数据，是的，您可以每个字节发送一个命令。如果你真的有64个或更少的命令，你可以使用第7位表示“另一个命令即将来临”，第8位表示“下一个字节启动规则/条件”。

请务必点击答案旁边的复选标记，以便在答案回答时接受答案。

Answer 2

在尝试优化网络带宽时，您应该记住两件事。

首先，每次要与对等方通话时，必须传输大约40个字节的开销。这只是IP中固有的。尝试将通信缩减到单个字节通常是错误的经济。您应该做的是充分利用往返：将消息与对等可能稍后需要的其他数据相结合。在有限的程度上，Nagle算法已经将这个用于天真的服务，延迟数据包直到对等体实际上表明它已准备好接收更多数据，这通常就足够了。

第二个问题是，在典型的MTU规模下，设计一个未压缩的二进制协议几乎是不可能的，它比使用通用压缩隧道传输的更简单的协议更节省空间。没有“压缩二进制http”，因为gzip压缩的ascii传输编码无论如何都会打败它。当考虑带宽时，始终包括压缩。剩下的就是确保您的协议“易于”压缩。