So-net blog 共通テーマ本

2002年の初版を2007年に改訂したもの。ブラウザでいれた「http://www.nikkeibp.co.jp/」がどのようにして画面に表示されるのか。そのような過程を探検ツアーのようにたどることで、ネットワーク全体を1冊に収めた本。　Webブラウザがメッセージを作るーブラウザ内部を探検- 　　　　　　↓ 　TCP/IPのデータを電気信号にして送る　-プロトコル・スタックとLANアダプタを探検- 　　　　　　↓ 　ケーブルの先はLAN機器だった　－ハブとスイッチ、ルータを探検ー　　　　　　↓ 　アクセス回線を通ってインターネットの内部へ　　　　　　↓ 　サーバ側のLANには何がある　　　　　　↓ 　Webサーバに到着し、応答データがWebブラウザに戻ると、順をおって解説していた。最初に探検ツアーの流れという図があって、スタートはユーザ側のコンピュータ,ゴールはサーバのコンピュータ、間に電話局やプロバイダが配置されたもので、ここにどの章で解説しているかのっている。　動きとしても、ブラウザから何らかの要求（リクエスト）をWebサーバに送り、　Webサーバはその要求に従って動き、結果（レスポンス）をブラウザに送るというやりとりがあるだけ　これを相手側まで運ぶ仕組み、運ぶのはすべて０と１のデジタルデータ。基本はデータをパケットという単位にわけて運ぶこと。　パケットは手紙や小包のようなもので宛先などが先頭に書いてある。スイッチやルータがその宛先をみながら運んでいく。 TCP/IPやイーサネットといった技術は、ネットワーク機器やソフトウェアがどのように動くべきかというルールだが、ルールだけでは個々の機器やソフトの中身は見えない。その部分を突っ込んで解説した。そのためページが330から440に増えたそうだ。第1章　Webブラウザがメッセージを作るーブラウザ内部を探検- 　　１．１　HTTPリクエスト・メッセージを作成する。　　　URLとは、http://ではじまるアレのこと。他にftp:とかfile:、mailto:ではじまるものがある。　　　ブラウザはwebの閲覧につかわれることが多いが、実はいくつかのクライアント機能をかねそなえている。　　　主要URLの書き方を解説した表。　　　　　　ブラウザはまずURLを解読する。ここではWebサーバにアクセスする例をとりあげている。　　　URLをどのように解釈するか例で解説。　　　先頭はデータ源にアクセスするプロトコル、ここではhttp 　　　//は次に続く文字列がサーバであることを表すなど　　　末尾が/で終わっているときはファイル名は省略されている。このときはindex.htmlあるいはdefault.htmにアクセスする。　　　末尾がなくファイル名もないときは、ルートディレクトリのindex.htmlあるいはdefault.htmにアクセス。　　　ただし、最後がファイル名なのかディレクトリ名なのかわからない時「末尾/がない」はファイルがなければディレクトリと解釈。　　　HTTPプロトコルとは、クライアントやサーバがやり取りするメッセージの内容や手順を定めたもの。　　　まず、クライアントがサーバにリクエストメッセージを送る。そこに「何を」「どうしてほしい」のか書いてある。　　　「何を」にあたるのはURIで普通ページのデータ格納したファイルの名前やCGIプログラムのファイル名、あるいはURLをそのままかける。　　　「どうして」にあたるのはメソッドで、GET、POSTなどの種類がある。一覧にまとまっていた。　　　サーバはこのメッセージをうけとって、処理をしてその結果を返す。先頭にはステータスコードが入る。「404 Not Found」などがこれにあたる。　　　サーバの返したメッセージをクライアントが画面に表示して終わり。　　　GETメソッドは一番よくつかう。Webサーバにアクセスしてページのデータを読み出すときに使う。　　　POSTはフォームにデータを記入してWebサーバに送信するとき使う。URIにはWebサーバマシン内で動作するアプリケーションプログラムのファイル名をかく、またプログラムやスクリプトに渡すデータも書く。　　　この２つがHTTPの典型的な使い方。　　　URLを解読し、Webサーバとファイル名が判明するとブラウザはそれを基にHTTPリクエスト・メッセージを作る。　　　リクエスト・メッセージフォーマットは、まず1行目にリクエストラインを書く。　　　<メソッド><空白><空白> 　　　次の部分は空白行がでてくるまでメッセージヘッダーになり、<フィールド名>：<フィールド値>を書く。付加的な細かい情報が必要なときに使う。　　　次の部分がメッセージボディになる。GETの場合は送信するデータは無い。　　　どのメソッドを使うべきかはブラウザの状態で決まる、URL欄にURLをいれて表示する場合はGETになる。　　　HTTPで使われる主なヘッダーフィールド一覧が見開きでのっていた。　　　Date、Pragmaなど。　　　メッセージにはレスポンスが返ってくる。　　　1行目はステータスラインで　　　<空白><ステータス・コード><空白><レスポンス・フレーズ> 　　　以下はリクエストメッセージと同じ構成。　　　ステータス・コードは数字で実行結果をしらせる、1xxなら処理の経過状況通知、2xxなら正常終了など。概要一覧があった。　　　画像が無い場合はデータを取り出して表示して終わり。　　　画像がある場合は、そこをあけて文章を表示して、画像をWebサーバから取得して表示する。　　　リクエスト・メッセージに書くURIは一つだけと決まっているので、ファイルは一度に１つずつしか読みだせない。　　　それでこのような処理になっている。この処理をコーディネイトするのはブラウザであり、Webサーバは関知しない。　　　具体的なHTTPメッセージの例が３ページにわたってのっていた。　　１．２　WebサーバのIPアドレスをDNSサーバに問い合わせる　　　　　　HTTPのメッセージを作ったら、今度はそれをOSに依頼してアクセス先のWebサーバに向けて送信してもらう。　　　このとき、URLに書いてあるサーバのドメイン名からIPアドレスを調べる。OSに依頼するときはIPアドレスでないといけないので。　　　　　　IPアドレスはTCP/IPの考え方に基づいて作られているので、まずTCP/IPについて説明する。　　　TCP/IPでは、サブネットという小さなネットワークをルータと接続することで全体のネットワークができあがっていると考える。　　　サブネットはハブに何台かのパソコンがっ接続されたものと考える。　　　そして○○丁目△△番地というようなネットワーク上の住所ともいえるアドレスを割り当てる。　　　○○丁目がネットワーク番号、番地をホスト番号とよび、このアドレスをIPアドレスと呼ぶ。　　　　　　送信元がメッセージをおくると、サブネットの中にあるハブがメッセージを運んで行って、一番近いルータまで届ける。　　　ルータがメッセージを届ける相手を見定めて次のルータを判断し、そこに届けるようし指示して送信動作を実行すると、再びサブネット内のハブがそのルータまでメッセージを届けてくれる。　　　実際のIPアドレスとは、32ビットのデジタル・データ。8ビットずつドットで区切って、10進数で表した表記が多い。　　　IPアドレスのルールでは、ネットワーク番号とホスト番号の２つあわせて32ビットと決まっているだけで区切りは決まっていない。ネットワークを構築するときユーザが自分で決める。これをネットマスクと呼ぶ。　　　ネットマスクはIPアドレスと同じ32ビット分のデジタル・データで、左側に1が右側に0が並ぶ。ネットマスクが1のところがネットワーク番号を、0のところがホスト番号を表す。　　　ホスト番号のビット部分がすべて0あるいは１の場合は特別な意味をもつ。　　　０は個々の機器ではなくサブネット自体を表し、１だとサブネットにある機器すべてにパケットを贈るブロードキャストを表す。　　　URLの中にIPアドレスを書いても正しく動くが、覚えるのが大変。　　　逆に名前で通信できるようにしたら、実行効率は良くない。IPなら4バイトで済むのを名前ならもっと多くなるので。　　　人間は名前を使い、ルータはIPアドレスを使うという今の方法（DNS)がとられている。　　　IPアドレスを調べるには、最寄りのDNSサーバに名前で問い合わせればいい。　　　DNSサーバに問い合わせメッセージを送り、応答を受け取るというDNSクライアントに相当する仕組みをDNSリゾルバとよぶ。この実体はSocketライブラリに入っている部品化したプログラム。　　　Socketライブラリは、OSに組み込まれているネットワーク機能をアプリケーションから呼び出すための部品を集めたもの。　　　リゾルバを呼び出すには、gethostbynameとWebサーバの名前を書けばいい。　　　　　　リゾルバ内部の動きを、アプリケーションプログラム（Webブラウザ）、Socketレベル、OS内部のプロトコル・スタックレベルで解説した図があった。　　　コンピュータの内部は多層構造になっていて、層をなすように多数のプログラムが存在し役割分担している。　　　上位の層から依頼された仕事は下位層に依頼しながら処理が進む。　　　　　　DNSサーバへメッセージを送信するときにもIPアドレスが必要だが、TCP/IPの設定項目になっているので、改めて調べる必要はない。WindowsでのDNSサーバのIPアドレス設定画面がのっていた。　１．３　世界中のDNSサーバが連携する　　　DNSサーバの基本動作は、クライアントから問い合わせメッセージを受け取り、その問い合わせの内容に応じる格好で情報を回答すること。　　　問い合わせメッセージに含まれる３つの情報　　　　・名前　サーバやメール配信先（@からうしろ）などの名前　　　　・クラス　インターネット以外のネットワークの利用も検討され、それを識別するために用意された。今はINしかなくなっている。　　　　・タイプ　名前のタイプ。Aなら名前にIPアドレスが対応づけられている。MXなら名前にメール配信先が対応づけられている。　　　３つの情報に対応づけて、クライアントに返信する項目を登録しておく。　　　DNSサーバ、名前、クラス、タイプからIPアドレス対応表を調べ、IPアドレスを回答する。　　　登録情報は設定ファイルに書き込まれていて、一行分の情報に相当するのをリソース・レコードとよぶ。　　　これまでの説明は問い合わせメッセージを受け取ったDNSサーバに名前とIPアドレスが登録されている場合を想定している。社内ならすべのWebサーバやメール・サーバを一台のDNSに登録できるが、インターネットでは莫大な数のサーバがあるので1台のDNSにすべて登録することはできない。　　　DNSサーバに情報が登録されていない場合は、どうするか。　　　DNSサーバに登録する情報はすべてドメイン名という階層的な構造を持つ名前がつけられている。　　　DNSで扱う名前はwww.lab.glasscom.comのようにドットで区切られているが、このドットが階層の区切りを表す。右が上位の階層を表す。会社組織なら、com事業部gloasscom部lab課のwwwとう名前ということになる。そして、一つの部署に相当するものをドメインとよぶ。　　　このドメインの情報をDNSサーバに登録するとき、１つのドメインをひとまとまりのものとして扱う。　　　ドメインの階層構造と同じ格好でDNSサーバが配置される。　　　インターネットの土間陰はすべて下位にドメインを作って国谷会社や団体にわりあてたもの。　　　下位のドメインを担当するDNSサーバのIPアドレスをその上位のDNSサーバに登録するという順番で登録していく。　　　lab.glasscom.comというドメインを担当するDNSサーバをglasscom.comのDNSサーバに登録し、glasscom.comのDNSサーバをcomドメインのDNSサーバに登録するという具合。こうすると上位のDNSサーバに行けば、下位のDNSサーバのIPアドレスがわかり、そこに問い合わせメッセージを送ることができる。　　　comやjpといったドメイン(トップレベル・ドメイン）の上位には、ルート・ドメインとよぶドメインがある。これを明示的に書くにはサイドにピリオドをつける。ここにcomやｊｐのDNSサーバを登録する。これでルート・ドメインから順に下の方にたどっていくことができる。　　　また、ルート・ドメインのDNSサーバをインターネットに存在するDNSサーバ全部に登録する。その結果どのDNSサーバからでもルート・ドメイン経由で目的のDNSサーバにたどり着ける。ルート・ドメインのDNSサーバに割り当てられたIPアドレスは全世界で13個しかないし、めったに変更されない。　　　ルート・ドメインのDNSサーバに関する情報はDNSサーバ・ソフトと一緒に設定ファイルとして配布されているので、インストールすれば自動的に登録される。　　　クライアント・パソコンがDNSサーバをたどって目的のサーバにたどり着く様子を追ってみる。　　　現実のインターネットの世界では1台のDNSサーバに複数のドメイン情報を記録ｓるので、ドメインごとに別のサーバにいって調べることはない。　　　また、一度調べた名前をキャッシュに記録しておく機能があり、問い合わせた名前に該当する情報がキャッシュにあれば、それを回答する。すると、その位置から階層構造を下に向かって探すことができるので手間がはぶける。　　　問い合わせた名前がドメインに登録されていない場合、名前が存在しないという回答が返ってきて、それもキャッシュに保存されるので、名前が存在しない場合も素早く回答できる。　　　キャッシュは保存された情報は、登録情報が変更されれば正しくなくなるので、キャッシュは一定の期間でクリアされる。　　　また、問い合わせの回答には、キャッシュからの情報なのかDNSサーバからの情報なのか知らされることになっている。　１．４　プロトコル・スタックにメッセージ送信を依頼する。　　　IPアドレスを調べたら、IPアドレスの相手にメッセージを送信するように、OS内部のプロトコル・スタックに依頼する。　　　Socketライブラリに入っている複数の部品を決められた手順で呼び出す。　　　イメージとしてはデータを送受信するコンピュータの間にパイプををつなぎ(両端はソケット）そこを通してデータをやり取りする。両方向にデータをやりとりできる。　　　手順としては、まずサーバ側がソケットつくり待つ。クライアントがソケットを作りパイプをつなぎにくるとソケットにつなぐ。つながったらソケットからデータを放り込むイメージでデータ送受信動作を実行。終わったらつながっていたパイプを外す（どちらからでもかまわない）そしてソケットを抹消する。この動作を行うのはプロトコル・スタック。しかし、一連の動作はSocketライブラリとプロトコル・スタックが連携しておこなうので、一体で説明していく。　　　ソケットを作るフェーズでは、Socketライブラリのsocketというプログラム部品を呼び出す。ソケットが出来たらディスクリプタというものが返ってくる。ディスクリプタはソケットを識別するのに使う。二つのブラウザを開いて同時にアクセスするときなど、ディスクリプタは二つあることになる。アプリケーションはディスクリプタはでソケットを識別する。　　　パイプをつなぐ接続フェーズでは、Socketライブラリのconnectというプログラム部品を呼び出すことで依頼動作を実行する。connectを呼び出すときに、ディスクリプタ、サーバのIPアドレス、ポート番号をセットで渡す。　　　ポート番号は相手のソケットを識別するもの。サーバ側のポート番号はアプリケーションの種類によってあらかじめ決められた値を使うというルールがある。Webだったら80番、メールだったら25番。ちなみにクライアントのポート番号はプロトコル・スタックが適当にわりあててサーバ側に通知してくれる。　　　メッセージをやり取りする通信フェーズでは、Socketライブラリを介してプロトコル・スタックに依頼してwriteというプログラム部品でソケットからデータを放り込む。このとき、ディスクリプタと送信データ（メモリにつくっておく）を指定する。返答がきたら、Socketライブラリのreadというプログラム部品を介してプロトコル・スタックに受信動作を依頼する。その際受信したレスポンス・メッセージを格納するためのメモリ領域＝受信バッファを指定する。メモリに書き込んだところでメッセージをアプリケーションに渡したことになる。　　　切断フェーズでは、ブラウザがデータを受信し終わったらSocketライブラリのcloseというプログラム部品を呼び出す。するとソケットの間をつないでいたパイプのようなものがはずれ、ソケットも抹消される。　　　Webで使うHTTPプロトコルでは、本来Webサーバ側から切断動作を実行するようになっている。まずWebサーバ側がcloseを実行し、それがクライアント側に伝わり、クライアントのソケットは切断フェーズに入る。そしてreadが実行されたとき、受信データの代わりに切断されたことをブラウザに通知する。　　　HTTPプロトコルは以前一つやりとりするたびに切断していたが、効率がわるいので1.1からは切断しないで複数のリクエストとレスポンスをやり取りできるようになった。このときはリクエストがなくなったところでブラウザから切断動作に入ることがある。　　　　　　第２章　TCP/IPのデータを電気信号にして送る　-プロトコル・スタックとLANアダプタを探検- OSに組み込まれたプロトコル・スタックがHTTPリクエスト・メッセージの送信依頼をどのように実行するか解説。　（１）ソケットを作成する　　プロトコルスタックの内部構成　　　OSの中にあり、TCPというプロトコルを使う部分（ブラウザやメールなど）とUDP（DNSサーバへの問い合わせなど短い制御用のデータの送受信）というプロトコルを使う部分がある。　　　その下にはIPがあり、パケットを通信相手に運ぶ。ICPMとARPというプロトコルを扱う部分を含む。　　　プロトコル・スタックの上にはアプリケーション（ソケットライブラリとリゾルバ）、その下にはLANドライバがある。　　プロトコル・スタックは内部に制御情報を記録するメモリー領域をもち、そこに通信相手のIPアドレス、ポート番号、通信の進捗状況を記録する。プロトコル・スタックはこれを参照して動く。　　netstatという困んでソケットの内容を画面に表示できる。その結果の説明ものっていた。　　　　Socketを呼び出したときの動きを、IP、TCP、UDPを絡めた図で説明。　　ソケットを作成するとは、ソケットひとつ分のメモリ領域を確保し、それを示す荷札のようなディスクリプタを返すこと。　　以降アプリケーションはこのディスクリプタを使って、ソケットを指定する。　　　（２）サーバに接続する　　クライアントから、自分のIPアドレスと、ポート番号を送って、データ送受信可能か問い合わせる。そして制御情報をやり取りする。　　制御情報は大きく分けて２つあり、クライアントとサーバがお互いに連絡を取り合うためにやりとりするもの。ヘッダに記載され、TCPのプロトコル仕様で規定されているもの。一覧があった。　　もう一つはソケットに記録してプロトコル・スタックの動作をコントロールするための情報。送受信動作の状態も記録され、プロトコル・スタックはその情報を参照しながら動く。この情報はプロトコル・スタックによって違う。　　　実際にconnectの動作をおいかけてみる。　　TCPは送信元と宛先のポート番号をを書くことで接続すべきソケットを指定する。　　そしてコントロール・ビットのSYNというビットを１にする＝接続するという意味のTCPヘッダーを作ってIPに渡す。　　IPはパケットを作って送信、サーバがわのTCP担当が、該当するソケットを接続進行中にして返事を返す。　　返事には送信元と宛先のポート番号、SYNや１にしたTCPヘッダを作る。ACKビットも１にするが、これはパケットを受け取ったことを知らせるもの。そしてIPに依頼して送る。　　返事を受け取ったクライアントはSYNが１なら接続成功として、ソケットにサーバのIPアドレスやポート番号をキロkして、ソケットに接続完了を表す制御情報を記録する。サーバにACKビットを１にしたTCPヘッダーを送る。　　これで接続完了。ソケットを結ぶパイプができたと考える。このパイプをコネクションとよび、closeするまで存在する。　（３）データを送受信する　　アプリケーションがwriteを呼び出して送信データをプロトコル・スタックに渡す。　　プロトコル・スタックは中身は関知しない。送信用バッファに記録して、アプリケーションが次のデータを渡してくるのを待つ。　　すぐに送ると小さなパケットをたくさん送ってしまうので、効率が低下するので。　　どの大きさで送るかはOSの種類とバージョンによる。　　MTU・・・１つのパケットで運ぶことができるデジタル・データの最大長、イーサネットでは通常1500バイト。　　MSS・・・MTUからヘッダーを除いたもの。この長さに近くなるまでデータをためる。　　ただし、時間がかかりそうなときはMSSまで溜まっていなくても送信する。　　また、アプリケーション側で送信のタイミングをコントロールする余地がある。　　大きなデータを一度に送るときには、送信バッファにはいっているデータを先頭からMSSのサイズに分割して送る。　　このときシーケンス番号に何バイト目かをいれて送る。　　TCPは送信したパケットが相手に届いたか確認（ACK番号で次が何バイト目かを返す）する。もし届いていなかったら送信する。　　分割したデータの何バイト目に相当するかACKにはいっており、それが続いていないとデータが抜けたと判断する。　　セキュリティのため開始は乱数で発生させた番号を使う。そして送信相手に初期値を送る。（SYNを１にしておくるとき）　　実際には送受信が同時におこる。　　そして、抜けがあれば再送するので、LANアダプタもハブもルータも回復処理をとらず、エラーがでたら、そのパケットを捨てるだけでいい。TCPは何度か再送してもダメならデータ送受信動作を強制終了してアプリケーションにエラーを返す。　　タイムアウト値・・・ACK番号が返るのを待つ時間。　　この値は混み具合などで変わるので、TCPは待ち時間を動的に変更する。　　ウインドウ制御・・・パケットを１つ送ったあと、ACK番号を待たずに次々と連続して複数のパケットを送る方法。この方法だと待ち時間の無駄はなくなるが、受信側の能力を超えてパケットを送ってしまう事態が起こる。そこで受信側から受信可能なデータ量を通知（受信バッファから計算）して、送受信動作を実行する。　　図を使って説明していた。　　受信側はACK番号やウィンドウを通知するときしばらくまって、その間に次の通知がおきたら、まとめて最後のものだけ通知する。　　　　ブラウザは返ってきたメッセージを受け取るためにreadプログラムを呼び出す。　　このときレスポンス・メッセージがなければOSのプロトコル・スタックはこの作業を一次棚上げして、受信が完了したとき作業を再開する。　　棚上げしている間に、受信処理が行われ、データの抜けがなければACK番号を返す。　　受信した断片を受信バッファに一時保管して元のすがたに復元後、アプリケーションに制御を戻す（read処理を再開）　　その後、タイミング見計らってサーバにウィンドウを通知する。　（４）サーバから切断してソケットを抹消　　アプリケーションがデータ送受信動作が終わったと判断すると切断フェーズに入る。　　プロトコル・スタックはクライアント、サーバどちらから切断がはじまってもいいように作ってある。　　説明ではサーバからでしていた。　　　サーバ側アプリケーションがSocketライブラリのcloseを呼び出す。　　　プロトコル・スタックがFINビットを１にした切断情報のTCPヘッダをつくり、IPに依頼して送る。サーバ側のソケットに切断動作に入ったことを記録。　　　クライアントは、自分のソケットに切断動作にはいったことを記録してACKを返す。アプリケーションが情報をとりにくるのを待つ。　　　アプリケーションがreadをしてきたら、サーバからのデータを受信し終わったことをアプリケーションに知らせる。すると、アプリケーションがcolseをよびだして送受信動作を終わりにする。　　　クライアント側のプロトコル・スタックはFINビットを１にしたTCPヘッダを作りIPに依頼して送信。サーバのACKで終了。　　ソケットの抹消はしばらく待ってから行う。ACK動作が届かないなどの誤動作を防ぐためである。（普通数分間）　　TCP全体の動作が図にまとめられていた。　（５）IPとイーサネットのパケット送受信動作　　パケットの仕組み　　　パケットはヘッダーとデータからなる。ヘッダーには宛先を表すアドレスなどの制御情報が入る。　　　　パケットの送り方　　　送信元の機器がパケットを作る。最寄りの中継装置に送信。　　　中継装置はヘッダーを調べて、パケットの行先を判断する。そのときどの宛先がどの方向にあるかとう情報を登録した表のようなものを使う。　　　これを繰り返して、最終的に目的の機器にパケットを届ける。　　通常、送ると返事がくるので、送信元と宛先を区別しない言い方をエンドノードという。　　　　TCP/IPネットワークではサブネットという考え方があるのと、ルータとハブという2種類のパケット中継装置で役割分担しているのでもう少し複雑。　　ルータは目的地を見定めて次のルータを示し、ハブはサブネットの中でパケットを運んで次のルータに届ける。　　　　TCP/IPのパケットにはMACヘッダーとIPヘッダーがつけられていて、IPアドレスには目的地が、MACには次のルータがいれられる。当然、届いたら次のMACに書き換えられる。図で説明してあった。　　イーサネットの部分（MACアドレス）は他のもので置き換えられるので、無線LAN、ADSL、FTTHでも使えるので巨大ネットワークを構築しやすい。　　IP部分の動き、TCPから渡されたIPアドレスとデータの断片にTCPヘッダーを付加したものの前に制御情報としてMACヘッダーとIPヘッダーをつける。　　IPヘッダーはIPプロトコルで規定されたルールに従ってIPアドレスで示された目的地までパケットを届ける際に使う制御情報を記載するもの。　　MACヘッダーはイーサネットなどのLANを使って、最寄りのルータまでパケットを運ぶ際に使う制御情報を記載したもの。　　その後出来上がったパケットをネットワーク用のハードウェアに渡す。　　受信はこの逆になる。　　特徴は中身をみないので、TCPヘッダーだけ(制御情報）でもきにしないで送る。フェーズやパケットの順番や抜けも一切きにしないこと。　　IPヘッダーを作る　　TCP担当部分から通知された宛先IPアドレスを設定。　　送信元にはそのコンピュータに割り当てられたIPアドレスをセットするが、LANアダプタが複数ある場合はルータで経路表をつかうのと同じ方法で使うLANアダプタを判断してIPアドレスを選ぶ。。詳しい説明は3章で。　　経路表はroute print　コマンドで内容を表示できるので、ここでも説明していた。　　経路表の一番上には目的地とネットマスクが0.0.0.0で登録されており、これはディフォルト・ゲートウェイを表す。　　プロトコル番号には、パケットにいれた内容物の依頼元を表す値をセット。TCPなら06（16進表記）UDPなら17 　　MACヘッダーを作る　　MACヘッダーはイーサネットで宛先判断に使う。　　MACアドレスは48ビットで考え方はIPアドレスと同様に住所。　　イーサ・タイプはパケットの内容物がなにかを示す、IPプロトコル（0800）かARPプロトコル(0806）が使われている。IPv6も設定はあった。　　送信元MACアドレスには、送信するLANアダプタのMACアドレスをセット　　宛先MACアドレスには、パケットを渡す相手がはいるが、送る時点ではわからないので、経路表のGateway欄のIPアドレスの機器が相手になる。そしてIPからMACを調べる。　　　　IPアドレスからMACアドレスを調べる方法　　ARP・・・ブロードキャスト（つながっている全員にパケットを送る）でIPアドレスを問い合わせ、該当者にMACアドレスを送ってもらう仕組み　　一度問い合わせた情報はARPキャッシュに入り、一定期間保持される。　　ARPキャッシュの中身はARP -dコマンドで見れる。　　こうして完成したパケットをLANアダプタに渡す。LANアダプタは単純に送信するのみ。　　　　イーサネットの基本　　　イーサネットは多数のコンピュータをいろんな相手と自由に安価に通信させるために考案された通信技術。　　　・イーサネットの原型＝１０BASE5 　　　　その実体はケーブルがあるだけ。トランクケーブルにトランシーバーがついて、その先にコンピュータがある。　　　　コンピュータが信号を送信すると全員に信号が届く。　　　　宛先に誰当てなのか書いておき、該当者は受け取り、他の人は捨てる。このとき宛先に使うのがMACヘッダー。　　　・リピータ・ハブを用いた派生形＝１０BASE-T 　　　　　トランクケーブルがリピータハブに、トランシーバーがツイストペアケーブルに置き換わった。　　　　　信号が全員に届くは変わっていない。　　　・スイッチング・ハブを用いた形態　　　　　スイッチング・ハブは宛先MACアドレスによって目的地を見定めてパケットを中継するので、信号は目的の相手にしか届かない。　　　LANアダプタは、デジタル・データを電気や光の信号に変換してネットワークのケーブルに送り出す。　　　LANアダプタをコントロールするのはLANドライバ。メーカによって違う。　　　LANアダプタ内部を概念構造で説明。　　　LANアダプタのROMには全世界で重複しないように一元管理されたMACアドレスが製造時に書き込まれている。　　　MACアドレスはLANドライバがMAC回路にセットする。(初期化が必要）　　　MAC回路はパケットの先頭にプリアンブルとスタート・フレーム・デリミタという２つのデータを、末尾にフレーム・チェック・シーケンス（FCS）を付け加え送り出す。　　　ビットの区切りを表すのにクロックを使う。データ信号とクロック信号は合成して送られる。これをわけるのがプリアンブルの役割。　　　イーサネットは多数の派生方式があり、信号の硬いが違うが、プリアンブルの役割は変わらない。　　　スタート・フレーム・デリミタはパケットの始まりを表し、FCSはデータ化けの検出に使う。　　　パケットの送信　　　リピータ・ハブは半2重モード、信号の衝突を回避するため、信号がながれているか調べ、流れ終わってから送信動作をする。データを電気信号に変換する（PHYまたはMAU回路を使う）速さが伝送速度で1秒間に10メガビットなら、10メガビット/秒になる。送信中に衝突がおきたら、中止して衝突を他の機器に知らせるジャミング信号を流してしばらく待つ。そして送信動作を試みる。待ち時間はそろわないようにMACアドレスを基に乱数で計算する。何度かやり直してもだめならエラーを返す。　　　全2重モードは3章で説明。　　パケットの受信　　すべての機器にパケットが届くので、すべて受信して波形を取りだし、エラーチェックをしながら電気信号に変換。エラー・パケットは捨てるが、TCPが再送してくれるはずなので問題ない。　　そしてMACアドレスを調べ、自分あてならバッファ・メモリに保存して、コンピュータ本体にパケットの受信を通知。　　通知は割り込みという仕組みを使う。LANアダプタが拡張・バススロットの割り込み用の信号線に信号を送り、CPUにしらせ、OSが割り込み処理をしてLANドライバからLANアダプタを制御して受信動作を行う。　　割り込み番号は現在PnPとう仕組みで自動になった。　　LANドライバはMACヘッダーのタイプ・フィールドからプロトコルを判別。対応するプロトコル・スタックに渡す。　　LANドライバから受信したパケットはIP担当部分に渡される。　　ICPMメッセージ一覧　　IP担当部分が通信相手に渡すメッセージechoの応答や、IPアドレスが自分でない場合Destination unreachableなど。　　宛先IPアドレスが正しければ、受信するが、いろんな機器を通る過程でパケットが分割されることがあるので、その復元=フラグメンテーションを行う。ここまでやったらTCP担当に渡す。　　TCP担当はTCPヘッダーからソケットを特定し、進捗状況に応じて動作を実行する。（必要なら受信確認パケットをおくりかえすし、受信バッファにデータをうつす、切断ならアプリケーションに通知するなど）　（６）UDPプロトコルを用いた送受信動作　　TCPが複雑なのは、データを確実に、そして効率的に届けようとするから。　　UDPはデータを分割せず、全部送ってから一度だけ確認する。この方法だと効率的ではないが、制御用の短いデータ（DNSの問い合わせなど）なら必ず1パケットに収まるので問題ない。また開始と終了の制御用のパケットも省略して、送信と応答だけにすることができる。　　音声や動画でもUDPが使われる。これは決められた時間内に送らないと再生タイミングに間に合わないのと、データが多少抜けても致命的にならないから。第３章　ケーブルの先はLAN機器だった　－ハブとスイッチ、ルータを探検ー　（１）ケーブルとリピータ・ハブの中を信号が流れていく　　コンピュータから送信されたパケットは、ハブやルータといった中継装置によって、中継され、目的地に向かって進んでいく。　　中継動作はパケットのヘッダーに記載された制御情報と、中継装置内部にある中継先を登録した表で目的地を判断し、目的地に近づくようにしてパケットを中継する格好になる。パケットの中身はみないでの、ＨＴＴＰのメソッドもＴＣＰの受信確認やシーケンス番号もサーバとクライアントの関係もすべて無視され、パケットは何の関連性もない別々のものとみなされ、目的地にむけて中継されていく。　　ＬＡＮアダプタのＰＨＹ（ＭＡＵ）回路で電気信号に変換　　　↓ 　　ＲＪ－４５コネクタを通ってツイストペア・ケーブル（より対線）に入る　　　↓ 　　ケーブルの中を流れる(エネルギーが弱くなる、周波数の高い信号ほど四角い角がとれて丸くなる）　　　↓ 　　リピータ・ハブに信号がはいり、ＰＨＹ（ＭＡＵ）回路を通り、リピータ回路を通り、入力ポート以外のすべてのＰＨＹ（ＭＡＵ）回路のあとＲＪ－４５ポートから出力　　ツイストペア・ケーブル（より対線）は2本の信号線を組みにしてより合わせている。こうすると電磁波の進行方向と打ち消し合うちからが生じて雑音を防ぐことができる。他にも信号線の間に間仕切り板をいれたり、電磁波を遮るために金属製のシールドという被膜をかぶせるなどいろいろな工夫が積み重ねられ、性能の異なるケーブルが何種類か発売されている。　　　　カテゴリという尺度は性能をあらわす。　　カテゴリ５（CAT-5）・・・10メガのイーサネットと100メガのイーサネットで使う。125Mhzまでの周波数の信号を100メートル伝えることができる。　　エンハンストカテゴリ５（CAT-5e）・・・ギガビット・イーサネット1000BASE-T用。10BASE-Tと100BASE-TXでも使用可能。　　カテゴリ6（CAT-６）・・・最高250MHzの信号対応する。1000BASE-TX、10BAGE-T、10BASE-T、100BASE-TX、1000BASE-Tで使用可能。　　など。　　リピータ・ハブは、全部にパケットをばらまいてMACアドレスが一致した機器だけが受信するというイーサネットのきほんとなる仕組みで動く。　　リピータ・ハブの端のコネクタにはMDI/MDI-Xとかかれたきりかえスイッチがついていることがあるが、これはハブ同士をせつぞくするとき、一方をストレートにする必要があるためである。　　リピータ回路の基本は信号をそのままばらまくことにあるので、雑音の影響をうけて変形し、データが化けてしまっていてもそのまま流してしまう。スイッチング・ハブやルータ、サーバはデジタルデータに変換しFCSと突き合わせて、変形したパケットは捨てる。応答がないので、TCPが再送をしてくれることになる。　（２）スイッチング・ハブのパケット中継動作　　信号がコネクタに届き。PHY（MAU)回路で受信するところまでは同じ。　　PHY（MAU）形式から共通の形式に変換したあと、信号はMAC回路に入る。ここでデジタルデータに変換してFCSチェックをかける。問題なければバッファに格納。（LANアダプタに似ている）　　コネクタとその内側の部分をまとめてポートとよぶ。ただしここのMAC回路にはMAC番号は割り振られない。　　MACアドレステーブルで宛先を調べ、スイッチ回路を経由してパケットを送信側のポートに送る。　　スイッチ回路は碁盤の目のようになっていてスイッチがついているもの。図で解説していた。2番から7番へ流すとか使う。　　送信動作はLANアダプタと同じで、イーサネットルールに基づいて、だれかが送信中でないことを確認してから送信。送信中に他の機器が送った信号が受信にはいってきたら、パケットが衝突したとみなし、ジャミング信号をながして送信動作を注視して、しばらくまってから送信（ここもLANアダプタと同じ）　　パケットを中継するときMACアドレス・テーブルの更新も同時に行う。一つは受信したパケットの送信元とポートを登録する。もうひとつは、一定時間経過したMACアドレスの登録を消すこと。　　パケット送信先ポートが受信したポートと同じなら捨てる。（スイッチング・ハブとリピータ・ハブが接続されているときにおきる）　　MACアドレス・テーブルに宛先MACアドレスと一致するアドレスが無い場合、すべてのポートからパケットを送信する。　　宛先がブロードキャストでも全ポートから送信する。　　全2重モードなので、送信と受信が同時にできる。（リピータハブはできない）　　本来のイーサネットでは信号が流れていると送信できないというルールがあったが、それでは全2重の能力が生かせないので、信号がながれていても送信してよいというモードを追加した。このモードのときは衝突の検出は行わない。　　オート・ネゴシエーション・・・相手の対応モードを検知して、全2重と半2重を切り替える。相手の伝送速度を検出して、それも自動的に切り替える。　　イーサネットではデータがながれていないときは、リンクパルスというパルス型の信号を流すことになっており、以前はネットワークがつながっているかなどに使っていたが、特定のパターンでパルス信号を送信して自分の状況を相手に伝えられるように改訂された。　　スイッチング・ハブは、宛先MACアドレスの機器が存在するポート以外には送信を行わないので、他のポートはあいている。だから一度に複数のパケットを送信することも可能。（リピータは全部のポートにだすので不可能）　（３）ルータのパケット中継動作　　ルータは中継部分とポート部分がある。　　中継部分はパケットの中継先を判断する動作を担当。ポート部分はパケットを送受信する動作を担当。　　これはプロトコル・スタックのIP担当とLANアダプタの役割分担と同じ。　　よって、ポート部分を載せ替えればイーサネットだけでなく、無線LANやADSL、FTTHにも対応可能。　　ポートは自分自身が送信元になってパケットを送信する。ここがスイッチング・ハブとの違い。　　よってルータの各ポートにはMACアドレスとIPアドレスがわりあてられている。　　　　中継分が宛先を探すのにつかうのはIPアドレス。このとき使う表をルーティング・テーブルあるいは経路表とよぶ。　　経路表には、宛先、ネットマスク、ゲートウェイ、インターフェース、メトリックの項目がある。　　ルータはホスト番号を無視して、ネットワーク番号の部分のみ調べる。　　宛先欄には通常サブネットを表すIPアドレスが登録されるが、アドレス集約という考え方のため、違う値が入ることがある。　　アドレス集約とは、サブネットをいくつか集めて一つのサブネットとみなし、まとめたサブネットを経路表に登録する方法。　　例　10.10.1.0/24、10.10.2.0/24、10.10.3.0/24という３つのサブネットがあったとして、これがすべてルータAの先にあるのなら、ルータBの経路表には、３つをひとまとめにした10.10.0.0/16というサブネットがあるものとみなして登録しておくことができる。こうすると登録を減らすことができる。このときネットマスク値はかえる。　　逆に１つのサブネットを細分化して経路表に登録し、複数のサブネットがあるようにみせかけることもある。　　つまり、ルータ経路表のネットマスク欄は、経路表の宛先とパケットの宛先アドレスを照合するときのビット数を表しているだけ。　　ゲートウェイ欄と、インターフェース欄はパケットの中継先を表す。　　メトリックは宛先IPアドレスに記載されている目的地が遠いか近いかを表す、小さいと近い。　　　　経路表に登録するのは、スイッチング・ハブと違って、パケットをやりとりするときではない。　　人間が手動で経路情報を登録/更新するか、ルーティング・プロトコルという仕組みでルータ同士で経路情報を交換し、ルータが自分で経路表に登録する方法をとる。　　イーサネットのパケットを受信する動作を追う。　　ポートでパケットをうけてLANアダプタのように動作してバッファメモリに格納するまではほとんど変わらない。　　PHY（MAU）回路とMAC回路でデジタルデータに変換しFCSでエラーチェックして異常ならすてる。　　正常ならMACヘッダーを調べ、自分あてなら受信バッファメモリに格納。他はすてる。　　先頭のMACヘッダーをすてて、IPヘッダーの内容をみて経路表の宛先欄を調べ、該当する行をさがす。　　このとき32ビットすべてではなく、ネットマスク欄に登録された値からネットワーク番号のビット数を判断して、ネットワーク番号の部分だけを比較する。　　複数の候補が見つかった場合は、ホスト番号のビット数が少ないほうが、範囲が絞りこまれているので採用される。　　これも同じならメトリックで判断する。　　経路表に該当する行が一つもない場合は、パケットをすてて送信元にICPMでその旨を通知する。　　スイッチング・ハブはたかだか数千台程度のあまり大きくないネットワークを想定しているが、ルータはインターネットの規模が違う。だから一斉にパケットをばらまくようなことはしない。　　しかし、経路表にすべての中継先を登録できるわけではない、そのためにディフォルト経路が設定されている。　　経路表の最後の1行にネットマスクが0.0.0.0が登録されており、これがディフォルト経路で、登録されるルータはディフォルト・ゲートウェイを表す。　　　　パケットには有効期限があり、ルータはIPフィールドのTTL（Time To Live）を１つ減らす。ルータの経由のたびにへらして0になったらパケットの期限がきれたとみなす。同じ個所をぐるぐるするのを防ぐ。普通64とか128をセットする。地球の裏側までいってもルータは数十個くらいなので、十分である。　　ルータのポートはイーサネットだけでないので、受信ポートより、送信ポートのパケットの最大長が小さいことがある。　　このようなときはIPプロトコルで規定されたフラグメンテーションという方法でパケットのTCPヘッダーとデータを分割し、パケットの長さを短くしてから送る。もしも分割不可ならパケットをすてて送信元にICPMで通知する。　　ルータの送信動作は出力側のポートによるが、ここではイーサネットで説明。　　イーサネットの送信動作はイーサネットのルールで規定されているので、コンピュータと同じ動作で行われる。（ARPでMACアドレスを調べる）　　通信相手までデータを届けるのはIP（ルータ）が担当。　　動作の際に次のルータまでパケット運ぶ部分をイーサネット（スイッチング・ハブ）が担当。　　IPはイーサネットでなくてもデータを運んでもらうことができる。このためインターネットのような巨大なネットワークをつくることができた。　（４）ルータの付加機能　　アドレスは本来インターネットに接続する機器がすべて固有でもつものであった。しかし爆発的に増えた接続でおいつかなくなった。そのため社内など、閉じたネットワークで使うアドレスは他と重複してもよいことになった。こうした社内の機器に割り当てるアドレスはプライベート・アドレスとよばれ、10.0．0.0～10.255.255.255、172.16．0.0～172.31.255.255、192.168．0.0～192.168.255.255に限定されている。従来の固有なアドレスはグローバル・アドレスとよばれている。両者のアドレスを対応させるのがアドレス変換。　　アドレス変換・・・パケットを中継するときにIPヘッダーに記載されたIPアドレスとポート番号を書き換える。具体的動作の説明あり。ポート番号を書き換えるのは、グローバル・アドレスとプライベートアドレスが1対1で対応しないようにするため。　　インターネットにアクセスしない機器には、インターネットからパケットを送れないのでセキュリティ上もよい。外からアクセスさせたいときは対応表に登録しておく。　　パケット・フィルタリング機能・・・パケットを中継するときに、MACヘッダー、IPヘッダー、TCPヘッダーに記載してある内容を調べ、それが事前に設定した条件に合致したらパケットを中継する仕組み。ファイアーウォールと同じ。第４章　アクセス回線を通ってインターネットの内部へ　(1)ADSL技術を用いたアクセス回線の構造と動作　　　インターネットと家庭や会社のLANとの違いは、ルータの間の距離と経路情報の登録方法にある。インターネットのルーターに登録される経路情報は10万件以上で、しかもそれが時々刻々かわっているのだ。　　　インターネット接続ルータが経路を調べる方法は同じだが、パケット送信動作はアクセス回線にあわせてかえている。アクセス回線にはADSL、FTTH、CATV,電話回線、ISDNなどがある。　　　ここではADSLを取り上げる。回線構成図があがっていて説明があった。ユーザ側ルータから送信されたパケットはADSLモデムや電話ケーブルを通って電話局に届き、そこからADSL事業者のネットワークを経由してプロバイダに届く。　　　インターネット接続用ルータはMACヘッダー、PPPoEヘッダー、PPPヘッダーの３つをつけて、ADSLモデムにパケットを送付する（PPPoE）の場合。ADSLモデムはパケットをセルに分割。電気信号に変えてすぷりったに送信。　　　ADSLモデムはなだらかな波形（正弦波）を合成した信号に０と１のビット値を対応づける変調技術を使う。振幅変調と位相変調をくみあわせた直交振幅変調を使用している。波を多数使って高速化もしている。上りは26個の波を、くだりは95または223の波を使う。これが上りと下りの速度の違いになる。雑音や減衰などの回線特性が電話回線でことなるので、ADSLは回線状態を調べ、使う波の一也個々の波い対応付けるビット数を判断する仕組みをもっていて、モデムの電源をいれたとき試験信号をおくって判断している。これをトレーニングといって数秒から数十秒かかる。　セルはスプリッタにはいって、そのまま電話の音声信号と混じって電話回線を一緒に流れていく。スプリッタは電話回線から信号が流れた場合に電話とADSL信号をわける（一定の周波数を越える信号をカットする）働きをする。電話機に流すほうは分けた後だが、ADSLモデムには分ける前のをそのまま送る。ADSLモデム自体が周波数をカットする機能をもっているから。また、スプリッタがないと受話器をとって回線を接続した状態と、そうでない状態で回線の状態がかわり、トレーニングがおこってしまうので、それを防ぐためでもある。　　　スプリッタの先には屋内配線をとおり、ビルなら外からの回線と内の回線をつなぐIDFやMDFがあり、一戸建てはそのままだして、保安器（落雷などから保護するもの）を通り電柱のケーブルに入る。その後地下に入り（そこをき線点とよぶ）電話局に近づくにつれてまとまって地下ケーブル（とう道とよばれるところを通る）になり電話局のMDFに1本1本つなぎこまれる。　　電話ケーブルはツイスト・ペアより雑音の影響をうけやすく、雑音（電車の線路脇やAMラジオなど）が多いと使える周波数が減って速度が低下する。昔はISDN回線にも影響されたが、今は克服されている。　　電話局にたどり着いた信号は、配電盤、スプリッタを通過してDSLAMに届く、ここで電気信号がデジタル・データのセルに戻される。DSLAMは多数のADSLモデムに相当する機能をまとめた装置。イーサネットでなくATMインターフェースをもつものが大半で、分割したセルのまま後方のルータとやりとりする。　　DSLAMをでたパケットはBAS（ルータ機能＋本人確認とTCP/IPの設定を送る機能がある）とよばれるパケット中継装置に届く。BASはATMセルをパケットに戻して、MACヘッダー、PPPoEヘッダーは捨てられる。そしてトンネリング用のヘッダーをつけてトンネリングの出口にむけて中継する。トンネリング用のルータがうけてトンネリング用のヘッダーを外してIPパケットを取りだし、インターネット内部に中継する。　（２）光ファイバを用いたアクセス回線（FTTH）　　光ファイバの基本。光ファイルバは二重構造の細い繊維状の透明な材質（ガラスやプラスチック）でできており、内側にあるコア部分に光の信号を流してデジタルデータを伝える。明るければ１、暗ければ０である。デジタルデータから一度電気信号に変換し、この電気信号をLEDやフォトダイオードなどの光源にいれて電圧に応じて明るい光や暗い光をだして通信する。受信側は光に感応して電圧をおこす受光素子があり、そこに光があたると、１または０が受信される。　　光ファイバケーブルの中に光が入り、反射しながから進むわけだが、発せられた光はあらゆる方向にひろがり、その一部がケーブルに入る。そして入った角度が悪いと反射している間に位相のずれで弱まってしまう。だからある特定の角度で入った光しかつたわらない。コアの太さが細いもの（シングルモード）と太いもの（マルチモード）があり、細いものは１つの角度しか伝えられないが、途中で反射を繰り返して弱まることが少なく、長距離を伝えられる、ただし光は弱く発光・受光素子の性能が必要で価格が高いこれがFTTH。マルチは複数の反射角の光を伝えられ、発光・受光の性能はそれほどなくていいので価格はひくいが、反射で減衰するため遠くまで伝えられない。　　ADSLの代わりにこのFTTHを使ってユーザ側インターネット接続用ルータとインターネット側のBASを接続するのがFTTHアクセス回線。1本の光ファイバをつかいメディア・コンバータでイーサネットの電気信号と光信号を変換する形態と、ユーザ近くの電柱に光スプリッタとよぶ分岐器を設置し、そこで光ファイバを分岐させて複数のユーザをつなぐタイプがある。後者ではメディア・コンバータの代わりにONUとう装置をユーザ側に、BASの手前にOLTを置く形態になる。　　PPPoEを使うときは、ADSLの説明と同じようにセル分割とヘッダーつけが行われる。　（３）アクセス回線で用いるPPPとトンネリング　　BASはログイン動作の窓口役で、PPPoEの仕組みでログインを行う。　　PPPは電話回線のダイヤルアップ接続でログイン動作をするためのもの。これはプロバイダのアクセスポイントに電話をかけて、繋がったらユーザ名とパスワードを入力、それはRADIUSというプロトコルでRASにおくられ認証が正しければIPアドレス（グローバルアドレス）が返されるという仕組み。　　ADSLやFTTHでもパソコンにグローバルアドレスを割り当てないと通信できないのはいっしょ。しかしBASとケーブルで固定的に接続するので本人確認の必要がないところが違う。でもユーザ名とパスワードを確認する動作を残しておけば、ユーザ名に応じてプロバイダを切り替えられて便利である。そこでアクセス回線の事業者はADSLやFTTHでもPPPの仕組みを使うことにした。　　PPPの仕組みをそのままま使えないので考えだされたのがPPPoE。PPPメッセージはRASに届けるまでにHDLCプロトコルを借用するが。PPPoEはイーサネットのパケットを使う。　　トンネリングはTCPコネクションのように、一方の出入り口からデータをいれるともう一方の出入り口にとどくという仕掛け。BASはこの機能を使ってアクセス回線がプロバイダのルータまで伸びたかのようにみせかける。トンネリングの実現方法はTCPコネクションを使う方法と、カプセル化といってヘッダーも含めたパケット全体を他のパケットに格納する方法もある。原理的にはパケットを丸ごとはこべればどんなものでもトンネリングに利用できる。　　インターネット接続ルータにプロバイダから割り当てられたユーザ名とパスワードを登録する。するとインターネット接続ルータはPPPoEのDiscoveryという仕組みをつかってBASを探す。この仕組みはARPのようにイーサネットのブロードkyストを利用している。ユーザ名とパスワードはCHAPという暗号化方式か、暗号化しないPAPどちらかで送られる。もっともパスワードが流れるのはルータとBASの間だけなのでケーブルでも盗聴しないとパスワードはわからないけど。パスワードが確認されるとTCP/IPの設定値が送られ、インターネット接続ルータのBASポート側に設定される。このあとクライアントからインターネットにアクセスするパケットが流れてくる。インターネットへのパケットの宛先はインターネット接続ルータには登録されていないので、ディフォルト経路でに送られることになる。ただし、送り方はイーサネットの方法ではなくPPPoEの方法（MAC、PPPoE、PPPヘッダーがつく）になる。　　アンナンバードとは、1対1で接続されたポートはIPアドレスを割り当てなくてもよいという特例があることである。相手がきまっていれば経路表も必要ない。PPPoEではこの方式でつなぐことが多いので付加するヘッダーは事前にきまっている。　　インターネット接続ルータでパケットを送信するとき、プライベートアドレスはグローバルアドレスに変換される。アプリケーションによっては自分のIPアドレスを通信相手や制御用サーバに通知する必要があるものがあり、この時は変換がおこなわれないようにBASが通知するPPPoEのメッセージをパソコンでうけとって接続する方法をとるが、インターネットと直接つなぐと攻撃をうけるおそれがあるのでパソコン用のファイアウォールを使うなどの処置が必要。　　PPPoAはMACヘッダーとPPPoEヘッダーをつけないでパケットをそのままセルに格納する方法。MACヘッダーがないのでそのままイーサネットに転送できないので、ルータとADSLモデムを一体化する必要がある。ただしMTUが短くならないので効率低下がおきない。　　PPPではなくDHCPを使ってBASからTCP/IPの設定情報を通知する場合はPPPoAでも問題ない。　　DHCPとは主に社内のLANで使われる方法で、パソコンからDHCPサーバに設定情報を要求して、サーバが通知する仕組み。ユーザ名とパスワードの確認もしない。単純にイーサネットのパケットをやりとりするだけ。　（４）プロバイダの内部　　インターネットの実体は、複数のプロバイダのネットワークを相互接続したもの。ADSLやFTTHのアクセス回線はユーザが契約しているプロバイダの設備につながっている。その設備をPOPという。　　POPの概要はそれぞれのアクセス回線に合わせたルータとそれがあつまるスイッチ、サーバ、他のPOPやNOCにつなぐルータから出来ている。NOCはPOPから入ってきたパケットが集まってくるところで高性能なルータである。転送速度はテラビットをこえるものもある。NOCとPOPの明確な区分はない。　　プロバイダの建物内はNOCやPOPをケーブルで結ぶが、建物の外は光ファイバなどでつなぐ。プロバイダ自身がもっていることもあるが、ほとんどのプロバイダは持っているところから借りている。こうしたサービスを通信回線という。通信回線の提供のされかたも、細分化したり、そのままカスなどバリエーションがある。　（５）プロバイダをまたがって流れるパケット　　ＰＯＰに届いたパケットはＰＯＰの経路表に従って中継される。経路表はルータ同士で経路情報を交換しあう機能で自動的に登録される。そして目的のＷｅｂサーバ側のＰＯＰにたどりつくまで中継される。プロバイダ同士での経路情報交換はＢＧＰという仕組みを使って接続相手の経路情報を教えてもらうかわり自分の経路情報を教えるという方法で自動で行われる。　　この交換にはインターネットの経路を全部相手に渡す方法＝トランジットと、それぞれのネットワークに関する経路情報だけを交換する方法＝非トランジットあるいはピアがある。　　社内では目的地まで最短経路でパケットを運ぶのが目的なので、無差別に周囲のルータと経路情報を交換するが、プロバイダ同士だと不都合。一方が高速な回線をもっていると、そこにパケットが集中したりするからだ。こういうとき相手に通信回線の費用負担を求めても応じてもらえないこともある。そこで、意図しない相手からのパケットを止める仕組みが必要になる。経路情報交換も交渉が成立した相手のみに行う。また経路を選ぶとき最短経路だけでない経路に優先度をつけられるようにする仕組みも必要。　　ＩＸ・・・プロバイダ同士が1対1で接続する方法では数千社のプロバイダを結ぶ必要があって大変なので、中心となる設備を設け、そこを経由して接続する方法をとる。この中心設備がＩＸ。日本にはＪＰＩＸ，ＮＳＰＩＸＰ－２、ＪＰＮＡＰが代表的。　　場所はタイ新設備と自家発電をもつビルの中にある。高速なＬＡＮインターフェースを多数装備したレイヤー2スイッチがある。高速スイッチングハブの集まりがＩＸの正体。第５章　サーバ側のLANには何がある　（１）Webサーバーの設置場所　　ルータ直結型　　　昔は社内LANにサーバを設置して、インターネットから直接アクセスできる（PO→ルータ→アクセス回線→サーバ側のルータ→サーバマシン）ようにしていたが、グローバルIPアドレスの枯渇と、セキュリティの問題からこの形態はなくなった。　　ファイアーウォールで分離するケース　　　特定のサーバで動く特定のアプリケーションのパケットだけを通す関所の役目をする。許可されたアプリにセキュリティホールがあると危険。　　データ・センターにWebサーバを設置　　　プロバイダのNOCやプロバイダを相互接続するIXに直結されているので高速。耐震性のビルや自家発電があって安全。付加サービスで、稼働の監視やファイアウォールの設置運営、不正侵入監視をしてくれるので安全性が高い。　（２）ファイアウォールの仕組みと働き　　サーバの設置場所によらず、手前にファイアウォールを設置するのが通例　　ファイアウォールでどのパケットを通すか決める方法はパケット・フィルタリング型が主流。　　パケット・フィルタリングはパケットのヘッダーの項目にいろんな条件を設定することで、どのパケットを通すか決める方法。見開きでヘッダーの種類、条件設定に使う項目、説明の順で、条件設定をするパケットの内容をあげていた。そして、具体的な設定方法でパケット・フィルタリングの考え方を説明。　　宛先IPアドレスと送信元IPアドレスから始点と終点を判断し、終点がWebサーバのものだけを通す。そして応答やデータをながすためにWebサーバが始点のパケットも通す。　　アプリケーションを限定するときには、TCPヘッダーやUDPヘッダーに記載されているポート番号を条件に加える。　　Webサーバからインターネットへの接続をとめる（不正アクセスの踏み台にされることもあるので）TCPヘッダーにあるコントロールビットで、SYN=1ACK=0のものを判断し、それを遮断するとTCP接続の3個のパケット（SYN→SYN,ACKが→ACK）ながれず接続が確立しなくなる。インターネットからのアクセスは逆パターンで3個のパケットが発生するので接続は確立する。　　このように条件を設定していく。　　DNSサーバへのアクセスはUDPなので、特定のパケットの遮断はできない。　　社外からインターネット公開サーバの間のパケットだけでなく、サーバから社内LANへのパケットも適切に条件の設定が必要。　　パケット・フィルタリング型のファイア・ウォールはアドレス変換も行っているので、その設定も必要。アドレス変換を行うとインターネットから社内LANへはアクセスできなくなるので、そのための条件設定は不要になる。　　ファイアウォールで条件に合わないパケットは廃棄するが、記録は残すので不正アクセスがあったかの解析はできる。通過させるときのパケットの中継動作はルータといっしょ。だからルータでもパケット・フィルタリングはできるが、複雑な条件設定や記録はできない。　　ファイアウォールではパケットの中身は調べないので、条件さえあっていればパケットは通過してしまう。受け取ったサーバ・ソフトがダウンしてしまうようなパケットを通すこともあるが、それはサーバ・ソフトのバグなので、改修バージョンで対応するはず、常に最新のバージョンをいれるように注意するべき。　（３）複数サーバにリクエストを振り分けてサーバの負荷を分散　　サーバへのアクセスが増えた時、回線を高速にしたり、サーバを高性能のマシンにするなどの方法が考えられる。　　それでもアクセスが集中したときのために考え出されたのが複数サーバによる負荷分散。　　ラウンド・ロビン方式・・・複数のサーバを一つのDNSでDNSサーバに登録、DNSサーバはリクエストがあるたびに、複数のサーバのIPアドレスを回転させて順番を変えながら送る。これで負荷が均等に分散されることになる。　　ラウンド・ロビンでは故障したサーバをよけることができないのと、CGIなどで複数のページにまたがってやりとりするときに相手がかわると困る。このため負荷分散装置またはロードバランサーという装置が考えだされた。　　負荷分散装置をDNSサーバに登録しておき、実際のサーバへの接続はこの装置が行う。サーバの負荷状態をしらべるか、あらかじめサーバの能力を登録しておき、どのくらい仕事を割り振ったかで判断したりしてリクエストを分散させる。　　HTTPはもともと静的データを扱うために開発されており、複数ページのリクエストという概念がなかった。だからWebサーバからはHTTPリクエストは1回ずつまるで別のものに見える。また、リクエストの送信IPアドレスが同じなら、一連のリクエストと判断する方法は、プロキシやアドレス変換のため使えない。そこで前後関係を判断する方法が考えられた。HTTPのヘッダー・フィールドの拡張などがそれ。　（４）キャッシュ・サーバを利用したサーバ負荷分散　　キャッシュ・サーバとはプロキシという仕組みを使ってデータをキャッシュするサーバ。　　DNSにはキャッシュ・サーバが登録されており、リクエストはまずキャッシュ・サーバに届く。キャッシュ・サーバはリクエストされたデータが自分のところにない場合、自分がクライアントになって（このときViaというヘッダーを追加）Webサーバにリクエストして、データを取得して、リクエスト先に返す。このとき、自分のディスクにデータを保存しておき、次に同じデータに対してリクエストがきたら、（変更があるかWebサーバに問い合わせIf-Modified-Sinceヘッダーてから）自分のデータをリクエスト先に返す。　　このとき、転送先のWebサーバを判断する仕組みが必要で、リクエストメッセージのURIのディレクトリで判断する方法などがある。　フォワード・プロキシ・・・プロキシの原型。クライアントにキャッシュ機能を置く方法。もともとはリクエストのパケットを一旦うけとって転送することで、パケットの中身をみて遮断をするために使っていたが、同時にキャッシュもすると効率的なので行われるようになった。通常使うときはブラウザの設定画面に用意されたプロキシ・サーバという項目にフォワード・プロキシのIPをいれる。メッセージ転送はサーバのプロキシと違ってURI部分に「http://...」がそのままあるのでそのまま送れる。　リバース・プロキシ・・・フォワードはブラウザの設定が不可欠だがwebサーバでは設定できない。そこで、リクエストメッセージのURIに書いてあるディレクトリ名と転送先のWebサーバを対応付けて設定することで、URI部分に「http://...」でない通常のリクエストメッセージを処理できるようにしてサーバに側に設置したプロキシ。　トランス・ペアレントプロキシ・・・リクエストメッセージのパケットのヘッダーから宛先IPを取り出して転送する方法をとる。便利だが、DNSに登録することができないので、リクエストのパケットの経路を絞り込んで、そこに置いてパケットを横取りする必要がある。通常アクセス回線につながるところに置かれるので、存在が意識されることはあまりない。キャッシュの側面が高まっている。　（５）コンテンツ配信サービス　　キャッシュサーバはクライアントに置いた方がインターネットのトラフィックが減るし早いという利点があるが、Webサーバ側からは操作できないという欠点をもつ。クライアントのプロバイダにキャッシュ・サーバをおいて、Webサーバ側が管理するともっとも効率がいいが、全部のプロバイダにキャッシュを置くことはできないし、Webサーバ側の管理が大変になる。これを解決したのが、CDSP事業者が提供するコンテンツ配信サービス。　　CDSPはプロバイダとWebサーバ管理者との間にはいり、キャッシュ・サーバを設置してそれをWebサーバ管理者に貸し出す。高性能なキャッシュ・サーバを複数のWebサーバが使うことで費用を抑え、プロバイダとの契約もひきうけてくれるので手間も減る。　こうしたコンテンツ配信のキャッシュ・サーバをインターネットから見つける方法（クライアントにアクセスさせる方法）として、DNSに最寄りのキャッシュサーバのIPアドレスを回答させる。（距離で判断するためルータの経路情報を収集して判断）や、HTTPのLocationヘッダーを使う方法＝リダイレクト。この方法ではメッセージのやり取りは増えるが、経路情報の精度はDNSよりもよい。　キャッシュ・サーバの効率を左右する要素は、クライアントからのアクセスを最寄りのキャッシュ・サーバにさばく方法と、キャッシュの内容の更新。キャッシュの内容は、Webサーバが更新されたら更新するとか、CGI部分だけをWebサーバに送るとか、いろいろな工夫がされている。　ファイアウォールやプロキシサーバ、キャッシュサーバなどを通ったリクエストは最終的にWebサーバに届くことになる。第６章　Webサーバに到着し、応答データがWebブラウザに戻る　（１）サーバの概要　　ネットワークに関する部分、LANアダプタ、プロトコル・スタック、Socketライブラリんどの機能はクライアントと変わらない。　　クライアントから接続動作を行い、サーバがうける格好になるのでSocketライブラリの呼び出し部品が違う。　　また、複数のクライアントと通信するところも違う。　　　　サーバ・アプリケーションは複数のクライアントと通信するために、接続を待つ部分と、クライアントとやり取りする部分に分かれているのが通常。クライアントがアクセスしてきたら、やり取りする部分を立ち上げるか、あらかじめ立ち上げておいて開いているものとつなぐ方法をとる。サーバのOSはマルチタスクあるいはマルチスレッドとよばれる機能で多数のプログラムを同時並行で動かせる。　　本来TCPは左右対称にどちらからでも自由にデータが送れるという発想でつくられているが、接続動作だけはそうはいかない。　　サーバ側のSocektライブラリの呼び出しは次のようになる。　　　１ソケットを作る　　　２－１ソケットを接続街状態にする　　　２－２接続を受け付ける　　　３データを送受信する　　　４パイプを外してソケットを抹消する。　　Socketライブラリの具体的説明　　　bind・・・ソケットにポート番号を記録　　　listen・・・ソケットに接続まち状態という制御情報を記録　　　accept・・・接続を受け付ける　　ポイントは元のソケットは接続まち状態のままコピーしたソケットを使うこと。このときポート番号は本来みな換えなければならないのだが、それではクライアントからのポート番号を無視してしまうことになるので、ソケットを特定するときには、クライアントのIP、クライアントのポート番号、サーバのIP、サーバのポート番号の４つで判断するようにする。ただし、実際にはディスクリプタを使う。理由はソケットを作ったときには４つの情報がそろっていないことと、いちいち４つ調べるよりディスクリプタ一つで判断したほうが簡単だから。　（２）サーバの受信動作　　・LANアダプタ　　パケットの電気や光の信号をLANアダプタでデジタルデータに変換する（クライアントと同じ）過程を１０BASE-Tで解説　　　１　信号変化のタイミングからクロックを抽出　　　２　抽出したクロックを同じ間隔で延長　　　３　クロックの位置でデータ信号の変化の方向を調べる　　　４　信号変化の向きを１と０に直す　　FCSでエラー検査　　正常ならメモリ部分に置く。　　LANアダプタのMAC部分がこれを行う。　　バッファに置いたらCPUに割り込みをおくってパケットの到着を知らせる。　　MACヘッダーのタイプ・フィールドからプロトコルを判断してプロトコルスタックを呼び出す。　　・IP担当　　　IPヘッダから、自分宛か、フラグメンテーションによるパケットの分割有無を調べる、TCPまたはUDP担当にパケットを渡す。　　・TCP担当　　　パケットが接続動作だったら、TCPコントロールビットを確認したあと、宛先ポート番号を調べ、該当する接続待ちのソケットをコピーして新しいソケットを作成、送信元のIPアドレスやポート番号などを記録。　　・データ送受信中のTCPの動作　　　届いたパケットの送信元IPアドレス、送信元ポート番号、宛先IPアドレス、宛先ポート番号から該当するソケットを判断し、データの断片をつなぐようにして受信バッファに補完し、クライアントに対してACKを返す。　　・TCPの切断動作　　　クライアント側と同じ。どちらから切断してもいい。　　　HTTP1.0だとサーバ側からSocketライブラリのcloseをよびだして、コントロールビットのFINの位置を１にしたTCPヘッダーを作って送る。クライアントがうけとるとACKを返す。その後クライアントもcloseを呼び出してFINを１にしたヘッダーを送ってくるので、サーバがACKを返して終わり。　（３）Webサーバ・ソフトがリクエスト・メッセージの意味を解釈して要求に応える。　　どのサーバ・アプリケーションでもデータの送受信は同じだが、リクエスト・メッセージの依頼内容を処理するのが異なる。　　Webサーバの場合はreadでうけとったHTTPリクエストメッセージを処理して、レスポンスメッセージをつくり、writeでクライアントに送り返す格好で動く。　　リクエスト・メッセージにはメソッドという一種のコマンドとURIというパス名のようなものが書いてあり、その内容に沿ってクライアントに送り返す。　　GETで説明。　　Webサーバのディレクトリは通常丸見えにならないように仮想ディレクトリになっている。　　URIがファイル名を省略してある場合、あらかじめ設定したファイル名がかいてあったものとみなすというルールがある。index.htmlとか。　　ファイル名の置き換えはサーバで設定できる。　　CGIプログラムの場合は、URI部分の拡張子が「.cgi」となっていると起動を判断。処理方法と処理させるデータがくるので、それをプログラムに渡す。通常出力データがHTMLドキュメントになっているので、Webサーバは内容はタッチしない。　　Webサーバで行うアクセス制御は　　　１クライアントのIPアドレス　　　２クライアントのドメイン名　　　３ユーザ名とパスワード　　これをデータ源となるファイルやディレクトリと対応させて設定し、URIでデータ源を判断してからアクセス可否の条件をみる。　　１ならメッセージで判断。　　２ならDNS問い合わせが必要。　　３ならクライアントにユーザ名とパスワードを要求。　　レスポンスメッセージを送り返す方法は、クライアントがリクエストを送る方法といっしょ。　　SocketライブラリのWriteをよびだし、レスポンス・メッセージをプロトコルスタックに渡す。相手はディスクリプタで判別。　（４）ブラウザがレスポンス・メッセージを受け取り画面に表示　　クライアントがパケットを受信する仕組みはサーバといっしょ。　　ブラウザの画面表示動作　　　レスポンス・メッセージの種類を調べる。Content-TYpeなどをつかう。テキスト、画像などがある。この使用はMINEで規定された方法が原則になっている。　　データの種類に応じて表示プログラムを呼び出してデータを表示して終了。HTMLタグの例で解説。最後に見開き４ページでパケットが通る道筋を一覧にしていた。左から物理的な装置やケーブル、メッセージの種類や電気信号、ヘッダーで解説。索引。