インターネットの仕組み enPiT資料
•
0 j'aime•2,098 vues
enPiT向けに作った資料。 学部生を対象としてインターネットについてわかった気分になってもらう目的で書いた。
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à インターネットの仕組み enPiT資料
Similaire à インターネットの仕組み enPiT資料 (20)
Plus de Ken SASAKI
Plus de Ken SASAKI (20)
Dernier
Dernier (8)
インターネットの仕組み enPiT資料
- 19. 19 どどどっと出力される!!
- 29. 29 通信の約束事 プロトコル
- 37. 37 IP: Internet Protocol HTTP/1 TCP UDP この部分が 現在のインターネットの基盤となっている パケット通信、という通信方式が使われている HTTP/2 IPv4/ IPv6 TLS QUIC
- 38. 38 偉大な発明 パケット通信
- 49. 49 その結果 届く!!
- 51. 51 何が革新的だったのか？ ● 通信は、通信回線(サーキット)を用意して、そこを占有してや りとりするのが普通だった – 銅線ケーブルを拠点間でひっぱって電話をするイメージ ● その場合、通信回線、データ、の両方をきちんとケアする必 要がある – 銅線が切れると通信が切れちゃう!! ● パケット通信では、データにヘッダを付けて送るだけでOK、 シンプルで簡単 – データにヘッダを付けて送るというアイディアはインターネットの他の 技術でも頻繁に出てくる ● 回線も占有する必要がない、共有が可能
- 54. 54 同じアドレスの人が沢山いたら？ 「千代田１番」に送付 どこに届ければ良いの？？ 「千代田１番」です! 「千代田１番」です! 「千代田１番」です! 「千代田１番」です! 「千代田１番」です!
- 55. 55 世界で1つだけのアドレスを振る ● 32bitのアドレスを割りあてる ● 数字とドットの組合せて表記 – 8bitで4つに区切る – 区切った部分を10進数に直す – ドットで区切る ● 例 – 198.51.100.5 – 203.0.113.8
- 57. 57 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::
- 58. 58 IPv6の歴史 ● IPv6の最初の仕様が作られたのは1995年 – v は version – 最近ようやくIPv6の通信が増えてきた – でも四半世紀経過してもIPv4との併用は続いている ● IPv6がなかなか流行らなかった理由 – IPv6とIPv4は互換性がなかった – アドレス不足に対する延命技術の登場
- 59. 59 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 差出元 宛先 ※RFCについては後で説明しますね
- 60. 60 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 + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 差出元 宛先
- 62. 62 あなたの家の中のIPアドレスは？ ● 以下のようなアドレスを使ってるはず – 192.168.xx.xx – 172.16〜20.xx.xx – 10.xx.xx.xx ● 家のアドレスは世界に1つだけじゃないのでは？
- 63. 63 プライベート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
- 74. 74 (注意)今使われてるのはNAPT ● この資料で説明した、IPアドレスだけを変換す る、原始的なNAT(Network Address Translation)は現在はほとんど使われていない。 ● IPアドレスに加えて、ポート番号の変換も行な う、NAPT(Network Address Port Transation) を使うのが今は普通。現在はNATという用語を 使っていてもNAPTのことを指すことが多い。 ● ポート番号についてはこの後で説明します。
- 89. 89 インターネットへの接続方法の変化 ● 最初期の頃は自力で接続をする必要があった – アドレスを取得して – 接続する相手を見つけて接続して – 経路を広報 ● インターネットに接続するサービスが誕生し、そこ と接続すれば、面倒なことをしなくてもインター ネットに接続できるようになった ● それでも裏側の仕組みはそれほど変わっていな い。
- 93. 93 (再掲)ウェブ通信で使うプロトコル HTTP/1 TCP UDP HTTP/2 IPv4/ IPv6 TLS QUIC すでに説明したところ これから説明するところ Transmission Contorol Protocol
- 94. 94 再掲:(注意)今使われてるのはNAPT ● この資料で説明した、IPアドレスだけを変換す る、原始的なNAT(Network Address Translation)は現在はほとんど使われていない。 ● IPアドレスに加えて、ポート番号の変換も行な う、NAPT(Network Address Port Transation) を使うのが今は普通。現在はNATという用語を 使っていてもNAPTのことを指すことが多い。 これについても説明します
- 101. 101 ポート番号の使いわけ ● 3種類定義されている ● でも強制力はない。最近はわりと自由に使われている。 – Linuxでは、32768番以降を動的に割り当てている。 種類 範囲 内容 WELL KNOWN PORT NUNBERS 0番〜1023番 一般的なポート番号 UNIX系OSでは利用するためにはroot 権限が必要 REGISTERED PORT NUMBERS 1024番〜49151番 登録済みポート番号 DYNAMIC AND/OR PRIVATE PORTS 49152番〜65535番 自由に使用できるポート番号
- 102. 102 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 (セキュアなウェブアクセス)
- 110. 110 分解するときに番号を振る 分割 採番 106 105 104 103 102 101
- 111. 111 番号順に組み立てる 組立 106 105 104 103 102 101
- 112. 112 もし途中が抜けていたら 106 105 103 102 101 104番が届いてないから 送り直してー 104番送るねー
- 121. 121 こんなヘッダとして実装されている 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgment Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data | |U|A|P|R|S|F| | | Offset| Reserved |R|C|S|S|Y|I| Window | | | |G|K|H|T|N|N| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Urgent Pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TCP Header Format RFC793
- 124. 124 src/dest 情報はどこにあるか (通信制御用情報) TCPヘッダ データ IPヘッダ src IP dest IP src port dest port
- 128. 128 こんなヘッダとして実装されている 0 7 8 15 16 23 24 31 +--------+--------+--------+--------+ | Source | Destination | | Port | Port | +--------+--------+--------+--------+ | | | | Length | Checksum | +--------+--------+--------+--------+ | | data octets ... +---------------- ... User Datagram Header Format RFC768で定義 とても短い文書
- 129. 129 パケット全体イメージ UDPヘッダ データ IPヘッダ src IP dest IP src port dest port
- 133. 133 わかりやすい名前を付ける DNS
- 138. 138 DNSの3種類の構成要素 ● 情報が欲しい人→スタブリゾルバー ● 情報が欲しい人からの依頼を受けて情報を渡し たり情報を探したりする人→フルリゾルバー ● 情報を提供する人→権威サーバ
- 140. 140 実際の動き1 フルリゾルバーが情報を知ってるとき DNS ルートサーバ DNS コンテンツサーバ A DNS コンテンツサーバ DNS コンテンツサーバ B 1. a.example.jpのIPアドレスを教えてください 2. 203.0.113.5 だよ ● 知っていればその情報を教える
- 141. 実際の動き2 フルリゾルバーが情報を知らないとき DNS ルートサーバ DNS コンテンツサーバ A DNS コンテンツサーバ DNS コンテンツサーバ B 1. a.example.jpのIPアドレスを教えてください 8. 203.0.113.5 だよ ● 知らなければルートサーバから順番辿って調べる 2. a.example.jpのIPアドレスを教えてください 3. jpのゾーンは、Aが知ってるよ 4. a.example.jpのIPアドレスを教えてください 2. a.example.jpのIPアドレスを教えてください 6. a.example.jpのIPアドレスを教えてください 5. example.jpのゾーンは、Bが知ってるよ 7. 203.0.113.5 だよ
- 143. 143 DNSのヤバいところ ● 便利なので様々な用途に使われまくっている – 乱立するリソースレコード – 何でも登録できてしまうTXTレコード ● 良くわからない仕様、追加され続ける仕様 – 一見簡単な仕組みのように見えるのに、実際には良くわからない ● 設定ミスの多発 – それでもそれっぽく動いてしまう ● 多発するセキュリティ脆弱性 – 仕様的な問題、実装的な問題
- 144. 144 インターネットの約束事 RFC
- 145. 145 再掲:DNSのヤバいところ ● 便利なので様々な用途に使われまくっている – 乱立するリソースレコード – 何でも登録できてしまうTXTレコード ● 良くわからない仕様、追加され続ける仕様 – 一見簡単な仕組みのように見えるのに、実際には良くわからない ● 設定ミスの多発 – それでもそれっぽく動いてしまう ● 多発するセキュリティ脆弱性 – 仕様的な問題、実装的な問題 この仕様はどこにある？ 誰が決めてる？
- 147. 147 再掲: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 差出元 宛先 これは何？
- 148. 148 再掲: 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 + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 差出元 宛先 これは何？
- 149. 149 再掲: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgment Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data | |U|A|P|R|S|F| | | Offset| Reserved |R|C|S|S|Y|I| Window | | | |G|K|H|T|N|N| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Urgent Pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TCP Header Format RFC793 これは何？
- 150. 150 再掲:UDPのヘッダ情報 0 7 8 15 16 23 24 31 +--------+--------+--------+--------+ | Source | Destination | | Port | Port | +--------+--------+--------+--------+ | | | | Length | Checksum | +--------+--------+--------+--------+ | | data octets ... +---------------- ... User Datagram Header Format RFC768で定義 とても短い文書 これは何？
- 151. 151 RFC って何？ ● インターネットで用いられるさまざまな技術の標準化や運用に関す る事項など幅広い情報共有を行うために公開される文書シリーズ ● インターネット技術の標準化を推進する任意団体であるIETFが管 理している ● 50年近く(1969年〜)維持され続けている歴史書 ● 書かれていること – インターネットの様々な技術的仕様 – インターネットに係わるルール – 良い知識、良い方法 – 遊び心に溢れるジョーク
- 152. 152 RFC は何の略？ ● Request for Comments（リクエスト フォー コメンツ、略称： RFC） – 直訳すると「求むコメント」 – インターネット技術の研究開発は、 米国国防総省のARPA/DARPAが 資金援助を行い研究開発活動が推進されたために、 研究開発の結果 は、広く公開できないことになっていた – しかし、研究結果を公開し、インターネットに関わる人々に広くその仕 様を流布し 普及させることが重要 – 「コメントを広く募集する」ための、ドキュメント であって、研究成果 を公開しているのではない、むしろ、研究成果をより良いもの にする ために、外部からのコメントを募集するためのドキュメントである、と いうトリック
- 154. 154 英語なので翻訳してみる
- 159. 159 UpdateがあるRFCもある
- 160. 160 RFC2549
- 161. 161 RFC6214
- 162. 162 Joke RFC 一覧 ● 英語版のWikipediaを参照するのが一番簡単 – https://en.wikipedia.org/wiki/April_Fools%27_D ay_Request_for_Comments ● 日本語Wikipediaには残念ながらありません ● 誰か項目を作ってくれればみんな喜ぶと思う
- 163. 163 ジョークが本当になった例もある Evil Bit ● 2003年のRFC3514 – IPv4ヘッダに使われていない領域が1ビットある – このビットに1がセットされていれば、パケットは悪意を持っていると する – 攻撃者がこの悪意のビットを立ててくれれば、安全なシステムは防衛 が可能になる。これで世界に平和が訪れる。すばらしい、実装しな ければいけない。 ● RFC発表とほぼ同じぐらいのタイミングで、FreeBSDに実装さ れる – 他のソフトウェアにも続々と実装されてる ● もちろん実際には無意味な仕様と実装なんだけど
- 164. 164 最初に読むべき文書、目次的なもの ● 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
- 166. 166 微妙な標準化もある ● MessagePackの標準化 – 元々の作者じゃない人が標準化提案をしちゃったとい う事案 ● OpenBSDのTheo de RaadtがIETFに対して激怒 – OpenSSLの脆弱性「Heartbreed」 – 誰からも必要とされない仕様がセキュリティホールの 元になった
- 167. 167 The Internet is for Everyone ● RFC3217 – https://tools.ietf.org/html/rfc3271 ● 2002年にInternet Societyから出された文書 ● インターネットに関わる人が増えてきて、お金も沢山動く ようになって、インターネットは誰の物か？、という議論 が盛んになったころに出された声明。 ● RFCを正しく理解するにはContext(文脈)を知っておくほう が良いことが多い。歴史と一緒。 ● 新し目のRFCではContextが省かれていることが多いので 行間を想像しつつ読むほうがより面白いよ。
- 168. 168 最古のインターネット 電子メール
- 175. 175 悪意に弱いインターネット
- 176. 176 「インターネットの精神」的な言葉 ● 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. ● (日本語意訳)己のなすことには慎重たれ、 他人のな すことには寛容たれ インターネットは「善意」で作られている
- 179. 179 再掲:DNSのヤバいところ ● 便利なので様々な用途に使われまくっている – 乱立するリソースレコード – 何でも登録できてしまうTXTレコード ● 良くわからない仕様、追加され続ける仕様 – 一見簡単な仕組みのように見えるのに、実際には良くわからない ● 設定ミスの多発 – それでもそれっぽく動いてしまう ● 多発するセキュリティ脆弱性 – 仕様的な問題、実装的な問題 悪意ある攻撃に弱い
- 181. 181 公開鍵暗号を使った防御 ● 公開鍵暗号技術を用いることによりある程度の防御は可 能 ● 公開鍵基盤(PKI)を用いて個々のプロトコルレベルでの 防御技術はある程度確立されている ● PKIが提供するサービスは以下 ● 守秘性: 特定の相手のみ読めるようにする ● 認証: その人が誰かを証明する ● 完全性: データが変更されてないことを証明する ● 否認防止: ある人が以前行なった行為を証明する
- 182. 182 具体的な防御技術 ● IP: IPsec ● ルーティング: RPKI ● DNS: DNSSEC ● ウェブ: TLS ● メール: SPF,DMARC,DKIM,TLS ※興味がある人は調べてみてください
- 184. 184 縁の下を支える 運用監視
- 186. 良い監視
- 187. 悪い監視
- 193. ハードウェア監視 ● 売ってる人 – ハードウェアメーカー ● 売ってるもの – 汎用コンピュータ – サーバ – ネットワーク機器 – ストレージ ● 監視システム例 – ハードウェア監視プログラム – 統合プラットフォーム管理ツール ● 監視プロトコル、インターフェイス例 – IPMI – SNMP – syslog
- 194. 設備監視 ● 売ってる人 – データセンター ● 売ってるもの – 電気 – セキュリティ ● 監視方法 – 防災センターによる統合監視 – Network Operation Centerによる統合監視
- 195. 回線監視 ● 売ってる人 – 電話会社、通信会社 ● 売ってるもの – 電話回線 – 専用線 – イーサネット接続 ● 監視方法 – OSS(Operation Support System ※電話会社用語) – NMS(Network Management System) ● 監視プロトコル例 – SNMP – syslog – Ether OAM
- 196. インターネット接続監視 ● 売ってる人 – ISP – データセンター ● 売ってるもの – インターネット接続 – 経路情報 ● 監視方法 – NMS(Network Management System) – OpenBMP – Nagios/Zabbix 等の汎用監視ツール ● 監視プロトコル例 – Ping – BFD – BMP
- 197. サーバ監視 ● 売ってる人 – ホスティング事業者 – MSP ● 売ってるもの – サーバ(物理、仮想) ● 監視方法 – Nagios/Zabbix 等の汎用監視ツール ● 監視プロトコル等 – Ping – syslog、サーバログ – HTTP/SMTP/DNS等の汎用プロトコル
- 198. サービス監視 ● 売ってる人 – コンテンツ事業者 – インターネットでサービスをしている事業者 ● 売ってるもの – インターネットを使ったサービス ● 監視方法 – Nagios/Zabbix 等の汎用監視ツール – エージェント型監視ツール – サービスチェックツール ● 監視プロトコル – HTTP/SMTP/DNS等のインターネットサービスプロトコル – 独自サービスチェックプロトコル – 各種ログ
- 202. 202 まとめ