JP3709558B2 - ウェブサーバの公開方法、システムおよびプログラム - Google Patents
ウェブサーバの公開方法、システムおよびプログラム Download PDFInfo
- Publication number
- JP3709558B2 JP3709558B2 JP2001329774A JP2001329774A JP3709558B2 JP 3709558 B2 JP3709558 B2 JP 3709558B2 JP 2001329774 A JP2001329774 A JP 2001329774A JP 2001329774 A JP2001329774 A JP 2001329774A JP 3709558 B2 JP3709558 B2 JP 3709558B2
- Authority
- JP
- Japan
- Prior art keywords
- user
- address
- response
- request
- url
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Computer And Data Communications (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、ウェブサーバの公開方法、公開システムおよびプログラムに関する。特に、ユーザが固定ＩＰアドレス持たない自分のコンピュータ上でも安全かつ容易にウェブサーバを公開できる手法に適用して有効な技術に関する。
【０００２】
【従来の技術】
一般ユーザがインターネットにウェブサーバ（ウェブページ）を公開しようとする場合には、ホスティングサービス等を提供する事業者等からグローバルＩＰアドレスを取得し、インターネットに常時接続しているシステムあるいはホスティングサービス事業者のシステムに公開しようとするウェブサーバを導入する。しかし、グローバルＩＰアドレスの数は有限であり、その利用には一般に高い利用料が要求される。
【０００３】
よって、より一般的には、ＩＳＰ（インターネットサービスプロバイダ）等事業者のハードディスクに所定の領域（一般に数ＭＢ〜数十ＭＢの容量）を確保し、このハードディスク領域にウェブページをアップロードしてコンテンツを公開する手法を用いる。この場合、ＩＰアドレスは事業者のシステムに対して与えられるものであり、ドメイン名も事業者のドメイン名である。よって、ユーザに独自のドメイン名は与えられず、事業者のドメイン名とユーザ名に相当するディレクトリ名とでユーザページのＵＲＬ（uniform resource locator）が特定される。
【０００４】
一方、近年のインターネット接続環境の向上により、一般的なユーザでも常時接続が安価に利用できるようになっている。すなわち、ＡＤＳＬ（asymmetric digital subscriber line）等電話加入線を利用した高速データ通信技術により、インターネットへの常時接続が安価に実現されつつある。
【０００５】
このような状況下で、ＩＳＰのウェブ機能を用いてウェブページを公開しているユーザが常時接続環境を入手すれば、自己の所有するコンピュータシステムでウェブサーバを公開したいという要求が発生するであろう。ＩＳＰ等が提供するウェブ機能は、一般に容量が制限され、また、既定のＣＧＩ（common gateway interface）のみ利用でき、独自のＣＧＩの利用が制限される。さらにセキュリティ機能に制限を受ける場合がある。自己のコンピュータシステムでウェブサーバを公開すれば、これら制限を何ら受けることなく、自由にサーバを構成することが可能になる。
【０００６】
【発明が解決しようとする課題】
ところが、多くの一般ユーザのＩＳＰ等への接続は、ＤＨＣＰ（dynamic host configuration protocol）によるものであり、固定のＩＰアドレスを持たない。よってＤＮＳ（domain name system）による名前解決（ＩＰアドレスへの変換）ができない。なお、ＤＨＣＰ環境に対応できるＤＮＳとしてDynamicＤＮＳがあるが、ドメインを超えた名前解決はできない。
【０００７】
固定アドレスを持たない問題に対し、ＩＰｖ６の普及によって、ユーザごとの固定ＩＰアドレスが普及し解決が図られることも考え得る。しかし、ＩＰアドレスを公開することは、セキュリティ、プライバシーの点から問題が多い。よってＩＰアドレスを隠蔽できる手段が提供されることが望ましい。
【０００８】
また、ユーザがＩＳＰを変更することや、ユーザによる２４時間のウェブサーバの公開が困難な場合もある。このような場合にも対処可能なウェブ公開サービスを提供できる手段が望まれる。
【０００９】
本発明の目的は、動的にＩＰアドレスが変更されるウェブサーバを容易に公開する手段を提供することにある。また、本発明の目的は、ＩＰアドレスの遮蔽性を高め、安全にウェブサーバを公開する手段を提供することにある。また、本発明の目的は、常時公開に対応できないようなユーザのウェブサーバであっても一貫したウェブサービスの提供を可能にすることにある。
【００１０】
【課題を解決するための手段】
本願発明の概略を説明すれば、以下の通りである。すなわち、本発明のウェブサーバの公開方法は、ＩＰアドレスが動的に変更されるウェブサーバの公開方法であって、ウェブサーバを含むユーザシステムからＩＰアドレスの通知を受け取るステップと、ユーザシステムを利用するユーザに関連付けてＩＰアドレスをデータベースに記録するステップと、クライアントシステムが発した第１リクエストを受け取るステップと、第１リクエストに含まれる第１ＵＲＬから、ユーザを特定するステップと、ユーザのＩＰアドレスをデータベースから読み取るステップと、第１ＵＲＬを、ＩＰアドレスを含む第２ＵＲＬに変換するステップと、第２ＵＲＬを含む第２リクエストを発行するステップと、第２リクエストに応答する第１レスポンスを受け取るステップと、第１レスポンスのステータスに正常に処理された旨のコードまたはメッセージを含む場合には、第１レスポンスを、第１リクエストに応答する第２レスポンスとしてクライアントシステムに返送するステップと、を含む。このようなウェブサーバの公開方法によれば、ユーザシステムからＩＰアドレスの通知を受け、このＩＰアドレスを用いてクライアントからの第１リクエストを転送する。このため、ＩＰアドレスが動的に変更されても、一貫して同じユーザにリクエストを転送できる。
【００１１】
第１ＵＲＬを第２ＵＲＬに変換するステップにおいて、第１ＵＲＬのドメイン名およびユーザの特定部分を、ＩＰアドレスおよび予めユーザに関連付けて記録されたディレクトリ名に変換できる。予めユーザシステムの任意のディレクトリを登録しておくことにより、このディレクトリをインターネットからのリクエストに対するルートディレクトリとすることができる。
【００１２】
ユーザシステムから通知されたＩＰアドレスを記録する際に、通知がなされた時刻またはＩＰアドレスを記録した時刻を最終更新時刻としてユーザに関連付けてデータベースに記録するステップと、ＩＰアドレスをデータベースから読み取る際に、データベースから最終更新時刻を読み取るステップと、をさらに有し、現在時刻が、最終更新時刻から所定の経過時間内に無い場合には、ユーザに関連付けて記録されているエラーリンクにリルートさせるステップ、または、予め登録したユーザごとのエラーページを第２レスポンスとしてクライアントシステムに返送するステップ、の何れかのステップをさらに有することができる。最終更新時刻を記録しておくことにより、一定の期間にＩＰアドレスの更新が無い場合は、ユーザシステムが切断されたとみなしてエラー処理を行える。
【００１３】
第１レスポンスのステータスに「Not Found」その他正常に処理されなかった旨のコードまたはメッセージを含む場合には、ユーザに関連付けて記録されているエラーリンクにリルートさせるステップ、または、予め登録したユーザごとのエラーページを第２レスポンスとしてクライアントシステムに返送するステップ、の何れかのステップをさらに有することができる。ユーザシステムに対するリクエストが正常に処理されなかった場合にも、エラー処理を行える。
【００１４】
ＩＰアドレスの通知は、ユーザシステムにインストールされているエージェントプログラムから定期的に受け取ることができる。エージェントプログラムを利用することにより、ユーザシステムからのＩＰアドレス通知のタスクをエージェントに任せることができ、サービス側のサーバ負荷を軽減できる。
【００１５】
第２リクエストおよびそれに応答する第１レスポンスは、ページキャッシュ機能を持つプロキシサーバを介して通信できる。ページキャッシュを利用できるので、ユーザシステムへの通信回線の容量が少ない場合であっても、キャッシュされたページへのリクエストであればホスティングシステム側の通信回線で処理が完了するので、レスポンスを早めることができる。
【００１６】
また、本発明のウェブページの公開方法は、インターネットサービスプロバイダから動的なＩＰアドレスを取得するステップと、動的にＩＰアドレスが変更されるウェブサーバの公開サービスを提供するホスティングシステムに、取得したＩＰアドレスを通知するステップと、ホスティングシステムから、通知したＩＰアドレスを含むリクエストを受け取るステップと、リクエストに応答するレスポンスを返送するステップと、を含む。すなわちＩＰアドレスが動的に変更された場合、これをホスティングシステムに通知するので、ホスティングシステムが受け取ったリクエストを適正なＵＲＬに変換して転送される。このため、ＩＰアドレスが変更されてもウェブサーバは通常のウェブサービスと同じように公開される。一方、本発明では、ウェブサーバはユーザ自身のコンピュータシステムに構築されるので、一般のウェブサービスのように機能や容量が制限されない。つまり、本発明によれば、一般のウェブサービスと比して遜色なく、かつユーザに自由なサーバ構成を許容するサービスを提供できる。
【００１７】
なお、本発明は、前記した方法としての発明の他、システムあるいはプログラムとして把握することも可能である。また、本発明においてＨＴＴＰには、セキュリティ機能を付加したプロトコルであるＨＴＴＰＳも含むものとする。
【００１８】
【発明の実施の形態】
以下、本発明の実施の形態を図面に基づいて詳細に説明する。ただし、本発明は多くの異なる態様で実施することが可能であり、本実施の形態の記載内容に限定して解釈すべきではない。なお、実施の形態の全体を通して同じ要素には同じ番号を付するものとする。
【００１９】
以下の実施の形態では、主に方法またはシステムについて説明するが、当業者であれば明らかな通り、本発明はコンピュータで使用可能なプログラムとしても実施できる。したがって、本発明は、ハードウェアとしての実施形態、ソフトウェアとしての実施形態またはソフトウェアとハードウェアとの組合せの実施形態をとることができる。プログラムは、ハードディスク、ＣＤ−ＲＯＭ、光記憶装置または磁気記憶装置等の任意のコンピュータ可読媒体に記録できる。
【００２０】
本実施の形態では、一般的なコンピュータシステムが利用できる。一般的なコンピュータシステムには、中央演算処理装置（ＣＰＵ）、主記憶装置（メインメモリ：ＲＡＭ）、不揮発性記憶装置（ＲＯＭ）、コプロセッサ、画像アクセラレータ、キャッシュメモリ、入出力制御装置（Ｉ／Ｏ）等、一般的にコンピュータシステムに備えられるハードウェア資源を備える。また、ハードディスク装置等の外部記憶装置、インターネットに接続可能な通信手段を備える。コンピュータシステムには、パーソナルコンピュータ、ワークステーション、メインフレームコンピュータ等各種のコンピュータが含まれる。また、各コンピュータシステムには、現に広く利用されている各種オペレーティングシステムその他汎用的なアプリケーションソフトウェアを稼動させることができることは勿論である。
【００２１】
以下の実施の形態において、各システムに含まれるサーバやエージェントの機能は、コンピュータソフトウェアによって実現できる。コンピュータソフトウェアは、たとえばオブジェクト指向のクラスプログラムを組み合わせたコンポーネントによって実現できる。サーバその他プログラムによって実現される機能は単一のコンポーネントで実現されてもよく、複数のコンポーネントを組み合わせて実現しても良い。また、各機能のうち、複数の機能が単一のコンポーネントによって実現されても良い。
【００２２】
図１は、本発明の一実施の形態であるウェブサーバ公開システムの一例を示したブロック図である。本実施の形態のウェブサーバ公開システムは、主にホスティングシステム１で実現され、ユーザシステム２の一部の機能がウェブ公開システムに含まれる。また、本実施の形態のウェブ公開システムを利用するために、クライアントシステム３、ＩＳＰ（インターネットサービスプロバイダ）４が必要である。
【００２３】
ホスティングシステム１は、動的にＩＰアドレスが変更されるウェブサーバの公開サービスを提供する。すなわち、ウェブサーバを自己のコンピュータシステムであるユーザシステム２に導入し管理するユーザからの依頼を受け、後に説明するようにクライアントシステム３からユーザシステム２へのアクセスをホスティングシステム１経由で可能にする。
【００２４】
ホスティングシステム１には、ゲーティングサーバ５、プロキシサーバ６、レジストレーションサーバ７、データベース８を含む。ゲーティングサーバ５は、ホスティングシステム１への入り口となる特殊なサーバである。ゲーティングサーバ５は、クライアントシステム３のウェブブラウザ１２が発するＨＴＴＰリクエストを受け取り、後に詳細に説明するようにＵＲＬ変換を行ってリクエストを転送する。プロキシサーバ６は、通常のプロキシサーバが有するものと同様の機能を有し、特にユーザページのキャッシングを行う機能を有する。レジストレーションサーバ７は、エージェント１１からのＩＰアドレスの通知を受けて、受け取ったＩＰアドレスその他の情報をデータベース８に登録する機能を持つ。
【００２５】
データベース８には、ウェブサーバを公開するユーザごとのユーザ情報９が記録される。ユーザ情報９に記録されるデータとして、ユーザＩＤ、ＩＰアドレス、ＨＴＴＰルート、エラーリンク、最終更新時刻を例示できる。ユーザＩＤはユーザを特定する識別文字あるいは記号である。ただし本実施の形態では、ＵＲＬに変換できる文字列（ＵＲＬの表現に用いることが許容されている文字列）に限られる。ＩＰアドレスは、ユーザシステム２に付与されている現在のＩＰアドレスである。厳密には現在ＩＰアドレスではないが、エージェント１１から通知された最新のＩＰアドレスが記録されている。ＨＴＴＰルートは、ユーザが公開するウェブページの最上位ディレクトリである。すなわち、ユーザのウェブサイトにおけるインデックスページを与える相対ディレクトリである。ＨＴＴＰルートはウェブサーバのルートディレクトリとは相違する。エラーリンクは、ＨＴＴＰリクエストがエラー（正常にリクエストが処理されなかった場合）であった場合、ブラウザに通知するリンク先である。エラーリンクにはブラウザにリダイレクトさせることによってアクセスできる。エラーリンクはエラーの種類に応じて複数用意することができる。最終更新時刻は、エージェントが最後にＩＰアドレスを報告した時刻である。現在時刻が、最終更新時刻から所定の経過時間内にないとき、ユーザシステム２は切断されたものとみなす。すなわち、現在記録されているＩＰアドレスは有効なものではないとして処理を行う。
【００２６】
ユーザシステム２は、ユーザが公開するウェブサーバ（ＨＴＴＰサーバ１０）を導入しているコンピュータシステムであり、ユーザが管理する。ユーザシステム２はユーザ自身が管理するため、ほとんどの場合ユーザ自身がその運営内容を決定できる。たとえばサーバとアプリケーションソフトウェアとのインタフェイスであるＣＧＩを独自に作成でき、サーバと任意のアプリケーションソフトウェアとを連携させることができる。また、サーバの管理するウェブページの記録容量にも制限を受けない。さらにユーザが必要と認めるセキュリティ対策をほぼ制限無く施すことが可能である。
【００２７】
ユーザが公開するウェブサーバとしてＨＴＴＰサーバ１０を例示する。ＨＴＴＰサーバ１０は、ＨＴＴＰ（hypertext transfer protocol）に従ったリクエストを受けて、それに応答するサーバである。応答結果はＨＴＴＰに従ったレスポンスとしてリクエスト元に返送する。
【００２８】
ユーザシステム２にはエージェント１１を含む。エージェント１１は、ユーザシステム２がたとえばダイアルアップ接続によってＩＳＰ４に接続し、インターネットに接続した場合、ＤＨＣＰサーバ１３から割り当てられたＩＰアドレス（すなわち現在有効なＩＰアドレス）を取得し、レジストレーションサーバ７にこれを通知する。エージェント１１は、定期的に現在有効なＩＰアドレスを、レジストレーションサーバ７に通知するようにプログラムされる。従ってエージェント１１からの通知が一定期間ない場合にはユーザシステム２は切断されている状態であり、ホスティングシステム１では所定の経過時間内にＩＰアドレスの更新が無いことによってＩＰアドレスの有効あるいは無効を判断することができる。
【００２９】
クライアントシステム３は、ウェブサーバ（ＨＴＴＰサーバ１０）にアクセスしようとする一般ユーザ（クライアント）である。クライアントシステム３には、ウェブブラウザ１２を含む。ウェブブラウザ１２はインターネットエクスプローラ（マイクロソフト社の商標）、ネットスケープナビゲータ（ネットスケープ社の商標）等の一般的なブラウザである。
【００３０】
ＩＳＰ４は、一般ユーザがインターネットに接続するための接続サービスその他のサービスを提供するサービス事業者である。ユーザシステム２からＩＳＰ４に接続要求を発すると、所定の認証処理等を行った後、ＩＳＰ４はＤＨＣＰサーバ１３によってＩＰアドレスを発行する。このＩＰアドレスがユーザシステム２における現在有効なＩＰアドレスである。前記したとおりこのＩＰアドレスはエージェント１１によってホスティングシステム１（レジストレーションサーバ７）に通知される。別の機会にユーザがＩＳＰ４に接続した時には別のＩＰアドレスが付与されることは言うまでもない。
【００３１】
図２は、本発明の一実施の形態であるウェブサーバの公開方法の一例を示したフローチャートである。左側にユーザシステム２での処理、中央部にホスティングシステム１での処理、右側にクライアントシステム３での処理を示す。
【００３２】
ユーザがＩＳＰ４に接続すると、ユーザシステム２にはＤＨＣＰサーバ１３によってＩＰアドレスが付与される（ステップ２０）。このＩＰアドレスは動的なものであり、次回の接続時には異なるＩＰアドレスとなる。
【００３３】
ユーザシステム２にＩＰアドレスが付与されると、エージェント１１がＩＰアドレスを取得し、これをレジストレーションサーバ７に通知する（ステップ２１）。レジストレーションサーバ７は、エージェント１１からの通知を受け取ると、ユーザと関連付けて、つまりユーザＩＤとともにこのＩＰアドレスをデータベース８に記録する（ステップ２２）。また、その時の時刻（最終更新時刻）を記録する。
【００３４】
このエージェント１１によるＩＰアドレスの通知は定期的に行われ、レジストレーションサーバ７はエージェント１１からの通知を受ける度にデータベース８を更新する。これにより、エージェント１１が稼動できる環境にある限りレジストレーションサーバ７は現在のＩＰアドレスの通知を受けることになり、データベース８（ＩＰアドレス）が最新であることが保証される。ただし、エージェント１１の通知周期（経過時間）より長い時間にＩＰアドレスが更新されない時にはエージェント１１は稼働環境にない（ユーザシステム２がダウンしているあるいはユーザシステム２はインターネットから切断されている）と判断するべきである。このための判断に最終更新時刻を利用する。
【００３５】
なお、ステップ２０〜２２の処理は、以下に説明するステップ２３以降の処理とは独立並行に行われる。つまり、上記ステップ２０〜２２の処理は、ユーザごとの最新のＩＰアドレスをデータベース８に記録し、その有効性の判断に資するために最終更新時刻を記録する処理である。
【００３６】
ユーザシステム２のＨＴＴＰサーバ１０（ウェブサーバ）の公開は以下のように行われる。まず、クライアントシステム３のウェブブラウザ１２がリクエストを発する（ステップ２３）。このリクエストに含まれるＵＲＬは、ゲーティングサーバ５のドメイン名とユーザを特定する記号（ユーザＩＤ）をディレクトリ名として記述することによって表現される。たとえばゲーティングサーバ５のドメイン名を「www.gating.net」とし、ユーザＩＤを「user」とすると、ウェブブラウザ１２が発するＵＲＬは「http://www.gating.net/user/index.thml」のようになる。このようなＵＲＬはユーザに一意のものであり、ユーザシステム２の接続環境やＩＰアドレスによって変動することはない。よって、クライアントシステム３のウェブブラウザ１２では、お気に入りやショートカットにこのＵＲＬを登録できる。
【００３７】
ステップ２３で発したリクエストは、ＤＮＳで名前解決される結果、ゲーティングサーバ５に送信される。ゲーティングサーバ５はリクエストを受け取り、そのＵＲＬからユーザを特定する（ステップ２４）。前記例言えば、ＵＲＬ「http://www.gating.net/user/index.html」のうち、ゲーティングサーバ５の名前部分の後に続くディレクトリ名「user」がユーザＩＤとなる。
【００３８】
ゲーティングサーバ５はユーザ名（ユーザＩＤ）でデータベース８を検索し、そのユーザのＩＰアドレスを取得する（ステップ２５）。また、そのＩＰアドレスが更新された最終更新時刻を取得する。
【００３９】
現在時刻が、最終更新時刻から所定の経過時間内にあるか、つまりＩＰアドレスが有効なものとみなせるかを判断する（ステップ２６）。ここで、所定の経過時間は前記したエージェント１１が通知する周期（誤差範囲を含めて周期の最大値とすることが妥当である）とすることができる。ステップ２６の判断が真の場合（つまりＩＰアドレスは有効であるとみなせる場合）、ＵＲＬ変換を行う（ステップ２７）。ＵＲＬ変換は、元のＵＲＬのドメイン名を、読み取ったそのユーザのＩＰアドレスに置き換え、元のＵＲＬのユーザ特定部分（ユーザＩＤ）をそのユーザのＨＴＴＰルートに置き換えることにより行える。たとえば、読み取ったユーザの現在有効とみなせるＩＰアドレスが「123.45.67.89」であり、ユーザのＨＴＴＰルートが「test」である場合、前記例のＵＲＬ「http://www.gating.net/user/index.html」は、「http://123.45.67.89/test/index.html」のように変換される。ゲーティングサーバ５は、この変換したＵＲＬに新たなリクエストを発する（ステップ２８）。新たなリクエストに含まれるＵＲＬのＩＰアドレス「123.45.67.89」は、現在インターネット上でユーザシステム２を一意に表す有効なアドレスであるはずなので、リクエストはユーザシステム２に到達するはずである。
【００４０】
一方、ステップ２６の判断が偽の時（ＩＰアドレスは無効であると判断された場合）、ゲーティングサーバ５はエラーリンク処理またはエラーページの送信を行う（ステップ２９）。たとえば、ステップ２３で発せられたＨＴＴＰリクエストに対するレスポンスとして、エラーリンク（エラーページのＵＲＬ）をロケーション情報に含め、ステータスをリダイレクトするように設定したレスポンスを、クライアントシステム３に返送する。あるいは、予め記録したエラーページをステップ２３で発せられたＨＴＴＰリクエストに対するレスポンスとしてクライアントシステム３に返送する。このようにエラー処理を行うことにより、現在ユーザシステム２がメンテナンス中である旨の表示や、次回の公開時期等をアナウンスすることができる。クライアントシステム３は、エラー処理を含むレスポンスを受け取り、エラーページにリルート（リダイレクト）またはエラーページの表示を行う（ステップ３０）。
【００４１】
本実施の形態では、ステップ２８で発せられたリクエストは、プロキシサーバ６を通過する。プロキシサーバ６では、リクエストを受け取り、キャッシュ３２を検索して該当ページが存在すればこれをキャッシュから読み取ってレスポンスとする（ステップ３１）。このようにキャッシングを行えば、ユーザシステム２への通信容量が小さい場合でも、ホスティングシステム１の大容量な通信環境内で処理が終了するので、応答速度を早くできる。キャッシュに該当ページがなけば、ユーザシステム２のＨＴＴＰサーバ１０にリクエストを転送する（ステップ３１）。ユーザシステム２では、リクエストに対する所定の応答処理を行い、レスポンスを返す（ステップ３３）。
【００４２】
プロキシサーバ６は、ＨＴＴＰサーバ１０からのレスポンスあるいはキャッシュからのレスポンスを転送し（ステップ３１）、ゲーティングサーバ５がこれを受け取る。そして、ゲーティングサーバ５はこのレスポンスをクライアントシステム３に転送する（ステップ３４）。
【００４３】
なお、ＨＴＴＰサーバ１０からのレスポンスが正常に処理された旨のメッセージ（ステータスコードが２００番台）を含まない場合、リクエストは何らかのエラーを生じていると考えられる。この場合、ゲーティングサーバ５は、前記したステップ２９のエラー処理と同様なエラーリンクまたはエラーページの処理（ステップ３５）を行い、この処理結果をレスポンスとする（ステップ３４）。
【００４４】
ゲーティングサーバ５は、ステップ２３のリクエストに対するレスポンスとして、所定のファイル（コンテンツ）またはエラー処理内容をクライアントシステムのウェブブラウザ１２に返送する（ステップ３４）。ウェブブラウザ１２はレスポンスを受け取り、これを表示する。あるいはエラー処理を行う（ステップ３６）。
【００４５】
以上のようにして、ユーザシステム２で運営されるＨＴＴＰサーバ１０が、動的なＩＰアドレスを持つ場合であっても、一貫してインターネット上に公開できる。すなわち、ユーザシステム２のＩＰアドレスが変更されるものであっても、ユーザのサーバを表す同一のＵＲＬ（たとえば「http://www.gating.net/user/index.html」）が使用できる。
【００４６】
また、ユーザシステム２のＨＴＴＰサーバ１０が稼動していない場合であっても、別のページ（エラーページ）が表示できる。これにより、ユーザは２４時間サーバを稼動させる必要は無く、好きな期間、時間帯にサーバを公開できる。
【００４７】
また、本実施の形態によれば、ユーザシステム２のＩＰアドレスを隠蔽できる。クライアントは、ゲーティングサーバ５のドメイン名とユーザ名を知ることができるだけであり、ユーザシステム２のＩＰアドレスが直接知られるわけではない。このため、特定のユーザサーバへの攻撃を困難にすることができる。つまりサーバを外部攻撃から守り、安全に公開することが可能になる。
【００４８】
また、本実施の形態によれば、ページの記録容量、使用できるＣＧＩなどに制限がない。独自のセキュリティ対策を施すことも可能になる。
【００４９】
また、本実施の形態ではプロキシサーバ６によるページキャッシュを利用できるので、ユーザのインターネット接続回線が低速回線であってもウェブサーバを公開できる。
【００５０】
また、本実施の形態では、ＨＴＴＰサーバ１０がユーザシステム２で構築されているので、コンテンツの更新時に従来必要であったアップロードの必要がない。
【００５１】
また、本実施の形態では、ユーザはドメイン名を取得する必要が無く、これを管理する必要もない。しかも、ユーザのサーバを特定するＵＲＬはユーザに一意であり、ブックマーク（お気に入り）等のブラウザ機能を利用できる。
【００５２】
また、ＨＴＴＰサーバ１０へのアクセスにパスワード認証等のセキュリティ機能を付加することはユーザの任意である。よって、プロバイダに対してコンテンツを秘匿でき、プロバイダのハードディスクにアップロードする従来の方式の場合には困難であった情報の秘匿を図ることも容易になる。
【００５３】
以上、本発明者によってなされた発明を発明の実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更することが可能である。
【００５４】
たとえば、前記実施の形態では、プロキシサーバ６を利用する例を説明した。しかし、プロキシサーバ６は必須の要件ではない。
【００５５】
また、公開するＵＲＬにユーザ名（ユーザＩＤ）を含める方法は一例であり、ユーザに関連付けられるその他の識別子を用いることもできる。
【００５６】
また、前記実施の形態ではエラー処理によるエラーページの表示を行う例を示したが、エラー処理は無くても良い。この場合、クライアントにはエラーである旨のステータスコード（ステータス行）を含むレスポンスが返送されることになる。
【００５７】
また、前記実施の形態では、リクエストあるいはレスポンスのスキームとしてＨＴＴＰを例示したが、これに限られない。ｆｔｐ（file transfer protocol）その他のスキームであっても同様に本発明を適用できる。
【００５８】
【発明の効果】
本願で開示される発明のうち、代表的なものによって得られる効果は、以下の通りである。すなわち、動的にＩＰアドレスが変更されるウェブサーバを容易に公開することができる。また、ＩＰアドレスの遮蔽性を高め、安全にウェブサーバを公開することができる。また、常時公開に対応できないようなユーザのウェブサーバであっても一貫したウェブサービスの提供を可能にできる。
【図面の簡単な説明】
【図１】本発明の一実施の形態であるウェブサーバ公開システムの一例を示したブロック図である。
【図２】本発明の一実施の形態であるウェブサーバの公開方法の一例を示したフローチャートである。
【符号の説明】
１…ホスティングシステム、２…ユーザシステム、３…クライアントシステム、４…ＩＳＰ（インターネットサービスプロバイダ）、５…ゲーティングサーバ、６…プロキシサーバ、７…レジストレーションサーバ、８…データベース、９…ユーザ情報、１０…ＨＴＴＰサーバ、１１…エージェント、１２…ウェブブラウザ、１３…ＤＨＣＰサーバ。
【発明の属する技術分野】
本発明は、ウェブサーバの公開方法、公開システムおよびプログラムに関する。特に、ユーザが固定ＩＰアドレス持たない自分のコンピュータ上でも安全かつ容易にウェブサーバを公開できる手法に適用して有効な技術に関する。
【０００２】
【従来の技術】
一般ユーザがインターネットにウェブサーバ（ウェブページ）を公開しようとする場合には、ホスティングサービス等を提供する事業者等からグローバルＩＰアドレスを取得し、インターネットに常時接続しているシステムあるいはホスティングサービス事業者のシステムに公開しようとするウェブサーバを導入する。しかし、グローバルＩＰアドレスの数は有限であり、その利用には一般に高い利用料が要求される。
【０００３】
よって、より一般的には、ＩＳＰ（インターネットサービスプロバイダ）等事業者のハードディスクに所定の領域（一般に数ＭＢ〜数十ＭＢの容量）を確保し、このハードディスク領域にウェブページをアップロードしてコンテンツを公開する手法を用いる。この場合、ＩＰアドレスは事業者のシステムに対して与えられるものであり、ドメイン名も事業者のドメイン名である。よって、ユーザに独自のドメイン名は与えられず、事業者のドメイン名とユーザ名に相当するディレクトリ名とでユーザページのＵＲＬ（uniform resource locator）が特定される。
【０００４】
一方、近年のインターネット接続環境の向上により、一般的なユーザでも常時接続が安価に利用できるようになっている。すなわち、ＡＤＳＬ（asymmetric digital subscriber line）等電話加入線を利用した高速データ通信技術により、インターネットへの常時接続が安価に実現されつつある。
【０００５】
このような状況下で、ＩＳＰのウェブ機能を用いてウェブページを公開しているユーザが常時接続環境を入手すれば、自己の所有するコンピュータシステムでウェブサーバを公開したいという要求が発生するであろう。ＩＳＰ等が提供するウェブ機能は、一般に容量が制限され、また、既定のＣＧＩ（common gateway interface）のみ利用でき、独自のＣＧＩの利用が制限される。さらにセキュリティ機能に制限を受ける場合がある。自己のコンピュータシステムでウェブサーバを公開すれば、これら制限を何ら受けることなく、自由にサーバを構成することが可能になる。
【０００６】
【発明が解決しようとする課題】
ところが、多くの一般ユーザのＩＳＰ等への接続は、ＤＨＣＰ（dynamic host configuration protocol）によるものであり、固定のＩＰアドレスを持たない。よってＤＮＳ（domain name system）による名前解決（ＩＰアドレスへの変換）ができない。なお、ＤＨＣＰ環境に対応できるＤＮＳとしてDynamicＤＮＳがあるが、ドメインを超えた名前解決はできない。
【０００７】
固定アドレスを持たない問題に対し、ＩＰｖ６の普及によって、ユーザごとの固定ＩＰアドレスが普及し解決が図られることも考え得る。しかし、ＩＰアドレスを公開することは、セキュリティ、プライバシーの点から問題が多い。よってＩＰアドレスを隠蔽できる手段が提供されることが望ましい。
【０００８】
また、ユーザがＩＳＰを変更することや、ユーザによる２４時間のウェブサーバの公開が困難な場合もある。このような場合にも対処可能なウェブ公開サービスを提供できる手段が望まれる。
【０００９】
本発明の目的は、動的にＩＰアドレスが変更されるウェブサーバを容易に公開する手段を提供することにある。また、本発明の目的は、ＩＰアドレスの遮蔽性を高め、安全にウェブサーバを公開する手段を提供することにある。また、本発明の目的は、常時公開に対応できないようなユーザのウェブサーバであっても一貫したウェブサービスの提供を可能にすることにある。
【００１０】
【課題を解決するための手段】
本願発明の概略を説明すれば、以下の通りである。すなわち、本発明のウェブサーバの公開方法は、ＩＰアドレスが動的に変更されるウェブサーバの公開方法であって、ウェブサーバを含むユーザシステムからＩＰアドレスの通知を受け取るステップと、ユーザシステムを利用するユーザに関連付けてＩＰアドレスをデータベースに記録するステップと、クライアントシステムが発した第１リクエストを受け取るステップと、第１リクエストに含まれる第１ＵＲＬから、ユーザを特定するステップと、ユーザのＩＰアドレスをデータベースから読み取るステップと、第１ＵＲＬを、ＩＰアドレスを含む第２ＵＲＬに変換するステップと、第２ＵＲＬを含む第２リクエストを発行するステップと、第２リクエストに応答する第１レスポンスを受け取るステップと、第１レスポンスのステータスに正常に処理された旨のコードまたはメッセージを含む場合には、第１レスポンスを、第１リクエストに応答する第２レスポンスとしてクライアントシステムに返送するステップと、を含む。このようなウェブサーバの公開方法によれば、ユーザシステムからＩＰアドレスの通知を受け、このＩＰアドレスを用いてクライアントからの第１リクエストを転送する。このため、ＩＰアドレスが動的に変更されても、一貫して同じユーザにリクエストを転送できる。
【００１１】
第１ＵＲＬを第２ＵＲＬに変換するステップにおいて、第１ＵＲＬのドメイン名およびユーザの特定部分を、ＩＰアドレスおよび予めユーザに関連付けて記録されたディレクトリ名に変換できる。予めユーザシステムの任意のディレクトリを登録しておくことにより、このディレクトリをインターネットからのリクエストに対するルートディレクトリとすることができる。
【００１２】
ユーザシステムから通知されたＩＰアドレスを記録する際に、通知がなされた時刻またはＩＰアドレスを記録した時刻を最終更新時刻としてユーザに関連付けてデータベースに記録するステップと、ＩＰアドレスをデータベースから読み取る際に、データベースから最終更新時刻を読み取るステップと、をさらに有し、現在時刻が、最終更新時刻から所定の経過時間内に無い場合には、ユーザに関連付けて記録されているエラーリンクにリルートさせるステップ、または、予め登録したユーザごとのエラーページを第２レスポンスとしてクライアントシステムに返送するステップ、の何れかのステップをさらに有することができる。最終更新時刻を記録しておくことにより、一定の期間にＩＰアドレスの更新が無い場合は、ユーザシステムが切断されたとみなしてエラー処理を行える。
【００１３】
第１レスポンスのステータスに「Not Found」その他正常に処理されなかった旨のコードまたはメッセージを含む場合には、ユーザに関連付けて記録されているエラーリンクにリルートさせるステップ、または、予め登録したユーザごとのエラーページを第２レスポンスとしてクライアントシステムに返送するステップ、の何れかのステップをさらに有することができる。ユーザシステムに対するリクエストが正常に処理されなかった場合にも、エラー処理を行える。
【００１４】
ＩＰアドレスの通知は、ユーザシステムにインストールされているエージェントプログラムから定期的に受け取ることができる。エージェントプログラムを利用することにより、ユーザシステムからのＩＰアドレス通知のタスクをエージェントに任せることができ、サービス側のサーバ負荷を軽減できる。
【００１５】
第２リクエストおよびそれに応答する第１レスポンスは、ページキャッシュ機能を持つプロキシサーバを介して通信できる。ページキャッシュを利用できるので、ユーザシステムへの通信回線の容量が少ない場合であっても、キャッシュされたページへのリクエストであればホスティングシステム側の通信回線で処理が完了するので、レスポンスを早めることができる。
【００１６】
また、本発明のウェブページの公開方法は、インターネットサービスプロバイダから動的なＩＰアドレスを取得するステップと、動的にＩＰアドレスが変更されるウェブサーバの公開サービスを提供するホスティングシステムに、取得したＩＰアドレスを通知するステップと、ホスティングシステムから、通知したＩＰアドレスを含むリクエストを受け取るステップと、リクエストに応答するレスポンスを返送するステップと、を含む。すなわちＩＰアドレスが動的に変更された場合、これをホスティングシステムに通知するので、ホスティングシステムが受け取ったリクエストを適正なＵＲＬに変換して転送される。このため、ＩＰアドレスが変更されてもウェブサーバは通常のウェブサービスと同じように公開される。一方、本発明では、ウェブサーバはユーザ自身のコンピュータシステムに構築されるので、一般のウェブサービスのように機能や容量が制限されない。つまり、本発明によれば、一般のウェブサービスと比して遜色なく、かつユーザに自由なサーバ構成を許容するサービスを提供できる。
【００１７】
なお、本発明は、前記した方法としての発明の他、システムあるいはプログラムとして把握することも可能である。また、本発明においてＨＴＴＰには、セキュリティ機能を付加したプロトコルであるＨＴＴＰＳも含むものとする。
【００１８】
【発明の実施の形態】
以下、本発明の実施の形態を図面に基づいて詳細に説明する。ただし、本発明は多くの異なる態様で実施することが可能であり、本実施の形態の記載内容に限定して解釈すべきではない。なお、実施の形態の全体を通して同じ要素には同じ番号を付するものとする。
【００１９】
以下の実施の形態では、主に方法またはシステムについて説明するが、当業者であれば明らかな通り、本発明はコンピュータで使用可能なプログラムとしても実施できる。したがって、本発明は、ハードウェアとしての実施形態、ソフトウェアとしての実施形態またはソフトウェアとハードウェアとの組合せの実施形態をとることができる。プログラムは、ハードディスク、ＣＤ−ＲＯＭ、光記憶装置または磁気記憶装置等の任意のコンピュータ可読媒体に記録できる。
【００２０】
本実施の形態では、一般的なコンピュータシステムが利用できる。一般的なコンピュータシステムには、中央演算処理装置（ＣＰＵ）、主記憶装置（メインメモリ：ＲＡＭ）、不揮発性記憶装置（ＲＯＭ）、コプロセッサ、画像アクセラレータ、キャッシュメモリ、入出力制御装置（Ｉ／Ｏ）等、一般的にコンピュータシステムに備えられるハードウェア資源を備える。また、ハードディスク装置等の外部記憶装置、インターネットに接続可能な通信手段を備える。コンピュータシステムには、パーソナルコンピュータ、ワークステーション、メインフレームコンピュータ等各種のコンピュータが含まれる。また、各コンピュータシステムには、現に広く利用されている各種オペレーティングシステムその他汎用的なアプリケーションソフトウェアを稼動させることができることは勿論である。
【００２１】
以下の実施の形態において、各システムに含まれるサーバやエージェントの機能は、コンピュータソフトウェアによって実現できる。コンピュータソフトウェアは、たとえばオブジェクト指向のクラスプログラムを組み合わせたコンポーネントによって実現できる。サーバその他プログラムによって実現される機能は単一のコンポーネントで実現されてもよく、複数のコンポーネントを組み合わせて実現しても良い。また、各機能のうち、複数の機能が単一のコンポーネントによって実現されても良い。
【００２２】
図１は、本発明の一実施の形態であるウェブサーバ公開システムの一例を示したブロック図である。本実施の形態のウェブサーバ公開システムは、主にホスティングシステム１で実現され、ユーザシステム２の一部の機能がウェブ公開システムに含まれる。また、本実施の形態のウェブ公開システムを利用するために、クライアントシステム３、ＩＳＰ（インターネットサービスプロバイダ）４が必要である。
【００２３】
ホスティングシステム１は、動的にＩＰアドレスが変更されるウェブサーバの公開サービスを提供する。すなわち、ウェブサーバを自己のコンピュータシステムであるユーザシステム２に導入し管理するユーザからの依頼を受け、後に説明するようにクライアントシステム３からユーザシステム２へのアクセスをホスティングシステム１経由で可能にする。
【００２４】
ホスティングシステム１には、ゲーティングサーバ５、プロキシサーバ６、レジストレーションサーバ７、データベース８を含む。ゲーティングサーバ５は、ホスティングシステム１への入り口となる特殊なサーバである。ゲーティングサーバ５は、クライアントシステム３のウェブブラウザ１２が発するＨＴＴＰリクエストを受け取り、後に詳細に説明するようにＵＲＬ変換を行ってリクエストを転送する。プロキシサーバ６は、通常のプロキシサーバが有するものと同様の機能を有し、特にユーザページのキャッシングを行う機能を有する。レジストレーションサーバ７は、エージェント１１からのＩＰアドレスの通知を受けて、受け取ったＩＰアドレスその他の情報をデータベース８に登録する機能を持つ。
【００２５】
データベース８には、ウェブサーバを公開するユーザごとのユーザ情報９が記録される。ユーザ情報９に記録されるデータとして、ユーザＩＤ、ＩＰアドレス、ＨＴＴＰルート、エラーリンク、最終更新時刻を例示できる。ユーザＩＤはユーザを特定する識別文字あるいは記号である。ただし本実施の形態では、ＵＲＬに変換できる文字列（ＵＲＬの表現に用いることが許容されている文字列）に限られる。ＩＰアドレスは、ユーザシステム２に付与されている現在のＩＰアドレスである。厳密には現在ＩＰアドレスではないが、エージェント１１から通知された最新のＩＰアドレスが記録されている。ＨＴＴＰルートは、ユーザが公開するウェブページの最上位ディレクトリである。すなわち、ユーザのウェブサイトにおけるインデックスページを与える相対ディレクトリである。ＨＴＴＰルートはウェブサーバのルートディレクトリとは相違する。エラーリンクは、ＨＴＴＰリクエストがエラー（正常にリクエストが処理されなかった場合）であった場合、ブラウザに通知するリンク先である。エラーリンクにはブラウザにリダイレクトさせることによってアクセスできる。エラーリンクはエラーの種類に応じて複数用意することができる。最終更新時刻は、エージェントが最後にＩＰアドレスを報告した時刻である。現在時刻が、最終更新時刻から所定の経過時間内にないとき、ユーザシステム２は切断されたものとみなす。すなわち、現在記録されているＩＰアドレスは有効なものではないとして処理を行う。
【００２６】
ユーザシステム２は、ユーザが公開するウェブサーバ（ＨＴＴＰサーバ１０）を導入しているコンピュータシステムであり、ユーザが管理する。ユーザシステム２はユーザ自身が管理するため、ほとんどの場合ユーザ自身がその運営内容を決定できる。たとえばサーバとアプリケーションソフトウェアとのインタフェイスであるＣＧＩを独自に作成でき、サーバと任意のアプリケーションソフトウェアとを連携させることができる。また、サーバの管理するウェブページの記録容量にも制限を受けない。さらにユーザが必要と認めるセキュリティ対策をほぼ制限無く施すことが可能である。
【００２７】
ユーザが公開するウェブサーバとしてＨＴＴＰサーバ１０を例示する。ＨＴＴＰサーバ１０は、ＨＴＴＰ（hypertext transfer protocol）に従ったリクエストを受けて、それに応答するサーバである。応答結果はＨＴＴＰに従ったレスポンスとしてリクエスト元に返送する。
【００２８】
ユーザシステム２にはエージェント１１を含む。エージェント１１は、ユーザシステム２がたとえばダイアルアップ接続によってＩＳＰ４に接続し、インターネットに接続した場合、ＤＨＣＰサーバ１３から割り当てられたＩＰアドレス（すなわち現在有効なＩＰアドレス）を取得し、レジストレーションサーバ７にこれを通知する。エージェント１１は、定期的に現在有効なＩＰアドレスを、レジストレーションサーバ７に通知するようにプログラムされる。従ってエージェント１１からの通知が一定期間ない場合にはユーザシステム２は切断されている状態であり、ホスティングシステム１では所定の経過時間内にＩＰアドレスの更新が無いことによってＩＰアドレスの有効あるいは無効を判断することができる。
【００２９】
クライアントシステム３は、ウェブサーバ（ＨＴＴＰサーバ１０）にアクセスしようとする一般ユーザ（クライアント）である。クライアントシステム３には、ウェブブラウザ１２を含む。ウェブブラウザ１２はインターネットエクスプローラ（マイクロソフト社の商標）、ネットスケープナビゲータ（ネットスケープ社の商標）等の一般的なブラウザである。
【００３０】
ＩＳＰ４は、一般ユーザがインターネットに接続するための接続サービスその他のサービスを提供するサービス事業者である。ユーザシステム２からＩＳＰ４に接続要求を発すると、所定の認証処理等を行った後、ＩＳＰ４はＤＨＣＰサーバ１３によってＩＰアドレスを発行する。このＩＰアドレスがユーザシステム２における現在有効なＩＰアドレスである。前記したとおりこのＩＰアドレスはエージェント１１によってホスティングシステム１（レジストレーションサーバ７）に通知される。別の機会にユーザがＩＳＰ４に接続した時には別のＩＰアドレスが付与されることは言うまでもない。
【００３１】
図２は、本発明の一実施の形態であるウェブサーバの公開方法の一例を示したフローチャートである。左側にユーザシステム２での処理、中央部にホスティングシステム１での処理、右側にクライアントシステム３での処理を示す。
【００３２】
ユーザがＩＳＰ４に接続すると、ユーザシステム２にはＤＨＣＰサーバ１３によってＩＰアドレスが付与される（ステップ２０）。このＩＰアドレスは動的なものであり、次回の接続時には異なるＩＰアドレスとなる。
【００３３】
ユーザシステム２にＩＰアドレスが付与されると、エージェント１１がＩＰアドレスを取得し、これをレジストレーションサーバ７に通知する（ステップ２１）。レジストレーションサーバ７は、エージェント１１からの通知を受け取ると、ユーザと関連付けて、つまりユーザＩＤとともにこのＩＰアドレスをデータベース８に記録する（ステップ２２）。また、その時の時刻（最終更新時刻）を記録する。
【００３４】
このエージェント１１によるＩＰアドレスの通知は定期的に行われ、レジストレーションサーバ７はエージェント１１からの通知を受ける度にデータベース８を更新する。これにより、エージェント１１が稼動できる環境にある限りレジストレーションサーバ７は現在のＩＰアドレスの通知を受けることになり、データベース８（ＩＰアドレス）が最新であることが保証される。ただし、エージェント１１の通知周期（経過時間）より長い時間にＩＰアドレスが更新されない時にはエージェント１１は稼働環境にない（ユーザシステム２がダウンしているあるいはユーザシステム２はインターネットから切断されている）と判断するべきである。このための判断に最終更新時刻を利用する。
【００３５】
なお、ステップ２０〜２２の処理は、以下に説明するステップ２３以降の処理とは独立並行に行われる。つまり、上記ステップ２０〜２２の処理は、ユーザごとの最新のＩＰアドレスをデータベース８に記録し、その有効性の判断に資するために最終更新時刻を記録する処理である。
【００３６】
ユーザシステム２のＨＴＴＰサーバ１０（ウェブサーバ）の公開は以下のように行われる。まず、クライアントシステム３のウェブブラウザ１２がリクエストを発する（ステップ２３）。このリクエストに含まれるＵＲＬは、ゲーティングサーバ５のドメイン名とユーザを特定する記号（ユーザＩＤ）をディレクトリ名として記述することによって表現される。たとえばゲーティングサーバ５のドメイン名を「www.gating.net」とし、ユーザＩＤを「user」とすると、ウェブブラウザ１２が発するＵＲＬは「http://www.gating.net/user/index.thml」のようになる。このようなＵＲＬはユーザに一意のものであり、ユーザシステム２の接続環境やＩＰアドレスによって変動することはない。よって、クライアントシステム３のウェブブラウザ１２では、お気に入りやショートカットにこのＵＲＬを登録できる。
【００３７】
ステップ２３で発したリクエストは、ＤＮＳで名前解決される結果、ゲーティングサーバ５に送信される。ゲーティングサーバ５はリクエストを受け取り、そのＵＲＬからユーザを特定する（ステップ２４）。前記例言えば、ＵＲＬ「http://www.gating.net/user/index.html」のうち、ゲーティングサーバ５の名前部分の後に続くディレクトリ名「user」がユーザＩＤとなる。
【００３８】
ゲーティングサーバ５はユーザ名（ユーザＩＤ）でデータベース８を検索し、そのユーザのＩＰアドレスを取得する（ステップ２５）。また、そのＩＰアドレスが更新された最終更新時刻を取得する。
【００３９】
現在時刻が、最終更新時刻から所定の経過時間内にあるか、つまりＩＰアドレスが有効なものとみなせるかを判断する（ステップ２６）。ここで、所定の経過時間は前記したエージェント１１が通知する周期（誤差範囲を含めて周期の最大値とすることが妥当である）とすることができる。ステップ２６の判断が真の場合（つまりＩＰアドレスは有効であるとみなせる場合）、ＵＲＬ変換を行う（ステップ２７）。ＵＲＬ変換は、元のＵＲＬのドメイン名を、読み取ったそのユーザのＩＰアドレスに置き換え、元のＵＲＬのユーザ特定部分（ユーザＩＤ）をそのユーザのＨＴＴＰルートに置き換えることにより行える。たとえば、読み取ったユーザの現在有効とみなせるＩＰアドレスが「123.45.67.89」であり、ユーザのＨＴＴＰルートが「test」である場合、前記例のＵＲＬ「http://www.gating.net/user/index.html」は、「http://123.45.67.89/test/index.html」のように変換される。ゲーティングサーバ５は、この変換したＵＲＬに新たなリクエストを発する（ステップ２８）。新たなリクエストに含まれるＵＲＬのＩＰアドレス「123.45.67.89」は、現在インターネット上でユーザシステム２を一意に表す有効なアドレスであるはずなので、リクエストはユーザシステム２に到達するはずである。
【００４０】
一方、ステップ２６の判断が偽の時（ＩＰアドレスは無効であると判断された場合）、ゲーティングサーバ５はエラーリンク処理またはエラーページの送信を行う（ステップ２９）。たとえば、ステップ２３で発せられたＨＴＴＰリクエストに対するレスポンスとして、エラーリンク（エラーページのＵＲＬ）をロケーション情報に含め、ステータスをリダイレクトするように設定したレスポンスを、クライアントシステム３に返送する。あるいは、予め記録したエラーページをステップ２３で発せられたＨＴＴＰリクエストに対するレスポンスとしてクライアントシステム３に返送する。このようにエラー処理を行うことにより、現在ユーザシステム２がメンテナンス中である旨の表示や、次回の公開時期等をアナウンスすることができる。クライアントシステム３は、エラー処理を含むレスポンスを受け取り、エラーページにリルート（リダイレクト）またはエラーページの表示を行う（ステップ３０）。
【００４１】
本実施の形態では、ステップ２８で発せられたリクエストは、プロキシサーバ６を通過する。プロキシサーバ６では、リクエストを受け取り、キャッシュ３２を検索して該当ページが存在すればこれをキャッシュから読み取ってレスポンスとする（ステップ３１）。このようにキャッシングを行えば、ユーザシステム２への通信容量が小さい場合でも、ホスティングシステム１の大容量な通信環境内で処理が終了するので、応答速度を早くできる。キャッシュに該当ページがなけば、ユーザシステム２のＨＴＴＰサーバ１０にリクエストを転送する（ステップ３１）。ユーザシステム２では、リクエストに対する所定の応答処理を行い、レスポンスを返す（ステップ３３）。
【００４２】
プロキシサーバ６は、ＨＴＴＰサーバ１０からのレスポンスあるいはキャッシュからのレスポンスを転送し（ステップ３１）、ゲーティングサーバ５がこれを受け取る。そして、ゲーティングサーバ５はこのレスポンスをクライアントシステム３に転送する（ステップ３４）。
【００４３】
なお、ＨＴＴＰサーバ１０からのレスポンスが正常に処理された旨のメッセージ（ステータスコードが２００番台）を含まない場合、リクエストは何らかのエラーを生じていると考えられる。この場合、ゲーティングサーバ５は、前記したステップ２９のエラー処理と同様なエラーリンクまたはエラーページの処理（ステップ３５）を行い、この処理結果をレスポンスとする（ステップ３４）。
【００４４】
ゲーティングサーバ５は、ステップ２３のリクエストに対するレスポンスとして、所定のファイル（コンテンツ）またはエラー処理内容をクライアントシステムのウェブブラウザ１２に返送する（ステップ３４）。ウェブブラウザ１２はレスポンスを受け取り、これを表示する。あるいはエラー処理を行う（ステップ３６）。
【００４５】
以上のようにして、ユーザシステム２で運営されるＨＴＴＰサーバ１０が、動的なＩＰアドレスを持つ場合であっても、一貫してインターネット上に公開できる。すなわち、ユーザシステム２のＩＰアドレスが変更されるものであっても、ユーザのサーバを表す同一のＵＲＬ（たとえば「http://www.gating.net/user/index.html」）が使用できる。
【００４６】
また、ユーザシステム２のＨＴＴＰサーバ１０が稼動していない場合であっても、別のページ（エラーページ）が表示できる。これにより、ユーザは２４時間サーバを稼動させる必要は無く、好きな期間、時間帯にサーバを公開できる。
【００４７】
また、本実施の形態によれば、ユーザシステム２のＩＰアドレスを隠蔽できる。クライアントは、ゲーティングサーバ５のドメイン名とユーザ名を知ることができるだけであり、ユーザシステム２のＩＰアドレスが直接知られるわけではない。このため、特定のユーザサーバへの攻撃を困難にすることができる。つまりサーバを外部攻撃から守り、安全に公開することが可能になる。
【００４８】
また、本実施の形態によれば、ページの記録容量、使用できるＣＧＩなどに制限がない。独自のセキュリティ対策を施すことも可能になる。
【００４９】
また、本実施の形態ではプロキシサーバ６によるページキャッシュを利用できるので、ユーザのインターネット接続回線が低速回線であってもウェブサーバを公開できる。
【００５０】
また、本実施の形態では、ＨＴＴＰサーバ１０がユーザシステム２で構築されているので、コンテンツの更新時に従来必要であったアップロードの必要がない。
【００５１】
また、本実施の形態では、ユーザはドメイン名を取得する必要が無く、これを管理する必要もない。しかも、ユーザのサーバを特定するＵＲＬはユーザに一意であり、ブックマーク（お気に入り）等のブラウザ機能を利用できる。
【００５２】
また、ＨＴＴＰサーバ１０へのアクセスにパスワード認証等のセキュリティ機能を付加することはユーザの任意である。よって、プロバイダに対してコンテンツを秘匿でき、プロバイダのハードディスクにアップロードする従来の方式の場合には困難であった情報の秘匿を図ることも容易になる。
【００５３】
以上、本発明者によってなされた発明を発明の実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更することが可能である。
【００５４】
たとえば、前記実施の形態では、プロキシサーバ６を利用する例を説明した。しかし、プロキシサーバ６は必須の要件ではない。
【００５５】
また、公開するＵＲＬにユーザ名（ユーザＩＤ）を含める方法は一例であり、ユーザに関連付けられるその他の識別子を用いることもできる。
【００５６】
また、前記実施の形態ではエラー処理によるエラーページの表示を行う例を示したが、エラー処理は無くても良い。この場合、クライアントにはエラーである旨のステータスコード（ステータス行）を含むレスポンスが返送されることになる。
【００５７】
また、前記実施の形態では、リクエストあるいはレスポンスのスキームとしてＨＴＴＰを例示したが、これに限られない。ｆｔｐ（file transfer protocol）その他のスキームであっても同様に本発明を適用できる。
【００５８】
【発明の効果】
本願で開示される発明のうち、代表的なものによって得られる効果は、以下の通りである。すなわち、動的にＩＰアドレスが変更されるウェブサーバを容易に公開することができる。また、ＩＰアドレスの遮蔽性を高め、安全にウェブサーバを公開することができる。また、常時公開に対応できないようなユーザのウェブサーバであっても一貫したウェブサービスの提供を可能にできる。
【図面の簡単な説明】
【図１】本発明の一実施の形態であるウェブサーバ公開システムの一例を示したブロック図である。
【図２】本発明の一実施の形態であるウェブサーバの公開方法の一例を示したフローチャートである。
【符号の説明】
１…ホスティングシステム、２…ユーザシステム、３…クライアントシステム、４…ＩＳＰ（インターネットサービスプロバイダ）、５…ゲーティングサーバ、６…プロキシサーバ、７…レジストレーションサーバ、８…データベース、９…ユーザ情報、１０…ＨＴＴＰサーバ、１１…エージェント、１２…ウェブブラウザ、１３…ＤＨＣＰサーバ。
Claims (11)
- ＩＰアドレスが動的に変更されるウェブサーバを公開するシステムにおけるウェブサーバの公開方法であって、
前記ウェブサーバを含むユーザシステムからＩＰアドレスの通知を受け取るステップと、
前記ユーザシステムを利用するユーザに関連付けて前記ＩＰアドレスをデータベースに記録するステップと、
クライアントシステムが発した第１リクエストを受け取るステップと、
前記第１リクエストに含まれ、前記システムのドメイン名および前記ユーザのユーザＩＤを含む第１ＵＲＬから、前記ユーザを特定するステップと、
前記ユーザのＩＰアドレスおよび予め記憶した前記ユーザ毎のディレクトリ名を前記データベースから読み取るステップと、
前記第１ＵＲＬを、前記ＩＰアドレスおよび前記ディレクトリ名を含む第２ＵＲＬに変換するステップと、
前記第２ＵＲＬを含む第２リクエストを発行するステップと、
前記第２リクエストに応答する第１レスポンスを受け取るステップと、
前記第１レスポンスのステータスに正常に処理された旨のコードまたはメッセージを含む場合には、前記第１レスポンスを、前記第１リクエストに応答する第２レスポンスとして前記クライアントシステムに返送するステップと、
を含むウェブサーバの公開方法。 - 前記ユーザシステムから通知された前記ＩＰアドレスを記録する際に、前記通知がなされた時刻または前記ＩＰアドレスを記録した時刻を最終更新時刻として前記ユーザに関連付けて前記データベースに記録するステップと、
前記ＩＰアドレスを前記データベースから読み取る際に、前記データベースから前記最終更新時刻を読み取るステップと、をさらに有し、
現在時刻が、前記最終更新時刻から所定の経過時間内に無い場合には、前記ユーザに関連付けて記録されているエラーリンクにリルートさせるステップ、または、予め登録した前記ユーザごとのエラーページを前記第２レスポンスとして前記クライアントシステムに返送するステップ、の何れかのステップをさらに有する請求項１記載の方法。 - 前記第１レスポンスのステータスに、正常に処理されなかった旨のコードまたはメッセージを含む場合には、前記ユーザに関連付けて記録されているエラーリンクにリルートさせるステップ、または、予め登録した前記ユーザごとのエラーページを前記第２レスポンスとして前記クライアントシステムに返送するステップ、の何れかのステップをさらに有する請求項１記載の方法。
- 前記ＩＰアドレスの通知は、前記ユーザシステムにインストールされているエージェントプログラムから定期的に受け取るものである請求項１記載の方法。
- 前記第２リクエストおよびそれに応答する前記第１レスポンスは、ページキャッシュ機能を持つプロキシサーバを介して通信される請求項１記載の方法。
- ＩＰアドレスが動的に変更されるウェブサーバを公開するシステムであって、
前記ウェブサーバを含むユーザシステムからＩＰアドレスの通知を受け取る手段と、
前記ユーザシステムを利用するユーザに関連付けて前記ＩＰアドレスをデータベースに記録する手段と、
クライアントシステムが発した第１リクエストを受け取る手段と、
前記第１リクエストに含まれ、当該システムのドメイン名および前記ユーザのユーザＩＤを含む第１ＵＲＬから、前記ユーザを特定する手段と、
前記ユーザのＩＰアドレスおよび予め記憶した前記ユーザ毎のディレクトリ名を前記データベースから読み取る手段と、
前記第１ＵＲＬを、前記ＩＰアドレスおよび前記ディレクトリ名を含む第２ＵＲＬに変換する手段と、
前記第２ＵＲＬを含む第２リクエストを発行する手段と、
前記第２リクエストに応答する第１レスポンスを受け取る手段と、
前記第１レスポンスのステータスに正常に処理された旨のコードまたはメッセージを含む場合には、前記第１レスポンスを、前記第１リクエストに応答する第２レスポンスとして前記クライアントシステムに返送する手段と、
を含むシステム。 - 前記ユーザシステムから通知された前記ＩＰアドレスを記録する際に、前記通知がなされた時刻または前記ＩＰアドレスを記録した時刻を最終更新時刻として前記ユーザに関連付けて前記データベースに記録する手段と、
前記ＩＰアドレスを前記データベースから読み取る際に、前記データベースから前記最終更新時刻を読み取る手段と、をさらに有し、
現在時刻が、前記最終更新時刻から所定の経過時間内に無い場合には、前記ユーザに関連付けて記録されているエラーリンクにリルートさせる手段、または、予め登録した前記ユーザごとのエラーページを前記第２レスポンスとして前記クライアントシステムに返送する手段、の何れかの手段をさらに有する請求項６記載のシステム。 - 前記第１レスポンスのステータスに、正常に処理されなかった旨のコードまたはメッセージを含む場合には、前記ユーザに関連付けて記録されているエラーリンクにリルートさせる手段、または、予め登録した前記ユーザごとのエラーページを前記第２レスポンスとして前記クライアントシステムに返送する手段、の何れかの手段をさらに有する請求項６記載のシステム。
- 前記ＩＰアドレスの通知は、前記ユーザシステムにインストールされているエージェントプログラムから定期的に受け取るものである請求項６記載のシステム。
- 前記第２リクエストおよびそれに応答する前記第１レスポンスは、ページキャッシュ機能を持つプロキシサーバを介して通信される請求項６記載のシステム。
- ＩＰアドレスが動的に変更されるウェブサーバの公開サービスをコンピュータに実行させるプログラムであって、
前記ウェブサーバを含むユーザシステムからＩＰアドレスの通知を受け取る手順と、
前記ユーザシステムを利用するユーザに関連付けて前記ＩＰアドレスをデータベースに記録する手順と、
クライアントシステムが発した第１リクエストを受け取る手順と、
前記第１リクエストに含まれ、当該プログラムを実行するシステムのドメイン名および前記ユーザのユーザＩＤを含む第１ＵＲＬから、前記ユーザを特定する手順と、
前記ユーザのＩＰアドレスおよび予め記憶した前記ユーザ毎のディレクトリ名を前記データベースから読み取る手順と、
前記第１ＵＲＬを、前記ＩＰアドレスおよび前記ディレクトリ名を含む第２ＵＲＬに変換する手順と、
前記第２ＵＲＬを含む第２リクエストを発行する手順と、
前記第２リクエストに応答する第１レスポンスを受け取る手順と、
前記第１レスポンスのステータスに正常に処理された旨のコードまたはメッセージを含む場合には、前記第１レスポンスを、前記第１リクエストに応答する第２レスポンスとして前記クライアントシステムに返送する手順と、
をコンピュータに実行させるプログラム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001329774A JP3709558B2 (ja) | 2001-10-26 | 2001-10-26 | ウェブサーバの公開方法、システムおよびプログラム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001329774A JP3709558B2 (ja) | 2001-10-26 | 2001-10-26 | ウェブサーバの公開方法、システムおよびプログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003152766A JP2003152766A (ja) | 2003-05-23 |
| JP3709558B2 true JP3709558B2 (ja) | 2005-10-26 |
Family
ID=19145615
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001329774A Expired - Fee Related JP3709558B2 (ja) | 2001-10-26 | 2001-10-26 | ウェブサーバの公開方法、システムおよびプログラム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3709558B2 (ja) |
Families Citing this family (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4055760B2 (ja) | 2004-09-13 | 2008-03-05 | 村田機械株式会社 | ファクシミリ装置 |
| JP4594818B2 (ja) * | 2005-07-29 | 2010-12-08 | 日本電信電話株式会社 | サービス提供システム |
| KR100901281B1 (ko) | 2007-08-30 | 2009-06-09 | 한국전자통신연구원 | 유비쿼터스 웹서비스 방법 |
| JP5196479B2 (ja) * | 2008-08-26 | 2013-05-15 | 日本電信電話株式会社 | 統一資源位置指定子の構成方法およびハイパーテキスト転送プロトコルネットワーク |
| JP5073616B2 (ja) * | 2008-08-26 | 2012-11-14 | 日本電信電話株式会社 | ユーザ識別型リバースプロキシー装置、そのデータ中継方法、およびそのプログラム |
| US9052898B2 (en) | 2011-03-11 | 2015-06-09 | Qualcomm Incorporated | Remote access and administration of device content, with device power optimization, using HTTP protocol |
| US8924556B2 (en) * | 2011-03-11 | 2014-12-30 | Qualcomm Incorporated | System and method for accessing a device having an assigned network address |
| US8862693B2 (en) * | 2011-03-11 | 2014-10-14 | Qualcomm Incorporated | Remote access and administration of device content and configuration using HTTP protocol |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH1065737A (ja) * | 1996-08-23 | 1998-03-06 | Matsushita Electric Ind Co Ltd | 代理サーバ装置およびサーバ装置 |
| JPH11177629A (ja) * | 1997-12-11 | 1999-07-02 | Nippon Telegr & Teleph Corp <Ntt> | セキュリティゲートウェイサーバおよび該サーバを用いたｗｗｗサーバｕｒｌ隠蔽方法とｗｗｗサーバｕｒｌ隠蔽プログラムを記録した記録媒体 |
| JP3475889B2 (ja) * | 2000-01-26 | 2003-12-10 | 日本電気株式会社 | 帯域制御装置，方法および記録媒体 |
| KR20000049472A (ko) * | 2000-03-27 | 2000-08-05 | 유태호 | 개인 컴퓨터로 웹서버운용하는 방법 및 그 시스템 |
| JP2002247075A (ja) * | 2001-02-14 | 2002-08-30 | Toyo Keiki Co Ltd | 接続確立方法、ネットワークシステムおよび自動検針システム |
| JP2003060671A (ja) * | 2001-08-16 | 2003-02-28 | Ivynetwork Co Ltd | 情報公開用サーバ仮想運用システム |
| JP2003078543A (ja) * | 2001-08-30 | 2003-03-14 | First Server Kk | ドメインリゾルバフェイクシステム |
-
2001
- 2001-10-26 JP JP2001329774A patent/JP3709558B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2003152766A (ja) | 2003-05-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7904345B2 (en) | Providing website hosting overage protection by transference to an overflow server | |
| US9219705B2 (en) | Scaling network services using DNS | |
| US9800539B2 (en) | Request routing management based on network components | |
| JP4592184B2 (ja) | 静的な識別子が付され、かつネットワークに断続的に接続される装置へのアクセス方法および装置 | |
| JP4583420B2 (ja) | 最適化されたネットワーク・リソース・ロケーション | |
| JP5404766B2 (ja) | ルーティングをリクエストするための方法とシステム | |
| US9021022B2 (en) | Method and system for identifying website visitors | |
| US7310686B2 (en) | Apparatus and method for transparent selection of an Internet server based on geographic location of a user | |
| US9712422B2 (en) | Selection of service nodes for provision of services | |
| JP7045104B2 (ja) | データを処理する方法、装置、及びコンピュータプログラム、並びに階層ドメインネームシステムのゾーンファイル | |
| CN1890942B (zh) | 重定向对万维网服务的客户端请求的方法 | |
| US20100064047A1 (en) | Internet lookup engine | |
| US20070038755A1 (en) | Systems and methods for direction of communication traffic | |
| US20080243536A1 (en) | Providing website hosting overage protection by storage on an independent data server | |
| US20070073829A1 (en) | Partitioning data across servers | |
| JP2001524778A (ja) | エンハンスドドメインネームサービス | |
| JP2004524602A (ja) | ピアツーピア環境においてキャッシュされた資源間における資源の相同性 | |
| JP2004533687A (ja) | コンピュータ・ネットワークにおけるサービスの動的配備 | |
| JP2014501958A (ja) | ネットワークにおけるコンテンツにアクセスする方法および対応するシステム | |
| JP3709558B2 (ja) | ウェブサーバの公開方法、システムおよびプログラム | |
| US20040122916A1 (en) | Establishment of network connections | |
| US11245623B2 (en) | Method and apparatus for collecting data in network communication using concealed user address | |
| JP2004207778A (ja) | ローカルアドレスを用いたサーバシステム | |
| JPH11175471A (ja) | Ｕｒｌ書き換え方法と装置およびｕｒｌ書き換えプログラムを記録した媒体 | |
| US20150304442A1 (en) | Website product integration and caching via domain name routing rules |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20041130 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20041208 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20050307 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20050310 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050608 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20050727 |
|
| RD14 | Notification of resignation of power of sub attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7434 Effective date: 20050727 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050729 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| LAPS | Cancellation because of no payment of annual fees |