ネットワーク - みる会図書館

1. UNIX MAGAZINE 1998年4月号

られすに WWW や FTP などのアプリケーションが商に使えないという状況もよくある。このように、インターネットにおける性能言叫面では、 IP 層レベルでのバケット損失率も注意すべき孑票である。スルーブットやの岳らぎネットワークでの性能の揺らぎにも注目する必要がある。揺らぎは、 WWW 、 FTP 、 Telnet 、電子メールといった時間制係生のないデータ通信ではとくに問題にならないが、ピテオ伝送やインターネット電話などの寒間マルチメディア情報の伝送では大きな問題となる。たとえば、ネットワークを用いてピデオ伝送をする場合を考えてみよう。ここでは、伝送するピデオば石宿されていないものとする。ーヨ殳に、ビデオは毎秒 30 フレームから構成されている ( 1 / 30 秒ごとに静止画を表示する樹冓と言い換えてもよい ) 。これをネットワークを介して送る場合、次のような条件を満たさねばならない。・あるフレームについて、データを受信して表小する処理を 1 / 30 秒以下でおこなう。・フレームどうしの間隔は 1 / 30 移未満にとどめる。ネットワークの遅延に揺らぎがあると、 2 番目の条件を満たせない可能性があり、結果として表小するビデオの生能が劣化する。圧縮したビデオを伝送する場合はもうすこし複雑な処理をおこなうが、それでも遅延の揺らぎによってピテオの性能は劣化する。ビデオや音声を実日判りてイ云送するときは、伝選星延の揺らぎが情報の再生に景グを - 与える。山も匠は、インターネットでも、マルチメディア・システムを利用して重丿像を提供する ReaISystem や、音声を伝送するインターネット電話などのサービスがおこなわれるようになった。このような用途を考えると、ネットワークにおける遅延などの生能の揺らぎについても注意を怠ってはならない。使用或ネットワークカ甘是供する帯域のうち、どの程度か実際に利用されているかを知ることも重要である。「通イ各性育幻の項でも述べたが、スルーブットや遅延バケット損失率は、ネットワークの利用頻度と相関関係がある。ー殳に、混雑したネットワークでは良好な生能力碍られない。このため、管理対象のネットワークを常時監視連載 /UNIX Communication Notes—O 18 図 4 MRTG を利用した長見測 w ・併叩 h M “ Av 鷦・ ) ー 63.0 k 12 ド「、 MaxIn m75 第 k Ⅳ 30 % ) A' 讐 a 3 刀 8k を ( 0.4 % ) C ー e 誠 9 ーⅣー ( 0 ん ) M 0 ヨ 48 & 8k s ( % ) A マ 0 0 : 700 3 / 5 ( 0. アん ) C 記は 0 就 : 380 ーな ( 0.4 % ) 'Monthly' Graph 。 Av ・ ) ー 4&.0 k 0 、 0 k ・ k OS を k M ヨ 07S.2k Ⅳゞ 0.1 % ) A a 352.8k ー ( 0 ぐ / 。 ) C 山化 4 .3k Ⅳー ( 0 、ぐる ) M 駅 0 応 92.9k ツ 30 4 % ) A 師 a 0 : 0.8kbI Ⅱ 0.5 % ) C 代就広 5 0 ミ ( 0.5 % ) Yearly' 併叩 ( 10 A er 鷦・ ) 36 .0 k 一方、個別のアプリケーションの生能を言れ則したり、パおこなうことができる ( 図 4 ) 。 Grapher) では、 SNMP を用いてマクロな観測を簡便ににひろく使われている MRTG (Multi Router Traffic 求されるかもしれない。たとえば、インターネットの管理週、月、年といった長期間のレベルでの継続的な監視も要用帯域の経時変化をマクロに捉える必要がある。さらに、を石忍するといったイ 1 璞になる。このような場合には、使用状況とその変化をみて、利用率か飽和しているかどうかワーク・インターフェイスを 5 分ごとに観測し、 1 日の利測を始める。具ー勺には、回線の両端のルータでのネットらわれる。このような症状カ斗長告されたら、使用帯域の観から東京への電子メールの酉当医カ嗹れるといった症状があサーバーにアクセスしたときに長日判待たされたり、大阪始めると、ユーザーレベルでは、東京から邸反の WWW 互接続しているケースを考えてみよう。この回線が昆雑し 1.5Mbps のデジタル専用回線を用いてネットワークを相築を検詞するような場合である。たとえば、東京・大阪間でマクロにみなけオ L ばならないのは、ネットワークの再構口にみなければならない場合がある。視については、マクロにみなければならない場合と、ミクゆる使用帯域を把屋することか重要である。使用帯域の監し、ネットワークの帯域がどオレごけ使われているか、いわ M 観北 : 033k Ⅳ 3 ( 3.4 % ) Av “ a 0 此 6 師 9 な ( 0 ず % ) C 以就 735.5 た⑩ア % ) M ロ 599k Ⅳ 30 % ) Av 0 地 : 359 ヨ k Ⅳ 5 ( 0. 。 ) 虹 0 3 ろ ( 0. も ) ドの′↓一 Sep 一を N ・ J ′・ F を 0 UNIX MAGAZINE 1998.4

2. UNIX MAGAZINE 1998年4月号

・インターネットの利用とイ且み ( 吉村伸 ) ( 45 ) ネットワークのトラブル・シューティング ( 4 ) ・・ ( 46 ) ネットワークのトラブル・シューティング ( 5 ) ・・・インターフェイスの街角 ( 増井俊之 ) ・ 1997 年 4 月 ~ 1998 年 3 月 04 26 05 58 ・・ 1997 / ・ 1997 / ( 26 ) ハードウェア去斤情報・・ Column ・・ 1997 / 07 118 ( 1 ) 携帯情幸末 Pilot のプログラム開発・・・・・・ 1997 / 12 109 ( 2 ) 重加勺曖床検索・・・・・・ 1998 / 01 65 ( 3 ) 重加勺第未検索プログラムの作成・・・・・・ 1998 / 02 76 ( 4 ) 予測インターフェイス・・・・・・ 1998 / 03 120 ・倉敷楙斗学大学のネットワーク構築 ( 小本林ロ真 ) ( 13 ) お買物リスト・・・ 1997 / 04 38 ( 14 ) ネットワークー画・・・・・・ 1997 / 05 52 ( 15 ) ダイヤルアップ・サーバー・・ 1997 / 06 59 (16)DHCP ・・・・・・ 1997 / 07 72 ( 17 ) ネットワークカ ) ・・・・ 1997 / 08 62 ( 18 ) インターネットを利した試験・・・・・・ 1997 / 09 95 ( 19 ) ホリシー・シェーピング・・・・・・ 1997 / 11 63 (20)MRTG ・・・・・・ 1997 / 12 38 ( 21 ) 岡山情報ハイウェイ・・・・ 1998 / 01 41 ( 22 ) 岡山情報ハイウェイ ( 2 ) ・・・・ 1998 / 02 57 ( 23 ) お買物リスト ' 98 ・・・ 1998 / 03 43 ・ファイアウォールの作り方 ( 白崎博生 ) (I)OS とソフトウェアのインストール・・・・ 1997 / 11 123 (2)FWTK の入手とコンパイル・・・・ 1997 / 12 96 ( 3 ) OS のド及とカスタマイズ・・・・・・ 1998 / 01 86 ( 4 ) セキュリティ・ポリシーの作成・・・・・・ 1998 / 02 45 ( 5 ) セキュリティ・プランの作成・・・・・・ 1998 / 03 17 ・プログラマー入門 (27)JavaScript ( 6 ) ・・ (28)JavaScript ( 7 ) ・・ (29)JavaScript ( 8 ) ・ (30)JavaScript ( 9 ) ・・ (31)JavaScript ( 10 ) ・・ ( 荒井美千子 ) 1997 / 04 93 ・・ 1997 / 05 107 ・・ 1997 / 06 90 ・・ 1997 / 07 108 1997 / 08 127 (32)Microsoft の Web 技術・・・・・・ 1997 / 09 122 (33)Microsoft の Web 技術 ( 2 ) ・・ (34)Microsoft の Web 技術 ( 3 ) ・・ (35)Microsoft の Web 技術 ( 4 ) ・・ (36)Microsoft の Web 技術 ( 5 ) ・・ (37)Microsoft の Web 技術 ( 6 ) ・・ (38)Microsoft の Web 技術 ( 7 ) ・・・プログラミング・テクニック・・ 1997 / 10 136 ・ 1997 / 11 157 ・・ 1997 / 12 116 ・・ 1998 / 01 136 ・・ 1998 / 02 113 ・・ 1998 / 03 128 ( 多治見寿和 ) ( 1 ) ソースコードから学ぶ・・・・・・ 1997 / 11 95 ( 2 ) データ構造・・・・・・ 1997 / 12 128 ( 3 ) 2 重リンクリスト・・ 1998 / 01 108 ( 4 ) : 木構造・・・・・・ 1998 / 02 70 ( 5 ) : 料冓造の作成と探索・・・・・・ 1998 / 03 111 ・ワークステーションの基礎矢 ( 齊藤己 ) (23)CPU ・・・・・・ 1997 / 04 45 (24)CPU ( 2 ) ・・・・ 1997 / 05 101 (25)CPU ( 3 ) ・・・・ 1997 / 06 116 UNIX MAGAZINE 1998.4 ・ AUTONOMOUS ZONE ( 粉川哲夫 ) (1)VirtuaI Reality Universe ' 97 ・・・ 1997 / 08 139 (2)One to One Communication ・・・ 1997 / 09 130 (3)VRN'1L ー記号から射景彡へ・・・・・・ 1997 / 10 147 ( 4 ) 02 と外付け Ultra Wide SCSI ・・・ 1997 / 11 116 ( 5 ) コンピュータにとっての委に / : ・・・・・・ 1997 / 12 156 ( 6 ) 情報マシンの宿命・ 1998 / 01 152 ( 7 ) ネットワークと動可央像・・・・・・ 1998 / 02 149 ( 8 ) 個族の日に・・・・・・ 1998 / 03 103 ・ Book Review 『 UNIX lnternals: The New Frontiers 』西本亨・ 1997 / 05 134 CFTP サー , 寸冓築ガイド』十」京哲①に・・・・・・ 1997 / 06 135 ・ Coffee Break ハッカーと食生活、ホーム・ディレクトリ itojun@itojun ・ org/ yuo@h.nui.org ・・・・ 1997 / 12 107 コンピュータの買い方、 PC UNIX 者のノート PC 選び izawa @anatano.koi.bi.to/itojun@itojun.org ・・ 1998 / 03 67 、 146 ・ NetNews 便り ( みるく ) fj の手引きを才齬高するニュースグループ・・・・・・ 1997 / 04 120 INN のセキュリティ・ホール、 Microsoft lnternet News の間題・・・・・・ 1997 / 05 128 セキュリティ・ホールのいろいろ・・・・・・ 1997 / 06 137 フリー・ソフトウェア配布と NetNews ・・ 1997 / 07 132 新 . archives. * に才齬哥される文書・・・・・・ 1997 / 08 90 お知らせ / 募集用ニュースグループ・・・・・・ 1997 / 09 107 URL Map about fj. * ・・ 1997 / 10 119 メール感染型偽ウイルス情報・・・・・・ 1997 / 11 110 fj の著竹権ガイド・・・・ 1997 / 12 147 fj Words World ・・・・ 1998 / 01 122 NetNews 用語・・・・ 1998 / 02 130 Wizard って何 ? ・・・・・・ 1998 / 03 148 ・ワークステーションのおと ( 坂下秀 ) (IOI)DiskSuite 4.0 ( 6 ) ・・・・ 1997 / 04 74 (102)DHCP を使おう・・ 1997 / 05 72 ( 103 ) ファイルサーバーか壊れた ! ! ・・・・ 1997 / 06 80 ( 104 ) 続・ファイルサーバーカれた ! ! ・・・ 1997 / 07 88 (105)DHCP サーバーあれこれ・・・・・・ 1997 / 08 121 ( 106 ) 電話システムの入替え・・・・・・ 1997 / 09 103 ( 107 ) 電話システムの入替え ( 2 ) ・・・・ 1997 / 10 98 ( 108 ) オフィスの引越し・・・ 1997 / 11 71 ( 109 ) オフィスの引越し ( 2 ) ・・・・ 1997 / 12 81 ( 110 ) オフィスの引越し ( 3 ) ・・・・ 1998 / 01 77 ( 111 ) 実家でも電子メール・・ 1998 / 02 98 (112)Deskpro 4000S ・・ 1998 / 03 98 167

3. UNIX MAGAZINE 1998年4月号

連載 UNIX Communication Notes 図 3 RTT (Round Trip Time) 素送信ホスト処理開始図 2 とネットワーク負荷の系受信ホスト遅延 0 ネットワークの負荷途中にあるルータなどの通信機器におけるバケット処理遅延もあるだろう。遅延とネットワーク利用頻度のあいだにも相関関係がある。ネットワークがあまり使われていないと遅延は低く抑えられるが、ネットワークの利用頻度か高くなって混雑してくると遅々寺間は大きくなる ( 図 2 ) 。伝送方式によっては、ネットワークの利用頻度が高くなると遅延が無限大、つまり、いつになってもデータカイ云送されない状態になることもありうる。たとえば、 Ethernet ではネットワークの利用頻度か高くなりすぎると、いつまでたってもデータ伝送カそきず、結果として遅々当間が無艮大になってしまうことがこれまでの研究で明らかになっている。ネットワークの遅延を考える場合、、、高速ネットワーク " という言葉には注意しなければならない。私たちはよく高速ネットワークという言葉を口にするが、たいていは広帯域ネットワークを指す。しかし、この言葉の用法が混同されているため、、、広帯域ネットワーク = 高速ネットワーク " と信しているユーザーは多い。このため、たとえば「 OC -12 の ATM ネットワークを使うと、伝送遅延はほとんど 0 になる」といったようなことを言う人もいる。たしかに、現在利用しているネットワークより広或なネットワークを使うことで、ネットワークの利用頻度が相対的に低くなり、結果として遅延日判肋ゞ小さくなるのは事実である。その未で、高速ネットワークということもできる。しかし、より広帯域なネットワークを使っても、伝各における伝送遅延は絶対に 0 になることはなく、定の伝送遅延がかならすある。したがって、伝各が長くなれば、たとえ OC-12 の ATM ネットワークを使ったとしてもある程度のイ云送遅延が生じるのである。遅延については、 RTT (Round Trip Time) に注意し処理終了時刻なければならない。 RTT とは、その名が示すように、送信先にデータを送り、そ窈区答をもらうまでの往復の時間である。ー殳に、通信システムでは RTT が小さな状態のはうが TCP などのプロトコルでの応答生か高くなる。逆に RTT の大きなネットワークでは、 TCP のフローントロールなどをうまく機能させるのか難しくなり、性能が劣化する。したがって、 RTT が小さくなるようにネットワークを構築したり、あるいは RTT が大きな状態を解消するようにネットワークを運用することカましい。図 3 でいえば、 RTT は、 RTT = tl 十 t2 十 t3 十 t4 十 t5 となる。ここで、 tl と t5 はそれぞれ送信側でのデータの送受信処理、 t2 と t4 はそれぞれネットワークでの伝送時間、 t3 が受信イ則でのバケット処理の時間である。 RTT には、もちろんネットワークでの伝選屋延が含まれるが、それ以外に送信先ホストで窈区送処理にかかる時間も含まれる。したがって、 RTT を言れ則したとしても、それは通信路での伝選屋延を正確に表すわけではない。バケット率バケット損失率とは、ネットワーク内の 2 点間で通信をおこなった場合のバケット損失の発生率を表す。バケット損失は、データリンク・レベルでは次のような原因で発生する。・通信路のノイズによるデータ工ラー・データをバースト的に送信した場合のネットワーク・インターフェイスへのノヾッフア・オーノヾーー ' フローー 16 UNIX MAGAZINE 1998.4

4. UNIX MAGAZINE 1998年4月号

れる。配送に使われるシステムを所有する ISP に直接分配されるわけではない。したがって、そのコストをどこかに転嫁仮に目標値を設定したとしても、ネットワーク環竟本の性能は、利用するデータリンク技術の能力だけを担纒こしなけれはならなくなる。決められるものではない。使用するワークステーションなインターネットにおける広告は、提供する側からは上交どのユーザー側の機器の設定や性能、ネットワーク・サー的対象を絞りやすいという利点もあるようだ。 Web 広告ピスを提供するサーバー群の設定や性能にも大きく左右さのマーケットは念敷に拡大しつつあるが、今後もさらに伸れる。ところが、ネットワーク導 . 邸学の性能評価では、たびると予測されている。そのなかで、酉占医コスト負担の間んなる通イ各の匪能測定にとどまるケースか大半である。題がどのように扱われるかはたいへんに興架い。ネットワークが運用段階に入っても、ネットワーク竟性能管理の現状の性能調面を定常的かっ十分に実施しているところは少ないようだ。去も匠は、 SNMP を用いたネットワーク管理シネットワーク管理のさまざまなイ業のなかで、もっともステムによってルータでのバケット処理の測定が可能に厄介なのが生能管理である。前回も説明したように、性能なり、ネットワークのおおまかな負荷を知ることができる管理では、言 1 時に掲げた達成目標を構築したネットワーようになってきた。しかし数分あるいは委齟間といったクで実現できたかどうかを調べ、状況に応して適切に対応ま麒月間のネットワーク利用状態を寸・分に角財斤できる竟をしなければならない。具イ勺には、ネットワークの導入時用意しているところはあまりない。多くの場合、尉見対象に性能を測定し、意図どおりに構築されているかを石忍すはネットワークだけであり、たとえばネットワーク・サーる作業や、運用状態に入ったネットワークを調べ問題をビスを提供するサーバーの運用状態や負荷などもあわせて発見する作業が含まれる。評価するような仕組みを総合的に構築している竟は伏ところが、現在のネットワーク構築においては、言段では稀であろう。運用中のネットワークでは、いすオ L 必要階で、となるネットワーグ叫冓築の準備としての長期的観測も重要である。さらに、ネットワークが急激に遅くなるといっ・ユーサーにとってどの程度のネットワーク帯域が必要かた障害に対応するためには、去麒月間の精密な則技術も不・どの程度のバックポーン帯域が必喫か可欠である。このように、運用状態にあるネットワーク竟に対するといった点を利的に決定するプロセスが欠けているよう性能管理では、いろいろな側面からの則が必要になる。だ。たとえば、運用中のネットワークでの利用状況を定期そのため、これらのニーズにつねに応えられるような調則的に測定して予測に役立てたり、あるいはシミュレーショ竟の整備は、コスト的にも運用的にもかなりの負担になンをするといったことはあまりない。実伏はといえは、「ネる。すべてのネットワーク・セグメントにトラフィック言れ則ットワークが昆雑して遅くなってきたのかな」と感してか機器を常日喆妾続しておくといった対策も考えられるが、大らネットワークのトラフィックをすこしばかり測定し、自莫なネットワークでは莫大なコストがかかるため、けっ分の感触か事実であることを石忍してから、より帯域の広きよくは運用上重要なセグメントに絞って監視するといっいデータリンク技術を使おうとネットワーク言 t を始めるた決析を下すことも多いようだ。ことが多いのではないだろうか。これは、ネットワークの状態を定常的に観測する仕組みか整っていなかったり、今回は、性能評価を中心として、工知点で利用できる手利用予測やシミュレーションをおこなう環境がなかった法について解説する。り、あるいは、ネットワーク機器の償却期間か决められていて、問題が発見されてもすぐに対応できないといった性能管理の目標要因があるからであろう。このような理由から、性能管理において重要な位置を占める性能の目標値を設定しないままネットワークの構築に着手することがかなり多いと思わ連載 UNIX Communication Notes— さきはども述べたように、性能管理の目標は、ネットワークが意図どおりの性能を提供しているかどうかを調べ、 14 UNIX MAGAZINE 1998.4

5. UNIX MAGAZINE 1998年4月号

増えるネットワークプリンタの利用かってネットワークプリンタといえば、社内ネットワークの整備された大企業で使われるもの、というイメージが強かった。しかし最近では、小規模オフィスにおいてもコンピュータのネットワーク化によるリソースの共有が進み、たとえば SOHO 的な規模のオフィスでもネットワークプリンタの導入はめずらしいことではなくなっている。たしかに、小規模なネットワークであっても、サーノヾーなしでネットワークに接続できるネットワークプリンタ導入のメリットは大きい。リソースの共有という観点からも、スペースの節約、コストの削減、といったメリットを直接感じられるのがネットワークプリンタであろう。以下、ネットワークプリンタを選ぶポイントをいくつかあげてみる。オフィスに必要なプリンタの基本機能ネットワークプリンタとはいっても、やはりプリンタ自体の機能がまず重要であることはもちろんである。ネットワークプリンタはほとんどがレーザープリンタであり、いまや印刷解像度は 600dpi がスタンダードだ。スムージング機能によって擬似的に 2400dpix600dpi といった高解像度を実現している機種もある。ネットワークに対応するソリューション最近、企業内だけでなく小規模オフィスでの利用も増えているネットワークプリンタ。進化するネットワーク環境に対応して、ネットワークプリンタもますます高機能化している印字スピードでは、 A4 6 枚 / 分、といったところを標準として、 A4 20 枚以上 / 分といった高速プリントを実現する高機能な機種も登場している。ネットワークプリンタにとって、この印字スピードは意外に重要なファクターである。ネットワーク全体の出力枚数に対応できないプリンタでは、ネットワーク化したことで逆にプリント待ち時間が増えてしまう、といった事態も発生しかねない。将来的なネットワークの規模、出力枚数を計算にいれて、ある程度余裕ある機種を選択したほうがいいだろう。また最近では、いったんプリントした書類のイメージをプリンタのメモリ上に保持し、複数部数の出力時にはメモリからの高速プリントを可能にしたプリンタも登場している。プリント後にコピーする手間が省け、きれいな出力を手にできるわけだ。印字スピードと同様、対応する用紙サイズと給紙容量も重要なポイントである。最近のプリンタでは A3 ~ A4 の用紙サイズに対応したものが多くなっている。オフィス内での用紙サイズごとの出力枚数を見極めて、必要な給紙容量を持ったプリンタを選ぶべきである。たとえば、 B4 と A4 をほば半々に出力するならば、最低 2 段の給紙カセットが必要となる。手差しの印刷が頻繁に発生するようでは、ネットワークプリンタの価値は半減してしまう。オプショントレイカセットの増設などによって、最大何枚までの給紙容量が確保できるのか、チェックしておくべきだろう。キヤノン販売レーザーショット LBP-750 レーザーショットのスタンダード〇プリント解像度 : 2400dPi 相当 x 600dpi 〇プリント速度 . A4 8 枚 / 分〇給紙容量 : 250 枚 ( 最大 850 枚 / 3 カセット ) 〇用紙サイズ : A3 / B4 / A4 / B5 / A5 〇内蔵メモリ : 4MB ( 最大 36MB ) 〇対応プロトコル : TCP / IP ・ EtherTaIk ・ NetWare ( 別売カード要 ) 〇 NetSpot によるネットワークプリンタ管理が可能〇標準価格 158 , 80 円

6. UNIX MAGAZINE 1998年4月号

連載 UNIX Communication Notes— 0 図 1 スルーブットとネットワーク負荷の系問題がある場合には適切に対処することにある。この目標をいくっかの技勺な項目に分け、各項目ごとに考えてみよう。通信路性能性能管理の重要な柱は、通信路の性能測定と詔面である。これは、構築したネットワークを構成する通信路カ硼待どおりの性能を発揮しているかを測定することである。ー殳に、通信路の性能測定では以下の点カ甘票となる。荷 " とは、ネットワークに接続されている端末がおこなう・スルーブット (throughput) 通信の頻度を表していると考えてよい。・遅延・バケット損失率実際にスルーブットを測定すると、ネットワークをあ・スルーブットや遅延の揺らぎまり使用していない場合は利用状況に応した値か得られるが、ネットワークの利用頻度が高まってくると、ある時スルーブット点から制御のためのオーバーヘッドか増大し、スルーフッスルーブットは、通信路が単位時間あたりに伝達できトが劣化する ( 使用しているデータリンク技術の種別や、る情報量を表す。たとえば、私たちはしはしばネットワルータやハプ、スイッチといった通信機器の性能によってークの性能を示す指標として「最大 12Mbps のスルー劣化の特生は変わる ) 。つまり、スルーブットとはネットブットが得られている」といった表現をする。ワークの利用状況に応じて変化するものなのである。ネッの、、 12Mbps" は、通信路が毎秒 12 , 000 , 000 ビットを伝トワークを過度に利用している場合、スルーブットは劣化送していることを表す。スルーブットを考える場合、いくすると憶えておいたほうがよい。っかの点に注意しなければならない。 1 つは、通信路カ甘是供するバンド幅 (bandwidth) ある遅延は、ネットワークにデータを流したときに、伝播にいは帯域と、通信路のスルーブットとは違うという事実でかかる時間を表す。ネットワークの遅延は、さまざまな要ある。たとえば、 Ethernet は IOMbps の帯域を提供す因に左右される。るが、スルーブットは 2Mbps といった場合もある。ーヨ殳その 1 つは、媒体における伝幻屋延である。たとえば、に、帯域はデータリンク技術を言したときの理言制直で定義されるのに対し、スルーブットは実際に測定した生能を光ファイバーを用いた伝各の場合、伝選屋延は光ファイバー内での光の伝播速度とファイバーの長さによって決ま示す。したがって、ネットワークの実装にともなうオーバーヘッドや測定に使用するソフトウェアなど、さまざる。したがって、距讎勺に長いファイバーを利用すれは、まな要因に景を受ける。さらに、性能を測定して最大スもちろん伝選星延が大きくなる。ルーブットを則したとしても、理言制直としての性能であ遅延は、伝各に送り出す手順によっても生しる。たとる帯域と同じ値か彳昇られることはほとんどない。このようえば、毎秒 10 回 ( 0.1 秒 ) 間隔で伝叝各にバケットを送なことから、ネットワークの帯域はあくまでも 1 つ窈票出するデータリンク技術では、その送出手順によって遅延として捉え、現実のスルーブットとは異なると考えるべきが生しる。こでの送出手順を、一ヨ殳にメディアアクセスである。制御 (MAC: Media Access Control) と呼ぶ。もう 1 つは、スルーブットとネットワークに対する負さらに、 TCP/IP 層でのバケットの処理やバッファリ荷との相関関係である。図 1 は、横軸にネットワークのングなどでも遅延が生しるし、アプリケーション・レベル負荷、縦軸にスルーブットをとり、多くの通信システムがでの遅延では、各種の情報処理のオーバーヘッドもカ刪未さこで、、ネットワークの負もっ特性を示したものである。れる。 LAN 相圧接続工竟やインターネットでは、経路のスルーブット - 最大スルーブット 0 0.5 ネットワークの負荷 15 UNIX MAGAZINE 1998.4

7. UNIX MAGAZINE 1998年4月号

また最近では、企画書などの書類にデジタル写真等のイメージ要素が多く取り入れられ、ドキュメントのカラー化も進んでいる。プレゼンテーション用のカラー書類を多く作成する企画、デザイン、広報などの部門では、カラーネットワークプリントが必要となる場合も多いだろう。た。たとえば、 W ⅲ dows では縮小印刷がサポートされている OS によって異なり、プリンタの機能が活用できない場合も多かっスされることが多いようだ。以前はドライバーソフトの機能が最近では Windows95 や NT 用のドライバーソフトからリリーは、当然ながら各 OS に対応するプリンタドライバが必要となる。また、クライアントマシンが多種類の OS で構成される場合 UNIX マシンなど、複数のクライアントマシンに対応可能だ。 Windows95 や WindowsNT 、 NetWare 、 Macintosh 、ンの場合もあるが、これらのプロトコルをサポートしていれば、いる製品が多い。ネットワークカードは標準の場合もオプショ ( IPX / SPX ) 、 EtherTalk の 3 つのプロトコルをサポートして最近のネットワークプリンタでは、 TCP/IP 、 NetWare きるか、が重要になる。トワークカードによってどんなネットワークプロトコルに対応でネットワークプリンタを選ぶ場合には、そのプリンタがネッマルチプロトコル対応とドライバーソフト〇標準価格 : 1 , 380 , 000 円・ NetWare ( オプションカード要 ) 応プロトコル : TCP / 旧・ EtherTalk / A3 / A4 〇内蔵メモリ : 48MB 〇対カセット ) 〇用紙サイズ : A3 ワイド〇給紙容量 : 250 枚 ( 最大 500 枚 / 2 し 8900-40 A4 1 6 枚 / 分 ( カラー A4 4 枚 / 分 ) REALBEAMS dpi 相当 X600dpi) 〇プリント速度カラーレーザープリンタ dpi ( スムージンク機能使用時 1200 〇プリント解像度 : 600dPiX600 三菱電機高性能ビジネスカラープリンタある。使用する各 OS 用のドライバーソフトの有無はもちろん、念のため、その性能を確認してみたほうがよいだろう。ネットワークプリンタ管理ユーティリティネットワークプリンタで重要となるのが、その設定を管理するソフトである。ネットワークプリンタは席から離れたところに設置されるものだから、プリンタの現在のステータスの表示、あるいは設定の変更といった操作をクライアントマシンで出来たほうが便利である。最近では、ネットワーク管理の標準プロトコル、 S 、狸 (Simple Network Management protocol) に対応したプリンタも増えてきた。また、プリンタ管理に必要な MIB (Management lnformation Base ) の情報を、インターネットのプラウザによって表示させることも可能になってきている。これを利用すれば、プラウザが動作すれば、 OS を問わずどんなクライアントマシンであってもリモートでのプリンタの管理が可能になる。たとえば、キヤノンの NetSpot ( ネットワークプリンタ管理ソフト ) では、 SNMP 、 MIB への対応によって、クライアントマシンからのプリンタ管理を可能にしている。日立工機タイフーン 24 (LB024AHK) 〇プリント解像度 : 600dpix600dpi 〇プ丿ント速度 : A4 2 / 分 (MOP 機能により多部数時にはメモリからの出力が可能 ) 〇給紙容量 : 1100 枚 ( 最大 3100 枚 / 3 カセット十ペーバーデッキ ) 〇用紙サイズ : A3 / B4 / A4 / レター / リーガル / B5 / A5 〇内蔵メモリ : 24MB ( 最大 72MB ) 〇対応プロトコル . TCP / IP ・ EtherTalk ・ NetWare ( ネットワークモデル・バワーモデルで標準 ) 〇 VPT アーキテクチャにより最大 64 通りの仮想プリンタ登録が可能〇標準価格 878 , 000 円 ( 2 書体ネットワークモデル )

8. UNIX MAGAZINE 1998年4月号

FreeBSD を使った OCN 工コノミー接続環境 2 ン個別の設定などが困難なユーザーがいたため、 NAT で切り抜けることにしました。ほかにも安全性を高める工夫をしています。外部からの侵入の危険に茁妾さらされるサーバーを守るため、外部セグメントへの入口となるプライマリ・サーバーに、 ipfw によるフィルタリングとロギングをおこない、 IP のレベルで防御しています。さらに、両サーバーに TCP wrapper を使って TCP のレベルでガードをかけています。図 2 に、当サイトのネットワークを示します。 2 台のサーバーはグローバル IP アドレスをもつネットワーク似 - 下、グローバル側ネットワーク ) とプライベート IP アドレスをもつネットワーク ( ローカル側ネットワーク ) の双方にインターフェイスをもっています。プライマリ・サーバーは OCN ェコノミーへのインターフェイスももっていますが、これは Point-to-Point 接続なので、インターフェイス自体には IP アドレスを割り当てていません (OCN 側のルータの IP アドレスをもつインターフェイスであるかのようにみえます ) 。当サイトでは、グローバル側ネットワークには OCN から割り当てられた 210.145.161.16 ~ 31 の 16 個のアドレスからなる 28 ピットのネットワーク、ローカ / 則ネットワークには RFC1918 に示されているプライベート IP アドレス空間のうちでもっとも憶えやすい 10.0.0.0 / 8 のネットワークを使っています。図でも分かるとおり、外部とのデータのやりとりはすべてプライマリ・サーバーを介することになります。外部とプライマリ・サ→ヾーとの通信はプライマリ・サーバーが妾おこない、外部とセカンダリ・サーバーとの通信はプライマリ・サ→ヾーを経由してグロ→ヾル側のネットワークを通っておこなわれます。ローカル側ネットワークに接続されたクライアント・マシンからの通信もプライマリ・サ→ヾーを通ることになりますが、このときプライベート IP アドレスとグローバル IP アドレスの変換がおこなわれます。このイ督みについては彳あします。なお、図 2 ではグローバル用とローカル用に 2 系毓の LAN か張ってあるかのように描いていますが、実際にはこの 2 系統の LAN は前述のとおり 1 つの 10B e2 / T べースのネットワークで代用されています。 2 台のサーバーには NE2000 互換の NIC がそれぞれ 1 枚ささっているだけですが、 1 つの NIC に複数の IP アドレスを割り当てることができるのを利用して、物理的な 1 つのネッ UNIX MAGAZINE 1998.4 トワークに論理的に 2 つのネットワークを割り当てています。ほんとうは、物理的にも 2 つの LAN に分けたはうカ吶部のネットワーク障害がインターネットと妾続に影響をおよばす可能カ觝くなり、 ipfw の設定も楽になるはすです。しかし、私たちはできるだけ財布からお金が出ていかないようなガ去をとりました。 FreeBSD のインストールシステムの構築で初に必要なのはもちろん、 Free- BSD のインストールです。といっても、実際のインストールについては、解言己事や本が多く出ていますからこでは省略します。当サイトで使用している FreeBSD のバージョンは 2.2. I-RELEASE で、、各不重のセキュリティ関 ; 里のノヾッチを当てています。 2.2.1 は、サーバー構築当時の最新ハジョンでしたカゞ、その後、 2.2.2-RELEASE と 2.2.5 ー RELEASE が公開されています 5 。 2.2.2 以降は /etc の設定ファイルの名前が一部変更されていますが、基本的な設定などははば同しです。説明は 2.2.1 をもとにしますが、 2.2.2 以降を使っている方は以下の説明中の / etc /sysconfig を /etc/rc. conf に、 /etc/netstart を /etc/ rc. network に読みかえてください。当サイトでは、プライマリ・サーバー、セカンダリ・サーバーとも通常どおりインストールしました。この際、カーネルソースもインストールします。あとでカーネルの再構築が必喫となるからです。それぞれのサーバーの NIC にはとりあえすローカル側ネットワークの IP アドレスを割り当てました。プライマリ・サ→ヾーが 10.0.1.1 、セカンダリ・サーバーが 10.0.2.1 です。各サーバーの NIC に複数の IP アドレスを割り当てる必要があります。当サイトのプライマリ・サーバーの場合、 NIC のテンヾイスドライバは ed0 なので、これに 10.0.1.1 と 210.145.161.17 の 2 つのアドレスを割り当てます。また、別の事情で 210.145.161.18 というアドレスも同時に割り当てています。そこで、 /etc/sysconfig 5 1998 年 2 月現似 network_interfaces="edO 100 ” (/etc/rc. conf) のなかで、 121

9. UNIX MAGAZINE 1998年4月号

連載 /UNIX Communication Notes—@ ・ネットワーク制御方式で定義されているバケット破棄 ( たとえば、 ATM スイッチにおけるセル廃棄処理など ) バケット損失率は、ネットワークの状況によっても変化する。たとえは、ひどく混雑したネットワークでは、データの送信・受信処理が追いつかすにバケットをとりこはすことも多い。 IP レベルでは、・大きな IP データグラムの伝送処理で発生したフラグメントの破棄・ノヾッフア・オーーノー - フローー・ TCP/IP の実装の不具合といった原因で IP データグラムか破棄されてしまう。 IP レベルでのバケット損失率は、インターネットの性能を考える場合に重要な孑票である。インターネットのネットワーク層プロトコルである IP では、大きな IP データグラムを伝送するデータリンクの MTU (Maximum Trans- mission Unit) を単位とするフラグメントに分割する。のとき、もとの 1 つの IP データグラムを構成する複数のフラグメントのうち、伝送中にどれか 1 つでも失われてしまうと、もとの IP データグラムを復元することができない。このため、 1 つの IP データグラムを構友するフラグメントのうち、たった 1 つのフラグメントか損失しても、正しく受信できたはかのフラグメントを破棄し、 IP データグラムの復元をすることはない。したがって、データリンク・レベルでのバケット損失率は IP 層レベルの匪能に大きな景グを与える。データリンク層でのバケット損失率が IP 層レベル窈生能に与・える景グについてよく紹介されるのが、 NFS の性能劣化の間題である。 NFS では、デフォルトで NFS サーバーとの通イ創寺に 8KB のデータブロックを交換する。現在、 LAN でひろく使われている 10Base T Ethernet では MTU が 1 , 500 オクテットなので、 NFS のデータを運 XIP データグラムは通常、 6 つのフラグメントに分割される。 NFS サーバーとのあいだの通信路でバケット損失率か高いと、これらのフラグメントか頻繁に失われ、結果として NFS サーバーを十分に利用できなくなる。このため、 NFS ではチューニング・パラメータとして、 NFS サーバーとやりとりする際のデータサイズカ甘旨定できる。去も匠ひろく使われている ATM では、データリンク層レベルで交換されるバケットは、セル " と呼ばれ、そのサ UNIX MAGAZINE 1998.4 イズはヘッダが 5 バイト、データ領域が 48 バイトしかない。 ATM では、そ云送方式からネットワーク内でセルが廃棄されることがある。仮に、ヘッダを含めて 8KB ( 8 , 192 バイト ) の IP データグラムが、単純にそのまま ATM セルに分割されてイ幻医されると考えると、 171 個のセルに分割される 1 。ある ATM ネットワークでのセル廃棄率が 0.1 % だったとする 2 。この場合、 IP データグラム・レベルでの廃棄率は、ー ( 1 ー 0 ・ 001 ) 171 = 0.15725 . となり、約 15.7 % の IP データグラムか破棄されてしまう。もちろん、現実の ATM ネットワークでは、セル廃棄率が 0.1 % というような状況はますありえない。しかし、 ATM ネットワークでは、セル廃棄率とネットワークの負荷に相関関係があり、負荷か高い状況ではセル廃棄率は上昇する。したがって、 IP データグラムか破棄される可能性はセル廃棄率以上に高まる。 IP 層でのバケット損失率が高い場合、さらに上位の TCP 層での生能も念敷に劣化する。 TCP は、コネクション指向型のトランスポート・プロトコルである。 TCP の通信生能は、 TCP で使われているフロー制彳卸、輻輳制御によって決められる。こでは詳細な説明はしないが、現在の TCP で使用されているウインドウフロー制御では、順調に通信がおこなわれているときは順次 TCP プロックの送出ペースを上げていき、咼いスルーブットを出そうとする。しかし、いったん通信中に IP バケットが失われると、ネットワークて疆輳が発生しているとみなし、 TCP プロックの送出ペースを一気に下げてしまう。したがって、 IP 層レベルでのバケット損失率か高いと、いつまでたっても TCP の送出ペースカ哇がらす、結果として良好な性能か得られない。事実、現在のインターネットではこの間題が頻発している。使用しているネットワークの帯域カ分にあっても、バケット損失率の高いルータがネットワーク内にあり、 TCP レベルでの良好な性能か得 1 実際の ATM ネットワークでは、 ATM サプレイヤ (sub-layer) として AAL (ATM Adaptation Layer) か完義されている。 IP データグラムを ATM ネットワーク元医する場合は、この AAL で定義されたフレーム・フォーマットにいった / レ格糸し、それが ATM セルにうリされてイ幻される。このため、 ( 幻の際には AAL て付加されるヘッダも含めて、さらに多くの ATM セルカイ更用される。 2 通常、 ATM の言 t においては 10 ー程度のセル廃棄率を目安とする。 17 ただし運月袱態が悪いと 10 ー、すなわち 0.01 % くらいは欠落する可自旨生がある。

10. UNIX MAGAZINE 1998年4月号

ケット損失率に関連する事象を考えるときは、使用帯域をかって、 10Base5 が全盛だったときに、使用していミクロに捉える必要がある。現在のインターネットでは、る Ethernet でコリジョンが多発する状況に出くわした。 Ethernet を使っていると、ときおりネットワークが詰 WWW はデータをサーバーからもってくるときに上勺バースト的に通信をおこなう。ー殳に、インターネットをまるような感しで通信か短時間停滞してしまうのである。含む通信システムはバースト的なデータ伝送の取扱いカ Ethernet モニターでネットワークを調べてみると、かな手で、しはしばバッフアのオーバーフローを起こす。そりの頻度でコリジョンが発生している。ところが、そのれにともない、バケット損失率ががることがよくある。 Ethernet には少数のシステムしか接続されておらす、コこのような現象を発見し、解析するには、より精密な角財斤リジョンが発生するような状況とは考えにくかった。そが可能なネットワーク・モニターを利用して、彳田なトラこで、システムを 1 台すっ調べたところ、利用していたフィック量を測定したり、アプリケーションが送出するパ Ethernet トランシーノヾの 1 つの糸色糸家か彳敗妙に悪く、ネッケット量の糸変化を言欟ルたりしなければならない。トワーク本に不具合をもたらしていた。以 - E のように、使用帯域をマクロ的に観測する場合と、もう 1 つ実例を紹介しよう。インターネットを介したほミクロ的に観測する場合とでは異なる技術が必要になる。かのサーバーへのアクセスが、突然遅くなったことがあった。このときもバケットモニターを接続して観測してみる総合性能測定と、特定のホストから膨大なトラフィックが送られている。性能管理においては、システム全体の総合的な性能測定さっそく調べてみたら、旧いバージョンの DNS (bind) も必要となる。ー 0 、 authorized secondary カゞ server からひっきりなしにゾーンデータを転送しており、これがたとえば、ユーサーからある WWW サーバーの反応が原因でネットワークの負荷が急激に上がっていた。遅いというクレームがきたとしよう。このとき、ユーサーの端末と WWW サーバーとは 10Base T てオ妾続されてこれらの例からも分かるように、ネットワークやシステいるとする。この場合、屯にネットワークが遅いからだムの不具合が、ネットワーク性能に顕著な景をおよはすと考えていいのだろうか。問題の WWW サーバーが十分ことがある。このような事例は、現在も数多く発生していな性能をもっているのなら、そう考えてもよいだろう。しる。定常的に性能管理をおこなっていま、障害を思こかし、たとえば、そのサーバーが 486 ー DX 66MHz 、メ発見する効果も期侍できる。モリが 8MB の PC 上で UNIX を動かしているような時最近は、セキュリティ保全の意味でも継続的な性能管代遅れのシステムだとしたら、サーバーの生能不足をます理が重要になりつつある。とくに、、嫌な " 攻撃去は、大第一に疑ってみるべきである。いに、端末の生能力觝け量のバケットを特定のホストのポートに絶え間なく送り、れば、それか原因かもしれない。通イ譴各をそのバケットて理め尽くして利用できないようにネットワーク・システムの性能を考えるうえでは、通信したり、ターゲットとするホストのサーバープロセスをダ路、途中の通信機器、サーバー、端末など、ネットワーク・ウンさせるといったものだ。これらの攻撃では、たいていシステムを構成するすべての要素について検討し、それぞは IP バケットの送信ホストアドレスを偽造するなどして、れの生能を十分コ未する必喫がある。そのうえで、どこどのホストから攻撃しているかを隠すような細工か施されカ墹題の原因となっているかを明らかにする必要がある。ている。大量のバケットを送りつける、いわゆるサービスつまり、ネットワーク・システムのポトルネックを探すの不能攻撃 (denial of service attack) を受けた場合、運である。が悪ければサーバーがダウンするといった症状によって顕在化する。しかし、サーバーが大量のバケットを処理する障害発見能力をもっていたり、あるいは、途中の通イ各に十分な帯システムの障害により、対象とするネットワークが性能域があるような場合には、攻撃による茁妾的なネ皮害が発生を十分に囎軍しない場合もある。このため、性能管理は障せす、気づかないおそれがある。このような潜在化した攻害発見の 1 つの手段としても使われる場合がある。撃を発見するには、定常的にトラフィックを監視し、どの連載 /UNIX Communication Notes—O 19 UNIX MAGAZINE 1998.4