ftp://ftp.delegate.org/pub/DeleGate/doc/History-199801-ja.txt ------------------------------------------------ 映像メディア学会誌 Vol.52,No.2, pp.153-156(1998) てれび・さろん - ものを作るこころ(第23回) ------------------------------------------------ プロトコル中継システムDeleGateの開発ストーリー 佐藤豊 電子技術総合研究所 情報アーキテクチャ部 History of Development of Protocol Mediation System "DeleGate". Yutaka Sato Computer Science Division, Electrotechnical Laboratory [梗概] インターネットを有効利用するために開発された、プ ロトコル中継システムDeleGateの開発経緯を紹介する。 インターネットを利用する上で筆者自身が直面した問 題を解決するためのちっぽけなプログラムとして産ま れ、その後次々と直面する問題を解決しつつ拡張され、 一般に公開されて多数の利用者の支援を受けながら、 実用のソフトウェアとして支持され、急速に成長を遂 げたソフトウェアの成長記録である。 １．まえがき 十年間に及ぶ地道な試行錯誤の末ついに技術の壁を打 ち破り実用化に成功。という特にハードウェア作りの 世界で聞くことのできる感動的なストーリーは、本稿 で紹介するソフトウェアの開発においては存在しない。 実際それは開発を始めた翌日から実用に供されていた し、その後新たに機能や改良を加える都度、即日公開 され利用されて来た。 　ここに紹介するDeleGateは一般に代理サーバ(proxy server) と呼ばれるソフトの一種であり、セキュリテ ィのための防火壁(firewall)の構築や、キャッシュ (cache) によるデータ転送量の削減を始め、様々な用 途に利用されている。技術的には、サーバとクライア ントとの間の通信プロトコルを解釈しながら通信を中 継するプログラムとして実現されている2)3)4)。今日 海外製が殆んどを占めるインターネット用の基盤ソフ トの中にあって、純国産のDeleGateは1994年の開発開 始以来、国内外で広く利用され、主要な代理サーバの 一つとして生き残り、現在も絶え間無く成長・普及を 続けている。 　本稿では、本誌読者には馴染みの薄いかもしれない このような「走り続けながら成長し続ける」ソフトを 「小さく産んで大きく育てた」事例として、DeleGate の開発の経緯を紹介する。 ２．DeleGateの開発の背景 1994年は日本においてインターネットが一般社会に爆 発的に浸透を始めた一年であった。爆発の引金を引い たのは、今日「ホームページ」と通称されるサービス を実現するWorld Wide Web (WWW)の技術であり、その マルチメディア対応のブラウザ(クライアント)である NCSA Mosaicである。ホワイトハウスや首相官邸のホ ームページが開設され話題となったのもこの年である。 テレビや一般誌のようなマスメディアに(しばしばWWW と混同されながら)インターネットという言葉が連日登 場するようになり、それまで主に学術用のインフラス トラクチャとして地味に応用されていたインターネッ トは、企業による商用利用や家庭における娯楽のため のネットワークへと急速に変貌しつつ拡大していった。 　一方、一般社会に喧伝された華々しい一面の裏側で、 インターネットは技術面においても通信網の整備の面 でも多くの問題を抱え、実際には、誰もが手軽に満足 に使えるような状況ではなかった。筆者自身も利用者 として直面することになった代表的な問題は以下のよ うなものである。 　まず、セキュリティを優先して使い易さが犠牲にさ れているという状況があった。例えば筆者の所属する 電子技術総合研究所(電総研)では、90年からWIDEイン ターネットに接続していたが、セキュリティ上、外部 に直接アクセス可能なホストは「出島」と称する一台 のUnixワークステーションだけに制限されていた。一 般利用者が外部のサービスを利用するには、このホス トに遠隔ログインしてその上の応用ソフトを実行する しかなかった。当然、異なる機種のUnixやパソコン用 の応用ソフトも使えない。当時はこのように原始的な 防火壁の実現方法が普通に採られていたのである。そ れでも当時一般利用者が利用していた応用プロトコル は、利用者数も利用頻度も限られるTelnet(遠隔ログ イン)とFTP (ファイル転送)が主であり、不便ながら 実用には耐えていた。しかし WWWのように誰もが日常 的に手元のホスト上で利用したいと思う応用が現れて 状況は一変し、このように不便な原始的防火壁への不 満は爆発寸前となった。 　また、利用できる通信回線の容量は不十分であり、 接続の安定性にも欠けていた。当時の電総研とWIDEを 繋ぐ回線の容量はわずかに64Kbpsであった(当時とし ては特に細いものではなかったが)。この回線は既に、 NNTP (電子ニュース配送)とSMTP(電子メール配送)の ために飽和状態であった。ただ、これらの応用は基本 的にバックグラウンドで実行されるものであり、数分 単位の配送遅延があっても実用に耐える。ところがこ こにGopherやWWW という、データ転送量も多く、秒単 位の応答性も必要とする応用が現れた。しかもその利 用を希望する利用者は従来の応用に比べて圧倒的に多 い。一人の利用者が数キロ〜数十キロバイトのデータ 転送を数秒毎に繰り返すこのような応用では、64Kbps の回線は数人の利用者で飽和し、同時に数十人、数百 人という利用者が使うにはとても耐えない。 　さらに、 WWWを利用して日本語情報を交換すること も容易ではなかった。そもそもインターネットを利用 するためのソフトはいずれも海外製で、開発元では日 本語に対応していない。特にMacintoshやWindowsなど のパソコン用Mosaicはソースプログラムが非公開で日 本語化が遅れており、何とか日本語を扱えても、一種 類の文字コード(主にShift-JIS)にしか対応していな かった。一方、Unixをベースに発展して来たインター ネットでは日本語コードとして7bits-JIS(ISO-2022-JP) を標準としていた。このためサーバ側では同一文書に 対して複数種の文字コードの版を用意し、利用者側で はそれらを明示的に選択するという無駄で不便な状況 にあった。 　早急な解決が強く求められていたこれらの問題を、 まとめて解決・緩和する方法として登場するのが、今 日代理サーバと呼ばれるようになった技術である。代 理サーバは、その効用の面から見れば様々に定義でき るが、基本的な動作原理は単純である。まず、ネット ワーク上のソフトの基本構成は、情報や機能を提供す るサーバと、それを利用するクライアントが、規定さ れたプロトコルで通信しながら目的とする応用を実現 するというものである。ここで、サーバとクライアン トの間が、防火壁などの何らかの障壁により直接的に 通信できなかったり、あるいは直接的な通信が非効率 ・不安定である場合に、両者の間を仲立ちして効率的 な通信を実現し、さらに中継に伴って積極的に何らか の付加価値を実現するのが、代理サーバである。 　当時この技術はまだ手探りの段階であり、その効用 についても実現法についてもよく知られていなかった。 しかしこのような発想は必要から必然的に産まれるも のであり、筆者のDeleGateを含め、多くの代理サーバ の開発が独立に開始されている。 ３．DeleGateの第１版の開発の歴史 DeleGateの開発は、1994年3月2日に唐突に、筆者の一 身上の理由で始められた。この前日筆者は、同年４月 から一年間の科学技術庁への出向を内示されている。 同年度に開始予定の省際研究情報ネットワーク(IMnet) の立ち上げに従事して技術面での支援を行え、という ようなことであった。 　当時筆者の主要な研究テーマは、自律的なソフトウ ェア部品をネットワーク上で繋ぎ合わせて全体として 動作するよう外部から制御する基礎技術 1)であった。 従ってネットワーク上のソフトを作成する技術に関す る基礎知識や開発経験は持ち合わせていたものの、実 際に世の中で使われている様々な応用プロトコルには 精通していなかったし、特に流行り物には疎く、これ では出向してもお役に立てないと不安になった。 　そこで準備のため、当時インターネット上の情報提 供サービスとして流行り始めていたGopherプロトコル をまず勉強してみようと考えた。ところが、電総研か ら外部のネットワークを利用することは、前述のよう に原始的な防火壁に阻まれて非常に不便な状況であっ た。まずはこれを解決しようと思い、そのためには出 島ホスト上で外部のGopherサーバと内部のクライアン トとの間の通信を中継すれば良いと考え、そのための プログラムを作り始めたのである。 　最初に作ったのは、それまでに筆者が開発していた プログラムからネットワーク接続用の部品を流用し、 多少のコードを書き加えただけの、数百行の小さなプ ログラムであった。遠隔のGopherサーバへのアクセス を可能にするという意味で冗談めかして「go-far」と 命名し、翌3月3日に電総研内で公開した。簡単なプロ グラムではあったが、いちいち出島に出掛けずに Gopherを利用できることは画期的であり好評を博した。 　さしあたって不便さは解消したが、通信性能の問題 であまり使い物にならない。デフォルトでGopherクラ イアントを立ち上げた時に最初に表示されるミネソタ 大学のサーバのメニューが、いつまで待っても表示さ れず、時間切れで切断してしまうという有り様である。 そこで、計算機屋の当然の発想として、一旦取り寄せ たデータを再利用して繰り返しアクセスを高速化しよ うと考え、キャッシュ機能を導入したのが3月4日のこ とである。当時はまだサーバ数が少くてアクセス対象 のデータの集合が小さく、簡単な実装ながら高い効果 （キャッシュヒット率）が得られ、ともかくもGopher が使い物になるようになった。 　どうにか使い物にはなったが、今度はインターネッ ト接続の不安定性に悩まされる。とにかく頻繁に外部 のネットワークに接続できなくなったり、DNSサーバ が引けなくなる。キャッシュの導入で状況は改善され てはいたが、他にも有効な方法が無いかと考えた。こ こで、電総研とは別に、工業技術院情報計算センター からTISNに(64Kbpsで)接続しており、電総研からはこ ちらの経路も利用できた。そこで、この2つの経路を 有効に利用できないかと考えた結果、外部のサーバへ の接続を2つの経路で順繰りに行ったり、一方を経由 して接続できなかったら他方で再試行するという、経 路制御(およびDeleGateの多段接続)の機能を実現した のが、3月5日のことである。 　これらと並行して、最初の数日間のうちにTelnet、 NNTP、FTP を中継するように相次いで拡張を行ってい った。その過程で、このような中継方式を一般化する ことで、中継し得る様々な応用プロトコルや、実現し 得る様々な付加価値の可能性が思い浮かび、気分が非 常に高揚したのを憶えている。実際、その後現在まで 4年間に渡って終わりの無い拡張を続けることになる DeleGateの機能の大半は、上記の機能やアクセス制御 機能を含め、この最初の一週間にごく簡単なプロトタ イプとして芽を出し、あるいは予見されていた。 　高揚する気分の中で、ひょっとするとこのソフトは 長期間かけて育て上げていけるかも知れないと思うよ うになり、念のためまともな名前を付けて置こうと、 3月8日にはDeleGateと改名した。そもそもこの名前が 思い浮かんだのは、当時開発していたオブジェクト指 向システムでクラス階層を実現するのに採用していた delegationという概念、言ってみれば実際の処理を行 えるところまで次々に要求をたらい回しにするという 概念が、この中継サーバと重なって見えたからである。 delegateは「依託、委譲、代表者」といった意味を持 ち、しばしばgatewayの短縮形として使われる「gate」 を含んでもいる。組織を代表して外部にアクセスする ソフトを表すのにぴったりだと、この名前に決めた。 　ところで、ここまでに実現した中継の方法は、Unix 用のクライアントプログラムに手を加えて、直接目的 のサーバに接続する代りにDeleGate経由で接続するよ うにしたものであった。しかし、当時から電総研では Unix以外のコンピュータ(主にMacintosh)の利用者が 優勢であり、それらのホストでGopherやWWWを利用し たいという要求が強かった。だがパソコン用のクライ アントプログラムには手が出せない。何とか、既存の プログラムをそのまま使いながら中継する方法がない かと考えた。その結果考え付いたのが、Gopherサーバ からの応答データ中でサーバを指し示している識別名 を加工して、それを手繰るクライアントの要求が必ず DeleGateに向けられるようにしつつ、加工した識別名 の中に埋め込んだ実際のサーバの情報に基づいて DeleGateが中継を行う、というものであった。これに より、代理サーバに対応していないクライアントとサ ーバの間を中継することが可能になり、DeleGateを適 用できる対象が広がって利用者が倍増した。 　さらに、上記のようにGopherで行ったのと同様な、 識別名の書き換えという枠組を用いて、WWWのプロト コル(HTTP)の中継を実現した。その後の WWWの普及に より、DeleGateは主にHTTPの中継サーバとして普及す ることになる。また、このようにサーバとクライアン トとの間で交わされるプロトコル上を流れるデータを 変換するという基本的な枠組は、後にDeleGateの目玉 機能となる文字コード変換機能や、「マウント機能」 を実現する基礎となる。 　DeleGateの開発を始めて2週間ほどが経過し、初期 の高揚が収まったころ、筆者は大きな落胆に出会う。 HTTPの中継を実現する過程で、それまでDeleGateで実 現したような機能としては既に、Socks やproxy HTTP という方式が開発されており、しかも標準化に向けて 進み始めているらしいことを知ったからである。それ でもDeleGateの開発を放棄してしまわなかったのは、 過去に幾度となく経験していた「あのままあのソフト の開発を続けていれば今頃は…」という後悔と、「自 分自身の発想を育てて行けば、独自な(そして運が良 ければ有意義な)ものを作り出せる」という経験則に よる。また実用ソフトとしては生き残れずとも、少く とも筆者自身の研究ネタとして続ける意味はあると考 えた。とはいえ、このソフトの賞味期限はそう長く無 く、標準化が進みつつある中継方式の実装・普及が終 われば用済みになる運命と考えていた。 　さて、パソコンで利用できるようになると、今度は 文字コードの問題に直面する。前述のように当時の パソコン用のWWWクライアントは一種類の日本語コー ドしか扱えなかった。これに対処するには、DeleGate が文書データをクライアントに中継する際に、クライ アントが扱える文字コードに変換すればよい。これも 必然の発想である。その実現は技術的には容易であり、 筆者がそれ以前に開発していたvinという電子ニュー スリーダのために作成した文字コード変換用の部品を 流用して即座に実現することができた。しかし、その 後間もなく、パソコン用の日本語化Mosaicが秋には商 品として発売されるというニュースを聞き、このよう な用途もごく短期的なものであろうと予想していた。 　4月1日以降DeleGateは筆者が霞ヶ関と筑波を往復す る車中と、帰宅途中に立ち寄る深夜の電総研で、細々 と育てられて行く。また出向先の科技庁でもDeleGate の中継機能やキャッシュ機能を利用して、インターネ ット利用のデモンストレーションを行っていた。 　夏に向かうころ、WWW の急速な普及につれて、WWW 利用者間の情報交換のための電子ニュースやメーリン グリストでは、日本語文字コードの問題が盛んに言わ れるようになった。開発者としてはそう先も長く無い と思っていたDeleGateではあったが、このような状況 に一時的にも役に立てるならばと、ソースプログラム の形で一般公開に踏み切ったのが6月11日のことであ る。開発者にとっては文字コード変換機能は技術的に は面白味の無いものであったが、当時の状況ではこの ような変換機能が必須で、利用者にとっては意義が大 きく、初期のDeleGateの主用途として、普及の原動力 となることになった。 　公開後のDeleGateは、多数の利用者の手で「よって たかって鍛えられる」状態になる。不具合の報告や改 良の要求が電子ニュースや電子メールで次々に寄せら れた。特に、様々な機種のUnix上でDeleGateを利用し ようとする人達の熱心な協力により、DeleGateの可搬 性は飛躍的に高められた。公開当時は、何とか使えな いでもない程度の完成度であったDeleGateは、利用者 からの膨大なバグ報告を得て徐々に実用に耐えるソフ トへと成長して行った。 　この頃筆者の日課は、霞ヶ関からの帰宅途中に数時 間立ち寄る電総研で、その日利用者から寄せられた報 告や要求に対応して修正を行い、その日のうちに改訂 版を FTPサーバ上に置いて公開するというものであっ た。例えば9月には、1ヵ月の間に20回もの改訂版公開 が行われている。このような「作りたてソフトの産地 直売」方式は、当時の筆者の置かれた状況で仕方なく とった方法であったが、結果的にはDeleGateを急成長 させるために極めて有効な手段であったと思う。 　８月末には工業技術院でもホームページを開設する 計画が進められていた。ところが、情報計算センター の防火壁上の限られたホストしかインターネットに接 続できないため、工技院各研究所毎の WWWサーバを外 部に公開できない。そこで、各所のサーバを防火壁上 のDeleGateで統合し、これを代表として外部に公開す ることを考えた。これを実現するために開発したのが、 内部のサーバ上での情報の識別名(URL)を外部に公開 する際に書き換える「マウント機能」である。これは、 proxy HTTPプロトコルの普及につれて用済みになりか けていた、中継データ中の識別名の書き換えの機能を 流用して実現することができた。そして後にはこれが、 DeleGateの重要な目玉機能となる。 ４．DeleGate第２版以降の開発と現状 翌年4月に出向から戻った時には、DeleGateの開発が 筆者の本業となっており、ほとんど昼夜も無く全ての 時間をDeleGateにつぎこめる幸福感にひたりつつ、開 発に没頭した。その後の一年間、平均してもほぼ2日 間に1度という頻繁な改訂版の公開が行われている。 　この頃から、DeleGateを単にエンドユーザとしてで はなく、利用者固有の用途のために改変を加えて使い たいという要求が寄せられるようになった。例えば、 画像データを圧縮して中継したい、英文／和文翻訳を して中継したい、衛星経由の通信の経路制御を行うた めに利用したい、といったものであった。しかし筆者 はこのような改変使用を許諾しなかった。著作権上の 理由もあったが、第一の理由は、そのような拡張を、 DeleGateの本体に手を加えずに実現できるようにする こと自体が、研究の素材としてのDeleGateの開発目的 の一つと考えていたからである。そこで、利用者の開 発した機能をフィルタプログラムという形でDeleGate に簡単に外付けできるように開発したのが「外部フィ ルタ」という機能である。この機能はその後、様々な 機能をDeleGateに付加して利用するために活用される ことになる。 　最初の1年間で代理サーバとしての基本的な機能を、 ともかくも実用に耐えるレベルで実現した後、2年目 以降の開発の主眼は、高速化と一般化に移った。当時、 利用者がDeleGateに期待する機能は「日本語コード変 換機能付きHTTP代理サーバ」であった。しかし筆者の 興味は、代理サーバという概念により実現できる新た な機能、多くのプロトコルに対して共通に適用できる 機能を、DeleGateの開発を通じて見出すことにあった。 そのため、Gopher,HTTP,FTP,Wais,Telnet,NNTPを始め、 SMTP,POP,X,Socks,CU-SeeMeなど多数のプロトコルの 中継を次々に実現して行った。国内におけるHTTP用の 代理サーバの主流は、当初はCERN-httpd、最近はSquid であり、DeleGateは2番手に甘んじて来た。しかし HTTPに限らず様々なプロトコルを付加価値付きで中継 できる多目的の代理サーバとして、DeleGateは多方面 で利用されるようになり、独自の立場を獲得した。 　機能拡張、高速化、中継可能なプロトコルの拡大に 伴って、DeleGateのプログラム規模は拡大を続けてい る。94年の版を第1版として、年を加える毎にバージョ ン番号を加えて来たが、第1版から第4版までのプログ ラム規模は、ソースプログラムの行数にしてそれぞれ 11500行、44000行、62900行、84500行と拡大している。 可搬性の向上により、DeleGateはほとんどの種類の Unix、WindowsとOS/2において、共通のソースプログ ラムを無変更でコンパイル・実行することができるよ うになった。 　DeleGateの配布は主に、電総研の FTPサーバに置か れたソースプログラムと Windows用実行形式の形で行 われている(ftp://ftp.etl.go.jp/pub/DeleGate/)。 現在までにこれらをダウンロードした組織は65か国に わたる4500組織に及び、ダウンロード組織数は前年同 月比ほぼ2倍で増加を続けている。この他、各地のFTP ミラーサイトや、雑誌付録のCD-ROM等による再配布も 行われている。 　利用者との間でDeleGateに関する情報交換を行うた めに94年７月に開設し30名の参加者で開始したメーリ ングリストは、現在600組織からの1100名の参加者を 擁している。これまで３年半の間に6000通を越えるや りとりが行われ、現在も盛んな意見交換が行われてい る。その内容は公開後のDeleGateの成長記録そのもの であり、WWW を介して公開されている (http://wall.etl.go.jp/delegate/ml/)。 　DeleGateは95年11月にフリーソフトウェア大賞・イ ンターネット賞を受賞し、また筆者はDeleGateの開発 に関連して96年6月に工業技術院長表彰、97年4月に科 学技術長官賞を受賞した。 ５．むすび 偶然に産み出されたおもちゃのようなプログラムが、 次々と現れる問題を乗り越えながら成長を続け、利用 者からの支援に支えられながら、常に第一線で役に立 つ実用ソフトとして支持されて来たという、幸福なも の作りのストーリーを紹介した。 　技術的内容の薄い、身の上話になってしまったこと をお詫びしたい。ただ、このような幸福なソフト作り の世界が存在することを知っていただき、このような 仕事に興味を持つ方々にとって何かの参考になれば幸 いである。 参考文献 1)佐藤豊,大蒔和仁:分散オブジェクト指向UIMSの実行 時アーキテクチャの設計と実現,電総研彙報,58,10, pp.63-71 (1994) 2)佐藤豊:DeleGateに見るインターネット上の公共ソ フトウェアのの成長過程,機械振興,28,4,pp.96-101 (1995) 3)佐藤豊:多目的プロキシサーバDeleGateの機能詳細, インターフェース,21,9,pp.130-146 (1995) 4)佐藤豊:インターネット防火壁の基礎技術と応用, コンピュータソフトウェア,14,1,pp.55-63 (1997) 著者略歴 1987年,筑波大学大学院博士課程工学研究科(電子情報 工学専攻)修了,工学博士。同年,電子技術総合研究所 に入所。利用者インターフェイスの構成法、ネットワ ーク指向ソフトウェア構成法の研究に従事。1994年4 月より1年間,科学技術庁科学技術振興局科学技術情報 課出向。現在,同所情報アーキテクチャ部主任研究官。 ---- 　　　　　　　 　　　 @ @　　 ┬─┐─┬─┌ ／／＼^^ ( - ) ├─　　│　│ ／　876m＼ _< >_ ┴──　┴　┴──────────────────────────────┘ 佐藤豊＠情報アーキテクチャ部.電子技術総合研究所.工業技術院.通商産業省.日本