我们正在开发一个浏览器扩展，它将把登录用户访问的所有URL发送到后端API以进行持久化。
现在，由于发送到后端API的请求数量将是巨大的，因此我们混淆了是通过websocket创建持久连接，还是通过TCP连接，即使用HTTP rest API调用。
发布到后端API的数据不需要是实时的，因为我们无论如何都会在我们的模型中使用这些数据，而这并不要求它们是实时的。
由于以下原因，我们倾向于使用HTTP rest API调用
- 易于实现
- 易于缩放(使用自动缩放技术(
- 团队中的每个人都已经熟悉了其余的API
但同时缺点是
- 在我们将有大量帖子请求发送到服务器的规模上，不确定它是否会得到优化
- 感觉websocket可以为我们提供优化的基础设施：(
如果我能听到社区的声音，如果我们在使用其余API调用选项时有任何陷阱，我会很高兴。
所以首先TCP是传输层。使用原始TCP是不可能的，你必须在它上面创建一些协议。你必须赋予数据流意义。
REST、HTTP甚至WebSocket永远不会像在原始TCP(甚至UDP(之上定制的协议那样高效。然而，收益可能并不像人们想象的那么惊人。事实上，我已经做过一次这样的转变，我们只经历了百分之几的性能提升。它既不容易做到正确，也不容易维护。当然是YMMV。
为什么？原因是HTTP已经进行了高度优化。首先，你有"保持活力"；如果使用连接，则保持连接打开的标头。因此，默认的HTTP机制在使用时已经保持了连接。其次，默认情况下，HTTP处理正文压缩，使用HTTP/2时，它还处理头压缩。有了HTTP/3，您甚至可以更高效地使用TLS，并在网络不稳定的情况下提供更好的支持(例如移动(。
另一件事是，由于您不需要实时数据，因此可以进行缓冲。因此，你不会每次都发送数据，而是在几秒钟、几分钟甚至几个小时内收集数据，然后一次性发送所有数据。有了这样的方法，HTTP和自定义协议之间的差异将更加不引人注目。
总而言之：我建议你从最简单的解决方案开始，在你的情况下，它似乎是REST。设计你的代码，使转换到其他协议尽可能简单。如果需要，稍后进行优化。始终测量。
顺便说一句，你的扩展有很多有效的隐私和安全问题。例如，我很惊讶你根本没有提到TLS。这一点很重要，不仅因为安全性，还因为性能：建立TLS连接不是免费的(尽管一旦建立，加密不会对性能产生太大影响(。
抛开我的不适(隐私，有人吗？(。。。
假设您的扩展核对了信息，您可能会考虑"；推动"；每次浏览器启动/退出时都会发送到服务器，然后每隔一个小时左右再发送一次(现在用户几乎从来没有完全使用过他们的浏览器(。。。这将使REST更加合乎逻辑。
如果您不在客户端整理信息，您可能更喜欢实时推送数据的WebSocket实现。
然而，无论您做出什么决定，您还希望将API与传输层解耦。
这意味着(忽略身份验证范式(WebSockets和REST实现看起来基本相同，并被路由到包含实际业务逻辑的相同函数。。。您也可以从脚本或终端调用函数。就API实现而言，网络层细节应该是无关的。
最后一点注意：我永远不会故意安装一个收集这么多数据的扩展。特别是因为URL通常包含私人信息(用于REST API路由(。如果你想参与创建这样的产品，请重新考虑如果我们不构建使其成为可能的工具，它们就不会侵犯我们的隐私。