只需阅读需求文档。
其中一个要求是不应有任何异步调用。这似乎是一项安全要求。
问题是使用异步调用的安全漏洞是什么？还是有其他理由禁止他们？
所有传输都通过 Https/SSL。调用是 2 个系统之间的 Web 服务。
【问题讨论】：
标签： c# web-services security asynchronous
异步调用本质上没有任何问题，尽管它们可能更难处理。
【讨论】：
我唯一能想到的是，可能有轻微的可能性，即“已完成”事件可能被欺骗，从而将恶意数据提供给您的应用程序。
但是，我原以为这种可能性很小。
【讨论】：
异步调用通常可能存在竞争条件，有时可能会导致安全漏洞。
但是，出于这个原因彻底禁止它们就像禁止使用有符号整数，因为它们可以有时 lead to security vulnerabilities - 解决方案是了解问题，而不是彻底它在地毯下。
【讨论】：
异步调用，定义为进程中的一个线程派生另一个线程来进行调用并在父线程继续其业务时侦听结果，与同步进行的同一调用一样安全。从进程的外部观察者的角度来看，两者之间的唯一区别是侧线程是在等待调用结果时被阻塞的线程，而不是主线程。新线程获得一个新的堆栈和执行指针，但与进程的所有其他线程共享堆，线程可以通过引用访问其他线程堆栈中的变量。它是同一个程序，在同一个内存空间中执行，只是它的代码从两个地方而不是一个地方执行。
此外，可能无法编写没有任何异步操作的 C# 程序；运行时中内置了许多此类操作。例如，垃圾收集和运行时用来与各种 I/O 层对话的线程。事件驱动的 UI 编程是重线程的；每当用户执行某项操作时，运行时的“UI 线程”都会调用程序的“主线程”；否则它只是在等待。
【讨论】：
对于异步调用，很难保持调用的正确上下文，因为调用的最后部分通常会在随机线程上执行。模拟，由运行时设置的线程本地对象（如 ASP.Net 中的 HttpContext.Current），常规在运行可能依赖它们的代码之前，需要正确恢复静态/线程本地对象。
不允许异步调用会导致问题 - 桌面应用程序中的非响应式 UI 和服务应用程序的性能问题。
正如其他人指出的那样，编写异步代码比同步代码更难。有一些库可以帮助编写此类代码 - 即 http://msdn.microsoft.com/en-us/magazine/cc546608.aspx
【讨论】：