我正在使用 Ruby on Rails 构建一个需要高度可扩展的 Web 应用程序。在此应用程序中，移动客户端每秒生成数据(大约 20 个字节)。所有这些数据都必须在某个时候传输到服务器，最好尽快传输。
为了完成这项任务，我希望服务器充当 RESTful 服务。客户端可以缓冲位置(比如每 5 到 30 秒)，然后将它们作为 HTTP put 请求发送出去，然后服务器可以将它们存储在其中。我相信这个模型实现起来更简单，并且可以更好地处理大流量，因为客户端可以一直缓冲数据，直到他们听到来自服务器的响应。
另一方面，我的老板想使用套接字编程来实现服务器。他认为套接字编程将导致传输的数据更少，这将提高系统的总效率。我不能不同意这一点，但我认为考虑到现代带宽，HTTP 的额外开销是值得的。另外，我认为试图与用户保持数千(或数百万)的同时连接会导致其自身的问题并大大增加服务器的复杂性。
老实说，我不知道解决这个问题的正确方法，所以我想我会把它贴在这里，并得到比我聪明得多的人的意见。如果任何答案包括所提出解决方案的利弊，我将不胜感激。
谢谢。
更新
我们现在清除了一些额外的要求。首先，移动客户端每月不能上传超过 5 GB 的数据。在这种情况下，我们每月每天 8 小时每秒发送一条消息。其次是我们希望尽可能少地组合消息。这是为了确保如果移动客户端出现问题(比如车祸)，我们会丢失尽可能少的数据。
最佳答案
您的老板似乎过早地进行了优化，这并不是一个好主意。
甚至在开始编写代码之前，不要试图与想象中的性能怪物作斗争，而应该检查应用程序的需求并针对它们进行设计。不要让感知到的问题驱动你的设计。
如果涉及到它，请让您的老板准确概述他将如何通过套接字连接编码数据，然后进行一些快速计算，看看您是否可以使用 HTTP 匹配或击败它们。他会使用 Google 的 Protocol Buffers 之类的东西，还是编写自己的编码(marshal)协议(protocol)？如果是这样，它会自我描述吗？像您在 HTTP 中免费获得的应用程序“动词”怎么样？他的关系会持久吗？ “套接字”不仅仅是打开一个连接并向下喷射字节。
您还正确地指出，您的老板似乎更喜欢套接字的原始速度而不是其他一切:可伸缩性、可维护性、开发和测试工具的可用性、协议(protocol)嗅探器、HTTPS 动词的有用语义等等。 HTTP 被负载平衡器和防火墙等很好地理解。你的专有套接字协议(protocol)就不会那么幸运了。
我的建议是您研究所有选项，并通过测试、原型(prototype)设计和基准测试从性能角度评估它们。然后权衡这些数字与使用该技术构建和维护应用程序的难度。
关于ruby-on-rails - 数据密集型应用程序的 RESTful Web 服务与 Socket 编程，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/6067538/