Блог

В синхронной модели, когда клиент подключается к серверу, и клиент, и сервер должны синхронизироваться друг с другом, чтобы завершить некоторые операции.

Между тем, асинхронная модель позволяет клиенту и серверу работать раздельно и независимо. Клиент отправляет запрос на установление соединения и выполнение чего-либо. Пока сервер обрабатывает запрос, клиент может сделать что-то еще. По завершении операции событие завершения помещается в очередь в демультиплексоре событий, ожидая, пока проактор (например, обработчик HTTP) отправит запрос обратно и вызовет обработчик завершения (на клиенте). Термины используются как в boost::asio документируют шаблон проектирования Proactor: параллелизм без потоков.

Работая таким образом, асинхронная модель может принимать одновременные соединения без необходимости создавать поток для каждого соединения, что повышает общую производительность. Для достижения того же эффекта, что и асинхронная модель, первая модель (синхронная) должна быть многопоточной. Для получения более подробной информации обратитесь к: Шаблон Proactor (я на самом деле изучаю шаблон proactor, который используется для асинхронной модели из этого документа. Здесь у него есть описание на типичном веб-сервере синхронного ввода-вывода).

Правильно ли я понимаю этот вопрос? Если это так, что означает, что асинхронный сервер может принимать запрос и возвращать результаты асинхронно (первый запрос на подключение, на который служба на веб-сервере не обязательно должна отвечать первой)? По сути, асинхронная модель не использует потоковую обработку (или потоковую обработку используют в отдельных компонентах, например, в компоненте Proactor, мультиплексоре асинхронных событий (boost::asio document), а не путем создания всего стека клиент-серверных приложений, который описан в многопоточной модели в документе шаблона Proactor, раздел 2.2 — Общие ловушки и подводные камни обычных моделей параллелизма).

Модель Proactor предполагает разделение процесса сетевого сеанса на подзадачи, такие как: разрешение имени хоста, прием или подключение, чтение или запись некоторой части информации, закрытие соединения — и позволяет переключаться между подзадачами из разных сеансов. Принимая во внимание, что модель реактора рассматривает процесс сетевого сеанса как (почти) единую задачу.

Абсолютные преимущества Proactor:

• Производительность повышается из-за задачи «аутсорсинг». Например, вы можете отправить запрос на разрешение в DNS и подождать 5 минут ответа, ничего не делая (реактор), или вы можете делать другие вещи во время ожидания (Proactor).

Абсолютные недостатки Proactor:

• Производительность снижается из-за переключения задач, что означает, что за один сеанс вы выполняете больше кода (Proactor), чем должно быть (Reactor).

Но общая производительность обычно измеряется количеством «удовлетворенных» клиентов за период времени. Итак, преимущества Proactor по сравнению Реактор зависит от ситуации. Вот несколько примеров.

1. HTTP-сервер. Клиент хочет что-то увидеть в окне своего браузера. Ему не нужно ждать, пока загрузится вся страница, чтобы увидеть первые фрагменты текста. Proactor эффективен, поскольку частичная загрузка страницы происходит быстрее, чем загрузка всей страницы. Тем не менее, вся страница загружается примерно в то же время, что и в реакторной модели.

2. Игровой сервер с низкой задержкой. Клиент хочет получить полный результат своей команды как можно быстрее. Реактор эффективен, поскольку нет таких подзадач, как частичное чтение или запись — клиент ничего не увидит, пока не прочитает полный ответ. Таким образом, реактор не будет выполнять дополнительные переключения между подзадачами, и в каждый момент гарантируется, что какой-то клиент получит прогресс по своей команде, в то время как Proactor заставит всех клиентов ждать друг друга непредсказуемое время.

Многопоточность может дать вам линейное ускорение в обоих случаях.