Linux 在“tcp”之间选择；“长”；连接和；简称；内部服务的连接

我得到了一个应用程序，web服务器将一些请求重新定向到后端服务器，后端服务器（Linux）将执行复杂的计算并响应web服务器。 对于web服务器和后端服务器之间的tcp套接字连接管理，我认为有两种基本策略：

“短”连接：即每个请求一个连接。这对于套接字管理和简化整个程序结构来说似乎非常容易。在接受之后，我们只需要一些线程来处理请求，最后关闭这个套接字

“长”连接：也就是说，对于一个tcp连接，可以一个接一个地有多个请求。这个策略似乎可以更好地利用套接字资源，并带来一些性能改进（我不太确定）但是这似乎比“短”连接带来了很多复杂性。例如，由于现在多线程可以使用套接字fd，因此必须涉及同步。还有更多，套接字失败过程，消息序列

对这两种策略有什么建议吗

更新：，@SargeATM的回答提醒我应该告诉更多关于后端服务的信息。

---

每个请求都是上下文无关的。后端服务可以基于单个请求消息进行计算。这似乎是无状态的。

如果不考虑后端的体系结构，我认为这会严重影响这一决定，我更喜欢短连接用于无状态的“快速”请求/响应类型通信，长连接用于有状态协议，如同步或文件传输

我知道建立新连接（如果不是本地主机）会有一些tcp开销，但这从来都不是我在应用程序中必须优化的

---

好的，我会学习一点建筑学，因为这很重要。我总是不按请求使用线程，而是按函数使用线程。所以我会有一根线在插座上监听。另一个线程读取所有活动连接的数据包，另一个线程执行后端计算，最后一个线程保存到数据库（如果需要）。这使事情保持干净和简单。易于测量、维护和在需要时进行优化。

第三个选项如何。。。没有联系

如果您的工作描述和工作结果都很小，那么UDP套接字可能是一个好主意。您需要管理的资源更少，因为不需要将请求/响应绑定到文件描述符，这为将来提供了一些灵活性。假设您有更多的后端服务，并且希望进行一些负载平衡—繁忙的服务可以将作业发送到另一个具有作业提交者UDP地址的服务。后者只是等待结果，并不关心您在哪里执行任务

显然，您必须处理丢失、重复和无序的数据包，但作为奖励，您不必处理断开的连接。如果您可以将请求和响应放在一条UDP消息中，那么无序的数据包可能不是什么大问题，复制可以由一些作业ID处理，而丢失的数据包。。。嗯，他们可能只是怨恨；-）

想想这个

嗯，你是对的

持久连接的最大问题是确保应用程序从池中获得“干净”连接。没有来自另一个请求的任何数据垃圾

---

有很多方法可以解决这个问题，但最后最好关闭（）受污染的连接并打开新的连接，而不是试图清除它…

谢谢。我从来没有想过这一点，因为我只是遵循遗留代码结构。但我担心大多数请求不能包含在一条UDP消息中。我会记住你的策略~