IIS 6.0（2）

W3SVCの詳細な分析は、IIS 6.0システムの最も目立つコンポーネントである可能性がありますが、これは重要ではないという意味ではありません。 W3SVCのタスクは、構成データの設定に従ってワーカースレッドを作成および監視することであり、Webサイトアプリケーションはワーカースレッドによって実行されます。 IIS 5.0では、IIS 6.0 W3SVCコンポーネントに最も近いものはIIS管理サービスであり、IIS管理サービスはInetinfoの一部であるため、Inetinfoに問題があると、IIS管理サービスにも問題が生じ、IIS管理サービスは使用できなくなります。 Inetinfoまたは他の失敗したアプリケーションを再起動します。 IIS 6.0では、W3SVCはスタンドアロンプ​​ロセスとして実行されます。また、W3SVC内で実行されるサードパーティコードがないため、Webアプリケーションの障害がW3SVCに影響を与えることはほとんどありません。 W3SVCは常に実行されているため、Webアプリケーションの状態を監視し、必要に応じて対処することができます。この方法により、サーバーはユーザー指定のパラメータに基づいてアプリケーションを監視および再起動できます。

■http.sys

IIS 6.0システムの設計における最も重要な変更は、http.sysドライバの追加です、http.sysドライバのタスクはHTTP要求を処理することであり、それはカーネルにあります。モードで操作を実行してください。この変更を過小評価しないでくださいHTTP要求を処理するタスクをIIS 5.0およびIIS 4.0のユーザーモードからIIS 6.0のカーネルモードに変更することで、新世代のIISサーバーが誕生しました。

Win 2KおよびNT 4.0では、IISはユーザーモードで動作します。ユーザーモードで実行されているアプリケーションは、ハードウェアと直接通信するのではなく、データをカーネルモードコンポーネント（NICドライバ、グラフィックサブシステムなど）に渡す標準プロシージャ、またはカーネルモードを呼び出します。ファイルの保存、IPアドレスの設定、ネットワークへのHTMLファイルの送信などのタスクを実行するためのコンポーネントの機能。

ユーザーモードとカーネルモード間の変換は非常に負荷のかかる操作で、サーバーは最初に着信HTTP要求をカーネルモードのTCP /IPスタックからユーザーモードのWinsockに渡します。要求はIISに渡されます。カーネルモードからユーザーモードへの切り替えは非常に迅速に行われますが、必然的にプロセスに直ちに遅延が生じます。負荷が大きい場合、この遅延は累積され、この変換は不可欠であるため、管理者がプロセスを最適化する方法はありません。

IIS 6.0用https.sysカーネルモードドライバは、ユーザーモードとカーネルモード間の切り替え数を大幅に削減します。 Http.sysはHTTP要求を待機し、どのユーザーモードプロセスが要求を処理するか、またはドライバ自体がユーザーによって要求されたコンテンツを返すかどうかを決定します。

IIS 6.0はユーザーモードで動作し、ユーザーの要求を受け取るサーバーエンジンとしてカーネルモードのhttp.sysに完全に依存しています。したがって、http.sysは常に応答できる必要があり、非常に信頼性が高いはずです。ユーザーコードはプロセスエラーを引き起こす可能性があるため、Microsoftはユーザーコードを実行しないようにhttp.sysを設計しました。これにより、アプリケーションが失敗してもIIS 6.0自体には影響しません。

カーネルモードのバッファから静的な応答を返したい場合は、アプリケーションコードの実行を許可しない高速のカーネルモードのHTTPプロセッサが理想的で、ユーザーモードに切り替える必要性が少なくなります。高価なオーバーヘッド、カーネルモードバッファからの応答をすばやく返す機能。 IIS 6.0のhttp.sysは、このようなバッファを管理し、高度に最適化されたヒューリスティックバッファアルゴリズムを使用して、何をバッファに入れるかを決定します（たとえば、http.sysは、複数回発生した要求のみをバッファリングします）。コンテンツ

http.sysは応答バッファから静的コンテンツを直接抽出するので、ユーザーモードに切り替える必要はありません。そのため、IIS 6.0の全体的なパフォーマンスは、IIS 5.0のパフォーマンスと比較して大幅に向上しています。 Microsoftのデータによると、WebBenchベンチマークテストは、IIS 6.0がIIS 5.0よりも150％早く静的コンテンツを返すことを示しています。 IIS 5.0サーバーをIIS 5.0の分離モードで実行している場合でも（IIS 6.0のアーキテクチャがIIS 5.0に似ている場合）、http.sysドライバの応答バッファおよびその他の改善点の恩恵を受けることができます。

さらに、Microsoftはhttp.sysドライバに最適化された多くのアルゴリズムを採用して、要求を適切なワーカープロセスに直接転送できるようにしました。 IIS 4.0およびIIS 5.0では、現在の要求を受信するWebアプリケーションがプロセスのどのインスタンスにあるかを判断するために複数の手順を実行する必要がありますが、IIS 6.0では、http.sysはすべてのIIS 6.0アプリケーションを登録し、各プロセスを許可します。登録済みアプリケーションによって使用される1つ以上のネームスペースを識別するためにIISが内部的に使用するハンドル。したがって、http.sysがHTTP要求を受信すると、カーネルモードのhttp.sysから正しいユーザーモードのWebアプリケーションにその要求をすばやく渡すことができます。

http.sysドライバは次のような他のタスクも行います。

（1）入ってくるURLをさまざまな長さや形式の規則と比較します。

（2）受信リクエストの待ち行列を管理します。

（3）IIS Webサイトのログ情報を記録します（これによりログのパフォーマンスが向上します）。

（4）帯域幅制限ポリシーを実装し、TCP /IPレベル管理をサポートします。

（5）クライアント証明書要求サービスを実装します（ただし、Secure Sockets Layer - SSLはサポートしません）。
http.sysはIISコンポーネントではなくオペレーティングシステムドライバであるため、ドライバの設定はIIS設定データではなくレジストリで行われます。現時点では、正式なドキュメントがまだ作成されていないhttp.sysレジストリ設定が多数ありますこれらの設定は将来変更される可能性があるため、マイクロソフトはユーザーがこれらの設定を変更することを推奨しません。 http.sysドライバのレジストリ設定は、HKEY_LOCAL_MACHINE \\ SYSTEM \\ CurrentControlSet \\ Services \\ HTTPにあります（登録キーはデフォルト設定には含まれていません）。 EnableNonUTF8サブキーを追加し、その値を0に設定します。http.sysは、UTF-8でエンコードされたURLのみを受け入れます。 UTF-8の正式名称は、Universal Character Set（UCS）変換フォーマット8です。これは、文字セットの標準、標準のフルテキストhttp://www.ietf.org/rfc/rfc2279.txtで、多言語の文字セットを使用できます。 。既定では、EnableNonUTF8の値は1です。これは、IISがUTF-8、ANSI、2バイト文字セット（DBCS）でエンコードされたURLを受け入れることを示します。

（2）PercentUAllowed：このサブキーが1（既定値）に設定されている場合、http.sysは部分文字が％uNNNNで表されるURLを認識します。NNNNは実際の文字を表す数値のセットです。 PercentUAllowedが0に設定されている場合、IIS 6.0は部分文字がこのように表されているURLを拒否します。

％uNNNNはあまり一般的ではないUnicode記号であり、一般的なUTF-8表現と混同しないでください。 UTF-8表現では、％20はスペースを表します。例えば、http://www.iisanswers.com/new article.htmは、http://www.iisanswers.com/new%20article.htmと2つの間にあります。 EnableNonUTF8およびPercentUAllowedによって設定された値に関係なく、変換はIEによって自動的に行われ、IIS 6.0が受け入れます。

これら2つの設定は、IIS 6.0のドキュメントに記載されている他の設定項目と共に、IIS 6.0でのURL解決の向上を反映しています。 IIS 5.0では、WebサーバーがURLを解析する方法と密接に関連したセキュリティ上の問題がいくつかありましたが、Microsoftはついに元の問題を解決し、いくつかの改善を行いました。ルールこれらの改善は、本質的に国際的であり、複数の言語が共存しているインターネット上で特に重要です。

Unicodeの詳細についてはhttp://www.unicode.orgを、IIS 5.0の欠陥の詳細についてはhttp://www.wiretrip.net/rfp/p/を参照してください。 Doc.asp /i5 /d57.htm http.sysの設定に役立つツールは、Windows Server 2003リソースキットにあります。

■W3Core

図5に示すように、既定では、IIS 6.0はワーカープロセス分離モードで実行されます。このモードでは、各Webアプリケーションに対して、IIS 6.0はw3wp.exeの個別のインスタンスを使用してWebアプリケーションを実行します。労働者は、アプリケーションのワーカープロセス分離モード（インプロセス）プロセス内に存在し、このようにw3wp.exeの

を呼ぶ効果信頼性とセキュリティを向上させる、問題ではありません。信頼性の向上は、Webアプリケーションの障害が他のWebアプリケーションにも影響せず、http.sysにも影響を与えないため、各WebアプリケーションはW3SVCによって健全性が監視されます。セキュリティの向上は、IIS 5.0およびIIS 4.0のインプロセスアプリケーションのように、アプリケーションがシステムアカウントで実行されなくなったことによるものです。図6に示すように、必要に応じてワーカープロセスを別のユーザーアカウントで実行するように構成することもできます。バッファオーバーフロー攻撃は、Webアプリケーションの成功侵攻がある場合

図VI

、攻撃者はアカウントがワーカープロセスがアクセス権を持って走るだけアクセスリソースは、デフォルトのネットワークサービスアカウントが書き込みをすることはできませんInetpubフォルダには、実行許可が非常に限られているので、CodeRedワームのような攻撃は単に不可能です。

一部のWebアプリケーション、特に一部のInternet Server API（ISAPI）フィルタでは、プロセス外で実行すると問題が発生する可能性があります。 IIS 5.0およびIIS 4.0では、ISAPIフィルタは常にInetinfo内で実行され、その設計目標はプロセス外では実行されないため、一部のフィルタはIIS 6.0ワーカープロセス分離モードになっています。実行時に問題が発生する可能性があります。特に、SF_READ_RAW_DATAまたはSF_SEND_RAW_DATAを呼び出すフィルタは特に顕著です。この目的のために、IIS 6.0はIIS 5.0分離モードと呼ばれる2番目の操作モードも提供します。 ISAPIフィルタがワーカープロセス分離モードで正しく機能しない場合は、IIS 5.0分離モードで問題は発生しません。この2番目の動作モードでは、アプリケーションは、http.sysドライバのパフォーマンスと信頼性の向上など、IIS 6.0の多くの機能強化から恩恵を受けています。

IIS 6.0のドキュメントには、 "アプリケーションプール"という新しい機能があります。アプリケーションプールには1つまたは一連のワーカープロセスが含まれており、アプリケーションプールには名前が付けられています。 IIS 5.0では、アプリケーション保護を低レベル（IISプロセス）、中間レベル（バッファプール）、詳細レベル（分離）に設定することができます。 1つのプール（dllhost.exeのインスタンス）で2つのアプリケーションを実行し、別のプール（dllhost.exeのインスタンス）で他の2つのアプリケーションを実行します。 IIS 5.0では、dllhost.exeのインスタンスに名前を付ける方法が提供されていないため、2つの特定のアプリケーションをプールに入れることはできません。 IIS 7のアプリケーションプールでは、図7に示すように名前を指定できます。[プロパティ]ダイアログボックスの[ホームディレクトリ]ページで、Webサイトまたはディレクトリをアプリケーションプールに簡単に配置できます。