インターネット上の NFS NFS は LAN上では普及していますが、インターネット上ではまだほとんど知られていません。また、Novell NetWare
や Microsoft の LAN Manager など普及している PC 用ファイル・アクセス・プロトコルでも同様の状況ですが、その理由は異なります。PC
用プロトコルはまず最初に非 TCP/IP 上で実行されていましたが、NFS はこれまでいつもインターネットと Web の転送プロトコルであるTCP/IP
上で走っていました。
UDP と TCP
NFS は UDP をトランスポート・プロトコルとして、一般的に実行されています。UDP が好まれるのは、LAN 上での機能が優れ、TCP
より高速なためです。UDP は LAN 特有の高いバンド幅、短い待ち時間から得られる利点はありましたが、インターネットのようにバンド幅が低く待ち時間が長い
WAN の場合には性能は劣っていました。インターネット上で初期 NFS が経験したことは、プロトコルがネットワークを効率悪く使いバンド幅を大幅に食うということでした。
近年、ハードウェアと TCP は進歩し、この違いは縮んで、TCP の性能は UDP を上回り多くの NFS が TCP
をサポートしています。Solaris2.5 NFS は
UDP ではなく、TCP を優先して使用します。
NFS バージョン 3
NFS プロトコルのバージョン 3 は、Sun、IBM、HP、DEC、Data General など、多くの NFS
ベンダーとの共同作業で設計されました。プロトコルの改訂によって、バージョン 2 で制限されていた多くの点が克服されています。
ファイル・オフセット
NFS プロトコル・バージョン 2 は、ファイルのオフセットを 32ビット に制限しており、ユーザがアクセスできるファイルの大きさは
4.2 GB までと限られていました。大きなファイルによくアクセスするユーザにとっては、この制限は厳しいものでした。NFS
のバージョン 3 はファイル・オフセットや、他の多くのフィールドを 64ビット に拡張しました。
転送サイズ
NFS のバージョン 2 では、データ転送の大きさは 8KB に制限されていました。1回の読み込み、書き込み処理は 8KB
を越えることはできません。この制限によって高いバンド幅のネットワークでの性能が限られたものになっていました。というのは、一定量のデータを転送する場合、NFS
へのリクエストが人工的に増えることになってしまったからです。NFS のバージョン 3 はこの制限を取り除き、クライアントとサーバは最大の転送サイズを交渉できるようになりました。転送サイズが大きくなったことで一定量のデータを転送する場合
NFS へのリクエストは減り、ネットワークのバンド幅とクライアントとサーバの I/O リソースは効率的に利用できるようになっています。もしサーバがサポートするならば、クライアントは1回の操作で1つのファイルをダウンロードする読み込みリクエストを出すことができます。転送サイズが大きくなったことは、多くのターンアラウンドを伴う待ち時間が長いインターネットのプロトコルには重要です。
書き込みの性能
NFS バージョン 2 のサーバでは、クライアントに応答する前に、クライアントが書き込んだデータを安定した記憶装置（ディスクまたは
NVRAM）に保存することが必要でした。これによってサーバがクラッシュした場合でもデータが失われる可能性を避けられます。この必要性によりサーバが、メモリを使って効率的に
I/O をバッファする能力を損なうので、クライアントの書き込み処理性能は効率が悪くなります。サーバ上で NVRAM（Moran90）（Presto90）
を使用し、書き込みバッファを提供できますが、サーバに高価なコンフィギュレーションを要求します。
NFS のバージョン 3 には新しく COMMIT 操作が追加され、クライアントはCOMMIT リクエストによってサーバに「不安定な」書き込みができるようになりました。サーバは
COMMIT 操作を受けたときにだけ、クライアントのデータが安定した記憶装置にあるかどうかを検証することを求められます。これはクライアントがコミットしていないデータがサーバ上で失われていないかどうかを検知し回復することができるメカニズムです。NFS
V3 を実行（Pawlowski94）し測定したところ、書き込みは以前よりずっと早くなり、書き込みの速度を制限するものはネットワークのスピードだけであることが示されました。
ファイア・ウォール
TCP 対 UDP
企業のイントラネットをインターネットの破壊者から守るファイア・ウォールは、インターネット上で NFS を効率的に使う上で障害ともなっています。パケット・フィルタリングファイア・ウォールは、良く知られているポート番号を利用する
TCP プロトコル・サービスのコンフィギュレーションが比較的容易です。一方、UDP に基づいたプロトコルは繰り返し攻撃される（replay
attack）と弱いため、安全ではないと思われています。
ポート番号
NFS プロトコルは TCP 接続の際、利用するポート番号を規定していませんが、事実上の標準が用いられています。ほとんどすべての
NFS は、UDP または TCPポート 2049 で実行されています。NFS は RPC に基づくプロトコルである為、NFS
用ポート番号はポートマップ・サービスを通じてダイナミックに決定されると思われています。RPC サービスと通信するためにクライアントは最初にサービスのプログラム番号をサーバのポート・マッパに提出し、そのサービス用に割り当てられたポートを受け取る必要があります。こういったポート間の交渉をトラックできる洗練されたファイア・ウォールもありますが、一般的ではありません。パケット・フィルタファイア・ウォールも、SOCKS
のようなアプリケーション・レベルのプロクシーも有名なポートに対応したTCP の流れの方を好みます。
すべての NFS がポート 2049 で実行されているので、クライアントにポート・マッパ・プロトコルを省略させて、ポート
2049 上のサーバと直接通信して、NFS 通信のファイア・ウォールを越えることは簡単に見えるかも知れません。しかし、ユーザは最初に別の
RPC サービス、すなわち MOUNT プロトコルを使って最初にファイル・ハンドルを得ない限り、NFS サーバと通信することはできません。
MOUNT プロトコル
NFS ファイル・ハンドルとは、サーバ上のファイルやディレクトリを1つだけ特定するためにクライアントが使うサーバが作りだす値です。NFS
バージョン 2 のファイル・ハンドルは 32バイト ですが、バージョン 3 のファイル・ハンドルは最大 64バイト までいろいろな長さをとることができます（図1を参照）
図1. NFS ファイル・ハンドル
ファイル・ハンドル内のデータはクライアントにはブラックボックスとなります。ファイル・ハンドルはサーバが作り出し、サーバが素早くファイルを特定するために使われるので、クライアントがその内容を知る必要はありません。クライアントがあるディレクトリ内の特定のファイルに対応するファイル・ハンドルを得るためには、LOOKUP
リクエストを使ってそのディレクトリに対応するファイル・ハンドルとファイル名をサーバに与えます。あるいは、クライアントが新しいファイルやディレクトリを作り出した場合、クライアントはそのファイル・ハンドルを得ることができます。NFS
のプロトコルでは、クライアントがこのプロセスを起動しネットワーク上に公開（エクスポート）されたファイル・システム用の最初のファイル・ハンドルを決定することはできません。クライアントは
MOUNT プロトコルを使って、サーバ上にエクスポートされたディレクトリに対応するパスネームを与え、そのディレクトリ用の最初のファイル・ハンドルを受け取ります。
図2. MOUNT プロトコル・ダイアログ
MOUNT サービスは、NFS と同じように RPC に基づくプロトコルです。しかし NFS と異なるのは、MOUNT
プロトコルは事実上の有名なポートを持たないことです。サーバのポート・マッパを使って MOUNT プロトコルのポートを割当なければなりません。MOUNT
プロトコルとポート・マップ・プロトコルを加えたため、NFS がファイア・ウォールを通り抜けて使うことが難しくなったばかりでなく、最初の
NFS リクエストが転送される前に追加ネットワーク・メッセージに強制的なオーバーヘッドが加えらます。
まとめ
NFS がインターネット上で使われなかったのは次の理由によります。
- 最初は UDP だけで実行された。
TCP で NFS をサポートするサーバが増えてきたので、それほど問題ではなくなっています。
- NFSバージョン 2 では使用に制限があった。
バージョン 3 で制限は除去されました。
- ポートマッピング処理が必要だったのでファイア・ウォールとプロクシーにとって不便であった。
サーバをポート 2049 に直接つなげて対応できます。
- マウント・プロトコルが必要だった。
パブリック・ファイル・ハンドルとマルチ・コンポーネント LOOKUP を用います（次項参照）。
| 
