1

私は現在、Webサーバーへの一連のリクエストを実行するシンプルなアプリを書いていますが、奇妙な...機能に遭遇しましたか？

リクエストのレスポンスストリームは必要ありませんが、ステータスコードのみが必要です。したがって、データの各部分について、独自の「送信」メソッドを呼び出します。

    public static int Send(string uri)
    {
        HttpWebRequest request = null;
        HttpWebResponse response = null;
        try
        {
            request = (HttpWebRequest)WebRequest.Create(uri);
            response = (HttpWebResponse)request.GetResponse();
            if (response.StatusCode == HttpStatusCode.OK) return 0;
        }
        catch (Exception e)
        {
            if (request != null) request.Abort();
        }
        return -1;
    }

正常に動作します？はい、この関数を少なくとも2回呼び出さない限り。そのような関数を（同じuriで）続けて2回呼び出すと、常にタイムアウトになります。

さて、それは奇妙です。request.Abort();ゼロを返すときに追加すると（ここでは、ステータスコードが200の場合）、すべてが常に正常に機能します。

だから私の質問は-なぜですか？それはある種のフレームワーク制限ですか、それとも特定のサーバーに対するある種のアンチDOS保護ですか（残念ながら、サーバーは私にとってブラックボックスです）？または多分私はそれがすべてどのように機能するかについてsmthを理解していませんか？

4

2 に答える 2

2

Web応答を破棄してみてください。一部のリソースがリークする可能性があります

public static int Send(string uri)
    {
        HttpWebRequest request = null;
        try
        {
            request = (HttpWebRequest)WebRequest.Create(uri);
            using (var response = (HttpWebResponse)request.GetResponse())
            {
               if (response.StatusCode == HttpStatusCode.OK) return 0;
            }
        }
        catch (Exception e)
        {
            if (request != null) request.Abort();
        }
        return -1;
    }

ドメインに対して同時に行うことができるデフォルトの接続数（2つだと思いますが、これを構成できます）もあります。このSOの質問を参照してください。閉じられていない応答で、おそらくこの制限に達しています。

于 2012-06-14T21:57:54.823 に答える
-1

まず、これの根本に到達するために、一連の変更を行います。

  • そのtry..catch{}を取り出してください（例外を飲み込んでいる可能性があります）
  • 数値の代わりにブール値を返す

次に、必要な例外情報を取得する必要があります。

また、ステータスコードのみが必要なため、メソッドとして「HEAD」を使用する必要があります。

request.Method = "HEAD";

ここで違いを読んでください。

于 2012-06-14T21:48:23.443 に答える