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