IHttpAsyncHandler 表示异步运行请求。
使用线程池也可以异步运行。
所以如果我想实现一个函数（比如 Comet，long poll），在使用带有 IHttpHandler 的线程池和使用 IHttpAsyncHandler 之间，哪个更好？
编辑：@Jon Skeet：感谢您耐心的回复。让我做一个结论。如果我在 IHttpHandler 中使用 delegate.BeginInvoke，处理请求的“主线程”仍然会一直旋转，直到请求结束，无论池线程发生了什么。如果我使用 IHttpAsyncHandler，处理请求的“主线程”将调用 BeginProcessRequest，然后将其释放（以处理其他请求）。BeginProcessRequest 方法将异步执行某些操作。当异步动作完成时，会调用 EndProcessRequest 方法。（或者我们可以说“主线程”将调用 EndProcessRequest 函数来完成当前请求）
以上都是我的想法，对吗？
不同之处在于，对于真正的异步模型，您根本不需要每个请求一个线程。如果每个请求都有一个线程，无论它是否在线程池中，您都将无法处理大量连接（因为您需要像长轮询这样的事情）。
假设你有 10 万个客户端，每个都长轮询——你真的想要 100,000 个线程吗？（提示：我怀疑你有足够的内存......）
使用真正的异步，您可以通过结束请求来对事件做出反应，而无需为每个请求指定一个专用线程。请注意，对于 C# 5 和 .NET 4.5，还有比使用更简单的方法IHttpAsyncHandler。这取决于您要实现的目标，但是 WCF 和 MVC 都具有面向异步的方法，您可以在其中编写异步方法，使用await表达式等。如果您然后等待本身不占用线程的东西（例如计时器，或者一些 IO 完成），那么您可以管理大量并发连接。
编辑：回答您的进一步问题：是的，如果您使用 just ，则必须在呼叫完成时完成IHttpHandler请求。您不能只是让它“悬空”......而允许请求仍在进行中，直到被调用。不过不要忘记这是一个非常古老的接口——它的文档记录不是很清楚，我不建议现在使用它，因为有明显更好的异步方法，特别是使用 .NET 4.5 和 C# 5。但是能够进行请求但没有任何特定线程与之关联的要点仍然成立。ProcessRequestIHttpAsyncHandlerEndProcessRequest