SEの読書術 -「本質を読む」力を磨く10の哲学

10人のSEが自分の読書術について語ったものをまとめた本

後藤大地　事実から本質を見抜く
UNIXやJava中心にシステム開発や執筆活動をしているかた。
まったくしらない技術を調べるときは内容に関係なく、有名そうな本を何冊かかってきて、有名なものから読む。全部はよまない。インストールとかプラグインはとばす。そしてあとの本は差分をよんでいく。それで全体を網羅できる。
本は著名なものを選ぶ、それは多くの人が「いい」といっているから。
でも本の著名度より信頼している人が「いい」というものを優先する。
本の情報は鵜呑みにしない。誤植やバグがあるから。ネットはコピーなので間違いが増殖していることがある。
全体を網羅したらネットでアップデートする。
一年間読まない本は不要としてすてているが、すてたのを後悔している本もある。
どちらかというと検索方法を覚えるようにしている。
得たノウハウは手元にまとめておく。プログラミングならソースコードを残しておく。それを部品にする。
そうしたソースがないときには、やりたいことに近いソースを改造する。
基本の言語を一つバリバリにしておいて、既存のコードと組み合わせれば、だいたいなんでもできる。
司馬遼太郎の「坂の上の雲」をよんで、自分の考えるようなことは、前の人がだいたい考えているので、そっちを調べたほうが早いと思った。ただ間違っていることもあるので注意だけど。
本当に大事なところは暗誦できるまでよみこむけど、あとは捨てる。丸覚えしないで本質だけを抜き出して覚えるようにしている。
物事は良いところと悪いところ両面で考える。
ただ、何かを創造するときは盲目的になるのも重要かもしれないと思う。


原田洋子　原点から読んでいく
Java Servletの第一人者
情報収集には時間をかけたくないので、おもしろいと思うことを中心にチェックする。
全然しらないものは雑誌でチェック。話題もチェック。だいたい何月号くらいって覚えておく。
書店でまえがきや目次をみて、最初の1章くらいとAppendixをみて、覚えられれば買わない。内容がすぐわかならければとりあえず買う。
必要なければ洋書はいなない。それしかないなら読む
人が書いたものでわからなければ仕様書を読む。読みこなすには慣れがいるが、慣れると一番わかりやすい。
仕様を読んだら、ちょっと時間はかかるがプログラムを書きながら理解する。
ネットより本のほうが仕様はよみやすい。
本もソースコードをみて「こういう風にかく」「こんなクラス名をつける」とみることが多い。
本のサンプルコードはキレイすぎるので、実用にするときは参考にするだけ。
本は基礎力アップのために読むもの。そっから先は人からのフィードバックで。


山本啓二　多くを取り入れ視野を広げる
システム開発者。システムアーキテクチャ、開発手法、チーム運営のコンサルティング。
できるだけ書店に足を運ぶ。タイトル、帯、出版社、値段ををみて、前書きや最初の章を読む、文章がうけつないならやめる。図版などもわかりやすそうかみる。おもしろければそのままよんで、そうでなければ、目次から拾い読みして本当に必要なら買う。
最後に著者略歴をチェック。
技術解説の本は前書き見てから本文を２，３ページ開けば詳細かどうかわかる。ちゃんと背景から書いて、その技術の目的や何のためにどういう文脈で出てきているのか踏まえられているのがよい。
インデックスみたいになっているものは通読しないで、こまったとき引く、3回助けてもらえれれば元はとれたとおもう。だからたくさん技がのっているほうが当たる確率が高いと考えている。
読みたい本に出会うために、興味が同じ人が発信している情報をみる、聞く。
目の前の課題を解決したいとネットサーフィンしたとき目にはいった情報をプリントアウトしておいて、喫煙室にもっていってざっと目を通す。細切れの時間で土地勘を養う。
技術書は正確性を期すために細かく規定してあるので、プログラムを解析する感覚で、あんまり深いところは気にしないで、気にしなきゃいけないところとメリハリをつけて読む。
コンサルティング会社なので、ロジカルシンキングやマッキンゼーの本も経営者の考えを理解するために読む。業界の本も必要に応じて読む。違う業界は土地勘がないので、アマゾンのレビューなどをみて、一番うれている入門書を読む。詳しい人の勧める本はレベルがあわないこともある。とっつきやすいものは、たいてい食い足りないので、まんべんなく情報量が多く、定番になっているものを読む。
業界ではなく業務をしりたければ雑誌を読む。現場の空気感がある。入門書だけだと現場の人間とは話がはずまない。
ビジネス書はお客様と同じ語彙でしゃべるためによむ。
読んだ本は読書ノートにしている、まじめに書くと続かないので、1冊3行くらい、タイトル、著者名、感想1-2行とか。
読んだ本をひとことでまとめる作業をすると、自分にとっての意味合いを明確にできる。リファレンス系なら、何の課題にために買った、解決できた、記述もしっかりしていたなどと、かいておく、時間ができたらまた読み返すと違う感想があるのでそこを1行かく。まとめておくと何ができるかをアピールするときに役にたつ。
メソッドとしては「量を読む」嗅覚もつくし、目も磨かれる。目の前の課題を解決してくれる本を選べるようになるのは重要。
目の前の仕事に追われてリファレンスをめくるだけだと場当たりの技術だけを追い求めることになってしまって、技術の概念がつかめなくなってしまう。
本をよむことで、地力、コンピテンシーが育つ。


平鍋健児　好きなことを人につなげる
オブジェクト指向技術、アジャイル開発、ファシリテーションのコンサルティング
メンテナンス性の高いプログラムをもとめてオブジェクト指向にであった。読むときは洋書とか意識せず、タイムギャップをうめるために読んでいる。
気になるキーワードの本は全部買う。前書きと目次だけしか読まないこともある。
読んでもまとめない。いいフレーズだけ紙にかいて壁にはったりしている。書評は昔かいたり、部内で読んでおくべき本リストをつくったこともある。ワインバーグだと「ライト、ついていますか」がおすすめ。
プログラミングでもHowToや文法でなく「なぜこうなの？」が重要なので技術を作った人が書いたバイブルみたいな本が好きで、まず読みたいと思う、
おすすめ
Kernighan & Richie
James Gosling
Guy Steel
Bertrand Meyer
まつもとゆきひろ
Grady Booch
Ivar Jacobson
James Rumbaugh
Tom Demarco
Tim Lister
Gerald Weinberg
Frederick P.BrooksJr.
技術の基盤と目的を理解する。±１運動＝自分がそれを作ってお客さんはどうつかうの（プラス１）、JavaでプログラムをかいたけどJavaVMってどうなっているだろう(マイナス１）で考える。上下両方の理解が必要。
好きの理由がわからないとモノがいえないので、価値観を示している本が好き「理科系の作文技術 (中公新書 (624))
」、XPの白本
高校までまったく本をよまなかった。ロジックですべてわかると思っていた。でもそれでは男女の恋愛とかまったくわからないので大学からは本を読んだり映画をみたりジャズを聴いたりするようになった。今の自分がやっているのはソフトウェア開発を批評空間とした批評活動ではないか。
新幹線では小説を読む。何度も読むと自分の成長を感じられる。
情報収集では自分とよく似た興味を持つ人が、どういう発言をしているか聞くのが一番てっとりばやい。
たくさんよんで、興味あるところを掘り下げる。縦の強さが、横の広がりになっていく。掘り下げたものをもっていないとだれも相手にしてくれない。
重要なのはハート、好きなことが持てるかどうか。
羽生義治の「決断力 (角川oneテーマ21)
」のなかの言葉「才能とは、継続できる情熱である」


浅海智晴　自分のスタイルを持つ
大学教授、オブジェクト指向、Java,XMLに関する活動。
本を買うことは将来への投資。わからなければ買っちゃう。
速読と精読をつかいわける、ちゃんと読まないといけないなら何年もかけることもある。
原典はちゃんとよむ。
原典から派生した本は疑いながら読む。
原典が何冊かあるならクロスチェックして読む。そしてみんながかぶっているところは大丈夫とチェックする。
ネットは情報を整理するのに使う。勘違いもたくさんある。
客観的な事実をつみあげてこそプロ
知識を組織化するには、だれかの視点を使う。
蓄積したものを交流するのは意味があるが、そうでないと顔見せ以上にはならない。交流よりまず蓄積。
ミッシングリンク＝これさえあればを探す。新しい技術は、「あの問題を解決できるからブレークするんじゃないか」という感じで見る。
流行りそうだからとやっていると中途半端になるので、自分がこうかなと思うことをやるのがいい。慈雨bんはたまたまやっていたことが波になっただけ、流行ると思ってやっていたわけではない。
「自分が楽しいとおもっていることをやると、自然にお金が入ってくるシステムをどう作るか」が大事。
生活習慣も同じ、どんなものを食べ、どのくらい仕事して遊ぶか。自分のフォームをきちんとつくる。


柴田芳樹　基礎を固めて継続する
富士ゼロックス社員、ソフトウェア設計コンサルタント。
読みたいのが洋書なので洋書が中心。初心者、中級者用は浅い。
いい技術書をしるためにアメリカの出版社のホームページを定期的にチェックする。
雑誌より専門書のほうがよい。
英語を読むのに必要なの文法力、次に基本単語をきっちりおさえる。しっているからと調べないとおもうと違う意味だったりする。
図に書いてみると理解できているかわかる。
専門書にはまちがいがけっこうある。100％正しいと思わないこと。
間違いは知らせてあげる。そのとき「英語の敬意表現
」という本で勉強したことを使った。
新しい技術に仕様書があれば読む。一度ではわからないので繰り返し読む。
勉強会をひらいている。週2回5か月で1冊の本を読む。参加するときは教えてもらえるではなく、自分から学ぶ姿勢でいくと成果がでる。
新しいことに興味をもって使ってみるのが重要。業務のどこかで役にたつ。
時代とともに消えていかない、基礎(アルゴリズムやデータ構造）は、本質的なことを知っていないと解けないときに役にたつ。
新卒のときこそ、しっかり学習する習慣をつくることが大事。5年で1人前に仕事ができないとそこまで。
途中やらないことがあってもとにかく継続すること。
いい本にであうと視野がひろがる。「Effective java」など


荒井玲子　「本物」だけを読む
富士ゼロックス、日本ラショナルで、オブジェクト指向導入、研究開発、人材育成活動。
あたらしいものをすぐに知りたければ、ネットが雑誌。英単語は辞書。
本は著者は翻訳者から、次は出版社。何度も増刷されている本をだしているようないい出版社を選ぶ
本の引用から他の本を探す。
手帳に読んだ本を書いておく。技術バカにならないために。あと買いすぎて破産しないために。
知らない分野の洋書は索引のついているものを買う。用語があまりに知らないものばかりなら、読まないで1年後にもう一度ひらいてみる。
技術書は1冊まるまるより、部分的に深く読む。何度も読むべきと思ったもの以外は売る。
速読を覚えた。「Power　Reading」
経営者を説得するためにビジネス書を読むようになったが、ドラッガーなど本物だけを読む。
本物は一番底に基本がある。基本がないとワザを覚えてもすぐに役にたたなくなる。
プログラムが動いておもしろいでおわってしまうと設計できない。教えるときは具体例をやらせてから基本に戻って説明する。
ものづくりは「美しい」ものにこだわる。コードの設計も同じ。
アーキテクトに必要なのは変化を予測すること。技術は人を変える。
技術は違ってもやることは同じなので、一流のプログラマは違う言語でもすぐ覚える。抱えている知識が違う。
他の人の経験値を得るという意味で、本はお得。
考え方のキャパシティを広げるには、あふれてもいいので一度パーっと頭にいれてみるのがいい。
ヒューマンスキルはモデルを探す。いなければ本で「闘うプログラマ」とか。
上司も率先して本を読むのが大事。


二上貴夫　外の世界に目を向ける
東陽テクニカ　ソフトウェア・システム研究部部長。IEEEソフトウェアのゲストエディタとしてMDD特集を編集。
情報があふれているので、検索エンジンを使って良い情報に素早くヒットさせる技術が必要。検索法とボキャブラリーを勉強する。
読んだ本は時系列で整理、そうするとアクセスが定期的にある本が一定の場所にキューイングされていく。「「超」整理法―情報検索と発想の新システム (中公新書)
」と同じ。
速読ができると会議などで自信になる。
好きな本で慣れるとよい。
わからなくてもとにかく1冊読み通す。英語を身につけるのに役にたった。
だめもとで著者にコミュニケーションしてみる。
翻訳がダメだとおもったら捨てる。
わからないものはとっておいてあとでみる。捨てない。
ソフトやさんでもハード（現実の世界の動き）を理解するのを忘れてはいけない。
最先端をおっかけるより、自分の足場を固める。
海外で仕事すると、仕事以外の情報がないと仲良くなれないと思って、書評をたよりに他の知識を読むようになった。
「同門」という茶道の本からソフト教育のヒントをもらったこともある。どんな情報でも役にたつ。自由度の高いSEならなおさら。
単なるプログラマでなくエンジニアやアナリストとしてシステムレベルのスキルが必要なことをやりたい人が増えてほしい。それにはノウハウものだけではだめ「困ります、ファインマンさん」など説明することのお手本としておすすめ。
ソフトウェアの最終的な問題は日本語がかけて読めるか。


山崎敏　知識と実践をループさせる
自称「武蔵流プログラマ」。
自分のレベルとあっていないと読んでもおもしろくない。１・２冊よんで嫌いだからってあきらめない、気にしない。
本屋にあってもリンクは張れないので、どんなことが書いてあったかだいたい覚えておいて置いておくだけでも意味はｎある。
言葉には力があるのでカバーはかけない
ネットはばらばら、本はまとめてある。なんで本を書こうとおもったのかから得られるものはある。
書いてあることは最低ライン。本のとおりだけでなく、もっと試して、どうしてそれを選んだのかいえないといけない。
本に書いてあることは書いた人の考え、感じて次につなげることが大事。
読んでやるだけでは意味がない。PDCAサイクルで全体をまわさないと。
本に書いてあることをうのみにしない。テクニックに頼るとかえってバグが増えるようなもの。
視点を変えてものをみましょうという本。「金持ち父さん貧乏父さん
」
お客さんがハッピーにならなきゃ、いいものをつくっても意味はない。技術書だけでは外の世界は見えない。


萩本順三　理想と現実をつなげる
豆蔵取締役。政府技術顧問やIT戦略の企画・実施を支援。
早くたくさんよむのばかりにこだわると、自分の考えがなくなる。情報発信する立場だから人の真似をしない、余計な情報をいれないようにしている。
技術を受け入れる「器」をつくる。目的、概念、メカニズム、具体例に分けて考える。
本質に注目する。よけいなことは連想記憶で思い出せる。オブジェクト指向の言語はメカニズムやコンセプトのレベルでは共通だが、なんで採用したかにその言語の特徴がでている。
若いときはたくさんよんだ。ひとをきにせずがむしゃらによんで、わかんないのはおいといて後でわかるようになってよんだ。
ソースのロジックの意味はイメージでとらえるようになったらわかるようになった。
もとは会計士をめざしていた。いまでもその知識は役にたっている。
しらない業界の人と仕事するときには、一応勉強するが、相手の知識をいれて、整理して返すことで成果をだしている。
自己主張もいきすぎると傲慢、「荘子 第1冊 内篇 (岩波文庫 青 206-1)
」でブレーキを踏む、周りをみて考えることができるようになった。
人がわからないことを形にするはすべのビジネスに当てはまる。ひとにどう理解させるかが重要。
オブジェクト指向は人間が物事を認知する方法。ソシュールがおもしろかった。
理想と現実は違うが、つなげる努力はすべき、ただ深追いははまってしまうのでロスがでる。
伝えることの限界はある。だからオブジェクト思考は続く。
仕事はモチベーションの高さで決まる。能力ではない。

SEの読書術 -「本質を読む」力を磨く10の哲学

• 作者: 浅海 智晴/荒井 玲子/後藤 大地/柴田 芳樹/萩本 順三/原田 洋子/平鍋 健児/二上 貴夫/山崎 敏/山本 啓二
• 出版社/メーカー: 技術評論社
• 発売日: 2006/01/30
• メディア: 単行本（ソフトカバー）

タグ：浅海 智晴

ネットワークはなぜつながるのか 第2版 知っておきたいTCP/IP、LAN、光ファイバの基礎知識

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タグの例で解説。 最後に見開き４ページでパケットが通る道筋を一覧にしていた。左から物理的な装置やケーブル、メッセージの種類や電気信号、ヘッダーで解説。 索引。

ネットワークはなぜつながるのか 第2版 知っておきたいTCP/IP、LAN、光ファイバの基礎知識

• 作者: 戸根 勤
• 出版社/メーカー: 日経BP社
• 発売日: 2007/04/12
• メディア: 単行本（ソフトカバー）

タグ：戸根 勤

NFS &amp; NIS (NUTSHELL HANDBOOKS)

1992年に発行されたNFSとNISの解説本。
今ではかわっているところもある。


大型コンピュータを何百人のユーザーが使用していた時代が終わり、ローカルエリアネットワークが使われだして10年。
ネットワークによる分散処理が普通になり、ファイルサーバー、計算サーバー、プリントサーバーといった専用システムを介して計

算機資源を共有する時代。
分散処理環境下では使いやすく有機的なネットワーク構築ができる反面、管理が複雑になる。

ネットワーク上の各マシンにすべてのファイルとコンフィギュレーション情報を一貫性をもって提供することが必要で、
それを意識しないで利用できる仕組みがNetwork File System(NFS) と　Network Infoation service(NIS）
どちらもSun Microsystemsが開発したプロトコル。

NISを利用するとパスワードファイルなどの同一の内容を複製して維持すべきコンフィギュレーションファイルを、1台のホストで集

中管理できる。更新もホストのみですむ。

NFSを利用すると、ネットワークを意識しないで、リモートファイルシステムを使用できる。
すべてのマシンで１つのファイルセットを共有できるので、そのセットのための物理的なスペースがネットワーク上のどこか1か所にあ

ればいい。

NFSはファイルシステムの物理的な保管場所を意識しないで、ネットワーク上でファイルシステムを自由に使用できる仕組みだが

、ユーザー情報グループ情報がまちがっているとアクセスできない。
NISでサービスすることで、どのワークステーションからでもそれが自分のグループのものであれば、自分のホームディレクトリにログイ

ンできて、資源を利用できる。
またコンフィギュレーションやディスク資源を一括管理できることはシステム管理者にもありがたい。

NFSをつかえばなんでもかんでも手に入るが、それよりは簡潔なネットワーク構成を考えること。
必要なファイルやユーザアカウント情報、システムサービスに”だけ”アクセスできる簡潔さは、多くの利用者を扱い、システム管理

者の労力を軽減する役にたつ。


対象読者
NISやNFSを使用しているシステム管理者ネットワーク管理者。
これから導入を検討している人。
UNIXのシステム管理やTCP/IPネットワーキングの基礎知識がある人。


目的
NFSやNISを使用して分散処理環境下でしばしば遭遇する問題の解決方法を紹介すること。
個々のベンダーのユーティリティーなどにはふれない。


対象バージョン
SunOS4.1 NFSとNISの実装に準拠。SunOS4.0でもあてはまる。
PC/NFS3.5準拠

第1章から9章
NFSとNISの実装と操作の解説

第1章　ネットワーキングの概要
　NIS・・・共通コンフィギュレーションファイルを分散データベース化してNISが管理する。NISクライアントはローカルなコピーを使

用しないでNISサーバーに要求する。
　NFS・・・分散ファイルシステム、NFSクライアントはNFSサーバにあるファイルシステムをマウントしてローカルディスクのように使う

。

　ISOの7階層モデル
　　　層７　アプリケーション　NFSおよびNIS
　　　層６　プレゼンテーション　XDR　異質なネットワークで有効。
　　　層5　セッション　RPC　ネットワーク接続の設定と維持の定義
　　　層4　トランスポート　TCPまたはUDP　ネットワーク層にあわせてデータ分割。着信の信頼性を確保。ポート番号
　　　層3　ネットワーク　IP　データフォーマットの互換性をとる。データグラム。　IPアドレス
　　　層2　データ・リンク　ネットワークのデータフォーマットが定義される　「パケット」　MACアドレス
　　　層1　物理　イーサネット
　下位層のレベルが正常に動いているのが前提でNFSとNISは動作する。

　IPアドレスの予約番号
　　０・・・ネットワーク番号を作成するためにプレースホルダーとして使用される。またIPブロードキャストアドレスとして使用される

ことがある。
　　１２７・・・ホストのループバックインターフェースに使用される。
　　２５５・・・IPブロードキャストアドレスに使用。

　RPC・・・リモートプロシージャコール。ローカルシステム内で処理されるように見せながら実際にはネットワーク上の別のマシンで

プロシージャ・コールを実行する仕組み。

　XDR・・・カノニカル形式と呼ばれる固定ネットワーク・バイトおーだリングに基づいて構築されている。個々のマシンの特異性と

は無関係に構造体データ（バイトストリームと対比した場合）の受け渡しが簡単にできる。

　コネクションレスサービス・・・接続時間の長いconnectionをクライアントサーバーで生成する必要がない。

　RPCはコネクションレスサービス。要求を送信し、応答を受信するためにサーバーと交信するが、そのための接続手続きは必要

ない。RPCサーバーはブートプロセス時に起動され、シングルスレッドで実行される。２つたてられることもあるが、sの場合要求は

待ち行列に入る。ポートやスーパーサーバは使わず、etc/rpcのサービス番号が指定されている。RPCプログラム番号からポート

番号へのマッピングには、ポートマッパデーモンを使用する。よってクライアントからのRPC呼出にはポートマッパデーモンが走ってい

る必要がある。


第2章　ネットワーク・インフォメーション　サービス機能
　ＮＩＳを使って分散型コンピュータ環境で、共通コンフィギュレーションのファイルを個々のマシンで持たず、一括で管理することで

、大規模なネットワークでも一貫性を確保できる。管理するのはパスワードファイルやグループファイル、ホストファイルといった、共

通するもので、ホスト固有の情報を含むもの　etc/ftab　などは含まない。

　２．１マスター、スレーブ、およびクライアント
　　ＮＩＳはクライアント・サーバーモデルで構築されている。
　　ＮＩＳサーバーはマップと呼ばれるＮＩＳデータファイルをもつホストのことで、クライアントはこれらのマップにデータを要求するホス

トである。
　　ＮＩＳの一つのマシンだけがマスターとなり実体＝ＮＩＳマップをもち、それがスレーブ・サーバーにコピーされ、ＮＩＳクライアントは

自分のローカルファイルでなく、ＮＩＳのマップをみにいく。変更はマスタだけで行う。扱うマップはドメインと考えられる。
　　マップごとにドメインをつくることができる。各マシンはディフォルトドメインがあり、参照するＮＩＳマップが特定されている。小規模

ネットワークでは通常ドメインは一つである。

　２．２ＮＩＳ管理の基本
　　ＮＩＳの動かし方。ＮＩＳサーバーを設定して、クライアント・ホスト上でＮＩＳが稼働するようにすること。
　　NISサーバーは可用性と要求処理能力が十分なものを選ぶ。サーバーからの応答がおそければクライアントはスレーブ・サー

バーを探す。各マスターサーバーにはすくなくとも一つスレーブ・サーバーをもたせたほうがいい。スレーブ・サーバーとのマップファイル

の同期も重要。

　　　サーバー作業
　　　　・新規のＮＩＳ環境をインストールし、マスターおよびスレーブ・サーバーを構築する。
　　　　・システムをＮＩＳのサーバーとして働かせるypserveデーモンを起動
　　　　・ネットワークの規模が拡大したりＮＩＳの性能向上のためサーバーの処理能力がさらに必要になった際に、新規のスレー

ブ・サーバーを追加する。
　　　クライアント作業
　　　　・クライアントの管理ファイルを修正し、クライアントがＮＩＳを利用できるようにする
　　　　・ypbindデーモンを起動し、クライアントがNISに要求を送出できるようにする。

　　マスター・サーバーの設定説明。　　　
　　　NISで管理されるファイル（UNIX標準ファイルの他に/etc/netgroup）
　　　インストール方法は、まずドメイン名を決めて、/etc/passwordファイルに+::0:0::が無いのを確認して、初期化コマンド

（/uer/etc/yp/ypinit -m）実行。ドメインにマスターは一つだけ。NISサービスを起動(ypserve）。普通サービス起動はドメイン

名が設定されているば行われるようにrc.localに書いてある。

　　スレーブ・サーバーの設定説明
　　　　初期化コマンド（/uer/etc/yp/ypinit -s　NISマスターサーバー名）実行。
　　　　自動でマスター・サーバーからマップファイルをコピーする。
　　　　スレーブ・サーバーはマスタのypserversマップに追加される。ypcatでダンプして追加する。

　　クライアント・ホストの設定説明
　　　　クライアント上のコンフィギュレーションファイルにNIS「マーカ」のエントリ（/etc/password や　/etc/groupのLではじまる

行）が必ず含まれているのを確認。これがないとNISマップ情報をローカルファイルに組み込めない。
　　　　domainnameユーティリティでクライアント上のNISドメイン名を設定する。
　　　　NISサーバを決定しドメイン名からサーバーをさがし、バインドを行うypbindデーモン起動。
　　　　NISが動いて、もローカルのコンフィギュレーションファイルが参照されなくなっても、は消さない方が良い。単体でたちあがれ

なくなるので。特に/etc/hostはNISが動きだすまでに必要なので消してはいけない。

　　NISサーバーをクライアントとしても動作させるのは、やったほうがいいといっていた。
　　ただし、セキュリティが弱くなるので別のパスワードファイルを使うなどの対策をとった方がいいといっていた。

　２．３NISにおけるファイルの管理
　　　NISで管理されているファイル中でとくに共通性の高いもののリスト。マップ名、ニックネーム、アクセス方法（検索キー）、内

容（ファイル名）　マップの利用形式（追加、置換など、ローカルファイルに対する操作）の順にのっていた。マップとファイルは1対1

ではない。
　　　netgroupはNIS管理のための新規のデータベース。/etc/groupとは異なり、記述の簡略化やニックネームを作成するため

の仕組み。
　　　NISマップとローカルファイルの統合。NISマップのオーバライド。
　　　＋記号を使うとNISマップまたはマップの一部をNISにより補てんされるファイルに組み込むことができる。passwordファイルな

どで説明していた。
　　　
　２．４　NISの設計と実装
　　　NISはRPCプロトコル上に構築され、クライアント・ホストからサーバーへの要求転送にはUDPトランスポートを使用している

。NISサービスは標準UNIXライブラリコールに組み込まれている。例えば/etc/paswordを読み込むのに使われるのは既存の

getpwuid()である。そのためNISを使用するために既存のソフトウェアを変更する必要はいっさいない。

　　　マップファイル
　　　　DBMデータベースファイル（UNIXに実装されたもの）で構成されている。
　　　　キーワードと値の組み合わせのテーブルをもち、高速検索する。
　　　
　　　マップ構成や名前、DMSデータベースの生成方法などが解説されていた。
　　　
　　　NISドメイン・・・同一セットのマップを使用するホストのグループ。ドメインに属するすべてのマシンはパスワードファイル、ホス

トファイル、およびグループファイルに関して同じ情報を共有する。
　　　ホストが属するデフォルトドメイン名を設定するにはdomainnameコマンドを使う。

　　　Internetドメイン・・Internetworkネームサービスにより管理されているホスト・グループを指す。共通の管理下におかれたホ

ストのグループとして厳密に定義されている。

　　　ypservデーモンが起動していればNISサーバである。このデーモンが要求を処理する仕組みを解説。
　　　ypbindデーモンが起動していればNISクライアント　。クライアントプロセスとサーバをバインドする、あとはサーバとやりとりしな

い。

　　　NISサーバとクライアントのイベントシーケンスをgetpwuid()ライブラリコールを例に説明。ローカルでみつからないとNISを使用

して探す。まずypbindがサーバ情報を返し、NISサーバーに要求をおくるとｙｐservが処理して返す。タイムアウトが発生すると

ypbindが以前つないでいたサーバ情報をつかって再接続をこころみる。何回か失敗すると他のサーバを探す。

　　　NISを使用しているマシンは、NISとのバインドが切れるとほとんど使えない。信頼性のなるNISサービスが必要である。


　３章　NISを用いたシステム管理
　　　NISを使っても、マップ参照の負荷や、NISのメンテナンスツールの負荷で、ユーザの通常の作業を邪魔しないようにしなけ

ればならない。
　　　NISドメインをいくつ使用するかは、計算機資源をどのように分割したいかによる。よく使われるのは管理用のドメインとネッ

トワーク用のドメインの２つに分割する方法。
　　　上記の判断基準は
　　　　　・独自のネットワークを持つ分離されたグループのために別個のドメインを用意する。
　　　　　・独自のシステム管理者を持つシステムのグループには、各グループごとに別個のNISドメインを用意する。
　　　ただし、特定のマシンへのアクセスを一部のユーザに与える為の手段としてNISドメインを確保してはならない。特定の分割

グループを作成するための最善策はネットグループを使用してドメインの部分集合を作成する方法。

　　　ドメイン名のつけ方例、ユニークであれば制約がないが、例として階層的な名前などをあげていた。
　　　NIS要求を延々と生成するタイプの作業はまれなので、NISドメインに能力が同等のクライアントとサーバがあるなら、クライ

アント３０-４０にサーバ一つくらいが目安になる。もちろんブリッジされているなどの状況によって変わる。

　　　マップファイルの管理は、マスターでmakefileとNISのMakefileを利用してスレーブに送りつける（PUSHする）方法と、ypxfrを

使用してスレーブ・サーバからマップを取り出す（PULLする）方法がある。
　　　他にcronを使ってypxfrの機能を使って、定期的にマップを転送するようにすべき。
　　　恒久的な変更はマスターで行わないとできない。スレーブを変更しても上書きされる。
　　　管理者が複数いてマスタの変更を同時に加えて矛盾が発生しないように、、SCCSまたはRCCを利用する。
　　　パスワードファイルの更新を例にマップの管理を説明。
　　　SCCSでの管理方法を説明。
　　　標準以外のマップ作成方法を、/etc/password 意外のファイルからパスワードマップを生成する例で説明。

　　　NISサーバ管理
　　　　プリンタスプーラの変更など、サーバを移動させるような場合の記述がマニュアルにないらしい。
　　　　スレーブサーバの移動方法・・・そのマシンのホスト名をypserverマップから取り除き、そのマシンの上のNISを止める。
　　　　マスターサーバの移動・・・新規にマスターにするマシンにスレーブをたちあげる。ここで新しいマスターの構成の新規マップを

作成。これをマスターにypxfrで吸い上げる。これをすべてのマシンに配布。元マスターをNISサービスからはずす場合はypservers

からはずす。

　　　　マルチドメイン・・・単一のサーバーが複数のマスターのスレーブになっているとか、マスターでありながら、他のマスターのスレ

ーブだとか。
　　　　ypserversマップでドメインごとに設定される。例として、host,alias,rpc,servicesは共有しながら、異なるpasswordと

groupをもつマルチドメイン構成があげられていた。

　　　　NISとDNS
　　　　　DNSの利点は、名前管理が分散されること。自分の管理下の名前をどう変更しようとも、中央に通知する必要がな

い。もちろん同じ名前がついていても区別される。
　　　　　NISをDNSの最下位構造に組み込むことができる。いくつかのネットワークがDNSドメイン内に存在し、複数のシステム

管理者により管理されている＝NIS
　　　　　NISとDNSの統合方法
　　　　　　　・NISをDNS抜きで走らせる＝ディフォルト
　　　　　　　・NISマップを参照して解決できない時にはDNS使用する。NISのhost関連のマップを-bフラグをいれて生成する。
　　　　　　　・ホスト名についてはNISを無視してDNSを使用する。ホスト名を検索するライブラリルーチンを再構築してNISのラ

イブラリコールを取り除く必要がある。
　　　　　NISとDNSを同時に使うときはNISのドメイン名とDNSのドメイン名を対応させる。DNSドメイン名.NISドメイン名にして

おくとよい。


第4章　ＮＩＳを使用したアプリケーション
　ＮＩＳを利用したカスタムアプリケーション。

　方法は３つ
　　１．ypmachやypcatなどのNISクライアントツールを利用する方法。
　　　　　例としてASCIIファイルをNISファイルに変化し、電話番号のNISマップを参照する。
　　２．NIS固有のツールを使い、rdistなどのUNIXのユーティリティ機能を拡張したりエミュレートしたりする。
　　　　　コンフィギュレーションファイルからクライアントが必要な情報を取り出す方法。
　　　　　rdistとgrepの機能を合わせたようなホスト固有の集中管理をつくる。
　　３．NISクライアント・ライブラリを使い、CプログラムからNISドメインのすべてのマップにアクセスする方法。
　　　　　NISのライブラリコールの紹介。例としてSunが寄付で作っている株価情報サービスで、寄付者のNISマップとユーザー名

を照合するプログラムをあげていた。


第5章　NFSを用いたシステム管理
　　Network File System(NFS)は、分散型ファイルシステム。
　　NISがユーザやホスト情報を集中管理できるように、NFSはいくつものディスクを集中管理できる。
　　/user/localのような共通ディレクトリを全システム上に重複してコピーするかわりに、NFSでは１つのコピーを1か所に保管す

る。
　　NFSを利用することによって、ホストはリモートとローカルの区別なくファイルを利用できる。
　　NISとNFSはいっしょに利用されることが多い
　　
　　NFSもRPCプロトコル上に構築されている。ホスト間にはクライアント・サーバー関係が成り立つ。
　　NFSサーバーは１つまたは複数のファイルシステムを持ち、ネットワーク上の各ホストに対しそれらのファイルシステムを利用可

能にするホストのこと
　　NFSクライアントは、１つまたは複数のサーバーからファイルシステムをマウントするホスト。
　　NFSの資源は、すべてのクライアントによって共有されるサーバー上の物理的んディスクドライブのこと。

　　NFSを介してシステムを管理するには、ファイルシステムの名前付けとマウントの枠組みを考える必要がある。
　　枠組みが決定したら、それにあわせてサーバーとクライアントをどのように配置するか考えなければならい。
　　名前付け規則はネットワーク自体の存在を意識せずに、ネットワークから利用できるようなものにするのが目標。
　　ユーザーがNFS自体の存在を意識しないのがよい状態。
　　何百台ものクライアントがつくと複雑で手に負えなくなりがち、上手に管理するには標準的な手順に若干の知性を加味す

る必要がある。ネットワークの一貫性を維持するコストが大きな管理オーバーヘッドとなってはならない。管理ツールオートマウンタ

などを使う。

　　NFSの設定
　　　クライアントとサーバーでNFSを設定するにはNFSRPCプロトコルのデーモン、ファイルロッキングなどの補助的サービスのデー

モンをを起動。その後NFSサーバーからファイルシステムを公開（export）し、クライアント上でマウント。

　　　クライアントでNFSを使用するには、biod rpc.lockd rpc.statdデーモンを起動(ブート起動が一般的）

　　　ネットワークに公開されるファイルシステムを持つホストがNFSサーバー。
　　　サーバーは現在公開しているファイルシステムとファイルシステムのアクセス制約情報をファイルテーブルとしてもち、NFSマウン

トの要求があればｍ要求されたファイルシステムをテーブルに登録されているエントリと比較する。
　　　サーバーはブート時に/etc/exporttsの存在をチェックして実行。その後nfsd epc.mountdのデーモンを起動。
　　　公開の法則と、オプションを解説。

　　　NFSクライアントはNFSサーバーが公開したファイルシステムであれば、どのようなものでも、一部でもマウントできる。
　　　方法は/etc/fstabファイルに登録するか、mount(8)コマンドを使用する。
　　　両方の方法の詳細を解説。
　　　マウントは普通すべてhardで行われ、タイムアウトしてしまったRPCはサーバーが応答するまで再実行される。
　　　マウントでよく起こるエラーメッセージの解説。RPCが何回もタイムアウトしていたり、別のクライアントにファイルが削除された

りする事態が想定できる。
　　　NFSにおけるシンボリックリンクの解釈。サーバーで解決されて返されたパス名が、クライアントのファイルシステムの範囲外の

場合エラーになる。相対的シンボリックリンクは、クライアントのファイルシステム上のリンクが置かれた位置から解釈され、サーバー

上のファイルシステムでは解釈されない。マウントしようとしたサーバー上のファイルシステムがシンボリックりんくだった場合奇妙なこ

とがおこるかもしれない。
　　　
　　　　名前付け規則
　　　　　　簡潔で効率的な方法で名前が管理されているファイルシステムは使い勝手がよい。そのための規則
　　　　　　　・ユーザのホームディレクトリは/home/hostnameを使用する。
　　　　　　　・各ユーザのホームディレクトリのマウントで/home/homenameでなく/home/usernameを利用する方法がある。こ

の方法だと/etc/fstabが大きくなるが、NFSオートマウンタを使用しているなら、この方が楽
　　　　　　　・クライアントとサーバーの双方で同一のパス名を使用すること。
　　　　　　　・システムの拡張性を念頭に入れておく。例サードパーティのプログラム用のシステムファイルを１つ用意する。
　　　　　　多機能ワークステーションで構成されているネットワークで/user/local/binに適切な実行ファイルだけを置く方法とし

て、個々のバイナリディレクトリに名にマシンの型を拡張子とつける方法を紹介。
　　　　　　各ユーザのホームディレクトリを指しているシンボリックリンクを/uというNFSファイルシステムにおいて、たとえホスト名がパ

ス中にあったとしても、ホームディレクトリやプロジェクトディレクトリを容易に見つけられる方法を解説。


6章　NFSの仕組み
NFSは実装上の設計や仕組みを知らなくてもインストールして使うことができる。しかし、動作不良や性能低下がおこったとき(

実際よくおこる）動作の仕組みをしらないと対処できない。
　透過性のレベル
　　１　NFSがファイルの位置を隠ぺいしすべてのファイルがローカルであるようにみえる
　　２　ファイルシステム間のアーキティクチャの違いを隠ぺいする。
　VFSで１を、v-nodeで２を実現している。

　VFS・・・ファイルインターフェースのスイッチボード。
　VFSオペレーションス・・・ファイルシステムの空き容量を調べるなど、全体に対する操作を行う・
　V-nodeオペレーション・・・ファイルやディレクトに対する操作。

　オブジェクトを指定する仕組み・・・UNIXは拡張子でおこなっているが、NFSはファイルハンドルで行っている。

　NFSはPRCプロトコル型の通信なので、クライアントとサーバーが存在する。
　NFSサーバー側ではnfsdデーモンがクライアントからのRPC要求を受け取る。
　NFSサーバーがマウント要求を処理するために、パス名変換用のrc.mountdデーモンを起動する
　biodデーモンはNFSの性能向上のためで、必須ではない。
　クライアントからみるとread()やwrite()をしているだけで、NFSはこれらのシステムコールの拡張にすぎない。

　NFSのRPCプロシージャは１６個。UNIXのシステムコールがどのようにマップされるかという視点で解説。
　
　NFSのプロトコルはUDP（状態をもたないので、パケットの到着や到着順を保証しない）である。
　このため、クライアントからのNFS要求はすべての情報を持つ必要がある。ファイルに書き込むなら、ファイルファンドル、オフセッ

ト、書き込みブロック数が必要。ここがwrite()システムコールとは異なる。
　idempotentであり、同じ操作をなんど繰り返して要求しても有害な副作用は発生しない。NFSサーバーは最近の要求を履

歴して、同じ操作をよける処理をおこなっている。
　ステートレスなので、サーバーやクライアントどちらがクラッシュしてもリブートすれば何事もなかったかのようにNFSが利用できる。

ここがデータベースなどと違うところ。

　RPC要求はクライアントからサーバーに同時に１つずつ送出される。このときタイムアウトをつけており、タイムアウトになると再送

する。これを繰り返す。クラッシュなのか過負荷なのかの判別はしない。
　サーバーは到着順にRPCを処理する。
　サーバーがRPC要求の履歴を保持する期間は短めに設定されている。

　NFSではVFSの定義によってすべてのファイルシステムにおいて同一のセマンティクスを保証している。
　VFSを使ってファイルシステムを非UNIXセマンティクスとして実装することも簡単にできる。
　オープンしているファイルが削除(remove)された場合の、NFSクライアントはrenameNFS要求をだして、一時.nfs.XXXX
というファイルをつくり、close(）されてから削除するという手順で対応する。
　
　ファイルのパス名は下からLookup される。そうでないと間違ったサーバーにNFS要求を送ってしまうことがあるから。
　例　cliantA% mount server1:/usr/local /usr/local
cliantA% mount server2:/usr/local/bin.mips /usr/local/bin
　カーネルのディレクトリ核検索キャッシュ（DNLC)により、すべてのルックアップがNFSサーバーにいくわけではない。
多くのUNIXマシンのNFSの実装ではファイルのi-node番号、ディスクデバイス番号、およびi-node世代番号をコード化したも

のをファイルハンドルとして使用している。その他のマシン上でのNFSの実装ではそのマシン固有のファイルシステム情報をコード

化している。どちらの場合もファイルハンドルの構造を解釈できるのはNFSサーバだけである。クライアントからは見えない。存在

するのもサーバだけ。
　よってクライアントからおかしくなったファイルハンドルに操作しようとRPCが実行されるとNFSサーバーは「stale file handle」を返

す。
　ファイルハンドルがおかしくなって問題となるのは、あるユーザの作業が他のユーザが使用中のエリアを侵してしまったり、ダンプテ

ープからファイルをフルリストアするなどしたときである。このようなときはNFSクライアントをリブートする必要がある。

　NFSがサーバー・クライアント・モデルと異なるのは、
　　クライアントプロセス自体が呼び出すだけでなく、クライアントのブロック入出力デーモンbiodからも実行されること。
　　性能を向上させるため、NFS九ランとおよびサーバのコードはサーバーデーモンの実行可能ファイルではなくカーネルにすべて

含まれている。
　がある。
　すべてのNFSコードがカーネルに実装されてはいるが、デーモンがいないと複数のNFS要求を並列に処理できない。
　
　UNIXにおけるバッファキャッシュ・・・最近参照されたファイルブロックを格納しておくためのシステムメモリの一部。SunOS4.xや

System Release 4ではバッファキャッシュはページマッピングシステムに置き換えられいる。
　NFSクライアント側のbiodデーモンはNFSの性能を向上させるためにNFSクライアント側のバッファキャッシュの補填と吐きだしを

おこなっている。先読みをするのでNFSクライアントの性能があがる。書き込みも一時バッファキャッシュに書き出しいっぱいになっ

たらNFSサーバーにRPC要求をおくる。

　NFSデーモンプロセスはカーネル内にあるNFSコードをスケジュールを行うためのハンドルにすぎない。
　read()システムコールの動きをクライアントとサーバのカーネルをとおして追跡。
　　・NFSマウントされたファイルに対してユーバープロセスがread()を実行。プロセスにはファイルの存在場所はわからない。
　　・VFSがファイル記述子を対応するv-nodeに変換、タイプに従った読み込み操作を呼び出す。VFSタイプはNFS。
　　　システムコールはNFSクライアント読み込みルーチンを呼び出す。ファイルディスクリプタはファイルハンドルに変換。
　　　クライアントはファイルシステム上でファイルの位置を示す仮想ノード(v-node)をローカルにもつ。ファイルがローカルならこの

ポインタはi-node NFSふぁいるであればNFSファイルハンドルを含む構造体を指している。
　　・クライアントの読み込みルーチンがローカルなバッファまたはページキャッシュ内でのデータ有無を返し、データがあればただち

に返す。
　　・データがない場合、クライアント・プロセスはNFS read RPCを実行。readは8KバイトのNFSバッファ全体を要求する。RPC

要求が完了するまで、クライアント・プロセスがスリープ。
　　・RPCパケットを受け取ったサーバはそれを処理するためにnfsdを１つ割り当てる。
　　　nfsdコードはパケットを受け取り、実行すべきRPCを決定し、ディスク操作を開始。
　　　nfsdプロセスはディスク読み込みの終了まち、スリープ。
　　　ディスクの読み込みが終了した時点でカーネルはデータおよびRPC応答をクライアントに送り返すためにnfsdの処理を再開

。
　　・クライアント上の読み込みプロセスが再開。
　　　NFS read RPC要求が返した8Kバイトバッファからデータを取り出される。データはキャッシュされる。
　　　プロセスが呼び出したread()システムコールがリターンしプロセスの処理が続行される。
　　　上記に平行してbiodデーモンにより送出されたRPCの先行読み込みファイルの先読みを行っている。プロセスがシーケンシャ

ルに読み込んでいれば、バッファキャッシュに必要なデータがなくなるまで、そうとう多くのread()システムコールを実行できる。

　キャッシュ・・・頻繁に必要とされるデータを必要とされるところの近くに保持しておくこと。または将来必要とされることを見越して

データをまえもってロードしておくこと。

　NFSのデータキャッシングとは、ネットワークを介してサーバにRPC要求を送出しないことを意味する。
　分散型システムでは、複数のプロセスが同一のファイルに対して入出力を行っている場合のデータの整合性と一貫性を保証

することが重要。NFSのキャッシュ・ポリシーはクライアント・サーバ関係に状態遷移情報を組み込まずに性能を向上させること。

　NFSではファイル属性情報はクライアント側にキャッシュされる。そして最小有効期間（通常3秒間）存在する。クライアントが

ファイルを書き換えると（ファイル属性を変更されると）それに伴う変更はキャッシュ上の情報に対して行われ、キャッシュの有効期

間もさらに最小有効期間の長さだけ延長される。最大有効期間(通常60秒）変更されなければ、キャッシュからフラッシュされる

。その際キャッシュ上のファイル属性情報が変更されていれば、サーバに書き込まれる。ディレクトリ属性情報も同様。
　biodが先読みしたキャッシュ内容の一貫性を保証するには、ファイルの属性情報が使用される。
　キャッシュ内容の一貫性自体が、キャッシュされているファイルの属性情報を使って行われる。
　読み込まれたデータブロックをクライアント上にキャッシュしてもNFSシステムに状態遷移情報をもちこまない。
　キャッシュ期間が長くなると、データの一貫性に問題が生じるの有効期間を限定する。
　書き込みもクライアントにキャッシュするのは、サーバにキャッシュすると状態遷移情報が必要になるから。
　write RPC要求の完了がクライアントに通知されるまえに、ディスクへの書き出しが必ず完了するようにするために、NFSの

write操作には大きなボトルネックが発生する。3回のディスク書き込み（inode 間接的ブロックポインタを更新するため、データブ

ロックの書き込みのため）があるので。そのためできるだけ大きい単位で書きだす。一度スピード・メモリに書き込むなどのボトルネ

ック解消策が使われている。
　flush-on-close・・・同じファイルに対する入出力が複数のユーザによって実行されてもファイルの一貫性がそこなわれないよう

にする。ファイルがクローズされた時点ですべてのNFSバッファの内容をNFSサーバーに描きだす。
　
　サーバのキャッシュ
　　・ファイル属性情報のためのi-nodeキャッシュ。ディスクから読み込まれたi-nodeエントリは可能な限り主記憶に格納されて

いる。メモリ上でファイルの属性情報が読み書きできるのでger-attributeなどが高速化される。
　　・最後に読み込まれたディスクエントリのためのディレクトリ名ルックアップキャッシュ(DNLC)パス名のと合わせのたびにサーバが

ディレクトリを参照しなくてよい。ディレクトリ検索はディス上で特定の名前を線形に検索するので、比較的コストの高い操作。
　　・ファイルから読み込まれるデータのためのサーバのバッファキャッシュ。NFSクライアントにとって効果的な読み込みキャッシュと

して機能する。

　ファイルロッキング
　　複数のクライアントが同じファイルにアクセスする際のファイル内容の一貫性をより厳密に制御する。複数のプロセスが同時に

同じファイルにアクセスするのを禁止できる。ロッキングは状態遷移情報を使用する操作でNFSの設計思想とはうまく適合しな

い。しかしUNIXファイルシステムのセマンティックスをすべてのファイルについて維持するという目標に適合する。
　　UNIXのファイルロッキングスタイル
　　　BSDスタイル・・・システムコールflock()ローカルの実を対象。
　　　SystemVスタイル・・システムコールfcntl()とlock()ライブラリルーチンによって実装。
　　RPCのロックデーモンrpc.lockd
　　　クライアントとサーバ双方で起動。/etc/sm と　/etc/sm.bak陵ディレクトリでロック状況を記憶。サーバのリブートの通知

も行われ、同じファイルロック状況をサーバ上に再構築する。
　　　クライアントが停止しているときは、ステータスデーモンプロセスを終了し、/etc/sam/bakから当該ファイルを削除して

rpc.statdを再起動。
　　　クライアントがリブートすると、rpclockdはクライアントのロック情報を回復しようとすると、リブートされたクライアントには情報

は残っていないので、結果的にサーバー上のロック情報も消去される。

　NFSの今後
　　・繰り返し要求のサーバ上でのキャッシング。また、クライアント側での再送アルゴリズムのさらなる高速化
　　・AppleShareプロトコルコンバータを介してのNFSの使用。
　　・IBMのMVSなど、非UNIX系プラットフォームへのNFSサーバーコード実装。
　　など


第7章　ディスクレス・クライアント
SunOSまたはSunOS系サーバのディスクレスクライアントについて説明。
　ルートファイルシステムとスワップファイルシステムのサービスに関してNFSを、ホストのコンフィギュレーション情報はNIS
を介して行うのが前提。
　ローカルな資源を持たないマシンを、ネットワークの一員として稼働させるのは、NFS、NISでもっともやっかいな部分。

　ディスクレス・クライアントのためのNFSサポート
　　SunOS4.0以前はディスクレス・クライアントはNDと呼ばれる分散型ファイルシステムプロトコルを課して別個にサポートされて

いた。
　　SunOS4.0ではディスクレス・クライアントのサポートはすべてNFSを介して実行される。これはSunオペレーティングシステムのフ

ァイルへのスワッピング機能（ページングでの仮想記憶管理システムでファイルをスワップエリアとして使用できる）と、NFSプロトコル

のNFSファイルシステムをルートディレクトリとしてマウントできる機能のおかげである。
　　ディスクレス・クライアントはVFSオペレーションのmount_root()を使って、マシンのルートデバイスにする。このため別のプロトコ

ルを使用してルートファイルシステムとスワップファイルシステムのための物理的ディスクブロックをサーバファイルシステムブロックにマッ

プする必要がなくなった。

　ディスクレス・クライアントの設定
　　適切なオペレーティングシステムをブートサーバ上にロードする。
　　クライアントとサーバのアーキテクチャが同じであれば、/usrと/usr/kvm両ファイルシステムをクライアントとサーバが共有する。

異なっていればクライアント用の適切な/usr　と　/usr/kvmがサーバに必要。稼働中のマシンのカーネルアーキティクチャを調べ

るには % arch -k コマンドを使う。
　　クライアント洋のルートファイルシステムとスワップファイルシステムは　サーバーの/export　にあるのが一般的。
　　オペレーティングシステムがロードされていれが、追加するクライアントのホスト名とIPアドレスをNISのhostsマップに登録
　　追加するクライアント用のブートパラメータを設定　/etc/bootparams
　　追加するクライアント・システムのMACアドレスとホスト名をNISの ethersマップに登録。クライアントのMACはネットワークケー

ブルを抜いて起動するとわかる。
　　追加するクライアントのエントリをサーバの /tfpbootディレクトリに登録
　　追加するクライアントのルートファイルシステムとスワップファイルシステムをブートサーバ上に作成 /etc/exports（マウントでき

ること）
　　exportsファイルの具体的な例。

　ディスクレス・クライアントのブートプロセス
　　ディスクレス・クライアントは電源投入時にもっているのは48ビットのイーサネットアドレスのみ、これをブロードキャストでリバース

ARP要求するのがブートプロセスの仕事、このとき飛ばすRARP要求はTCP層やUDP層ではなく、Netwrok Interface Tap

（NIT)デバイスで検出される。よってサーバ側に/dev/nitがなかったり、カーネルにNITデバイスが組み込まれていないとディスクレ

ス・クライアントは起動できない。サーバーは受け取ったRARP要求をrarpdでIPアドレスとホスト名に変換して返す。このとき

/tfpboot　をチェックして自分がサーバを起動するのに最適でないと判断すると応答をおくらせる。
　　ちなみにRARP要求に応答するホストは一つではない。
　　
　　次にブートブロックをftp(trivial ftp)を使って取得する。これは最小限度のファイル転送用ユーディリティでユーザやパスワード

のチェックをしない。ダウンロードは/tfpbootから行われる。
　　サーバはクライアントのアーキティクチャについて/tfpboot　ファイルから得る。
　　RARP要求を返したホストにブートブロックがなければクライアントはｔｆｔｐ要求をブロードキャストする。
　　/tftpbootに登録する最後のエントリは自分自身へのシンボリックリンク。これを取り除くと古いタイプのディスクレス・クライアン

トが正しいブートブロックをダウンロードできなくなる。
　　
　　ブートブロックがロードされうとディスクレス・クライアントはPROMのモニタからブートコードにジャンプする。
　　ファイルシステムの情報を入手するためにbootはブロードキャストでブートパラメータを要求する。
　　これに応答するのはrpc.bootprarad　を実行しているサーバ。ルートファイルシステムの場所。クライアントのホスト名。ディフォ

ルト経路、NISドメイン名、およびブートサーバ名をひとまとめで返す。この情報は/etc/bootprarams　か　bootpraram NISマッ

プに登録されている。クライアントに渡されるNISドメイン名はサーバのディフォルトドメインである。異なるNISドメインに属するクラ

イアントの情報を同一のbootpraramasマップに登録はできない。
　　ディスクレス・クライアントは指定されたブートサーバから自分のルートファイルシステムをマウントして、そこに置かれたカーネルイ

メージをブートする。カーネルもスワップファイルシステムを決定するのにブートパラメータを要求し、これに答えるのも

rpc.bootpraramd　である。そしてクライアントは起動する。ちなみにrpc.bootpraramdデーモンが返す名前およびアドレス情報は

クライアントのコンフィギュレーションファイルの情報と一致していなければならない。コンフィギュレーションファイルの情報はNISマッ

プの内容と一致していなければならない。
　　クライアントが起動して/usrファイルシステムがマウントされてからは、ブートスクリプトの問題で、ディスクレス・クライアントのブー

トプロセスの問題ではない。

　　/etc/bootpraramsファイルの最後に+があれば　NIS bootpraramsマップが追加される。追加されるのはすべてで一部を混

み込むことはできない。
　　NISを使用しているときには、ブートパラメタはbootpraramsマップ上で管理すること。
　　複数のNISドメインに複数のディスクレス・クライアントが存在するのであれば、ドメインごとに別個のbootpraramsマップがある

ことを確認する。そうでないとクライアントが間違ったNISドメインを受け取る可能性がある。
　　多機種のディスクレス・クライアントを有するネットワークでは、各機種が同一の形式でブートパラメタ情報を使用していること

を確認すること。
　　NISマスター・サーバー以外のサーバ上にあるブートパラメータ情報のコピーはなるべく削除しておく。コンフィギュレーションの変

更後に使用不適当な情報がブートサーバ上に存在する可能性を減少できる。

　　クライアントのスワップエリアは、通常実メモリの4倍、少なくとも24メガから32メガ必要。
　　もっと必要になったとき、増やす方法は、クライアントをシャットダウンしてから、旧スワップファイルを削除する、ブートサーバ上

に新規にスワップファイルをmkfileを使って作成する。このときのオプションなど解説。
　　スワップファイルには先行読み込みを実行しない。

　　クライアント名の変更
　　　クライアントをシャットダウンして、ルートファイルシステムとNISマップを変更する方法。
　　　クライアントのシャットダウン以外は実際にはスクリプトで実行するのがよいといっていた。
　　　
　　トラブルシューティング
　　　ディスクレス・クライアントがブートできないときは、まずホスト名、IPアドレス、およびイーサネットアドレスのすべてがブートサー

バとNISサーバ上で正しく登録されていることを確認。
　　　次にブートできなくなった箇所。ブートブロックの決定ができなければブート情報が、シングルユーザモードで立ち上がれない

マシンは/usrファイルシステムがないことが考えられる。
　　　クライアント情報が必要なファイルにかけていたりすれば、止まったところでどのファイルを確認すればいいかわかる。
　　　わかりずらいのはブート要求に応答したrpc.bootparamd　が不適当なマップである場合。
　　　クライアントまたはブートサーバ上でデバッグモードを蔭位するとブートパラメータの内容をチェックできる　b -v
　　　/usrがない場合のよくある原因は、
　　　　　/usrがマウントされるまでNISは起動されないので　ディスクレス・クライアントの小さな/etc/hostsに、自分のホスト名、

localhostエントリ、ブートサーバ名、および/usrサーバ名をもつ必要がある。これがない。
　　　　　機種ごとのアーキティクチャの問題で間違った/usrをマウントしようとしている。

　　コンフィギュレーションのオプション
　　　ローカルクライアントにディスクをとりつけて、スワップエリアとして使用する方法と
　　　　ブート可能なシステム全体を構築し、ルートファイルシステムとスワップファイルシステムファイルを構築する＝データレス・ク

ライアントにする方法を解説。
　　　ローカルファイルを追加する場合はディス容量を小さくしないとユーザファイルの格好の住処になってバックアップが必要にな

る。
　　　ディスクレス・クライアントにローカルディスクをつけても、サーバーからブートできてかつ、ローカルディスクをファイル格納に使用

するには、Genericカーネルのコンフィギュレーションとして明示的に指定する必要がある /sys/srch/conf/name archはカーネ

ルアーキティクチャ、nameはカーネル名を指定。例をあげて解説。

　　クライアントとサーバの比率
　　　クライアントとサーバーの分散具合のテスト方法
　　　・一台のディスクレス・クライアントあるいはデータレス・クライアントをサーバとともに設定し負荷を測る
　　　・クライアントにスクリプトで通常の負荷をかけ点綴的ネットワーク・トラフィック・パターンを実現する。サーバ側で数時間平

均トラフィックを計測、クライアントからの要求がピークに達したときのレートも計測、サーバーが秒あたりに処理するNFS要求回

数を測定（nfsstat)
　　　・これをクライアントまたはユーザのタイプごとに繰り返し実行。
　　　・AppendexDの方法でサーバをチューニングしてベンチマーク実行。
　　　・サーバ能力をクライアント要求レートの平均値で割って大雑把なクライアント/サーバ比率を決める。個々のクライアント

が実行するNFSオペレーションの回数とクライアント数を掛け合わせるとサーバーをチューニングする際の目標になる。
　　　でも。あくまで目安と言っていた。プリンタの駆動などもあるので。
　　　

第8章　ネットワークのセキュリティ
　NISやNFSがもつマシンやファイルシステムへのアクセスを制限する仕組みを解説。
　ただしすべてのセキュリティ対策を網羅したものではない。
　
　＊ユーザレベルのネットワーク・セキュリティ
　　ローカルなマシンへのログインの制限はローカルホストのパスワードファイル、NISのパスワードマップ、ネットグループで定義され

る。
　　ネットワーク上のアクセスは、信頼できるホストと信頼できるユーザとう概念で決定される。

　　信頼されているホストとは、信頼されているマシンと、信頼しているマシンで表される。どのユーザやホストが信頼されているか

はホスト同士の関係がどのようになっているかにより定義される。
　　ホストとサーバの信頼関係
　　　サーバとサーバ・・・一般的にサーバ同士は信頼しあう。NISパスワードマップのサブセットを含むパスワードファイルが各サー

バにあれば限られたユーザが信頼される。サーバ同士の信頼を拡大すれば、１つのセキュリティがやぶられれば他のサーバセキュ

リティも破れる。
　　　サーバーからクライアント・・・ほとんどのクライアントがサーバとサーバのユーザを信頼する。
　　　クライアントからサーバ・・・もっとも制約をうける。サーバの管理をまかされているユーザにだけ無制限のアクセスが与えられる

のが一般的。
　　　クライアントとクライアント・・・ディスクがどのように管理されているかによる。いくつかのファイルサーバで全ファイルを取り扱って

いる場合、クライアント同士の制限は緩やかになる。独自のデータを格納している場合、クライアント同士の関係はクライアント

とサーバの関係に近い。

　　rloginとrshはruserok()を使って通常のログインとパスワードによるセキュリティチェックを回避している。
　　ruserok()は指定されたユーザやホストがローカルホスト上で信頼されているか否か決定する。信頼がなければパスワード入

力をもとめるか、rshなら「Permisson denied」を返す。
　　hosts.equivファイルの定義方法。ネットグループごと許可をあたえたり、特定のホストやユーザごとに許可をあたえたり、ここで

も＋でNISマップが組み込まれる。
　　.rhostsよりもhosts.equivが優先されるが、rootの場合は.rhostが先に参照される。
　　自分のマシンと他のホストで異なるユーザネームを使っている場合は、自分の.rhostsで指定すると変換できる。または rlogin

するとき指定する。
ネットワーク管理者は許可を与えすぎている.rhostsファイルに気をつけるべき。NISで管理されていないプライベートなエントリ

を含むパスワードファイルが数多くあるときには、.rhostsの使用状況を監視する必要がある。パスワードファイルをマージして無秩

序なユーザを排除してしまうほうが、監視より簡単。

　　ネットグループは大きなNISドメインを複数のグループに分割するために利用するのが最も適切。
　　NISマップとかhostsファイルやパスワードファイルにないホストやユーザ名を使用してネットグループの定義をしてはならない。
　　ネットグループの設定方法と、間違えやすいところの解説。

　＊パスワードとNISのセキュリティ
　　パスワードを使用してのごく常識的なセキュリティ保護
　　　　簡単に推測できなくする。設定条件(ナン文字以上など）をつける。辞書にでている単語は必ずみつかる。パスワードを

推測できるプログラムがあったら使用してみよう。同じ土俵で勝負できる。
　　
　　NISを使用してrootのパスワードを管理する。
　　　サーバのルート特権はできるかぎり慎重にほごされなればならない。ローカルのマシンの管理者たちに安易使わせれば、か

ならずシステム管理者に跳ね返ってくる。教えないのは信頼していないからではないと伝えて、全権は掌握しておくべき。
　　　システム管理者がすべてのマシンでスーパーユーザになるためにNIマップの設定方法解説。

　　NISをさらに安全にする
　　　・NISマップをプライベートにするなら、２つ以上のネットワークにつながっているホストをNISサーバにしない。
　　　・マスターNISサーバ上では、サーバのパスワードファイルとNISパスワードファイルを別にする。
　　　・awkスクリプトを使ってパスワードの設定されていないエントリを定期的にチェックする.
　　　・マシンのコンソールについてsecureパラメータを削除すると、ルートパスワードを示さないとシングルユーザモードではブートで

きなくなる。SunOSならブートPROMにセキュリティを設定できるが、ただしパスワードを忘れると新しいPROMを買う羽目になる

　　「Intruder alart」メッセージ
　　　　よくある原因としてはパスワードファイルのUIDフィールドの数字を削除してしまい、その壊れたマップを分配してしまうこと。

UIDが同一でないのにNISパスワードファイルエントリをローカルなパスワードファイルエントリで差し替えてしまった場合もIDのミスマ

ッチを引き起こす。このようなときwhoamiコマンドを実行すると「Intruder alart」メッセージが表示される。
　　　　また、rcp、rlogin、ｒｓｈが実行されるとパスワードマップ中にユーザのUIDがないと「who are you?」と表示される。

　＊NFSのセキュリティ
ファイルシステムのセキュリティは、ファイルアクセスとファイル操作を制限することと、ファイルの内容を関係者以外の目から保

護すること。
　　リモートファイルへのアクセスを制限する＝UNIXのふぃある操作のセマンティクスをNFSシステムにマップすること。
　　ほかにも、NFS要求に含まれるUNIXスタイルの権限の正当性を、チェックしたり、ファイルを暗号化するなどのより強いセキュ

リティがある。
　　なによりも漏えいを防ぐにはNFSマウントされるところに置かないことが一番である。

　　NFSのRPCにおける認証
　　　すべてのNFS要求には、ユーザの認証情報(credential)が含まれる。これはUIDおよびUIDが属するグループID（GID)のリ

スト。この情報でNFSサーバではUNIXでファイルアクセスする際のパーミッションチェックをする。
　　　NFSの認証情報とユーザのローカルな認証情報の構造がマッチしない場合が３つある
　　　　・ユーザの属するグループが多すぎる。RPC人商標法構造体のクライアントのグループ数の上限がサーバのグループ数の

上限より大きい。
　　　　・スーパーユーザのマッピング
　　　　　rootアクセスの付与は各マシンで行うことになっているため、スーパーユーザにはNFSマウントされたファイルに対して通常

のファイルアクセス許可があたえられていない。あるマシン上のrootになれるユーザでもファイルサーバのファイルを修正する許可が

あるわけでない。ルート特権を取得するsetuidプログラムもリモートファイルに使用しても通常の機能や期待した通りの機能を示

さない。
　　　　　スーパーユーザでのアクセスはrootのUIDをNFSの認証情報構造体でぇあ匿名ユーザであるnobody（-2）にマップするこ

とで制限している。サーバのカーネル中でマップされるnododyのUIDを変更してrootUIDマッピングを無効にすればサーバから公

開されたファイルをすでてスーパーユーザとしてアクセスできるが、これは危険。
　　　　　ほとんどのNFSサーバでは公開したファイルシステムに対するrootパーミッションは、root=exportオプションを使用すること

で各ホストごとにあたえられているようになっている。/etc/exportsファイルにこのオプションを指定して登録されているホストに対

しては、ファイルシステムを公開するサーバがrootアクセス権限を付与することになっている。その例。
　　　　　NFSファイルシステムにrootパーミッションを与えても問題ないのは、ディスクレス・クライアントのルートとスワップのパーティ

ションに対してだけであり、当然でもある。
　　　　　NFSマウントされた実行ファイルで、setuidビットがたっているものは信用しない方がいい。また侵入者がsetuidをたてた

実行可能ファイルが置いていくことも考えられる。正規のスーパーユーザがこのファイルを実行すると被害が発生する。nosuidオプ

ションを指定してマウントを行うと、NFSマウントされていてもsetuidビットが設定されている実行可能ファイルの実行でもsetuid

機能は作動しなくなる。これを/etc/ftabのエントリに登録しておくこともできる。

　　正体不明のユーザマッピング
　　　NFS要求に認証情報が欠けている場合
　　　　・Secure PRCを利用しているが、クライアント側のユーザが正しい認証情報をSecure RPCシステムに提供していない。
　　　　・クライアントがPC/NFSを実行しているPCで、PCユーザが正当なユーザ命とパスワードを示していない。
　　　　・クライアントがUNIXマシンでなく、UNIXスタイルの認証情報を作成できない
　　　　・要求が偽物。
　　　ディフォルトでは匿名ユーザはnododyとして扱われる（rooｔも）　公開のオプションとしてanonを指定して匿名要求のサーバ

ー上でのマッピングを変更できる。/etc/exportsに匿名ユーザのIDを設定して、正体不明のユーザを既知のローカルユーザにマ

ップできる。ただしスーバーユーザにしてはいけない。

　　ファイルシステムへのアクセス
　　　特にソースファイルのあるマシンは特定のホストからのアクセスからもほごされなければならない。サーバの/etc/exportsファイ

ルに-accessオプションを指定するとアクセスが許されているホストを記述できる。

　　読み出し専用でのアクセス
　　　/etc/exportsにｒｗオプションを指定することで書き込み許可でファイルシステムをマウントできるホストを指定できる。

　　ポートチェッキング
　　　spoofing・・・正当な権限が与えられていないユーザプロセスから手作りで模倣した正当なNFS要求を送出すること。
　　　NFS要求が正当なNFSクライアントから送られた場合はクライアント上の特権UDP/IPポートから送られているはずなので、

ポートモニタを有効にしてチェックすることができる。
　　　ディフォルトでNFSポートモニタが有効になっている場合もある。カーネル変数で管理されているのが一般的。変数自体は

ブート時にスクリプトのadbを使用して設定できる。
　　　　echo "nfs_portmon/W1" | adb -w /vmunix /dev/kmem
ポートモニタをオフにするにはブートスクリプトでデーモンを呼び出している行に　-n フラグを加える。 rpc.mountd -n
ただし、NFSクライアントコードをPC用に実装したものなど、特権ポートからの要求を送出しないものもあるので注意。
　　　
　　　SecureRPCとSecureNFS
　　　　SecureRPC・・・標準のRPCシステムに認証情報の正当性をチェックする仕組みを加えたもの。DES暗号化と公開鍵

暗号化の二種類をくみあわせている。秘密鍵にはユーザのパスワードなどが良く使われる。この対話手順を解説。
　　　　SecureNFS・・・NFSにSeureRPCを使っているもの。ファイルシステムを公開してマウントする際に、secureオプションを

指定する。（クライアントでも）。
　　　　この仕組みに使う公開鍵と秘密鍵はNISマップのpublickey.bynameで管理されている。このマップはNISマスタサーバ

の/etc/publickeyから構築されるので、NISを実行していなければ鍵を作成できない。ディフォルトの鍵はnobodyのためだけ。マ

ップ内の識別子について解説。
　　　　鍵の作成はスーパーユーザが「newkey -u user」で生成できる(NISマスタサーバ上）このコマンドについて解説。
　　　　対話鍵の生成方法
　　　　SecureNFSが適切に動作するためのデータとデーモンファイルの解説。

　　　kerverosシステム
　　　　MITのAthenaプロジェクトで開発されたNFSサービスをSecureにするための仕組み。SecureNFSとの違いを解説

　　＊ウイルス
　　　　コンピュータウィルス・・・オペレーティングシステムやシステムユーティリティを変更して危害を加えるプログラムコード。
自己増殖し、ベクトルあるいはキャリアを通じて広がる。ネットワーク上のすべてのコンピュータが汚染されることもある。
　　　　UNIXはrootでなければカーネルの書き換えができないので、DOSよりセキュリティが高いと言えるが注意も必要。cronの

エントリ、パブリックドメインから入手した実行コード、root権限で得体のしれない実行ファイルを走らせるのはしてはらないない。
　　　　


第9章　NFSとNISによる電子メールサービスの集中化
　メール設定はDNSによる設定が多くなっているが、ここではNFSとNISを利用したメール設定を解説。
　サイトのメール管理を簡潔にするため、メールhubとよばれる1台のマシンにメールの転送とスプールを割り当てている。
　
　＊共有メールスプール作成
　　　個別スプールではユーザは特定のマシンからしかメールの送信できないし、返信は送ったマシンにきてしまう。またワークステ

ーションのないユーザのメールスプールはどうするか、すべてのワークステーションにsendmailデーモンがが起動していなければならな

い、すべてのバックアップが必要など、あまりよいことはない。
　　　メールhubで集中処理することで、ローカルに変更があってもメールの不達などがおこらないようにする、外部には名前を隠

ぺいして、すべてのメールがよくしられているホストから送られてくるようにみせかけて、内部の変更に影響されないようにする。
　　　NFSでメールhubマシンのスプールディレクトリをマウントして実現する。
　　　ただし全ユーザのメールがはいるのでファイルが大きくなる欠点がある。スプールエリアは大きくもとう。
　　　具体手にはexportsで/usr/spool/mail か　/var/spool/mailを公開する。このときシンボリックりんくであればリンクのターゲ

ットもexportsファイルに登録しないといけない。その後メールスプールのクライアントでｒｗおよびhardオプションでメールスプールをマ

ウントする。 wahoo:/var/spool/mail /var/spool/mail nfs rw,hard 0 0。クライアントのsendmailデーモンはコメントアウトして

停止しえかまわない。
　　　すべてのメールをメールhubから配送するときはsendmailのリモートモードを使うか、エイリアスを使用する。その詳細解説。
　　　メールの到着を通知する仕組みbiffはすべてのメールがメールhub上で配送されている場合には作動しない。
　　　一般的にメールの通知はcomsatデーモンがbiff設定されているかチェックして行われる。NFSでメールスプールをマウントして

いる場合でも、通知をうけれるようにCシェルのmail変数を利用する方法と、ネットワーク経由でuunet.uu.netなどのアーカイブサ

ーバからxbiffを入手して利用する方法がある。その設定方法解説。

　＊名前の隠ぺい
　　　sendmailのリモートを利用するときには名前の隠ぺいは暗黙裡に行われるが、エイリアスの場合は明示的な実行が必要。

メールが送信される前にメールhub上のsendmailに差出人アドレスに適用されるアドレス書き換え規則と受取人アドレスに適用

されるアドレス書き換え規則が必ず含まれている。ローカルのメールを処理するmailerが利用する規則を変更することでhostがロ

ーカルネットワークにある場合、差出人アドレスの形式をuser@hostからuserに書き換えられる。その方法

　＊NISエイリアスの展開
　　　通称ユーザ名を定義するシステム、自動メールハンドラ、ローカルおよび高域用のメーリングリスト作成のためにエイリアスが

使用される。NISでのエイリアスの展開または/etx/aliasesファイルからの展開は以下のようになる。user1とuser2の名前は同

一でも構わない。
user1: user2@host
　　　ベンダーによっては、/usr/lib/aliasesや/usr/lib/mail.aliasesにおくこともある。
　　　自分のエイリアスファイルがどこにあるかはsendmail.cfファイルの前半部のOAオプションを参照するとわかる。

　＊広域エイリアス
　　　広域エイリアス・・・複数のネットワークやNISドメインにまたがったエイリアスの意味。例このサイトのすべての従業員など。
　　　広域メーリングリストの設定
　　　　階層化されたメーリングリストの最上位に位置するマシンを1台選択する。メーリングリスト管理者は、このマシンへのスー

パーユーザアクセスを持っていなければならない。ここでメール配布の名前とメール投降の名前がリストで定義される。エイリアスが

２つ使用されるのはフィードバックループを発生させないため。この階層構造の解説。
　　　存在しなくなったユーザ名がリストに残っていたり、ユーザの自分のメール転送をおかしく指定してしまう、ホスト・マシンが停

止してリストの配布が不能になるなどの問題が考えられる。エイリアスにowner-listを定義すると、これらのエラーはこのエイリアス

に送られる。リストの所有者はNISドメインをリストから外すことができるローカルシステムの管理者がなるべき。

　　　アーカイブと管理
　　　　配布リスト中にローカルファイルを名を記述しておくと、リスト宛てのメッセージを全部マシンにアーカイブしておくことができる

。管理者はときどき、ファイルをリネーム、圧縮してスプールエリアがオーバーフローしないようにするべき。

　＊NISエイリアスとローカルエイリアスの統合
　　ローカルのaliasファイルとNISエイリアスマップを統合してつかうことができるが、これはsendmailデーモンがローカルで起動されて

いてリモートになっていない場合。具体的な例を解説。

　＊メールの転送
　　共有されたメールスプールとメール敗走機構によってメールサービスを集中化させる枠組みとしてNFSとNISは最適だが、メー

ルの転送は逆に複雑になる。
　　メールがユーザ当てに配送されるとき、mailerはユーザのホームディレクトリに.fowardがないかチェックして、他のユーザに転送

したり、シェルスクリプトや実行可能ファイルにパイプでメッセージをおくることができる。vacationユーティリティもこの一種。
　　メールhubがユーザのホームディレクトリをみつけて、転送のスクリプトやフィルタはメールhub上で実行可能でないといけない。

ディレクトリやファイルが参照される場合、それらはメールhubに存在しないといけない（コンフィギュレーションが異なるから）




第10章から第14章は応用編。
ネットワーク環境下のシステム管理やデバッグ技術について解説。
性能の測定やチューニング方法を紹介。


第10章　診断用および管理用ツール
　分散型のアーキティクチャが予想通りの能力を発揮するには、ネットワークがきちんと整備され、サーバが適切にコンフィギュレー

ションされていることが必要。
　ネットワークを変更する際はつねに影響が複数のマシンに及ぶことを考慮すべき。
　NFSクライアントを追加するなら、接続が増える、ノードが増える、ネットワーク処理の能力などを考慮。
　サーバ資源を増やすなら、もっともきびしい状態の資源はなにか認識しておく、CPU速度、ディスク速度、ディスク容量など。

単にサーバーを追加すればネットワークの効率がよくなるのではない。
　NFSやNISネットワークで問題を解析するためのツール、手順、および評価基準を解説。
　NISが稼働していることが前提であり、一般的なNISマップ(下記）を基準とする
　マップ名　 ニックネーム　ローカルファイル
　password.byname passwd /etc/passwd
group.byname group /de/groupe
hosts.byname hosts /etc/hosts
rpc.byname rpc /etc/rpc
services.byname services /etc/services

　＊ブロードキャストアドレス
　　ブロードキャストアドレスはローカルエリアネットワークのすべてのマシンにパケットを送出する。
　　MAC層とIP層があり、MAC層のブロードキャストアドレスは　ff:ff:ff:ff:ff:ffのみ、IP層はいくつかの表し方があるので、ネットワ

ーク全体で揃えておかないと混乱する。

　＊MAC層とIP層の操作を行うツール
　　ifconfig・・・インターフェース・コンフィギュレーション。IPアドレス設定や設定状況の確認　使い方詳細解説。複数のネットワ

ーク・インターフェースに接続するときにはifconfigを複数回使う。

　　ホストの情報の誤り・・・ポートマップのエラー「portmap: Non-local attempt to unset prog 100105」などがでる。原因は

NISのホストマップとローカルのhostsファイル、ホストのブートスクリプトのに登録されているホスト名とIPアドレスに一貫性がないこ

とが多い。

　　サブネットワーク・マスクはNISのnetmasksマップでどうなているとよいのか

　　IPアドレスからMACアドレスへの変換はARP（アドレス・リゾリューション・プロトコル）が使われる。ARP要求でネットワークのトラ

フィックが異常に高くなる状態をARPストームと呼ぶが、まちがって設定されたパケットをブロードキャストパケットを勘違いしたホス

トが異常なパケットを最初に送出したホストのイーサネットアドレスをARP要求で得ようとするためにおきる。トランシーバの電気

系統に問題がある場合が多い。「arp　-a」でARPテーブルのエントリがみれる。その解説。

　　ping・・・ネットワーク上のホストの情報を得る。ネットワークの物理的な接続状況をチェックできるツール。ICPM

（Internetwork Control Message Protocol)を使っている。コマンドの結果の説明。

　　イーサネットインターフェースの処理能力の測定・・・ネットワークが適切に設定されていて、ホストのコンフィギュレーションが正

しくても、ネットワーク・インターフェースに負荷がかかりすぎて交信がうまくいかないことがある。sprayユーティリティでネットワーク・イ

ンターフェースの能力を大まかに測定できる。sprayはリモートホスト上のprc.spraydデーモンにRPCを送出することで、ホストに固

定長のパケットを連続的に送信し、最後のパケットが送出された時点で、受信されたパケット数が、rpc.spraydデーモンから報

告される。これでクライアント・サーバ間のパケット転送レートを算出する。ただし原因の特定は難しい。sprayでわかること（遠い

マシンと近いマシンへうってみるなど）詳細解説。

　＊リモートプロシージャ・コールに関するツール
　　ネットワークに問題があるとすぐに気が付くが、ネットワーク・プロトコル・スタックのような上位の層にあるときは、少数のマシンに

しか影響を与えないので気が付きにくい。
　　RPC層からNFSやNISのアプリケーション層までの機能を調べる為のツール紹介。
　　
　　RPCはネットワーク上のマシンにクライアント・サーバ関係を与える。
　　NFSサービス用に公開されたディスクやNISマップといった共有資源を物理的に所有しているのがサーバ、サーバの資源を

RPCで要求するのがクライアント。
　　RPCサービスの識別は、プログラム番号、バージョン番号、プロシージャ番号、プロトコル（UDPまたはTCP）で行う。
　　この仕組みを詳細に解説。
　　rpcinfo・・・pingのようにRPCサーバに対してポートマッパーが持っているRPCに関するマッピング情報を確認できる。ただし、

セッション層には利用できない。このコマンド結果の詳細解説。
　　
　　RPCの問題点をデバッグする
　　最初にブートされたブートパラメータがまちがっている場合を調べる為に「rpcinfo-b」を実行する方法解説。
　　rpcinfo要求に対して応答するホストがなければ、ブロードキャストパケットがいずれのNISサーバにも到達していないのが原

因。NISドメイン名とブロードキャストアドレスが正しいのなら、ブロードキャストでサーバを探すことはやめて、ypbindデーモンに正し

いNISサーバのホスト名とアドレスを直接渡すようにしてやればいい。

　＊NISツール
　　使うには下位レベルに問題がないことが前提。
　　ypmatch・・・NISマップ用のgrepに相当するもの。使い方解説。
　　ypcat・・・同じくcatに相当
　　
　　クライアントのバインド状況の表示と解析
　　ypwhich・・・引数なしだとクライアントがその時点でバインドしているNISサーバホスト名が表示されるなど、シェルスクリプトを

使った使い方解説。

　　NISのマップ情報をypwhichで調べる方法。
　　
　　ypset・・・クライアントのバインド変更。使い方解説。

　＊NFSツール
　　NFSの操作はどちらかというと静的で結局ファイルシステムをマウントするかしないかの話で、うまく走るのか、まったくだめなのか

という話でもある。
　　NFSが動作していないと、ファイルシステムの公開がうまくいかない、パーミッションがおかしい、データが古くなったり分いsつした

りする、サーバの性能が制限されてしまうといった問題が発生する。

　　マウント情報の管理ファイル
　　　ファイル　 ホスト　 内容
　　　/etc/xtab server 現在公開されているファイルシステム
　　　/etc/rmtab server このサーバのクライアントのためのホスト：ディレクトリのペア
　　　/etc/mtab client 現在マウントされているファイルシステム

　　公開しているファイルシステムとそのファイルシステムをマウントしているクライアントはどれかは/etc/exportsと/etc/xtabの対

応でわかる。

　　サーバは/etc/exportsに従ってrpc.mountdを起動して/etc/xtabを長さ0にする。
　　/etc/xtabの管理にはexportfsユーティリティを使う。/etc/xtabの最終変更時刻がファイルシステムの航海情報が最後に

変更された時刻となる。

　　exportfsを引数なしで実行するとマウントされているかわかる。＝cat /etc/xtabでも同じ出力が得られる。

　　mountdデーモンはクライアントからのマウント要求を受理すると、マウント要求で指定されたディレクトリ名とクライアントのホス

ト名を/etc/rmtabに記録する。unmountがくるまで記録されている。サーバがリブートされてもパージされない。普通クライアント

がシャットダウンするときリモートファイルシステムをアンマウントするはずだが、それを行わないとここに誤った情報が残る。

　　showmountはrpc.mountdデーモンに対して現在のリモートマウントテーブルを要求する。このとき参照されるの

は/etc/rmtabである。コマンドのオプションと見方解説。

　　dtコマンドはクライアント上で現在のマウントしているふぃあるシステムをレビューできる。オプションと使い方解説。多機種のマ

シンを使っている環境ではdfコマンドは紛らわしい情報や矛盾した情報を表示することがある。

　　mountコマンドを引数なしで実行すると、mtabの内容が表示される。オプションと使い方解説。

　＊NFSの統計情報
　　クライアント側とサーバ側でNFSサービスの利用量が手続きの呼び出し単位でRPC層とアプリケーション層各々について収

集されている。
　　nfsstat -c はクライアント側の統計情報を、nfsstat -s はサーバ側の統計情報を表示する。オプションと結果の見方解説

。

　＊システムクロックの合わせ方
　　複数のサーバ上にファイルを分散させる場合、サーバとクライアント間でシステムクロックの同期をとることが重要。
　　
　　rdate　ホスト名でそのホストに時間を合わせられる（スーパーユーザ権限が必要）
　　ネットワーク上の現在時刻はタイムキーパホストに管理させるのが一般的。
　　NISのhostsファイルにtimehostというホスト名のエイリアスをつくってrdateで指定するのが一般的。

　　ネットワーク上のマシンの時刻同期はまず、/etc/rc.localに指定してブートシーケンス中に行う。
　　それ以降はcronで定期的に行う。crontabで一定間隔を指定する。
　　各ホストのrdateの時間が重ならないようにする。
　　ミリ秒単位で同期をとれるNTP（Network Time Protocol）もあるが、解説はない。


第11章　ネットワーク障害の修正
　ネットワーク・ケーブルが物理的におかしいときの診断法からまちがったドメインのNISサーバとして機能してしまうマシンへの対応

まで幅広くとりあげる。
　ネットワーク障害を上手にデバッグするには手順が重要。プロトコルスタックの下位レベルから上位レベルへ診断する。
　例　NISサーバにバインドできない
　　　pingでネットワークをテスト→rpcinfoでypservプロセスが正常かテスト→ypsetでバインドをしてみる。

　＊正しく終端されていないネットワーク
　　マシンによって接続で来たりせつぞくできなかったり、あるいは、マシンの接続が時としておかしくなるのは、ネットワーク・ケーブ

ルの配線状態が悪いか、正しく終端されていないことが原因であることが多い。こんなときには隣のマシンへのpingに20ミリ秒もか

かたりする。例をあげて解決方法を解説。信号が反射されるとどうなるかはAppendixAの伝送線路理論で詳細に解説。
　　終端されていないネットワークを壁に背を向けて立っている友達にゴムボールをなげて、キャッチして跳ね返さないようにしない

といけないところを取りこぼしていると説明していた。跳ね返りの信号から遠いところのマシンはあまり影響を受けない。
　　またイーサネット同軸ケーブル内での信号反射を回避するには、トランシーバをできるだけケーブルの近くに配置すること。
　　信号吸収を電気信号が厚いレンガ塀に突き当たるのではなく、ビルの曲がり角に入り込むようなものといっていた。
　　例としてあがっていたのは、
　　　　ゲートウェイを介したネットワーク・アクセスの障害、
　　　　リピータを介した場合にネットワークがおかしくなる。

　＊複数のARP応答がある場合
　　IPアドレスからMACアドレスの変換がおかしくなった場合の悪影響について述べる。
　　　例として
　　　　マシンが時に遅くなる。すべてのマシンが同時に遅くなるわけではない。
　　　　マシンが突如数分間行方不明になる。
　　症状が散発的で時間が経過すると治るという特徴がある。
　　このときのARP要求の診断方法を解説。

　＊NISサーバをかたるマシン
　　ある日クライアントマシンからログインできなくなって、マシンをリブートしたらマウントもできなくなった例。
　　シングルユーザモードで立ち上げて、ypbind、ypwhichでバインド先を確かめる。すると、そのドメインのなかにNISサーバをかた

るゲートウェイがいたため、ypservがまちがったドメインにバインドされていた。ゲートウェイをちがうドメインに移してもらい、NISマッ

プを含むサブディレクトリ/var/yp/ドメイン名を削除してリブートすると正常に動くようになった。

　　NISサーバのマップがおかしくなっていたり、不完全でも似たような症状がでる。ypwhichで出力されるNISサーバがただしけれ

ば、この可能性が高い。マップの整合性をチェックするにはypcatですべてのキーをダンプし、変更漁にあわせて、初期化したり修

正したりする。

　＊ブートパラメータの混乱
　　ディスクレスマシンSun3/50をブートしようとしたところエラーになった。
　　近くのマシンからブートシーケンスのブロードキャストをエミュレートしたところ（rpcinfo -b bootparam 1）異なるベンバーのブー

トサーバがみつかって、そこが応答していることがわかった。ブロードキャストの要求に対する応答形式がベンダーで異なっているこ

とがあるのである。このマシンのrpc.bootparamdをコメントアウトする方法が考えられるが、もしこのサーバが別のディスクレス・クライ

アントを持つ場合はそれはでいないので、自分のクライアントを記述したリストをもたせる（/etc/bootpraramsファイルからプラス

記号をとりのぞく）ことで解決する。

　＊NFSエラーメッセージ
　　NFSは実装の方法で性能やチューニングが微妙に異なることが多い。
　　NFSマウントされたディスクに対する書き出しエラーはその仕組みのゆえに多い。
　　NFSの書き出しが頻繁に失敗するような場合、どのファイルが実際に書き込まれているかを調べることで、書き込みを実際に

実行しているユーザやプロセスをみつけることができる。SunOS4.0 ではshowfhユーティリティを使う。そのためにはサーバ上で

RPCサーバデーモンrpc.showfhdを起動して、クライアントでshowfhを実行する。
　　クライアントの書き込みが遅いなら、NFSの負荷を効率よく設定する必要がある。


第12章　性能の測定とチューニング
　取扱い範囲は、性能のボトルネックを識別する方法や性能を向上させるためのさまざまなオプションを解説。
　ネットワーク資源の使い方や、ネットワーク構成がまずい場合はシステムの応答も悪い。特に重要な部分がおかしいなら、時

間をかけても対処した方が見返りは大きくなる。
　チューニングの過程では最初は性能が大きく向上するが、やがてあまり上がらなくなる。こうなると手間ばかりかかって、性能の

向上率はたいしたことはないので「だいたいチューンされていればそれでよし」のジャズ流精神で解説する。
　ユーザは自分のマシンが早くなればそれでよいと考えている。システム管理者は常にネットワーク全体を考えなければならない。
　NFSよりrpを利用したほうが早い。NFSをチューニングする必要はないという考えに反論。NFSの利点は自分のマシンのファイ

ルシステムにアクセスするようにアクセスできることで、ｒｃｐコマンドでは相手のサーバ名とディレクトリ名が必要になるといっていた。

　＊NFSはどのように動作するのか
　　チューニング前にしっておくべきこと。どれだけのことがサーバに要求されているのか？＝どのくらい調整がいるのか。
　　コンフィギュレーションのオプションとしてどのようなものが利用できるのか？＝変更で事態が改善したと知る方法。
　　
　　NFSの任意性。NFS要求はバーストである。そしてバーストの間は頻繁だが、そのあとは静かになる。
　　負荷の高いNFS要求・・ディスへの入出力をサーバに要求するもの(シンボリックリンクの展開も）
　　負荷の低いNFS要求・・・ファイル属性情報やディレクトリ名のlook-upキャッシュに単にアクセスする要求など。
　　NFS RPC mixture ・・・サーバに対して発行されたすべてのRPCを各タイプごとの平均比率で表したもの。

　＊性能の診断
　　上手にチューニングできたかの目安はクライアントから見てサーバの処理が速くなること。
　　具体的には標準的なクライアントからの要求に対するサーバの応答時間の平均値を割り出すこと。ここではディスクレスクラ

イアントなら２５－３０ミリ、NFSクライアントであれば５０-７０ミリが一般的としていた。あとはクライアント１台で応答値をはかって

、最小時間をわりだしその２倍以上ならサーバに負荷がかかりすぎていると考える方法もある。
　　クライアント上でサーバの応答時間の平均値を計算するには、クライアントが発行したNFSのRPCの総数を所要時間で割

る。あくまで平均なので、あまり細かいことは考えない。詳細な方法を解説。

　＊ベンチマーク
　　ベンチマークをテストするときには、NFSコールの受診率とRPCのばらつきを現実に近づけないと意味がない。規則的な間隔

のものは、あまり意味がない。留意点と、Heisenbergの不確定性原理（何かを観察するプロセス自体が観察の対象をへんかさ

せてしまう）ことをあげて、性能を測る方法を考えるように促す。

　＊NFS性能・ボトルネックの識別方法
　　NFSは状態遷移情報がないのでクラッシュからの復旧が容易であるが、逆に負荷でタイムアウトなのか、サーバダウンなのか

判断がつきにくい。
　　過負荷のサーバはnfsdデーモン待ちになっているので、新たなパケットは受信できないが、受信したパケットには応答できる。

でもそのころにはクライアントはパケットを再送してしまっている。
　　
　　サーバクライアント関係でボトルネックになりやすところ
　　　・クライアントのネットワーク・インターフェース
　　　・ネットワークの処理能力
　　　・サーバのネットワーク・インターフェース
　　　・サーバのCPU負荷状態
　　　・サーバのメモリ使用状況
　　　・サーバのディスクの転送能力
　　　・システム構成の及ぼす影響・・・サーバのカーネルコンフィギュレーションが悪い、ディスクのバランスが悪い。マウントポイント

を指定するのに使用している名前付け規則が効果的でないが考えられる。
　　　
　　ボトルネックをみつけるには
　　　ネットワークの問題かサーバの問題か切り分ける。
　　　典型的NFSクライアントでnetstatツールを使用して、再送率と複製応答率をみる。これでパケットがサーバに達しているな

らネットワークは問題ないと考える。NFSは下位レベルのプロトコルがわからないのでこのような全体的なチェックが必要になる。

　＊ネットワークの混雑とネットワーク・インターフェース
　　便利なネットワークは拡張を繰り返す。しかし、ネットワークは拡張をされると負荷が高くなりすぎたりホストのネットワーク・イ

ンターフェースがおかしくなったりして性能が低下するものである。
　　ネットワークの設計と、容量をどのように評価していくか考える。

　　・「netstat -i」を使ってイーサネットのネットワークインターフェースが正常に働いているかを確認する方法。
　　・「netstat -i」で衝突回数をしらべる。イーサネットはパケットを送信するときキャリアセンスをだして、送路があいているか確

認するのだが、つながるマシンが増えれば当然衝突も増える。ネットワーク使用率が３０-４０％を超えるとイーサネット自体がボ

トルネックになる。

　＊ネットワークを分割するための機器
　　ネットワークの分割は１本のバックボーンを複数のセグメントに分岐することで行う。セグメントはパーティション用の機器を介し

て接続される。この機器には、リピータ（中継器）、ブリッジ、ルータ、ゲートウェイがある。
　　リピータ・・・２つのセグメントを物理層で接続。信号とパルスの整形をするだけで、ネットワーク混雑回避にならない。
　　ブリッジ・・・セグメントをデータリンク層で接続。MACアドレスで転送すべきパケットを選択する。学習型でない場合MACアド

レスを各ネットワークごとに登録してやる手間がかかる。セグメントの混雑は緩和するはずだが、もっとも使用頻度が高い伝送路

が新しいブリッジを通過していないことが前提。
　　ルータ・・複数のIPネットワークの接続に用いられる。イーサネットアドレスでなく、ソースIPアドレスとディスティネーションIPアドレ

スに従ってパケット転送を行う。
　　ゲートウェイ・・ネットワーク・プロトコルスタックの最上位。アプリケーションレベルでの転送機能を実行する。トラフィックの転送

においてプロトコル変換も同時に行うことが多い。異なる通信プロトコルを用いる複数のネットワーク接続に用いられることが多い

。

　　プロトコルフィルタリング
　　　IPプロトコルと無関係なデータが大量に取り扱われるなら、IPプロトコルのパケット比率を調べる。LANアナライザやSunの

trafficユーティリティを使う。そしてプロトコルでパケットの選択転送を行うブリッジやルータを使うようにする。

　　ブリッジによる分割
　　　NFSで通信を行うクライアントとサーバをグループにしてブリッジで分ける。NISはブリッジがブロードキャストトラフィックを阻止

しないので普通に使える。またNISはNFSに比べ通信量が少ない。
　　　ネットワーク中のノードの理想的な分割を行うために各ホストをノードとするようなグラフで自分のネットワークを表現する方

法を解説。マウントの重みづけをする。FordとFulkersonのmax-flowmin-cau理論（ネットワークにおける最大量量は１つ以上

のボトルネックによって制限される）によるもの。　
　　　冗長な回路が必要な場合も解説。

　　分割されたネットワークでのNISの利用
　　　間にルータがあるとypbindのRPC要求がブロードキャストされないという問題が発生する。
　　　またブリッジがあると通過に時間がかかるので、構成によっては一部のNISサーバの負荷があがることが考えられる。

　　ディスクレス・ノードの影響
　　　よほどの事情がない限り、ディスクレス・ノードは物理的にも論理的にもサーバと同じネットワーク上に設置されるべき。
　　　どうしてもそうならないときのための対処法が解説してあった。

　＊サーバのチューニングをするには
　　まずはサーバの何が原因で性能が向上しないのか調べる。

　　CPU負荷を調べる
　　　CPUの負荷が高すぎると、NFSデーモンがスケジュールされるまでの待ち時間が長くなる。同時にサーバ上で実行されてい

るCPU依存のプロセスの性能が低下する。
　　　すべてのnfsdデーモンは同一のUDPソケットから要求を受け取るので、デーモンが他のプロセスと競合してCPUサイクルを書

くとしなければならないとサーバの応答時間が余計にかかる。そうなると下位レベルのネットワーク・ドライバがパケットを落としてし

まう。Berkely版のvmstatはCPU統計情報を表示するコマンド。
　　　NFSサーバに端末を接続するのはやめる。
　　　NFSサーバをゲートウェイにしない。

　　NFSサーバ・デーモン
　　　標準仕様のブート時に起動されるnfsdデーモンは通常の使用状況での性能が得られるようにベンダーが適当にきめたもの

。nfsdの数を８個にするには「nfsd 8 & echo -n 'nfsd'」とスクリプトで指定する。
　　　最善の数を試してみよう。
　　　ただしどのnfsdデーモンも要求をうけとるソケットは同じ。nfsdデーモンの数が極端に少なくソケットがオーバフローしていると

きには「netstat -s」でわかる。
　　　nfsdデーモンが多くなりすぎるとコンテキストスイッチングとスケジューリングのオーバヘッドが問題になる。思わぬ悪影響でメ

ールが配信されないなどの事態が考えられる。nfsdデーモンは最低で４つ。UDPソケットがオーバーフローしなくなるまで増やすの

がよい。

　　メモリ使用量
　　　NFSはサーバのバッファ・キャッシュを使用してNFSのread要求に伴うファイルブロックの読み込みを実行する。このバッファキ

ャッシュを増やすことができる。ただしリブートが必要。サーバがNFS専用でないなら、すべてのプロセスが実行できるだけのメモリを

用意してページングを起こさないようにすべき。
　　　
　　ディスクとファイルシステムのスループット
　　　NFSの場合ネットワークより、サーバがディスクとファイルシステムを効率よく利用するようにした方が全体の性能は上がる。
　　　ディスク・アクセスを最適にして、カーネルのテーブルサイズを最適にして、ディスクにまんべんなく要求を分散する。
　　　UNIXのファイルシステムは小さなファイルを扱うには理想的だが、大きなファイルには向かない。ディレクトリが大きすぎると

NFSにむかない。ファイルシステムのフラグメンテーションも効率低下をまねく。これを直すにはダンプして再構築するしかない。
　　　ディスクのデータ転送速度をあげるにはシーク時間を短くすること。難題もあるディスクのなかの１・２ぢに要求が集中するの

は好ましくない。
　　　ディスクの負荷分散は頻繁に利用されるファイルシステムを複数のディスクに移し、それらのファイルシステムに対する要求を

同時処理することで行われる。ディスクレス・クライアントの場合はとくに重要。「iostat -D」でディスク待ちしている要求の数の偏

りがわかる。

　　カーネルのコンフィギュレーション
　　　ファイルのi-node情報だけで事足りる要求は多いのでi-nodeテーブルのサイズを最適化する方法解説。
　　　サーバー間でファイルをマウントするとデッドロックが発生しやすくなるのでやらないこと。どうしてもというときは「bg」オプションを

使う。
　　
　　マルチホームサーバ
　　　サーバからNFSファイルシステムが複数のネットワークインターフェースに対して公開されている場合、インターフェース間でパ

ケットがなるべく転送されないようにマウントをする。

　*クライアントのチューニング
　　　クライアントのチューニングはサーバに劣らず重要。サーバの能力には限界があるが、クライアントはそれを考慮して要求をし

てこないので、サーバがいっぱいになってしまう。このような場合クライアントに調整弁をつける。

　　遅いサーバの補償
　　　RPC再送アルゴリズムでは、遅いサーバとネットワークの混雑の区別ができない。
　　　「nfsstart -rc」でサーバが遅いのかがわかる。しかし両方だと見分けはつきにくい。すべてのサーバに同じディスク操作をし

てみて、他より遅いか見る方法もある。
　　　遅いサーバに対応するために/etc/fstabでtimeoパラメタを調整する方法解説。
　　　「netstat -m」でNFSサーバの応答時間がわかる。タイムアウト時間を増やすときはいきなり３００とかにしない。
　　　再送率の閾値の考え方と設定値の解説。

　　ファイルシステムがソフトマウントされている場合
　　　RPC要求の再送サイクルが繰り返されるのは、ファイルシステムがハードマウントされている場合だけ。
　　　softオプションでマウントされているとRPCの再送シーケンスは最初のmajor timeout発生時点で停止。
　　　そのため、中途半端なところできれてしまうと、書き込みかけたファイルをそのままにしてしまったりするので、読み書き可能の

マウントはハードで行うべき。retransマウントオプションで再送回数を増やせる。

　　タイムアウト時間の算出
　　　ハードマウントの短所はサーバが復帰するまでクライアントがハングしてしまうこと。ファイルシステムをハードマウントする際に

「intr」オプションを指定するとキーボードからの割り込みが可能になって再送ループを停止できる。NFS再送アルゴリズムのタイム

アウト期間の求め方を示し、あまり長いのはいけないと解説。

　　ネットワークの信頼性の問題
　　　パケットがブリッジやルータを通る際に欠落するような信頼性に欠ける場合にもNFSの性能は低下する。
　　　「ntsstat -rc」のRPC統計情報を検討するとこのような事態もわかるとして解説。信頼性が低いネットワークではNFSバッ

ファサイズ小さくしろと書いてあった。またサーバとクライアントでそろえるといいとか書いてあった。

　　広域ネットワークでのNFSの利用
　　　広域ネットワークでもNFSは利用可能。その際はバッファサイズを小さめにもっとも遅いリンクのMTUに揃える。RPCタイムア

ウトは長めにとる。

　　biodのチューニング
　　　サーバが原因で機能が悪くなっているときに、クライアントマシン上で起動するbiodを増やすとNFS要求が増えて性能が悪

化する。biodを減らしても性能は向上しない、閃光読み出しや地縁書き込みが実行されなくなるのでスループットが落ちる。サ

ーバー上でbiodデーモンが４つ起動している場合書き込み要求が５つくると４つまでbiodがほかはプロセス自体がうけもつ。biodは

ブート時に数を指定される。

　　ファイル属性情報のキャッシング
　　　NFSクライアントはファイル属性のキャッシュをもっている。（あまり変更されないので）
　　　ファイル属性情報キャッシュのパラメータを解説、ベンダーによりディフォルト値は異なる。
　　　マウントオプションで「noac」でキャッシュしないように設定できる。ただしファイル情報にアクセスするすべての場合サーバにつ

ながないといけない。こうなるとサーバが処理するNFSコールの６０％が属性情報で占められる可能性がある。
　　　一つのディレクトリで複数のクライアントが同時にファイルを作成している場合は、どのようなファイルが作成されたかをすべて

のクライアントができるだけ早く知りたい場合がある、このときキャッシュの時間を短くすべき。
　　　「ls ファイル名」と「ls ファイル名の一部＋＊」ではワイルドカードをつかうとキャッシュが検索される可能性があるといっていた

。

　　マウントポイントの構成
　　　非効率的なマウントポイントの構成の代表は、マウントポイントが飛び石的になっている場合と、サーバが中間にはいるシ

ンボリックリンク。理由を解説。

　　ルーティング情報
　　　小規模ネットワークや、１台のルータで他のネットワークとの接続を行っているようなネットワークでは、ネットワークルーティン

グデーモンroutedの動的経路制御よりも、静的経路制御の方が適している。動的経路制御ではゲートウェイやルータホストが

３０秒ごとに経路情報をブロードキャストするが、ネットワークの出口がひとつしかないなら無駄だから。

　　ファイルのハンドル異常
　　　あるクライアントがオープンしているファイルやディレクトリを他のクライアントが削除したりすると、そのファイルのファイルハンドル

が必ずおかしくなってしまう。このときのメッセージは「stale file handle」これがしょっちゅう発生しているならディレクトリを共有して

いるユーザやコピーされたプログラムを使用しているユーザをチェックしてみるべき。スクラッチ領域を別のユーザが消していることもあ

る。NFSファイルをユーザがどのように利用しているか知ることが大切。



第13章　自動マウント
　オートマウンタ・・・NFSファイルを自動的にマウントするツール。NISでNFSコンフィギュレーションファイルを管理している。したがっ

てNISのマップひとつでネットワーク上のクライアントのマウント情報を管理できる。/etc/fstabの管理を自分でおこなわなくていい

というメリットもある。

　オートマウンタを使うメリット
　　共通エントリを各/etc/fstabにいれなくていい。
　　マウントテーブルの管理が簡素化され、ユーザアカウント情報の管理が簡素化できる
　　オートマウンタが参照していないファイルシステムをアンマウントするので、NFSサーバがクラッシュしてもプロセスがハングしたまま

になる確率を大幅に下げられる。
　NFSのマウントプロトコルを拡張しており、ネットワーク上に分散されている読み出し専用のファイルシステムをマウントするときに

「もっとも近い」サーバからマウントするようになっている。ネットワークの負荷が分散される。
　　rootにならなくてもマウントできる。
　　NFSサーバの追加や再構築にともなう管理作業が単純になる。
　　マウントするときに複数のサーバを探すので、クラッシュに強くなる、負荷分散できる。

　*オートマウンタ・マップ
　　クライアント側からみて共通のパス名のプレフィックスで複数のファイルシステムをマウントするときは間接マップが
　　マウントポイントに共通のプレフィックスが存在しないとき直接マップが便利。
　　間接マップと直接マップの働きを例で説明。

　　オートマウントの構造
　　　オートマウンタはシンボリックリンクをエミュレートする機能。
　　　エミュレータ機能を実現しているオートマウンタの仕組み解説。カーネルがオートマウンタをNFSサーバと勘違いさせると書い

てあった。

　　直接マップ解説
　　絶体パス名でマウントポイントを指定。

　＊オートマウンタの起動とマスターマップ
　　オートマウンタのマップ選択、起動を解説

　　オートマウンタは起動されるとNISのauto.masterマップをマスターマップとして読み込む。
　　マスターマップにはすべての直接・間接マップとそれに対応するディレクトリがリストされている。
　　マスターマップのエントリは、ディレクトリ名、マップ名、マウントオプションで構成されている。具体例をあげて、オプションやタイム

アウト時間（何分マウントしていなかったらアンマウントするか）を解説。

　＊NISの利用
　　オートマウンタで使用する3種類のマップをNISで管理する。NISマスターサーバのMakefileにオートマウンタマップのエントリを追

加する方法を解説。
　　マップの変更はプッシュされた時点で行われる。
　　現在マウントしているファイルシステムのパラメータを変更するには、一度アンマウントしてからオートマウンタにSIGHUP(kill　-l

）シグナルを送る。
　　直接マップだと書き換えてから再起動が必要。

　＊キーや環境変数による置換
　　キーによる置換
　　　＆はマップのキーに対応する文字列で置き換えられる。などの解説。
　　　オートマウンタの右側の要素を環境変数（＄ではじまる文字列）で置き換えられるなど解説。

　＊高度なマップファイルの利用
　　サーバーを複数指定し、一番近いサーバーを選択する機能解説
　　階層マウント・・・同一のサーバから複数のファイルシステムを階層的にマウントする機能。解説。
　　直接マップの間接マップへの変換解説。

　＊オートマウンタの副作用
　　検索パスに多数のディレクトリが入っていて、これらのディレクトリのいくつかに自動マウントがはいっていると、ログインが完了す

るまで時間がかかる
　　ローカルマウントしている場合、ファイルを指定をローカルホストのパス名で行うか、オートマウンタのパス名で行うかでpwdで表

示されるディレクトリのパス名が異なる。
　　夜中に起動されるfind作業や、claenderユーティリティなどcronによって起動されるユーティリティはオートマウンタを用いると無

駄な処理を行うことがある。
　　pwdコマンドはカレント・ディレクトリを順にさかのぼっていくことでシンボリックリンクの展開をおこなうので、オートマウントされたデ

ィレクトリで用いると予期しない結果がでる。シェル変数のcwdを使うとよい。
　　オートマウンタを kill -9で停止しないこと。SIGTERMを使うと問題なく停止できる。


第14章　PC/NFS　
　PC/NFSは、DOSをオペレーティングシステムとするIBM互換機上で動作するNIFプロトコルのクライアント専用の実装。
　これによってNFSファイルシステムを論理ディスクとしてマウントし、大容量DOSディスクとして使用することができる。
　PCが常にNFSの実行主体となる。転送の種類や方向は限定されない。

　＊PC/NFS設定
　　PCの設定、nfsconfというプログラムで行うのがよい。
　　起動ファイルにコマンドを追加する方法、PC/NFSの設定ユーティリティが追加した行を書き換えるための情報について述べ

る。

　＊PC/NFSの起動
　　ブートの時点でNISが利用できるように、NETWORK.BATが最初に実行されるようにする。
　　net ypdomain コマンドでドメイン名を設定。
　　net ypset コマンドで、設定されたドメイン名でNISマップを扱うサーバをみつける。
　　PC/NFSではUNIXマシンでPC/NFSユーザの認証情報を確認している。標準設定できはNISサーバと認証サーバは同一

マシン。
　　最後はネットワーク・リダイレクタを起動させる。　net start rdr 普通NETWORK.BATの最後に書いてある。Reverse　ARP

をブロードキャストしてPCのIPアドレスを得る。

　サーバの設定
　　PC/NFS用のサーバデーモンが一つ必要pcnfsデーモン。

　＊PC/NFSの利用
　　ファイルシステムのマウント　ダブル・バックスラッシュに続くサーバ名とファイル名をつかう、例で解説。
　　ファイルパーミッション確認　PCユーザーがUNIXの認証サーバにログインすることで、制限の厳しいパーミッションから解放され

る。

　　ファイル名の変換。
　　UNIXのファイル名の長さは通常14文字、システムによって最大256文字。大文字小文字混在可能、バンクチュエーション

記号利用できる。
　　DOSは8文字と拡張子。大文字だけ。ドットではじまるファイル名は不可。
　　この二つのファイル形式の変換法則を解説。
　　シンボリックリンクはDOSでサポートされていないが、PC/NFSは若干の制限つきで利用できる。
　　ファイル内容の変換法則解説。

　＊プリンタサービス
　　PC/NFSによるプリント作業は、プリントファイルをホストにコピーし、そこからプリントするのと同じ。
　　net use lpt1: サーバのパス名として指定したUNIXプリンタ名　でプリンタ指定。
　　出力のリダイレクトで、ファイルの内容を直接プリンタに送る場合、DOSはすぐに送る（シングルタスクだから）がUNIXでは魔う

ちタスクなので一旦スプールする。
　　PC/NFSのプリントメカニズムをpcnfsdデーモンなどの動きとともに解説。

　＊ネットワーク・リダイレクタの動作
　　PCのディスクをUNIXにマウントすることはできない。DOSがシングルタスクだから。
　　ネットワーク・リダイレクタは通常DOSの入出力に送られる要求を横取りして適当なNFSサーバに送出するためにRPC要求

に加工する仕組み。UNIXのbiodデーモンと同等のもの。

　＊PC/NFSネットワークの管理
　　　PC/NFSのネットワーク管理用ツールを使うことでリモートUNIXサーバへの経路の指定、PC/NFSの統計情報表示。PCク

ライアントの性能の最適化を行うためのネットワーク・ドライバの設定を行える。

　　　PC/NFSでのルーティング　DOSではディフォルト回路が一つだけ設定されている。「net route ホスト名」引数なしだとディ

フォルト経路がでる。
　　　ネットワーク上のサーバへの経路を調べる　「netstat -r」
　　　PC/NFSで提供されているネットワーク診断ツールと解説。UNIXでのものとあまり変わらない。netsat arp nfsstat nfsping
　　　PC/NFSでは、NFSバッファサイズも小さく、バッファやキャッシュの管理が制限されているので、NFSサーバに対する要求も

異なる。PC/NFSのクライアントがネットワークに追加された場合の観察は、10章、12章を参照しておこなう。
　　　マウントパラメータのチューニングはCONFIG.SYSファイルのPC/NFSドライバの行で設定を行う。「DEVICE=C:\NFS

\PCNFS.SYS オプション」オプションの解説。エラーの解説。
　


AppendixA 伝送経路理論
　物理層の特性をきめるもの。ＮＦＳなどの上位レベルプロトコルとは直接会関わりはないが、物理層の制約を守らないと断続

的で奇妙な問題が上位層でおこることがある。
　伝送経路輪・・・通信線路を移動する信号の波長よりも長い線路のこと。
　信号の周波数が高ければ高いほど、波長は短くなる。よって、高いほど短い線路での信号特性について解析しなければらな

ない。イーサネットで使用される波長は約１メートル。だから２台以上のワークステーションがあれば、伝送経路理論の適応対象

。
　どのような信号導体にも、導体固定の静電容量とインダクタンスがある。イーサネットのバックボーンケーブル長に制限があるの

は容量負荷効果のためである。周波数がひくいとケーブルが理想的でなくても無視できるが、イーサネットがデータ転送に使用

している10MHzの周波数では無理。
　イーサネットケーブルを同じふるまいをする電気回路で説明。電圧の移動や終端について解説。
　イーサネットケーブルのインピーダンスは50オームでこれはターミネータの抵抗値。
　ネットワークの使用中は行えないが、テスタを「抵抗測定レンジ」にして同軸ケーブル芯とアース間の抵抗値を測れば25オーム

になるはずである。
　ネットワーク・ケーブルを調べておくことで、潜在的問題を解決することができる。


AppendexB　IPパケットの線路制御
　ルータはユニークなIPアドレスを持つ複数のネットワークインターフェースを持っている。またIPアドレスにはユニークなホスト名が対

応している。一般にセカンドネットワークインターフェースに対応するホスト名には-gwを使加えたホスト名が持ちいられる。
　「netstat -i」で双方のインターフェースとそれに対応するネットワークとホスト名を表示できる。
　ローカルネットワークが他のネットワークにどよように接続されているかとう情報を変更する方法
　　１　動的経路情報はホストから定期的に宗主されin.routedなどのデーモンがその情報を解釈してルーティングテーブルを更

新する。
　　２　静的経路情報はコマンドで手動で設定される。ネットワークにルータが1台しかない場合などに使う
　　３　別のネットワークにパケットを転送するために選択されたルータが最適でない場合、選択されたルータが経路のリダイレク

ションメッセージ要求を実行。このICMPリダイレクトメッセージでルーディングケーブルが更新される。
　現在のルーティングテーブルの状況を調べる「netstat -r」とその結果の解説。
　ARPブロードキャストが同一ローカルネットワーク内しかいかないが、リモートのIPのホストと通信できるわけ解説。（MACアドレス

が変換されていく）
　通常２つ以上のネットワークに接続されたホストは、自分のルーティングテーブルを参照しながらIPパケットの転送を行うように

設定されているが、通信はおこなってもネットワーク間の転送を行わないようにしておくと、セキュリティが増す。「adbを用いてカー

ネル変数のip-forwardingの値を変更する」


AppendexC　NFSのトラブルシューティング（本編のまとめてきに）
　NFSサーバの問題
　　netstat -s の出力について
　　　badcalls>0　ユーザ認証の問題
　　　nullrecv>0 NFSサーバデーモンの数を減らす。
　　　symlink>10% サーバが公開しているファイルシステムのシンボリックが多すぎる
　　　getattr>60% NFSクライアントのファイル属性情報キャッシュの大きさが小さすぎるか０になっている。
　　　null > 1% オートマウンタからマウント要求が頻繁に発行されている。マウントタイムアウトのパラメータ値を増やす。

　NFSクライアントでの問題
　　netstat -cの出力について確認
　　　timeout >5% サーバが応答するまえにクライアントのRPC要求がタイムアウトしているか、サーバに到達していない。bacxid

フィールドを調べる。
　　　badxid-timeout　再送した要求もサーバで処理され、クライアントがサーバからの応答を重複してうけとっている。要求の再

送を短くする。
　　　badxid=0 タイムアウトが多い場合NFS要求や応答の一文がクライアントとサーバの間のネットワーク上で落ちてしまってい

る可能性がある。rsize, wsizeのマウントパラメータをつかってNFSのバッファサイズを小さくすることで解決することがある。
　　　badcalls>0 ソフトマウントされたファイルシステムに対するRPCがタイムアウトしている。サーバクラッシュの直後は問題ない。

　NFSのエラーコード解説
　　　EINTR ハードマウントされたファイルシステムでintrオプションが設定されていて、システムコールが中断された。
　　　EACCES 妥当なユーザ権限をもたないユーザがファイルにアクセスしようとした。
　　　EBUSY NFSクライアントで使用中のファイルシステムをスーパーユーザがアンマウントしようとした。
　　　ENOSPC　クライアントがNFSのwriteオペレーションを実行しようとしたが、ファイルサーバのディスクスペースが足りなくなって

いた。
　　　ESTALE　NFSクライアントが参照しようとしてサーバに要求を発行したi-ノードが別のクライアントによりすでに削除されて

いた。
　　　EREMOTE　サーバにNFSマウントされているファイルシステムをNFSマウントすることは許されていない。


AppendexD　NFSのベンチマーク
　クライアントからの負荷を生成する方法
　　Legato Systems社のnhfsstoneユーティリティ
　　シェルスクリプトにファイル操作をさせる
　二つの方法について解説
　どちらにしても現実実況をそっくりシュミレートするのは難しい。


末尾に索引。

NFS & NIS (NUTSHELL HANDBOOKS)

• 作者: ハル ストーン
• 出版社/メーカー: アスキー
• 発売日: 1992/12
• メディア: 単行本

タグ：ハル ストーン