SignalR与Redis的背板F5的背后 - 状态code：400，ReasonPhrase：“错误的请求” [英] SignalR with Redis Backplane Behind F5 - StatusCode: 400, ReasonPhrase: 'Bad Request'
问题描述
我在服务器2012 R2使用SignalR版本2.1.2与2.1.2 SignalR.Redis，IIS 8.5使用WebSockets启用。
I'm using SignalR version 2.1.2 with SignalR.Redis 2.1.2 on Server 2012 R2, IIS 8.5 with WebSockets enabled.
所有在我的开发环境完美地运行。我甚至可以站起来在不同的服务器副本（例如http计算机1 / MyApp的/ signalr，HTTP机2 / MyApp的/ signalr）的配置为使用相同的背板上的网站，并pubb'd他们既完美UI的获取消息。
All is running perfectly in my development environment. I can even stand up copies on different servers (e.g. http machine1/myapp/signalr, http machine2/myapp/signalr) of the site configured to use the same backplane, and both UI's get messages pubb'd to them perfectly.
然后我感动的myapp我们的下一个环境，这是2机坐在后面的F5负载均衡集群，具有DNS别名设置路由到F5，然后循环赛的myapp。该网站本身可以连接到signalr蛮好的，可以接收它订阅发布的消息，但是当我试图通过别名（例如HTTP myappalias / signalr）发布到该网站，我得到一个400错误请求错误响应。以下是错误的一个例子。
I then moved "myapp" to our next environment, which is a cluster of 2 machines sitting behind an F5 load balancer, with a dns alias setup to route to the F5, and then round robin "myapp". The website itself can connect to signalr just fine, and can receive published messages it subscribes to, BUT when I try to publish to the site via the alias (e.g. http myappalias/signalr), I get a 400, Bad Request error response. Here is an example of the error.
InnerException: Microsoft.AspNet.SignalR.Client.Infrastructure.StartException
_HResult=-2146233088
_message=Error during start request. Stopping the connection.
HResult=-2146233088
IsTransient=false
Message=Error during start request. Stopping the connection.
InnerException: System.AggregateException
_HResult=-2146233088
_message=One or more errors occurred.
HResult=-2146233088
IsTransient=false
Message=One or more errors occurred.
InnerException: Microsoft.AspNet.SignalR.Client.HttpClientException
_HResult=-2146233088
_message=StatusCode: 400, ReasonPhrase: 'Bad Request', Version: 1.1, Content: System.Net.Http.StreamContent, Headers:
{
Pragma: no-cache
Transfer-Encoding: chunked
X-Content-Type-Options: nosniff
Persistent-Auth: true
Cache-Control: no-cache
Date: Thu, 13 Nov 2014 22:30:22 GMT
Server: Microsoft-IIS/8.5
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Content-Type: text/html
Expires: -1
}
下面是一些测试code我使用发布测试消息到每个环境中，它的失败connection.Start（）。等待（）
Here is some test code I'm using to publish test messages to each environment, where it fails on "connection.Start().Wait()"
class Program
{
static void Main(string[] args)
{
var connection = new HubConnection("http://myappalias/signalr");
connection.Credentials = System.Net.CredentialCache.DefaultNetworkCredentials;
var proxy = connection.CreateHubProxy("MyAppHub");
connection.Start().Wait();
ConsoleKeyInfo key = Console.ReadKey();
do
{
proxy.Invoke("NewMessage", new Message() { Payload = "Hello" });
Console.WriteLine("Message fired.");
key = Console.ReadKey();
} while (key.Key != ConsoleKey.Escape);
}
}
现在，如果我不使用myappalias，而是在击中头部服务器，它完美的作品。看来无论是F5的问题，客户端需要对这种情况进行不同的配置，或者我有设立signlar的启动类时做不同的事情。下面是我使用的启动类的一个实例。
Now, if I don't use the "myappalias", and instead hit the server head on, it works perfectly. It appears either the F5 is the problem, the client needs to be configured differently for this scenario or I have to do something different when setting up signlar's startup class. Here is an example of the startup class I'm using.
[assembly: OwinStartup(typeof(MyApp.Startup))]
namespace MyApp
{
public class Startup
{
private static readonly ILog log = LogManager.GetLogger
(System.Reflection.MethodBase.GetCurrentMethod().DeclaringType);
public void Configuration(IAppBuilder app)
{
try
{
log.Debug(LoggingConstants.Begin);
string redisServer = ConfigurationManager.AppSettings["redis:server"];
int redisPort = Convert.ToInt32(ConfigurationManager.AppSettings["redis:port"]);
HubConfiguration configuration = new HubConfiguration();
configuration.EnableDetailedErrors = true;
configuration.EnableJavaScriptProxies = false;
configuration.Resolver = GlobalHost.DependencyResolver.UseRedis(redisServer, redisPort, string.Empty, "MyApp");
app.MapSignalR("/signalr", configuration);
log.Info("SIGNALR - Startup Complete");
}
finally
{
log.Debug(LoggingConstants.End);
}
}
}
}
我下载了客户端源$ C $ c和有线在直接代替的NuGet包，这样我就可以通过一切步骤。我看来它成功地协商，然后尝试与上交所的连接，然后LongPolling运输，但却未能在两个。
I download the client source code, and wired that in directly instead of the nuget package, so I could step through everything. I seems it successfully negotiates, and then attempt to "connect" with SSE's and then LongPolling transports, but fails at both.
问题1.1
任何人都知道的替代来Signalr用于.NET的支持与负载比例在平衡不太我想拉我的头发去的一种方式？
Anyone know of an alternative to Signalr for .NET that supports scaling with load balancing in a less "I want to pull my hair out" kind of way?
推荐答案
的问题得到了解决由F5切换配置文件MyApp的，使用内置到F5作为与父配置文件中的SOURCE_ADDR简介1小时超时。这里是一个什么样的个人资料不说明：
The problem was fixed by switching the profile for "MyApp" in the F5, to using the "source_addr" profile built into the F5 as a parent profile with a timeout of 1 hour. Here is a description of what that profile does:
源地址亲和持续性也称为简单持续性，
源地址亲和持续性支持TCP和UDP协议，
并指示会话请求，仅在基于同一服务器
数据包的源IP地址。
Source address affinity persistence Also known as simple persistence, source address affinity persistence supports TCP and UDP protocols, and directs session requests to the same server based solely on the source IP address of a packet.
修改
这结束了工作了一段时间，但如果我没有部署重新发布中心，出版商超时试图一遍又一遍又一遍连接发布者（的东西，只需通过signalr客户端发布）。 UHG。
This ended up "Working" for a while, but if I deploy a publisher (something that simply publishes through the signalr client) without republishing the Hub, the publisher times out trying to connect over and over and over again. uhg.
这篇关于SignalR与Redis的背板F5的背后 - 状态code：400，ReasonPhrase：“错误的请求”的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
