大規模なデータとストリーミング

2025-06-22

Windows Communication Foundation (WCF) は、XML ベースの通信インフラストラクチャです。 XML データは XML 1.0 仕様で定義されている標準テキスト形式でエンコードされるのが一般的であるため、接続システムの開発者やアーキテクトは通常、ネットワーク経由で送信されるメッセージのワイヤフットプリント (またはサイズ) を気にしており、XML のテキストベースのエンコードは、バイナリデータを効率的に転送するための特別な課題をもたらします。

基本的な考慮事項

WCF の次の情報に関する背景情報を提供するために、このセクションでは、一般的に接続されたシステムインフラストラクチャに適用されるエンコード、バイナリデータ、ストリーミングに関する一般的な懸念事項と考慮事項について説明します。

データのエンコード: テキストとバイナリ

一般的に表現される開発者の懸念としては、開始タグと終了タグの繰り返しの性質により、XML がバイナリ形式と比較すると大きなオーバーヘッドが発生する、数値のエンコードがテキスト値で表されるために大幅に大きいと見なされる、バイナリデータをテキスト形式に埋め込むには特別にエンコードする必要があるため効率的に表現できない、という認識が含まれます。

これらの問題と同様の懸念事項の多くは有効ですが、XML Web サービス環境の XML テキストでエンコードされたメッセージと、従来のリモートプロシージャコール (RPC) 環境でのバイナリエンコードメッセージの実際の違いは、多くの場合、最初の考慮事項が示唆するよりもはるかに重要ではありません。

XML テキストでエンコードされたメッセージは透過的で "人間が判読できる" のに対し、バイナリメッセージは比較でかなりわかりにくく、ツールがないとデコードが困難なことがよくあります。この読みやすさの違いは、バイナリメッセージもペイロードにインラインメタデータを含むことが多く、XML テキストメッセージと同様にオーバーヘッドが増加することを見落とします。これは、疎結合および動的呼び出し機能を提供することを目的とするバイナリ形式に特に当てはまります。

ただし、バイナリ形式では、通常、このような記述メタデータ情報が "ヘッダー" に格納され、次のデータレコードのデータレイアウトも宣言されます。その後、ペイロードは、この一般的なメタデータブロック宣言に従い、オーバーヘッドを最小限に抑えます。これに対し、XML は要素または属性で各データ項目を囲み、囲むメタデータがシリアル化されたペイロードオブジェクトごとに繰り返し含まれるようにします。その結果、テキストとバイナリ表現を比較する場合、1 つのシリアル化されたペイロードオブジェクトのサイズは似ていますが、バイナリ形式は、両方に対して記述する必要があるためです。ただし、バイナリ形式は、全体的なオーバーヘッドが低いために転送される各追加ペイロードオブジェクトと共有メタデータの説明の利点があります。

ただし、数値などの特定のデータ型では、固定サイズのバイナリ数値表現 (プレーンテキストの代わりに 128 ビットの 10 進型など) を使用する場合、不都合があります。プレーンテキスト表現は数バイト小さい場合があるためです。テキストデータには、通常より柔軟な XML テキストエンコードの選択肢からサイズの利点がある場合もありますが、一部のバイナリ形式では既定で 16 ビットまたは 32 ビット Unicode に設定される場合があり、これは .NET バイナリ XML 形式には適用されません。

その結果、バイナリメッセージが XML テキストメッセージよりも常に小さいと仮定した場合ほど、テキストとバイナリのどちらを決定するかは容易ではありません。

XML テキストメッセージの明確な利点は、標準ベースであり、相互運用性オプションとプラットフォームサポートの選択肢が最も広い点です。詳細については、このトピックで後述する「エンコード」セクションを参照してください。

バイナリコンテンツ

メッセージサイズの観点からテキストベースのエンコードよりもバイナリエンコードが優れている領域の 1 つは、画像、ビデオ、サウンドクリップなどの大きなバイナリデータ項目、またはサービスとそのコンシューマー間で交換する必要がある不透明なバイナリデータです。これらの種類のデータを XML テキストに収めるために、一般的な方法は、Base64 エンコードを使用してエンコードすることです。

Base64 でエンコードされた文字列では、各文字は元の 8 ビットデータの 6 ビットを表します。その結果、Base64 のエンコードオーバーヘッド比は 4:3 になります。通常、規則によって追加される追加の書式設定文字 (復帰/改行) はカウントされません。 XML エンコードとバイナリエンコードの違いの重要性は、通常、シナリオによって異なりますが、通常、500 MB のペイロードを送信する場合、33% を超えるサイズゲインは許容されません。

このエンコードのオーバーヘッドを回避するために、メッセージ転送最適化メカニズム (MTOM) 標準では、メッセージに含まれる大きなデータ要素を外部化し、特別なエンコードを行わずにバイナリデータとしてメッセージと共に伝達できます。 MTOMでは、メッセージは添付ファイルまたは埋め込みコンテンツ(画像およびその他の埋め込みコンテンツ)を含む簡易メール転送プロトコル(SMTP)電子メールメッセージと同様の方法で交換されます。MTOM メッセージは、ルート部分が実際の SOAP メッセージであるマルチパート/関連 MIME シーケンスとしてパッケージ化されます。

MTOM SOAP メッセージは、エンコードされていないバージョンから変更され、それぞれの MIME 部分を参照する特別な要素タグが、バイナリデータを含むメッセージ内の元の要素の代わりに使用されます。その結果、SOAP メッセージは、一緒に送信された MIME パーツを指すことによってバイナリコンテンツを参照しますが、それ以外の場合は XML テキストデータのみを伝送します。このモデルは確立された SMTP モデルと密接に連携しているため、多くのプラットフォームで MTOM メッセージをエンコードおよびデコードするための広範なツールサポートが用意されているため、非常に相互運用可能な選択肢となります。

それでも、Base64 と同様に、MTOM には MIME 形式に必要なオーバーヘッドも伴います。そのため、MTOM を使用する利点は、バイナリデータ要素のサイズが約 1 KB を超える場合にのみ表示されます。オーバーヘッドのため、バイナリペイロードがそのしきい値を下回っている場合、MTOM でエンコードされたメッセージは、バイナリデータに Base64 エンコードを使用するメッセージよりも大きくなる可能性があります。詳細については、このトピックで後述する「エンコード」セクションを参照してください。

大きなデータコンテンツ

ワイヤーフットプリントはさておき、前述の 500 MB のペイロードも、サービスとクライアントにとって大きなローカルの課題となります。既定では、WCF は バッファーモードでメッセージを処理します。つまり、メッセージの内容全体は、送信前または受信後にメモリ内に存在します。これはほとんどのシナリオに適した戦略であり、デジタル署名や信頼性の高い配信などのメッセージング機能に必要ですが、大きなメッセージはシステムのリソースを使い果たす可能性があります。

大きなペイロードに対処するための戦略はストリーミングです。特に XML で表現されるメッセージは、比較的コンパクトなデータパッケージと考えられますが、メッセージのサイズは数ギガバイトで、データパッケージよりも連続するデータストリームに似ている可能性があります。データがバッファーモードではなくストリーミングモードで転送されると、送信者はメッセージ本文の内容をストリームの形式で受信者に提供し、メッセージインフラストラクチャは、使用可能になると、送信者から受信者にデータを継続的に転送します。

このような大規模なデータコンテンツ転送が発生する最も一般的なシナリオは、次のようなバイナリデータオブジェクトの転送です。

メッセージシーケンスに簡単に分割することはできません。
タイムリーに配信する必要があります。
転送が開始されると、完全には使用できません。

これらの制約がないデータの場合は、通常、1 つの大きなメッセージよりもセッションのスコープ内でメッセージのシーケンスを送信することをお勧めします。詳細については、このトピックで後述する「ストリーミングデータ」セクションを参照してください。

大量のデータを送信する場合は、 maxAllowedContentLength IIS 設定 (詳細については、「 IIS 要求制限の構成」を参照) と maxReceivedMessageSize バインディング設定 ( System.ServiceModel.BasicHttpBinding.MaxReceivedMessageSize や MaxReceivedMessageSize など) を設定する必要があります。 maxAllowedContentLength プロパティの既定値は 28.6 MB、maxReceivedMessageSize プロパティの既定値は 64 KB です。

エンコーディング

エンコードは、ネットワーク上でメッセージを表示する方法に関する一連のルールを定義します。 エンコーダーはこのようなエンコードを実装し、送信側では、インメモリ Messageを、ネットワーク経由で送信できるバイトストリームまたはバイトバッファーに変換します。受信側では、エンコーダーはバイトシーケンスをメモリ内メッセージに変換します。

WCF には 3 つのエンコーダーが含まれており、必要に応じて独自のエンコーダーを記述してプラグインできます。

各標準バインドには事前構成済みのエンコーダーが含まれています。これにより、Net* プレフィックスを持つバインドではバイナリエンコーダー ( BinaryMessageEncodingBindingElement クラスを含む) が使用され、 BasicHttpBinding クラスと WSHttpBinding クラスではテキストメッセージエンコーダー ( TextMessageEncodingBindingElement クラスを使用) が既定で使用されます。

エンコーダーバインド要素	説明
TextMessageEncodingBindingElement	テキストメッセージエンコーダーは、すべての HTTP ベースのバインドの既定のエンコーダーであり、相互運用性が最も重要なすべてのカスタムバインドに適しています。このエンコーダーは、バイナリデータに対する特別な処理なしで、標準の SOAP 1.1/SOAP 1.2 テキストメッセージを読み書きします。メッセージの System.ServiceModel.Channels.MessageVersion プロパティが MessageVersion.None に設定されている場合、SOAP エンベロープラッパーは出力から省略され、メッセージ本文の内容のみがシリアル化されます。
MtomMessageEncodingBindingElement	MTOM メッセージエンコーダーは、バイナリデータの特別な処理を実装するテキストエンコーダーであり、厳密にはケースバイケースの最適化ユーティリティであるため、標準バインディングでは既定では使用されません。 MTOM エンコードによってメリットが得られるしきい値を超えるバイナリデータがメッセージに含まれている場合、データはメッセージエンベロープに続く MIME パーツに外部化されます。このセクションで後述する MTOM の有効化を参照してください。
BinaryMessageEncodingBindingElement	バイナリメッセージエンコーダーは、Net* バインディングの既定のエンコーダーであり、両方の通信相手が WCF に基づいている場合は常に適切な選択です。バイナリメッセージエンコーダーでは、.NET バイナリ XML 形式を使用します。これは、通常、同等の XML 1.0 表現よりもフットプリントが小さく、バイナリデータをバイトストリームとしてエンコードする XML 情報セット (Infoset) 用の Microsoft 固有のバイナリ表現です。

通常、テキストメッセージエンコードは相互運用性を必要とする通信パスに最適な選択肢ですが、バイナリメッセージエンコードは他の通信パスに最適な選択肢です。バイナリメッセージエンコードでは、通常、1 つのメッセージのテキストと比較してメッセージサイズが小さくなり、通信セッションの期間中はメッセージサイズが徐々に小さくなります。テキストエンコードとは異なり、バイナリエンコードでは、Base64 などのバイナリデータに対して特別な処理を使用する必要はありませんが、バイトをバイトとして表します。

ソリューションで相互運用性を必要としないが、引き続き HTTP トランスポートを使用する場合は、トランスポートに HttpTransportBindingElement クラスを使用するカスタムバインドにBinaryMessageEncodingBindingElementを作成できます。サービス上の多数のクライアントで相互運用性が必要な場合は、それぞれのクライアントに対して適切なトランスポートとエンコードの選択肢が有効になっている並列エンドポイントを公開することをお勧めします。

MTOM の有効化

相互運用性が要件であり、大きなバイナリデータを送信する必要がある場合、MTOM メッセージエンコードは、それぞれのMessageEncoding プロパティをMtomに設定するか、MtomMessageEncodingBindingElementをCustomBindingに構成することで、標準のBasicHttpBindingまたはWSHttpBinding バインディングで有効にできる代替のエンコード方法です。 MTOM エンコードサンプルから抽出された次のコード例は、構成で MTOM を有効にする方法を示しています。

<system.serviceModel>  
     …  
    <bindings>  
      <wsHttpBinding>  
        <binding name="ExampleBinding" messageEncoding="Mtom"/>  
      </wsHttpBinding>  
    </bindings>  
     …  
</system.serviceModel>

前述のように、MTOM エンコードを使用するかどうかは、送信するデータボリュームによって異なります。また、MTOM はバインディングレベルで有効になっているため、MTOM を有効にすると、特定のエンドポイントのすべての操作に影響します。

MTOM エンコーダーは、バイナリデータが外部化されるかどうかに関係なく、MTOM でエンコードされた MIME/マルチパートメッセージを常に出力するため、通常は、1 KB を超えるバイナリデータでメッセージを交換するエンドポイントに対してのみ MTOM を有効にする必要があります。また、MTOM 対応エンドポイントで使用するように設計されたサービスコントラクトは、可能な場合は、そのようなデータ転送操作の指定に制限する必要があります。関連する制御機能は、別のコントラクトに存在する必要があります。この "MTOM 専用" ルールは、MTOM 対応エンドポイントを介して送信されたメッセージにのみ適用されます。MTOM エンコーダーは、受信した MTOM 以外のメッセージもデコードおよび解析できます。

MTOM エンコーダーを使用すると、他のすべての WCF 機能に準拠します。セッションのサポートが必要な場合など、すべてのケースでこの規則を確認できない場合があることに注意してください。

プログラミングモデル

アプリケーションで使用する 3 つの組み込みエンコーダーに関係なく、バイナリデータの転送に関するプログラミングエクスペリエンスは同じです。違いは、WCF がデータ型に基づいてデータを処理する方法です。

[DataContract]  
class MyData  
{  
    [DataMember]  
    byte[] binaryBuffer;  
    [DataMember]  
    string someStringData;  
}

MTOM を使用する場合、上記のデータコントラクトは次の規則に従ってシリアル化されます。

binaryBufferがnullされず、Base64 エンコードと比較して MTOM の外部化オーバーヘッド (MIME ヘッダーなど) を正当化するのに十分なデータが個別に含まれている場合、データは外部化され、バイナリ MIME 部分としてメッセージと共に送信されます。しきい値を超えない場合、データは Base64 としてエンコードされます。
文字列 (およびバイナリではないその他のすべての型) は、サイズに関係なく、常にメッセージ本文内の文字列として表されます。

前の例に示すように、明示的なデータコントラクトを使用するか、操作でパラメーターリストを使用するか、入れ子になったデータコントラクトを持っているか、コレクション内のデータコントラクトオブジェクトを転送するかに関係なく、MTOM エンコードへの影響は同じです。バイト配列は常に最適化の候補であり、最適化のしきい値が満たされている場合に最適化されます。

注

データコントラクト内で派生型 System.IO.Stream 使用しないでください。ストリームデータは、次の「ストリーミングデータ」セクションで説明されているストリーミングモデルを使用して伝達する必要があります。

データのストリーミング

転送するデータが大量にある場合、WCF のストリーミング転送モードは、メモリ内のメッセージ全体をバッファリングおよび処理する既定の動作に代わる実行可能な代替手段です。

前述のように、データをセグメント化できない場合、メッセージをタイムリーに配信する必要がある場合、または転送が開始されたときにデータがまだ完全に使用できない場合は、大きなメッセージ (テキストまたはバイナリコンテンツを含む) に対してのみストリーミングを有効にします。

制約

ストリーミングが有効になっている場合、多数の WCF 機能を使用することはできません。

メッセージ本文のデジタル署名は、メッセージの内容全体に対してハッシュを計算する必要があるため、実行できません。ストリーミングでは、メッセージヘッダーが構築および送信されるときにコンテンツを完全に使用できないため、デジタル署名を計算できません。
暗号化は、データが正しく再構築されたことを確認するためにデジタル署名に依存します。
リライアブルセッションでは、転送でメッセージが失われた場合に再配信のためにクライアントで送信されたメッセージをバッファーに格納する必要があり、メッセージが順序外で受信された場合にメッセージの順序を保持するためにサービス実装に渡す前に、サービスにメッセージを保持する必要があります。

これらの機能上の制約のため、ストリーミングにはトランスポートレベルのセキュリティオプションのみを使用でき、信頼できるセッションを有効にすることはできません。ストリーミングは、次のシステム定義バインディングでのみ使用できます。

NetTcpBindingとNetNamedPipeBindingの基になるトランスポートには、信頼性の高い配信と接続ベースのセッションサポートが固有であるため、HTTP とは異なり、これら 2 つのバインドは、実際にはこれらの制約の影響を最小限に抑えるだけです。

ストリーミングはメッセージキュー (MSMQ) トランスポートでは使用できないため、 NetMsmqBinding または MsmqIntegrationBinding クラスでは使用できません。メッセージキュートランスポートでは、メッセージサイズが制限されたバッファー内のデータ転送のみがサポートされますが、他のすべてのトランスポートには、ほとんどのシナリオで実際のメッセージサイズの制限はありません。

ピアチャネルトランスポートを使用する場合はストリーミングも使用できないため、 NetPeerTcpBindingでは使用できません。

ストリーミングとセッション

セッションベースのバインディングを使用して呼び出しをストリーミングすると、予期しない動作が発生する可能性があります。すべてのストリーミング呼び出しは、使用されているバインディングがセッションを使用するように構成されている場合でも、セッションをサポートしない単一チャネル (データグラムチャネル) を介して行われます。セッションベースのバインディングを介して複数のクライアントが同じサービスオブジェクトに対してストリーミング呼び出しを行い、サービスオブジェクトのコンカレンシーモードが単一に設定され、インスタンスコンテキストモードが PerSession に設定されている場合、すべての呼び出しはデータグラムチャネルを通過する必要があるため、一度に処理される呼び出しは 1 つだけです。その後、1 つ以上のクライアントがタイムアウトになる可能性があります。この問題を回避するには、サービスオブジェクトのインスタンスコンテキストモードを PerCall に設定するか、コンカレンシーを [複数] に設定します。

注

使用可能な "セッション" は 1 つしかないため、この場合、MaxConcurrentSessions は無効です。

ストリーミングの有効化

ストリーミングは、次の方法で有効にすることができます。

ストリーミングモードで要求を送受信し、バッファーモード (StreamedRequest) で応答を受け入れて返します。
バッファーモードで要求を送信および受け入れ、ストリームモード (StreamedResponse) で応答を受け入れて返します。
両方向のストリーミングモードで要求と応答を送受信します。 (Streamed)。

ストリーミングを無効にするには、転送モードを Buffered に設定します。これは、すべてのバインドの既定の設定です。次のコードは、構成で転送モードを設定する方法を示しています。

<system.serviceModel>  
     …  
    <bindings>  
      <basicHttpBinding>  
        <binding name="ExampleBinding" transferMode="Streamed"/>  
      </basicHttpBinding>  
    </bindings>  
     …  
</system.serviceModel>

コードでバインドをインスタンス化する場合は、バインドのそれぞれの TransferMode プロパティ (またはカスタムバインドを作成している場合はトランスポートバインド要素) を、前述の値のいずれかに設定する必要があります。

機能に影響を与えずに、通信相手の両側で、要求と応答または双方向のストリーミングを有効にすることができます。ただし、転送されるデータサイズが非常に大きいので、通信リンクの両方のエンドポイントでストリーミングを有効にすることが正当であると常に想定する必要があります。エンドポイントの 1 つが WCF と実装されていないクロスプラットフォーム通信の場合、ストリーミングを使用する機能はプラットフォームのストリーミング機能によって異なります。もう 1 つのまれな例外は、クライアントまたはサービスがワーキングセットを最小限に抑える必要があり、小さなバッファーサイズしか割り当てられないメモリ消費型のシナリオです。

非同期ストリーミングの有効化

非同期ストリーミングを有効にするには、 DispatcherSynchronizationBehavior エンドポイントの動作をサービスホストに追加し、その AsynchronousSendEnabled プロパティを true に設定します。また、送信側で真の非同期ストリーミングの機能を追加しました。これにより、複数のクライアントにメッセージをストリーミングするシナリオでサービスのスケーラビリティが向上します。一部のクライアントでは、ネットワークの輻輳が原因で読み取りが遅い場合や、まったく読み取らない場合があります。これらのシナリオでは、クライアントごとにサービス上の個々のスレッドをブロックしません。サービスはこれによってこれまで以上のクライアントを処理できるようになり、スケーラビリティが向上します。

ストリーミング転送のプログラミングモデル

ストリーミングのプログラミングモデルは簡単です。ストリーミングデータを受信するには、単一の Stream 型指定された入力パラメーターを持つ操作コントラクトを指定します。ストリーミングデータを返す場合は、 Stream 参照を返します。

[ServiceContract(Namespace="http://Microsoft.ServiceModel.Samples")]  
public interface IStreamedService  
{  
    [OperationContract]  
    Stream Echo(Stream data);  
    [OperationContract]  
    Stream RequestInfo(string query);  
    [OperationContract(OneWay=true)]  
    void ProvideInfo(Stream data);  
}

前の例で Echo 操作はストリームを受け取って返すため、 Streamedを持つバインディングで使用する必要があります。操作RequestInfoでは、Streamのみを返すので、StreamedResponseが最適です。一方向操作は、 StreamedRequestに最適です。

次の Echo または ProvideInfo の操作に 2 番目のパラメーターを追加すると、サービスモデルはバッファーに格納された戦略に戻り、ストリームの実行時のシリアル化表現を使用します。 1 つの入力ストリームパラメーターを持つ操作のみが、エンドツーエンドの要求ストリーミングと互換性があります。

この規則は、メッセージコントラクトにも同様に適用されます。次のメッセージコントラクトに示すように、メッセージコントラクトにはストリームである本文メンバーを 1 つだけ含めることができます。ストリームと追加情報を通信する場合、この情報はメッセージヘッダーに含まれている必要があります。メッセージ本文は、ストリームコンテンツ専用に予約されています。

[MessageContract]  
public class UploadStreamMessage  
{  
   [MessageHeader]  
   public string appRef;  
   [MessageBodyMember]  
   public Stream data;  
}

ストリーム転送が終了し、ストリームがファイルの末尾 (EOF) に達するとメッセージが閉じられます。メッセージを送信するときに (値を返すか、操作を呼び出す)、 FileStream を渡すことができます。その後、WCF インフラストラクチャは、ストリームが完全に読み取られ、EOF に到達するまで、そのストリームからすべてのデータをプルします。このような事前構築された Stream 派生クラスが存在しないソースのストリームデータを転送するには、そのようなクラスを構築し、そのクラスをストリームソースにオーバーレイし、引数または戻り値として使用します。

メッセージを受信すると、WCF は Base64 でエンコードされたメッセージ本文コンテンツ (または MTOM を使用する場合はそれぞれの MIME 部分) を介してストリームを構築し、コンテンツが読み取られた時点でストリームが EOF に到達します。

トランスポートレベルのストリーミングは、他のメッセージコントラクト型 (パラメーターリスト、データコントラクト引数、および明示的なメッセージコントラクト) でも機能しますが、このような型指定されたメッセージのシリアル化と逆シリアル化にはシリアライザーによるバッファリングが必要であるため、そのようなコントラクトバリアントを使用することはお勧めしません。

大きなデータに関する特別なセキュリティに関する考慮事項

すべてのバインディングを使用すると、受信メッセージのサイズを制限して、サービス拒否攻撃を防ぐことができます。たとえば、 BasicHttpBindingでは、受信メッセージのサイズを制限する System.ServiceModel.BasicHttpBinding.MaxReceivedMessageSize プロパティが公開されるため、メッセージの処理中にアクセスされるメモリの最大量も制限されます。この単位はバイト単位で設定され、既定値は 65,536 バイトです。

大規模なデータストリーミングシナリオに固有のセキュリティ上の脅威は、受信側がストリーミングされることを予期したときにデータをバッファーに格納することで、サービス拒否を引き起こします。たとえば、WCF では常にメッセージの SOAP ヘッダーがバッファーされるため、攻撃者はヘッダー全体で構成される大きな悪意のあるメッセージを構築して、データを強制的にバッファーに格納する可能性があります。ストリーミングが有効になっている場合、受信側はメッセージ全体が一度にメモリ内にバッファリングされることを想定しないため、 MaxReceivedMessageSize は非常に大きな値に設定される可能性があります。 WCF がメッセージを強制的にバッファーに格納すると、メモリオーバーフローが発生します。

そのため、この場合、受信メッセージの最大サイズを制限するだけでは不十分です。 WCF がバッファーするメモリを制限するには、 MaxBufferSize プロパティが必要です。ストリーミングするときは、これを安全な値に設定 (または既定値のままに) することが重要です。たとえば、サービスで最大 4 GB のファイルを受信し、ローカルディスクに格納する必要があるとします。また、一度に 64 KB のデータしかバッファーに格納できないような方法でメモリが制約されるとします。次に、 MaxReceivedMessageSize を 4 GB に設定し、 MaxBufferSize を 64 KB に設定します。また、サービス実装では、受信ストリームからのみ 64 KB のチャンクで読み取り、前のチャンクがディスクに書き込まれ、メモリから破棄される前に次のチャンクを読み取らないようにする必要があります。

また、このクォータは WCF によって行われるバッファリングのみを制限し、独自のサービスまたはクライアント実装で行うバッファリングから保護できないことを理解することも重要です。セキュリティに関するその他の考慮事項の詳細については、「データのセキュリティに関する考慮事項」を参照してください。

注

バッファー転送とストリーミング転送のどちらを使用するかは、エンドポイントごとにローカルに決定します。 HTTP トランスポートの場合、転送モードは、接続全体、またはプロキシサーバーやその他の中継局に伝達されません。転送モードの設定は、サービスインターフェイスの記述に反映されません。 WCF クライアントをサービスに生成した後、ストリーム転送で使用するサービスの構成ファイルを編集してモードを設定する必要があります。 TCP トランスポートと名前付きパイプトランスポートの場合、転送モードはポリシーアサーションとして伝達されます。

こちらも参照ください

方法: ストリーミングを有効にする