インターネット アーキテクチャ概論 - Japan Network Information Center

インターネット
アーキテクチャ概論
慶應義塾大学
村井 純
[email protected]
99/02/14
99/02/14
11
チュートリアルの目的
u
インターネットアーキテクチャを構成する
基幹技術を理解する
u
インターネットアーキテクチャの持つ特徴
を理解する
99/02/14
99/02/14
22
キーワード
u
u
u
u
u
u
u
u
Best Effort
Scalability
Security
Operation
Autonomy
Distributed
Exponential Growth
End System
99/02/14
99/02/14
33
AGENDA
u
u
u
u
u
u
はじめに
インターネットのコア技術
インターネットの運用技術
通信媒体とインターネットアーキテクチャ
環境適応のための技術
アプリケーションアーキテクチャ
99/02/14
99/02/14
44
はじめに
99/02/14
99/02/14
55
OSIの7階層モデル
u
u
u
u
プロトコル設計のものさし
わかりやすい機能の分離と独立性
エンドシステムの n層同士が通信を行っているつもり
中間システムは1∼3層でリレーするだけ
アプリケーション
アプリケーション
プレゼンテーション
プレゼンテーション
セッション
セッション
トランスポート
トランスポート
ネットワーク
ネットワーク
ネットワーク
データリンク
データリンク
データリンク
物理
物理
物理
99/02/14
99/02/14
66
OSI各層の役割(1)
u
物理層(第1層)
Ø
u
データリンク層(第2層)
Ø
u
物理メディアへの直接接続の提供
宛先のシステムまでのパスのうちの隣接す
るシステムとの間の情報の流れを制御
ネットワーク層(第3層)
Ø
99/02/14
99/02/14
エンドシステム間のコネクションの確立
77
OSI各層の役割(2)
u
トランスポート層(第4層）
Ø
u
セッション層（第5層）
Ø
99/02/14
99/02/14
スループットと信頼性について、上位層に
サービス品質を保証
システム間の対話に使われる枠組みの確
立に対する責任
88
OSI各層の役割(3)
u
プレゼンテーション層（第6層）
Ø
u
転送される情報の表現の共通化
アプリケーション層（第7層）
Ø
99/02/14
99/02/14
ユーザプロセスに通信環境へのアクセスを
提供
99
階層型プロトコル
u
u
送信側：各層がそれぞれの情報を付加し
て下層へ渡す
受信側：各層がそれぞれの情報を取り除
いて上層へ渡す
届けたいデータ
プロトコルのオーバーヘッド
各層用の情報
99/02/14
99/02/14
10
10
OSIモデルと
インターネットアーキテクチャ
アプリケーション
プレゼンテーション
アプリケーション
セッション
トランスポート
99/02/14
99/02/14
TCP
UDP
ネットワーク
IP
データリンク
Network Interface
物理
物理
11
11
通信形態
u
バーチャルサーキット型
Ø
Ø
u
データグラム型
Ø
Ø
99/02/14
99/02/14
仮想的なパイプを通した転送
コネクション型
データを小分けにし、バラバラに転送
コネクションレス型
12
12
VC型 vs DG型
u
バーチャルサーキット
Ø
Ø
Ø
Ø
Ø
Ø
99/02/14
99/02/14
信頼性
順序保証
フロー制御
輻輳制御
再送
重量課金
u
データグラム
Ø
Ø
Ø
Ø
Ø
Ø
信頼性保証せず
順序保証せず
フロー制御なし
輻輳制御なし
再送なし
固定課金
13
13
VC型 vs DG型
u
VC の手順 (例:FAX)
Ø
Ø
Ø
u
u
あて先を指定し、
まず接続
接続を確認してから
データを転送
転送が終わったら
接続を切断
送信順に相手に届く
信頼性があるが、オ
ーバヘッドが大きく処
理能力が必要
99/02/14
99/02/14
u
DGの手順 (例:はがき）
Ø
u
u
あて先を指定してポスト
に投函
投函した順には届かない
信頼性はないが、オーバ
ヘッドが少なく、処理能
力を要求しない
14
14
回線交換方式
B
A
99/02/14
99/02/14
A∼Cへの通信
Bは回線交換を行う
電話の交換機
C
15
15
パケット交換方式
B
A
A∼Cへの通信
データはパケットに分割
Bはパケット交換を行う
99/02/14
99/02/14
C
16
16
インターネットのコア技術
99/02/14
99/02/14
17
17
ネットワークプロトコル
u
ネットワーク層
Ø
u
IP - Internet Protocol
トランスポート層
Ø
TCP - Transport Control Protocol
アプリケーション
TCP
アプリケーション
UDP
TCP
UDP
IP
IP
IP
Network Interface
Network Interface
Network Interface
物理
物理
物理
99/02/14
99/02/14
18
18
IPの機能
u
ホストの識別
Ø
u
経路の決定
Ø
u
バケツリレー方式
データの分割
Ø
99/02/14
99/02/14
IPアドレスの一部から経路を決定
データの中継
Ø
u
32bit の識別子 −IPアドレス
一度に送れないデータを分割、再構成
19
19
IPアドレス
u
u
３２ｂｉｔのアドレス空間(IPv4の場合）
TCP/IPネットワークに接続するためのＩＤ
Ø
Ø
Ø
u
世界中で唯一自分を証明するためのもの
重複してはいけない
自分と相手を認識する
構造化されたアドレス
Ø
Ø
Ø
99/02/14
99/02/14
ネットワークを表すネットワークアドレスとホ
ストを表すホストアドレスから成り立つ
ネットマスクによる柔軟な構造
ネットワーク部から経路を決定
20
20
IPアドレスとネットマスク
３２ｂｉｔ
ＩＰアドレス
１０１１１０１１１０１０１０１１００１１０１０ １１００１１０１０
３２ｂｉｔ
ネットマスク
１１１１１１１１１１１１１１１１１１１１１１１ ０００００００００
２３ｂｉｔ
３２ｂｉｔ
ネット部
１０１１１０１１１０１０１０１１００１１０１０ ０００００００００
２３ｂｉｔ
３２ｂｉｔ
ホスト部
99/02/14
99/02/14
０００００００００００００００００００００００ １１００１１０１０
２３ｂｉｔ
21
21
IPの特徴
u
データグラム型の通信
Ø
Ø
u
信頼性のない通信を提供
仕組みが単純
Best Effort （最善努力型)
Ø
Ø
Ø
99/02/14
99/02/14
中間ノードに一度に処理できない数のパケットが
集まると待ち行列(queue)が発生(混雑の発生)し、
限界を超えると破棄
エラーの訂正は行わないが、エラーの報告は行う
ICMP - Internet Control Message Protocol
22
22
IPの仕事の流れ
ネットワークインターフェースから
ネットワークインターフェースから
データを受け取る
データを受け取る
次に誰に渡せばよいか判断
次に誰に渡せばよいか判断
次に渡すために
次に渡すために
適切なネットワーク
適切なネットワーク
インターフェースに渡す
インターフェースに渡す
99/02/14
99/02/14
NO
NO
あて先は自分あて？
あて先は自分あて？
YES
YES
あて先のポート番号を見て
あて先のポート番号を見て
上位層へ渡す
上位層へ渡す
23
23
IPヘッダ
u
データグラムの配送に必要な情報を含む
Ø
Ø
Ø
u
送信者アドレス
受信者アドレス
データグラムの長さ ｅｔｃ．．．．
一つ一つのデータグラムに付加される
Ø
99/02/14
99/02/14
Virtual Circuitではない
24
24
IPヘッダ (IPv4)
Ver
IHL
TOS
Total Length
Identification
TTL
Flg Fragment Offset
Protocol
Header Checksum
Source IP Address
Destination IP Address
Options
4 octets
99/02/14
99/02/14
25
25
IPヘッダ
u
Ver
Ø
u
バージョンフィール
ド - 現在は ４
IHL
Ø
u
u
ヘッダの長さ
4octet を 1 として
カウント
Ø
u
Type of Service
配送のタイプ
Ø
u
もともとのデータを識別
する
Fragmentation の際に
必要
flg （Ｆｌａｇ）
Ø
99/02/14
99/02/14
ＩＰデータグラム全体の
大きさ （1octetでカウン
ト）
Identification
Ø
TOS
Ø
Ｔｏｔａｌ Ｌｅｎｇｔｈ
Fragmentされたか、
Fragmentしてはならな
26
いか
26
IPヘッダ
u
Fragment Offset
Ø
Ø
u
TTL （Time To Live）
Ø
Ø
Ø
u
元のデータのどこで
Fragmentか
8octets 単位で計られる
このデータグラムの寿命
基本的には1つのホスト
を経由すると1減る
初期値は64
Protocol
Ø
u
Header Checksum
Ø
Ø
u
Source Address
Ø
u
送信元ホストのアドレス
Destination Address
Ø
u
ヘッダ部分の検証
データが壊れていないか
送信先ホストのアドレス
Option
Ø
特別な機能を提供
上位層が何か
99/02/14
99/02/14
27
27
IPとエラー
u
エラー
Ø
Ø
Ø
u
IPとエラー訂正
Ø
Ø
Ø
99/02/14
99/02/14
データグラムの紛失
checksum の不一致
Fragment したデータの一部欠落
IPはエラーの訂正は行わない
送信者にエラーの報告を行う
エラー報告するのがICMP
28
28
ICMP
u
u
Internet Control Message Protocol
機能的には IPを補うもの
Ø
Ø
送信先への到達不能，フロー制御など
IPにかわってエラー報告する．
アプリケーション
TCP
IP
UDP
ICMP
Network Interface
物理
99/02/14
99/02/14
29
29
ICMPパケット
IPデータグラム
IPヘッダ(20byte)
ICMPタイプ
コード
ICMPメッセージ
チェックサム
ICMPデータ （任意の長さ．メッセージタイプに依存）
99/02/14
99/02/14
30
30
ICMPメッセージタイプ
u
u
u
u
u
u
u
エコー応答（Echo replay)
宛先到達不能（Destination Unreachable)
発信抑制(Source Quench)
ルート変更(Redirect)
エコー要求(Echo request)
Datagramの時間超過(Time exceed)
Datagramのパラメータ異常(Parameter
Problem)
99/02/14
99/02/14
31
31
ネットワーク層のまとめ
u
ネットワーク層だけでは，信頼性のある通
信を行うことはできない。
u
送信側と受信側とが応答確認する必要
性がある。．
99/02/14
99/02/14
32
32
インターネットと鉄道網
u
u
u
u
u
客(データ)は必ず目的駅(コンピュータ)に到達する
駅には乗換え駅(ゲートウェイ)と普通の駅がある
各路線(ネットワーク)は自律運用、かつ、相互協調
選択可能な経路、経路の選択は知的な作業
鉄道網の「オーナー」はいない
99/02/14
99/02/14
33
33
乗り換え駅
u
鉄道の路線と路線が交わるところ
Ø
例： 藤沢駅
Ø
Ø
Ø
u
ＪＲ東海道線
小田急江ノ島線
江ノ島電鉄
客の行き先で路線を選ばなくてはならない
Ø
例： 湘南台から品川
Ø
Ø
99/02/14
99/02/14
湘南台： 藤沢に行く
藤沢： 東海道線に乗り換え
34
34
経路制御とは
u
u
だれが？ − 乗換駅（ルータ）
何を？- 最適な路線（経路）
Ø
Ø
行き先に応じて路線を判断
最適な路線を選ぶ
Ø
u
どうやって？
Ø
Ø
経路表を作成
経路に関する情報を交換し経路表を更新
Ø
99/02/14
99/02/14
事故の迂回・近い経路・速い経路
Ø
RIP
OSPF
35
35
経路制御
u
どの路線（経路）に乗せればいいか？
Ø
u
目的のホストがどの経路に接続してるか？
経路制御表
Ø
Ø
Ø
経路の選択、制御に用いる
どの路線にはどのホストが接続していると
いう情報（経路情報）をまとめた表
すべてのホストはまとめきれない
Ø
Ø
99/02/14
99/02/14
IPアドレスのネットワーク部
default という経路
36
36
経路表の例
nr60: {2} % netstat -rn
Routing tables
Internet:
Destination
Gateway
Flags Refs Use Interface
default
203.178.140.1
UG
7 35972 ef1
127
127.0.0.1
UR
0
0 lo0
127.0.0.1
127.0.0.1
UH
0
0 lo0
133.27.12.129
203.178.140.1
UGHc 1
120 ef1
133.27.171/24
203.178.140.1
UG
0
0 ef1
202.0.73
203.178.140.1
UG
0
0 ef1
202.0.73.96/27
203.178.140.1
UG
0
0 ef1
202.0.73.128/27
203.178.140.1
UG
0
0 ef1
202.0.73.236/30
203.178.140.1
UG
0
0 ef1
203.178.138.18/30 203.178.141.9
UG
0
0 ef0
203.178.139.64/27 203.178.140.1 UG
0
0 ef1
203.178.139.96/27 203.178.140.1 UG
0
0 ef1
203.178.139.128/27 203.178.140.1 UG
0
0 ef1
99/02/14
99/02/14
37
37
RIP
Routing Information Protocol
u
u
u
送信元と宛先との間で最適なルートを探す
送信元と宛先間の通過しなければならないネ
ットワークの数を単純にカウントする．
ホップ数の一番短いルートが最適ルート
Ø
u
遅延，不可，信頼などは考慮されていない．
最適経路の計算には簡単なコスト計算（三角
不等式）をもちいる．
99/02/14
99/02/14
38
38
OSPF
Open Shortest Path Find
u
u
u
サイト内のルータは同じデータベースを
共有する．
この情報を元に最短パスツリー(Shortest
Path Tree)を形成する．
ネットワークの変化に柔軟に対応できる
99/02/14
99/02/14
39
39
トランスポート層
u
u
u
マシンまで到達したデータをアプリケーションと結
び付ける
ＴＣＰ
ＵＤＰ
アプリケーション
TCP
UDP
IP
Network Interface
物理
99/02/14
99/02/14
40
40
ポート番号
u
u
ネットワーク層によるホストーホスト間の
データ配送
同一ホスト内でのアプリケーションの識別
Ø
u
アプリケーションの識別子
Ø
Ø
99/02/14
99/02/14
一つのホスト内でアプリケーションごとに割
り振りが必要
プロトコル（ＴＣＰ・ＵＤＰ）
ポート番号（プロトコルに固有）
41
41
ポート番号の例
www.sfc.wide.ad.jpのport 番号80番に接続
% telnet www.sfc.wide.ad.jp 80
Trying 203.178.140.3 ...
Connected to enterprise.sfc.wide.ad.jp.
Escape character is '^]'.
GET /index.html
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE>Tokuda, Murai, Kusumoto &amp; Nakamura Laboratory</TITLE>
<LINK REV=MADE HREF="mailto:[email protected]">
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO2022-JP">
</HEAD>
<BODY BGCOLOR="#D6AF85">
99/02/14
99/02/14
42
42
/etc/services
#
# @(#)services 1.16 90/01/03 SMI
tcpmux 1/tcp
# rfc-1078
echo
7/tcp
echo 7/udp
discard
9/tcp
sink null
discard
9/udp
sink null
systat
11/tcp
users
daytime
13/tcp
daytime
13/udp
netstat
15/tcp
chargen
19/tcp
ttytst source
chargen
19/udp
ttytst source
20/tcp
ftp-data
ftp
21/tcp
telnet
23/tcp
smtp
25/tcp
mail
time
37/tcp
timserver
time
37/udp
timserver
99/02/14
99/02/14
43
43
ネットワーク層と
トランスポート層
u
u
トランスポート層でもヘッダを付ける
ネットワーク層ではトランスポート層 ヘ
ッダがついたデータにネットワーク層のヘ
ッダを付加する
5層以上
データ
4層
TCP ヘッダ
データ
3層
IPヘッダ TCP ヘッダ
データ
99/02/14
99/02/14
44
44
UDP
User Datagram Protocol
u
Datagram型通信の提供
Ø
IPはDatagram型の通信
Ø
Ø
トランスポート層はアプリケーションを識別
Ø
99/02/14
99/02/14
Datagram型通信のための新たな機能は必要無い
識別子があればOK
45
45
TCP
Transmission Control Protocol
u
u
データ転送に関する制御を行う
具体的には......
Ø
IPに信頼性を加える
Ø
Ø
Ø
Ø
Ø
99/02/14
99/02/14
Virtual Circuit型通信
エラー検出とエラー訂正
フロー制御
順序の再構成
データ転送に関するインターフェイスを提供
46
46
TCPヘッダ
Src Port
Dst Port
Sequence Number
Acknowledgement Number
Offset
Reserved
Flag
TCP Checksum
Option (if any)
Window Size
Urgent Pointer
Padding
Data
99/02/14
99/02/14
47
47
Flags CODE
u
u
FlagsはTCPがコネクション制御に利用
6つのflagsがある
Ø
Ø
Ø
Ø
Ø
Ø
99/02/14
99/02/14
URG： Urgent Pointerが有効
ACK： Acknowledge Numberが有効
PSH： セグメントをすぐに上位層へ渡す
RST： エラーによる強制的なクローズ
SYN： コネクションセットアップの同期をとる
FIN： コネクションを終了する
48
48
TCPの状態遷移図
CLOSED
Passive Open
Active Open
LISTEN
SYN_SENT
SYN_RCVD
ESTABLISHED
99/02/14
99/02/14
49
49
コネクション開始
送信側
SEQ=812
受信側
SYN SEQ=812 No ACK
SEQ=123
SYN SEQ=123 ACK=813
SEQ=813
ACK=124
SEQ=123
SEQ=813 ACK=124
ACK=813
99/02/14
99/02/14
50
50
3way Handshake
u
99/02/14
99/02/14
コネクションのセットアップ
Ø ホスト1、ホスト2間で
Ø ホスト1はSYN Flagのついたパケットを送る
Ø SYNを受けたホスト2は相手との同期を取るた
めにSYN Flagのついたパケットを送る。この時
いっしょに受け取ったSYNに対するACK Flagも
つける
Ø ホスト2からSYNを受け取ったホスト1はACKを
返す
Ø SYN と ACKが相乗り
Ø Piggy Back
51
51
コネクションの終了
u
u
コネクションの終了はFIN Flagによって行う
コネクションの終了は一方ごとにできる
FIN SEQ=457
SEQ=789 ACK=458
FIN SEQ=790
SEQ=458 ACK=791
99/02/14
99/02/14
52
52
データの転送
u
u
u
Sequence NumberとAcknowledge Numberによって、デ
ータの順番を保証
ACKが帰ってきたら次のデータを送る
ACKが帰ってこなかったら前のデータを再転送
SEQ=231 DATA
SEQ=456 ACK=232
SEQ=232 DATA
99/02/14
99/02/14
53
53
データ転送（続き）
u
u
u
u
99/02/14
99/02/14
いちいちACKを待つと効率が悪い
推測を元にある程度先送りした方が良い
だが、先送りしすぎるとACKがなかなか帰って
こない
幅を決めなければならない
54
54
フロー制御
u
フロー制御とは？
Ø
Ø
u
フロー制御のための機構
Ø
u
相手の受信能力にあわせた送信
ネットワークの状態にあわせた送信
ウィンドウ方式
ウィンドウサイズの決定
Ø
Ø
Ø
99/02/14
99/02/14
受信側が自分の能力にあわせて決定
送信側がネットワークの状態を判断して決定
最適値 = 通信経路の帯域 * RTT
55
55
ウィンドウコントロール
u
u
４
99/02/14
99/02/14
先送りする幅を決める仕組み
送るパケットを制限する
SEQ=238
SEQ=270
SEQ=302
SEQ=334
ACK=335
４
56
56
ウィンドウサイズ制御
u
通信開始時のウィンドウサイズ制御
Ø
Ø
u
スロースタート
ACK毎にサイズを +1
輻輳回避時のウィンドウサイズ制御
Ø
99/02/14
99/02/14
ACK毎ににサイズを “1/輻輳ウィンドウ“づ
つ増加
57
57
スロー･スタート
u
u
u
u
u
99/02/14
99/02/14
ネットワークに送り出されるパケットの通信速度
を他方のエンドから返される確認応答の通信速
度を同期させるためのもの
送り手のTCPに別のウィンドウを追加する。
Ø 輻輳ウィンドウ(cwnd)
新しいコネクションが確立
輻輳ウィンドウをセグメント1つに初期化
ACKが受け取られるたびに、輻輳ウィンドウは1
セグメントずつ増やされる
58
58
スロー・スタート
animation
cwnd=1
１
1:513(512)ack1, win4096
ack513, win8192
cwnd=2
３
４
cwnd=4
cwnd=5
99/02/14
99/02/14
513:1025(512)ack1, win4096
1025:1537(512)ack1, win4096
ack1025, win8192
cwnd=3
２
６
1537:2049(512)ack1, win4096
７
2049:2561(512)ack1, win4096
５
ack1537, win8192
８
ack2049, win8192
９
59
59
TCP-輻輳制御
u
輻輳とは？
Ø
Ø
中間ノードにキューができ通信に遅延が生
じた状態
判断基準
Ø
u
パケット喪失が発生
輻輳回避のストラテジ
Ø
Ø
99/02/14
99/02/14
輻輳を検出したらウィンドウサイズを小さく
ネットワークに負荷をあたえずすみやかに
最適なウィンドウサイズへ回復
60
60
輻輳への対応策
u
喪失パケットの再送ストラテジ
Ø
Ø
u
Fast Retransmit
１パケット喪失／１ウインドウの場合に適用
輻輳後の転送レートの回復ストラテジ
Ø
Ø
99/02/14
99/02/14
Fast Recovery
輻輳から速やかに回復する
61
61
Fast Retransmit
u
DUP ACKが３つ来た場合に適用
Ø
u
すぐにパケットを再送する
さらに DUP ACKがくる場合
Ø
１パケット喪失した後に、さらにパケットが到
着していると推測
Ø
Ø
u
輻輳ウインドウを一旦増加
新しいセグメントを送出する
新しいACKがきたら
Ø
輻輳の終了とみなす
Ø
99/02/14
99/02/14
Fast Retransmitの成功
62
62
Fast Recovery
u
Fast Retransmitが成功した場合
Ø
Ø
Ø
99/02/14
99/02/14
輻輳は深刻なものではなかったと推測
速やかにウインドウを回復
スロースタート段階に入らず、いきなり輻輳
回避段階へ
63
63
TCP通信モデル
u
u
u
99/02/14
99/02/14
ウインドウサイズの変化
スロースタートを経て平衡状態へ
平衡状態ー一定間隔でパケットロス
64
64
インターネットの運用技術
99/02/14
99/02/14
65
65
運用技術
u
u
u
u
99/02/14
99/02/14
DNS
DHCP
品質保証
セキュリティ技術
66
66
名前とIPアドレス
u
コンピュータは数字を扱う方が得意
Ø
u
人間は数字を扱うのは得意ではない
Ø
u
コンピュータはアドレスが分ればＯＫ
数字より名前の方が扱いやすい
名前
Ø
Ø
ホストの名前 (例： mail0 )
組織の名前 （例： sfc.keio.ac.jp)
DNS
Domain Name System
u
ホスト名 (例: mail0.sfc.keio.ac.jp) とIPアドレス(
例: 133.200.113.5) のマッピングを管理
Ø
Ø
Ø
Ø
Ø
Ø
ホスト名とIPアドレスの分散データベース
世界中の全ホストに関する情報を持つ
世界住のどこからでも検索可能
階層化されたマスター情報の管理
サーバ：データの形式と答え方
クライアント：問い合わせ先の情報と問い合わせ方
ＤＮＳの構造
ｊｐ
ａｄ
ｗｉｄｅ
ｅｄｕ
ａｃ
ｋｅｉｏ
ｓｆｃ
ｃｍｕ ｓｔａｎｆｏｒｄ
ｊａｉｓｔ
ｍａｇ
ｃｓ
ｌｅｌａｎｄ
ｓｒ
DHCP
u
u
u
Dynamic Host Configuration Protocol
RFC2131
主に動的に接続するホストを自動構成す
るためのプロトコル
DHCP
DHCP Server
Server
Network
Network
接続希望
接続希望
DHCPDISCOVER
DHCPDISCOVER
DHCPOFFER
DHCPOFFER
DHCP
DHCP Client
Client
DHCPREQUEST
DHCPREQUEST
99/02/14
99/02/14
DHCPACK
DHCPACK
ネットワークアドレスなどを通知
ネットワークアドレスなどを通知
70
70
QoS
Quality of Service
u
Quality
Ø
Ø
Ø
u
99/02/14
99/02/14
到達性の保証
帯域の保証
遅延の保証
優先度に応じた制御
71
71
知性は外側へ
エンドシステム志向
エッジシステム志向
エンド
Core
routers
Core
routers
エッジ
99/02/14
99/02/14
エンド
エッジ
72
72
輻輳制御ルール１：返事で判断
返事が早い→空いてる→沢山送る
99/02/14
99/02/14
73
73
輻輳制御ルール2：混んだら小さく
返事が遅い→混んでる→少し送る
99/02/14
99/02/14
74
74
輻輳制御ルール2：混んだら小さく
返事が無い→混んでる→少し送る
99/02/14
99/02/14
75
75
輻輳制御ルール3：空いても急ぐな
返事が早い→空いてる→ゆっくり送る
99/02/14
99/02/14
76
76
インターネットが遅い原因
u
返事が遅い
Ø
Ø
u
相手がのろい
途中がのろい
相手がのろい場合
Ø
相手が過負荷
Ø
Ø
u
アクセスが多すぎる
力がなさ過ぎる
途中がのろい場合
Ø
99/02/14
99/02/14
どこかの待ち行列であふれている
77
77
インターネットが遅い原因
u
返事が遅い
Ø
Ø
u
相手がのろい
途中がのろい
相手がのろい場合
Ø
相手が過負荷
Ø
Ø
u
アクセスが多すぎる
力がなさ過ぎる
途中がのろい場合
Ø
99/02/14
99/02/14
どこかの待ち行列であふれている
78
78
Differentiated Service
u
今までのインターネット
Ø
ベストエフォート
Ø
Ø
u
サービス保証システム
Ø
Ø
u
届くように努力する
コアシステムに負荷が無い
契約したサービスを保証する
コアシステムの負荷が大きい
これからのインターネット
Ø
Ø
99/02/14
99/02/14
ベストエフォート＋DiffServe
コアシステムに負荷をかけずに優先度のあ
るサービスを提供する
79
79
Random Early Detection
（RED）
Explicit Congestion Notification
（ECN）
ここまでつまったら‥
ここまでつまったら‥
u
u
いくつか捨てる
いくつかマークする
エンドシステムが気がつく
Ø ペースダウンする
99/02/14
99/02/14
Ø
80
80
プライオリティサービス
優先度に応じて捨てちゃえ！
99/02/14
99/02/14
81
81
輻輳制御ルール2：混んだら小さく
返事が無い→混んでる→少し送る
99/02/14
99/02/14
82
82
プレミアムサービス
優先度に応じた別の待ち行列
99/02/14
99/02/14
83
83
RED
Random Early Detection
u
u
ルータの負荷が増大したときに，優先度
の低いトラフィックを意図的に遅らせるこ
とで輻輳の発生を軽減し、優先度の高い
トラフィックの優先的到達を保証する技術
待ち行列の中にあるパケットを優先順位
に基づきにマークもしくは落とす
99/02/14
99/02/14
84
84
セキュリティ
u
公開鍵暗号系を用いた認証に基づくセキ
ュリティの確保
99/02/14
99/02/14
85
85
通信媒体とインターネット
アーキテクチャ
99/02/14
99/02/14
86
86
通信媒体技術
u
広域系
Ø
Ø
Ø
Ø
Ø
Ø
衛星
Cable TV
xDSL
SONET
WDM
ISDN
u
LAN系
Ø
Ø
Ø
Ø
Ø
Ø
Ø
99/02/14
99/02/14
10baseT
100baseT
Gigabit
Wireless
HUB
Switch
FDDI
87
87
帯域が異なる媒体の混在
u
フラグメントをさける技術
Ø
u
ボトルネック
Ø
99/02/14
99/02/14
PathMTU
Packat Pair
88
88
遅延の大きく高速な
通信媒体の混在
u
99/02/14
99/02/14
輻輳制御の副作用で利用効率が悪化
89
89
片方向の通信媒体の混在
u
99/02/14
99/02/14
UDLRなどを用いた有効利用が必要
90
90
Satellite for Internet
N-STAR
JCSAT
30Mbps
ＳＯＨＯ
FIL
TX
MOD
♦ MPEG2
♦ Multicast
♦ Unicast
Home
Local Office
NOC
(Network Operation Center)
TX Server Information Server
Proxy Server
64kbps
ISDN
MUX
Encoder
Router
Authentication Server
28.8k
bps
Router
Internet
Router
99/02/14
99/02/14
Head
Office
91
91
環境適応のための技術
99/02/14
99/02/14
92
92
適応のための技術
u
SOHO
Ø
u
NAT/Masquerade
Ø
Mobile-IP
IP トンネル
非対称通信
Ø
UDLR
Security
Ø
モバイル
Ø
u
u
Ø
Ø
u
アドレス枯渇
Ø
u
Firewall
Application
Gateway
VPN
CIDR
経路情報の氾濫
Ø
IGP+BGP
本来アーキテクチャはどう対応すべきか？
本来アーキテクチャはどう対応すべきか？
99/02/14
99/02/14
93
93
NAT・Masquerade
99/02/14
99/02/14
94
94
Mobile IP
u
u
RFC2002
Mobile Node:
Ø
u
Home Agent:
Ø
u
移動先での移動ノードの管理
Care-of Address:
Ø
99/02/14
99/02/14
移動ノードの位置を管理
Foreign Agent:
Ø
u
移動ノード
IP tunnelingの移動先での端点
95
95
Mobile IP
移動の通知
トンネルの確立
MN
FAの発見
FA
HA
CN
99/02/14
99/02/14
96
96
経路の集約(aggregation)
u
u
u
各ノードが持つ経路情報はホストの数だ
け存在する．
ホストが増えるにつれて，経路情報も増
大．
このままでは破綻してしまうので，経路情
報の階層化，経路情報の圧縮をおこなう
．
99/02/14
99/02/14
97
97
経路の集約その２
ルータ2
ルータ1
203.178.140.0/27
ルータ3
203.178.140.32/27
203.178.140.64/27
経路の集約
203.178.140.0/24
集約した経路を流す
99/02/14
99/02/14
98
98
CIDR
Classless Internet Domain Routing
u
u
複数のIPアドレスをより少ない数のルー
ティングテーブルに集約する
例
Ø
99/02/14
99/02/14
インターネット上で異なる8個所に割り当て
られているネットワークのアドレスを集約化
して１つのルーティング・テーブル・エントリ
として扱う
99
99
AS - Autonomous System
u
u
u
さまざまなネットワークが相互接続してい
る状況では通信を行う経路は複数存在
どの経路を選ぶかは，ネットワークを運営
する組織のポリシーによる．
経路情報を一定のグループにまとめて扱
うことができるようにASという概念を導入
．
99/02/14
99/02/14
100
100
IGPとEGP
u
u
u
経路制御プロトコルには，スケールする
限界がある．
おもにAS内でもちいるプロトコルを
IGP(Interior Gateway Protocol)という．
ASとASとの間の経路情報交換などを想
定してるつくられている経路制御プロトコ
ルをEGP(Exterior Gateway Protocol)
99/02/14
99/02/14
101
101
ASとルーティング
AS１
IGP
EGP
AS2
代表的なAS番号
ASN-WIDE 2500
OCN
99/02/14
99/02/14
4717
102
102
EGP
Exterior Gateway Protocol
u
u
ASとASとの間でのネットワーク到達情報
を伝達するプロトコルの総称．
EGP,BGP(Border Gateway Protocol)
BGP2,BGP3とへて現在はBGP4がもちい
られている．
99/02/14
99/02/14
103
103
Packet Filtering Firewall
内部ネットワーク
×
フィルタリング・ゲートウェイ
(外部から直接内部にアクセ
スする通信をブロックする）
The Internet
外部ゲートウェイ
(全てを通過させる）
出島
（アクセスコントロールをこのゲー
トウェイに集約。攻撃の発見のた
めにモニタリングも実施）
Application Gateway
内部ネットワーク
？
The Internet
アプリケーション・ゲートウェイ
外部からはこのマシンのみが見える
外部アプリケーションはこのマシンに接続。
プロキシ的な役割
99/02/14
99/02/14
105
105
VPN
u
u
Virtual Private Network
プライベートネットワーク間でパケットをカ
プセル化してインターネット上を配送
Private
Private
Internet
99/02/14
99/02/14
106
106
アプリケーション
アーキテクチャ
99/02/14
99/02/14
107
107
アプリケーション
アーキテクチャ
u
u
Client - Server モデル
WWW
Ø
Ø
Ø
Ø
u
99/02/14
99/02/14
キャッシュ
Proxy
Java
CGI vs Java
SLP
108
108
クライアント・サーバモデル
u
通信相手とのタイミング
Ø
２つのプログラムのコミュニケーション
２つが非同期だとうまく通信できない
Ø
一方が待ち受けし続け、一方がリクエストを送る
→ クライアント・サーバモデル
Ø
u
クライアント
Ø
u
能動的にサービス提供を促す側
サーバ
Ø
受動的にサービス提供する側
クライアント・サーバ
u
クライアントとサーバの役割分担
クライアント
Ø
Ø
通信を開始するアプリケーション
サーバ
Ø
Ø
クライアントからの要求を待ち受けるアプリケーション
Client
メッセージの流れ
要求
時 間
応答
Server
処理
クライアント・サーバの例
u
サーバ（サービスを提供する側）
Ø
Ø
Ø
u
finger サーバ （fingerd）
WWWサーバ （httpd)
体育予約サーバ
クライアント（サービスを受ける側）
Ø
Ø
Ø
finger クライアント (finger)
WWWクライアント （Netscape）
体育予約クライアント
アプリケーションの識別
UDP
TCP
アプリ
ネットワーク層
プロトコル
ホスト内のアプリ
ケーションを識別
ポート番号
インターネット内の
IPアドレス
ホストを識別
データリンク層
同一ネットワーク内の
MACアドレス
ホストを識別
25
80
1024
トランスポート層
ホストA
99/02/14
99/02/14
アプリ
アプリ
ホストB
112
112
WWWの仕組み
u
クライアントサーバモデル
Ø
クライアント
Ø
Ø
Ø
サーバ
Ø
Ø
u
Webブラウザ
情報の獲得・表示を行う
Webサーバ(httpd)
リクエストされた文書(ドキュメント)を送る
URL
Ø
Ø
Uniformed Resource Locator
リソース(情報)の取り方と場所を一意に表記
http://www.nic.ad.jp/iw97/index.html
入手方法(プロトコル)
99/02/14
99/02/14
サービスしているサーバ
サーバ内の場所
(フォルダ・ファイル名)
113
113
WWWの仕組み
u
Proxy サーバ
Ø
中間で両方の代理として動作
Ø
Ø
Ø
様々な利用方法
Ø
Ø
u
キャッシュ
セキュリティ
HTTP
Ø
Ø
Ø
Hyper Text Transfer Protocol
TCPを用いた通信
様々な種類のリソースを転送
Ø
Ø
Ø
99/02/14
99/02/14
クライアントの代わりにサーバにアクセス
サーバの代わりのクライアントに情報を提供
Ø
HTML文書
plain Text
GIF画像 etc…
単純なプロトコル
Ø
数種類のRequest Method
GET/PUT/POST…
114
114
WWW
インターネット
99/02/14
99/02/14
115
115
CGI
u
動的なContentsを作るための仕組み
Ø
Ø
プログラムインターフェイス
決められた方式でクライアント側からの情報を渡す
Ø
Ø
動作する言語は考慮しない
Ø
99/02/14
99/02/14
2種類のMethod
Ø XXX
Ø 環境変数
なんでもOK
116
116
サーバとクライアントの関係
IPアドレス
ポート番号
要求
クライアント
返答
WWWサーバ
99/02/14
99/02/14
117
117
プログラム実行とその権限
Java
クライアント
Java Applet
サーバ
プログラム
プログラム
OS
OS
プログラム権限
インターフェイス
インターフェイス
プラットフォーム
CGI
クライアント
プログラム
プラットフォーム
CGIリクエスト
実行 結果
サーバ
プログラム
インターフェイス
インターフェイス
OS
OS
プラットフォーム
99/02/14
99/02/14
プラットフォーム
118
118
プログラム実行とその権限
ActiveX
クライアント
プログラム
インターフェイス
OS
プラットフォーム
99/02/14
99/02/14
HTTPリクエスト
ActiveX情報
どのタイプ
サーバ
プログラム
インターフェイス
OS
プラットフォーム
119
119
Java
u
プラットフォームを意識しない
Ø
u
ネットワークを介した環境を考慮
Ø
Ø
u
プログラムのダウンロード
実行ホストへのセキュリティ対策
WWWのContentsとして普及
Ø
99/02/14
99/02/14
Java VM
クライアント側で実行
120
120
Java
ネットワーク上の動作
Java
これを実行してね
URL
プログラムを頂戴
99/02/14
99/02/14
WWWサーバ
121
121
Java
動作概要
サービス
を要求
Java
プログラム
Java VM
ローカルの資源に
アクセス
プラットフォーム
99/02/14
99/02/14
122
122
Service Location Protocol
as of Atlanta Olympic 1996
JAPAN
US 1
US 2
UK
Germany
Internet
99/02/14
99/02/14
123
123