次の方法で共有

ベスト プラクティス (Windows フィルタリング プラットフォーム)

  • [アーティクル]

次の一覧には、Windows フィルタリング プラットフォーム (WFP) API を使用してアプリケーションを開発するためのベスト プラクティスが含まれています。

  • 動的セッションを使用します。

    多くのアプリケーションでは、開始時にフィルター 処理ポリシー オブジェクトを追加し、停止時にこれらのオブジェクトを削除します。 動的セッションを使用すると、アプリケーションがクラッシュした場合でも、これらのオブジェクトが削除されることを保証できます。 さらに、各オブジェクトを削除する個々の呼び出しを行うよりも、停止時にエンジン ハンドルを閉じる方が効率的です。

  • トランザクション タイムアウトを適切に処理するか、セッション txnWaitTimeoutInMSec を無限に設定してタイムアウトを防ぎます。

    明示的なトランザクションを使用しない場合でも、ほとんどの呼び出しは暗黙的なトランザクションで実行されるため、タイムアウトになる可能性があります。

  • 明示的なトランザクションを使用して、関連する追加操作または削除操作を 1 つのトランザクションに結合します。

    これはより効率的であり、エラー パスで部分的な結果を簡単にクリーンできます。

  • MUI 準拠の文字列を使用します。

    ローカライズ可能なすべての文字列は、共通のデータ構造 (FWPM_DISPLAY_DATA0) に格納されます。 この構造体内の文字列には、 SHLoadIndirectString でサポートされている型の間接文字列を指定できます。 FWPM_DISPLAY_DATA0構造体が関数によって返される前に、間接文字列は呼び出し元のロケールを使用して指定された文字列リソースに解決されます。

  • すべてのオブジェクトをプロバイダーに関連付けます。

    システムに複数のプロバイダーがインストールされている場合、これにより、診断ツールで誰が何を追加したかを簡単に判断できます。

  • 独自のサブレイヤーにフィルターを追加します。

    サブレイヤー内の終端フィルターがヒットすると、そのサブレイヤー内のフィルターは評価されなくなります。 したがって、別のプロバイダーと同じサブレイヤーにフィルターを追加すると、お互いのフィルターが呼び出されるのを防ぎ、予期しない結果になる可能性があります。

  • パケット指向のフィルター処理ではなく、アプリケーション層強制 (ALE) を使用します。

    パケット レイヤーでのフィルター処理が遅い。

  • ICMP エラーと RST イベントを生成する前にフィルター処理します。

    これは、生成後にこれらのイベントをフィルター処理する方が効率的です。

  • トランスポート層ではなく、Stream/Datagram Data レイヤーでパケット検査を実行します。

    これは、吹き出しの開発に適用されます。 詳細については、「Windows ドライバー キット (WDK) での コールアウト ドライバーのプログラミングに関する考慮事項 」を参照してください。

  • 複雑なフィルターを使用する場合は、パフォーマンスへの影響を考慮してください。

    Windows 7 および Windows Server 2008 R2 以降では、同じフィールド キーを使用する複数の条件でフィルターを作成できます。 これにより、より少ないフィルターで複雑なポリシーを作成できます。 ただし、このような複雑なフィルターでは、WFP フィルター エンジンの分類のパフォーマンスが低下する可能性があります。 このようなフィルターを使用すると、ソリューションの全体的なパフォーマンスに悪影響を及ぼすかどうかを判断するために、評価を行う必要があります。