问题标签 [webhttprelaybinding]

当我尝试使用通用消息处理程序时，如果我使用我自己的类型（例如 text/x-json），我会在接受或内容类型为 html/xml/json 时遇到错误，一切都按预期工作，消息被发送到我的处理程序和流将数据返回给 webclient。我已经使用调试器逐步完成了此操作，并且我的代码成功创建了消息，但是服务总线绑定中的某些内容阻塞并导致服务器不响应。是否需要更改设置以允许 application/json 并使服务总线发送原始数据而不是尝试重新序列化它？

我正在尝试制作一个侦听服务总线的 WCF 应用程序。以下用于在 Web.config 中定义服务的代码段在设置为时multipleSiteBindingsEnabled有效false：

当multipleSiteBindingsEnabled设置为 时true，我将配置更改为以下内容：

这会导致以下错误： Could not find a base address that matches scheme https for the endpoint with binding WebHttpRelayBinding. Registered base address schemes are [http].

为了将 https 注册为方案，我还需要为该服务声明什么吗？请注意，我确实将绑定的安全模式设置为传输。

我正在使用 webHttpRelayBinding 通过服务总线中继公开托管在 IIS 上的 WCF 数据服务。虽然我可以找到如何使用用户名/密码或共享密钥来验证服务身份。但是，我找不到如何将基于证书的凭据用于服务身份的示例。我google了很多，但徒劳无功。它们都主要基于共享秘密。

任何人都可以提供一个示例，说明如何将基于证书的服务身份认证用于 REST OData 服务。

我正在使用中继绑定来创建 ChannelListener。

现在我想添加 ConnectionStatusBehavior 以便我知道频道使用的连接是否在线。有谁知道如何做到这一点？

外部提供者需要向我们的 BizTalk 环境发送回调。回调只是一个带有 XML 正文的 HTTP POST。

自然，我们不想在外部公开我们的 BizTalk，我们想在 Azure 中使用中继服务。

据我所知，BizTalk 中没有 WebHttpRelayBinding。有没有办法解决这个问题，还是我需要创建一个 .NET 服务来处理这个问题？

我已经使用 Microsoft Azure 设置了 ServiceBus 中继。我使用 HTTP 后端连接到这个，处理传入的 GET 和 POST 请求命中中继。

现在，这工作得很好。不过我的问题是我可以获得的最大并发是 2 个同时请求，即我的后端将只能同时接收 2 个请求，如果有更多请求，它们将被停止，直到之前的请求被处理和完成。我尝试通过服务行为增加并发性，但这似乎被忽略了，但是将并发性降低到 1 似乎正在使用设置。所以我猜这是实际继电器施加的某种限制！？但这真的可以吗？只有2个？在我的场景中，这使得中继无法使用，因为请求必须进行耗时的处理（2 秒），不能延迟并且需要立即响应。因此，我不能简单地存储请求并像队列一样处理它们。

我怎样才能扩大规模？添加更多继电器并连接到所有继电器？

我们正在构建一个允许从云端调用本地 API 的平台，为此我们使用 WCF 中继，这实际上是适合我们的服务，因为我们需要动态创建中继（我们有一个载入 API它负责验证客户许可，并在许可有效的情况下在 Azure 中创建中继，以使云 API 和本地 API 之间的通信成为可能）。

目前，我们的 QA 团队正在进行负载测试，以了解有多少流量支持该平台，在测试期间，我们的 QA 团队在运行来自 JMeter 的 50 个并发请求的测试时检测到了一个奇怪的行为。

基本上，在这种情况下（50 个并发请求），一些请求由于 502 Bad Gateway 响应而失败，这些响应来自中继，因为内容类型是 XML。

502 Bad Gateway 响应告诉侦听器在允许的时间间隔内没有接受连接，但奇怪的是，一旦我们收到 502 Bad Gateway 响应，就没有更多请求到达侦听器（本地 API），使通信再次起作用的唯一方法是关闭侦听器并重新启动它。

据我所知，WCF 中继支持负载均衡，使用随机策略选择负责处理请求的侦听器，我在 Github repo 中找到了一个属于 WCF 中继服务的线程，其中描述负载均衡算法如下：

1. 获取发送者请求的地址的所有已知负载平衡侦听器列表的本地副本（这来自每 500 毫秒更新一次的缓存）。
2. 如果侦听器列表为空，并且我们没有完全刷新侦听器列表一次，则强制刷新端点的已知负载平衡侦听器列表。
3. 如果侦听器列表为空，则向发送者返回异常并停止。
4. 在潜在听众列表中选择一个随机索引。
5. 尝试与选定的侦听器会合。
6. 如果该会合成功，则停止。
7. 如果与所选侦听器的集合尝试在 10 秒内未成功，则从要尝试的侦听器列表中删除所选侦听器。
8. 如果超过 60 秒，则向发件人返回异常。
9. 转到第 2 步。

如果算法以上述方式工作，那么默认行为对 DoS 攻击非常敏感，因为一旦集合尝试失败，侦听器将从侦听器列表中删除以尝试，这是一个非常糟糕的主意，因为只有使通信再次正常工作的方法是重新连接侦听器，在我们的例子中，这意味着用户手动操作，因为我们将 WCF 服务托管在 Windows 服务中（如果集合尝试失败，用户应该重新启动 Windows 服务）。

有趣的是，我们正在将“ConnectionStatusBehaviour”应用于端点以记录任何连接问题，并且我们在日志中看不到任何奇怪的东西，显然，服务保持连接/在线，并且在天蓝色监视器中，侦听器保持连接为出色地。

当集合点尝试不成功时，有一些方法可以配置不同的行为？。

我们当前的WCF配置如下：

实际绑定配置（WebHttpRelayBinding）

• 安全模式 = 传输
• RelayClientAuthenticationType = RelayAccessToken
• IsDynamic = 假
• UseDefaultProxy = false
• OpenTimeout = 10 秒
• 关闭超时 = 10 秒
• 发送超时 = 10 秒
• ReceiveTimeout = TimeSpan.MaxValue

实际服务节流行为

• MaxConcurrentCalls = 160
• MaxConcurrentInstances = 1000
• 最大并发会话数 = 1160

实际 Wcf 服务行为

• InstanceContextMode = PerCall
• 并发模式 = 单

客户端

WCF 中继是使用 HttpClient 从 AspNetCore 2.2 应用程序调用的，因为中继地址是在运行时发现的（在这种情况下我们不能使用 WCF 代理）。

AspNetCore 应用程序托管在 Azure 中。

听众

部署在 Azure 中的虚拟机上 系统连接模式使用值 ConnectivityMode.Https 进行配置

我偶然发现了一个恼人的 azure wcf http 中继问题，我似乎无法解决。

当我将安全 relayClientAuthenticationType 设置为 RelayAccessToken 时出现问题，这使我的端点由于“无效的授权标头：请求缺少 WRAP 授权凭据”错误而无法访问，我似乎无法解决。

如果我将安全设置为“无”，则没有问题。我目前正在使用 Postman 来测试该服务。

以下是应用程序的所有相关详细信息（.net 4.6.2 控制台应用程序），在此先感谢 :)

应用程序配置

打开主机

Azure 中继防火墙设置

允许从所有网络访问

测试继电器：测试方法（接口）

试验结果

如果我将 relayClientAuthenticationType 设置为 None，我会得到预期的 json 响应。

如果我将 relayClientAuthenticationType 设置为 RelayAccessToken，则会收到未经授权的错误。