水曜日 - 東京大学

集中講義
インターネットテクノロジー
第3回
一井信吾
東京大学大学院数理科学研究科
[email protected]
昨日の補足：DHCP
(Dynamic Host Configuration Protocol)
„
ホストをネットワークにつなぐ
とき、いろいろな情報が必要
‰
‰
‰
‰
‰
‰
„
„
IPアドレス
ネットマスク
ホスト名
ドメイン名
ネームサーバ
デフォルトルータ
手入力は面倒
手入力は間違える
⇒ 自動設定したい！
2002/5/29
„
IPアドレスとネットマスク
CIDR表記 157.82.16.1/22
マスク 255.255.252.0
„
デフォルトルータ
ルーティングテーブルを簡単化
するための手段
dest net
next hop
hop
157.82.16.0/24
-
0
default
157.82.16.1
1
広島大学集中講義
2
通信を始めるには？
„
通信を行うにはIPアドレスが
必要
‰
„
鶏が先か卵が先か！？
„
ブロードキャストとは？
‰
‰
特別なアドレスを使う
‰
‰
„
0.0.0.0
„
„
未設定ホスト
‰
255.255.255.255
„
“this network”
„
「このネットワーク」全体への
ブロードキャスト
IPアドレスがわかっている場
合はhost部all 1
„
一対「全体」通信
link layerの機能を使う（こと
が多い）
‰
Ethernet
無線LAN
同一「ネットワーク」上の全て
のホストにデータグラムが届
けられる
cf.
„
„
ユニキャスト（一対一）
マルチキャスト（一対多）
157.82.19.255
2002/5/29
広島大学集中講義
3
DHCPサーバ
„
DHCPを使うホスト（DHCPクライアント）に与え
るべき情報を保持
‰
IPアドレス
„
アドレスプール
DHCPで割り当ててよいアドレスをいくつか確保しておき、動的に
割り当てる
„
固定割り当て
クライアントのMacアドレスにIPアドレスを固定対応させる
‰
„
netmask, default router etc.
サーバは複数あってもよい
‰
2002/5/29
クライアントが選択
広島大学集中講義
4
DHCPの動作
DHCP client
startup
DHCP server
DHCPDISCOVER (broadcast)
DHCPOFFER (unicast)
時間
DHCPREQUEST (broadcast)
DHCPACK (unicast)
(lease expire毎にrequest/ack繰り返し）
shutdown
2002/5/29
DHCPRELEASE (unicast)
広島大学集中講義
5
本日の内容
„
トランスポート層プロトコル
‰
‰
„
TCP (Transmission Control Protocol)
UDP (User Datagram Protocol)
DNS (Domain Name System)
2002/5/29
広島大学集中講義
6
トランスポート層のサービスとプロトコル
„
‰
ネットワーク層：エンドシステ
ム間のデータ送受信
トランスポート層：プロセス間
のデータ送受信
„
2002/5/29
network
data link
physical
t
or
sp
an
tr
‰
network
data link
physical
network
data link
physical
d
en
den
al
ic
„
application
transport
network
data link
physical
g
lo
„
異なったホスト上で実行されて
いるアプリケーションプロセス
（プログラム）の間の論理的な
通信 を実現する
トランスポート層プロトコルは
エンドシステム上で動く
トランスポート層とネットワーク
層のサービスの相違
network
data link
physical
network
data link
physical
application
transport
network
data link
physical
ネットワーク層のサービスを
使いつつ、それをenhance
する
広島大学集中講義
7
トランスポート層のプロトコル
network
data link
physical
t
or
sp
an
tr
広島大学集中講義
network
data link
physical
network
data link
physical
d
en
den
al
ic
2002/5/29
application
transport
network
data link
physical
g
lo
インターネットでのトランスポート層
„ 信頼性があるユニキャスト転送
(TCP)
‰ 輻輳（混雑）
‰ フロー制御
‰ コネクションの確立
„ 信頼性がない (“best-effort”),
ユニキャストまたはマルチキャス
トの転送(UDP)
„ リアルタイムアプリケーションの
サポート(RTP)
„ 開発されたがまだあまり使われ
ていない技術もある
‰ 帯域確保
‰ 信頼性のあるマルチキャスト
network
data link
physical
network
data link
physical
application
transport
network
data link
physical
8
Multiplexing/demultiplexing
セグメント：トランスポート層の
データ転送単位
application-layer
data
segment
header
segment
2002/5/29
Ht M
Hn segment
P1
M
application
transport
network
Demultiplexing: ホストが受け
取ったセグメントを正しいアプリ
ケーションプロセスに渡す
P3
receiver
M
M
application
transport
network
広島大学集中講義
P4
M
P2
application
transport
network
9
Multiplexing/demultiplexing
Multiplexing:
単一ホスト上の複数のプロセス
から送信されるセグメントを
demultiplexingで使うヘッダをつ
けて送出
multiplexing/demultiplexing:
„ src, destの各ポート番号、IP
アドレスによって識別
‰ 各セグメントにsrc, destポー
ト番号
‰
2002/5/29
特定のアプリケーションに
は”well-known port”が割り
当てられている
広島大学集中講義
32 bits
source port #
dest port #
other header fields
application
data
(message)
TCP/UDP セグメントのフォーマット
10
Well-Known Ports
purple: [263] % cat /etc/services
#
# Network services, Internet style
#
#
@(#)services
8.1 (Berkeley) 6/9/93
#
BSDI services,v 2.29 2001/04/17 20:55:18 jch Exp
#
tcpmux
1/tcp
# TCP port multiplexer (RFC1078)
echo
7/tcp
echo
7/udp
discard
9/tcp
sink null
discard
9/udp
sink null
systat
11/tcp
users
systat
11/udp
users
daytime
13/tcp
daytime
13/udp
netstat
15/tcp
qotd
17/tcp
quote
qotd
17/udp
quote
chargen
19/tcp
ttytst source
chargen
19/udp
ttytst source
ftp
21/tcp
ssh
22/tcp
# Secure shell
2002/5/29
広島大学集中講義
11
Multiplexing/demultiplexing: 例
host A
source port: x
dest. port: 23
server B
source port:23
dest. port: x
Source IP: C
Dest IP: B
source port: y
dest. port: 80
telnet
Web client
host A
2002/5/29
Web client
host C
Source IP: A
Dest IP: B
source port: x
dest. port: 80
Source IP: C
Dest IP: B
source port: x
dest. port: 80
Web
server B
Web server
広島大学集中講義
12
UDP: User Datagram Protocol [RFC 768]
„
„
„
„
「飾りのない」「裸の」トラン
スポート層プロトコル
“best effort”サービス
UDP セグメントは
‰ なくなるかもしれない
‰ 順番は入れ替わるかも
しれない
コネクションレス型：
‰ UDPの送信側と受信側
でハンドシェイク等無用
‰ ルータ上UDPセグメント
は一つずつ独立に処理
される
2002/5/29
どうしてUDPがあるのか？
„
„
„
„
広島大学集中講義
コネクション確立（時間がか
かる）不要
単純：送信側、受信側ともに
状態がない
セグメントヘッダが小さい
輻輳制御なし：いくらでも帯
域を使える（⇔使ってしまう）
13
UDP: 続き
„
マルチメディアストリーミ
ングによく使われている
‰
‰
少々のパケットロスは気に
しない
使える帯域は全部使う（使
えてしまう）
ヘッダを含む
UDP
セグメント長
（バイト）
„
他にUDPを使うもの
„
DNS
‰ SNMP
UDPを使って信頼性ある通信
を行う
‰ NFS
‰
„
2002/5/29
アプリケーションで再送な
どの制御を行う
広島大学集中講義
32 bits
source port #
dest port #
length
checksum
Application
data
(message)
UDP のセグメントフォーマット
14
UDP checksum
目的： 受信したセグメントに誤り（0が１に、1が0になって
しまう）がないか検査する
送信側：
„
„
„
„
受信側：
checksumフィールドを0とす
る
セグメントの内容を16ビット
整数と思う
順に足して行き、最後に0と1
を反転する（1の補数）
得られた値をUDP
checksumフィールドに入れ
る
2002/5/29
„
„
受け取ったセグメントのチェッ
クサムを計算する
11111...1になるかどうか？
広島大学集中講義
‰
‰
NO – エラー発見
YES – エラーは見つからなかっ
た
15
Reliable Transport
„
unreliableなIPを使ってreliableな転送をしたい
‰
„
reliableとは？データの欠落、重複、順序の入れ替えなどが起こらない
こと
Link層の性質が、機能や性能に影響を与える
2002/5/29
広島大学集中講義
16
TCP: Overview
„
point-to-point:
‰
„
‰
socket
door
１対１通信
バイト単位の「データの流れ」
のようなサービス
メッセージ境界はない
‰
„
„
application
writes data
application
reads data
TCP
send buffer
TCP
receive buffer
データ交換を始める前に
handshakingが必要
フロー制御
‰
socket
door
単一のコネクションで双
方向通信
MSS: maximum
segment size
connection-oriented:
‰
TCP輻輳制御、フロー制御
によりwindow sizeがきまる
send & receive buffers
全二重
‰
パイプライン
‰
„
„
reliableで順序を保つバイトス
トリーム
‰
„
RFCs: 793, 1122, 1323, 2018, 2581
受信側が受け取れるスピー
ドで送信
segment
2002/5/29
広島大学集中講義
17
Pipelined protocols
パイプライン： 送信側が（受信側からの到達確認ack
を待たずに）次々にパケットを送る
‰
‰
2002/5/29
送信側、受信側ともにバッファが必要
RTT (round trip time)が長いとき、throughputを上げる
ために有効
広島大学集中講義
18
TCP segment structure
32 bits
URG: urgent data
(generally not used)
ACK: ACK #
valid
PSH: push data now
(generally not used)
RST, SYN, FIN:
connection estab
(setup, teardown
commands)
Internet
checksum
(as in UDP)
2002/5/29
source port #
dest port #
sequence number
acknowledgement number
head not
UA P R S F
len used
checksum
rcvr window size
ptr urgent data
Options (variable length)
counting
by bytes
of data
(not segments!)
# bytes
rcvr willing
to accept
application
data
(variable length)
広島大学集中講義
19
TCPのシーケンス番号とACK
シーケンス番号
‰ セグメントの先頭のバ
イトがバイトストリー
ム中で何バイト目か
ACK:
‰ 次に受信することが
期待されるシーケン
ス番号
‰ cumulative ACK
„
まとめてACK
Q: セグメント到着の順序が
変わったら？
‰ A: RFCには何も書い
てない。実装任せ
Host B
Host A
User
types
‘C’
Seq=4
2
, A CK
=79, d
a
=
ACK
,
9
7
Seq=
host ACKs
receipt
of echoed
‘C’
Seq=4
3
ta = ‘C
ata =
43, d
’
‘C’
host ACKs
receipt of
‘C’, echoes
back ‘C’
, A CK
= 80
simple telnet scenario
2002/5/29
広島大学集中講義
time
20
TCP: reliable data transfer
event: 上位のアプリケーション層
からデータ到着
セグメントを作成、送信
wait
wait
for
for
event
event
送信側(simplified)
•片方向通信
•フロー制御、輻輳制御なし
event: シーケンス番号yを待っている
間にタイムアウト
セグメント再送
event: ACK y受信
ACK 処理
2002/5/29
広島大学集中講義
21
TCP: reliable
data transfer
Simplified
TCP
sender
2002/5/29
00
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
sendbase = initial_sequence number
nextseqnum = initial_sequence number
loop (forever) {
switch(event)
event: data received from application above
create TCP segment with sequence number nextseqnum
start timer for segment nextseqnum
pass segment to IP
nextseqnum = nextseqnum + length(data)
event: timer timeout for segment with sequence number y
retransmit segment with sequence number y
compue new timeout interval for segment y
restart timer for sequence number y
event: ACK received, with ACK field value of y
if (y > sendbase) { /* cumulative ACK of all data up to y */
cancel all timers for segments with sequence numbers < y
sendbase = y
}
else { /* a duplicate ACK for already ACKed segment */
increment number of duplicate ACKs received for y
if (number of duplicate ACKS received for y == 3) {
/* TCP fast retransmit */
resend segment with sequence number y
restart timer for segment y
}
} /* end of loop forever */
広島大学集中講義
22
TCP ACK 生成ルール [RFC 1122, RFC 2581]
Event
TCP Receiver action
セグメントが順序どおり到着
ギャップなし
他のセグメントは全てACK済
delayed ACK. 次のセグメントが来るまで
最大500ms待つ。セグメントがこなければ、
ACK送信
セグメントが順序どおり到着
ギャップなし
delayed ACK待ち
cumulative ACK を即時送信
セグメント到着順序誤り
期待より大きなシーケンス番号
ギャップ発見
期待するシーケンス番号をつけた
duplicate ACK送信
ギャップを一部または全部
埋めるセグメント到着
ギャップの低い側が埋まったら、
ACKを即時送信
2002/5/29
広島大学集中講義
23
TCP: 再送のシナリオ
Host A
, 8 byt
es da
ta
=100
K
C
A
X
loss
Seq=9
2
, 8 byt
es da
ta
=100
K
C
A
time
2002/5/29
Host B
Seq=9
2
Seq=100 timeout
Seq=92 timeout
Seq=9
2
timeout
Host A
Host B
lost ACK scenario
Seq=
1
, 8 byt
es da
00, 2
0 byt
広島大学集中講義
es da
ta
0
10
=
K
120
=
C
K
A AC
Seq=9
2
, 8 byt
es da
A
time
ta
ta
=1 2
CK
0
premature timeout,
cumulative ACKs
24
TCP フロー制御
フロー制御
受信側： バッファの開き
スペースを
RcvWindowフィール
ドに入れて受信側に
伝える
受信側の受信バッファが
あふれないように
送信側が送信速度を
制御する
RcvBuffer = size of TCP Receive Buffer
RcvWindow = amount of spare room in Buffer
送信側： 送信済、未
ACKデータの量が直
近受信した
RcvWindowフィール
ドの値を超えないよう
に制御
receiver buffering
2002/5/29
広島大学集中講義
25
RTTとタイムアウト
Q: タイムアウト時間を
どう決めるか？
„
„
RTTより長く
‰ RTTは変動すること
に注意
タイムアウト時間が短す
ぎるとpremature
timeout
‰
„
不必要な再送につ
ながる
長すぎると、セグメント
損失への対応（再送）が
遅くなる
2002/5/29
Q: RTTをどう推定するか？
„
„
SampleRTT: セグメント送信
時刻からACK受信までの時間
‰ 再送とcumulatively ACKさ
れたセグメントは除く
SampleRTTは「ばたばた」
変動するので、変動を滑ら
かにしたい
‰
SampleRTTの移動平均を
使う
広島大学集中講義
26
RTTとタイムアウト
EstimatedRTT = (1-x)*EstimatedRTT + x*SampleRTT
„
„
„
指数重み付け移動平均
ここのサンプルの影響は指数関数的に減少
x = 0.1程度
タイムアウト時間の設定
„
„
EstimtedRTT ＋安全マージン
EstimatedRTTの変動が大 ⇒ 安全マージンも大
Timeout = EstimatedRTT + 4*Deviation
Deviation = (1-x)*Deviation +
x*|SampleRTT-EstimatedRTT|
2002/5/29
広島大学集中講義
27
コネクション管理
TCPでは、データ交換を始
める前にコネクション設定
が必要
„
„
„
Control segmentを使う
変数の設定
‰ シーケンス番号
‰ RcvWindowなどの値
クライアント：コネクションを始
める
Socket clientSocket = new
Socket("hostname","port
number");
„
サーバ：クライアントからのコネ
クションを受け付ける
Socket connectionSocket =
welcomeSocket.accept();
2002/5/29
Three way handshake:
Step 1: クライアント側
‰
‰
TCP SYN セグメントをサーバ
に送信
初期シーケンス番号を通知
Step 2: サーバ側
‰
SYNACKを返送
‰
サーバ側バッファ割り当て
‰
初期シーケンス番号を通知
Step 3:クライアント側
‰
ACKを返送
‰
バッファ割り当て
広島大学集中講義
28
TCP コネクション管理
client
コネクションの終了
client closes socket:
clientSocket.close();
close
Step 1: クライアント側
TCP FIN送信
Step 2: サーバ側
‰
ACK送信
‰
通信終了
‰
FIN送信
FIN
AC K
close
FIN
timed wait
‰
server
A CK
closed
（続く）
2002/5/29
広島大学集中講義
29
TCP コネクション管理
Step 3: クライアント側
‰
ACK送信
‰
timed waitに入る
client
closing
Step 4:サーバ側
closing
FIN
通信終了
注： もし双方が同時にFINを送
信しても大丈夫
FIN
AC K
timed wait
‰
server
A CK
closed
closed
2002/5/29
広島大学集中講義
30
TCP コネクション管理
サーバ側
クライアント側
2002/5/29
広島大学集中講義
31
+---------+ ---------¥
active OPEN
| CLOSED |
¥
----------+---------+<---------¥
¥
create TCB
|
^
¥
¥ snd SYN
passive OPEN |
|
CLOSE
¥
¥
------------ |
| ---------¥
¥
create TCB |
| delete TCB
¥
¥
V
|
¥
¥
+---------+
CLOSE
|
¥
| LISTEN |
---------- |
|
+---------+
delete TCB |
|
rcv SYN
|
|
SEND
|
|
----------|
|
------|
V
+---------+
snd SYN,ACK /
¥
snd SYN
+---------+
|
|<---------------------------------->|
|
|
SYN
|
rcv SYN
|
SYN
|
|
RCVD |<-----------------------------------------------|
SENT |
|
|
snd ACK
|
|
|
|------------------------------------|
|
+---------+
rcv ACK of SYN ¥
/ rcv SYN,ACK
+---------+
|
-------------|
|
----------|
x
|
|
snd ACK
|
V
V
| CLOSE
+---------+
| ------| ESTAB |
| snd FIN
+---------+
|
CLOSE
|
|
rcv FIN
V
------|
|
------+---------+
snd FIN /
¥
snd ACK
+---------+
| FIN
|<---------------------------------->| CLOSE |
| WAIT-1 |-----------------|
WAIT |
+---------+
rcv FIN ¥
+---------+
| rcv ACK of FIN
------|
CLOSE |
| -------------snd ACK
|
------- |
V
x
V
snd FIN V
+---------+
+---------+
+---------+
|FINWAIT-2|
| CLOSING |
| LAST-ACK|
+---------+
+---------+
+---------+
|
rcv ACK of FIN |
rcv ACK of FIN |
| rcv FIN
-------------- |
Timeout=2MSL -------------- |
| ------x
V
-----------x
V
¥ snd ACK
+---------+delete TCB
+---------+
------------------------>|TIME WAIT|------------------>| CLOSED |
+---------+
+---------+
TCP Connection State Diagram
2002/5/29
広島大学集中講義
32
輻輳制御
輻輳(congestion)とは
„
„
„
„
ネットワーク（≒ルータ、スイッチ）が処理しきれないほど
たくさんのデータが一度に送信されている状態
フロー制御とは別（ホストのバッファあふれを防ぐ）
症状
‰ パケット損失（ルータでのバッファあふれ）
‰ 遅延増大（ルータでの待ち行列）
ネットワーク3大問題(?)の一つ
2002/5/29
広島大学集中講義
33
輻輳が起こるとき
80Mbps
１００Mbps
１００Mbps
１００Mbps
１００Mbps
１００Mbps
80Mbps
このルータの「出口」でパケット廃棄！
2002/5/29
広島大学集中講義
34
このときは？
50Mbps
１００Mbps
１００Mbps
１００Mbps
１００Mbps
１００Mbps
50Mbps
トラフィックには統計的変動があるので、
この場合でもやはり輻輳発生！
⇒ トラフィックの統計的性質の解明が重要！
2002/5/29
広島大学集中講義
35
輻輳によるコスト
„
輻輳が起きると...
‰
パケット廃棄が起きるので
„
同じデータを送るために、再送を繰り返す必要がある
‰
‰
„
‰
packet-loss sensitiveなアプリケーションが使えなくなる
パケット転送時間が長くなるので
„
TCPのRTT推定値が長くなる
‰
‰
„
バッファ消費量が増える
throughputが下がる
RTT-sensitiveなアプリケーションが使えなくなる
‰
2002/5/29
余計な時間がかかる
帯域の無駄遣いが生じる
例：IP電話
広島大学集中講義
36
輻輳制御の方法
End-end 輻輳制御:
„
„
„
ネットワークからの特別な情
報はない
end systemが検知するパケッ
ト損失、遅延から輻輳状態を
推定
(original) TCPの道
2002/5/29
ネットワークによる輻輳制
御
„
ネットワーク（≒ルータ）が輻輳
状態をend systemに通知
‰ single bit indicating
congestion (SNA, DECbit,
TCP/IP ECN, ATM)
‰ 送信側の送信レートを指定
‰ TCPでも使われる可能性
(ECN)
広島大学集中講義
37
TCP の輻輳制御
„
„
end-end control（ネットワークの手助けなし）
congestion window size Congwin によって制御
Congwin
„
MSSバイトのセグメント w 個が1 RTTの間に送られ
る
w * MSS
throughput =
2002/5/29
RTT
Bytes/sec
広島大学集中講義
38
TCP の輻輳制御
„
利用可能なバンド幅を推
定する
‰
‰
できるだけ速く送信
（Congwinをできるだけ大
きく）
„
„
slow start
congestion avoidance
変数
‰
‰
Congwin
threshold
„
Congwin を増やす
パケット損失が起きると
„
2002/5/29
‰
パケット損失が起きるまで
„
‰
２つのフェイズ
理想的には
„
‰
„
Congwin を小さくする
再度、徐々にCongwinを
大きくしていく
広島大学集中講義
slow start と congestion
avoidance の境界を与え
る
39
TCP Slowstart
Host A
initialize: Congwin = 1
for (each segment ACKed)
Congwin++
until (loss event OR
CongWin > threshold)
„
„
CongWin は RTT 毎に指数的に増え
る
パケット損失の検出
‰
‰
2002/5/29
timeout (Tahoe TCP)
and/or or three duplicate ACKs
(Reno TCP)
広島大学集中講義
RTT
Slowstart algorithm
Host B
one segm
ent
two segm
en
ts
four segm
ents
time
40
TCP Congestion Avoidance
Congestion avoidance
/* slowstart is over
*/
/* Congwin > threshold */
Until (loss event) {
every w segments ACKed:
Congwin++
}
threshold = Congwin/2
Congwin = 1
perform slowstart 1
1: TCP Reno skips slowstart (fast
recovery) after three duplicate ACKs
2002/5/29
広島大学集中講義
41
AIMD
TCP congestion
avoidance:
„ AIMD: additive
increase, multiplicative
decrease
‰
‰
RTT毎にwindowを1ず
つ増やす
パケット損失検出毎に
windowを半分にする
TCP Fairness
Fairnessの目標
N個のTCPセッションが同一
のリンクを共用しているとき、
おのおののセッションが得る
帯域は1/N
TCP connection 1
TCP
connection 2
2002/5/29
広島大学集中講義
bottleneck
router
capacity R
42
Why is TCP fair?
2つのセッションがあるとする
„
„
throughputが増えるとき、additive increaseによって傾き1の方向にすすむ
パケット損失があると、各々のセッションのthroughputはそのときに実現している
throughputに比例した量だけ減少する
equal bandwidth share
Connection 2 throughput
R
loss: decrease window by factor of 2
congestion avoidance: additive increase
loss: decrease window by factor of 2
congestion avoidance: additive increase
Connection 1 throughput R
2002/5/29
広島大学集中講義
43
TCP の遅延のモデル
Q: WWWサーバにリクエストを送って
から、オブジェクト（例：HTMLファイ
ル）が届くまでにどれだけの時間が
かかるか？
記号と仮定
„
„
TCP コネクション確立
„
„
データ転送時間
„
„
„
サーバとクライアントは転送レー
トRのリンクで接続されている
W: congestion window （固定）
S: MSS (bits)
O: オブジェクトの大きさ (bits)
再送なし
場合わけ
•WS/R > RTT + S/R
•window内の最初のセグメントに対するACKが、window一杯のデータを送り
終わる前に帰ってくる
•WS/R < RTT + S/R
•window一杯のデータを送り終わってから、ACKを待つ時間がある
2002/5/29
広島大学集中講義
44
TCP latency Modeling
Case 1: latency = 2RTT + O/R
2002/5/29
K:= O/WS
Case 2: latency = 2RTT + O/R
+ (K-1)[S/R + RTT - WS/R]
広島大学集中講義
45
Slow Start の効果
Example:
O/S = 15 segments
K = 4 windows
initiate TCP
connection
request
object
first window
= S/R
RTT
second window
= 2S/R
Q=2
third window
= 4S/R
P = min{K-1,Q} = 2
Server stalls P=2 times.
fourth window
= 8S/R
complete
transmission
object
delivered
time at
client
2002/5/29
広島大学集中講義
time at
server
46
DNS: Domain Name System
インターネットのホスト、ルー Domain Name System:
タ等を識別するもの
‰
IPアドレス（32ビットの数）
„
‰
分散データベース
‰
経路を与える
「名前」
„
„
purple.ms.u-tokyo.ac.jp
人間がわかりやすい
Q: IPアドレスと「名前」をど
う結びつけるか？
2002/5/29
„
„
多数の「ネームサーバ」
を階層的に構成して全
世界をカバー
名前の「解決」
(resolve)
‰
広島大学集中講義
ホスト、ルータ、ネーム
サーバ等がアプリケー
ション層プロトコルを通
じて通信
47
ドメイン名とは
„
URL
http://www.ms.u-tokyo.ac.jp/~ichii/hiroshima2002/
„
メールアドレス
[email protected]
„
ホスト名
$ ssh as301.ecc.u-tokyo.ac.jp
2002/5/29
広島大学集中講義
48
ドメイン名の構造
„
RFC1035
“DOMAIN NAMES – IMPLEMENTATION AND
SPECIFICATION”
„
as amended by RFC1123
“Requirements for Internet Hosts – Application and
Support”, Section 2.1
2002/5/29
広島大学集中講義
49
TLD: Top Level Domain
„
gTLD: generic TLD
‰
‰
„
ccTLD: country code TLD
‰
‰
„
.com, .org, .net
.int, .edu, .mil, .gov
.us, .jp, etc.
.uk (.gbでなく)
New TLDs
‰
‰
2002/5/29
.biz, .info
.aero, .coop, .museum, .name, .pro
広島大学集中講義
50
.jp
„
属性型ドメイン名
‰
„
地域型ドメイン名
‰
„
AC, AD, CO, ED, GO, GR, NE, OR
tokyo.jp, chiba.jp etc.
汎用JPドメイン名
‰
‰
‰
‰
‰
2002/5/29
本国内に住所があればだれでも登録できる。
いくつでも登録できる。
<名前>.JP と短いドメイン名
日本語を使ってドメイン名が登録できる。
ドメイン名の移転(登録名義の変更)ができる。
広島大学集中講義
51
ICANN etc.
„
„
ICANN: Internet Corporation for Assigned Names
and Numbers
Registry
‰
„
Registrar
‰
„
.org, .net, .com: VeriSign, Inc.
ICANN accredited registrars
JP
‰
株式会社日本レジストリサービス
„
2002/5/29
かつてはJPNICだったが、2002.4.1より移管
広島大学集中講義
52
多言語ドメイン名
„
iDN: “Internationalized Domain Name”
‰
‰
„
標準化
‰
‰
‰
„
現在英数字と一部の特殊記号しか許されていないドメイン名に、
さまざまな国や地域で日常的に使われている文字を使えるよう
にしようというもの
多言語化されたドメイン名 (Multilingual Domain Name) とも
Multilingual Internet Names Consortium
IETF idn WG
日本語implementation
IEの機能を使った先行利用
‰
‰
‰
2002/5/29
アドレスバーに「日本語.jp」と入力
DNSとは独立のデータベースにより接続
RealNames社のサービス終了により停止(2002.5/e)
広島大学集中講義
53
DNS ネームサーバ
集中データベースではなぜ
いけないか
„ single point of failure
„
„
„
分割して統治せよ
ローカルネームサーバ:
„
‰
近くのネームサーバ（同じ大
学、学部、研究室...）
ホストはまずローカルネー
ムサーバに「聞きに行く」
大量のトラフィック
‰
データベースが遠くにある
メンテナンス不可能
authoritative ネームサーバ:
‰
スケールしない！
データベースを持つ
„
„
‰
2002/5/29
広島大学集中講義
IPアドレスと名前
そのほかの情報
アドレス解決の機能を持つ
54
DNS: ルートネームサーバ
„
„
„
ネームサーバの木の根
元(root)
役割
‰ local name server や
host からの問い合わ
せに対し、
authoritative name
server を返事する
A–M
‰
2002/5/29
M は日本にある
広島大学集中講義
55
簡単な例
root name server
host surf.eurecom.fr が
gaia.cs.umass.edu の
IPアドレスを知りたい
2
4
5
1. local DNS server,
dns.eurecom.frに問い合
local name server
わせ
dns.eurecom.fr
2. dns.eurecom.fr は root
1
name server に問い合わせ
6
3. root name server は
authoritative name server
dns.umass.edu に問い合requesting host
surf.eurecom.fr
わせ
2002/5/29
広島大学集中講義
3
authorititive name server
dns.umass.edu
gaia.cs.umass.edu
56
DNSの例
root name server
ルートネームサーバ
は
„
„
authoratiative name
serverのデータを持っ
ていないかもしれない
authoritative name
serverのデータを持っ
ている、途中のネーム
サーバのデータを持っ
ているかもしれない
（そうでないと動かな
い！）
6
2
7
local name server
dns.eurecom.fr
1
8
requesting host
3
intermediate name server
dns.umass.edu
4
5
authoritative name server
dns.cs.umass.edu
surf.eurecom.fr
gaia.cs.umass.edu
2002/5/29
広島大学集中講義
57
DNS: 問い合わせ2態
root name server
recursive query:
„
„
問い合わせを受けた
ネームサーバの負荷
が高い
root server どうする？
iterated query:
„
„
別の、より適切なネー
ムサーバを回答
“I don’t know this
name, but ask this
server”
iterated query
2
3
4
7
local name server
dns.eurecom.fr
1
8
requesting host
intermediate name server
dns.umass.edu
5
6
authoritative name server
dns.cs.umass.edu
surf.eurecom.fr
gaia.cs.umass.edu
2002/5/29
広島大学集中講義
58
DNS: キャッシュ
„
ネームサーバ（どれも）は、アドレス／名前の解決
を行った後、そのデータをキャッシュしておく
‰ キャッシュは一定時間の後消去される(expire)
‰ “authoritative” でない回答になる
2002/5/29
広島大学集中講義
59
DNS レコード
データベースの中身：resource records (RR)
RR format: (name,
„
Type=A
‰
‰
„
value, type,ttl)
„
Type=CNAME
name ：ホスト名
value：IPアドレス
‰
‰
Type=NS
‰
‰
2002/5/29
name：ドメイン
value：そのドメインの
authoritative name
serverのIPアドレス
„
name：ホスト名（「別名」）
value：ホスト名（「本名」
(cannonical name)
Type=MX
広島大学集中講義
‰
value：メールサーバのホス
ト名
60
DNS プロトコル
DNS プロトコル: query と reply メッセージからなる
‰
フォーマットは同じ
メッセージヘッダ
„
„
identification: 16 ビット、
query と reply は同じ番号
flags:
‰ query/reply
‰ recursion desired
‰ recursion available
‰ reply is authoritative
2002/5/29
広島大学集中講義
61
参考文献
„
RFC
‰ TCP
„
„
„
„
„
‰
UDP
„
‰
RFC768, “User Datagram Protocol”, 1980.
DNS
„
„
„
RFC793, “Transmission Control Protocol”, 1981.
RFC1122 , “Requirements for Internet Hosts --- Communication
Layers”, 1989.
RFC1323 , “TCP Extensions for High Performance”, 1992.
RFC2018 , “TCP Selective Acknowledgment Options”, 1996.
RFC2581 , “TCP Congestion Control”, 1999.
RFC1034, “Domain Names --- Concepts and Facilities”, 1987.
RFC1035, “Domain Names --- Implementation and Specification”,
1987.
その他
‰ 昨日の参考文献
2002/5/29
広島大学集中講義
62