我有一个应用程序，Web 服务器将一些请求重定向到后端服务器，后端服务器(Linux)将对 Web 服务器进行复杂的计算和响应。 对于web服务器和后端服务器之间的tcp socket连接管理，我认为有两种基本策略:
“短”连接:即每个请求一个连接。这对于套接字管理和简化整个程序结构来说似乎非常容易。 接受后，我们只需要一些线程来处理请求，最后关闭这个套接字。
“长”连接:即对于一个tcp连接，可以有多个请求一个接一个。似乎这种策略可以更好地利用套接字资源并带来一些性能提升(我不太确定)。 但是 这似乎比“短”连接带来了很多复杂性。例如，由于现在socket fd可能被多线程使用，所以必须涉及到同步。还有更多，socket失败过程，消息序列...
这两个策略有什么建议吗？
更新:，@SargeATM 的回答提醒我应该详细介绍后端服务。 每个请求都是上下文无关的。后端服务可以根据一条请求消息进行计算。好像是……无国籍。
最佳答案
在不深入我认为对这个决定有重大影响的后端架构的情况下，我更喜欢无状态“快速”请求/响应类型流量的短连接和同步或文件传输等有状态协议(protocol)的长连接。
我知道建立新连接(如果它不是本地主机)会产生一些 tcp 开销，但这从来都不是我必须在我的应用程序中优化的任何内容。
好的，我会稍微了解一下架构，因为这很重要。我总是不是按请求而是按功能使用线程。所以我会有一个在套接字上监听的线程。另一个线程从所有事件连接中读取数据包，另一个线程执行后端计算，最后一个线程在需要时保存到数据库。这使事情变得干净和简单。易于测量慢点、维护并在以后需要时进行优化。
关于linux - 在 tcp "long"连接和 "short"连接之间选择内部服务，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/11406405/