インターネットの仕組み

enPiT資料 インターネットの仕組み 2021-02-12 佐々木 健

この文書について ● ● enPiTの講義資料です インターネットの仕組みについてわかった気分に なって欲しい、という気持ちで書きました 2

目次 ● インターネットって何だろう？ ● Webアクセスの裏側を覗いてみよう ● 通信の約束事、プロトコル ● 偉大な発明、パケット通信 ● 世界にたった1つだけの、IPアドレス ● 世界に1つだけじゃないアドレス、NAT ● 宛先を見て適切に処理、ルーティング ● 分解合体再送信、通信を調整する、TCP ● わかりやすい名前を付ける、DNS ● インターネットの約束事、RFC ● 最古のインターネット、電子メール ● 悪意に弱いインターネット ● 縁の下を支える、運用監視 ● まとめ 3

インターネットって何だろう？ 4

インターネット使ってますか？ ● みんな使ってるよね ● 動画見てるよね ● メッセンジャーアプリ使ってるよね ● コロナの影響で講義もインターネットを使ったり ● 何かあったらウェブサイトを見るよね 5

ところでインターネットって何？ ● ウェブサイトを見る仕組み？ ● 動画配信の基盤？ ● メッセンジャーの裏側で動いてるもの？ ● Wi-Fiに接続すると使えるネットワーク？ ● プロバイダと契約すると使えるもの？ ● ？？？ 6

Wikipediaを見てみよう ● https://ja.wikipedia.org/wiki/インターネット インターネットとは、インターネット・プロトコル・スイートを使用し、複 数のコンピュータネットワークを相互接続した、地球規模の情報通信網 のことである。省略してネットとも呼ばれる。 … (以下とても長い読んでも良くわからない説明) (2021-02-01時点で、42,117バイト) ● ● ● ● 世界中の機器が接続された巨大なネットワークなのか わりと長い歴史があるな いろいろな人や組織が関わってるんだな 良くわからない単語が沢山出てくるな 7

• https://ja.wikipedia.org/wiki/インターネット

構成要素について考えてみよう ● インターネットに接続されるのは計算機 ● 計算機の基本的な動作は ● 何かを入力すると ● 決まった処理を行なって ● 何かを出力する 入力 処理 出力 8

計算機同士を接続してみる ● いろいろ複雑なことができるようになる 9

インターネットってこんなもの？ ● ● ● 沢山の計算機が世界規模で接続された巨大シ ステム 規模がどんどん大きくなったら、いろいろなこと ができるようになった!!! 次セクションで沢山接続してることを実感してみ よう 10

Webアクセスの裏側を覗いてみよう 11

Webアクセスしてみよう ● パソコンからウェブサイトにアクセスしてみる ＵＲＬ入力 画面出力 12

Webアクセスの裏側 ● 裏側は沢山の通信が行なわれている DNS ルートサーバ DNS コンテンツサーバ DNS コンテンツサーバ DNS キャッシュサーバ データベース ウェブサーバ ウェブサーバ 13

実際の通信の中身を覗き見 ● 最近のブラウザには通信の状態を確認するため の機能が付いているのでそれを使ってみる。 ● Google Chrome を起動、F12を押す 14

F12を押すとこうなる Developer Tools(DevTools) 15

Elements ページデータ(HTML)の確認 16

Network: 通信の確認 17

enpit.jpを見てみよう URLを入力 18

どどどっと出力される!! 19

Webページの表示の仕方 ● ● ● ブラウザからウェブサーバにHTMLを取りにいく 取ってきたHTML情報を元に、さらに必要なデー タをウェブサーバに取りにいく 取ってきたデータを全部組み合わせて表示する 1ページを表示するだけでも、 沢山の通信が行なわれている 20

表示エリアの見方1 全ての通信の時間を図示 上から順番に通信が実行されている 横軸は時間 並列で複数の通信がされているのもわかる 21

表示エリアの見方2 1つ1つのウェブの構成要素毎の通信の内容を羅列 上から順番に通信を行なっている 通信データ要素、応答ステータス、ファイル種別、時 間、等のデータを記載 各項目をクリックすると詳細データが確認できる 22

Web通信プロトコル、HTTP ● Hypertext Transfer Protocol こういう情報ください こういう情報あげるよ 23

Web通信プロトコル、HTTPの概要 Request URL Request Header こういう情報ください こういう情報あげるよ Respons Header + データ本体 24

Request/Response を確認 DevToolsで 要素を選択して Headersを押す 25

どのぐらい時間がかかっているか Timingを押せば 通信時間がわかる 26

ゴチャゴチャしてきたら Clearすればスッキリします 27

Web通信プロトコルの階層構造 HTTP/1 HTTP/2 TLS QUIC TCP UDP IPv4/ IPv6 Chrome DevToolsで確認できるのは HTTP部分 28

通信の約束事 プロトコル 29

そもそも通信とは何か？ ● オブジェクトとオブジェクトが協調動作を行なうための 手段 ● 情報をやりとりする ● なにかを媒体としてやりとりする ● なんらかの目的があって行なわれる ● 決まった手順、約束事に従って行なわれる 30

そもそも通信とは何か？ ● オブジェクトとオブジェクトが協調動作を行なうための 手段 ● 情報をやりとりする ● なにかを媒体としてやりとりする ● なんらかの目的があって行なわれる ● 決まった手順、約束事に従って行なわれる プロトコル 31

(例)ハンバーガーを買いに行こう!! いらっしゃいませ ご注文は何になさいますか？ ビッグマックセットで お飲み物は何になさいますか？ オレンジジュース 600円にいただきます。 スイカで払います ありがとうございました 32

(例)ハンバーガーを買いに行こう!! 目的: ハンバーガーや飲み物を買いたい、売りたい やりとりするもの: 買うもの、値段 媒体: 日本語、音声、空気 手順、約束事: 接客マニュアル、商品メニュー、 日本円決済、電子決済 33

通信条件が合わないと通信できない いらっしゃいませ ご注文は何になさいますか？ (私、セルクナム族!!) (日本語良くわからない!!) .......... 34

プロトコルの階層構造 ハンバーガーの注文 日本の社会常識 日本語 通信を正しく行なうためには、 その通信を支えるプロトコルを お互いに理解している必要がある 35

ウェブ通信プロトコルの階層構造 HTTP/1 HTTP/2 TLS QUIC TCP UDP IPv4/ IPv6 Chrome DevToolsで確認したのはHTTP部分 その土台として、IP等のプロトコルが存在する 36

IP: Internet Protocol HTTP/1 HTTP/2 TLS QUIC TCP UDP IPv4/ IPv6 この部分が 現在のインターネットの基盤となっている パケット通信、という通信方式が使われている 37

偉大な発明 パケット通信 38

パケット通信とは何か？ 郵便でデータを運ぶイメージ 封筒には、 宛先、差出元が書いてある 39

配送方法1(直接渡す) お互いが近くにいて顔もわかる場合 差出人が相手に直接手渡し 40

配送方法2(書類置き場の活用) ちょっとオフィスが大きくなって顔がわからない場合等 書類置き場に入れる 書類置き場をチェック 自分宛のものがあったら受けとる 41

配送方法3(配達人が頑張る) さらにオフィスが大きくなって専門の人を雇ってみたり 書類置き場に入れる 書類置き場を配達人がチェック 宛先まで届ける 42

配送方法4(配達先が増えた場合) さらにオフィスが大きくなってフロアが増えた!! 近くの書類置き場に入れる 宛先に届ける 宛先に近い書類置き場に転送 43

配送方法5(外の人にも配達したい) 郵便の活用 ポストに投函 宛先に届ける 44

配送方法6(遠くに届けたい) 県をまたいだ配送 トラック輸送 ポストに投函 45

配送方法7(海外に届けたい) 飛行機便を利用 飛行機便 ポストに投函 46

共通なこと1 宛先、差出元 を書いてどこかに送る 47

共通なこと2 宛先を見て 適切に処理する 48

その結果 届く!! 49

インターネットの基本アイディア ● データをパケット通信で送る ● パケットには宛先と差出元を書いておく ● ● パケットを受けとった人は各自が適切に判断して 処理をする 宛先、差出元はユニーク(世界でひとつだけ) 50

何が革新的だったのか？ ● 通信は、通信回線(サーキット)を用意して、そこを占有してや りとりするのが普通だった – ● その場合、通信回線、データ、の両方をきちんとケアする必 要がある – ● 銅線が切れると通信が切れちゃう!! パケット通信では、データにヘッダを付けて送るだけでOK、 シンプルで簡単 – ● 銅線ケーブルを拠点間でひっぱって電話をするイメージ データにヘッダを付けて送るというアイディアはインターネットの他の 技術でも頻繁に出てくる 回線も占有する必要がない、共有が可能 51

世界にたった1つだけの IPアドレス 52

再掲:インターネットの基本アイディア ● データをパケット通信で送る ● パケットには宛先と差出元を書いておく ● ● パケットを受けとった人は各自が適切に判断して 処理をする 宛先、差出元はユニーク(世界でひとつだけ) 53

同じアドレスの人が沢山いたら？ 「千代田１番」です! 「千代田１番」です! 「千代田１番」に送付 「千代田１番」です! 「千代田１番」です! 「千代田１番」です! どこに届ければ良いの？？ 54

世界で1つだけのアドレスを振る ● 32bitのアドレスを割りあてる ● 数字とドットの組合せて表記 ● – 8bitで4つに区切る – 区切った部分を10進数に直す – ドットで区切る 例 – 198.51.100.5 – 203.0.113.8 55

32bitでは足りるの？ ● IPアドレスは32bitで、アドレス総数は2の32乗 個、つまり約43億個 ● 世界の人口は78億人(2020年) ● あれ？足りない？？ 56

128bitに増やしてみた(IPv6) ● 32bitじゃ足りなかったら、128bitに増やそう!! – 32bit → 約43億 = 4.3×10^9個 – 128bit → 約340澗 = 3.4×10^38個 ● ● ● めちゃくちゃ多い、これで大丈夫だ!! 16進数とコロンを組合せて表記 – 32bitで4つに区切る – 区切った部分を16進数で表記 – コロンで区切る – ゼロになる部分は省略できる 例 – 2001:db8::11:1 – 2001:db8:: 57

IPv6の歴史 ● ● IPv6の最初の仕様が作られたのは1995年 – v は version – 最近ようやくIPv6の通信が増えてきた – でも四半世紀経過してもIPv4との併用は続いている IPv6がなかなか流行らなかった理由 – IPv6とIPv4は互換性がなかった – アドレス不足に対する延命技術の登場 58

IPv4アドレスの定義 RFC:791 INTERNET PROTOCOL 0 ※RFCについては後で説明しますね 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address 差出元 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding 宛先 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Example Internet Datagram Header 59

IPv6アドレスの定義: RFC:8200 Internet Protocol, Version 6 (IPv6) Specification 3. IPv6 Header Format +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Traffic Class | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | Next Header | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Address + | | + + | | 差出元 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address 宛先 + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 60

世界に1つだけじゃないアドレス NAT 61

あなたの家の中のIPアドレスは？ ● ● 以下のようなアドレスを使ってるはず – 192.168.xx.xx – 172.16〜172.31.xx.xx – 10.xx.xx.xx 家のアドレスは世界に1つだけじゃないのでは？ 62

プライベートIPアドレス ● プライベートネットワーク（外部から利用できな い社内LANなど）のアドレスとして使うことがで きる。 – 10.0.0.0〜10.255.255.255 – 172.16.0.0〜172.31.255.255 – 192.168.0.0〜192.168.255.255 63

NATの考え方 ● ● ● 自分達の組織の中はプライベートアドレスを使 う。 外と通信するときだけグローバルアドレス(ユ ニークに割り当てられたIPアドレス)を使う。 プライベートネットワークとグローバルネットワー クの繋ぎ目にはルータを配置し、そこでアドレス の変換を行なう。 64

良くある構成 クライアントPC IPアドレス 192.168.0.10 ルータ IPアドレス IPアドレス 192.168.0.1 198.51.100.1 ウェブサーバ IPアドレス 203.0.113.1 ​※ルータは複数のIPアドレスを持っている プライベートアドレス グローバルアドレス ​クライアントPCからウェブサーバへの通信を考える 65

具体的なパケットのイメージ 送信元IPアドレス src IP 宛先IPアドレス dest IP データ 66

1.クライアントPCから送信 192.168.0.10 203.0.113.1 data IPアドレス 192.168.0.10 IPアドレス IPアドレス 192.168.0.1 198.51.100.1 IPアドレス 203.0.113.1 67

2.ルータが変換テーブルを作成 192.168.0.10 203.0.113.1 data IPアドレス 192.168.0.10 IPアドレス IPアドレス 192.168.0.1 198.51.100.1 192.168.0.10 IPアドレス 203.0.113.1 203.0.113.1 変換テーブルに追加される 68

3.ルータがsrcアドレスを変換、送信 192.51.100.1 203.0.113.1 data IPアドレス 192.168.0.10 IPアドレス IPアドレス 192.168.0.1 198.51.100.1 192.168.0.10 IPアドレス 203.0.113.1 203.0.113.1 69

4.サーバから返信(送信) srcとdstが逆になる 203.0.113.1 192.51.100.1 data IPアドレス 192.168.0.10 IPアドレス IPアドレス 192.168.0.1 198.51.100.1 192.168.0.10 IPアドレス 203.0.113.1 203.0.113.1 70

5.変換テーブルと付き合わせ 203.0.113.1 192.51.100.1 data IPアドレス 192.168.0.10 IPアドレス IPアドレス 192.168.0.1 198.51.100.1 192.168.0.xx xx.xx.xx.xx 192.168.0.10 203.0.113.1 192.168.0.xx xx.xx.xx.xx IPアドレス 203.0.113.1 71

6.ルータがdstアドレスを変更、送信 203.0.113.1 192.168.0.10 data IPアドレス 192.168.0.10 IPアドレス IPアドレス 192.168.0.1 198.51.100.1 192.168.0.10 IPアドレス 203.0.113.1 203.0.113.1 72

6.ルータがdstアドレスを変更、送信 203.0.113.1 192.168.0.10 data IPアドレス 192.168.0.10 IPアドレス IPアドレス 192.168.0.1 198.51.100.1 192.168.0.10 IPアドレス 203.0.113.1 203.0.113.1 73

(注意)今使われてるのはNAPT ● ● ● この資料で説明した、IPアドレスだけを変換す る、原始的なNAT(Network Address Translation)は現在はほとんど使われていない。 IPアドレスに加えて、ポート番号の変換も行な う、NAPT(Network Address Port Transation) を使うのが今は普通。現在はNATという用語を 使っていてもNAPTのことを指すことが多い。 ポート番号についてはこの後で説明します。 74

NAT(NAPT)によるIPv4の延命 ● ● IPアドレスが足りない!!、と思われていた が、NATを利用することで、ユニーク性が必要な IPアドレスの量が大幅に削減された。 IPv6に無理に移行しなくても良くなった。 – IPv6はIPv4と互換性がなく、移行は大変。 – とはいえ、最近はIPv6もかなり使われるようになっ てきている。 75

宛先を見て適切に処理 ルーティング 76

パケットはどうやって届けられる？ 宛先、差出元 を書いて送る 届く!! 宛先を見て 適切に処理する 適切って何？？ 77

パケットは誰に渡すのか？ 最寄りの郵便局に渡すイメージ 宛先 郵便局は、 、を見て その宛先を知ってる郵便局に渡す ルータ 適切な隣の郵便局に渡すのが ルーティング 郵便局に相当するものが 78

郵便局が宛先を知らなかったら？ 宛先 郵便局が、 、を見て その宛先を渡す先を知らなかったら？ 容赦なく捨てられる!!! 79

届けてもらうためには (1) 届けてもらいたい人が自分の存在を アピールする必要がある A宛はここだよ!!! ※存在アピール＝経路広報 主に使われるプロトコルはBGP Aさん 80

届けてもらうためには (2) 郵便局が自分が配達するお客さんを 周囲の郵便局にアピールする必要がある Aさん宛は X局に届けてね!!! Aさん X局 ※存在アピール＝経路広報 主に使われるプロトコルはBGP 81

これで無事に届く 宛先 郵便局は、 、を見て その宛先を知ってる郵便局に渡す Aさん宛はX局に 渡せば良いんだな!!! Aさん宛は 直接配送か!!! 82

インターネットが発展 郵便局が増殖!! Aさん宛は X局に届けてね!!! X局 ※経路広報の数が増えてくる ※全部直接連絡するのは大変 83

バケツリレーすれば大丈夫 Aさん宛は Z局 Z局に届けてね Aさん宛は Y局に届けてね Y局 Aさん宛は X局に届けてね X局 84

経路が複数ある場合は？ どっちに投げても届きそう 下のほうが近いかな？ ここがどの配送経路を 選ぶか判断する 85

さらにインターネットが発展 ● インターネットに接続するユーザ数が激増 ● ルータ(郵便局)の数も激増 ● たくさん繋がってるところが力を持つ 86

階層化されるインターネットの構造 だんだんとこんな感じに接続が まとまってきた 87

お金の流れ インターネットのビジネス化 繋げてあげるから お金払ってね!! 88

インターネットへの接続方法の変化 ● ● ● 最初期の頃は自力で接続をする必要があった – アドレスを取得して – 接続する相手を見つけて接続して – 経路を広報 インターネットに接続するサービスが誕生し、そこ と接続すれば、面倒なことをしなくてもインター ネットに接続できるようになった それでも裏側の仕組みはそれほど変わっていな い。 89

分解合体再送信 通信を調整するTCP 90

再掲:インターネットの基本アイディア ● データをパケット通信で送る ● パケットには宛先と差出元を書いておく ● ● パケットを受けとった人は各自が適切に判断して 処理をする 宛先、差出元はユニーク(世界でひとつだけ) 91

疑問 ● この仕組みで双方向通信とか本当にできるの？ ● 大きいデータはどうやって運ぶの？ ● パケットが届かなかったらどうするの？ ● いろいろな通信が混ざってしまったりしないの？ 92

(再掲)ウェブ通信で使うプロトコル すでに説明したところ HTTP/1 HTTP/2 TLS QUIC TCP UDP IPv4/ IPv6 これから説明するところ Transmission Contorol Protocol 93

再掲:(注意)今使われてるのはNAPT ● ● この資料で説明した、IPアドレスだけを変換す る、原始的なNAT(Network Address Translation)は現在はほとんど使われていない。 IPアドレスに加えて、ポート番号の変換も行な う、NAPT(Network Address Port Transation) を使うのが今は普通。現在はNATという用語を 使っていてもNAPTのことを指すことが多い。 これについても説明します 94

実現したいこと ● 相手との通信の確立、切断 ● 双方向通信、同時通信 ● 高信頼性、安定性 95

パケット通信(IP)でどう実現するか？ ● 相手との通信の確立 ● 双方向通信、同時通信 ● 高信頼性、安定性 意外とむずかしい それを実現するのがTCP 96

実現する仕掛け ● ポート番号 ● 3way hand shake ● シーケンス番号 ● フロー制御、輻輳制御 ● チェックサム 97

実現する仕掛け ● ポート番号 ● 3way hand shake ● シーケンス番号 ● フロー制御、輻輳制御 ● チェックサム 98

ポート番号 ● マンションの宅配ボックス、のイメージ ● 利用したいときに使う ● あらかじめ番号がふられている(0〜65535) 99

ポートを使った通信のイメージ ● ポートとポートを繋いで通信する ● 1拠点から複数の接続ができる ● 元ポート番号と宛先ポート番号を決めて通信をする。 ● 片側が1つで宛先が複数という接続もある。 100

ポート番号の使いわけ ● 3種類定義されている ● でも強制力はない。最近はわりと自由に使われている。 – Linuxでは、32768番以降を動的に割り当てている。 種類 範囲 内容 WELL KNOWN PORT NUNBERS 0番〜1023番 一般的なポート番号 UNIX系OSでは利用するためにはroot 権限が必要 REGISTERED PORT NUMBERS 1024番〜49151番 登録済みポート番号 DYNAMIC AND/OR PRIVATE PORTS 49152番〜65535番 自由に使用できるポート番号 101

WELL KNOWN PORT NUNBERS ● ● ● IANA(Internet Assigned Numbers Authority)が管理してい る。 UNIX系OSでは /etc/services というファイルに記述されてい る。 一般的に良く使われるポート番号 – TCP/22: SSH (リモート接続) – TCP/25: SMTP (メール送信) – TCP/80: HTTP (ウェブアクセス) – UDP/123: NTP (時刻同期) – TCP/443: HTTPS (セキュアなウェブアクセス) 102

実現する仕掛け ● ポート番号 ● 3way hand shake ● シーケンス番号 ● フロー制御、輻輳制御 ● チェックサム 103

3way hand shake ● 通信を開始するための儀式 SYN データ送っていい？ SYN+ACK OK〜 そっちからも届いた 通信開始するね ACK 104

通信の前にやらなきゃいけないこと ● 受け側は、受ける口(ポート)を作る – ● Listen 送る側は、送る口(ポート)を作る – Connect 105

接続時の状態遷移 ● Wikipediaから引用 – Wikimedia:File:Tcp start.svg 106

切断時の遷移図 ● Wikipediaから引用 – Wikimedia:File:Tcp end.svg 107

実現する仕掛け ● ポート番号 ● 3way hand shake ● シーケンス番号 ● フロー制御、輻輳制御 ● チェックサム 108

大きいデータはどうやって送るか ● 送る前に分割 ● 分割したものをパケットで送る ● 届いたものを組み立てる 109

分解するときに番号を振る 分割 採番 106 105 104 103 102 101 110

番号順に組み立てる 106 105 104 103 102 101 組立 111

もし途中が抜けていたら 106 105 103 102 101 104番が届いてないから 送り直してー 104番送るねー 112

実現する仕掛け ● ポート番号 ● 3way hand shake ● シーケンス番号 ● フロー制御、輻輳制御 ● チェックサム 113

確認しながらデータを送ると大変 101番送るねー 101番届いたー 102番送るねー 102番届いたー 103番送るねー 103番届いたー 104番送るねー 104番届いたー 114

ある程度まとめて送る 101番送るねー 102番送るねー 103番送るねー 104番送るねー 101〜104番届いたー 115

余裕があるなら沢山送る 101番送るねー ○○番送るねー 102番送るねー ○○番送るねー 103番送るねー ○○番送るねー 104番送るねー ○○番送るねー ○○番送るねー ○○番送るねー ○○番送るねー ○○番送るねー ○○番送るねー ○○番送るねー 全部届いたー 116

余裕がなかったら断わる 101番送るねー ○○番送るねー 102番送るねー ○○番送るねー 103番送るねー ○○番送るねー 104番送るねー ○○番送るねー ○○番送るねー ○○番送るねー ○○番送るねー ○○番送るねー ○○番送るねー ○○番送るねー そんなに送ってこないで!! 117

実現する仕掛け ● ポート番号 ● 3way hand shake ● シーケンス番号 ● フロー制御、輻輳制御 ● チェックサム 118

チェックサム ● ● ● ● 誤り検出のための手法 受けとったデータが壊れていないか判定するために 用いられる 各ワード列毎の総和を取っていき、その下位1ワード 部分を符号として用いるのが一番簡単なチェックサム TCPにおいては、疑似ヘッダを定義し、パディングし た後、全16ビットワードを1の補数表現で加算してい き、その総和をビット毎に反転する – ※興味がある人は調べてくださいね 119

再掲:実現する仕掛け ● ポート番号 ● 3way hand shake ● シーケンス番号 ● フロー制御、輻輳制御 ● チェックサム 120

こんなヘッダとして実装されている 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | RFC793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgment Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data | |U|A|P|R|S|F| | Offset| Reserved |R|C|S|S|Y|I| | |G|K|H|T|N|N| | | Window | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Urgent Pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TCP Header Format 121

各ノードがデータ通信時にやること ● ● データをパケットに分割し、それぞれのパケット にヘッダを付けて送信 パケットを受けとった人はヘッダを見て、適切に 判断して処理をする IPでやっていることと考え方はあまり変わらない。 ルール、仕組み、等の機能はヘッダが受け持つ 122

具体的なパケットのイメージ IPヘッダ TCPヘッダ データ 123

src/dest 情報はどこにあるか src IP IPヘッダ src port dest IP dest port (通信制御用情報) TCPヘッダ データ 124

TCPは複雑なのでは？ ● 実装はわりと大変 ● ちゃんと理解するのもわりと大変 ● 仕様を元に細かい動作を動きを追って いくと良くわからないところも結構出て くる。 – ● 実装依存となるところもある 元の仕様はセキュリティ的に甘いところ もある 125

(再掲)ウェブ通信で使うプロトコル すでに説明したところ HTTP/1 HTTP/2 TLS QUIC TCP UDP IPv4/ IPv6 これから説明するところ 126

UDPがやること ● User Datagram Protocol ● パケットにポート番号を付けるだけ。 ● TCPみたいな複雑な仕組みはない。 127

こんなヘッダとして実装されている 0 7 8 15 16 23 24 31 +--------+--------+--------+--------+ | Source | Destination | | Port | Port | +--------+--------+--------+--------+ | | | Length | RFC768で定義 とても短い文書 | Checksum | +--------+--------+--------+--------+ | | data octets ... +---------------- ... User Datagram Header Format 128

パケット全体イメージ src IP IPヘッダ dest IP src port dest port UDPヘッダ データ 129

(再掲)ウェブ通信で使うプロトコル すでに説明したところ HTTP/1 HTTP/2 TLS QUIC TCP UDP IPv4/ IPv6 これから説明するところ 130

TLS、QUICがやること ● ● TLSは安全に通信をするための仕組みを提供 QUICは今の時代に合ったより高品質な通信を 提供 – ※興味がある人は調べてください 131

(再掲)ウェブ通信で使うプロトコル 全部説明した!!! HTTP/1 HTTP/2 TLS QUIC TCP UDP IPv4/ IPv6 132

わかりやすい名前を付ける DNS 133

再掲:enpit.jpを見てみよう URLを入力 IPアドレスを入れてないよね？ 134

DNS ● ● Domain Name System ホスト名やドメイン名をIPアドレスに変換する 分散データベースシステム 135

再掲:enpit.jpを見てみよう URLを入力 DNSでIPアドレスを調べて ● enpit.jp→157.7.107.26 ● 157.7.107.26 にアクセス ● 136

再掲:Webアクセスの裏側 ● 裏側は沢山の通信が行なわれている DNS ルートサーバ DNS コンテンツサーバ DNS キャッシュサーバ DNS コンテンツサーバ 分散データベース データベース ウェブサーバ ウェブサーバ 137

DNSの3種類の構成要素 ● ● ● 情報が欲しい人→スタブリゾルバー 情報が欲しい人からの依頼を受けて情報を渡し たり情報を探したりする人→フルリゾルバー 情報を提供する人→権威サーバ 138

3種類の構成要素の場所 DNS ルートサーバ DNS コンテンツサーバ フルリゾルバー DNS キャッシュサーバ DNS コンテンツサーバ スタブリゾルバー 権威サーバ 139

実際の動き1 フルリゾルバーが情報を知ってるとき ● 知っていればその情報を教える DNS ルートサーバ DNS コンテンツサーバ A DNS コンテンツサーバ 2. 203.0.113.5 だよ DNS コンテンツサーバ B 1. a.example.jpのIPアドレスを教えてください 140

実際の動き2 フルリゾルバーが情報を知らないとき ● 知らなければルートサーバから順番辿って調べる 2. a.example.jpのIPアドレスを教えてください DNS ルートサーバ 3. jpのゾーンは、Aが知ってるよ 4. a.example.jpのIPアドレスを教えてください DNS コンテンツサーバ A DNS コンテンツサーバ 5. example.jpのゾーンは、Bが知ってるよ 8. 203.0.113.5 だよ 6. a.example.jpのIPアドレスを教えてください DNS コンテンツサーバ B 7. 203.0.113.5 だよ 1. a.example.jpのIPアドレスを教えてください

DNSの凄いところ ● 世界中の沢山のDNSサーバが分散しつつ協調 しながら動いている ● 沢山の人が同時にデータの更新ができる ● 巨大なデータレコードの検索ができる ● 実用的な速度で動く ● 優れた耐障害性 – 設定が正しくなくてもそれっぽく動く 142

DNSのヤバいところ ● ● 便利なので様々な用途に使われまくっている – 乱立するリソースレコード – 何でも登録できてしまうTXTレコード 良くわからない仕様、追加され続ける仕様 – ● 設定ミスの多発 – ● 一見簡単な仕組みのように見えるのに、実際には良くわからない それでもそれっぽく動いてしまう 多発するセキュリティ脆弱性 – 仕様的な問題、実装的な問題 143

インターネットの約束事 RFC 144

再掲:DNSのヤバいところ ● ● 便利なので様々な用途に使われまくっている – 乱立するリソースレコード – 何でも登録できてしまうTXTレコード 良くわからない仕様、追加され続ける仕様 – ● 設定ミスの多発 – ● 一見簡単な仕組みのように見えるのに、実際には良くわからない それでもそれっぽく動いてしまう 多発するセキュリティ脆弱性 – この仕様はどこにある？ 誰が決めてる？ 仕様的な問題、実装的な問題 145

再掲:そもそも通信とは何か？ ● オブジェクトとオブジェクトが協調動作を行なうための 手段 ● 情報をやりとりする ● なにかを媒体としてやりとりする ● なんらかの目的があって行なわれる ● 決まった手順、約束事に従って行なわれる これはどこにある？ 146 誰が決めてる？

再掲:IPv4アドレスの定義 RFC:791 INTERNET PROTOCOL 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 これは何？ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address 差出元 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding 宛先 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Example Internet Datagram Header 147

再掲: IPv6アドレスの定義: RFC:8200 Internet Protocol, Version 6 (IPv6) Specification 3. IPv6 Header Format +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Traffic Class | Flow Label | これは何？ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | Next Header | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Address + | | + + | | 差出元 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address 宛先 + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148

再掲: TCPのヘッダ情報 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | RFC793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgment Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data | |U|A|P|R|S|F| | Offset| Reserved |R|C|S|S|Y|I| | |G|K|H|T|N|N| | | Window | これは何？ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Urgent Pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TCP Header Format 149

再掲:UDPのヘッダ情報 0 7 8 15 16 23 24 31 +--------+--------+--------+--------+ | Source | Destination | | Port | Port | +--------+--------+--------+--------+ | | | Length | とても短い文書 | Checksum | +--------+--------+--------+--------+ | | RFC768で定義 これは何？ data octets ... +---------------- ... User Datagram Header Format 150

RFC って何？ ● ● インターネットで用いられるさまざまな技術の標準化や運用に関す る事項など幅広い情報共有を行うために公開される文書シリーズ インターネット技術の標準化を推進する任意団体であるIETFが管 理している ● 50年近く(1969年〜)維持され続けている歴史書 ● 書かれていること – インターネットの様々な技術的仕様 – インターネットに係わるルール – 良い知識、良い方法 – 遊び心に溢れるジョーク 151

RFC は何の略？ ● Request for Comments（リクエスト フォー コメンツ、略称： RFC） – 直訳すると「求むコメント」 – インターネット技術の研究開発は、 米国国防総省のARPA/DARPAが 資金援助を行い研究開発活動が推進されたために、 研究開発の結果 は、広く公開できないことになっていた – しかし、研究結果を公開し、インターネットに関わる人々に広くその仕 様を流布し 普及させることが重要 – 「コメントを広く募集する」ための、ドキュメント であって、研究成果 を公開しているのではない、むしろ、研究成果をより良いもの にする ために、外部からのコメントを募集するためのドキュメントである、と いうトリック 152

読んでみる https://tools.ietf.org/html/rfc1149 153

• https://tools.ietf.org/html/rfc1149

英語なので翻訳してみる 154

参考:機械翻訳との付き合い方 ● ● 概要、単語を知ることはできる 母国語のほうが斜め読みの速度はあきらかに速 いはず ● ただし昔のRFCは翻訳しにくい ● 最近のRFCはわりと良い翻訳をしてくれる ● ちゃんと理解するには英語で読む必要がある ● うまく付き合いましょう 155

このRFC1149って何？ ● ● ● 1990年のエイプリルフールに発表されたジョーク RFC 伝書鳩を使ったIPのデータ転送を行なう方法 インターネットに関する教養として知っておいて 欲しいRFC 156 Wikimedia:Junge_Frau_mit_Taubenpost.jpg

Errata(修正)があるRFCもある 157

RFC1149のErrata 特別な考慮事項： ミラーとの1回の衝突でそのキャリアが 100％損失するため、ポートミラーを鳥類 キャリアと一緒に使用しないでください。 - 研修員のメモ Windowsとの1回の衝突も同様です。 158

UpdateがあるRFCもある 159

RFC2549 160

RFC6214 161

Joke RFC 一覧 ● 英語版のWikipediaを参照するのが一番簡単 – https://en.wikipedia.org/wiki/April_Fools%27_D ay_Request_for_Comments ● 日本語Wikipediaには残念ながらありません ● 誰か項目を作ってくれればみんな喜ぶと思う 162

• https://en.wikipedia.org/wiki/April_Fools'_Day_Request_for_Comments

ジョークが本当になった例もある Evil Bit ● ● 2003年のRFC3514 – IPv4ヘッダに使われていない領域が1ビットある – このビットに1がセットされていれば、パケットは悪意を持っていると する – 攻撃者がこの悪意のビットを立ててくれれば、安全なシステムは防衛 が可能になる。これで世界に平和が訪れる。すばらしい、実装しな ければいけない。 RFC発表とほぼ同じぐらいのタイミングで、FreeBSDに実装さ れる – ● 他のソフトウェアにも続々と実装されてる もちろん実際には無意味な仕様と実装なんだけど 163

最初に読むべき文書、目次的なもの ● ● ● STD-1 – 標準となっているプロトコル仕様一覧 – https://tools.ietf.org/html/std1 FYI-1 – 標準化が目的でない情報提供が目的の文章一覧 – https://tools.ietf.org/html/fyi1 BCP-1 – Best Current Practice。現時点での最良の実践手法一覧 – https://tools.ietf.org/html/bcp1 164

• https://tools.ietf.org/html/std1
• https://tools.ietf.org/html/fyi1
• https://tools.ietf.org/html/bcp1

標準化は何のため？ ● ● ● ネットワークはお互いが繋がらないと成りたたな い。どうやって繋ぐかを決めておいて、みんなで それを守るほうが良い。 良い方法は共有したい。 機器を導入する側の視点に立つと、標準化され ているものを選択したい。中身もわかるし、なに かあったときに交換可能だから。 – 標準仕様に準拠した製品のほうが競争力が高くな る。 165

微妙な標準化もある ● MessagePackの標準化 – ● 元々の作者じゃない人が標準化提案をしちゃったとい う事案 OpenBSDのTheo de RaadtがIETFに対して激怒 – OpenSSLの脆弱性「Heartbreed」 – 誰からも必要とされない仕様がセキュリティホールの 元になった 166

The Internet is for Everyone ● RFC3217 – ● ● ● ● https://tools.ietf.org/html/rfc3271 2002年にInternet Societyから出された文書 インターネットに関わる人が増えてきて、お金も沢山動く ようになって、インターネットは誰の物か？、という議論 が盛んになったころに出された声明。 RFCを正しく理解するにはContext(文脈)を知っておくほう が良いことが多い。歴史と一緒。 新し目のRFCではContextが省かれていることが多いので 167 行間を想像しつつ読むほうがより面白いよ。

• https://tools.ietf.org/html/rfc3271

最古のインターネット 電子メール 168

電子メール使ってますか？ ● みんな使ってる？ ● いつからあるか知ってる？ ● 電子メールって何？ 169

最初の電子メール ● 最初の電子メールが送受信されたのは1965年 ● メインフレーム(大型計算機)時代 ● 1台のマシンを複数人で使っていた ● 利用者同士でメッセージをやりとりするシステムがあった ● ● ● そのメッセージを他のマシンのユーザーにも送れるように した ARPANET(世界で初めて運用されたパケット通信コン ピュータネットワーク)のスタートは1969年 UNIXの誕生は1970年頃 170

電子メールアドレスの最初の定義 name@host 計算機名 計算機上のユーザー名 区切り文字 171

電子メールのインパクト ● ● ● ● ARPANETが作られた当初は利用する積極的な目的 はなかった 1973年にはARPANETのトラフィックの4分の3が電 子メールのトラフィック 電子メールを使いたい、というのがARPANETへの接 続、インターネットへの接続のモチベーションになっ た インターネットに接続する=電子メールが使える、と いう時期があった 172

再掲:そもそも通信とは何か？ ● オブジェクトとオブジェクトが協調動作を行なうための 手段 ● 情報をやりとりする ● なにかを媒体としてやりとりする ● なんらかの目的があって行なわれる ● 決まった手順、約束事に従って行なわれる 人はコミュニケーションをしたい!!! 173

再掲:電子メール使ってますか？ ● みんな使ってる？ ● いつからあるか知ってる？ ● 電子メールって何？ ぶっちゃけ今はあんまり使ってないよね？ なんでだろう？？ →迷惑メール(SPAM)問題 →もっと便利なツールでやりとり 174

悪意に弱いインターネット 175

「インターネットの精神」的な言葉 ● TCPを定義したRFC793に書いてある言葉 ● ● 2.10. Robustness Principle TCP implementations will follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others. (日本語意訳)己のなすことには慎重たれ、 他人のな すことには寛容たれ インターネットは「善意」で作られている 176

途中に悪意がある人がいると、、、 ● ● ● 途中で盗まれたり 内容を読まれたり 改竄されたり 177

嘘の情報を流す人がいると、、、 ● 他の人宛のパケットを奪いとったりされる A宛はこっちだよ!!! A宛はここだよ!!! Aさん 178

再掲:DNSのヤバいところ ● ● 便利なので様々な用途に使われまくっている – 乱立するリソースレコード – 何でも登録できてしまうTXTレコード 良くわからない仕様、追加され続ける仕様 – ● 設定ミスの多発 – ● 一見簡単な仕組みのように見えるのに、実際には良くわからない それでもそれっぽく動いてしまう 多発するセキュリティ脆弱性 – 悪意ある攻撃に弱い 仕様的な問題、実装的な問題 179

再掲:電子メール使ってますか？ ● みんな使ってる？ ● いつからあるか知ってる？ ● 電子メールって何？ ぶっちゃけ今はあんまり使ってないよね？ なんでだろう？？ →迷惑メール(SPAM)問題 →もっと便利なツールでやりとり 180

公開鍵暗号を使った防御 ● ● ● 公開鍵暗号技術を用いることによりある程度の防御は可 能 公開鍵基盤(PKI)を用いて個々のプロトコルレベルでの 防御技術はある程度確立されている PKIが提供するサービスは以下 ● 守秘性: 特定の相手のみ読めるようにする ● 認証: その人が誰かを証明する ● 完全性: データが変更されてないことを証明する ● 否認防止: ある人が以前行なった行為を証明する 181

具体的な防御技術 ● IP: IPsec ● ルーティング: RPKI ● DNS: DNSSEC ● ウェブ: TLS ● メール: SPF,DMARC,DKIM,TLS ※興味がある人は調べてみてください 182

なくならない攻撃 ● プログラムにはバグがある ● 仕様にもたいていバグがある ● 新しい攻撃手法は次々発見されている ● ● 防御側の対応には時間がかかる どうしても防御できない攻撃もある ● クーデターによる通信断とかは対応不能 183

縁の下を支える 運用監視 184

インターネット接続を守る ● プログラムにはバグがある ● 形あるものはいつかは壊れる ● 悪意ある攻撃もある それでもインターネットを動かし続けたい なにかあったときに対応するために監視しよう 185

良い監視

悪い監視

なぜ良いか ● 目的が明確 ● なにかあったときの対応策がある ● ローコスト

なぜ悪いか ● 目的が不明確(監視が目的になっている) ● なにかあったらひどいことになる ● コストかけすぎ

監視をするときに考えること ● 監視をする目的は何か？ ● その目的を決めるのは誰か？ ● 何を監視する？ ● どうやって監視する？ ● 異常が発生したらどのように対応する？ ● コストはどのぐらいかける？

お金の話 ● リアルな世界で何かをするときには必ずお金の話がつ いて回る – お金の話をごまかす人は、宗教、政治、学術関係者に多 い印象ですが、そういう人には近寄らないほうが多分良い ● インターネットもお金がかかっている ● サービスの利用にもお金がかかる ● 監視を考える場合には、監視対象の価値を考えて、 その価値に見合うコストで監視をする必要がある

ビジネスにおける監視の動機 ● 売ってるものが動いてることを確認したい。 ● 売ってるものの異常は把握したい。 「売ってるもの」に 注目してみる

ハードウェア監視 ● 売ってる人 – ● ● ● ハードウェアメーカー 売ってるもの – 汎用コンピュータ – サーバ – ネットワーク機器 – ストレージ 監視システム例 – ハードウェア監視プログラム – 統合プラットフォーム管理ツール 監視プロトコル、インターフェイス例 – IPMI – SNMP – syslog

設備監視 ● 売ってる人 – ● ● データセンター 売ってるもの – 電気 – セキュリティ 監視方法 – 防災センターによる統合監視 – Network Operation Centerによる統合監視

回線監視 ● 売ってる人 – ● ● ● 電話会社、通信会社 売ってるもの – 電話回線 – 専用線 – イーサネット接続 監視方法 – OSS(Operation Support System ※電話会社用語) – NMS(Network Management System) 監視プロトコル例 – SNMP – syslog – Ether OAM

インターネット接続監視 ● ● ● ● 売ってる人 – ISP – データセンター 売ってるもの – インターネット接続 – 経路情報 監視方法 – NMS(Network Management System) – OpenBMP – Nagios/Zabbix 等の汎用監視ツール 監視プロトコル例 – Ping – BFD – BMP

サーバ監視 ● ● 売ってる人 – ホスティング事業者 – MSP 売ってるもの – ● 監視方法 – ● サーバ(物理、仮想) Nagios/Zabbix 等の汎用監視ツール 監視プロトコル等 – Ping – syslog、サーバログ – HTTP/SMTP/DNS等の汎用プロトコル

サービス監視 ● ● 売ってる人 – コンテンツ事業者 – インターネットでサービスをしている事業者 売ってるもの – ● ● インターネットを使ったサービス 監視方法 – Nagios/Zabbix 等の汎用監視ツール – エージェント型監視ツール – サービスチェックツール 監視プロトコル – HTTP/SMTP/DNS等のインターネットサービスプロトコル – 独自サービスチェックプロトコル – 各種ログ

「売ってるもの」についてまとめ ● ● ● ● 売ってるもの(お金を生み出してるもの)について はちゃんと監視をしておこう ものによって監視方法等は違う 買ってるものについては、売る側のほうで監視し てくれてることも多い 必要だけど不足してるところは自前で頑張る必要 がある

異常が見付かったら ● ● ● ● 売ってる人に直してもらうのが基本 でも自分の責任範囲については自分で直さないとい けない この異常時には、この対処をする、というような手順 をあらかじめ整備しておくと、すみやかに対処が可能 対処記録を残して、ふり返りをする – 次回同じ異常が発生した場合にすみやかに対処ができる – そもそも異常が発生しないような対策も実施できる

最近の監視の方法 ● 取れるデータはとりあえず取っておく ● ツールは簡単に使える新しいものを選定する ● ログはログ収集基盤に飛ばす ● ● ● ダッシュボードを作成し必要な情報にアクセスで きるようにする アラートは必要なものだけ飛ばす 全部自分で作らず、クラウドやSaaSの便利なサー ビスの利用も検討する

まとめ 202

大変なインターネットの運用 ● 沢山の技術要素があってキャッチアップが大変 ● 日進月歩の技術進化 ● 止まられない攻撃 それでもなぜインターネットを使うのか？

再掲:そもそも通信とは何か？ ● オブジェクトとオブジェクトが協調動作を行なうための 手段 ● 情報をやりとりする ● なにかを媒体としてやりとりする ● なんらかの目的があって行なわれる ● 決まった手順、約束事に従って行なわれる 人はコミュニケーションをしたい!!! 204

次のインターネットを作るために ● 今あるインターネットを地道に改良していく – ● 新しい技術(アルゴリズム)を元に新しい基盤を発明 する – ● プロトコルを1つずつ交換していく ブロックチェーンのような技術を使ってインターネットを 再構築する妄想をすると楽しい ネットワークはそれ自体より、それを使って何をす るかが重要 – より良いコミュニケーションができるツールを作ろう

次に何をすれば良いか ● 疑問点等があれば、とりあえず検索してみましょ う ● 良い本を読みましょう ● 仲間を探しましょう ● 楽しみましょう!!!!