とことこロゴス
パケット交換
データをパケット単位で扱い、複数の通信が伝送路を共有しながら、宛先や接続の識別情報に基づいて中継する交換方式である。送信するデータがある通信へ、その時点の送信機会を割り当てられる。
イマシルちゃんの解説
パケット交換は、データを小さな単位にまとめて送り、複数の通信が同じ伝送路を使えるようにする交換方式なんだ。
例えば、ある人の画像データを送る合間に、別の人のメッセージを送れるよ。
途中のルータなどは、パケットに付いた宛先や通信を識別する情報を見て次の送り先を決めるんだ。
送るものがない通信の分も、そのとき必要な通信に容量を回しやすいのが利点だよ。
ただし送信が集中すると、順番を待つ時間が長くなったり、一部のデータが届かなかったりすることもあるんだ。
必要な速さや確実さに応じて、混雑を抑える仕組みや失敗から回復する仕組みを組み合わせるよ。
この解説はわかりやすかったですか？
より深い解説
データの単位と送り先を扱う情報
パケットは、転送に使う情報と利用者のデータをまとめた単位である。宛先や接続の識別子などを入れる部分をヘッダー、運びたいデータの部分をペイロードという。どの情報を載せるか、どの長さを扱えるかはプロトコルごとに決まる。パケット交換という言葉だけで、全ての網が同じ形式や長さを使うと決まるわけではない。
IPネットワークでは、ルータがパケットの宛先アドレスと経路情報を使って出力先を判断する。RFC 791 は、IPデータグラムがパケット交換網をまたいで転送される基本的な仕組みを示している。パケット交換はそれより広い概念であり、IPだけを指す名称ではない。
アプリケーションの大きなデータを複数の転送単位に分けることと、途中のリンクで扱える大きさに合わせてIPパケットをさらに分割するフラグメンテーションは区別する。パケット交換の通信が全て途中で分割されるわけではなく、送信側があらかじめ適切な長さにすることもできる。
送るデータがある通信に容量を使う
複数の通信の発生時刻がずれることを利用し、必要になった通信へ伝送路の容量を割り当てる考え方を統計多重という。ある利用者が送っていない間は別の利用者のパケットを送れるため、短い送信と長い休止が交互に現れる通信をまとめやすい。RFC 3439 第5.1節 も、パケット交換の容量利用を考える際の基本としてこの性質を扱っている。
例として、各端末が最大1 Mbit/sで送信するが、常時その速度で送り続けるわけではない構成を考える。端末ごとに1 Mbit/sを固定で確保せず、複数台が容量を分け合う設計が可能である。ただし全端末が同時に最大速度で送れば、合計の要求が伝送路の容量を超えることがある。平均だけでなく、送信の集中がどれくらい起きるかを見積もる必要がある。
また、パケットごとに制御情報を付けるため、その分も伝送容量を消費する。短いデータを細かく送りすぎると利用者データの割合が小さくなる。一方で一つを大きくすると送り終えるまでの時間が長くなるので、細分化すれば常に効率が上がるわけではない。
送信が集中すると何が起きるか
中継装置が受信した単位をいったん保持してから次へ送る方式を蓄積交換という。出力先が送信中なら、後から来たパケットを待ち行列に入れて送信機会を待たせる。保持領域があることで短時間の集中を吸収できるが、その容量は有限である。
ネットワークへの要求が処理可能な量に対して過大となり、待ち時間や損失が増える状態を輻輳という。バッファがいっぱいになると新しいパケットなどを廃棄する必要が生じる。また、いっぱいになる前にパケットを捨てたり混雑の印を付けたりして、送信側に送信量を抑えるよう知らせる制御もある。
バッファを増やすだけでは、入力が出力の容量を長時間上回る状況を解消できない。捨てるまでの時間が延びても、たまったパケットの待ち時間が長くなるためである。RFC 7567 は、一時的な送信の集中を吸収する容量を確保しつつ、普段の列を短く保つことの意義を説明している。
この性質は、回線交換で新しい接続を受け付けられないことと異なる。パケット交換では既に通信している利用者にも待ち時間や損失として影響が現れ得る。ただし、資源の予約を伴うサービスでは、新規の通信を開始時に制限することもある。
遅延を要素ごとに分ける
端から端までの遅延には、パケットのビット列を伝送路へ送り出す時間、信号が伝わる時間、装置での処理時間、送信機会を待つ時間が含まれる。伝送速度を上げて直接短くできるのは、主にビット列を送り出す時間である。離れた場所まで信号が伝わる時間まで同じ割合で短くなるわけではない。
長さをL bit、伝送速度をR bit/sとすると、一つのリンクへパケット全体を送り出す伝送時間は L ÷ R 秒である。例えば制御情報を含めて1,000 byteのパケットを2 Mbit/sで送る場合は 1,000 × 8 ÷ 2,000,000 = 0.004 秒、すなわち4 msとなる。byteとbitの換算を忘れないことが重要である。
さらに、同じ速度のリンクを三つ通り、各中継装置はパケットを全て受信してから送り始める条件を考える。ほかの通信がなく、信号の伝搬と処理にかかる時間を無視すれば、最初のパケットの受信完了まで12 msかかる。二つ目を直後に続けて送ると、各リンクで別々のパケットを同時に運べるため、二つ目の受信完了は最初のパケットを送り始めてから16 ms後となる。これは一連の処理を段階ごとに重ねるパイプラインの効果である。
実際の装置には受信の途中から転送を始める方式もある。時間を求める際は、全体を受け取ってから送る条件なのか、各リンクの速度が同じか、伝搬や待ち時間を含めるかを確認する必要がある。
論理的な通信路を先に作るか
パケット交換には、個々のパケットを独立に扱うデータグラム方式と、論理的な通信路を先に用意する仮想回線方式がある。接続の事前設定がないことは全てのパケット交換に共通する性質ではない。
| 比較する点 | 個々のパケットを独立に扱う方式 | 論理的な通信路を用意する方式 |
|---|---|---|
| 転送の前提 | 通信ごとの経路を先に設定する必要がない。 | 接続時または管理設定で転送の対応関係を作る。 |
| 転送判断 | 各パケットの宛先などを調べる。 | 接続を表す識別子と設定済みの対応関係を使う。 |
| 経路と順序 | 経路変更などで順序が入れ替わり得る。 | 接続に対応する経路を使い、順序を保つサービスを実現しやすい。 |
| 代表例 | IPが該当する。 | X.25やフレームリレーが該当する。 |
独立に扱う方式でも、毎回必ず違う経路を通るわけではない。宛先に対する経路が安定していれば、同じ経路を続けて通ることが多い。反対に論理的な通信路を作る方式でも、それだけで物理回線を丸ごと専有したり、必要な帯域を必ず保証したりするとは限らない。経路の状態と容量の予約は別の仕組みである。
X.25上でIPを運ぶ方法を定めたRFC 1356 では、必要時に論理的な接続を開き、その上でデータを運ぶ構成が示されている。異なる層の方式を重ねられるため、ある層が接続型であるという理由だけで、システム全体を回線交換と判断してはいけない。
届くことと順序を誰が保証するか
パケット交換という分類だけでは、宛先へ必ず届くことや、送った順にアプリケーションへ渡ることは保証されない。提供される性質は具体的なプロトコルとサービスによる。例えばIP自身には、届かなかったデータを送り直す機能がない。
TCPはIPの上で動作し、欠けたデータの再送や順序の管理によって、アプリケーションへ順序どおりのバイト列を提供する。RFC 9293 第2.2節 はこの役割を明確にしている。TCPが接続を設定しても、途中のネットワークに一定の帯域を確保することにはならない。
失われたデータを後から補うと、完全な内容を届けやすくなる一方で待つ時間が増える。ファイル転送では待ってでも全体を正しくそろえることが重要であり、会話音声では再生時刻を過ぎたデータの価値が低い場合がある。アプリケーションは必要な完全性と期限に応じて回復方法を選ぶ必要がある。
品質を管理するための条件
パケット交換でも、音声などの通信を優先して送る制御や、送信量をならすシェーピング、利用可能な容量の予約によって通信品質を管理できる。ただし優先度を付けても伝送路の総容量は増えない。優先したい通信だけで容量を使い切れば、それら全てを希望どおりには運べなくなる。
そこで、追加する通信に必要な容量があるかを確認し、条件を満たさない場合は開始を認めない受付制御を組み合わせる方法がある。保証を行うには、経路上の装置が必要な機能を備え、送信側が合意した通信量を守ることも必要である。RFC 2212 は、このような条件の下で帯域や待ち時間の上限を提供するサービスを規定している。
したがって「パケット交換は必ず品質を保証できない」と決め付けるのも適切ではない。一般的なインターネットの転送と、閉じた網で資源を管理するサービスでは前提が違う。方式の名称だけでなく、どの範囲で何を保証しているかを確認する。
実際の通信を調べる視点
応答が遅くなる場合は、リンクの速度だけでなく、送信の集中と待ち時間の変化を確認する。例えばバックアップと通話が同じ出力回線を使う構成では、バックアップの開始時刻だけ音声の遅延や損失が増える可能性がある。一時間平均の使用率が低くても、短い間隔で容量を使い切る時間帯を見落とさないことが重要である。
損失が見つかったら、混雑によるものか、伝送誤りや装置の処理能力不足によるものかを切り分ける。対策も、帯域の増強、送信時刻の分散、優先制御、故障箇所の修復などで異なる。データを小分けにする利点と、複数の通信が資源を分け合うことの影響を合わせて捉えると、必要な対策を選びやすい。