トップ «前の日記(2008年04月29日) 最新 次の日記(2008年06月08日)» 編集

のろのろのろ雑記


2008年05月01日 Nagle アルゴリズム と 遅延ACK(Delayed ACK)

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

 こういう面からのアプローチもなかなか面白いです(?)。