ターミナル サーバーのチュートリアル: スタートアップ、接続、アプリケーション

この記事では、ターミナル サーバーの初期化プロセスについて説明し、ユーザーがサーバーに接続してアプリケーションを実行するときに発生する動作について説明します。

適用対象: Windows Server 2012 R2
元の KB 番号: 186572

Windows ターミナル サーバーの初期化

Windows ターミナル サーバーが起動してコア オペレーティング システムを読み込むと、ターミナル サーバー サービス (Termsrv.exe) が開始され、受信接続をリッスンするリッスン スタック (プロトコルとトランスポート ペアごとに 1 つ) が作成されます。 各接続には、ターミナル サーバーへの個々のセッションを表す一意のセッション識別子または "SessionID" が与えられます。 セッション内で作成された各プロセスは、関連付けられた SessionID で "タグ付け" され、その名前空間を他の接続の名前空間と区別します。

コンソール (ターミナル サーバーのキーボード、マウス、ビデオ) セッションは常に最初に読み込まれるものであり、特殊なケースのクライアント接続と割り当てられた SessionID として扱われます。 コンソール セッションは、構成されたWindows NTディスプレイ、マウス、キーボード ドライバーが読み込まれた通常のWindows NT システム セッションとして開始されます。

ターミナル サーバー サービスは、Windows NT セッション マネージャー (Smss.exe) を呼び出して、クライアント接続を待機する (コンソール セッションを作成した後) 2 つの (既定値 = 2) アイドル 状態のクライアント セッションを作成します。 アイドル 状態のセッションを作成するために、セッション マネージャーは、Windows NT ベースのクライアント/サーバー ランタイム サブシステム プロセス (Csrss.exe) を実行し、そのプロセスに新しい SessionID が割り当てられます。 CSRSS プロセスでは、Winlogon (Winlogon.exe) プロセスと、新しく関連付けられた SessionID の下で Win32k.sys (Window Manager およびグラフィックス デバイス インターフェイス - GDI) カーネル モジュールも呼び出されます。 変更されたWindows NTイメージ ローダーは、この Win32k.sys を、イメージ ヘッダーに定義済みのビット セットによって SessionSpace 読み込み可能なイメージとして認識します。 その後、Win32k.sys がまだ読み込まれていない場合は、そのセッションの仮想カーネル アドレス空間からのポインターを使用して、イメージのコード部分を物理メモリに再配置します。 設計上、メモリに既に存在する場合は、以前に読み込まれたイメージのコード (Win32k.sys) に常にアタッチされます。 たとえば、任意のアクティブなアプリケーションまたはセッションから。

このイメージのデータ (または共有されていない) セクションは、新しく作成された SessionSpace ページング可能なカーネル メモリ セクションから新しいセッションに割り当てられます。 コンソール セッションとは異なり、ターミナル サーバー クライアント セッションは、ディスプレイ、キーボード、マウス用の個別のドライバーを読み込むよう構成されています。

新しいディスプレイ ドライバーは、リモート デスクトップ プロトコル (RDP) ディスプレイ デバイス ドライバー Tsharedd.dll です。 マウス ドライバーとキーボード ドライバーは、複数のインスタンス スタック マネージャー (termdd.sys) を介してスタックに通信します。 Termdd.sys は、RDP ドライバーとの間でマウスとキーボードのアクティビティのメッセージを送信 Wdtshare.sys。 これらのドライバーを使用すると、RDP クライアント セッションをリモートで使用して対話型にすることができます。 最後に、ターミナル サーバーは RDP プロトコルの接続リスナー スレッドも呼び出します。もう一度、TCP ポート番号 3389 で RDP クライアント接続をリッスンする複数インスタンス スタック マネージャー (Termdd.sys) によって管理されます。

この時点で、CSRSS プロセスは独自の SessionID 名前空間の下に存在し、そのデータはプロセスごとに必要に応じてインスタンス化されます。 この SessionID 内から作成されたすべてのプロセスは、CSRSS プロセスの SessionSpace 内で自動的に実行されます。 これにより、異なる Session ID を持つプロセスが別のセッションのデータにアクセスできなくなります。

クライアント接続

RDP クライアントは、任意の Windows ベースのターミナル (WinCE に基づく)、TCP/IP-32b を実行している Windows for Workgroups 3.11、または Microsoft Win32 API ベースのプラットフォームにインストールして実行できます。 Windows ベース以外のクライアントは、Citrix メタフレーム アドオンでサポートされています。 Windows for Workgroups RDP クライアントの実行可能ファイルのサイズは約 70 KB で、300 KB のワーキング セットを使用し、表示データには 100 KB を使用します。 Win32 ベースのクライアントのサイズは約 130 KB で、表示データには 300 KB のワーキング セットと 100 KB を使用します。

クライアントは、TCP ポート 3389 を介してターミナル サーバーへの接続を開始します。 ターミナル サーバー RDP リスナー スレッドはセッション要求を検出し、新しいセッション要求を処理する新しい RDP スタック インスタンスを作成します。 リスナー スレッドは、受信セッションを新しい RDP スタック インスタンスに引き渡し、TCP ポート 3389 でさらに接続試行をリッスンし続けます。 各 RDP スタックは、クライアント セッションが接続され、セッション構成の詳細のネゴシエーションを処理するために作成されます。 最初の詳細は、セッションの暗号化レベルを確立することです。 ターミナル サーバーは、最初に、低、中、高の 3 つの暗号化レベルをサポートします。

低暗号化では、クライアントからターミナル サーバーに送信されるパケットのみが暗号化されます。 この "入力のみ" 暗号化は、ユーザーのパスワードなどの機密データの入力を保護するためです。 中程度の暗号化では、低レベルの暗号化と同じクライアントからの送信パケットが暗号化されますが、ターミナル サーバーからクライアントに返されるすべての表示パケットも暗号化されます。 この暗号化方法は、リモート画面に表示されるネットワーク上を移動するため、機密データをセキュリティで保護します。 低暗号化と中暗号化の両方で、40 ビット キーで Microsoft-RC4 アルゴリズム (パフォーマンスが向上した変更された RC4 アルゴリズム) が使用されます。 高い暗号化では、クライアントとの間で双方向のパケットが暗号化されますが、業界標準の RC4 暗号化アルゴリズムを使用します。再び 40 ビット キーを使用します。 Windows NT ターミナル サーバーのエクスポート以外のバージョンでは、128 ビットの高レベル RC4 暗号化が提供されます。

クライアントとサーバーの間でフォント交換が行われ、インストールされている一般的なシステム フォントが決定されます。 クライアントは、インストールされているすべてのシステム フォントをターミナル サーバーに通知して、RDP セッション中のテキストのレンダリングを高速化します。 ターミナル サーバーでクライアントが使用できるフォントが認識されたら、大きなビットマップではなく圧縮フォントと Unicode 文字列をクライアントに渡すことで、ネットワーク帯域幅を節約できます。

既定では、すべてのクライアントは、アイコン、ツール バー、カーソルなどのビットマップをキャッシュするために使用されるビットマップ キャッシュ用に 1.5 MB のメモリを予約しますが、Unicode 文字列を保持するために使用されません。 キャッシュは (レジストリ キーを介して) 調整可能であり、最も最近使用された (LRU) アルゴリズムを使用して上書きされます。 ターミナル サーバーには、一定のビットストリームではなく、フロー制御によるクライアントへの画面更新の渡しを可能にするバッファーも含まれています。 クライアントでのユーザー操作が高い場合、バッファーは 1 秒あたり約 20 回フラッシュされます。 アイドル時間中、またはユーザー操作がない場合、バッファーの速度は 1 秒あたり 10 回だけフラッシュされます。 これらのすべての番号は、レジストリを通じて調整できます。

セッションの詳細がネゴシエートされると、この接続のサーバー RDP スタック インスタンスが既存のアイドル状態の Win32k ユーザー セッションにマップされ、ユーザーにWindows NTログオン画面が表示されます。 自動ログオンが構成されている場合、暗号化されたユーザー名とパスワードがターミナル サーバーに渡され、ログオンが続行されます。 現在、アイドル状態の Win32k セッションが存在しない場合、ターミナル サーバー サービスはセッション マネージャー (SMSS) を呼び出して、新しいセッションの新しいユーザー空間を作成します。 Win32k ユーザー セッションの多くは共有コードを使用しており、1 つのインスタンスが以前に読み込まれた後に読み込みが著しく速くなります。

ユーザーがユーザー名とパスワードを入力すると、パケットは暗号化されてターミナル サーバーに送信されます。 次に、Winlogon プロセスは、必要なアカウント認証を実行して、ユーザーがログオンする権限を持っていることを確認し、ユーザーのドメインとユーザー名をターミナル サーバー サービスに渡します。このサービスでは、ドメイン/ユーザー名 SessionID リストが保持されます。 SessionID が既にこのユーザーに関連付けられている場合 (切断されたセッションが存在する場合など)、現在アクティブなセッション スタックが古いセッションにアタッチされます。 その後、初回ログオンに使用された一時的な Win32 セッションが削除されます。 それ以外の場合、接続は通常どおり続行され、ターミナル サーバー サービスによって新しいドメイン/ユーザー名 SessionID マッピングが作成されます。 何らかの理由でこのユーザーに対して複数のセッションがアクティブになっている場合は、セッションの一覧が表示され、再接続のために選択するセッションがユーザーによって決定されます。

アプリケーションの実行

ユーザーログオン後、ユーザーのデスクトップ (シングル アプリケーション モードの場合はアプリケーション) が表示されます。 ユーザーが実行する 32 ビット アプリケーションを選択すると、マウス コマンドがターミナル サーバーに渡され、選択したアプリケーションが新しい仮想メモリ空間 (2 GB アプリケーション、2 GB カーネル) に起動されます。 ターミナル サーバー上のすべてのプロセスは、可能な限りカーネル モードとユーザー モードでコードを共有します。 プロセス間でのコードの共有を実現するために、Windows NT Virtual Memory (VM) マネージャーは、コピーオンライト ページ保護を使用します。 複数のプロセスが同じメモリコンテンツの読み取りと書き込みを行う場合、VM マネージャーはメモリ領域にコピーオンライト ページ保護を割り当てます。 プロセス (セッション) は、書き込み操作が実行されるまで同じメモリコンテンツを使用します。この時点で、VM マネージャーは物理ページ フレームを別の場所にコピーし、プロセスの仮想アドレスを更新して新しいページの場所を指すように更新し、ページを読み取り/書き込みとしてマークします。 書き込み時のコピーは、ターミナル サーバーで実行されているアプリケーションに便利で効率的です。

Microsoft Word などの Win32 ベースのアプリケーションが 1 つのプロセス (セッション) によって物理メモリに読み込まれると、コピーオンライトとしてマークされます。 新しいプロセス (セッション) もWordを呼び出すと、アプリケーションが既にメモリに読み込まれているため、イメージ ローダーは新しいプロセス (セッション) を既存のコピーにポイントするだけです。 バッファーとユーザー固有のデータが必要な場合 (ファイルへの保存など)、必要なページは新しい物理メモリの場所にコピーされ、個々のプロセス (セッション) の読み取り/書き込みとしてマークされます。 VM マネージャーは、このメモリ領域を他のプロセスから保護します。 ただし、ほとんどのアプリケーションは共有可能なコードであり、実行回数に関係なく、物理メモリ内のコードのインスタンスは 1 つだけです。

ターミナル サーバー環境で 32 ビット アプリケーションを実行することをお勧めします (必要ありません)。 32 ビット アプリケーション (Win32) を使用すると、コードの共有が可能になり、マルチユーザー セッションでより効率的に実行できます。 Windows NTを使用すると、Win16 アプリケーションごとに仮想 MS-DOS ベースのコンピューター (VDM) を作成して、Win16 環境で 16 ビット アプリケーション (Win16) を実行できます。 16 ビット出力はすべて Win32 呼び出しに変換され、必要なアクションが実行されます。 Win16 アプリは独自の VDM 内で実行されているため、複数のセッションのアプリケーション間でコードを共有することはできません。 Win16 呼び出しと Win32 呼び出しの間の変換では、システム リソースも消費されます。 ターミナル サーバー環境で Win16 アプリケーションを実行すると、同等の Win32 ベースのアプリケーションよりも 2 倍のリソースが消費される可能性があります。

セッションの切断とユーザー ログオフ

セッション切断

ユーザーがセッションの切断を決定した場合、他のプロセスに物理メモリが必要な場合、プロセスとすべての仮想メモリ領域は残り、物理ディスクにページングされます。 ターミナル サーバーはドメイン/ユーザー名とそれに関連付けられた SessionID のマッピングを保持するため、同じユーザーが再接続すると、既存のセッションが読み込まれ、再度使用可能になります。 RDP のもう 1 つの利点は、ユーザーがセッションに対して要求した内容に応じて、セッション画面の解像度を変更できることです。 たとえば、ユーザーが以前に 800 x 600 の解像度でターミナル サーバー セッションに接続していて、切断されていたとします。 その後、ユーザーが 640 x 480 の解像度のみをサポートする別のコンピューターに移動し、既存のセッションに再接続すると、新しい解像度をサポートするためにデスクトップが再描画されます。

ユーザー ログオフ

ログオフは通常、簡単に実装できます。 ユーザーがセッションからログオフすると、SessionID に関連付けられているすべてのプロセスが終了し、セッションに割り当てられたメモリが解放されます。 ユーザーが Microsoft Word などの 32 ビット アプリケーションを実行していて、セッションからログオフした場合、アプリケーション自体のコードは、最後のユーザーがアプリケーションから終了するまでメモリに残ります。