のろのろのろ雑記

_ Nagle アルゴリズム と 遅延ACK(Delayed ACK)

　P2P地震情報のデータ到達時間を短くしようと調べていたら、 Nagle アルゴリズム と 遅延ACK という仕組みがあるらしい。自己中心的な解釈なので、あんまりアテになりませんが。

Nagle アルゴリズム

• 細切れのデータをまとめてパケットにすることで、転送効率の向上を図るアルゴリズム。
• データパケットを送信した後、次のデータ送信を以下のいずれかが満たされるまでバッファリングする
  • 送信したパケットのACKが返ってくる
  • MSS(MTU - 40)を超えるデータの送信要求が発生する
  • 200ミリ秒が経過する

遅延ACK (Delayed ACK)

• ACKの送信をバッファリングし、他データとの同時送信による転送効率向上や、Nagle アルゴリズムの機能性向上を図る。
• データパケットを受信した後、ACKの送信を以下のいずれかが満たされるまでバッファリングする
  • 次のパケットを受信する
  • 送信するパケットが発生する
    • ACKと送信するパケットをまとめることで効率化
  • 200ミリ秒が経過する

問題になるケース

リアルタイム性が要求される小さなデータを一方向に送信し続ける場合

• Nagle アルゴリズムにより、小さなデータはバッファリングされる
• 遅延ACKにより、送信パケットに対するACKを返してこない
• その結果、データは200ミリ秒に1回まとめて送信される。
  • 改善策として、受信確認を返すようにする。
    • 遅延ACKの送信条件「送信するパケットが発生する」が満たされる。ただし、そのACKを受信するまでの間はやはりバッファリングされる（Nagle アルゴリズム）。
  • 別の改善策として、Nagle アルゴリズムを無効化する。
    • ACKを待たずに送信するため、バッファリングとそれによる送信遅延がほとんどなくなる。

…というわけで。

　P2P地震情報の通信で、これらが問題になっているケースもありそうです。データを連続送信するような機会は少ないので、確率としてはかなり低いと思いますが…　いや、その低い確率でも遅延は問題だ。

　こういう面からのアプローチもなかなか面白いです（？）。