集中講義 インターネットテクノロジー 第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
© Copyright 2024 Paperzz
