我有一个应用程序，Web服务器将一些请求重定向到后端服务器，而后端服务器（Linux）将执行复杂的计算和对Web服务器的响应。 对于Web服务器和后端服务器之间的tcp套接字连接管理，我认为有两个基本策略：
“短”连接：即每个请求一个连接。对于套接字管理来说这似乎很容易，并简化了整个程序结构。在接受之后，我们只需要一些线程来处理请求，最后关闭此套接字。
“long”连接：也就是说，对于一个tcp连接，可能会有多个请求逐个连接。看来这种策略可以更好地利用套接字资源并带来一些性能提升（我不太确定）。 但是它似乎比“短”连接带来了很多复杂性。例如，由于现在套接字fd可能被多线程使用，因此必须涉及同步。还有更多，套接字失败过程，消息序列......
对这两种策略有什么建议吗？
更新：，@ SargeATM的回答提醒我，我应该详细介绍后端服务。 每个请求都是无上下文的。后端服务可以基于单个请求消息进行计算。好像是......无状态的。
答案 0 :(得分：2)
如果没有进入我认为会严重影响这一决定的后端架构，我更喜欢短连接，用于无状态“快速”请求/响应类型流量以及有状态协议的长连接，如同步或文件传输。
我知道有一些tcp开销用于建立新连接（如果它不是本地主机），但从来没有我在应用程序中优化的任何东西。
好的，我会对架构有所了解，因为这很重要。我总是不是按照请求而是按功能使用线程。所以我会有一个在socket上监听的线程。另一个线程从所有活动连接读取数据包，另一个线程执行后端计算，最后一个线程在需要时保存到数据库。这样可以保持简洁。易于测量慢点，维护，并在需要时根据需要进行优化。
答案 1 :(得分：0)
第三个选项怎么样...... 没有连接！
如果您的职位描述和工作结果都很小，UDP套接字可能是个好主意。您拥有更少的资源来管理，因为不需要将请求/响应绑定到文件描述符，这为您的未来提供了一些灵活性。想象一下，您有更多的后端服务，并希望进行一些负载平衡 - 繁忙的服务可以将作业发送到另一个具有作业提交者的UDP地址的作业。后者只是等待结果，而不关心你执行任务的位置。
显然，您必须处理丢失，重复和乱序的数据包，但作为奖励，您不必处理断开的连接。如果您可以在一条UDP消息中处理请求和响应，那么乱序包可能不是什么大问题，一些工作ID可以处理重复，丢失数据包......好吧，它们可以简单地重新发送;-)
考虑一下这个！
答案 2 :(得分：0)
嗯，你是对的。
持久连接的最大问题是确保应用程序从池中获得“干净”的连接。没有任何垃圾来自另一个请求的数据。
有很多方法可以解决这个问题，但最后关闭（）污染连接并打开新连接比尝试清理它更好......