2

そのため、Azure で奇妙な問題が発生したため、サポートを利用することができました。SSL を介して HTTPWebRequest (POST - GET は正常に動作) に分離する自由を取りました。クライアントへのこの特定の要求はどのコンピューターでも確実に機能しますが、Azure VM をスピンアップして実行すると、90 ～ 95% の確率で失敗します。それが機能するという事実が、これを非常に困難にしている理由です。

これをさらに奇妙にすることの 1 つは、Azure では、Fiddler によってプロキシされると、この同じ要求が 100% の時間で機能することです。デバッグを支援するために Fiddler をインストールしましたが、問題を再現できませんでした。Fiddler を終了すると、問題が再び発生します。

SSL に関係している可能性が最も高いのですが、SSL がまったく機能したという事実が、私を完全に困惑させました。Azure VM から成功したトレースログと失敗したトレースログをキャプチャできました。

基になる接続が閉じられました: 接続が予期せず閉じられました..

もう 1 つの要因は、クライアントが DataPower と呼ばれる製品を使用していることですが、それがこのスレッドの余分なノイズであるかどうかは不明です。

4

2 に答える 2

2

まあ、私は気が狂ってしまうと思って、似たようなものを追いかけて6時間過ごしました. 私の場合、他の 5 つのサーバーと同様に、シングル サインオンの実装に 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 Cloud 上の Citrix PV イーサネット アダプター) に移動し、[構成] をクリックして [詳細] に移動し、[ IPv4 チェックサム オフロード] を無効にしました。その後、すぐに機能し始めました。

IPv4 チェックサム オフロードが何をするのかわかりませんが、この仮想マシンでは確実に動作しませんでした。これが他の誰かに役立つことを願っています!

于 2013-12-11T16:30:32.033 に答える