构建套接字通信以最小化数据传输
我正在开发一个项目，该项目将在带宽受限的网络（蜂窝）上使用客户端设备。我对套接字通信不是很熟悉，但我已经弄清楚如何使用Java作为服务器（来自本教程），Python 是客户端的语言。
我将发送有限数量的命令（少于 50 个），表示“执行命令”，但有时我也需要发送更长的命令集，为客户端提供未来的规则/条件。我的想法是为每个命令发送一个字节，其中一个字节表示还有更多命令即将到来。这是正确的方法吗，或者我应该继续写入套接字输出（我猜它是 utf-8，如果我没有记错的话，它是 3bytes/char）。
感谢您的投入， 詹姆斯
I am working on a project that will utilize a client device on a bandwidth constrained network (cellular). I am not very familiar with socket communications, but I have figured out how to use Java as the server (from this tutorial), and Python is the language on the client.
I will be sending from a limited number of commands (less than 50) that say to "do command", but I will also on occasion need to send a longer set that gives the client a future rule/condition. My thinking is to send a single byte for each of the commands, with one of the bytes signifying there is more to come. Would that be the proper way to do it, or should I continue writing to the socket output (I'm guessing it is utf-8, which is 3bytes/char if I'm not mistaken).
Thanks for the input,
James
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在尝试优化网络带宽时，您应该记住两件事。
首先，每次想要与对等方通信时，您都必须传输大约 40 字节的开销。这是知识产权所固有的。试图将通信减少到单个字节通常是错误的经济做法。您应该做的是充分利用往返：将消息与对等方稍后可能需要的尽可能多的附加数据结合起来。在有限的程度上，Nagle 算法已经为简单的服务解决了这个问题，延迟数据包，直到对等方实际表明它已准备好接收更多数据，这通常就足够了。
第二个问题是，在典型的 MTU 规模下，几乎不可能设计出比使用通用压缩进行隧道传输的更简单协议更节省空间的未压缩二进制协议。不存在“打包的二进制 http”，因为 gzipped ascii 传输编码无论如何都会击败它。当带宽是一个问题时，请始终包括压缩。剩下的就是确保您的协议“容易”压缩。
There are two things you aught to keep in mind when trying to optimize network bandwidth.
The first is that you have to transfer about 40 bytes of overhead every time you want to talk to the peer. That's just inherent in IP. Trying to get communication down to a single byte is often a false economy. What you should be doing is making the best of the round trip: combine the message with as much additional data as the peer might later need. To a limited extent, the Nagle algorithm already takes care of this for naive services, delaying the packet until the peer actually indicates that it's ready for more data, and that's usually sufficient.
The second is that, at typical MTU scales, it's almost impossible to design an uncompressed, binary protocol that's more space efficient than a simpler protocol that is tunneled using general purpose compression. There is no "packed binary http" because the gzipped ascii transfer encoding would beat it anyways. When bandwidth is a concern, always include compression. All that's left is to make sure that your protocol is "easy" to compress.
UTF-8 不是任何固定的字节数 - UTF-8 字符可以是 1 - 16 个字节。
不要将命令视为文本，而应将它们视为最大 255 的整数——没有编码或字节顺序或任何东西。
chr(command)其中 command 是此范围内的整数，只要您不尝试显示它，就可以正常工作，而无需担心编码。如果您想发送最少的数据，是的，您可以每个字节发送一个命令。如果您确实有 64 个或更少的命令，则可以使用第 7 位表示“另一个命令即将到来”，使用第 8 位表示“下一个字节开始规则/条件”。
如果答案回答了您的问题，请记得单击答案旁边的复选标记来接受它。
UTF-8 is not any fixed number of bytes - a UTF-8 character can be 1 - 16 bytes.
Don't think of your commands as text, think of them as integers up to 255 -- No encoding or byte order or anything.
chr(command)where command is an integer in this range will work fine without worrying about encoding, as long as you don't try to display it.If you want to send minimal data, yes, you can send one command per byte. If you really have 64 or less commands, you can use the 7th bit to mean "another command is coming" and the 8th bit to mean "the next byte starts a rule / condition".
Please remember to click the check mark next to an answer to accept it if it answered your question.