我有一个 FTP 服务器，在 QTcpServer 和 QTcpSocket 之上实现。
我利用信号和槽机制同时支持多个 TCP 连接，即使我只有一个线程。我的代码尽快返回到事件循环，它不会阻塞（没有等待函数），并且它不会在任何地方使用嵌套事件循环。这样我就已经有了协同多任务处理，就像 Win3.1 应用程序一样。
但是很多其他 FTP 服务器都是多线程的。现在我想知道使用单独的线程来处理每个 TCP 连接是否会提高性能，尤其是延迟。
一方面，线程会增加延迟，因为您需要为每个新连接启动一个新线程，但另一方面，在我的协作多任务处理中，其他 TCP 连接必须等到我返回主循环后才能发出readyRead()/bytesWritten()信号可以处理。
在您当前的系统中并忽略文件 I/O 时间，如果有一些有用的事情要做，一个处理器总是在做一些有用的事情，如果没有什么有用的事情要做，则等待准备就绪。如果这是一个单处理器（单核）系统，您将获得最大的吞吐量。这通常是一个非常好的设计——特别是对于一个 FTP 服务器，您通常不需要一个人在逐个数据包的基础上等待。
您还最小化了平均延迟（对于单处理器系统）。您没有的是一致的延迟。测量系统性能可能会显示很多抖动——处理数据包所需的时间有很多变化。同样因为这是 FTP 而不是实时过程控制或人工交互，所以抖动可能不是问题。
但是，现在请考虑您的系统上可能有多个处理器可用，并且可能会重叠 I/O 时间和处理时间。
要充分利用多处理器（核心）系统，您需要一些并发性。
这通常转换为使用多个线程，但可以通过异步（非阻塞）文件读取和写入来实现并发。
然而，在一个程序中添加多个线程会打开一个巨大的蠕虫罐。
如果你决定走 MT 路线，我建议你考虑依赖线程感知 I/O 库。QT 可能会为您提供（我不确定。）如果没有，请查看 boost::asio （或 ACE 用于较旧但仍然可靠的解决方案）。您会发现使用此类库的 MT 功能需要对学习时间进行大量投资；然而，事实证明，“手动”添加多线程并使其正确的时候会更糟。
所以我会说保留现有的解决方案，除非你担心未使用的处理器周期和/或抖动，在这种情况下开始学习 QT 的多线程支持或 boost::asio。
您是否需要为每个新连接启动一个新线程？你能不能只有一个线程池在请求到达时对请求起作用。这应该会减少一些延迟。我不得不说，一般来说，多线程 FTP 服务器应该比单线程服务器响应更快。是否有可能拥有基于事件的 FTP 服务器？