套接字编程与Web服务？

Question

我想创建一个移动消息服务，但我不知道使用套接字编程或Web服务哪个更好？

在创建此类服务时，我需要考虑哪些问题？如连接成本......等等。

如果您需要更多详细信息，请在投票或关闭之前告诉我！

Answer 1

Web服务通常说“更容易”，这要归功于它们对它们的巨大兴趣以及它们在开发人员工具中以及通过库和框架的支持。

但是，特别是如果您的有效负载很小（认为消息的大小与典型的SMS或推文相同），您使用webservices创建的开销是令人望而却步的：通过无线网络（如GPRS或UMTS）发送的字节仍然非常昂贵，通过电缆或ADSL传输的字节数。并且Web服务带有几层隐形信息，最终客户也必须支付这些信息。

因此，如果您的用例基于短消息，我至少建议您进行一些带宽模拟计算，并根据带宽节省与应用程序复杂性的增加做出决策。

在查看套接字时，还要看一下UDP：如果你可以忍受这样一个事实，即基本上你扔了一个数据包，并且没有在你的协议中设计一些ack机制，你永远不会确定消息到达了，它是非常高效，因为没有流量来创建和维护连接，甚至很长的消息也可以在1 UDP包内传输。

根据评论编辑：

• stream socket：不确定如何定义流，但是流和消息对我来说是两个截然不同的概念，流是通常发送的更长的数据序列，而消息是发送的实体，可选地确认或接收者回答。
• 带宽模拟：了解我正在谈论的内容的最简单方法是获取Wireshark并将通过网络传输的所有内容添加到一个非常短的字符串的简单请求中 - 您将看到几层管理信息（即不可见，只是为了使不同的协议层工作），这些都是最终用户支付的流量。然后，使用UDP编写一个小型模拟服务来传输相同的消息，或使用像netcat这样的工具，好的教程here，并添加传输的字节。你会发现交换的字节数差异很大。

EDIT2，我忘了提到：移动网络过去是开放的透明网络，设备由公共IP地址识别。 NAT移动网络迅速发展，这对这个“围墙花园”内外的设备如何通信产生影响（NAT traversal）。在设计沟通渠道时，您需要考虑到这一点。

对于聊天应用程序使用流：它提供了一些概念上的优势，但您可以在UDP之上层叠聊天应用程序，查看here或here