JP2005501354A - 単一ｉｐアドレスを介して複数のウェブ・ドメインによりウェブ・サービスを提供する方法およびシステム - Google Patents
単一ｉｐアドレスを介して複数のウェブ・ドメインによりウェブ・サービスを提供する方法およびシステム Download PDFInfo
- Publication number
- JP2005501354A JP2005501354A JP2003524225A JP2003524225A JP2005501354A JP 2005501354 A JP2005501354 A JP 2005501354A JP 2003524225 A JP2003524225 A JP 2003524225A JP 2003524225 A JP2003524225 A JP 2003524225A JP 2005501354 A JP2005501354 A JP 2005501354A
- Authority
- JP
- Japan
- Prior art keywords
- server
- client
- domain
- service
- web
- 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.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/35—Network arrangements, protocols or services for addressing or naming involving non-standard use of addresses for implementing network functionalities, e.g. coding subscription information within the address or functional addressing, i.e. assigning an address to a function
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/564—Enhancement of application control based on intercepted application data
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computer Security & Cryptography (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer And Data Communications (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Replacement Of Web Rolls (AREA)
- Small-Scale Networks (AREA)
- Information Transfer Between Computers (AREA)
Abstract
【課題】単一IPアドレスを介して複数のウェブ・ドメインによりウェブ・サービスを提供する方法およびシステムであって、HTTPだけでなく、FTP、SMTP、POP3およびその他のウェブ・サービスに実施可能のものを提供すること。
【解決手段】各ドメインについて、一意のドメイン名を有するサーバおよびIPアドレスを割り付け、専用プロトコルを介してサービスのクライアントとサーバの間を仲介すると共に、標準プロトコルを介して各サーバと通信するラッパーを提供し、接続要求を受信した時に、専用プロトコルを介して該クライアントとラッパーの間で相互作用することにより、要求の標的ドメイン名を確認し、標準プロトコルによりラッパーとサーバの間で相互作用し、サーバとクライアントの間で通信チャンネルを確立し、サーバがクライアントにサービスを提供することを許可する。
【選択図】図２
【解決手段】各ドメインについて、一意のドメイン名を有するサーバおよびIPアドレスを割り付け、専用プロトコルを介してサービスのクライアントとサーバの間を仲介すると共に、標準プロトコルを介して各サーバと通信するラッパーを提供し、接続要求を受信した時に、専用プロトコルを介して該クライアントとラッパーの間で相互作用することにより、要求の標的ドメイン名を確認し、標準プロトコルによりラッパーとサーバの間で相互作用し、サーバとクライアントの間で通信チャンネルを確立し、サーバがクライアントにサービスを提供することを許可する。
【選択図】図２
Description
【技術分野】
【０００１】
本発明は、ウェブ・ホスティングの分野に関し、特に、単一IPアドレスを介して複数のウェブ・ドメインによりウェブ・サービス（HTTP、FTP、POP3、SMTPおよびその他のウェブ・サービス）を提供する方法およびシステムに関する。
【背景技術】
【０００２】
ドメインとは、企業により提供されるウェブ・サービス、又は企業のためのウェブ・サービスのグループのことをいう。通常、ドメインはネットワーク・アドレスの組からなり、それぞれが1つまたは複数のウェブ・サービス（HTTP、Telnet、FTP、電子メール等）を提供している。
【０００３】
ドメイン名は、URL（Uniform Resource Locator）の一部であって、ドメインネームシステム（Domain Name System、DNS）を使用して、ドメインネームサーバに、ウェブ・ページまたはウェブ・サービスの要求を転送するべきか、及びどのドメインネームサーバに転送するべきかを示している。ドメイン名は、インターネット上において、識別可能な地点を表すIPアドレスに割り当てられる。
【０００４】
IPアドレス（インターネット・プロトコル・アドレス）とは、TCP/IPネットワークに接続しているコンピュータのアドレスである。インターネットを介して接続できるクライアントおよびサーバ・ステーションは全てIPアドレスを有する必要がある。特定のコンピュータは1つ以上のIPアドレスを持つことも可能である。コンピュータが一つ以上のIPアドレスを有する場合、それらのアドレスは別々のNIC（Network Interface Cards、ネットワーク・インターフェース・カード）に関連させることができ、また、複数のIP（アドレス）は１つのNICに関連させることができる。負荷分散装置またはファイヤ・ウォールを用いて、一つのIPが複数のコンピュータに関連している場合もある。この場合、外部装置（負荷分散装置またはファイヤ・ウォール）が外部IPをある局所IPへ、およびその逆方向に（局所IPを外部IPへ）翻訳する。
【０００５】
IPアドレスは、ピリオドで区切られる４組の番号、例えば204.171.64.2等で表す。TCP/IPパケットは、ネットワーク・アドレス（NetID）およびホスト・アドレス（HostID）からなるIPアドレスを含むために、32ビットを使用する。高位ビットの一部はクラス・タイプを識別し、番号の一部は予約されている。インターネット自体、即ちルートに沿ってパケットを一点から別の点へ移動させるルーターの間において、アドレスのネットワーク部分のみが参照される。
【０００６】
ネットワーク・アドレスにはより多くのビットが使用されているのに対して、ホスト・アドレスには残りの少数のビットが使用されている。インターネットが一般化して、IPアドレスのリソースが消耗されるにつれて、結果としてIPアドレスは貴重なリソースとなる。
【０００７】
数年前までは、インターネット上の各ドメインが自らのIPアドレスを有していたが、現在では、IPリソースの急激な枯渇により、一つのIPアドレスを複数のドメインの間で共有する技術の開発に一層の努力が注がれている。実際、従来技術として、HTTPサービスを提供する複数のウェブサイトのサービスを提供するために、１つのIPアドレスを使用する技術が既に利用されている。この技術を仮想ホステイングという。
【０００８】
仮想ホステイングを実施する方法として次の2つが知られている。名前ベースの仮想ホステイングおよびIPベースの仮想ホステイングである。IPベースの仮想ホステイングでは、１つのホストコンピュータが複数のIPアドレスを取り扱い、それぞれが１つのドメインに対応している。名前ベースの仮想ホステイングでは、１つのIPアドレスが複数のドメインにより共用されている。
【０００９】
HTTP/1.1プロトコルおよびHTTP/1.0の一般的な拡張は、名前ベースの仮想ホステイングをサポートしており、それゆえにウェブサーバはこのプロトコルと互換性がある。これは、ウェブ・ドメインをHTTPの「GET」要求に含めることにより実施（実装）されている。しかしながら、従来の技術では、HTTP以外のウェブ・サービス（FTPおよび電子メールサービス等）を提供する複数のドメインの間でIPアドレスを共用するという問題に対する解決法は開示されていない。
【発明の開示】
【発明が解決しようとする課題】
【００１０】
本発明は、単一IPアドレスを介して複数のウェブ・ドメインによりウェブ・サービスを提供する方法およびシステムであって、HTTPだけでなく、FTP、SMTP、POP3およびその他のウェブ・サービスに実施可能のものを提供することを課題とする。
【００１１】
本発明の他の目的および利点は、説明を進めるに連れて明らかになるであろう。
【課題を解決するための手段】
【００１２】
上記課題を解決するため、本発明では次のような構成を採っている。
【００１３】
本発明の一様態は、単一IPアドレスを介してコンピュータによりホスト（提供）されている複数のウェブ・ドメインにより、ウェブ・サービスを提供する方法に係り、以下からなる。
【００１４】
a)各ドメインについて、サービスを提供するために、一意のドメイン名を有するサーバおよびIPアドレスを割り付ける。
【００１５】
b)専用プロトコルを介してサービスのクライアントとサーバの間を仲介し、標準プロトコルを介して各サーバと通信する、ソフトウェア・モジュールであるラッパーを提供する。
【００１６】
c)サービスを提供するために、クライアントをサーバの一台と接続させるための要求を受信した時に以下を実行する。
【００１７】
(i)専用プロトコルを介してクライアントとラッパーの間で相互作用することにより、要求の標的ドメイン名を確認する。
【００１８】
(ii)標準プロトコルにより、ラッパーと標的ドメイン名に関連するサービスを提供するサーバの間で相互作用する。
【００１９】
(iii)サーバとクライアントの間で通信チャンネルを確立する。そして、
【００２０】
(iv)サーバがクライアントにサービスを提供することを許可する。
【００２１】
専用プロトコルは、ユーザおよびドメインを確認するための司令（コマンド）を含んでいても良い。ドメイン名は、ユーザ名においてプロトコルで定義された1つまたは複数の非許容文字により、ユーザ名から分離されていてもよい。
【００２２】
本発明の一実施形態によれば、ウェブ・サービスはFTPであり、ドメイン名フレーズは「user%domain」または「domain%user」であり、ここで「user」はユーザ名、「domain」はドメイン名、そして「%」は非許容文字である。
【００２３】
本発明の他の実施形態によれば、ウェブ・サービスはPOP3であり、ドメイン名フレーズは「user%domain」または「domain%user」であり、ここで「user」はユーザ名、「domain」はドメイン名、そして「%」は非許容文字である。
【００２４】
ウェブ・サービスは、HTTP、FTP、POP3、SMTP、MIRC（チャットを利用するための代表的なソフトウェア）、Telnet、SSH、Rtelnet、およびShellであっても良い。
【００２５】
各ウェブ・ドメインは、異なった仮想専用サーバを参照しても良い。
【００２６】
コンピュータ・システムは、Unix（登録商標）ベースのシステムであっても良く、Unix（登録商標）、Solaris（登録商標）、Linux（登録商標）（Red Hat（登録商標）、Debian（登録商標）、SuSE（登録商標）、FreeBSD（登録商標）等）、AIX、HP（登録商標）/UX、Tru64、およびIrix（登録商標）のいずれの亜種でも良い。
【００２７】
本発明の一実施形態によれば、一部のサーバまたは全サーバをハード・リンク（hard link）で置き換えることが可能である。
【００２８】
本発明の他の様態は、単一IPアドレスを介してコンピュータによりホストされている複数のウェブ・ドメインにより、ウェブ・サービスをクライアントに提供するシステムに係り、以下からなる。
【００２９】
各ドメインにつき、サービスを提供するサーバと、
【００３０】
クライアントとの通信が専用プロトコルを介して行われ、サーバとの通信が標準プロトコルにより行われるように、クライアントとサーバの間を仲介するラッパーとである。
【発明を実施するための最良の形態】
【００３１】
以下、図面を参照しながら、本発明の実施形態について説明する。
【００３２】
本明細書において、実施例は、一般性を失うことなく、Solaris（登録商標）、Linux（登録商標）（Red Hat（登録商標）、Debian（登録商標）、SuSE（登録商標）、FreeBSD（登録商標）等）、AIX、HP（登録商標）/UX、Tru64、Irix（登録商標）等のUnix（登録商標）ベースのオペレーティング・システムに係る。
【００３３】
クライアント／サーバとは、一方のプログラムであるクライアントが、他方のプログラムであるサーバからのサービスを要求して、サーバーが要求を満たすという、2つのコンピュータ・プログラムの間にある関係を言う。クライアント／サーバの関係は、単一コンピュータ内のプログラムによっても使用できるが、ネットワークにおいてより役立つ。ネットワークにおいて、クライアント／サーバ・モデルは効率的に別々の位置に渡って分配されているプログラムを互いに接続させる便利な方式を提供する。クライアント／サーバ・モデルはネットワーク・コンピューティングの中心思想になった。通常、TCP/IPプロトコルに基づくインターネットの主要プログラムの他に、近年作成されているビジネス・アプリケーションの殆どがクライアント／サーバ・モデルを使用している。
【００３４】
IPアドレスに関連するクライアント・プロセスが、実際にウェブサーバと通信する。ウェブサーバは、クライアント／サーバ・モデルを使用し、そのサービスの要求に対して「サービスを提供する」プログラムである。ウェブサイトを含有するインターネット上のコンピュータは全てウェブ・サーバ・プログラムを有する必要がある。一方では、大規模のウェブサイトが別々の地理的位置において複数のサーバ上に展開される場合もある。他方では、1台のウェブサーバが、複数のウェブサイトをホスト（提供）する場合もある。
【００３５】
ウェブに対して、ウェブサーバは、要求されたHTMLページまたはファイルを提供するコンピュータプログラムである。ウェブクライアントは、ユーザに関連している要求側プログラムである。ユーザのコンピュータ内のウェブ ブラウザは、ウェブサーバからHTMLファイルを要求するクライアントである。
【００３６】
通常のクライアント／サーバ・モデルでは、一つのサーバが起動しており、クライアント要求を待ち受ける。このサーバは、デーモンと呼ばれることがある。一般に、多数のクライアント・プログラムが共通のサーバ・プログラムのサービスを共用する。クライアント・プログラムとサーバ・プログラムの両方が、より大規模のプログラムまたはアプリケーションの一部であることはよくある。インターネットに対して、ウェブ ブラウザは、インターネット上の何所かにある別のコンピュータ内のウェブサーバ（技術的には、ハイパーテキスト転送プロトコルまたはハイパーテキスト転送プロトコルサーバという）からサービス（ウェブページまたはファイルの送信）を要求するクライアント・プログラムである。同様に、TCP/IPがインストールされているコンピュータは、インターネット上の他のコンピュータ内のFTP（ファイル転送プロトコル）サーバから、ファイルのクライアント要求を開始するのに適合している。
【００３７】
デーモンとは、受信要求を待ち受け、適時、他のプロセスへ転送するプロセスである。ウェブ上では、各サーバは、ウェブの他の場所から要求が着信するのを随行して待つHTTPD（ハイパーテキスト・転送プロトコル・デーモン）を有する。
【００３８】
本明細書においてソケットという用語は、TCP/IPネットワークを介してデータをアプリケーションへ向ける設備（仕組み）のことをいう。ステーション（コンピュータ）のIPアドレスとポート番号の組み合わせにより、ソケットが決定される。第1のコンピュータは、データを第2のコンピュータへ送信するために、データをソケットに書き込む。そして、第2のコンピュータは、データをそのソケットから読み取る。これは電話の呼出と同様に説明できる。電話の加入者と話すには、その電話番号（本例ではIPアドレス）、次いで、内線番号（ポート番号）をダイヤルする必要がある。接続が確立した後、受話器（ソケット）に向かって話し、相手は自分の受話器（ソケット）から聞き取る。
【００３９】
本明細書において公知のポートとは、ネットワーク上において一定のタイプのデータに幅広く使用されているプロトコル・ポートのことをいう。例えば、HTTPには通常、ポート80が割り当てられ、FTP転送は、ポート21であり、POP3はポート番号110、およびX-Windows（登録商標）は6000である。本明細書において「優先ポート」とは、1から1023の番号を振り付けたプロトコル・ポートのことをいう。
【００４０】
Unix（登録商標）ベースのオペレーティング・システムにおいて、FTPサーバは、公知のポートを介して通信セッションを行うプロセスである。通信セッション中、FTPサーバは、RFC 959に定義される司令（コマンド）を実行する。RFC（Request For Comment、コメントの要求）は、Internet Engineering Task Force（IETF、インターネット・エンジニアリング・タスク・フォース）からの正式な文書であり、委員会の草案、および関係者によるその後の改訂の結果である。
【００４１】
通常最初に実行されるべき２つの司令は、FTPサーバへのユーザ名およびそのパスワードを確認するために使用される「USER」司令および「PASS」司令である。ユーザ確認は、ファイルのダウンロードまたはアップロードなどのFTPサーバに対する次なる司令の前に行われる。
【００４２】
FTPサーバは、コンピュータのユーザ名およびパスワード（Unix（登録商標）ベースのシステムでは「/etc/passwd」にある）を使用して、名前およびパスワードを認証し、一致する場合、ユーザは、ファイルシステム上の特定のユーザ許可（パーミッション）に従ってファイルへアクセスすることを許可される。当然、他のいずれの安全機構を使用することもでき、本明細書においては簡潔にするためにこの方式のみを記述した。
【００４３】
Inetd（InternET Daemon , インターネット・デーモン）は、通常のTCP/IPサービスを管理するUnix（登録商標）機能である。Inetdは、スタートアップ時に起動し、各種接続要求（FTP、Telnet等）を待ち受け、適当なサーバ構成要素（コンポーネント）を起動する。
【００４４】
従来の技術によれば、FTPサーバまたは他のいずれのインターネットサーバは、以下の２つのモードで起動される。
【００４５】
一つは、単一プロセス（Inetdデーモン）が複数のネットワーク・サービスを提供する「Inetd」モードである。このデーモンは、接続要求を待ち受けながら特定のポートを「聞き取っている」。接続要求が着信すると、サービス・プロセス（公知のポートに従い）を作成し、それが通信セッションを処理できるようにする。
【００４６】
このアプローチの利点は、複数のプロセスの代りに単一プロセスがポートを聞き取っているため、システム・リソースを節約できるところにある。
【００４７】
もう一つは、「スタンド・アロン」モードであり、関連するプロセスが一回（例えば、システム・ブート時に）作成され、そのプロセスが接続を扱う。このモードは、通常、常に活動中（利用可能）のサービスであって、接続（コネクション）が着信する毎にプロセスを開始したり終了すると不必要なオーバーヘッドになってしまうサービスに適している。
【００４８】
通常、HTTPサーバは、スタンド・アローン・モードで操作するが、一方、FTPサーバ、POP3サーバ、およびSMTPサーバは「Inetd」モードである。
【００４９】
〔名前ベースのFTPおよび電子メールの問題〕
【００５０】
RFC 959に記述のとおり、FTPの元の設計では、司令に対象ドメインが含まれているHTTPサービスとは異なり、FTPは、1つのIPアドレスに関連する1つのドメインのサービスを提供するように向けられている。従って、例えば、ftp.aaa.comおよびftp.bbb.comの２つのドメインが同じホスト・コンピュータ上に存在して同じIPアドレスを共有している場合、ユーザxxx@ftp.aaa.comとユーザxxx@ftp.bbb.comは同一である。また、ユーザが「ftp.aaa.com/pub/」にアクセスを試みると、「ftp.bbb.com/pub/」と同様のディレクトリに達することになる。
【００５１】
当業者は、ftp.aaa.comおよびftp.bbb.comの特定のサブディレクトリを定義し、各ドメインのユーザが他のディレクトリにアクセスするのを防ぐことにより、この問題に対して部分的な解決法を決定し得る。しかしながら、このようなアプローチには実質的に複数の問題がある。
【００５２】
ユーザは、もう一つのディレクトリがあることを意識しているが、アクセスできない。このことは、各ドメインが同じホスト・コンピュータ上にある他のドメインの存在を意識しない方が望ましいので、ウェブ・ホスティング会社にとっては不利であり得る。
【００５３】
ホスト・コンピュータ上において、特定の名前のユーザは一人のみ（上記の例では「xxx」）しか存在できないので、共通の名前（「webmaster」、「jobs」、「info」等）を複数のドメインに割り当てることができない。この解決法を支援するには、システムは、各ドメインのユーザを個別の場所に保つべきであることに注意すべきである。例えば、同時係属中のイスラエル特許出願第147560号に記述のVDS技術は、そのような解決法である。
【００５４】
ホスト・コンピュータによりホスト（提供）されている全てのドメインに対して一つのFTPサーバが使用される。したがって、プロセス・リソースが共有されているので、１つのドメインによるリソースの消費を計算するための自明な方法はない。
【００５５】
ファイルのアクセス許可を変更することにより、ファイルが、「cookie」ユーザなど他のユーザによりアクセス可能になってしまう。
【００５６】
〔解決法〕
【００５７】
実際、上記問題の基本となるのは単一のコンピュータから複数のドメインへFTPサービスを提供するのに適していないプロトコルである。同様の問題がメール・サービスにも関連する。プロトコルにおける制限により、サービスのプロバイダも限られている。
【００５８】
「欠落」ドメインの問題は、POP3のみに当てはまる。SMTPにおいては、ドメインも渡されるため、FTPのようにドメインをユーザ名に追加する必要はない。しかしながら、妥当なサーバ、即ち、適当なVDSのサーバは、要求に対応するためにラッパー（wrapper）が常に必要である。
【００５９】
本明細書に開示する解決法によれば、通信の連鎖において、クライアントとサーバの間に仲介者が追加される。仲介者の役割は、サービス要求において要求されるドメインを認識し、そのサーバへ標準的な形式で要求を転送することである。
【００６０】
よって、仲介者は、あたかもサービス・プロバイダであるかのようにクライアントと相互作用すると共に、クライアントであるかのようにサービス・プロバイダと相互作用する。
【００６１】
実際、ドメインが確認された後、クライアントは、要求されたドメインに関連するサービス・プロバイダと直接に、即ち、いかなる仲介もなく相互作用できる。
【００６２】
〔独立ユーザ名付けシステム〕
【００６３】
従来の技術によれば、domainl.com、domain2.com、等のドメインをホスト（提供）するホスト・コンピュータは、例えばsysadminという名前のユーザを2人、またはそれ以上有することはできない。
【００６４】
本発明の一実施形態によれば、ホスト・コンピュータ・システム上においてホスト（提供）されている各ドメインの独立ユーザ名付けシステムを可能とするため、ドメイン名は、ユーザ名に組込まれている。前記例においては、ユーザーは、ユーザ名、即ちxxxの代りに、xxx%aaa.com、xxx%bbb.com、等で身元を明らかにする。
【００６５】
具体的に、標準のFTPプロトコルに従って「USER」司令（コマンド）を発行した時、ユーザは、ドメインが組込まれた名前で身元を明らかにする。これは本例によるとUSERNAM%DOMAIN、即ち、ユーザ名に「%」およびドメイン名が後続するものである。
【００６６】
当然、この構文は、RFC 959に定義されているFTPの標準プロトコルに適合しないので、以降説明するような追加ステップを行うべきである。
【００６７】
〔1つのコンピュータ・システムによって複数のドメインをホスト（提供）する〕
【００６８】
本発明の一実施形態によれば、この形式をサポートするためにFTP処理を変更する。
【００６９】
本発明の他の実施形態によれば、通信部分を扱う構成要素（コンポーネント）が通信の連鎖に追加される。この構成要素は、ユーザが確認されると、第三者（サード・パーティ）のFTPサーバ（即ち、コンピュータの所有者は、任意のFTPサーバを使用することができる。例えば、オープンソース、市販、または自家製のものであってもよい）への接続を担当する。
【００７０】
簡略にするため、この構成要素がプロセスであると仮定する。このプロセスは、以降FTPラッパーまたはラッパーという。
【００７１】
FTPポートへの接続がホスト・コンピュータに着信すると、デーモンは、FTPラッパー・プロセスを作成する。FTPラッパーは、FTPサーバとしてクライアントと「交渉」し、即ち、クライアントから司令を受けとり、FTPサーバとしてクライアントへ返答を中継する。交渉はクライアントが「USER」司令を発信するまで続く。
【００７２】
ユーザがFTPサーバにログインする前には司令の殆どがサポートされないため、ラッパーは、FTP司令のサブセットのみをサポートしてもよいことに注意すべきである。FTPラッパーが一旦「USER」司令を受信すると、FTPラッパーは、それ（「USER」指令）がユーザ名および有効なドメイン名を含んでいることを確認し、そのドメイン用のFTPサーバを起動する。
【００７３】
より改善した性能を達成するために、ラッパーをデーモンと統合し、各接続毎のラッパー・プロセスの作成を不要としてもよいことに注意すべきである。
【００７４】
元のFTPサーバが一旦作成されると、FTPサーバは、「USER」司令、およびユーザが発信した、いずれの司令も含め、最初から通信を受けることとなる。
【００７５】
本発明の一実施形態によれば、ラッパー・プロセスは、FTPセッション全体において、活動を保っている（起動している）。よって、ラッパー・プロセスは、クライアントとFTPサーバの間のインターフェイスとして機能する。即ち、サービス要求は全てFTPサーバに渡され、サーバからの結果はいずれもクライアントに渡される。
【００７６】
共用ライブラリ（Shared library、また、Windows（登録商標）オペレーティング・システムではDLLという）は、機能（関数）の寄せ集めであって、当該機能（関数）は、通常特定の課題に関連し、実行時に全てのプロセスによりアクセス可能な独立ファイルに保管されている。
【００７７】
本発明の好ましき実施形態によれば、上記問題の解決法は、Unix（登録商標）ベースのプロセスの大半が共用ライブラリにリンクされていることに基づく。このアプローチには以下の利点がある。
【００７８】
共用機能（関数）はプロセス自体の一部ではないので、各プロセスは小規模である。これにより、プログラムを保存するためにも、かつプログラムを分散するためにも、より少量のディスク空き領域で足りる。
【００７９】
オペレーティング・システムは、ライブラリの単一コピーをメモリに取り込み、多数のプロセスに対してそれ（ライブラリの単一コピー）を使用できるので、共用ライブラリを使用する多数のプロセスに要するメモリの量は、共用ライブラリなしで実行する同プロセスに要する量より少ない。
【００８０】
既存の機能に新しい特性を含めたり、バグを修正したり、セキュリティ・ホールを修正するためには、新しいバージョンの機能（関数）を開発することになる。新しいバージョンの機能を共用ライブラリ内に据え付けると、実行時に取り込まれるプロセスは、新しいバージョンの機能を参照するが、他のプロセスは新しいバージョンの機能（関数）を参照しない。
【００８１】
本発明の一実施形態によれば、元のソケット・ライブラリの当該機能と置き換わる新しい共用ライブラリが実行されるが、元のソケット・ライブラリは、後で使用するために保管される。新しい共用ライブラリの機能は、ある追加操作（元の機能にはないもの）を行った後、元のライブラリにおける同名の機能（関数）を実行する。
【００８２】
この機構は従来の技術において公知であり、フッキングという。フックとは、追加特性など、パッケージ化されたコード内に提供される場所（通常インターフェイス）であって、プログラマーがカスタマイズしたプログラミングを挿入できる場所である。
【００８３】
本発明の一実施形態によれば、フッキングは以下の通り実行する。
【００８４】
クライアントから受信した情報を一時的に保持するためのバッファが各ソケットに提供される。
【００８５】
操作中に、バッファが空でない場合、「読み取り」司令は、このバッファからデータを読み取り、バッファが空の場合、「読み取り」司令は、ソケットからデータを検索する。
【００８６】
「読み取り」バッファが空になるまで、いずれの「書き込み」司令もデータを無視する。その後、情報は全てソケットへ転送される。ライブラリを使用しているプロセスが「書き込み」司令を行う場合、ライブラリは常に内部バッファのステータスを確認する。内部バッファに何らかの情報がある場合、この情報がラッパーにより既に扱われたものであるため、「書き込み」司令に渡された情報は無視され、「成功」ステータスが呼び出し側に戻される。内部バッファ内に更なるデータが存在しない場合、情報は通常のソケット・ライブラリに渡される。
【００８７】
本発明の好ましき実施形態によれば、共用ライブラリとしてソケット・ライブラリ機能の特殊バージョンが提供される。ラッパー・プロセスは、このライブラリを参照する。ソケット・ライブラリの特殊バージョンは、ソケットに送信したデータまたはソケットから受信したデータをバッファに書き込む。一旦「USER」司令を受信すると、FTPラッパー・プロセスは、FTPプロセスを作成する。この時点以降、FTPサーバは、FTPラッパーの仲介なしで直接にクライアントと通信する。即ち、ライブラリの特殊バージョンの機能ではなく元の機能が呼び出される。これにより、僅かなオーバーヘッドが発生する。
【００８８】
〔FTPセッション〕
【００８９】
図1は、本発明の一実施形態による代表的なFTPセッションを図示する概略図である。
【００９０】
ステップ1では、クライアントは、ホスト・コンピュータのFTPポートに接続する。Inetdは、要求を受信し、ポート（即ち、クライアントとの通信チャンネル）を開く。
【００９１】
ステップ2では、一旦クライアントとの通信チャンネルが確立されたら、「USER」司令以外のFTP司令は、いずれも「USER」司令が着信まで処理されずバッファに保存される（但し、クライアントが通信を終了しないように適当な返信／応答がクライアントに送信される）。
【００９２】
ステップ3では、「USER xxx%aaa.com」司令が受信される。FTPプロセスに関連のある司令のみ、即ち「USER xxx」が前述のバッファに保存される。
【００９３】
ステップ4では、aaa.comドメイン用にFTPプロセスが作成される。
【００９４】
ステップ5では、ラッパーがプロセス（機能ではなく）である場合、ラッパーの実行は終了する。ステップ1乃至5のセッションが、従来の技術のようにクライアントとFTPサーバの間ではなく、クライアントとInetdの間で、またはラッパーにより行われたことに注意すべきである。
【００９５】
ステップ6では、FTPプロセスは、前述のバッファに保存された司令を受信する。実際、FTPサーバは、クライアントとではなく、ラッパー（あるいはラッパーがバッファ内に保持した情報）と通信するが、FTPサーバはこのことを「意識」していない。この時点以降、クライアントは、従来の技術の如くFTPサーバと通信する。
【００９６】
ステップ7では、認証のためクライアントからFTPサーバにPASS司令が送信される。
【００９７】
ステップ8では、FTPサーバによりパスワードが認証された後、クライアントは、ダウンロード、アップロード、消去、等のFTPサーバにより実行されるファイル関連の司令を送信することができる。パスワードの確認が、ラッパーではなくFTPサーバにより対応されていることに注意すべきである。したがって、ユーザが、そのFTPサーバに特殊な認証モジュールをインストールしたり、ログインが失敗した際に特別な動作が実行されることを好む場合、これらの操作はいずれにしても行われることになる。
【００９８】
〔本発明を他のウェブ・サービスに適用する〕
【００９９】
ウェブ・メール・サービスでは、インターネットに接続された任意のコンピュータから新しい電子メールを表示し、返答することができる。電子メール・メッセージは、ユーザが自分のホーム・コンピュータから再度メールを確認するまでメール・サーバ上に残る。
【０１００】
POP（Post Office Protocol、ポスト・オフィス・プロトコル）では、メールはウェブを介してアクセス可能なサーバに配達され、パーソナル・コンピュータのユーザが周期的にサーバに接続し、全ての未通知メール（メール・サーバに残されているメール）を「クライアント」機にダウンロードする。その後、メールの処理はクライアント機において局所的なものになる。
【０１０１】
SMTP（Simple Mail Transfer Protocol、単純メール転送プロトコル）は、インターネット上において、標準の電子メールプロトコルである。SMTPサーバは、インターネットを通じてSMTPメッセージをPOP3またはIMAP4など、着信メールのメッセージを蓄えるメールサーバへ配達する。
【０１０２】
ウェブ・メール・プロトコルは、FTPプロトコルと同様に、ユーザを認証することによりユーザへのサービス提供を制限していて、これは通常ユーザ名およびパスワードにより行われる。ユーザは通常ホスト・コンピュータ上のアカウントに属するため、このようなサービスの提供は、FTPと同様に導入することが可能である。
【０１０３】
HTTP（HyperText Transport Protocol、ハイパーテキスト転送プロトコル）は、ワールド・ワイド・ウェブ上のサーバに接続するために使用される通信プロトコルである。その主な機能は、ウェブサーバとの接続を確立し、HTMLページをクライアントのブラウザに転送することである。ウェブサイトのアドレスは「http://」の接頭部で始まる。
【０１０４】
HTTPでは、「仮想ホステイング」という公知の解決法がある。この技法を使用することにより、HTTPサーバは、（司令内の特殊な行から）ユーザがアクセスを望んでいるドメインを検出することができ、したがって各ドメインの別のディレクトリ・ツリーへアクセスすることができる。しかしながら、この解決法は、ドメインの間で同じウェブサーバを共有することを前提としている。したがって、この解決法は、各ドメインに与えられるリソースを制限することに興味があり、各アカウントの実際の使用に基づいて課金するであろうウェブ・ホスティング会社には不適である。
【０１０５】
本発明の一実施形態によれば、ウェブサーバからの複数の要求が同時に実行できるので、各ドメイン（またはドメインのグループ）が自らの要求を受信できるようになる。しかしながら、コンピュータ上で一定時間に一定のポートを使用できるのは１台のウェブサーバのみであり、その時間活動していていられるウェブサーバは１台のみである。
【０１０６】
この制限は、データを元のソケットから、一定時間に複数のウェブサーバにより実際にアクセス可能な「内部」ソケットにパイプする（プロセス間通信方式の一つで、あるプログラムの出力を、別のプログラムに入力する）ことにより克服することができる。
【０１０７】
よって、本発明はHTTPサービス並びにFTPおよびメールにも適用し得る。従来の技術において使用される仮想ホステイング方法、即ち、ウェブサーバにより提供される仮想ホステイング能力を導入することにより、全てのドメインのサービスが単一のウェブサーバにより提供される。しかしながら、本発明によれば、複数のウェブサーバが同時に稼動し、各ウェブサーバがドメインの一部のサービスを提供することができる。したがって、WHP（Web Hosting Provider）は、提供するウェブサイトの性能を改善することができる。
【０１０８】
接続要求を受信して、要求ドメインを読み取り、情報を有するソケットをウェブサーバに渡すことは、サーバにとって透過的であることに注意すべきである。
【０１０９】
上記実施例および説明は当然例示を目的としてのみ提供されたものであり、本発明は、MIRC、Telnet、SSH、Rtelnet、およびShellを含め、任意のウェブ・サービスに導入することが可能である。
【０１１０】
これらサービスの安全なバージョン、並びに他のいずれの安全なサービスも類似したアプローチにより導入することができる。しかしながら、安全なサービスは、通常各ドメイン毎に異なった暗号化キーを使用するので導入は容易ではない。 このキーは、許可されていないコンピュータが情報にアクセスするのを防止するため、並びに情報が送信されるサーバを認証するために使用される。安全なサービスに対して同様のアプローチを導入するための解決法として次の方法が可能である。
【０１１１】
各サーバ上の、全ドメインに同一のキーを使用すること。
【０１１２】
標的ドメインに関する情報の一部をクリア（即ち、暗号化されていない）テキストに含むようにプロトコルを変更すること。
【０１１３】
全てのドメインキーを使用して、メッセージの復号化を試みること。一旦メッセージが復号化されると、ラッパーは、メッセージを標的ドメイン（メッセージの復号化が行われたキーにより決定される）に渡すことができる。
【０１１４】
〔名前ベースのVDS〕
【０１１５】
同時係属中のイスラエル特許出願第147560によると、リモートクライアントがそのシステム・ユーティリティおよびプログラムにアクセスできるコンピュータ・システムのエミュレーションを仮想専用サーバ（Virtual Dedicated Server、VDS）という。該特許出願によると、複数のVDSインスタンスが同時に１台のコンピュータ・システム上で実行され、各VDSインスタンスはルート・ディレクトリとして別々のディレクトリ・ツリーを参照することができる。
【０１１６】
VDS技術を使用すると、FTPサーバは、各ドメインに別々の「/etc/passwd」を使用することができる。その結果、各ドメインにつき異なった許可されたユーザの組ができる（複数のドメイン内に同じユーザ名を含んでもよい）。
【０１１７】
本明細書に記載の技術を使用すると、複数のVDSが、VDSにより提供されるウェブ・サービスに対して単一のIPアドレスを使用することができる。
【０１１８】
図2は本発明の好ましき実施形態による1台のコンピュータ・システムによりホスト（提供）されているVDSシステムによりホスト（提供）されているウェブサーバを図示する概略図である。
【０１１９】
ホスト・コンピュータ10は、VDSシステム 60および70をホストしている。VDS 60は、FTPサーバ11およびPOP3サーバ12をホストしている。VDS 70は、POP3サーバ21、FTPサーバ22およびHTTPサーバ23をホストしている。デーモン40は、公知のFTPポート、HTTPポート、およびPOP3ポートを「聞き取っている」。クライアント30からの接続要求をデーモン40が指定すると常に、ラッパーは、ドメインが指定されるまで適当なウェブ・サーバとしてクライアント30と「交渉する」。次いで、ラッパーは、クライアントであるのかのように、適切なウェブサーバ11、12、21、22または23と交渉する。最終段階において、適当なウェブサーバとクライアントの間に、通信セッションが終了するまで接続が確立される。
【０１２０】
「適当なサーバ」は、次の2つのパラメータにより指定される。この２つのパラメータとは、サーバのタイプ（FTP、HTTP等）を指定するポート、および適当なVDSを指定するドメインである。
【０１２１】
同時係属中のイスラエル特許出願第147560号に記載の如く、システムの性能は、ハード・リンク（hard link）を使用することによって改善することが可能である。
【０１２２】
上記実施例および説明は、当然例示を目的として提供したものであり、本発明を何ら制限するものではない。本発明は、上記の技法を1つ以上用い、多数の態様により、全て本発明の請求の範囲から遺脱せず、実施出来ることは当業者に明らかであろう。
【図面の簡単な説明】
【０１２３】
【図１】本発明の一実施形態において、代表的なFTPセッションを図示する概略図である。
【図２】本発明の最良の実施形態において、一つのコンピュータ・システムがホストする（備えた）VDSシステムによりホスト（提供）されているウェブサーバを図示する概略図である。
【符号の説明】
【０１２４】
１０ ホスト・コンピュータ
１１ FTPサーバ（ウェブサーバ）
１２ POP3サーバ（ウェブサーバ）
２１ POP3サーバ（ウェブサーバ）
２２ FTPサーバ（ウェブサーバ）
２３ HTTPサーバ（ウェブサーバ）
３０ クライアント
４０ デーモン
５０ ラッパー
６０ VDSシステム
７０ VDSシステム
【０００１】
本発明は、ウェブ・ホスティングの分野に関し、特に、単一IPアドレスを介して複数のウェブ・ドメインによりウェブ・サービス（HTTP、FTP、POP3、SMTPおよびその他のウェブ・サービス）を提供する方法およびシステムに関する。
【背景技術】
【０００２】
ドメインとは、企業により提供されるウェブ・サービス、又は企業のためのウェブ・サービスのグループのことをいう。通常、ドメインはネットワーク・アドレスの組からなり、それぞれが1つまたは複数のウェブ・サービス（HTTP、Telnet、FTP、電子メール等）を提供している。
【０００３】
ドメイン名は、URL（Uniform Resource Locator）の一部であって、ドメインネームシステム（Domain Name System、DNS）を使用して、ドメインネームサーバに、ウェブ・ページまたはウェブ・サービスの要求を転送するべきか、及びどのドメインネームサーバに転送するべきかを示している。ドメイン名は、インターネット上において、識別可能な地点を表すIPアドレスに割り当てられる。
【０００４】
IPアドレス（インターネット・プロトコル・アドレス）とは、TCP/IPネットワークに接続しているコンピュータのアドレスである。インターネットを介して接続できるクライアントおよびサーバ・ステーションは全てIPアドレスを有する必要がある。特定のコンピュータは1つ以上のIPアドレスを持つことも可能である。コンピュータが一つ以上のIPアドレスを有する場合、それらのアドレスは別々のNIC（Network Interface Cards、ネットワーク・インターフェース・カード）に関連させることができ、また、複数のIP（アドレス）は１つのNICに関連させることができる。負荷分散装置またはファイヤ・ウォールを用いて、一つのIPが複数のコンピュータに関連している場合もある。この場合、外部装置（負荷分散装置またはファイヤ・ウォール）が外部IPをある局所IPへ、およびその逆方向に（局所IPを外部IPへ）翻訳する。
【０００５】
IPアドレスは、ピリオドで区切られる４組の番号、例えば204.171.64.2等で表す。TCP/IPパケットは、ネットワーク・アドレス（NetID）およびホスト・アドレス（HostID）からなるIPアドレスを含むために、32ビットを使用する。高位ビットの一部はクラス・タイプを識別し、番号の一部は予約されている。インターネット自体、即ちルートに沿ってパケットを一点から別の点へ移動させるルーターの間において、アドレスのネットワーク部分のみが参照される。
【０００６】
ネットワーク・アドレスにはより多くのビットが使用されているのに対して、ホスト・アドレスには残りの少数のビットが使用されている。インターネットが一般化して、IPアドレスのリソースが消耗されるにつれて、結果としてIPアドレスは貴重なリソースとなる。
【０００７】
数年前までは、インターネット上の各ドメインが自らのIPアドレスを有していたが、現在では、IPリソースの急激な枯渇により、一つのIPアドレスを複数のドメインの間で共有する技術の開発に一層の努力が注がれている。実際、従来技術として、HTTPサービスを提供する複数のウェブサイトのサービスを提供するために、１つのIPアドレスを使用する技術が既に利用されている。この技術を仮想ホステイングという。
【０００８】
仮想ホステイングを実施する方法として次の2つが知られている。名前ベースの仮想ホステイングおよびIPベースの仮想ホステイングである。IPベースの仮想ホステイングでは、１つのホストコンピュータが複数のIPアドレスを取り扱い、それぞれが１つのドメインに対応している。名前ベースの仮想ホステイングでは、１つのIPアドレスが複数のドメインにより共用されている。
【０００９】
HTTP/1.1プロトコルおよびHTTP/1.0の一般的な拡張は、名前ベースの仮想ホステイングをサポートしており、それゆえにウェブサーバはこのプロトコルと互換性がある。これは、ウェブ・ドメインをHTTPの「GET」要求に含めることにより実施（実装）されている。しかしながら、従来の技術では、HTTP以外のウェブ・サービス（FTPおよび電子メールサービス等）を提供する複数のドメインの間でIPアドレスを共用するという問題に対する解決法は開示されていない。
【発明の開示】
【発明が解決しようとする課題】
【００１０】
本発明は、単一IPアドレスを介して複数のウェブ・ドメインによりウェブ・サービスを提供する方法およびシステムであって、HTTPだけでなく、FTP、SMTP、POP3およびその他のウェブ・サービスに実施可能のものを提供することを課題とする。
【００１１】
本発明の他の目的および利点は、説明を進めるに連れて明らかになるであろう。
【課題を解決するための手段】
【００１２】
上記課題を解決するため、本発明では次のような構成を採っている。
【００１３】
本発明の一様態は、単一IPアドレスを介してコンピュータによりホスト（提供）されている複数のウェブ・ドメインにより、ウェブ・サービスを提供する方法に係り、以下からなる。
【００１４】
a)各ドメインについて、サービスを提供するために、一意のドメイン名を有するサーバおよびIPアドレスを割り付ける。
【００１５】
b)専用プロトコルを介してサービスのクライアントとサーバの間を仲介し、標準プロトコルを介して各サーバと通信する、ソフトウェア・モジュールであるラッパーを提供する。
【００１６】
c)サービスを提供するために、クライアントをサーバの一台と接続させるための要求を受信した時に以下を実行する。
【００１７】
(i)専用プロトコルを介してクライアントとラッパーの間で相互作用することにより、要求の標的ドメイン名を確認する。
【００１８】
(ii)標準プロトコルにより、ラッパーと標的ドメイン名に関連するサービスを提供するサーバの間で相互作用する。
【００１９】
(iii)サーバとクライアントの間で通信チャンネルを確立する。そして、
【００２０】
(iv)サーバがクライアントにサービスを提供することを許可する。
【００２１】
専用プロトコルは、ユーザおよびドメインを確認するための司令（コマンド）を含んでいても良い。ドメイン名は、ユーザ名においてプロトコルで定義された1つまたは複数の非許容文字により、ユーザ名から分離されていてもよい。
【００２２】
本発明の一実施形態によれば、ウェブ・サービスはFTPであり、ドメイン名フレーズは「user%domain」または「domain%user」であり、ここで「user」はユーザ名、「domain」はドメイン名、そして「%」は非許容文字である。
【００２３】
本発明の他の実施形態によれば、ウェブ・サービスはPOP3であり、ドメイン名フレーズは「user%domain」または「domain%user」であり、ここで「user」はユーザ名、「domain」はドメイン名、そして「%」は非許容文字である。
【００２４】
ウェブ・サービスは、HTTP、FTP、POP3、SMTP、MIRC（チャットを利用するための代表的なソフトウェア）、Telnet、SSH、Rtelnet、およびShellであっても良い。
【００２５】
各ウェブ・ドメインは、異なった仮想専用サーバを参照しても良い。
【００２６】
コンピュータ・システムは、Unix（登録商標）ベースのシステムであっても良く、Unix（登録商標）、Solaris（登録商標）、Linux（登録商標）（Red Hat（登録商標）、Debian（登録商標）、SuSE（登録商標）、FreeBSD（登録商標）等）、AIX、HP（登録商標）/UX、Tru64、およびIrix（登録商標）のいずれの亜種でも良い。
【００２７】
本発明の一実施形態によれば、一部のサーバまたは全サーバをハード・リンク（hard link）で置き換えることが可能である。
【００２８】
本発明の他の様態は、単一IPアドレスを介してコンピュータによりホストされている複数のウェブ・ドメインにより、ウェブ・サービスをクライアントに提供するシステムに係り、以下からなる。
【００２９】
各ドメインにつき、サービスを提供するサーバと、
【００３０】
クライアントとの通信が専用プロトコルを介して行われ、サーバとの通信が標準プロトコルにより行われるように、クライアントとサーバの間を仲介するラッパーとである。
【発明を実施するための最良の形態】
【００３１】
以下、図面を参照しながら、本発明の実施形態について説明する。
【００３２】
本明細書において、実施例は、一般性を失うことなく、Solaris（登録商標）、Linux（登録商標）（Red Hat（登録商標）、Debian（登録商標）、SuSE（登録商標）、FreeBSD（登録商標）等）、AIX、HP（登録商標）/UX、Tru64、Irix（登録商標）等のUnix（登録商標）ベースのオペレーティング・システムに係る。
【００３３】
クライアント／サーバとは、一方のプログラムであるクライアントが、他方のプログラムであるサーバからのサービスを要求して、サーバーが要求を満たすという、2つのコンピュータ・プログラムの間にある関係を言う。クライアント／サーバの関係は、単一コンピュータ内のプログラムによっても使用できるが、ネットワークにおいてより役立つ。ネットワークにおいて、クライアント／サーバ・モデルは効率的に別々の位置に渡って分配されているプログラムを互いに接続させる便利な方式を提供する。クライアント／サーバ・モデルはネットワーク・コンピューティングの中心思想になった。通常、TCP/IPプロトコルに基づくインターネットの主要プログラムの他に、近年作成されているビジネス・アプリケーションの殆どがクライアント／サーバ・モデルを使用している。
【００３４】
IPアドレスに関連するクライアント・プロセスが、実際にウェブサーバと通信する。ウェブサーバは、クライアント／サーバ・モデルを使用し、そのサービスの要求に対して「サービスを提供する」プログラムである。ウェブサイトを含有するインターネット上のコンピュータは全てウェブ・サーバ・プログラムを有する必要がある。一方では、大規模のウェブサイトが別々の地理的位置において複数のサーバ上に展開される場合もある。他方では、1台のウェブサーバが、複数のウェブサイトをホスト（提供）する場合もある。
【００３５】
ウェブに対して、ウェブサーバは、要求されたHTMLページまたはファイルを提供するコンピュータプログラムである。ウェブクライアントは、ユーザに関連している要求側プログラムである。ユーザのコンピュータ内のウェブ ブラウザは、ウェブサーバからHTMLファイルを要求するクライアントである。
【００３６】
通常のクライアント／サーバ・モデルでは、一つのサーバが起動しており、クライアント要求を待ち受ける。このサーバは、デーモンと呼ばれることがある。一般に、多数のクライアント・プログラムが共通のサーバ・プログラムのサービスを共用する。クライアント・プログラムとサーバ・プログラムの両方が、より大規模のプログラムまたはアプリケーションの一部であることはよくある。インターネットに対して、ウェブ ブラウザは、インターネット上の何所かにある別のコンピュータ内のウェブサーバ（技術的には、ハイパーテキスト転送プロトコルまたはハイパーテキスト転送プロトコルサーバという）からサービス（ウェブページまたはファイルの送信）を要求するクライアント・プログラムである。同様に、TCP/IPがインストールされているコンピュータは、インターネット上の他のコンピュータ内のFTP（ファイル転送プロトコル）サーバから、ファイルのクライアント要求を開始するのに適合している。
【００３７】
デーモンとは、受信要求を待ち受け、適時、他のプロセスへ転送するプロセスである。ウェブ上では、各サーバは、ウェブの他の場所から要求が着信するのを随行して待つHTTPD（ハイパーテキスト・転送プロトコル・デーモン）を有する。
【００３８】
本明細書においてソケットという用語は、TCP/IPネットワークを介してデータをアプリケーションへ向ける設備（仕組み）のことをいう。ステーション（コンピュータ）のIPアドレスとポート番号の組み合わせにより、ソケットが決定される。第1のコンピュータは、データを第2のコンピュータへ送信するために、データをソケットに書き込む。そして、第2のコンピュータは、データをそのソケットから読み取る。これは電話の呼出と同様に説明できる。電話の加入者と話すには、その電話番号（本例ではIPアドレス）、次いで、内線番号（ポート番号）をダイヤルする必要がある。接続が確立した後、受話器（ソケット）に向かって話し、相手は自分の受話器（ソケット）から聞き取る。
【００３９】
本明細書において公知のポートとは、ネットワーク上において一定のタイプのデータに幅広く使用されているプロトコル・ポートのことをいう。例えば、HTTPには通常、ポート80が割り当てられ、FTP転送は、ポート21であり、POP3はポート番号110、およびX-Windows（登録商標）は6000である。本明細書において「優先ポート」とは、1から1023の番号を振り付けたプロトコル・ポートのことをいう。
【００４０】
Unix（登録商標）ベースのオペレーティング・システムにおいて、FTPサーバは、公知のポートを介して通信セッションを行うプロセスである。通信セッション中、FTPサーバは、RFC 959に定義される司令（コマンド）を実行する。RFC（Request For Comment、コメントの要求）は、Internet Engineering Task Force（IETF、インターネット・エンジニアリング・タスク・フォース）からの正式な文書であり、委員会の草案、および関係者によるその後の改訂の結果である。
【００４１】
通常最初に実行されるべき２つの司令は、FTPサーバへのユーザ名およびそのパスワードを確認するために使用される「USER」司令および「PASS」司令である。ユーザ確認は、ファイルのダウンロードまたはアップロードなどのFTPサーバに対する次なる司令の前に行われる。
【００４２】
FTPサーバは、コンピュータのユーザ名およびパスワード（Unix（登録商標）ベースのシステムでは「/etc/passwd」にある）を使用して、名前およびパスワードを認証し、一致する場合、ユーザは、ファイルシステム上の特定のユーザ許可（パーミッション）に従ってファイルへアクセスすることを許可される。当然、他のいずれの安全機構を使用することもでき、本明細書においては簡潔にするためにこの方式のみを記述した。
【００４３】
Inetd（InternET Daemon , インターネット・デーモン）は、通常のTCP/IPサービスを管理するUnix（登録商標）機能である。Inetdは、スタートアップ時に起動し、各種接続要求（FTP、Telnet等）を待ち受け、適当なサーバ構成要素（コンポーネント）を起動する。
【００４４】
従来の技術によれば、FTPサーバまたは他のいずれのインターネットサーバは、以下の２つのモードで起動される。
【００４５】
一つは、単一プロセス（Inetdデーモン）が複数のネットワーク・サービスを提供する「Inetd」モードである。このデーモンは、接続要求を待ち受けながら特定のポートを「聞き取っている」。接続要求が着信すると、サービス・プロセス（公知のポートに従い）を作成し、それが通信セッションを処理できるようにする。
【００４６】
このアプローチの利点は、複数のプロセスの代りに単一プロセスがポートを聞き取っているため、システム・リソースを節約できるところにある。
【００４７】
もう一つは、「スタンド・アロン」モードであり、関連するプロセスが一回（例えば、システム・ブート時に）作成され、そのプロセスが接続を扱う。このモードは、通常、常に活動中（利用可能）のサービスであって、接続（コネクション）が着信する毎にプロセスを開始したり終了すると不必要なオーバーヘッドになってしまうサービスに適している。
【００４８】
通常、HTTPサーバは、スタンド・アローン・モードで操作するが、一方、FTPサーバ、POP3サーバ、およびSMTPサーバは「Inetd」モードである。
【００４９】
〔名前ベースのFTPおよび電子メールの問題〕
【００５０】
RFC 959に記述のとおり、FTPの元の設計では、司令に対象ドメインが含まれているHTTPサービスとは異なり、FTPは、1つのIPアドレスに関連する1つのドメインのサービスを提供するように向けられている。従って、例えば、ftp.aaa.comおよびftp.bbb.comの２つのドメインが同じホスト・コンピュータ上に存在して同じIPアドレスを共有している場合、ユーザxxx@ftp.aaa.comとユーザxxx@ftp.bbb.comは同一である。また、ユーザが「ftp.aaa.com/pub/」にアクセスを試みると、「ftp.bbb.com/pub/」と同様のディレクトリに達することになる。
【００５１】
当業者は、ftp.aaa.comおよびftp.bbb.comの特定のサブディレクトリを定義し、各ドメインのユーザが他のディレクトリにアクセスするのを防ぐことにより、この問題に対して部分的な解決法を決定し得る。しかしながら、このようなアプローチには実質的に複数の問題がある。
【００５２】
ユーザは、もう一つのディレクトリがあることを意識しているが、アクセスできない。このことは、各ドメインが同じホスト・コンピュータ上にある他のドメインの存在を意識しない方が望ましいので、ウェブ・ホスティング会社にとっては不利であり得る。
【００５３】
ホスト・コンピュータ上において、特定の名前のユーザは一人のみ（上記の例では「xxx」）しか存在できないので、共通の名前（「webmaster」、「jobs」、「info」等）を複数のドメインに割り当てることができない。この解決法を支援するには、システムは、各ドメインのユーザを個別の場所に保つべきであることに注意すべきである。例えば、同時係属中のイスラエル特許出願第147560号に記述のVDS技術は、そのような解決法である。
【００５４】
ホスト・コンピュータによりホスト（提供）されている全てのドメインに対して一つのFTPサーバが使用される。したがって、プロセス・リソースが共有されているので、１つのドメインによるリソースの消費を計算するための自明な方法はない。
【００５５】
ファイルのアクセス許可を変更することにより、ファイルが、「cookie」ユーザなど他のユーザによりアクセス可能になってしまう。
【００５６】
〔解決法〕
【００５７】
実際、上記問題の基本となるのは単一のコンピュータから複数のドメインへFTPサービスを提供するのに適していないプロトコルである。同様の問題がメール・サービスにも関連する。プロトコルにおける制限により、サービスのプロバイダも限られている。
【００５８】
「欠落」ドメインの問題は、POP3のみに当てはまる。SMTPにおいては、ドメインも渡されるため、FTPのようにドメインをユーザ名に追加する必要はない。しかしながら、妥当なサーバ、即ち、適当なVDSのサーバは、要求に対応するためにラッパー（wrapper）が常に必要である。
【００５９】
本明細書に開示する解決法によれば、通信の連鎖において、クライアントとサーバの間に仲介者が追加される。仲介者の役割は、サービス要求において要求されるドメインを認識し、そのサーバへ標準的な形式で要求を転送することである。
【００６０】
よって、仲介者は、あたかもサービス・プロバイダであるかのようにクライアントと相互作用すると共に、クライアントであるかのようにサービス・プロバイダと相互作用する。
【００６１】
実際、ドメインが確認された後、クライアントは、要求されたドメインに関連するサービス・プロバイダと直接に、即ち、いかなる仲介もなく相互作用できる。
【００６２】
〔独立ユーザ名付けシステム〕
【００６３】
従来の技術によれば、domainl.com、domain2.com、等のドメインをホスト（提供）するホスト・コンピュータは、例えばsysadminという名前のユーザを2人、またはそれ以上有することはできない。
【００６４】
本発明の一実施形態によれば、ホスト・コンピュータ・システム上においてホスト（提供）されている各ドメインの独立ユーザ名付けシステムを可能とするため、ドメイン名は、ユーザ名に組込まれている。前記例においては、ユーザーは、ユーザ名、即ちxxxの代りに、xxx%aaa.com、xxx%bbb.com、等で身元を明らかにする。
【００６５】
具体的に、標準のFTPプロトコルに従って「USER」司令（コマンド）を発行した時、ユーザは、ドメインが組込まれた名前で身元を明らかにする。これは本例によるとUSERNAM%DOMAIN、即ち、ユーザ名に「%」およびドメイン名が後続するものである。
【００６６】
当然、この構文は、RFC 959に定義されているFTPの標準プロトコルに適合しないので、以降説明するような追加ステップを行うべきである。
【００６７】
〔1つのコンピュータ・システムによって複数のドメインをホスト（提供）する〕
【００６８】
本発明の一実施形態によれば、この形式をサポートするためにFTP処理を変更する。
【００６９】
本発明の他の実施形態によれば、通信部分を扱う構成要素（コンポーネント）が通信の連鎖に追加される。この構成要素は、ユーザが確認されると、第三者（サード・パーティ）のFTPサーバ（即ち、コンピュータの所有者は、任意のFTPサーバを使用することができる。例えば、オープンソース、市販、または自家製のものであってもよい）への接続を担当する。
【００７０】
簡略にするため、この構成要素がプロセスであると仮定する。このプロセスは、以降FTPラッパーまたはラッパーという。
【００７１】
FTPポートへの接続がホスト・コンピュータに着信すると、デーモンは、FTPラッパー・プロセスを作成する。FTPラッパーは、FTPサーバとしてクライアントと「交渉」し、即ち、クライアントから司令を受けとり、FTPサーバとしてクライアントへ返答を中継する。交渉はクライアントが「USER」司令を発信するまで続く。
【００７２】
ユーザがFTPサーバにログインする前には司令の殆どがサポートされないため、ラッパーは、FTP司令のサブセットのみをサポートしてもよいことに注意すべきである。FTPラッパーが一旦「USER」司令を受信すると、FTPラッパーは、それ（「USER」指令）がユーザ名および有効なドメイン名を含んでいることを確認し、そのドメイン用のFTPサーバを起動する。
【００７３】
より改善した性能を達成するために、ラッパーをデーモンと統合し、各接続毎のラッパー・プロセスの作成を不要としてもよいことに注意すべきである。
【００７４】
元のFTPサーバが一旦作成されると、FTPサーバは、「USER」司令、およびユーザが発信した、いずれの司令も含め、最初から通信を受けることとなる。
【００７５】
本発明の一実施形態によれば、ラッパー・プロセスは、FTPセッション全体において、活動を保っている（起動している）。よって、ラッパー・プロセスは、クライアントとFTPサーバの間のインターフェイスとして機能する。即ち、サービス要求は全てFTPサーバに渡され、サーバからの結果はいずれもクライアントに渡される。
【００７６】
共用ライブラリ（Shared library、また、Windows（登録商標）オペレーティング・システムではDLLという）は、機能（関数）の寄せ集めであって、当該機能（関数）は、通常特定の課題に関連し、実行時に全てのプロセスによりアクセス可能な独立ファイルに保管されている。
【００７７】
本発明の好ましき実施形態によれば、上記問題の解決法は、Unix（登録商標）ベースのプロセスの大半が共用ライブラリにリンクされていることに基づく。このアプローチには以下の利点がある。
【００７８】
共用機能（関数）はプロセス自体の一部ではないので、各プロセスは小規模である。これにより、プログラムを保存するためにも、かつプログラムを分散するためにも、より少量のディスク空き領域で足りる。
【００７９】
オペレーティング・システムは、ライブラリの単一コピーをメモリに取り込み、多数のプロセスに対してそれ（ライブラリの単一コピー）を使用できるので、共用ライブラリを使用する多数のプロセスに要するメモリの量は、共用ライブラリなしで実行する同プロセスに要する量より少ない。
【００８０】
既存の機能に新しい特性を含めたり、バグを修正したり、セキュリティ・ホールを修正するためには、新しいバージョンの機能（関数）を開発することになる。新しいバージョンの機能を共用ライブラリ内に据え付けると、実行時に取り込まれるプロセスは、新しいバージョンの機能を参照するが、他のプロセスは新しいバージョンの機能（関数）を参照しない。
【００８１】
本発明の一実施形態によれば、元のソケット・ライブラリの当該機能と置き換わる新しい共用ライブラリが実行されるが、元のソケット・ライブラリは、後で使用するために保管される。新しい共用ライブラリの機能は、ある追加操作（元の機能にはないもの）を行った後、元のライブラリにおける同名の機能（関数）を実行する。
【００８２】
この機構は従来の技術において公知であり、フッキングという。フックとは、追加特性など、パッケージ化されたコード内に提供される場所（通常インターフェイス）であって、プログラマーがカスタマイズしたプログラミングを挿入できる場所である。
【００８３】
本発明の一実施形態によれば、フッキングは以下の通り実行する。
【００８４】
クライアントから受信した情報を一時的に保持するためのバッファが各ソケットに提供される。
【００８５】
操作中に、バッファが空でない場合、「読み取り」司令は、このバッファからデータを読み取り、バッファが空の場合、「読み取り」司令は、ソケットからデータを検索する。
【００８６】
「読み取り」バッファが空になるまで、いずれの「書き込み」司令もデータを無視する。その後、情報は全てソケットへ転送される。ライブラリを使用しているプロセスが「書き込み」司令を行う場合、ライブラリは常に内部バッファのステータスを確認する。内部バッファに何らかの情報がある場合、この情報がラッパーにより既に扱われたものであるため、「書き込み」司令に渡された情報は無視され、「成功」ステータスが呼び出し側に戻される。内部バッファ内に更なるデータが存在しない場合、情報は通常のソケット・ライブラリに渡される。
【００８７】
本発明の好ましき実施形態によれば、共用ライブラリとしてソケット・ライブラリ機能の特殊バージョンが提供される。ラッパー・プロセスは、このライブラリを参照する。ソケット・ライブラリの特殊バージョンは、ソケットに送信したデータまたはソケットから受信したデータをバッファに書き込む。一旦「USER」司令を受信すると、FTPラッパー・プロセスは、FTPプロセスを作成する。この時点以降、FTPサーバは、FTPラッパーの仲介なしで直接にクライアントと通信する。即ち、ライブラリの特殊バージョンの機能ではなく元の機能が呼び出される。これにより、僅かなオーバーヘッドが発生する。
【００８８】
〔FTPセッション〕
【００８９】
図1は、本発明の一実施形態による代表的なFTPセッションを図示する概略図である。
【００９０】
ステップ1では、クライアントは、ホスト・コンピュータのFTPポートに接続する。Inetdは、要求を受信し、ポート（即ち、クライアントとの通信チャンネル）を開く。
【００９１】
ステップ2では、一旦クライアントとの通信チャンネルが確立されたら、「USER」司令以外のFTP司令は、いずれも「USER」司令が着信まで処理されずバッファに保存される（但し、クライアントが通信を終了しないように適当な返信／応答がクライアントに送信される）。
【００９２】
ステップ3では、「USER xxx%aaa.com」司令が受信される。FTPプロセスに関連のある司令のみ、即ち「USER xxx」が前述のバッファに保存される。
【００９３】
ステップ4では、aaa.comドメイン用にFTPプロセスが作成される。
【００９４】
ステップ5では、ラッパーがプロセス（機能ではなく）である場合、ラッパーの実行は終了する。ステップ1乃至5のセッションが、従来の技術のようにクライアントとFTPサーバの間ではなく、クライアントとInetdの間で、またはラッパーにより行われたことに注意すべきである。
【００９５】
ステップ6では、FTPプロセスは、前述のバッファに保存された司令を受信する。実際、FTPサーバは、クライアントとではなく、ラッパー（あるいはラッパーがバッファ内に保持した情報）と通信するが、FTPサーバはこのことを「意識」していない。この時点以降、クライアントは、従来の技術の如くFTPサーバと通信する。
【００９６】
ステップ7では、認証のためクライアントからFTPサーバにPASS司令が送信される。
【００９７】
ステップ8では、FTPサーバによりパスワードが認証された後、クライアントは、ダウンロード、アップロード、消去、等のFTPサーバにより実行されるファイル関連の司令を送信することができる。パスワードの確認が、ラッパーではなくFTPサーバにより対応されていることに注意すべきである。したがって、ユーザが、そのFTPサーバに特殊な認証モジュールをインストールしたり、ログインが失敗した際に特別な動作が実行されることを好む場合、これらの操作はいずれにしても行われることになる。
【００９８】
〔本発明を他のウェブ・サービスに適用する〕
【００９９】
ウェブ・メール・サービスでは、インターネットに接続された任意のコンピュータから新しい電子メールを表示し、返答することができる。電子メール・メッセージは、ユーザが自分のホーム・コンピュータから再度メールを確認するまでメール・サーバ上に残る。
【０１００】
POP（Post Office Protocol、ポスト・オフィス・プロトコル）では、メールはウェブを介してアクセス可能なサーバに配達され、パーソナル・コンピュータのユーザが周期的にサーバに接続し、全ての未通知メール（メール・サーバに残されているメール）を「クライアント」機にダウンロードする。その後、メールの処理はクライアント機において局所的なものになる。
【０１０１】
SMTP（Simple Mail Transfer Protocol、単純メール転送プロトコル）は、インターネット上において、標準の電子メールプロトコルである。SMTPサーバは、インターネットを通じてSMTPメッセージをPOP3またはIMAP4など、着信メールのメッセージを蓄えるメールサーバへ配達する。
【０１０２】
ウェブ・メール・プロトコルは、FTPプロトコルと同様に、ユーザを認証することによりユーザへのサービス提供を制限していて、これは通常ユーザ名およびパスワードにより行われる。ユーザは通常ホスト・コンピュータ上のアカウントに属するため、このようなサービスの提供は、FTPと同様に導入することが可能である。
【０１０３】
HTTP（HyperText Transport Protocol、ハイパーテキスト転送プロトコル）は、ワールド・ワイド・ウェブ上のサーバに接続するために使用される通信プロトコルである。その主な機能は、ウェブサーバとの接続を確立し、HTMLページをクライアントのブラウザに転送することである。ウェブサイトのアドレスは「http://」の接頭部で始まる。
【０１０４】
HTTPでは、「仮想ホステイング」という公知の解決法がある。この技法を使用することにより、HTTPサーバは、（司令内の特殊な行から）ユーザがアクセスを望んでいるドメインを検出することができ、したがって各ドメインの別のディレクトリ・ツリーへアクセスすることができる。しかしながら、この解決法は、ドメインの間で同じウェブサーバを共有することを前提としている。したがって、この解決法は、各ドメインに与えられるリソースを制限することに興味があり、各アカウントの実際の使用に基づいて課金するであろうウェブ・ホスティング会社には不適である。
【０１０５】
本発明の一実施形態によれば、ウェブサーバからの複数の要求が同時に実行できるので、各ドメイン（またはドメインのグループ）が自らの要求を受信できるようになる。しかしながら、コンピュータ上で一定時間に一定のポートを使用できるのは１台のウェブサーバのみであり、その時間活動していていられるウェブサーバは１台のみである。
【０１０６】
この制限は、データを元のソケットから、一定時間に複数のウェブサーバにより実際にアクセス可能な「内部」ソケットにパイプする（プロセス間通信方式の一つで、あるプログラムの出力を、別のプログラムに入力する）ことにより克服することができる。
【０１０７】
よって、本発明はHTTPサービス並びにFTPおよびメールにも適用し得る。従来の技術において使用される仮想ホステイング方法、即ち、ウェブサーバにより提供される仮想ホステイング能力を導入することにより、全てのドメインのサービスが単一のウェブサーバにより提供される。しかしながら、本発明によれば、複数のウェブサーバが同時に稼動し、各ウェブサーバがドメインの一部のサービスを提供することができる。したがって、WHP（Web Hosting Provider）は、提供するウェブサイトの性能を改善することができる。
【０１０８】
接続要求を受信して、要求ドメインを読み取り、情報を有するソケットをウェブサーバに渡すことは、サーバにとって透過的であることに注意すべきである。
【０１０９】
上記実施例および説明は当然例示を目的としてのみ提供されたものであり、本発明は、MIRC、Telnet、SSH、Rtelnet、およびShellを含め、任意のウェブ・サービスに導入することが可能である。
【０１１０】
これらサービスの安全なバージョン、並びに他のいずれの安全なサービスも類似したアプローチにより導入することができる。しかしながら、安全なサービスは、通常各ドメイン毎に異なった暗号化キーを使用するので導入は容易ではない。 このキーは、許可されていないコンピュータが情報にアクセスするのを防止するため、並びに情報が送信されるサーバを認証するために使用される。安全なサービスに対して同様のアプローチを導入するための解決法として次の方法が可能である。
【０１１１】
各サーバ上の、全ドメインに同一のキーを使用すること。
【０１１２】
標的ドメインに関する情報の一部をクリア（即ち、暗号化されていない）テキストに含むようにプロトコルを変更すること。
【０１１３】
全てのドメインキーを使用して、メッセージの復号化を試みること。一旦メッセージが復号化されると、ラッパーは、メッセージを標的ドメイン（メッセージの復号化が行われたキーにより決定される）に渡すことができる。
【０１１４】
〔名前ベースのVDS〕
【０１１５】
同時係属中のイスラエル特許出願第147560によると、リモートクライアントがそのシステム・ユーティリティおよびプログラムにアクセスできるコンピュータ・システムのエミュレーションを仮想専用サーバ（Virtual Dedicated Server、VDS）という。該特許出願によると、複数のVDSインスタンスが同時に１台のコンピュータ・システム上で実行され、各VDSインスタンスはルート・ディレクトリとして別々のディレクトリ・ツリーを参照することができる。
【０１１６】
VDS技術を使用すると、FTPサーバは、各ドメインに別々の「/etc/passwd」を使用することができる。その結果、各ドメインにつき異なった許可されたユーザの組ができる（複数のドメイン内に同じユーザ名を含んでもよい）。
【０１１７】
本明細書に記載の技術を使用すると、複数のVDSが、VDSにより提供されるウェブ・サービスに対して単一のIPアドレスを使用することができる。
【０１１８】
図2は本発明の好ましき実施形態による1台のコンピュータ・システムによりホスト（提供）されているVDSシステムによりホスト（提供）されているウェブサーバを図示する概略図である。
【０１１９】
ホスト・コンピュータ10は、VDSシステム 60および70をホストしている。VDS 60は、FTPサーバ11およびPOP3サーバ12をホストしている。VDS 70は、POP3サーバ21、FTPサーバ22およびHTTPサーバ23をホストしている。デーモン40は、公知のFTPポート、HTTPポート、およびPOP3ポートを「聞き取っている」。クライアント30からの接続要求をデーモン40が指定すると常に、ラッパーは、ドメインが指定されるまで適当なウェブ・サーバとしてクライアント30と「交渉する」。次いで、ラッパーは、クライアントであるのかのように、適切なウェブサーバ11、12、21、22または23と交渉する。最終段階において、適当なウェブサーバとクライアントの間に、通信セッションが終了するまで接続が確立される。
【０１２０】
「適当なサーバ」は、次の2つのパラメータにより指定される。この２つのパラメータとは、サーバのタイプ（FTP、HTTP等）を指定するポート、および適当なVDSを指定するドメインである。
【０１２１】
同時係属中のイスラエル特許出願第147560号に記載の如く、システムの性能は、ハード・リンク（hard link）を使用することによって改善することが可能である。
【０１２２】
上記実施例および説明は、当然例示を目的として提供したものであり、本発明を何ら制限するものではない。本発明は、上記の技法を1つ以上用い、多数の態様により、全て本発明の請求の範囲から遺脱せず、実施出来ることは当業者に明らかであろう。
【図面の簡単な説明】
【０１２３】
【図１】本発明の一実施形態において、代表的なFTPセッションを図示する概略図である。
【図２】本発明の最良の実施形態において、一つのコンピュータ・システムがホストする（備えた）VDSシステムによりホスト（提供）されているウェブサーバを図示する概略図である。
【符号の説明】
【０１２４】
１０ ホスト・コンピュータ
１１ FTPサーバ（ウェブサーバ）
１２ POP3サーバ（ウェブサーバ）
２１ POP3サーバ（ウェブサーバ）
２２ FTPサーバ（ウェブサーバ）
２３ HTTPサーバ（ウェブサーバ）
３０ クライアント
４０ デーモン
５０ ラッパー
６０ VDSシステム
７０ VDSシステム
Claims (9)
- 単一IPアドレスを介して複数のウェブ・ドメインによりウェブ・サービスを提供する方法であって、
a)各該ドメインについて、該サービスを提供するために、一意のドメイン名を有するサーバおよび該IPアドレスを割り付け、
b)専用プロトコルを介して該サービスのクライアントと該サーバの間を仲介すると共に、標準プロトコルを介して各該サーバと通信するソフトウェア・モジュールであるラッパーを提供し、
c)該サービスを提供するために、該クライアントを該サーバの一台に接続させるための要求を受信した時に、
(i)該専用プロトコルを介して該クライアントと該ラッパーの間で相互作用することにより、該要求の標的ドメイン名を確認するステップと、
(ii)該標準プロトコルにより該ラッパーと該標的ドメイン名に関連する該サービスを提供するサーバの間で相互作用するステップと、
(iii)該サーバと該クライアントの間で通信チャンネルを確立するステップと、
(iv)該サーバが該クライアントに該サービスを提供することを許可するステップと、
を実行することを特徴とした方法。 - 該専用プロトコルがユーザ及びドメインを認識する司令を含むことを特徴とする請求項1記載の方法。
- ドメイン名が、ユーザ名において該プロトコルにより定義された1つまたは複数の非許容文字により、ユーザ名から分離されていることを特徴とする請求項2記載の方法。
- 該ウェブ・サービスがFTPであり、ドメイン名フレーズが「user%domain」または「domain%user」であり、この内「user」がユーザ名、「domain」がドメイン名、そして「%」が非許容文字であることを特徴とする請求項3記載の方法。
- 該ウェブ・サービスがHTTP、FTP、POP3、SMTP、MIRC、Telnet、SSH、RtelnetおよびShellの中から選ばれることを特徴とする請求項1記載の方法。
- 各該ウェブ・ドメインが、異なった仮想専用サーバを参照していることを特徴とする請求項1乃至5のいずれかに記載の方法。
- コンピュータ・システムが、Unix（登録商標）ベースのシステム、又はUnix（登録商標）、Solaris（登録商標）、Linux（登録商標）（Red Hat（登録商標）、Debian（登録商標）、SuSE（登録商標）、FreeBSD（登録商標）等）、AIX、HP（登録商標）/UX、Tru64、およびIrix（登録商標）のいずれかの亜種であることを特徴とする請求項1乃至6のいずれかに記載の方法。
- 該サーバの一部または全部がハード・リンクにより置き換えられていることを特徴とする請求項1記載の方法。
- 単一IPアドレスを介してコンピュータにより提供されている複数のウェブ・ドメインにより、ウェブ・サービスを提供するシステムであって、
各該ドメインにつき、該サービスを提供するサーバと、
該クライアントとの通信が専用プロトコルを介して行われ、該サーバとの通信が標準プロトコルにより行われるように、該クライアントと該サーバの間を仲介するラッパーと、
を備えたことを特徴としたシステム。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| IL145105A IL145105A (en) | 2001-08-23 | 2001-08-23 | Method and system for providing a web service by a plurality of web domains through a single ip address |
| PCT/IL2002/000695 WO2003019902A2 (en) | 2001-08-23 | 2002-08-22 | A method and system for providing a web service by a plurality of web domains sharing a single ip address |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2005501354A true JP2005501354A (ja) | 2005-01-13 |
Family
ID=11075736
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003524225A Pending JP2005501354A (ja) | 2001-08-23 | 2002-08-22 | 単一ｉｐアドレスを介して複数のウェブ・ドメインによりウェブ・サービスを提供する方法およびシステム |
Country Status (8)
| Country | Link |
|---|---|
| US (1) | US7613793B2 (ja) |
| EP (1) | EP1419637B1 (ja) |
| JP (1) | JP2005501354A (ja) |
| AT (1) | ATE366021T1 (ja) |
| AU (1) | AU2002328134A1 (ja) |
| DE (1) | DE60220926D1 (ja) |
| IL (1) | IL145105A (ja) |
| WO (1) | WO2003019902A2 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2009545274A (ja) * | 2006-07-31 | 2009-12-17 | ハリス コーポレイション | ネットワークのエッジでの動的にカスタマイズ可能なサービス品質システム及び方法 |
Families Citing this family (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB2410402B (en) * | 2004-01-23 | 2007-01-24 | Rxtxtech Ltd | A system and method for limiting simultaneous access to a network service |
| US7882317B2 (en) * | 2004-12-06 | 2011-02-01 | Microsoft Corporation | Process isolation using protection domains |
| US8020141B2 (en) | 2004-12-06 | 2011-09-13 | Microsoft Corporation | Operating-system process construction |
| US7451435B2 (en) | 2004-12-07 | 2008-11-11 | Microsoft Corporation | Self-describing artifacts and application abstractions |
| US7600232B2 (en) * | 2004-12-07 | 2009-10-06 | Microsoft Corporation | Inter-process communications employing bi-directional message conduits |
| US8417825B2 (en) * | 2005-03-09 | 2013-04-09 | Apple Inc. | Communications handles and proxy agents |
| US20060259602A1 (en) * | 2005-05-12 | 2006-11-16 | Randall Stewart | Method and apparatus for transport level server advertisement and discovery |
| US8849968B2 (en) | 2005-06-20 | 2014-09-30 | Microsoft Corporation | Secure and stable hosting of third-party extensions to web services |
| US8621078B1 (en) | 2005-08-15 | 2013-12-31 | F5 Networks, Inc. | Certificate selection for virtual host servers |
| US8074231B2 (en) * | 2005-10-26 | 2011-12-06 | Microsoft Corporation | Configuration of isolated extensions and device drivers |
| US8032898B2 (en) * | 2006-06-30 | 2011-10-04 | Microsoft Corporation | Kernel interface with categorized kernel objects |
| US8789063B2 (en) | 2007-03-30 | 2014-07-22 | Microsoft Corporation | Master and subordinate operating system kernels for heterogeneous multiprocessor systems |
| US9152293B2 (en) * | 2010-12-09 | 2015-10-06 | Verizon Patent And Licensing Inc. | Server IP addressing in a computing-on-demand system |
| CN114499965B (zh) * | 2021-12-27 | 2023-07-07 | 北京安博通科技股份有限公司 | 一种基于pop3协议的上网认证方法及系统 |
Family Cites Families (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5898830A (en) * | 1996-10-17 | 1999-04-27 | Network Engineering Software | Firewall providing enhanced network security and user transparency |
| US5918018A (en) * | 1996-02-09 | 1999-06-29 | Secure Computing Corporation | System and method for achieving network separation |
| US5898780A (en) * | 1996-05-21 | 1999-04-27 | Gric Communications, Inc. | Method and apparatus for authorizing remote internet access |
| US7137006B1 (en) * | 1999-09-24 | 2006-11-14 | Citicorp Development Center, Inc. | Method and system for single sign-on user access to multiple web servers |
| US7237036B2 (en) * | 1997-10-14 | 2007-06-26 | Alacritech, Inc. | Fast-path apparatus for receiving data corresponding a TCP connection |
| US7299294B1 (en) * | 1999-11-10 | 2007-11-20 | Emc Corporation | Distributed traffic controller for network data |
| US6466977B1 (en) * | 1999-05-06 | 2002-10-15 | Cisco Technology, Inc. | Proxy on demand |
| US6430619B1 (en) * | 1999-05-06 | 2002-08-06 | Cisco Technology, Inc. | Virtual private data network session count limitation |
| US6976258B1 (en) * | 1999-11-30 | 2005-12-13 | Ensim Corporation | Providing quality of service guarantees to virtual hosts |
| US6948003B1 (en) * | 2000-03-15 | 2005-09-20 | Ensim Corporation | Enabling a service provider to provide intranet services |
| WO2002001416A2 (en) * | 2000-06-23 | 2002-01-03 | The Johns Hopkins University | Architecture for distributed database information access |
| US7010582B1 (en) * | 2000-06-26 | 2006-03-07 | Entrust Limited | Systems and methods providing interactions between multiple servers and an end use device |
| US7110393B1 (en) * | 2001-02-28 | 2006-09-19 | 3Com Corporation | System and method for providing user mobility handling in a network telephony system |
| US6999912B2 (en) * | 2001-03-13 | 2006-02-14 | Microsoft Corporation | Provisioning computing services via an on-line networked computing environment |
| US7174390B2 (en) * | 2001-04-20 | 2007-02-06 | Egenera, Inc. | Address resolution protocol system and method in a virtual network |
| US7035942B2 (en) * | 2002-09-17 | 2006-04-25 | Bellsouth Intellectual Property Corp. | Server-based message protocol translation |
-
2001
- 2001-08-23 IL IL145105A patent/IL145105A/en not_active IP Right Cessation
-
2002
- 2002-08-22 JP JP2003524225A patent/JP2005501354A/ja active Pending
- 2002-08-22 AU AU2002328134A patent/AU2002328134A1/en not_active Abandoned
- 2002-08-22 WO PCT/IL2002/000695 patent/WO2003019902A2/en active IP Right Grant
- 2002-08-22 DE DE60220926T patent/DE60220926D1/de not_active Expired - Lifetime
- 2002-08-22 EP EP02762738A patent/EP1419637B1/en not_active Expired - Lifetime
- 2002-08-22 AT AT02762738T patent/ATE366021T1/de not_active IP Right Cessation
-
2004
- 2004-02-23 US US10/784,570 patent/US7613793B2/en active Active
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2009545274A (ja) * | 2006-07-31 | 2009-12-17 | ハリス コーポレイション | ネットワークのエッジでの動的にカスタマイズ可能なサービス品質システム及び方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| DE60220926D1 (de) | 2007-08-09 |
| IL145105A0 (en) | 2002-06-30 |
| EP1419637B1 (en) | 2007-06-27 |
| IL145105A (en) | 2007-02-11 |
| ATE366021T1 (de) | 2007-07-15 |
| WO2003019902A2 (en) | 2003-03-06 |
| EP1419637A2 (en) | 2004-05-19 |
| US20040236861A1 (en) | 2004-11-25 |
| US7613793B2 (en) | 2009-11-03 |
| AU2002328134A1 (en) | 2003-03-10 |
| WO2003019902A3 (en) | 2004-03-18 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| WO2022057000A1 (zh) | 一种数据代理方法、系统及代理服务器 | |
| US8332464B2 (en) | System and method for remote network access | |
| JP4727125B2 (ja) | ファイア・ウォールを経由する安全なデュアル・チャネル通信システム及び方法 | |
| US6081900A (en) | Secure intranet access | |
| US9253193B2 (en) | Systems and methods for policy based triggering of client-authentication at directory level granularity | |
| JP4734592B2 (ja) | クライアントリダイレクトによるプライベートネットワークへの安全なアクセス提供方法およびシステム | |
| JP4782139B2 (ja) | モバイルユーザーをトランスペアレントに認証してウェブサービスにアクセスする方法及びシステム | |
| US8533453B2 (en) | Method and system for configuring a server and dynamically loading SSL information | |
| US7925693B2 (en) | NAT access control with IPSec | |
| US20050273849A1 (en) | Network access using secure tunnel | |
| US20030120680A1 (en) | Method for directly providing content and services via a computer network | |
| JP5239341B2 (ja) | ゲートウェイ、中継方法及びプログラム | |
| CN104270379A (zh) | 基于传输控制协议的https 代理转发方法及装置 | |
| US7613793B2 (en) | Method and system for providing a web service by a plurality of web domains through a single IP address | |
| WO2012097728A1 (zh) | 一种开放平台代理访问方法及装置 | |
| US20050160160A1 (en) | Method and system for unified session control of multiple management servers on network appliances | |
| JP2010272951A (ja) | 共有鍵配信管理方法及び共有鍵配信管理サーバー | |
| KR101642665B1 (ko) | 다이렉트 전자 메일 | |
| US11797289B2 (en) | Containerized, decentralized, and distributed web applications with end-to-end encryption | |
| GB2496380A (en) | Private cloud server and client architecture using e-mail/SMS to establish communication | |
| Kaminsky et al. | REX: Secure, Extensible Remote Execution. | |
| JP4878043B2 (ja) | アクセス制御システム、接続制御装置および接続制御方法 | |
| Boyce | Linux networking cookbook | |
| CN106452896A (zh) | 一种实现虚拟专网平台的方法及系统 | |
| Ashley et al. | Securing Applications with the GSS-API |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050822 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050822 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070219 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20070508 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20070515 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20071011 |