Web 服务器中的前摄器模式和同步模型之间的区别
在同步模型中，当客户端连接到服务器时，客户端和服务器都必须相互同步才能完成某些操作。
同时，异步模型允许客户端和服务器分开、独立地工作。客户端发送请求以建立连接并执行某些操作。当服务器处理请求时，客户端可以做其他事情。操作完成后，完成事件被放置到事件多路分离器中的队列中，等待前摄器（例如 HTTP 处理程序）发回请求并调用完成处理程序（在客户端）。这些术语的使用如 boost::asio 文档 前摄器设计模式：无线程并发。
通过这种方式，异步模型可以接受同时连接，而不必为每个连接创建一个线程，从而提高整体性能。为了达到与异步模型相同的效果，第一个模型（同步）必须是多线程的。更详细的内容请参考：前摄器Pattern （我实际上从该文档中学习了用于异步模型的前摄器模式。这里有关于典型同步 I/O Web 服务器的描述）。
我对这个问题的理解正确吗？如果是这样，这意味着异步服务器可以异步接受请求并返回结果（Web 服务器上的服务不需要第一个响应第一个连接请求）？本质上，异步模型不使用线程（或者在各个组件中使用线程，例如在 Proactor、Asynchronous Event Multiplexer（boost::asio 文档）组件中，而不是通过创建整个客户端-服务器应用程序堆栈，这被描述为在前摄器模式文档的多线程模型中，第 2.2 节 - 传统并发模型的常见陷阱和陷阱）。
In synchronous model, when a client connects to the server, both the client and server have to sync with each other to finish some operations.
Meanwhile, the asynchronous model allows client and server to work separated and independently. The client sends a request to establish a connection and do something. While the server is processing the request, the client can do something else. Upon completion of an operation, the completion event is placed onto a queue in an Event Demultiplexer, waiting for a Proactor (such as HTTP Handler) to send the request back and invoke a Completion Handler (on the client). The terms are used as in boost::asio document The Proactor Design Pattern: Concurrency Without Threads.
By working this way, the asynchronous model can accepts simultaneous connections without having to create a thread per connection, thus improve overall performance. In order to achieve the same effect as asynchronous model, the first model (synchronous) must be multi-threaded. For more detail, refer to: Proactor Pattern (I actually learn proactor pattern which is used to asynchronous model from that document. In here it has description on a typical synchronous I/O web server).
Is my understanding on the subject correct? If so, which means the asynchronous server can accepts request and return results asynchronously (the first connection request the service on web server does not need to be the first to reply to)? In essence, asynchronous model does not use threading (or threading is used in individual components, such as in the Proactor, Asynchronous Event Multiplexer (boost::asio document) component, not by creating an entire client-server application stack, which is describe in the multi-threaded model in Proactor Pattern document, section 2.2 - Common Traps and Pitfalls of Conventional Concurrency Models).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
Proactor 模型假设将网络会话过程拆分为子任务，例如：解析主机名、接受或连接、读取或写入部分信息、关闭连接，并允许您在不同会话的子任务之间切换。然而，Reactor 模型将网络会话过程视为（几乎）单个任务。
Proactor的绝对优势：
Proactor 的绝对缺点：
但总体绩效通常是根据每个时间段内“满意”的客户数量来衡量的。所以，Proactor 与 Reactor 的优势取决于具体情况。这里有一些例子。
HTTP 服务器。客户希望在他的浏览器窗口中看到一些内容。他不需要等到整个页面加载完毕才能看到第一段文本。前摄器是有效的，因为部分页面加载比整个页面加载更快。整个页面的加载时间仍然与 Reactor 模型中的加载时间大致相同。
低延迟游戏服务器。客户希望尽快得到其命令的完整结果。反应堆是有效的，因为没有像部分读取或写入这样的子任务 - 客户端在读取完整响应之前不会看到任何内容。因此，Reactor 不会在子任务之间进行额外的切换，并且在每个时刻都可以保证某个客户端在其命令上取得进展，而 Proactor 将迫使所有客户端相互等待不可预测的时间。
在这两种情况下，多线程都可以为您提供线性加速。
The Proactor model assumes splitting the network session process in a subtasks like: resolving hostname, accepting or connecting, reading or writing some part of information, closing connection - and allows you to switch between subtasks from different sessions. Whereas, the Reactor model sees the network session process as a (almost) single task.
The absolute Proactor advantages:
The absolute Proactor disadvantages:
But the overall performance usually is measured in a number of "satisfied" clients per time period. So, the advantages of Proactor vs. Reactor depend on the situation. Here goes some examples.
HTTP server. The client wants to see something in his browser window. He doesn't need to wait before the whole page is loaded to see the first pieces of text. The Proactor is effective, since the partial page loading is faster than the whole page loading. Still the whole page is loaded about the same time as in the Reactor model.
Low-latency game server. The client wants to get the complete result of his command as quick as possible. The Reactor is effective, since there are no subtasks like partial reading or writing - the client won't see anything until he reads the full response. So, the Reactor won't do additional switches between subtasks and at each moment it's guaranteed that some client gets progress on his command, while the Proactor will force all of the clients wait each other unpredictable time.
The multi-threading can give you a linear acceleration in both cases.