我目前正在阅读 Web 服务。 http://www.w3schools.com/soap/soap_intro.asp 有一个 SOAP 教程。以下段落来自该页面：
“今天的应用程序在 DCOM 和 CORBA 等对象之间使用远程过程调用 (RPC) 进行通信，但 HTTP 并不是为此而设计的。RPC 代表了兼容性和安全性问题；防火墙和代理服务器通常会阻止这种流量。”
我不明白这一点。有人可以向我解释一下吗？特别是我想知道，为什么 RPC 是一个安全问题（至少通过 HTTP）。知道为什么它是一个兼容性问题也很好。
【问题讨论】：
标签： web-services http soap rpc
关于兼容性，问题在于，让使用 DCOM 的东西与使用 CORBA 的东西对话并不明显。 SOAP 的目标之一是提供互操作性，以便协调这种通信的实现方式。 （根据您使用的工具，与 SOAP 的互操作性可能仍然存在一些小故障。）
关于安全性，长期以来，围绕使用端口号来区分应用程序制定了策略：如果要阻止某个服务（例如 NNTP），则在防火墙级别阻止其端口。它可以很容易地粗略控制可以使用哪些应用程序。 SOAP over HTTP 所做的就是将问题推到上一层。您无法再通过 TCP 级别的端口号来区分使用了哪个应用程序或服务，而是必须能够分析 HTTP 消息和 SOAP 消息的内容以授权某些应用程序或服务。
SOAP 主要使用 HTTP POST 发送消息：即使用 HTTP 作为 传输 协议，而 HTTP 是 传输 协议，因此不使用 HTTP Web 架构（SOAP 2 可能试图改善这种情况）。因为现在几乎每个人都需要访问网络，所以几乎可以保证 HTTP 端口不会被阻塞。如果在此之上没有添加安全层，那实际上是在使用一个漏洞。 话虽这么说，在安全性方面，使用 HTTP 进行 SOAP 通信是有优势的，因为在现有的 HTTP 身份验证系统方面有更多的协调性。 SOAP/WS-* 堆栈试图做的是协调“RPC”通信，独立于平台。这不是“SOAP 是安全的”v.s. 的情况。 “DCOM/CORBA 不是”，您仍然必须使用它的安全组件，例如WS-Security，并且您可能已经能够使用其他系统实现合理的安全级别。
【讨论】：
他们要强调的是，“传统 RPC”有时会使用不寻常的低级网络协议，而这些协议通常会被公司防火墙阻止。因为 SOAP 使用 HTTP，所以它的流量与普通网页视图“无法区分”，因此不会被这些防火墙捕获。 不太确定安全点，我认为他们可能暗示 HTTP 可以通过 HTTPS 轻松保护，而专有 RPC 协议通常不能。当然，这取决于协议，并非所有的 RPC 协议都是不安全的，其中许多协议都可以通过 HTTPS 进行隧道传输。
【讨论】：