2

我想知道为什么 Windows Azure 服务总线通过 NAT、防火墙、代理工作。微软经常提到这个事实，但他们没有提到为什么会这样。

我认为每个参与者都会发起连接，好的，但这还不够。他们是否“滥用”了一些开放的端口，80？

谢谢

4

4 回答 4

3

如果没有运行 Wireshark 能够确定，我猜是因为客户端（在 nat/防火墙后面）启动连接并保持调用服务器（始终打开）以获取更多信息。

让我们进一步解释一下：因为 tis 在 Windows 套接字（以及其他套接字系统）中的工作方式略有不同：

  1. 客户端 (C) 在端口 80 上启动与服务器 (S) 的连接

  2. 服务器然后响应客户端：80 上的调用太多，让我们将连接移动到端口 90000 + rnd() = 90001 的下一个空闲套接字

  3. 客户端套接字管理器计算客户端上未使用的套接字，并说找到 C:90012 端口

  4. 客户端在 S:90001 调用服务器，并在 C:90012 和 S:90001 之间启动正确的连接

  5. 这将被写入 nat/防火墙盒上的 nat 表中，并允许 C <-> S 之间的通信

于 2012-02-28T14:28:35.413 回答
3

如果可能，服务总线将尝试使用 9350 - 9353 端口进行 TCP 连接，以获得更好的性能。如果失败，它将尝试使用 80 和 443。由于在大多数情况下防火墙不会阻止 80 和 443，因此您的本地服务可以通过 80/443 连接到 sb://xxxx/，而无需对防火墙进行任何更改。然后如果客户端调用你的服务，它会首先点击 sb://xxxx/ ，然后服务总线会通过 80/443 将请求转发到你的机器，然后你将回复发送回服务总线，它会转发回复回到客户端。

那是服务远程模式。如果您使用事件模式，则类似的步骤。

于 2012-02-29T02:05:47.447 回答
2

仅仅是因为每个连接都是出站的，并且服务总线充当“转发器”。

于 2012-02-28T14:21:43.877 回答
1

在许多配置下，它确实只使用 80 (http) 和 443 (https)，​​如下所示。但是，它看起来有时也使用 9350、9351、9352 和 9353 - 所以在某些情况下，您可能需要打开它们。

于 2012-02-28T14:13:24.610 回答