为了克服 Azure 负载均衡器上（明显的）4 分钟空闲连接超时，似乎有必要不时地通过管道向客户端发送一些数据，以防止连接被视为空闲。
我们的控制器设置为 AsyncController，它会在其他对象上触发几种不同的异步方法，所有这些方法都设置为使用 IO 完成端口。因此，我们立即从我们的方法返回，当完成数据包被处理时，IIS 会重新连接到原始请求，以便我们可以呈现我们的视图。
在这种情况下，有没有办法定期发送几个字节？在“经典”情况下，我们可以执行该方法，然后在等待时旋转，每隔几秒发送一次数据，直到异步方法完成。但是，在这种情况下，IIS 线程被释放以去做其他事情，我们在完成回调中重新连接到它。该怎么办？这可能吗？
虽然您的特定情况涉及 Windows Azure 特定（LB 的 4 分钟超时），但问题是纯粹的 IIS / ASP.NET 工作方式。无论如何，我认为在 AsyncController/AsyncPage 中不可能向客户端发送“ping-backs”。这就是 AsyncPages/Controllers 的全部思想。IIS 将套接字放在一边，让线程为其他请求提供服务。并且仅当您使用 AsyncManager.OutstandingOperations.Decrement() 将OutstandingOperations 归零时才返回；只有这样，控制权才会被交还给客户端以发送最终响应。一旦您成为发送响应的重点，就没有回头路了。
我宁愿争论为什么有人会等待 4 分钟才能得到响应的架构方法（即使有一个很好的动画“请稍候”）？这段时间可能会发生很多事情。从浏览器崩溃、互联网中断到客户端完全断电/中断。如果你在做真正的 Azure，为什么不通过队列（Azure 存储队列或服务总线队列）为 Worker 角色发送任务。对于这么长时间运行的任务，您面前的另一个选择是使用 SingalR 和完全 AJAXed 解决方案。您通过 SignalR 传达长期运行操作的状态的位置。
更新 1 由于评论
除了@knightpfhor 建议的方法之外，这也可以通过队列来实现。请求者创建一个具有唯一 ID 的任务并将其发送到“任务提交队列”。然后“侦听”（或定期/不定期轮询）“任务完成”队列以获取具有给定任务 ID 的消息。
无论如何，我看不到在整个长时间运行的任务期间保持客户端连接的理由。有许多方法可以解耦这种通信。