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