Summary

  • RFC 1692のTMuxは、同じホストへ向かうTelnetやRloginの短い通信を一つのIPデータグラムに集め、パケット処理と割り込みの負担を減らす案だった。
  • 外側のプロトコル番号18だけを見るルーターには、内側のTCPポートが見えない。RFCはポートで検査する機器に、TMuxを解いて調べるか遮断するよう求めた。RFC 4450は後にHistoricへ移した。

端末で一文字を打つ。小さなパケットが一つ出る。数多くの端末から同じホストへこの往復が続くと、回線のビット数は少なくても、ホストは到着のたびに処理と割り込みを繰り返す。1994年8月のRFC 1692は、1オクテットを運ぶパケットにも、1500オクテットのパケットとほぼ同じ処理の手間が掛かると論じた。混雑を読む単位をビットからパケットへ変えたのである。

Peter Cameron、David Crocker、Danny Cohen、Jon PostelのTMuxは、同じ送信元と宛先の間にある複数の短いトランスポートセグメントを一つのIPデータグラムに詰めた。各セグメントには長さ、元のプロトコル番号、小さなチェックサムを持つ4オクテットの見出しが付く。外側のIPヘッダーはプロトコル18を示す。受信ホストが束をほどき、TCPやUDPへ一件ずつ渡す。上の層からは普通の通信として見える。

束を作るには少し待つ。最初のセグメントを入れた時点でタイマーが動き、期限までに集まった仲間を一緒に送る。RFCが挙げた妥当な設定は20〜30ミリ秒で、端末の反応を損なうため約0.1秒が上限の目安だった。バッファが満ちれば先に送る。700オクテットを超えるような大きなセグメントは通常のIPデータグラムに任せる。束がいつも一件なら、節約より待ち時間が目立つ。

相手の対応も確かめる必要があった。有効なTMuxパケットを受け取れば対応の手掛かりになる。最初の呼び水には、データを載せないプロトコル18のENQを送る。返事がなければ再試行間隔を広げ、その間も通常のデータグラムは流せる。相手が再起動して能力を失う可能性に備え、記憶した対応状態には期限を置いた。TMuxか通常の形かは通信中にも切り替えられた。

安全性の節が示した負担は明白だ。TCPポートで通信を選別するルーターには、外側のプロトコル18しか見えない。同じTCP接続の大きなセグメントは通常のIP/TCPとして流れ、別の判断を受け得る。RFC 1692は、TMuxを読めないポートフィルターには双方向のTMuxパケットを止めるよう求めた。読めるルーターなら、束を開いて各セグメントを調べ、規則に反するものを除く。

TMuxはProposed Standardとして発行された。2004〜2005年の古い提案に対する見直しでは、今後の実装や維持が論点になり、RFC 4450はTMuxをHistoricへ移す一覧に載せた。RFC Editorも現在その状態を示す。小さなパケットをまとめると、ホストが見る包みの数は減る。その包みを通す側は、内側まで読む仕事を新たに引き受けなければならなかった。

出典