接続とセッションを区別する必要があります。接続により、サーバーを呼び出すことができます。セッションを使用すると、同じクライアントからの後続のリクエスト間で状態を維持できます。たとえば、アプリケーションセッションでは、サーバー側のキャッシュを使用できます。まず第一に、BasicHttpBindingはセッションをサポートしていません。
HTTP 1.1仕様では、各接続を永続的に開く必要があると説明されています。新しいサーバーへの最初のHTTPリクエストを呼び出すと、永続的な接続が確立され、同じサーバーへの後続の呼び出しのために開いたままになります。サーバーを再度呼び出さない場合は、タイムアウト後にサーバーが閉じられます。永続的な接続の開閉は内部で処理され、開発者には完全に透過的です。
永続的な接続は、.NETHttpWebRequestを含むすべてのブラウザとHTTPAPIで使用されるため、すべてのHTTPベースのバインディングで使用されます。HTTPトランスポートチャネルとプロパティKeepAliveEnabledをfalseに設定してカスタムバインディングを作成することにより、要求/応答ごとに新しい接続を作成して閉じるように要求できます。要求/応答ごとに新しいTCP接続が確立されるため、オーバーヘッドが追加されます。TCP接続の確立は時間のかかる操作です。
永続的なHTTP接続は、WCFアプリケーションセッションとは関係ありません。WCFセッションは、デフォルトで単一サービスプロキシインスタンスと単一サービスインスタンスの間で処理されます。同じプロキシインスタンスからの後続のすべての呼び出しは、同じサービスインスタンスによって処理されます(PerSessionインスタンス化)。WCFアプリケーションセッションは、接続、セキュリティ、信頼性など、他のセッションの上に構築されます。BasicHttpBindingは、これらのセッションタイプのいずれもサポートしていないため、WCFアプリケーションセッション(およびPerSessionインスタンス化)を使用できません。BasicHttpBindingで公開されるサービスの各リクエストは、デフォルトで新しいサービスインスタンス(PerCallインスタンス化)によって処理されます。
HTTP仕様により、クライアントは同じサーバーへの2つの同時永続HTTP接続のみを開くことができる必要があります。永続的なHTTP接続は、同じクライアントマシンから同じ期間に同じサーバーを呼び出すすべてのサービスプロキシで共有されます。さらに、呼び出し間で長期間が経過した場合、単一のプロキシインスタンスが多くの異なる接続からサービスを呼び出すことができます。これらが、永続的なHTTP接続を接続セッションとして使用できない理由です。HTTPはコネクション型ではなく、パフォーマンス上の理由から接続の再利用のみを許可します。
WCFでの永続的なHTTP接続の非アクティブタイムアウトは100秒です。Procmonで測定することにより、このタイムアウトを見つけました。このタイムアウトを別の値に設定することについて、未回答の質問があります。
負荷分散を使用している場合、接続に依存することもできません。永続的なHTTP接続は、クライアントとロードバランサーの間で開かれます。ただし、処理サーバーを選択するのは負荷分散アルゴリズムの責任です。BasicHttpBindingの場合、処理サーバーはいかなる種類のセッションも使用しないため、単純なラウンドロビンにすることができます。セッション指向のバインディングの場合、同じサービスインスタンスがそれらを処理できるように、同じセッションから同じサーバーにすべての要求を転送するセッションアフィニティ(スティッキーセッション)を備えたアルゴリズムを使用する必要があります。ただし、BasicHttpBindingの場合はそうではありません。