WCF：异步调用更安全吗？答案

【问题标题】：WCF: Are asynch calls more secure?WCF：异步调用更安全吗？
【发布时间】：2010-07-13 09:30:32
【问题描述】：

在我目前正在工作的项目中，我们正在使用 WCF。公司政策迫使我们使用异步调用，原因应该是安全性。我问过为什么这样更安全，但我没有得到明确的答案。

有人能解释一下为什么这么安全吗？

【问题讨论】：

【解决方案1】：

他们不是。相同的安全（身份验证、加密）机制和注意事项适用于调用是否阻塞直到它得到响应或使用回调。

人们可能会混淆认为异步调用更“安全/可靠”的唯一方法是，他们认为未处理的 WCF 异常如果是异步的，则不会关闭主线程，因为它们会在回调中引发.

在这种情况下，我建议在与此政策的所有者联系时要格外小心，以避免职业生涯受到限制。有些人可能会对他们的政策产生情感上的依恋。

【讨论】：

去过那里，被那个灼伤，不希望它在任何人身上：P
为避免职业生涯受到限制的后果，或许向政策制定者展示此页面？
'如果 wcf 异常是异步的，它们不会关闭主线程' 恰恰相反。 WCF 入口线程上抛出的异常将被编组，依此类推。他们可能会破坏频道，但这只是因为您没有正确翻译它们（即这是设计使然）。他们并没有真正造成任何损害。但是，除非处理，否则在您剥离的任何后台线程上引发的异常都是进程终止（！）。因此，从这个角度来看，同步实现所有内容肯定会更安全，在堆栈中进一步进行大尝试{}...

【解决方案2】：

没有理由说异步调用比同步调用更安全。我认为您应该与该政策的所有者交谈。

【讨论】：

【解决方案3】：

不，它们并不比同步调用更安全或更不安全。唯一的区别是客户端在同步调用上等待响应，而在异步上它是通知响应。

它们是从同步调用使连接打开更长时间的角度还是什么？

【讨论】：

【解决方案4】：

仅使用异步签名 (BeginBlah/EndBlah) 公开 WCF 操作实际上根本不会影响公开的操作。当您查看元数据时，像

这样的操作

[OperationContract(AsyncPattern=true)]
IAsyncResult BeginSomething(AsyncCallback, object)

void EndSomething(IAsyncResult)

...实际上仍然最终被表示为一个名为“某事”的操作。实际上，这是 WCF 的优点之一：客户端和服务器在选择同步实施/使用操作方面可能有所不同。

因此，如果您使用生成 WCF 代理（例如通过添加服务引用），那么您将获得每个操作的同步版本无论它们是否异步实现，除非您勾选小复选框以生成异步重载。当您这样做时，您将获得可能仅在服务器上同步声明的异步操作版本。

WCF 所做的只是在客户端和服务器上为您提供有关线程模型的选择：您希望 WCF 等待结果，还是向它发出信号表明您已经完成。实际运输连接的管理方式 - 据我所知 - 完全不受影响。例如：对于 NetTcpBinding，无论哪种方式，套接字在调用期间仍保持打开状态。

所以，直截了当地说，我真的很难想象这会对 WCF 服务的安全范围产生什么影响。如果服务使用异步模式公开，并且真正以异步方式实现（用于出站 IO 的异步，或者队列通过线程池或其他方式工作），那么可能会有一个论点是对服务进行 DOS 处理会更加困难（通过耗尽 WCF IO 线程池），但仅此而已。

注意：如果您共享客户端和服务器之间的合约接口，那么显然两端的同步性匹配（因为它们都使用相同的接口类型），但这只是一个限制使用共享接口。如果您制作了另一个 equivilent 接口，仅在异步模式上有所不同，您仍然可以针对它创建一个 ChannelFactory。

【讨论】：

【解决方案5】：

我同意其他答案 - 绝对不是更安全。

启动Fiddler 并观察同步请求与异步请求。您基本上会看到相同类型的流量（尽管同步可能会发送和接收更多数据，因为它可能是回发）。但是你可以拦截这两个请求，操纵它们，然后重新发送它们，从而对你的服务器造成严重破坏。

顺便说一句，Fiddler 是一个很棒的工具。就您发送到服务器的数据类型和数据量而言，这让您大开眼界。

【讨论】：