使用 BeginAccept 与使用 TcpListener 阻塞 Accept 的专用线程相比，我可以获得什么好处？答案

【问题标题】：What benefits do I gain using BeginAccept vs a dedicated thread that blocks on Accept using TcpListener?使用 BeginAccept 与使用 TcpListener 阻塞 Accept 的专用线程相比，我可以获得什么好处？
【发布时间】：2013-03-01 19:22:52
【问题描述】：

我试图考虑是否会从使用 BeginAccept 与仅阻塞在等待连接的专用线程中获得任何可伸缩性优势。显然，各个客户端将使用 BeginXXX/EndXXX 对来利用 IOCP 进行网络 IO，但我认为等待客户端连接的延迟应该非常低。我计划创建一个任务来处理传入的连接，这样我在接受完成后的后续代码不会阻塞主接受线程很长时间（足够长来创建一个任务对象），我可以马上回到阻塞状态在新的连接上。这几乎就是我对 BeginAccept/EndAccept 所做的事情，而无需管理异步调用的复杂性。

那么，我的问题是，如果有的话，我可以通过使用 IOCP 来接受可扩展性优势吗？请注意，这不是用于在单个客户端套接字上发送/接收，而只是用于接受服务器侦听套接字上的连接。

【问题讨论】：

如果你的应用想要监听 100 个端口，你想浪费 100MB 的内存让 100 个线程阻塞等待连接吗？
@JonSkeet 有趣的一点，但是如果您的应用正在侦听 100 个端口，您可能应该首先重新考虑应用的设计：D
您可以只监听 1 个端口并在接受传入连接后重用它（再次监听）。就像网络服务器在 80 端口上所做的那样。
@AgentFire：不，我的意思是真的监听多个端口 - 不同的数字。
@Jon 不确定你从哪里得到的，但我有一个线程阻止接受。这是一个单线程，而不是监听多个端口的多个线程——这太疯狂了。我也没有为每个客户端启动线程，而是使用 BeginXXX/EndXXX IOCP 调用。我的问题是使用 BeginAccept 与阻塞 Accept 相比，我可以获得哪些 IOCP 好处？另外，用另一个问题回答一个问题也不是很有帮助。

标签： c# sockets asynchronous

【解决方案1】：

如果您只有一个端口正在监听，那可能不值得 - 就像您一次只需要处理几个连接一样，您可能不会费心使用异步操作来处理这些.

异步的服务器端好处通常是在您扩大规模时 - 对于处理连接，当您获得大量连接时；对于BeginAccept，这是您在许多不同端口上监听的时候。这可能比较少见，但如果您确实想要监听 100 个不同的端口（例如，如果您在一台服务器上托管大量网站，并且出于某种原因只想监听不同的端口而不是使用 Host headers) 那么你不希望 100 个线程坐在那里只是消耗堆栈空间。

【讨论】：