2

所以在 Azure 中有一个奇怪的问题，我们可以使用一些帮助。我们冒昧地将其隔离为通过 SSL 的 HTTPWebRequest（POST - GET 工作正常）。对我们客户的这个特定请求在任何计算机上都能可靠地运行，但是，在我们启动 Azure VM 并运行它的那一刻，它有 90-95% 的时间会失败。它起作用的事实使这变得如此困难。

让这更加奇怪的一件事是，同样的请求，在 Azure 中，一旦被 Fiddler 代理，100% 的时间都可以工作。安装了 Fiddler 以帮助调试，但无法重现该问题。退出 Fiddler，问题再次出现。

很可能与 SSL 有关，然而，它完全起作用的事实让我完全困惑。我们已经能够从 Azure VM 捕获成功的跟踪日志和失败的跟踪日志。

基础连接已关闭：连接意外关闭..

另一个因素是客户端使用了一个名为 DataPower 的产品，但不确定这是否只是该线程中的额外噪音。

4

2 回答 2

2

好吧，我只花了六个小时想我会疯狂地追逐类似的东西。就我而言，我使用 DotNetOpenAuth 实现单点登录，就像我的其他五台服务器一样。但是这个新服务器会在 99% 的时间里呕吐：

DotNetOpenAuth.Messaging.ProtocolException: Error occurred while sending a direct message or getting the response. ---> System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a receive. ---> System.IO.IOException: Received an unexpected EOF or 0 bytes from the transport stream.
   at System.Net.FixedSizeReader.ReadPacket(Byte[] buffer, Int32 offset, Int32 count)
   at System.Net.Security._SslStream.StartFrameBody(Int32 readBytes, Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest)
   at System.Net.Security._SslStream.StartFrameHeader(Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest)
   at System.Net.Security._SslStream.StartReading(Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest)
   at System.Net.Security._SslStream.ProcessRead(Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest)
   at System.Net.TlsStream.Read(Byte[] buffer, Int32 offset, Int32 size)
   at System.Net.PooledStream.Read(Byte[] buffer, Int32 offset, Int32 size)
   at System.Net.Connection.SyncRead(HttpWebRequest request, Boolean userRetrievedStream, Boolean probeRead)
   --- End of inner exception stack trace ---
   at System.Net.HttpWebRequest.GetResponse()
   at DotNetOpenAuth.Messaging.StandardWebRequestHandler.GetResponse(HttpWebRequest request, DirectWebRequestOptions options)
   --- End of inner exception stack trace ---
   at DotNetOpenAuth.Messaging.StandardWebRequestHandler.GetResponse(HttpWebRequest request, DirectWebRequestOptions options)
   at DotNetOpenAuth.Messaging.UntrustedWebRequestHandler.GetResponse(HttpWebRequest request, DirectWebRequestOptions options)
   at DotNetOpenAuth.Yadis.Yadis.Request(IDirectWebRequestHandler requestHandler, Uri uri, Boolean requireSsl, String[] acceptTypes)
   at DotNetOpenAuth.Yadis.Yadis.Discover(IDirectWebRequestHandler requestHandler, UriIdentifier uri, Boolean requireSsl)
   at DotNetOpenAuth.OpenId.UriDiscoveryService.Discover(Identifier identifier, IDirectWebRequestHandler requestHandler, Boolean& abortDiscoveryChain)
   at DotNetOpenAuth.OpenId.IdentifierDiscoveryServices.Discover(Identifier identifier)
   at DotNetOpenAuth.OpenId.RelyingParty.AuthenticationRequest.Create(Identifier userSuppliedIdentifier, OpenIdRelyingParty relyingParty, Realm realm, Uri returnToUrl, Boolean createNewAssociationsAsNeeded)

真的要质疑我的理智，

  • 在 Web 浏览器中访问 SSL 端点工作得很好
  • 打开 Fiddler 捕获使其工作，关闭它使其不起作用
  • 它确实在大约 1% 的时间里自己工作
  • 在控制台应用程序中使用一个HttpWebRequest到同一个端点的工作，但切换到 DotNetOpenAuth（这似乎在做或多或少相同的事情）导致它大部分不起作用

在检查了所有可能检查的内容后，我进入了网络适配器属性（在我的例子中，是 Rackspace 云上的 Citrix PV 以太网适配器），单击配置，进入高级，然后禁用 IPv4 Checksum Offload。然后它立即开始工作。

我不知道 IPv4 Checksum Offload 做了什么，但它在这个虚拟机上不能可靠地工作。希望这对其他人有帮助！

于 2013-12-11T16:30:32.033 回答
0

在更改我们的标头以强制在标头中传递凭据之后（通过http://www.west-wind.com/weblog/posts/2010/Feb/18/NET-WebRequestPreAuthenticate-not-quite-what-it-听起来像）这绕过了问题。

问题仍然存在，我们客户端的 IBM Datapower 在使用 NetWorkCredential（例如 req.Credentials = new NetworkCredential）来自 Azure 时正在重置连接。

我们无法解释为什么当我们在本地机器上运行代码并且 DataPower 不会丢弃请求时它会起作用，但是，当它在 Azure 中时它会起作用。

至少我们有一个解决方法，如果我收到有关 DataPower 问题的任何回复，我们会通知您。

于 2013-10-24T13:02:57.547 回答