問題タブ [nagle]

この Socket FAQ articleによると、Nagle のアルゴリズムは、多数のデータを TCP バッファに保持させ、ネットワークにヒットさせないアルゴリズムの 1 つです。Nagle アルゴリズムによる遅延は最大 200 ミリ秒です。

何らかの理由で、Nagle のアルゴリズムを完全にオフにすることはできますが、一度だけフラッシュすることはできません。これは本当に不可解です。なぜ「今回だけ、これ以上のデータを待たずに、ネーグルの 200 ミリ秒が経過したかのように振る舞う」と言う方法がないのはなぜですか。

それは完全に理にかなっており、Nagle をまったく使用しない、常に Nagle を使用する、および独自のプロトコルをゼロから実装することとの間でバランスが取れているのではないでしょうか?

私は常に、Nagleのアルゴリズムが両方向のソケットに影響を与え、その設定TCP_NODELAYがリモートエンドにNagleをオフにするように通知したと常に想定していました。

それは正しいですか、それとも設定TCP_NODELAYはそれを呼び出すエンドの動作にのみ影響しますか？

少なくともWindowsのデフォルトでは、Naglingはオンになっています。オフにすると、パフォーマンスが向上する可能性があります。それをオフにすることの欠点は何ですか？

socket.io の使用中に nagle のアルゴリズム (オンまたはオフ) を構成する方法を知っている人はいますか?
このオプションは socket.io でも提供されますか?
デフォルトの動作は nagle のアルゴリズムを使用するように構成されていると想定しています (間違っている場合は訂正してください)。

理想的には、使用している Web/アプリ サーバーに関係なく、さまざまなアプリケーションで必要に応じて socket.io を使用しながら、nagle のアルゴ (オン/オフ) を構成したいと考えています。

ありがとう！

Web ゲームに socket.io を使い始めました。

nodejs Expressサーバーを使って簡単なテストを書いてみました。このテストでは、サーバーがタイムスタンプをクライアントに書き込み、クライアントがこのタイムスタンプを返します。この後、サーバーは送受信に使用された時間をログに記録します。

結果: ping 500 ミリ秒 +- 10 ミリ秒。そして、ローカルネットワーク内の別のコンピューターで実行しようとしたときも同じ結果でした。

ですから、TCP Nagle アルゴリズムまたは類似のアルゴリズムが原因で、遅延が非常に大きくなっていると思います。nodejsサーバーにデータを待たずに表示されるようにフラッシュするように指示する方法を知っている人はいますか?

サーバーコード:

クライアントコード:

Linux（Ubuntu）で作業しています。これらの概念は両方とも理解していますが、自分でロジックを読みたいと思っています。ソースコードのどこに書かれていますか？FreeBSD の方が理解しやすいという人もいます。本当？

Azureで作業しているときに、WCFでNagleアルゴリズムを無効にすることに関する投稿をいくつか見てきました。これがAzureにのみ適用できるのか、それともより一般的なベストプラクティスにする必要があるのか​​疑問に思っていました。

さまざまなソースで説明されているように、Nagleアルゴリズムは基本的に、小さなTCP要求を単一の大きな要求にバッチ処理します。バッチ処理は接続ごとに行われます。

私が専門的な文脈で見たほとんどのWCF送信は、データの小さなブロックであり、単一のスレッドによって送信され、ほとんどが双方向です。これは、Nagleアルゴリズムにとって実際には理想的な状況ではないことを理解しています。

だから...私の結論は正しいですか、コンテキストに関係なく、WCFまたはSOAPを使用するときは常に無効にするのが最善ですか？

Python2.6 で nagle アルゴリズムを無効にする必要があります。そのようにhttplib.pyでHTTPConnectionにパッチを当てることがわかりました

トリックを行います。

明らかに、可能であればシステム lib にパッチを適用することは避けたいと考えています。それで、問題は次のとおりです。そのようなことを行う正しい方法は何ですか？（私はPythonにかなり慣れていないため、ここで明らかな解決策を簡単に見逃してしまう可能性があります）

私は、3つの組み合わせがTCPで200msの遅延のようなものを引き起こすことを読みました：Nagleのアルゴリズム、遅延確認応答、および「書き込み-書き込み-読み取り」の組み合わせ。ただし、Javaソケットではこの遅延を再現できないため、正しく理解したかどうかはわかりません。

ループバックアドレスを介してソケットを使用する2つのスレッドを備えたJava7を搭載したWindows7でテストを実行しています。ソケットのtcpNoDelayオプション（デフォルトではfalse）に触れたり、OSのTCP設定を試したりしていません。クライアントのコードの主な部分は次のとおりです。サーバーは、クライアントから2バイトを受信するたびに1バイトで応答しています。

遅れは見られません。なぜだめですか？

Boost asio を使用して TCP メッセージを送信しています。これは「リアルタイム」制御システムであるため、NO_DELAY オプションを設定します。Wireshark を使用して、メッセージに PSH フラグが設定されていることがわかります。パフォーマンスに満足しており、期待どおりに機能しています。

興味を引くために、NO_DELAY をオフにして、パフォーマンスの違いを測定することにしました。

既存のコードを交換しました：

為に

PSH フラグが設定されたままです。

set_option コードも削除しようとしましたが、まだ設定されています。

Wireshark では次のように表示されます。

ここで、104 と 105 は私の 2 台の PC の IP アドレスです。私のデータを含むメッセージに ACK があることにも驚きました。

NO_DELAY をオフにするにはどうすればよいですか?