ページ構成の際、次の情報源を参考にした。また、章立てはシンプルさを重視してTCP/IPモデルに則る。各層の名前はWikipediaに準拠する。
ネットワーク通信のモデルとしてOSI参照モデルとTCP/IPモデルが知られている。実は両者の違いは階層だけではない。OSI参照モデルでは、UCI (user network interface)とNNI (network network interface)の違いがあり、前者はISPがユーザーに提供するインターフェースを、後者はISP内の通信のインターフェースを表す。
プロトコル毎にデータとノードの呼び方が異なるため、次の表にまとめた。
| プロトコル | パケットの呼び方 | ノードの呼び方 |
|---|---|---|
| イーサネット | フレーム | ステーション |
| IP | データグラム | ホスト |
| TCP | セグメント | ホスト |
リンク層のネットワーク機器について、次の表にまとめた。
| MACアドレス | ポート数 | 名前 |
|---|---|---|
| 学習しない | 2 | （狭義の）リピータ |
| 学習しない | 3以上 | ハブ (リピータハブ) |
| 学習する | 2 | （狭義の）ブリッジ |
| 学習する | 3以上 | スイッチ (ブリッジングハブ, スイッチングハブ) |
ブリッジとリピーターの違いについて。リピーターは信号を増幅するだけだが、ブリッジはフレームに含まれるMACアドレスを読んで適切な宛先に転送ができる。そのため、不要なフレーム転送がなくなる。
リンク層のネットワークには、媒体共有型と媒体非共有型がある。いずれの場合も同じネットワークに複数のホストがいるため、通信したいホスト同士で通信するための仕組みが必要である。
一般に、動画を見ながらクラウドにファイルをアップロードできる。つまり、往復の通信が同時に行われている。しかし、もし無線LANケーブルが1本の光ファイバーなら、往路と復路の光の点滅が混ざり合ってしまうはずである。ということは、通信方式には原始的なものから工夫がされたものまで、いくつかの種類がありそうだ。電気通信の種類を次の表にまとめた。
| 方式 | 特徴 | 例 |
|---|---|---|
| 単行通信(simplex) | 一方向への通信 | テレビ, ラジオ |
| 半二重通信(half duplex) | 交互に通信できるが、同時に通信できるのは片方向のみ | トランシーバー |
| 全二重通信(full duplex) | 同時に送受信ができる | ツイストペアケーブルや光ファイバーを用いたLAN通信 |
半二重通信は、交通における片側交互通行[^mlit_kiseinaiyo]に相当する。 [^mlit_kiseinaiyo]: 用語説明
複数のノードが同一の通信媒体を共有して通信を行うネットワーク形態。有線接続であれば、リピータハブを用いたセグメントが媒体共有型となる。また、ノード間で無線周波数が重複している場合も媒体共有型と言える。
媒体共有型のネットワークにおける制御方法。前提として、有線通信で物理的なネットワークで異なる電気信号が同時に流れると、データが衝突して壊れてしまう。衝突を回避するためのやり方として、通信路（キャリア）が使用中かを検知する（センス）する方法（キャリアセンス）が考えられる。このやり方は早いもの勝ちなのでコンテンション(競争)方式、またはCSMA(Carrier Sense Multiple Access)方式という。しかし、複数のノード1から同時にデータが送信された場合の衝突は避けられない。CSMA方式では、衝突が発生した場合、応答が帰ってこないことで間接的に問題を認識する。
CSMA方式に対して、積極的にデータの衝突を検知するよう改良されたCSMA/CD(CSMA with Collision Detection)方式がある。CSMA/CD方式は主に有線LANでの通信で用いられる。
CSMA方式では、他のノードが送信中のときは送信を待つ。したがって、他のノードの送信が終了した直後に衝突が発生しやすい。CSMA/CD方式は、フレーム送信中の衝突を検知する仕組みを備えているが、特にフレームの先頭で衝突が発生した場合を検知したい。フレームの先頭が衝突したことを検知するのにかかる最悪時間は往復の伝送速度だから、フレームサイズを往復の伝送にかかるサイズよりも大きくすることで、自然とフレーム先頭の衝突に備えることができる。[^xtech_2006]また、通信を開始した後も、他のノードが通信していないかの監視を続け、競合を見つけたら直ちに通信を中止する。その後、ランダムな時間待ってから再送を行う。 [^xtech_2006]: イーサネットの基本原理(2)，フレーム間ギャップと最短フレーム長の存在意義
無線LANのアクセス制御方式としてはCSMA/CA (CSMA with Collision Avoidance)がある。無線通信では、送信中は自身の信号が強いため、他の弱い信号を検出できない。したがって、CSMA/CD形式のように、送信中に衝突を検知することが難しい。そのため、CSMA/CA形式では、衝突が起きやすい条件で衝突を予防する。具体的には、送信を開始する前に通信路が使用中かを検知して、実際に使用中だった場合、他にも待っているノードがいる可能性があるため、ランダムな時間待ってから送信を開始する。
媒体共有型かつノードが数珠つなぎになっているようなケースで、ノード間でトークンをリレー形式で回し、自分がトークンを持っている間だけ通信できるようにする方式。
ネットワーク層とデータリンク層の関係は、旅行代理店の比喩が分かりやすい。旅行者が旅行代理店に行き先を伝えると、旅行代理店が現地までの電車や飛行機などを手配してくれる、というものである。旅行代理店の場合は、事前に経路が分かっている。しかし、実際のネットワーク通信では、ノードはどのルーターを通るかを事前に調べているのだろうか？
実際のネットワーク通信では、事前に経由するルーターを全て把握する必要はなく（仮にそうだとしたら、ISPがルーターの交換作業をする度にネットワークの再接続が起きそうじゃないですか？）、パケットを受け取ったノードそれぞれが、隣り合うノードの中で宛先のIPアドレスに最も近いノードにパケットを送ることを繰り返している。といっても、IPv4アドレスは$2^{32} = 4294967296$種類もある。1エントリあたり僅か16バイト[^16byte]で見積もっても64GB必要になってしまうし、そもそも経路情報の交換が頻繁に発生しすぎて通信どころではないのではないか。そこで、ひとかたまりのIPアドレスをネットワークとみなして管理しよう、という発想になる。 [^16byte]: IPアドレス4バイト、ネクストホップ4バイト、その他8バイトで計算。
ISPと契約しないでも利用可能なネットワークをLAN, 契約が必要なものをWANと考えて良さそうだ。
IPv4アドレスは、IP通信を行うノードを識別するためのIDである。NICに割り当てるため、例えばEthernetとWiFiの2つのインターフェースを持つマザーボードのマシンは、2つのIPアドレスを持つ。また、ルーターは2つ以上のNICを持つため、2つ以上のIPアドレスを持つ。データの単位はパケット。
[!NOTE] localhost, 127.0.0.1, 0.0.0.0 の違いは？ IPアドレスはNICごとの値だから、Webサーバーを立ち上げる時は、実はどのIPアドレス/NICを用いるか指定する必要がある。
localhostは127.0.0.1のエイリアスである。127.0.0.1はRFC1122で定義されているループバックアドレスを指すサブネット127.0.0.1/8の1つ。ループバックアドレスとは、自身からしか到達できない仮想的なNIC（ループバックインターフェース）に割り当てられたアドレスを指す。 それに対して、0.0.0.0は全てのNICに紐づいており、ホストアドレスと呼ばれることがある。 Webサーバーを立ち上げる際、特に何も指定しないでよいのは、実はデフォルトで値が設定されているからに過ぎない。例えばNode.jsのnetモジュール[^nodejs_serverlisten]の場合、0.0.0.0をリッスンしている。 Webアプリケーション開発において、特にIPアドレスを指定しなくても、ローカルとデプロイ後の両方で問題なく動くのはこのためである。 [^nodejs_serverlisten]: server.listen()
当初IPアドレスはA,B,C,D,Eの5クラスに分類されており、クラスごとにネットワーク部とホスト部が分けられていた。しかし、クラスAやBのアドレスが効率的に使われないことから、柔軟にネットワーク部とホスト部を分ける必要が出てきた。
サブネットマスクは、経路制御の表において、複数のIPアドレスを自由に束ねることができる。ネットワーク部とホスト部を分けているんだから単にマスクもしくはネットマスクで良いのでは？というのは良い視点で、Aクラスを/24でマスクするなどAやBクラスよりも下位のマスクが可能だからサブネットマスクと呼ばれているそうだ。[^milestone-of-se_subnet]
[^milestone-of-se_subnet]: 【図解】初心者にも分かるサブネットマスクとデフォルトゲートウェイ
ところでIP通信では、データリンク層で直接繋がっているノード間ではMACアドレスで通信を行う。具体的には、arpリクエストを送ってIPアドレスからMACアドレスを取得する。ここで仮に、自分が所属しているサブネットが分からないとしよう。経路制御のテーブルには、隣のノードからもらったエントリに+1ホップした値を記録するから、隣のノードが自分自身をホップ数0として紹介してくれればそれで済みそうである。しかし大規模なネットワークを考えると、サブネット内にデバイスが出たり入ったりする度に、全てのデバイスと経路情報を交換し合うというのは明らかに効率が悪い。そこで、ホストがルーターに接続した際、予めホスト自身が直接接続できるサブネットが渡されるようになっている。これはDHCPの枠組みで行われる。
次に、ホストではなくルーターがネットワークに接続する場合を考える。ネットワークにルーターを追加することは、新たにサブネットを切り出すことを意味する。
従来はサブネットマスクが固定長だったため、割当予定のサブネット内で最大のホスト数を持つサブネットに合わせてサブネットの大きさを決めていた。しかし、サブネット毎にホスト数が大きく違う場合は無駄が生じる。そこでサブネットマスクの大きさを可変にできるようになった（VLSM）。
VLSMを用いたサブネット構築の演習問題を次の通りまとめた。
静的IPアドレスを動的IPアドレスに変換する技術。あえて包含関係で言えば、NAT ⊇ NAPT ⊇ IPマスカレード、となる。
IPv4を延命するための技術としての説明をよく見かけるが、「すでにプライベートIPアドレスで構築したLANをインターネットに接続する際に、グローバルIPアドレスへの付け替えをしないで良い」という利点もあったようだ。[^yamaha_2018]なお前提として、1990年代頃にはプロバイダから複数のIPアドレスをもらえた時代があった。[^nec_1999] [^yamaha_2018]: NATとIPマスカレードって？ [^nec_1999]: Aterm導入マニュアル
主にIPv4で用いられるが、セキュリティ向上のためにIPv6で用いる例もある。
[!NOTE] IPv4は繋がらないのにIPv6は繋がる事象ってなぜ起きるの？ IPv4ではNATが必要だが、IPv6では不要となっている。そのため、NATの設定が誤っている際にIPv6だけが通信可能になる。これは家庭では、ルーターが二重になっている際によく見られる。
[!NOTE] IPアドレスの開示請求とIPv6って関係ある？ 注意: 筆者は法律の専門的知識を持ち合わせていません。
インターネットで誹謗中傷を受けた場合等に、発信者に対して損害賠償請求等を行う前提として、個人を特定する必要があります。 通常はコンテンツプロバイダ（例えば5ch）にIPや電話番号の開示請求 → ISPに開示請求の順番で個人を特定しますが、コンテンツプロバイダから開示されたIPアドレスがIPv6の場合はどうなるのでしょうか？ IPv4では複数のデバイスが同じIPアドレスを利用している可能性があるため、同じISPのIPアドレスから複数人が同時に同じコンテンツプロバイダにアクセスしている可能性があります（そのため、ISPへの請求時にはタイムスタンプを含める） IPv6ではデバイスごとにIPアドレスが異なるため、コンテンツプロバイダに保存されているIPアドレスのみで個人の特定がしやすくなると言えそうです。
IPアドレスからMACアドレスを取得するためのプロトコル。逆にMACアドレスからIPアドレスを取得するためのプロトコルをRARP (Reverse ARP)という。
[!NOTE] RARPは確かに便利そうだけど、具体的にはいつ使うの？ 外部記憶装置を持たないデバイスが、ブート時に自身のIPアドレスを知るために持ちられることが多かったそう。現在ではDHCPに取って代わられている。[^ITMedia_RARP] [^ITMedia_RARP]: RARP
[!NOTE] IPアドレスの代わりにドメイン名を直接使えないの？ 仮に実現するとして、次のような技術が必要になると思われる。
- ARPに相当する技術（ドメイン名からMACアドレスを引き当てる）
- 経路集約に関する技術
特に経路集約について考えたい。IPアドレスでは、IPアドレスの階層性を保つようにISPに配布すること、およびCIDRで階層性を表現することで経路集約を容易にしている。 一方で、ドメイン名はエンドユーザーが自由に選ぶことのできる文字列である。したがって経路集約は容易ではない。結局階層性を保つにはトップダウンの構造が必要であり、IPアドレスのような単純が数字が適している、ということだろう。
IPプロトコルの管理のためのメタ的なプロトコル。トランスポート層のプロトコルだが、インターネット層のような扱いを受ける。pingやtracerouteで利用されている他、IPプロトコルについてのエラーメッセージはICMPで送信される。
IP通信は複数のルーターを経由するため、攻撃者は通信経路上で通信を傍受したり、改ざんすることができる。HTTPSを用いているなら、通信内容はアプリケーション層で暗号化されているから、読むことはできない。
企業の拠点間を繋ぐ専用線は、戦前から存在した。しかし、距離に応じて専用線を敷設する料金がかかる。1990年代の中頃から2000年代にかけてインターネット通信が普及した。距離に無関係な料金体系であることなどから、専用線からインターネットへの移行が進んだ。[^kogures_vpn] [^kogures_vpn]: 専用線とＶＰＮの歴史
離れた場所から、あたかも拠点にいるかのようにLAN内のノードにIPプロトコルでアクセスするためには、ノードを一意に特定すること（つまりローカルIPアドレスの解決）が問題になる。専用線で接続されている場合は、単にLAN毎に異なる範囲のローカルIPアドレス（例えば、10.0.0.0/8と192.168.0.0/16）を利用すればよい。実際、AWSのVPC peeringではIPアドレスの範囲が問題になることがある。
専用線ではなくインターネットで拠点間を接続する場合、異なるLANにおけるローカルIPアドレスの解決といえば、技術的に素直に思いつく方法はNAT/NAPTである。実際、LAN内のノードの数だけグローバルIPアドレスを持っているとか、特定のポートと特定のノードのポート間の転送を固定する（ポートフォワーディング）設定をするとかして、離れた拠点内のノードにアクセスできる。しかし、NATのために十分な数のグローバルIPアドレスを用意するのは難しい。またポートフォワーディングの場合は、ポートごとの設定が必要であり、かつICMPなどIP層で直接動作するプロトコルをサポートできない。加えて、いずれの方法でも拠点外からアクセスしたいノードの数だけ設定が必要となる。
NAT/NAPTを用いたIPヘッダーを読み替えるアプローチに対して、元のIPパケットを別のパケットで丸ごとカプセル化してしまうアプローチがVPNである。カプセル化を用いたトンネリングを担うプロトコルとしてL2TPがある。リモートワーカーがインターネットを用いて拠点ネットワークにアクセスすることを意図しており、PPTPとL2Fが元になっている。IP層のパケットを運ぶことができ、下位レイヤーをIPやUDPなどから選択することができる。[^mshindo_2007] [^mshindo_2007]: T27 : VPN 再考
専用線とインターネットを比較すると、ローカルIPアドレスの読み替え以外にも、認証と暗号化が必要となる。L2TPはトンネリングのみを担うため、実際のVPNではIPSecと合わせてL2TP/IPSecとして用いられる。また、IPSecのトンネリングモードを用いることで、IPアドレスのカプセル化と暗号化・認証を一度に賄うことができる。
[!NOTE] VPN経由の不正アクセスって、そもそもオフィスのIPアドレスはどう調べているの？ アンダーグラウンドマーケットでVPNの脆弱性とIPアドレスのセットが取引されているようだ。[^trendmicro_2023]ポートスキャンでVPN用のプロトコルが待ち受けているIPアドレスをスキャンしたり、フィッシングメールなどで標的のIPアドレスを入手するケースなどがあるようだ。 [^trendmicro_2023]: VPN、サイバー攻撃被害に共通するセキュリティの注意点
トランスポート層のコネクション指向の通信プロトコル。
TCPは信頼性の高い通信のために応答確認を行うため、すでに信頼性が高い通信経路で多くのパケットをやり取りする場合、都度行われる応答を待つ時間がオーバーヘッドになると言える。そこで、一定のサイズまでは応答を待たずに次のパケットを送信している。この方式をスライディングウィンドウ方式といい、応答を待たずに送信できるサイズをウィンドウサイズという。
[!NOTE] 受信ホストが求めているシーケンス番号のセグメントが送信失敗している時、そのシーケンス番号とウインドウサイズの和を超えるシーケンスのセグメントの送信を自重するのはどうして？ 例えば、受信ホストのウィンドウサイズが5000で、受信ホストがシーケンス番号1000を求めており、2000~5000はすでに受け取っている場合、なぜシーケンス番号6000のセグメントを送る仕様にしなかったのだろうか？
ウィンドウサイズが余っているなら、順序を問わずに次々セグメントを送ってしまおう、というのは一見効率が良さそうに見える。
セグメントを順序立てるメリットとして、全てのACK応答を送らなくてもよいことが挙げられる。実際、複数のACK応答を1つにまとめる遅延ACKという実装が存在する。
また推測になるが、TCPの策定当初はネットワークの信頼性が現在よりも低かったのではないか。上位レイヤーのメッセージを分割したセグメントを順不同で送信するということは、セグメントの応答確認をセグメント毎に行う必要がある。極端な話で言えば、あるセグメントの応答確認のパケットをルーターが”苦手”としていた場合、送信ホストはいつまでもそのセグメントを再送することになる。
また、セグメント間が順不同の場合は、応答のないセグメントが往復路のどちらで失敗しているかの手がかりに、他のセグメントの応答を用いることができない。そのため、再送の判断はタイムアウトで行うしかなくなってしまう。
IPv4, IPv6では、ネットワークの経路上の問題でパケットが届かなかった場合に、再送を行うのはスコープの範囲外である。TCPでは、受信側がAWKを返さない場合は自動で再送が行われる。
輻輳について説明する。混雑を意味する、通信工学分野の congestion の訳語であるが、日本古来の単語である。日本国語大辞典によれば、770年に記録された、南インド出身の僧ボーディセーナの碑文にも「於是道俗輻輳」との記載がある。[^minamitennjikubaramonnsoujou] [^minamitennjikubaramonnsoujou]: 南天竺波羅門僧正碑幷序
TCPは様々なネットワーク環境で利用されているため、TCPそのものに固定のタイムアウト時間はない。パケットを送信する毎に往復にかかった時間 = RTT (Round Trip Time) を計測し、そのRTTよりも少し長い時間待っても応答が無ければ再送する。また、RTTにはブレがあるため、常に最新のRTTを用いて平滑化を行っており、これをSRTTと言う。古いSRTT9割に対して新たに観測したRTT1割の割合で重み付き平均を取って更新しており、うなぎのタレを継ぎ足すようなイメージ。
また、再送待ちの時間は指数関数的に増加するようになっている。
帯域幅 ($x\text{Gbits/msec}$) と 遅延 (RTT, $y\text{msec}$) の積を帯域遅延積といい、ネットワークのパイプの容量を表す。RTTではなく片側伝送遅延を用いる定義もある。[^takano_2009] [^takano_2009]: HPCユーザが知っておきたいTCP/IPの話
要するにACKが戻ってくるまでに送信可能なデータの量を表す。区間が複数ある場合、最も細い帯域×全区間の遅延の合計で計算するようだ。帯域遅延積とウインドウサイズの内、小さい方を遅延で割った値がスループットになる。
データの単位はデータグラム。
TCP/UDPでは、パケットを目的のプロセスに届けるためにポート番号が含まれている。しかし、より具体的にプロセス識別子を用いたり、あるいは抽象的にアプリケーションのID（そんなものは存在しないが、敢えて言えばmacOS, iOSにおけるバンドルID）を用いることで、新たにIDを増やすことを避けなかったのはなぜだろうか？TCPはクライアント・サーバーを区別しないプロトコルなので、プロセス識別子のような予め予測できない値を用いると通信を待ち受けるのが困難になる。一方、アプリケーションのIDを用いるとクライアント側がアプリケーションを多重起動するのが困難になる。よって新たに番号を設けて通信を識別したものと考えられる。
TCPとUDPで同じポート番号を利用しても、通信が混線することはない。では、なぜTCPとUDPは同じ仕様のポート番号を使っているのだろうか？UDPのRFCを読んでみたが、理由は分からなかった。[^rfc768] [^rfc768]: RFC768
ルーターは、ヘッダーのIPアドレスを見てパケットを転送するインターフェースを決める機能がある。YAMAHA RTX1210で経路情報を出力した結果が次の通り。
> show ip route
Destination Gateway Interface Kind Additional Info.
default 192.168.1.1 LAN2(DHCP) static
192.168.1.0/24 192.168.1.250 LAN2 implicit
192.168.100.0/24 192.168.100.1 LAN1 implicit
経路情報を動的に更新するためのプロトコルを、次の通り分類する。
| 種類 | ルーティングタイプ | 経路制御方式 | プロトコル |
|---|---|---|---|
| IGPs | ユニキャスト | 距離ベクトル型 | RIP |
| IGPs | ユニキャスト | 距離ベクトル型 | RIP2 |
| IGPs | ユニキャスト | リンク状態型 | OSPF |
| IGPs | マルチキャスト | 距離ベクトル型 | DVMRP |
| IGPs | マルチキャスト | リンク状態型 | MOSPF |
| EGPs | ユニキャスト | パスベクトル型 | BGP |
距離ベクトルはディスタンスベクター、リンク状態はリンクステートともいい、表記揺れがある。
[!NOTE] IGPsとEGPsを分けたとしても、IPヘッダを見てパケットを転送する以上は、EGPsスピーカーではないルーターも巨大な経路制御表を持つことにならない？ たしかにEGPsでやり取りされる経路制御表は巨大である。ISPの数で考えてもほとんどAS番号と同じだけ（約10万）存在する上、ISPの保有するIPアドレスのネットワーク部が飛び地のために経路集約できないことも普通だから、フルBGPテーブルのエントリは100万以上になる。しかし、ISPでEGPsスピーカー（以降エッジルーター）同士をつなぐルーターが必ずしもハブのような役割を果たすわけではないらしい。むしろエッジルーターが転送先のルーターを慎重に選ぶことで、転送先のルーターがパケットをデフォルトゲートウェイとなる別のエッジルーターに転送するだけで済むようになっているようだ。[^nikkei_2007] [^nikkei_2007]: IPパケットはプロバイダ内をどのように転送されるのか
ホストは自分が知っている経路制御表を30秒ごとにブロードキャストする。経路制御表を受け取ったホストは、受け取った経路情報で自分が持っていた経路情報を更新し、それをブロードキャストする。このアルゴリズムはベルマン・フォード法に則っている。
距離ベクトル型プロトコルでは、誤った経路情報を設定してしまった場合、メトリックが無限に増大する恐れがある。例えば、ルーターAが実際には接続していないネットワークXへのホップ数を1としてルーターBに通知した場合、ルーターBはルーターXへのホップ数を2としてAに再び通知する。ルーターAは実際にはネットワークXに接続していないので、ホップ数を3にして再び通知してしまい、無限ループが発生する。これを無限カウント問題という。無限カウント問題を避けるため、RIPでは最大ホップ数を15に設定している。
各ルーターはAS内のネットワーク構造をグラフとして持つ。各ルーターはグラフの情報を受け取ったら、中身を読む前に隣接する全てのルーターに情報をコピーして配信する。これをフラッディング(flooding)という。[^takagi_2010]グラフを更新次第、ルーターは各宛先への最短距離をダイクストラ法で計算し、ネクストホップをルーティングテーブルに登録する。経路情報の操作が難しいため、エリア間での利用には適さない（逆にIGPsとして運用する分には問題ない）。 [^takagi_2010]: ディスタンスベクターとリンクステート
最短経路について、RIPではルーターのホップ数で計算していたが、OSPFではサブネット毎に自由にコストを付与できる。例えば、LANケーブルが古いなどで遅いネットワークではコストを重くする運用が考えられる。
ISOで標準化されている、OSPFの基になった経路制御プロトコル。
AS間の通信経路を定めるために用いるプロトコル。パスベクトル型といい、向きと距離だけでなく、途中で経過するAS番号も全て持っている。これにより、ルーティングループによる無限カウント問題を回避できる。無限カウント問題とは、ルーティング情報が永遠にループし続け、メトリック値が際限なく増加する現象だ。BGPでは、自身のAS番号がすでにパス内に存在する経路を受け取った場合、その経路を破棄することでループを防ぐ。また、AS番号の列を参照することで、管理者はより柔軟なポリシーを設定でき、セキュリティや経済的な要因に基づいてパケット毎に最適な経路を選択しやすくなる。
[!NOTE] 全ASとの通信経路を持っているとしたら、エントリ数が膨大にならない？ なる。AS番号は約10万だが、エントリ数は100万行以上に達する。したがって、経路表は差分更新を行っている。
ホストがIPv4でネットワークに接続するために必要な設定を払い出してもらうためのプロトコル。サブネットマスク・デフォルトゲートウェイ・DNSサーバーの他に、NTPサーバーのアドレスを受け取ることもできる。
ネットワークの混雑を考慮しなくて良い特性のためか、UDPが用いられている。
HTTPにおいてキャッシュといえばCDNを用いたキャッシュを指す。一方で、かつてはトランスペアレントキャッシュという仕組みがあった。ISPがL4の通信を監視し、適宜コンテンツをキャッシュして返す、という仕組みだったと推察される。[^naogya]クライアントとサーバーのいずれかもキャッシュを意識できないため、トランスペアレント (透過的) という名がついているようだ。しかし、HTTPSの普及で通信の内容を監視できなくなり、またユーザーごとに動的に生成されるコンテンツが増えたことから、CDNに役割を譲ったと考えて良さそうだ。[^senki_2014] [^naogya]: 1. Web トランスペアレントキャッシュについての概要 [^senki_2014]: Is “Transparent” Web Caching Dead?
UDP上に築かれているため便宜上アプリケーション層のプロトコルとして説明するが、HTTP/3の基盤でもあるため、従来のTCP/IPモデルでの分類は難しい。
1990年代、eコマースの登場によって安全な取引が急務となった。NetscapeはSSLを、MicrosoftはPCTを開発し、SSLが標準となった。後継プロトコルのTLSにはPCTの知見も取り入れられている。
暗号化のためには鍵が必要になる。そこで、その鍵をどのように共有するかが問題になる。SSL/TLSでは、共有鍵の共有のために公開鍵暗号を用いる。通信開始時、クライアントは使用可能な暗号などのアルゴリズムをサーバーに通知し、サーバーは使用するアルゴリズムと、公開鍵を含む証明書を返信する。証明書は公開鍵ごと認証局の秘密鍵で署名されている。署名とは、簡単に言えば、証明書全体のハッシュを取得し、それを暗号化することをいう。したがってブラウザは署名を復号し、証明書のハッシュと比較して証明書および公開鍵が正しいことを確かめる。そうした後、クライアントはセッション限りの共通鍵を公開鍵で暗号化し、サーバー・クライアント共に共通鍵を持ったことを確認してから、暗号化通信を始める。
[!NOTE] TCP/IPを丸ごと暗号化すれば、アプリケーション層でSSL/TLS対応する必要はないのでは？ 暗号化には、アルゴリズムの調整とセッションの考え方が必要になる。しかし、IP層にはICMPのような短い通信のためのプロトコルや、UDPのようにセッションのないプロトコルもある。そうしたプロトコルに取ってオーバーヘッドになることを避けると、結局はアプリケーション層で暗号化したほうが効率が良いのではないか。ただし、特定のIPアドレス間で複数のプロトコルでのやり取りが行われる場合は、IPSecのようなプロトコルが活躍する。
なお、リンク層ではノードをステーションと呼ぶことが多い。 ↩