第1回 ユーザーから見たWindowsネットワークとその舞台裏：基礎から学ぶWindowsネットワーク（3/4 ページ）

[デジタルアドバンテージ，著]

　以上、ユーザーから見たWindowsネットワークの現在について簡単にご紹介してきた。いずれも日ごろから使い慣れたWindowsネットワークであり、退屈だと感じたかもしれない。しかしWindowsネットワークの核心部分は、この例だけでもかなり説明できる。つまり皆さんのゴールは、いままで述べてきた「退屈な機能」の舞台裏を理解することにほかならない。

　ただし最新のWindowsネットワークのしくみを説明する前に、ここでWindowsネットワークのこれまでの歴史を振り返ってみたい。だがこれは単なる懐古主義ではない。万物は常に過去の蓄積のうえに成り立っている。例えばコマンド・プロンプトを開いて、NTFSボリュームの適当なフォルダに移動して「dir /x」と実行してみよう。周知のようにNTFSでは、255文字までの長いファイル名を使用できるのだが、同時に内部的には、MS-DOS時代の8.3形式のファイル名もこっそり保持している。「dir /x」は、この8.3形式のファイル名を表示させるオプションである。どうして8.3形式などという過去の遺物をいまなおサポートしなければならないのか？ 歴史的な背景を知らずして、この答えを得ることはできないだろう。

Windows XPのコマンド・プロンプトで「dir /x」を実行したところ
Windows XPでは、ファイルに255文字までの長いファイル名を付けることができる。しかし過去との互換性を維持するために、内部的には、MS-DOS時代の8.3形式のファイル名も同時に生成し、それをひそかに保持している。
　（1）通常の長いファイル名。
　（2）互換性のためにひそかに生成されて保持されている、8.3形式の短いファイル名。

　これと同様に、改良に改良を加えて現在に至るWindowsネットワークではあるが、その核心部分には、初期の仕様をいまなお引きずっている部分もある。こうした古い仕様も完全に隠ぺいされているなら意識する必要はないのだが、現実には、込み入ったトラブルなどでは、一見すると合理性を欠くこうした古い仕様が問題を複雑にしていることが少なくない。

　Windowsネットワークの成り立ちを理解するには、こうした過去の経緯を学んでおくことは決して無駄ではない。

ネットワーク用の拡張BIOS：NetBIOS

　いまから約20年前の1980年代前半、コンピュータとコンピュータが通信するというネットワークは、パーソナル・コンピュータ（現在のPCの原型になったIBM-PC）にとってはまだ特別な存在で、それを実現するためのハードウェアも、ソフトウェアもほとんど整備されていなかった。当時IBMは、IBM-PC用のOSとして、ネットワーク機能を付加したPC Networks（PC-DOS 3.0をベースとして、ネットワーク機能を付加したもの）を開発し、このPC Networkで使用するためのネットワーク・カードの開発を同時に進めていた。

　マイクロプロセッサの処理能力が高く、メモリもふんだんに使える昨今では、ハードウェアに処理をまかせるより、ソフトウェアで処理した方が速いし安上がりであることが多い。しかしこのような常識は比較的新しいものだ。1980年代前半という、パーソナル・コンピュータの黎明期には、マイクロプロセッサの処理能力は極めて低く、メモリは非常に高価だった。また、ハードウェアをデバイス・ドライバのレイヤで仮想化するようなしくみもOSは備えていなかった（例えばMS-DOS時代のワードプロセッサは、各社用のプリンタ・ドライバを自分自身で持っていた）。このため当時は、拡張カード側にROMなどを搭載し、この中に基本的な入出力ルーチンなどを格納しておいて、必要に応じてこれを呼び出す方式が一般的だった。これなら、上位ソフトウェアは、ハードウェアの細部を意識しなくても、基本入出力ルーチンを呼び出すことで、それを使うことができる。例えばPCには、BIOS（Basic Input/Output System）ルーチンを収めたROMチップが搭載されており、ここにシステムの起動時テストや、キーボードやマウス（PS/2）、グラフィックス・デバイスなどのハードウェアを制御するための基本ルーチンが格納されている。現在のWindows XPなどでは、BIOSルーチンは基本的に使わなくなったが（BIOSはマルチタスクなどを考慮しない、古い仕様を元に作られているため）、過去との互換性を維持する目的で、現在でもマザーボード上に搭載されている。

　これと同様に、グラフィックス・カードやSCSIカード、ネットワーク・カードなどの拡張カードでも、その制御をできるだけカード側で請け負い、上位ソフトウェアの負担を軽減するために、BIOSを搭載するのが当時は一般的だった。BIOSレベルで機能が統一されていれば、実際のハードウェアが変わっても、OSや上位のアプリケーションは変更する必要はない。そのため各ハードウェア･ベンダは、新しい機能やまったく新しいデバイスを実装しても、互換性のために、外部からは既存のBIOSインターフェイスを使って呼び出せるようにしていた（ただしBIOSでサポートされていないような、新しい機能の利用が困難になるというデメリットはあるが）。

　このような理由から、ネットワーク・カードを制御するためのAPI（Application Program Interface）として、IBMとSytek社（その当時ネットワーク・カードの実際の設計を担当した企業）が開発したのがNetBIOS（Network Basic Input/Output System：「ネット・バイオス」）である。名前が示しているとおり、NetBIOSを端的に説明すれば、マザーボード上にあって、キーボードやマウスなどの基本入出力ルーチンを担う標準BIOSのように、ネットワーク・カードの機能を使うための、一種の拡張BIOSのようなものである。極めて低レベルであったが、NetBIOSが提供するAPIを使用することで、上位ソフトウェアは、物理的なネットワークの機能や構造を意識することなく、煩雑なネットワーク・カードの制御などをBIOSまかせにできる。NetBIOSを使えば、通信相手の名前を指定してセッション（データを相互に交換するためのパイプのようなもの）を確立し、アプリケーション間でデータ交換を行うことが可能になる。上位ソフトウェアは、ネットワーク・カードが実際にどのような信号のやりとりをするか、などといった低レベルな通信デバイスの制御を自身で行うことなく、より抽象度の高いデータ通信処理に専念できるようになるわけだ。

　プログラム・インターフェイスの観点から見たNetBIOSの基本的な機能は、「NCB（Network Control Block）」と呼ばれるデータ構造体にNetBIOSのコマンドや必要なパラメータをセットし、NetBIOS APIを呼び出すことによって、各種のネットワーク・サービスを利用するというものである。拡張BIOSなどと聞くと、いかにも古い過去の遺物といった感があるが、現在でもこのNetBIOSの仕様はWindowsネットワークの内部で生きている（この詳細については連載で追って解説する）。NetBIOSで提供されているネットワーク・サービスの機能はさして高くないが、実際の物理メディアに（大きく）依存するような部分もなく、比較的汎用性が高く設計されていた。そのためNetBIOSインターフェイスは、次々と拡張が行われながらも、現在まで生き続けているのである。Windowsネットワークを始め、さまざまなネットワーク・サービスがこのNetBIOSをベースにして機能を拡張してきたので、いまさら変えるわけにもいかないという事情もある。

　ここで注意すべきは、NetBIOSは、あくまでも上位ソフトウェアにネットワーク・サービスを提供するためのAPIを規定しているだけで、それ自体はネットワークの通信手順を規定するプロトコル（protocol）ではないということだ。プロトコルとは、異なるデバイスやコンピュータ同士が通信する際に、お互いが正しくデータを交換できるようにあらかじめ取り決めておく、一連の手順のことだ。例えばネットワークでデータ交換を行うためには、データ送受信のタイミングや送受信されるデータ・フォーマットなど、データを送り出す側、データを受け取る側の双方が解釈できる共通の手順が必要である。言葉も習慣も違う人間同士がコミュニケーションすることを考えればよい。お互いに意思を疎通するには、お互いが理解できる何らかの共通の言葉や手順が必要になるだろう（Protocolのもともとの意味は「（外交上の）儀礼や協定、条約」である）。NetBIOSでは、物理的なネットワーク媒体や、通信でやりとりされるパケットの構造などといったプロトコルは規定していない。つまり、NetBIOSが開発された初期の段階では、これらのプロトコルは明確に規定されておらず、ネットワーク・カードの通信方式に依存していた。

NetBIOSインターフェイスを拡張したネットワーク・プロトコル：NetBEUI

　例えば現在では、イーサネットやアナログ・モデムによるダイヤルアップ、ADSL、ケーブル・インターネットなど、さまざまな通信デバイスを通してインターネットに接続することができる。そして重要なことは、どのような手段でインターネットに接続した場合でも、Webブラウザやメール・ソフトウェアなどはまったく同じものを使い、設定も変更することなくネットワークにアクセスできることだ。しかしイーサネットを経由してインターネットにアクセスした場合と、ADSLモデムを経由してインターネットにアクセスした場合では、ネットワークで物理的に交換されるデータの仕様や通信手順（つまりプロトコル）はまったく異なっている。このように、異なる通信デバイスなどを必要に応じて臨機応変に組み合わせて、しかもWebやメールなどの上位ソフトウェアはそれを意識することなく使えるようにするには、混とんとしている複雑な通信手順を分析して、それらを体系的にまとまったいくつかの機能に分類し、それらの機能間でのインターフェイス（呼び出し方法）を決定して、部分部分を代替可能にすることだ。この際には、アプリケーションなどの高度なサービス・ソフトウェアを上位レイヤに、ネットワークの最も低レベルな通信の信号手順などを実装するレベル（ネットワーク・カードなど）を最下位レイヤに配置した、階層的なモデルを考慮するとよい。

　話をNetBIOSに戻そう。NetBIOSは、上位ソフトウェア（NetBIOSアプリケーション）がネットワーク・サービスを呼び出すためのAPIインターフェイスであり、通信の信号仕様とか、パケット構造などといった通信プロトコルは既定しておらず、それらは実質的にネットワーク・カードの仕様に依存していた（当初のPC-Networksシステムでは、同じベンダ同士のカードでなければ通信できなかった）。これでは、ネットワークに拡張性を持たせたり、異なるシステム間での相互運用を実現したりといった柔軟な運用な困難である。

　IBMとMicrosoft、3Com（ネットワーク製品の著名ベンダ）は、MS-DOSをベースとする、より本格的なネットワーク・システムとしてLAN Managerを開発することになった。この際3社は、LAN Managerを使ってより機能的で柔軟なネットワークを構成できるように、NetBIOSのサービス内容を拡張し、イーサネットやToken Ring（IBMが開発したネットワーク・システム）を使用する場合の具体的なパケット構造までをも決定した。こうして、NetBIOSインターフェイスを使用したネットワークの通信手順（プロトコル）の1つとして開発されたものがNetBEUI（NetBIOS Extended User Interface）である。

　このNetBEUIは、小規模なLANを手軽に構築し、運用できることを目標として開発されたプロトコルで、ネットワークに参加するコンピュータに名前を付けておくと、自動的にお互いを識別し、通信できるという特徴がある。