WCF：System.Net.SocketException-通常、各ソケットアドレス（プロトコル/ネットワークアドレス/ポート）の使用は1つだけ許可されます
WCFサービスとWebアプリケーションがあります。 Webアプリケーションは、ポーリングという連続的な方法でこのWCFサービスを呼び出します。実稼働環境では、このエラーを受け取ることはほとんどありません。これは、このエラーがスローされるタイミングをユーザーが認識していなかった内部アクティビティであるためです。
http：//localhost/QAService/Service.svc に接続できませんでした。 TCPエラーコード10048：各ソケットアドレス（プロトコル/ネットワークアドレス/ポート）の使用は1回のみ許可されています127.0.0.1:80。---> System.Net.WebException：Unable toリモートサーバーへの接続---> System.Net.Sockets.SocketException：通常、各ソケットアドレス（プロトコル/ネットワークアドレス/ポート）の使用は1回のみ許可されています127.0.0.1:80
Dev/qa環境でこの動作を再現するのに問題があります。クライアント接続がtry..catch..finallyブロックで閉じられていることを確認しました。それでもこの問題の原因を理解していない..これを知っている人はいますか？
注：私はこれを見ました SOの質問 ですが、私の問題に答えているようには見えないので、繰り返されません質問。
TCP/IPスタックをオーバーロードしています。 Windows（および実際にはすべてのソケットスタック）には、通常の操作でソケットがどのように閉じられるかにより、高速で開くことができるソケットの数に制限があります。ソケットが閉じられると、一定時間（240秒IIRC）TIME_WAIT状態になります。ポーリングするたびに、ソケットはデフォルトのダイナミックレンジ（1024のすぐ上の約5000個のダイナミックポート）から消費され、ポーリングが終了するたびに、その特定のソケットはTIME_WAITになります。十分に頻繁にポーリングすると、最終的に利用可能なすべてのポートを消費し、その結果TCPエラー10048が発生します。
通常、WCFは接続などをプールすることでこの問題を回避しようとします。これは通常、インターネットを経由しない内部サービスの場合です。 wsHttpバインディングのいずれかが接続プーリングをサポートするかどうかはわかりませんが、netTcpバインディングはサポートする必要があります。名前付きパイプではこの問題が発生しないと思います。 MSMQバインディングについては言えません。
この問題を回避するために使用できる解決策は2つあります。動的ポート範囲を増やすか、TIME_WAITの期間を短くすることができます。前者はおそらくより安全なルートですが、非常に大量のソケットを使用している場合（シナリオの場合とは思えません）、TIME_WAITを減らすことはより良いオプションです（または両方を同時に）。
動的ポート範囲の変更
- Regeditを開きます。
- キーHKLM\System\CurrentControlSet\Services\Tcpip\Parametersを開きます
- MaxUserPort値を編集（またはDWORDとして作成）します。
- より大きな数値に設定します。 （つまり65534）
TIME_WAIT遅延の変更
- Regeditを開きます。
- キーHKLM\System\CurrentControlSet\Services\Tcpip\Parametersを開きます
- TcpTimedWaitDelayを編集（またはDWORDとして作成）します。
- 小さい数値に設定してください。値は秒単位です。 （つまり、1分間で60）
上記の解決策のいずれかが問題を解決するはずです。ポート範囲を変更した後も持続する場合は、ポーリングの頻度を増やして頻度を減らしてみてください...これにより、待機時間の遅延を回避する余裕が得られます。最後の手段として、待機時間の遅延を変更します。
HttpClientは、IDisposableを実装していますが、共有オブジェクトですが、可能な限りインスタンスの数を減らす必要があります。リクエストごとにインスタンスを作成するのではなく、アプリケーションのライフタイム全体でインスタンスを1つだけ作成するだけで済みます。
私は http://aspnetmonsters.com/2016/08/2016-08-27-httpclientwrong/ でかなり広範囲にそれについて書いた