Использование IHttpHandler и Threadpool VS с использованием IHttpAsyncHandler

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

Предположим, у вас есть сто тысяч клиентов, каждый из которых ведет длинный опрос - вы действительно хотите 100 000 потоков? (Подсказка: сомневаюсь, что у вас достаточно памяти ...)

При подлинной асинхронности вы можете реагировать на события, завершая запрос без наличия выделенного потока для каждого запроса. Обратите внимание, что в C # 5 и .NET 4.5 есть и более простые способы, чем использование IHttpAsyncHandler. Это зависит от того, чего вы пытаетесь достичь, но и WCF, и MVC имеют асинхронные подходы, в которых вы можете написать асинхронный метод, используя выражения await и т. Д. Если вы затем ожидаете чего-то, что само по себе не принимает поток (например, таймер или, возможно, завершение ввода-вывода), тогда вы можете управлять огромным количеством одновременных подключений.

РЕДАКТИРОВАТЬ: Чтобы ответить на ваши дальнейшие вопросы: да, если вы используете только IHttpHandler, запрос должен быть выполнен после завершения вызова ProcessRequest. Вы не можете просто оставить его «висящим» ... тогда как IHttpAsyncHandler разрешает выполнение запроса до тех пор, пока не будет вызван EndProcessRequest. Не забывайте, что это очень старый интерфейс - он не очень четко документирован, и я бы не предлагал использовать его в наши дни, когда есть значительно лучшие подходы к асинхронности, особенно с использованием .NET 4.5 и C # 5. Но основной момент в том, чтобы иметь возможность иметь запрос в процессе, но без какого-либо конкретного потока, связанного с ним, все еще сохраняется.