Networking 是否有必要使用队列来保存从客户端接收到的、等待转发到后端服务器的消息？ 我想为基于ASIO的SMB2编写一个代理服务器，并考虑使用一个累积缓冲区来接收一个完整的消息，以便做业务逻辑，并为多个消息引入一个队列，这将迫使我同步下面的资源访问： 队列上的读写操作，因为两个上游/下游队列由前端客户端和后端服务器共享 后端连接状态，因为在下一次读取之前，前端上的读取不会等待后端服务器上的连接或写入完成，并且 发生错误或连接正常关闭时的资源释放，因为在EventLoop中注册的同一scoket上的读写处理程序尚未完成，并且在工作线程中可以在其伙伴套接字关闭时启动异步连接操作，并且这些操作可以并发运行

如果不使用这两个队列，则只有一个（读、写和连接）处理程序向代理流上的EventLoop注册请求，因此无需同步

从应用层面看,

我认为，在多次相关API调用（系统API:recv或read，或库API:asio:：sync|U read）之后，为了处理完整的消息包（例如，fomat长度（4字节）|正文（变量）|中的消息），通常必须使用累积缓冲区

然后，是否需要使用队列来保存从客户端接收到的消息，并等待转发到后端服务器

使用下面的图表，它与我的想法类似（NGINX上游服务器中的

上游
概念）

偶尔，它会打印几个错误，“连接到10.23.57.158失败（错误NT\U状态\U IO\U超时）”。但是如果增加连接的数量，错误的数量就会增加，所以这是一个阈值？事实上，这些连接在30秒内完成，我还将smbclient的超时设置为100。怎么了

现在，我知道这些问题需要解决。但在这里，我只想知道“是否有必要使用队列来保存从客户端接收到的消息以及等待转发到后端服务器的消息？”这样我就可以确定我的目标，因为这会导致很大的差异

可能他们不关心应用程序消息格式，下面的示例将在完成对它的写入操作后重新测试下一次读取。
或者

其他参考资料



在github
在维基百科

                                    ---> upstream --->           +---------------+
                                                     +---->------>               |
                               +-----------+         |           | Remote Server |
                     +--------->          [x]--->----+  +---<---[x]              |
                     |         | TCP Proxy |            |        +---------------+
 +-----------+       |  +--<--[x] Server   <-----<------+
 |          [x]--->--+  |      +-----------+
 |  Client   |          |
 |           <-----<----+
 +-----------+
                <--- downstream <---

   Frontend                                                           Backend