データ通信方式には、種々の要因から一度に送ることがデータ量の上限が存在するものと、上限が存在しないものとがあります。こんにち利用されている通信のほどんどでは、一度に送ることができるデータ量の上限が存在し、「パケット」と呼ぶデータの塊に分割してやり取りされています。「パケット」に分割して送りあう方式を「パケット通信方式」と呼びます。
「パケット通信方式」には、基本となる考え方・概念があります。基本となる概念を理解しておくことで、様々な「プロトコル」の働きや成り立ちの理解が進みます。
パケット通信方式、パケット交換方式
通信自体の最初は、「太鼓」や「のろし」かもしれませんね。
「電気通信」の歴史を振り返ると、その最初は「電信」「電話」から始まっています。
回線交換⇒パケット交換
「電話」というものが使われだしたとき、当初は発信者から「交換手」に「通話したい相手」を告げ、「交換手」が告げられた相手の「回線（加入者線）」と発信者の「回線（加入者線）」を直接接続してやる、という「回線交換」でした。概念上は、発信者やその相手という「加入者」からの「回線（加入者線）」が「交換手」が操作する「交換台」に集中してつながっている形になっています。
異なる「交換台」に収容されている「加入者」間での通話のため、「交換台」間を結ぶ「回線」も用意する必要があります。
「回線交換」では、交換手が「回線」同士を接続した後は、「1対1でつながった状態」で通話します。
たとえ無言であっても、「回線」を切断するまで「1対1でつながった状態」を維持・占有します。
交換台を超えた通話を複数同時に可能とするため、「交換台」間の回線は、複数用意することになります。「交換台」間を結ぶ「回線」も、無音状態が続こうが通話終了まで占有しています。
のちに、発信者が相手先の電話番号をダイヤルを使って送り、「交換機」が自動で回線を接続するようになって以降も概念的には同じ仕組みです。
やがて「データ通信」を行うようになると、「回線交換」方式に対して「パケット交換」方式が登場します。「データ通信」は何らかのコンピュータ装置が主体となって行うものなので、コンピュータ装置による自動処理が前提の「パケット交換」方式との相性がよく、「無音」＝「無通信」の間も「交換機」間の「回線」を占有されることなく共用して運用することが可能です。
パケット通信方式の要素
「パケット」＝定型サイズの封筒
「パケット通信方式」とは、例えていえば、「定型サイズの封筒」を使って手紙を送りあうという方式です。封筒を運ぶ人は封筒の中身を解釈することなく、ただ封筒の外側に記載されている事項に従って、封筒を届けます。
アドレス、ポート
封筒の表には「宛先」と「差出人」を識別するための「住所・氏名」＝「アドレス」を記載します。
TCP、UDPでは「ポート番号」と呼ばれるものが、該当します。
カプセル化、階層化、多重カプセル化
定型封筒の中には、総重量、外形寸法、厚みの上限を超えなければ、入れ子状に別の封筒を入れることができます。「カプセル化」です。
プロトコルの階層を下がっていく毎に、新たな封筒の中に入れて渡していくイメージです。
封筒の外側には、その階層での「宛先」と「差出人」を識別する「アドレス」、中身を扱うプロトコルを記載します。例えば、
「UDPパケット」の封筒には「宛先」「発信元」の「UDPポート番号」を記載、
「UDPパケット」を入れる外側の「IPパケット」の封筒には、「宛先」「発信元」のIPアドレスと中身が「UDP」であることを記載、
「IPパケット」を入れる外側の「MACフレーム」の封筒には、「宛先」「発信元」のMACアドレスと中身が「IP」であることを記載します。
「MACフレーム」封筒は「MACフレーム」を扱う配送業者「イーサネット」に渡されて、「宛先MACアドレス」のところに配達されます。
受け取った側の「MAC層」係は、「MACアドレス」封筒から、中身の「IPパケット」封筒を取り出して「IPプロトコル」係に渡します。
「IPプロトコル」係は、「IPパケット」封筒から、中身の「UDPパケット」封筒を取り出して「UDPプロトコル」係に渡します。
「UDPプロトコル」係は、「UDPパケット」封筒から、「UDPポート」番号の係に中身を取り出して渡します。その中身がさらに別の上位プロトコル封筒であれば、さらに該当するプロトコル担当に中身を渡すこともあるでしょう。
分割、オフセット
「カプセル化」に使う定型封筒には、入れられる中身（ペイロード）の量に上限があります。各レイヤのプロトコルは、上位下位のプロトコルとは独立しているので、それぞれのレイヤで扱えるペイロード量の上限も異なっています。そこで、上位プロトコルから渡された「一かたまり」の量を送るのにも、複数の封筒に分割して送る必要が出ることがあります。
例えば、「UDP」のレイヤでは、「UDPヘッダ」内でデータ長を表すLengthフィールドが16ビットです。
このため、最大値65535バイトの「UDPパケット」を扱うことが可能であることになります。この「UDPパケット」を渡された「IP」プロトコルは、さらに下位のレイヤである「イーサネット」の封筒のサイズ（MTU）に合わせてこの「UDPパケット」を分割して、分割したものそれぞれを別々の「IP」の封筒に収めてから「イーサネット」に渡します。
分割して収めた封筒の外側には、受け取った側で順番に組み立てて再構成することができるように、
a) 分割前の「一かたまり」を識別できる情報
b) 続きがあることを示す情報
c) 分割したそれぞれが、「一かたまり」の先頭から数えてどの部分にあたるのかを示す情報（オフセット）
を記載します。
「IP」のレイヤであれば、次のものが該当情報として、IPの封筒の外側（IPヘッダ）に書き込まれます。
a) IPパケットの「ID」
b) 「more fragment」flag
c)「offset」
トンネル、トンネリング
「カプセル化」を利用して、「仮想的な通信路」を作り、通信を行う通信の方式が様々な場面で使われています。この「仮想的な通信路」は、多くの場合「トンネル」「トンネリング」と呼ばれています。「仮想的な通信路」を確立することを「トンネルを張る」と表現します。
「トンネル」の例
IPsec、L2TP、PPTP、IPv4 over IPv6
「カプセル化」を応用・発展させた「トンネル」
一般的な「カプセル化」では、UDPなどのL4層プロトコルのパケットをIPパケットでカプセル化し、さらにMACフレームでカプセル化する、といった階層の順にカプセル化されます。
「カプセル化」の順を、階層の順に縛られることなく拡張した使い方をして、プロトコル的にも離れた2点間に「仮想的な通信路」を作るものを「トンネル」「トンネリング」と呼ぶと理解すればよいでしょう。
「トンネル」の例
IPsec
実際に通信させたい二つのIPネットワーク間のIPパケットをIPsecのパケットに暗号化してカプセル化し、セキュアな通信路「IPsecトンネル」を実現するものです。
PPTP
PPPパケットを（通常は暗号化して）IPパケットに乗せて運ぶトンネリングです。
L2TP
PPPなどのLayer2フレームをトンネリングする通信がL2TPです。PPPを運ぶトンネリングであるPPTPとL2F(CSCO社)を改良する形で登場しました。
L2TPは通常、IPsecの仕組みを利用して暗号化を加える「L2TP/IPsec」として実装されています。L2TPパケットはUDPで運ばれます。
IPv4 over IPv6
IPv4パケットを直接IPv6パケットでカプセル化し、IPv6網で運ぶトンネリングです。
SSL、TLS
2点間のセキュアな通信路を、TCPのさらに上位のセッション層というLayer上で確立するトンネリングです。httpをSSLでトンネルするもの（HTTPS）、SSL‐VPN、ユーザ認証時などに使われる暗号通信に利用されています。
QUIC
SSL、TLSをTCPでのコネクションではなく、UDPで運んでいるのがQUICです。厳密にいえば、「トンネリング」の一種ではありません。
PPPoE
インターネットが一般家庭でも利用可能になる過程で多く利用されてきたのが「PPPoE」です。
ダイヤルアップ接続で利用されたPPPをイーサネットでカプセル化し、ユーザ宅の端末あるいは宅内のルータとプロバイダ側のアクセスサーバとの間でPPPで通信する通信路を確立します。
「トンネル」の「太さ」
トンネリングを利用する上で重要になってくるのが、一つの「トンネル」パケットで送ることができるデータの量です。
トンネルを通して、一度のパケットで送ることができるデータサイズの上限を「トンネル」の「太さ」と表現することがあります。「太さ」を超えるデータを一度に送ってしまった結果、実際に大きさを超えるレイヤで破棄されて通信が欠落する問題は起こり勝ちです。
どんな通信でも、最終的に物理層上でデータを運ぶLayer2フレームのペイロード最大長「MTU」が一度に送ることができる上限になります。イーサネットでは、MTUは1500バイト（ジャンボフレームを除く）。イーサネットで運ばれるIPパケットのペイロードは、MTUからIPヘッダ長分を差し引いたサイズが上限になります。
IPの上で運ばれるUDPパケットのペイロードは、フラグメントにより分割された先頭パケットでは、IPパケットのペイロード最大長から、さらにUDPヘッダ長（8バイト）を差し引いたものが上限になります。
カプセル化を重ねるごとに、カプセル化するプロトコルのヘッダ分を差し引いた残りが、一度に送ることができるデータの上限になりますので、「トンネル」を張る場合、通常の通信からさらに「トンネル」を張る階層までの各層ヘッダ長分などが差し引かれ、一度に送ることができるデータ上限が小さくなっていきます。
トンネルを張る2点間、さらにそのトンネルを通して通信をするEnd to Endでこの「太さ」をどう決めていく仕組みであるか、注意が必要な事項です。Layer2のMTUサイズを超えないようにトンネルの太さを制御することは、実は簡単なことではありません。
MAC層直上にあるIP層は、MAC層ドライバからMAC層のMTUを得ることは大方の場合可能です。
一方トンネリングを利用する場合、トンネルの下層プロトコルのためにどれだけのヘッダ長分を消費するかは必ずしも一定ではなく、また上位層から下層が扱えるデータ量上限を知る手段は必ずしも確立されていません。
例えば、TLSトンネル内で通信するIP層やそれ以上を考えたとき、TLSトンネルを確立する下層にあるTCPのヘッダ長は、TCPのフェーズによって増減しますし、暗号Keyの更新などのタイミングではTLSトンネルそのもののヘッダ部分もデータだけを送っているときより、大きくなります。
TLSトンネルを確立する下層にあるTCPでは、そのTCPコネクションを張るときに、当該TCP通信で送るデータの最大サイズをMSSというパラメータを使ってやり取りします。このMSSのやり取りでは、途中で変化するTCPヘッダやTLSヘッダの変化も含めて、一番外側のレイヤのMTUを超えないように制御する必要があります。
QUICなどUDPを使っている場合、UDPで送るデータ量の最大値をやり取りするというフェーズがありません。送信元がIP層にUDPパケットを乗せる時点でMTUを超えるのであれば、IP層のフラグメントにより分割される可能性があります。さらに経路上のルータでMTUサイズを超えたパケットについては、IPレイヤでフラグメントせざるを得ませんが、例えばIPv6経路上のルータではフラグメントは禁止されており、送信元に分割送信を要求するためのICMP通信もブロックされていることが一般的です。初期値か、あらかじめ設定した値を使い、欠落が判明した場合に小さくしていく、など手探りに近い方法で探索するしかないようです。
コメント