要約

  • Nagle の規則は、先行データが未確認でなければ最初の小さな送信を許可し、その後の小さな書き込みを ACK の到着または完全なセグメントの形成まで保留する。
  • これは受信側の遅延 ACK、送信側の Silly Window Syndrome 回避、輻輳制御とは別の仕組みであり、接続ごとに無効化できなければならない。

RFC 896 は 1984 年 1 月、初期の TCP/IP ネットワークで目立った小パケット問題を論じた。アプリケーションが一文字ずつ送ると、1 バイトのデータに TCP と IP のヘッダー 40 バイトが伴うことがあった。異種のネットワークや混雑した長距離リンクでは、このようなパケットの連続がゲートウェイの処理能力と伝送能力を消費し、輻輳や損失を招きやすくした。

当時の 200〜500 ミリ秒程度の収集タイマーは、帯域幅と往復遅延が異なるネットワークを一つの値で扱おうとした。ローカル環境に合う値では長い経路で十分にまとめられず、長い経路に合う値では対話性を損なう。Nagle は判断の基準を経過時間から確認応答の状態へ移した。

RFC 1122 の状態テストは SND.NXT > SND.UNA である。これは、送信済みだがまだ確認されていないデータがあることを示す。この間、送信側は PSH ビットにかかわらずユーザーデータをバッファし、未確認データが ACK されるか、待機データが Eff.snd.MSS の完全なセグメントになるまで送信を控える。完全なセグメントは ACK とは別の解放条件である。接続がアイドルで未確認データがなければ、最初の小さな書き込みは直ちに送れる。

RFC 1122 は TCP が Nagle を実装すべきだとしながら、アプリケーションが個々の接続で無効化できることを必須にした。RFC 9293 もこの境界を引き継ぎ、送信がスロースタートの制約を受けることを明記する。Nagle は小セグメントを形成するかを決めるのであって、輻輳制御を置き換えるものではない。

また、受信側がいつ ACK を送るかも定めない。RFC 9293 は Nagle と送信側 SWS 回避を区別し、遅延 ACK との相互作用が悪くなり得ると注意する。送信側が ACK の進展を待ち、受信側も ACK を遅らせれば、双方がそれぞれ妥当な動作をしていても境界で追加の待ち時間が生じる。

参考文献