概要
ネットワークについて勉強しないといけなくなったぼくが
「ネットワークはなぜつながるのか 第２版」
を読んで気になる部分だけを抜粋して勉強のために書いた記事です。詳細？ 本を買ってください！
第１章 忙しい人のためのWebブラウザ
Chromeとか、FireFoxとか、Safariとかのことですね。（IE？誰だそいつは...）
URL
常識だけどブラウザはURLを打ち込むとそのURLの規則に沿ってWebページを探しに行って、結果を返す。
ブラウザは打ち込まれたURLを解析し、探しに行く。
http以外も打ち込める
- http:// httpプロトコルの利用
- ftp:// FTPプロトコルの利用
- file:// ローカルファイルの読み込み
- mailto:// メールの送信
- news:// ニュースグループの読み込み
でもブラウザで「http://」以外使うことまれですよね....？
httpプロトコル
ふんわりインターネット使ってても急に言われるとわからないマジックワード「プロトコル」何度か説明受けてもすぐ忘れる。
プロトコル・・・データ通信を行うために，あらかじめ定めておく規約。信号送信の手順，データの表現法，誤り検出法などを定める。通信規約。
つまり、httpプロトコルってのはクライアント（例えば。ブラウザ）がネット上に公開されているサーバーに上手いこと接続するための手順の事を言ってる。
手順１
URL（http://example.com/hoge/?huga=piyo)をブラウザに打ち込むと
ブラウザが何（URI /hoge/?huga=piyo）を、どうして（メソッド GET）してほしいのかをサーバーに送る
手順２
サーバーがブラウザにレスポンスを返す（２００とか４０４とか）
<html>
ほげ「ふがはぴよじゃないよ」
</html>
リクエスト・メッセージ、レスポンス・メッセージ
リクエスト・メッセージ POSTでよくパラメータを渡す。なんてHTMLを書いたことある人は、ブラウザはよしなにリクエスト・メッセージを作成して送っているということです。
他にも、認証するための情報など（リクエスト・ヘッダーのこと）色々送ってる。
レスポンス・メッセージ はそれに対応して、サーバーは要素の検証した時にLocationとかServerとか呪文のような要素（レスポンス・ヘッダーのこと。）と一緒にhtmlを返してくれたりする。（レスポンス・メッセージ）
DNSサーバー
ドメインでIPアドレスを調べるためDNSサーバーで名前解決（ネーム・リゾリューション Name Resolution）する。
- ドメイン こういうやつ -> example.com
- IPアドレス こういうやつ -> 255.255.255.255
DNSサーバーにどうやって問い合わせてるの？
DNSリゾルバ
リゾルバと呼ぶらしい。これはSocketライブラリに入ってるプログラムらしい。OSレベルで組み込まれていて利用することは簡単。
こいつに問い合わせたいドメインを投げると、最寄りのDNSサーバーを探して問い合わせて、その結果として得られたもの（例えば、IPアドレス）を返してくれる。
DNSサーバーの基本動作
| 名前 | クラス | タイプ |
|---|---|---|
| example.com | IN | A |
AWSのRoute53とかでよく見るやつです。リゾルバが要求してきたものを、DNSサーバーが持つ情報と照合してIPアドレスを返す。
クラスINっていうのはインターネットを表し、タイプAっていうのはIPアドレスを返すということ。
DNSサーバーは他のDNSサーバーを教えてくれる
DNSサーバーに全てのドメインの情報は無い。その為なかったら上位のDNSサーバーに聞きに行く。上位のDNSサーバーは下位のドメイン情報を知っているので、最終的には見つかる。という仕組み。
最終的にはルート・ドメインと呼ばれる、ドメインの末尾に「.(ピリオド)」をつけるDNSサーバー界最上位のDNSサーバーにたどり着くようだ。
プロトコル・スタック
１章の難関。
本に「プロトコル・スタックに依頼」と書いてあるからプログラムとか機能のことかと思ったら
コンピュータ上で、通信を実現するための一連の通信プロトコル群を実装しているモジュール（プログラム部品）
群なのか。ほぇーわからん（白目）
とにかくOSに組み込まれている内部にそういったモジュールがあるようだ。
メッセージを送受信するための仕組み
Socketライブラリを使い、クライアント側とサーバー側のソケット（データの出入り口）をパイプをつなぐ（送り先と返し先を一致させる）あと、データの遣り取りをする。
なんのこっちゃ、という感じだ。ぼくのイメージだと、プロトコル・スタックは送信したあと受信する側がちゃんと返信を返すまで待っているタスク待合室。って感じ。（詳しい人わかりやすく教えてください）
ポート番号
相手側がデータを受け取って置くためのソケットがどこなのか。というのを識別する仕組みとして、ポート番号がその役割を担っている。
- http://example.com:80/ 80番ポート つながる
- http://example.com:1234/ 1234番ポート つながらない
Webは一般的に80番ポートを開けているというルールが有る。ブラウザも特に指定がなければ80番ポートを見に行ってる。
サーバーによっては8000番ポートを開けている。という場合があるがその場合はわざわざ
みたいにしないと、ユーザー側は接続できない。
クライアント側のポート番号は？
プロトコル・スタックが勝手に見繕ってポート番号を割り当てるらしい。そんな感じなんだねぇ。
第２章 忙しい人のための プロトコル・スタックとLANアダプタ 〜内部構造を添えて〜
プロトコル・スタックっでHP削られた方、忙しいと思うので飛ばして３章へGO！
プロトコル・スタックの中身
群ってことなので、いろいろな要素が組み合わさっている。
- TCPプロトコル ブラウザやメールなどのデータ送受信
- UDPプロトコル 短いデータ送受信
プロトコル・・・データ通信を行うために，あらかじめ定めておく規約。信号送信の手順，データの表現法，誤り検出法などを定める。通信規約。
そういうルールを内包していて、用途によって使い分けてるらしい。
- IPプロトコル パケット通信する
- ICMPプロトコル 通信の際のエラー通知の役割
- ARPプロトコル IPアドレスに対応するMACアドレスを調べる
たくさんプロトコルあるんやなぁって....（瀕死）
- MACアドレス IEEEで標準化されたアドレス。そういう命名規則があるって覚えておけば良いと思う。
サーバーに接続する
クライアントとサーバー側の双方が送受信の準備が整うことを言うらしい。
そういう状態になってTCPさんが頑張って働いたりします。詳しくは書籍へ。
データを送受信する
リクエスト・メッセージやレスポンス・メッセージをやり取りするわけだが、データ量が多いと一発でやり取りが終わらない。
- MTU １パケットで運べる最大長。1500バイト
- MSS ヘッダーを除く、１パケットで運べるTCPのデータの最大長
上記のようなサイズや、待機時間によってデータを小分けにしてやり取りする。ぱっとページが出ないときは、裏でTCPさんが細いパイプ（回線が弱い）をひぃひぃ言いながらデータを運んでると思えばOKですね。
ACK番号で欲しいデータが来たのか確認
一度の送信の末尾に必ず、シーケンス番号が記載される。これはやり取りがどこまで進んだのか互いで確認しあうために利用される。
地下鉄などで一瞬、電波が届かなくなってもシーケンス番号のやり取りで「あ、今のやつ受け取れんかった。もっかい頼むわ」とTCPさんがよしなにやり取りしてくれてるわけです。
そのデータをどこまで、何バイト目まで受信できたかと言うのをACK番号として送る。
このACK番号のやり取りに時間がかかりすぎる（送信してから受信するまで）とタイムアウトとして処理され通信に時間がかかりすぎて読み込めませんでした。という表記が出て来る。
ただ、このやり取り自体時間がかかる。もうとにかく早くデータを送りたい！ という場合はUDPさんが活躍する。１パケットだけで済んでしまうようなDNSサーバーへの問い合わせ。生放送など、受け取れなくてもどんどん進んでいってしまうようなLIVE配信などに使われたりするっぽい。
ここを更に深掘りすると「パケットの送受信」の話になるが、忙しいので割愛。詳しくは書籍へ。
第３章 忙しい人のための ハブ、スイッチ、ルーター
物理的に機材がいかにすごいかを語る章。それぞれの機材の機能や処理について書かれているので、大半を割愛。
パソコン ＞ リピーター・ハブ ＞ スイッチング・ハブ ＞ ルーター ＞ インターネット
インターネットに繋ぐときの機材の順番はこんな感じですよね。
え？ ハブなんてない？ ぼくも使ったことないです。
- リピータ・ハブ 一台のパソコンから送られたデータを、接続されているすべてのパソコンに送ります。
- スイッチング・ハブ データを送る先を判断してデータを送ります。
ルーターだけで有線の口が足りないと、スイッチング・ハブを導入して、口を増やしたりします。
リピーター・ハブは昔の道具で、今はスイッチングハブに仕事を取られました。まぁ、関係ない情報受信させられても困るからしょうがない。
第４章 忙しい人のための アクセス回線、プロパイダ
アクセス回線
インターネットと家庭、会社のLAN(Local Area Network)を結ぶ通信回線のこと。
- ADSL 電話用の金属製ケーブルを使った高速通信技術
- FTTH Fiber To The Home 光ファイバー
- CATV ケーブルテレビ回線
- 電話回線
- ISDN 公衆交換電話網
結構色々ある。
ADSLの場合
パソコン ＞ ルーター ＞ ADSLモデル とつなぎ、インターネットへと情報が飛び出ていく。TCPさんが１パケット作り、ADSLモデルを通ると
ユーザー
①ADSLモデル パケット受信し、更に細かく分解（ATMセル）
②ADSLモデル 電気信号に変換し、送信
ADSL業者
③DSLAM（電話局用集合モデム） 電気信号を受信し、ATMセルに戻して送信。
④BAS（ブロードバンドアクセスサーバー） ATMを受信、パケットに戻し、IPアドレスやら情報を取り出す。
⑤ルーター（トンネリング用） インターネットに向けて送信
- セル ヘッダー情報５バイト、デジタルデータ48バイトの塊
- ATM 電話回線を用いる通信技術のこと
電話するための回線でも一度変換してしまえばインターネットに接続できるんだなぁ。
ただ、弱点として、電話局から遠くなると電波が弱くなるので通信速度が弱くなるという欠点がある。
FTTHの場合
光ファイバはADSLの電気信号に変換するところが、光の信号に変換するという部分が違います。
電気の速度より光の速度が早い。こっちは繋がってしまえばADSLよりうんと早い。さすが光。
トンネリング
クライアントとサーバーのソケットをつなぎパケットを運ぶ機能のこと。
入り口のトンネリングにデータを入れると、出口のトンネリングにデータが出てくる。そんな感じ。
本人確認と設定値通知
インターネットに接続するためにはユーザー情報とパスワードが欠かせない。
BASはそのログインのための窓口としての役割を担っている。そのため、PPPoEという仕組みを使っている。
PPPoE？
Point-to-Point Protocol over Ethernet。またプロトコルか。
これはPPPという電話回線を用いた接続の発展系の仕組みらしい。
PPPはシンプルに、プロパイダのアクセスポイントに電話をかけて、ユーザー名とパスワードを確認。ログイン。
（裏でRADIUSというプロトコルが働いて、RASという本人確認用サーバーで正当性を確認する）
問題なければレスポンスとして、認証サーバーからIPアドレスなどの設定情報が返ってきて、送受信の用意が整う。というもの。
これをADSLとかFTTHにも、イーサネットのパケットを通じてやり取りするようにして取り入れたからPPPoEという。
PPPoA！？
最後の2つはover ATMの略
イーサネットのパケットに入れてセルにしていたところ、直接セルに突っ込んでやり取りする方式。
DHCP？？
PPPの代わりに使える仕組み。
DHCPサーバーにクライアントが設定情報を要求して、DHCPサーバーが設定を返す。シンプル。
その代わりユーザー情報やパスワードが無いため、プロパイダの変更ができない。
....とはいうけど、そうそうプロパイダ変えてネットワークに繋ぐことはしないし、いちいちパスワードを入力するのも面倒です。
最近だとDHCPが主流ですね。
POPとかNOCとか
- POP Point of Presence
アクセス回線を通過したパケットはユーザーが契約しているプロパイダの設備にたどり着く。このルーターのことをPOPという。
- NOC Network Operation Center
POPから入ってきたパケットが集まってくる場所。ここから他のPOPへ流れ、目的のサーバーのある他のプロパイダへとパケットが流れていく。
POPと明確な違いは無いらしく、POPの大規模なのがNOCという認識で良いらしい。
また、どっちも凄く性能がいいルーターがおいてあるらしい。
個人が１メガビット毎秒だとしたら、プロパイダのもつルーターは１テラビット毎秒。１万倍の性能差。
第５章 忙しい人のための ファイアウォール プロキシ
ゴールが見えてきました。
ファイアウォール
Webサーバーを悪意あるメッセージ送信やアクセスから守る仕組み。
パケット・フィルタリング
主流の方式らしい。要はパケットに含まれた情報をみて、AllowしたりDenyしたりするあれです。
フィルタする情報は下記の通り。
- MACヘッダー 送信元、中継元のMACアドレスをチェック
- IPヘッダー IP制限するとかていうのは多分ここの情報を見てる
- TCP，UDPヘッダー 送信元のポート番号や、宛先のポート番号など
- ICMPのメッセージの中身 パケット送信中に発生したエラーのこと。このエラーを見て遮断したりできる
TCP,UDPヘッダーはよく使う気がする。
Webサーバーで80、443しか使ってないので、他のポートからのアクセスは全て遮断する。みたいな。
あとは社内からしか繋げないサーバーを用意するときは、社内で使っているIPアドレスのみの接続を許可する。なんてのは結構珍しくないはず。
遮断された場合？
パケットが破棄される。破棄されても捨てた記録が残ります。
これをたどると不正侵入をたどることができます。
注意するべきは、どこにファイアウォールを用意したかという部分。もしルーターにあると、ルーターの記憶容量は少ないのでログが全然残らず破棄されていく。
また設置した場所できちんとログを残すようにしてないと、そもそも残らなかったり...
フォワード・プロキシ
「Proxy」は代理という意味らしいです。
クライアント側にプロキシ・サーバーを置く方式のこと。「Webブラウザ＋プロキシサーバ」でクライアント側というイメージをしてください。
プロキシ自体はサーバーとクライアントの間を仲介する仕組みのことで、それがクライアント側にあるのをフォワードプロキシというようです。
フォワードプロキシは出て行くリクエストを一度集約して、プロキシサーバーが代理でリクエストを出す仕組みです。
この仕組を採用するとプロキシサーバーを一度経由しないとクライアントはサーバーにリクエストを投げれないです。
これで管理者が危険なサイトへのアクセスを制限したり、データの流出を止めたりできます。
万が一外部から攻撃されてもプロキシサーバーが身代わりになってくれたり...するかもしれません。
わかりやすく言うと、小学校とかでエロサイトにつなげようとしている 悪戯坊主の夢を破壊 青少年を守ったりする仕組みです。
ただ、ブラウザの設定画面からプロキシサーバーという項目の設定をすることが必須になります。面倒くさい。
リバース・プロキシ
フォワードプロキシの面倒から開放された仕組み。ここ本の書き方が本当に悪くて、最初に書いてあるプロキシの説明がリバースプロキシとイコールな感じです。
フォワードがクライアント側ならリバースはサーバー側にあるプロキシサーバーだと思えばOKです。
ブラウザは一度必ずプロキシサーバーを通るので
- URIの解析 リダイレクトの設定
- IPアドレスのフィルダリング
などをサーバー管理者側が挟ませることができる。便利。
第６章 忙しい人のための Webサーバー
apache、nginxを日常的に使う人はもうゴールしてもいいのよ...
クライアントとの違い
多くは変わらない。Socketのライブラリを備えてることが大体だと思います。
レスポンスを返す
やっと第１章からリクエストが届きました。リクエストに中身に書いてある要求に答えるべく、処理を進めます。
然るべき処理を終えると、通って来た道（サーバー側のプロトコル・スタック）に対して、レスポンス・メッセージを返します。
するとパイプを通ってクライアントのもとへデータが送られていきます。
....説明終わり？ ６章早い。
まとめ
忙しかったので結構すっ飛ばした部分も多いはずなんですが、なんだかんだ大量になってしまった。
なかなか濃度の濃い本でした。なのに時々、説明の時系列が飛ぶので追っかけるのが大変。という印象でした。
書くことによって勉強になったのでみんなも
「うわ、この本興味ねぇ！」「この本眠い....読み進められない」「なぜだ、全く頭に入ってこない！」
って人は、記事化しながら本を読み進めると
「この単語、他の人聞いたらわかるかな。わかりやすく説明するためにちょっと調べなきゃ」「これ意味わかんねぇ。紹介できない。もっと調べないと」
と、なるので定着しやすいです。時間がかかるけどそれに見合った学習ができるのでおすすめです。
ではまた。