Azureで作業しているときに、WCFでNagleアルゴリズムを無効にすることに関する投稿をいくつか見てきました。これがAzureにのみ適用できるのか、それともより一般的なベストプラクティスにする必要があるのか疑問に思っていました。
さまざまなソースで説明されているように、Nagleアルゴリズムは基本的に、小さなTCP要求を単一の大きな要求にバッチ処理します。バッチ処理は接続ごとに行われます。
私が専門的な文脈で見たほとんどのWCF送信は、データの小さなブロックであり、単一のスレッドによって送信され、ほとんどが双方向です。これは、Nagleアルゴリズムにとって実際には理想的な状況ではないことを理解しています。
だから...私の結論は正しいですか、コンテキストに関係なく、WCFまたはSOAPを使用するときは常に無効にするのが最善ですか？
私が理解しているように、Nagleのアルゴリズムは、データがネットワークスループットを下回る速度で小さなチャンクにストリーミングされる場合にのみ本質的に役立ちます。たとえば、それがビデオフィードまたはハードウェアセンサーからの一定の出力である場合（リアルタイムは重要ではありませんが、履歴は重要です）。極端なケースを想像してみてください。このデータはすべて、Nagleのアルゴリズムを使用せずにバイト単位で送信され、基本的にトラフィックに41を掛けます。
逆に、データが1つの大きなチャンクで書き込まれ（SOAP要求）、次に1つの大きなチャンクで受信される（SOAP応答）場合、それはもちろん有用ではなく、有害でさえあります（遅延のため）。したがって、それをツアーするためのアドバイス。
したがって、リアルタイム処理が重要でない限り（コンソール端末）、ストリーミングアプリケーション（ファイル、ビデオ、一定のデータフィード）ではNagleのアルゴリズムをオンのままにしておく必要があると結論付けることができます。これは基本的に、アプリケーションが無駄なトラフィックでチャネルを詰まらせないための「善行のコード」です（これは、ネットワーク負荷の高い大規模なデータセンターで問題になる可能性があります）。通信が要求応答モードで行われる場合（つまり、すべてのデータが一度にバッファーに書き込まれるため、Nagleのアルゴリズムは効果的ではありません）、デフォルトでオフにすることができます。
小さなサイズの（TCP / HTTPレベルで）多くのメッセージを使用するプロトコルでは、Nagleをオフにする必要があります。いつもこれをやっても大丈夫だとは思いません。
また、WCFは必ずしもSOAPを意味するわけではないことに注意してください。使用するバインディングによって異なります。メッセージサイズは、使用するエンコーディングによっても異なります。WCFは非常に構成可能です。
WCFは、たとえばJSONを使用できます。したがって、WCF + JSON + RESTでサーバーアプリケーションを構築し、平均JSONペイロードが小さい（たとえば、JSONがデフォルトでUTF-8を使用しているため1500バイト未満、つまり最大1500文字）としましょう。価値がある。
ただし、アプリケーションでSOAPバインディングを使用していて、平均メッセージサイズが1500バイト（SOAP XMLペイロードで率直に言って可能と思われる）を超えていると測定した場合、それだけの価値はありません。
したがって、決定を下す前に、実際に物事を測定する必要があります。Azureの人たちが行ったように、おそらく彼らは後でそれを行いました:-)。HTTPメッセージサイズを測定する簡単な方法の1つは、Fiddler2、特に統計タブを使用することです（すべてのメッセージを選択すると、フレームの総数とバイトの総数が表示されます）。