プライマリ・コンテンツに移動
Oracle® Database Net Services管理者ガイド
11gリリース2 (11.2)
B56288-05
  ドキュメント・ライブラリへ移動
ライブラリ
製品リストへ移動
製品
目次へ移動
目次
索引へ移動
索引

前
 
次
 

4 通信レイヤーの理解

Oracle Netの主要な機能は、クライアント・アプリケーションとOracle Databaseサーバー間の接続を確立して維持することです。Oracle Netは複数の通信レイヤーで構成されており、クライアントとデータベース・サーバーはデータの共有、変更、操作が可能です。

この章の内容は、次のとおりです。


関連項目:

Oracle Netアーキテクチャの予備的な説明は、第1章「Oracle Net Servicesの概要」を参照してください。

クライアント/サーバー・アプリケーションのOracle Netスタック通信の理解

データベース・サーバーとはデータベースを管理するOracleソフトウェアであり、クライアントはサーバーに情報を要求するアプリケーションです。クライアントとサーバーが通信する方法をクライアント/サーバー・スタックと呼びます。

ネットワーク・プロトコルを通じてクライアント・アプリケーションから渡された情報(クライアント通信スタックによって送信されたもの)は、データベース・サーバー側にある同様の通信スタックで受信されます。データベース・サーバー側でのプロセス・フローは、クライアント側でのプロセス・フローの逆になり、情報は通信レイヤーを通ってさかのぼります。

図4-1では、接続が確立された後のクライアントとデータベース・サーバーの様々なレイヤーを示します。

図4-1 クライアント/サーバー・アプリケーション接続で使用するレイヤー

図4-1の説明が続きます。
「図4-1 クライアント/サーバー・アプリケーション接続で使用するレイヤー」の説明

この通信アーキテクチャは、Open Systems Interconnection (OSI)モデルに基づいています。OSIモデルでは、いくつかのコード・レイヤーを介して一方のノードから他方のノードへ情報を渡す、スタックのような形式でコンピュータ間の通信が行われます。次のレイヤーがあります。

  1. 物理レイヤー

  2. データ・リンク・レイヤー

  3. ネットワーク・レイヤー

  4. トランスポート・レイヤー

  5. セッション・レイヤー

  6. プレゼンテーション・レイヤー

  7. アプリケーション・レイヤー

図4-2では、Oracle Net FoundationレイヤーとOracle Protocol Supportで構成されるOracle Netソフトウェアが、OSIモデルのセッション・レイヤーにどのように適合しているかを示します。

図4-2 OSI通信レイヤー

図4-2の説明が続きます。
「図4-2 OSI通信レイヤー」の説明


関連項目:

OSIスタックの詳細は、次のURLを参照してください。

http://www.ietf.org


この項で説明する項目は、次のとおりです。

クライアント通信スタックの理解

クライアント通信スタックには次のものが含まれています。

クライアント・アプリケーション・レイヤー

データベースとのセッション時、クライアントはOracle Call Interface(OCI)を使用して、データベース・サーバーとの対話型操作を実行します。OCIは、アプリケーションとSQL間のインタフェースを提供するソフトウェア・コンポーネントです。


関連項目:

『Oracle Call Interfaceプログラマーズ・ガイド』

プレゼンテーション・レイヤー

クライアントとデータベース・サーバーが異なるオペレーティング・システムで実行されている場合、キャラクタ・セットの相違が発生します。プレゼンテーション・レイヤーによって、すべての相違が解決されます。接続ごとに最適化され、必要に応じて変換が実行されます。

クライアント/サーバー・アプリケーションが使用するプレゼンテーション・レイヤーは、Two-Task Common(TTC)です。TTCは、クライアントとデータベース・サーバー間のキャラクタ・セットの相違または形式の相違に対して、キャラクタ・セットとデータ型の変換を行います。初期の接続時に、TTCは内部データとキャラクタ・セットの表現の違いを評価したり、2つのコンピュータが通信するために変換が必要かどうかを判断します。

Oracle Net Foundationレイヤー

Oracle Net Foundationレイヤーは、クライアント・アプリケーションとデータベース・サーバー間でのメッセージの交換に加え、これらの間の接続を確立および維持します。Oracle Net Foundationレイヤーは、Transparent Network Substrate (TNS)テクノロジによってこれらのタスクを実行できます。TNSは、すべての業界標準OSIトランスポート・プロトコルおよびネットワーク・レイヤー・プロトコルに単一の共通インタフェースを提供します。TNSによって、ピアツーピア・アプリケーション接続が可能になります。複数のコンピュータが相互に直接通信でき、中間デバイスは必要ありません。

クライアント側で、Oracle Net Foundationレイヤーは、クライアント・アプリケーション要求を受け取り、すべての一般的なコンピュータ・レベルの接続性の問題を解決します。次のような問題があります。

  • データベース・サーバーや接続先の場所

  • 接続に含まれるプロトコルの数

  • それぞれの機能に基づいた、クライアントとデータベース・サーバー間の中断の処理方法

サーバー側で、Oracle Net Foundationレイヤーはクライアント側と同じタスクを実行します。また、リスナーとともに機能して着信接続要求を受信します。

接続の確立と維持に加えて、Oracle Net Foundationレイヤーは、ネーミング・メソッドを使用して通信し名前を解決します。また、セキュリティ・サービスを使用して安全な接続を実現します。

Oracle protocol supportレイヤー

Oracle protocol supportレイヤーは、Oracle Net Foundationレイヤーの最下位に位置します。これは、クライアント/サーバー接続で使用される業界標準のプロトコルにTNS機能をマッピングする役割を担います。このレイヤーは次のネットワーク・プロトコルをサポートしています。

  • TCP/IP(IPv4およびIPv6)

  • SSL付きTCP/IP

  • Named Pipes

  • Sockets Direct Protocol(SDP)

クライアント/サーバー接続の際、すべてのOracleソフトウェアは、トランスポート・レイヤーの2台のコンピュータ間のコンピュータ・レベルの接続を確立するために、既存のネットワーク・プロトコル・スタックが必要です。ネットワーク・プロトコルは、クライアント・コンピュータからデータベース・サーバー・コンピュータまで、データを送る役割があります。ここで、データはサーバー側のOracle protocol supportレイヤーに渡されます。


関連項目:

プロトコルの説明は、「Oracle protocol supportレイヤーの理解」を参照してください。

サーバー通信スタックの理解

サーバー通信スタックはクライアント・スタックと同じレイヤーを使用しますが、例外としてデータベースはOracleプログラム・インタフェース(OPI)を使用します。OCIから送信される各文に対して、OPIは応答します。たとえば、OCIが25行のデータのフェッチを要求すると、OPIはフェッチした25行のデータをOCIに戻します。

JavaアプリケーションのOracle Netスタック通信の使用

Oracle Java Database Connectivity(JDBC)ドライバにより、JavaアプリケーションはOracle Databaseにアクセスします。Oracleには、2つのJDBCドライバが用意されています。

  • JDBC OCIドライバは、クライアント/サーバーのJavaアプリケーションによって使用されるタイプ2のJDBCドライバです。JDBC OCIドライバは、標準のクライアント/サーバー通信スタックと同様の通信スタックを使用します。JDBC OCIドライバは、JDBC起動をOCIの呼出しに変換します。変換された呼出しはOracle Netを介してOracle Databaseサーバーに送信されます。

  • JDBC Thinドライバは、Javaアプレットが使用するタイプ4のドライバです。JDBC Thinドライバは、Javaソケットを通してOracle Databaseサーバーに直接接続を確立します。JDBC Thinドライバは、JavaNetと呼ばれるOracle Net FoundationレイヤーのJava実装と、JavaTTCと呼ばれるTTCのJava実装を使用してデータベースにアクセスします。

図4-3では、JDBCドライバが使用するスタック通信レイヤーを示します。

図4-3 Javaクライアント・アプリケーションで使用するレイヤー

図4-3の説明が続きます。
「図4-3 Javaクライアント・アプリケーションで使用するレイヤー」の説明


関連項目:

『Oracle Database JDBC開発者ガイドおよびリファレンス』

WebクライアントのOracle Netスタック通信の使用

Oracle Databaseサーバーは、Webクライアントがデータベース内の機能にアクセスするためにTTC以外に使用できる、その他の多数の実装をプレゼンテーション・レイヤーに対してサポートしています。リスナーは、これを容易にするため、データベースで要求されるあらゆるプレゼンテーションの実装をサポートします。

図4-4は、Oracle DatabaseインスタンスのOracle XML DBへのHTTP接続またはFTP接続で使用するスタック通信レイヤーを示しています。WebDAV接続では、HTTPおよびFTPと同じスタック通信レイヤーが使用されます。

図4-4 Webクライアント接続に使用するレイヤー

図4-4の説明が続きます。
「図4-4 Webクライアント接続に使用するレイヤー」の説明


関連項目:

『Oracle XML DB開発者ガイド』

Oracle protocol supportレイヤーの理解

ネットワーク・プロトコルは、クライアント・コンピュータからデータベース・サーバー・コンピュータまで、データを送る役割があります。この項では、Oracle Net通信スタックのOracle Protocol Supportレイヤーで使用されるプロトコルについて説明します。内容は次のとおりです。


関連項目:

各プロトコルの設定の詳細は、『Oracle Database Net Servicesリファレンス』を参照してください。

TCP/IPプロトコル

Transmission Control Protocol/Internet Protocol (TCP/IP)は、ネットワークを介したクライアント/サーバー通信に使用される標準的な通信プロトコル・スイートです。TCPは、ホスト間のデータ交換を管理するトランスポート・プロトコルです。IPは、パケット切替えネットワークのためのネットワーク・レイヤー・プロトコルです。

Oracle Netでは、IP version 4 (IPv4)およびIP version 6 (IPv6)の2つのバージョンのIPをサポートしています。IPv6は、現在使用しているIPv4の短所に対応しています。IPv6の主な利点として、128ビット・アドレスの使用から導出される大容量のアドレス空間があります。


関連項目:

IPv6の仕様は、http://tools.ietf.org/html/rfc2460を参照してください。

IPv6アドレスの表記

Oracle Databaseでは、RFC 2732で指定されている標準のIPv6アドレス表記をサポートしています。通常、128ビットのIPアドレスは、8つのグループに分かれた4桁の16進数で表され、グループ・セパレータとしてコロン(:)が使用されます。たとえば、次のアドレスは有効なIPv6形式です。

2001:0DB8:0000:0000:0000:0000:200C:417A

アドレスの各16進数は4ビットを表すため、アドレスの各グループは16ビットを表します。次のアドレスは、2001:0DB8:0000:0000サブネットの最初と最後のホストを表します。

2001:0DB8:0000:0000:0000:0000:0000:0000
2001:0DB8:0000:0000:FFFF:FFFF:FFFF:FFFF

簡易表記では、連続するゼロのフィールドを2つのコロン(::)セパレータで圧縮できます。次のアドレスは同等の表記になります。

2001:0DB8:0:0::200C:417A
2001:0DB8::200C:417A
2001:DB8::200C:417A

関連項目:


CIDR表記

Classless Inter-Domain Routing(CIDR)は、IPアドレスをアドレスの値に関係ないサブネットにグループ化する方法です。クラスレス・ルーティングは、IPクラス・システムのアドレス空間の枯渇およびルーティング表の急増を解決するために設計されました。

CIDRは、ネットワーク内の最初のアドレスと、ネットワーク接頭辞のサイズ(10進数で表したビット数)をスラッシュ(/)で区切ることでネットワークを表します。たとえば、2001:0DB8::/32は、アドレスの最初の32ビットがネットワークを特定し、残りのビットがネットワーク内のホストを特定することを示します。

CIDRはIPv4アドレスの類似した表記を使用します。たとえば、192.168.2.1/24という表記では、アドレスの最初の24ビットはネットワーク接頭辞を表します。DBMS_NETWORK_ACL_ADMINパッケージは、アクセス制御リストを管理するためのAPIを提供し、IPv6とIPv4の両方のアドレスおよびサブネットのCIDR表記をサポートします。


関連項目:

  • DBMS_NETWORK_ACL_ADMINの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

  • RFC 4632については、http://tools.ietf.org/html/rfc4632を参照してください。


URLのIPv6アドレス

URLでは、IPv6アドレスは左括弧([)および右括弧(])文字で囲まれています。たとえば、IPv6アドレス[2001:0DB8:0:0:8:800:200C:417A]は、次のURLの一部を形成します。

http://[2001:0DB8:0:0:8:800:200C:417A]
http://[2001:0DB8:0:0:8:800:200C:417A]:80/index.html
IPv4マップ・アドレス

IPv4マップ・アドレスは、次の条件が真の場合のIPv6アドレスのサブクラスです。

  • 最初の80ビットは、標準のIPv6表記では0に設定されます。

  • 次の16ビットは、標準のIPv6表記では1に設定されます。

  • 最後の32ビットはIPv4表記で表されます。

IPv4マップ・アドレスは、IPv4専用ノードのアドレスをIPv6アドレスとして表すことができます。

例4-1は、同じIPアドレスを異なる表記で示しています。最初のアドレスは標準のIPv6表記を使用しています。2番目のアドレスは、最後の32ビットがピリオドで区切ったIPv4表記を使用しているIPv4マップ・アドレスです。最後のアドレスは、連続するゼロのフィールドを圧縮する簡易表記を使用しています。

例4-1 IPv4マップ・アドレス

0000:0000:0000:0000:0000:FFFF:C0A8:0226
0000:0000:0000:0000:0000:FFFF:192.168.2.38
::FFFF:192.168.2.38

関連項目:

IPv4マップ・アドレスの使用に関連するセキュリティの考慮事項については、http://tools.ietf.org/html/rfc4942を参照してください。

IPv6インタフェースとアドレス構成

1つのホストで、IPv4とIPv6の2つのインタフェース構成を使用できます。ホストで使用できる構成は次のとおりです。

  • IPv4インタフェースのみ。この場合、ホストはIPv4専用ホストです。

  • IPv6インタフェースのみ。この場合、ホストはIPv6専用ホストです。

  • IPv4インタフェースとIPv6インタフェースの両方。この場合、ホストはデュアル・スタック・ホストです。

1つのホストで異なるタイプのIPアドレスを使用することもできます。たとえば、ドメイン名サーバーは、デュアル・スタック・ホストをIPv4アドレスとIPv6アドレスの両方、またはIPv6アドレスのみに関連付けることができます。サポートされていないIPアドレス構成は次のとおりです。

  • IPv4専用ホストはIPv6アドレスを使用できません。

  • IPv6専用ホストはIPv4アドレスを使用できません。

図4-5は、使用できるホストとインタフェース構成を示しています。図の中央のデュアル・スタック・ホストは、IPv4を通じてIPv4ホストと通信し、IPv6を通じてIPv6ホストと通信できます。

図4-5 サポートされているホストおよびインタフェース構成

図4-5の説明が続きます。
「図4-5 サポートされているホストおよびインタフェース構成」の説明

IPv6のネットワーク接続

ホストのネットワーク接続とは、ネットワークを通じて別のホストと通信できることを意味します。たとえば、デュアル・スタック・クライアントがIPv6専用サーバーと通信する必要がある場合、ネットワークとルーターはこれらのホスト間のエンドツーエンド通信を可能にする必要があります。

クライアントまたはサーバー・ホストは次の条件を満たす場合、IPv6に対応します。

  • 構成済IPv6インタフェースがある。

  • IPv6プロトコルを使用して他のホストに接続できる。

ホストのIPv6機能は、一部はネットワーク、一部はインタフェースとアドレス構成に依存します。図4-6は、クライアント/サーバー・ネットワークにおける接続の可能性を示しています。たとえば、IPv4専用ホストはIPv4専用サーバーまたはデュアル・スタック・サーバーに接続できますが、IPv6専用サーバーには接続できません。専用サーバー・モードと共有サーバー・モードの両方がサポートされています。

図4-6 クライアント/サーバー接続

図4-6の説明が続きます。
「図4-6 クライアント/サーバー接続」の説明

表4-1は、ホストとネットワーク構成が異なるクライアント/サーバー接続に使用されるIPプロトコルをまとめたものです。

表4-1 サポートされているホストおよびネットワーク構成

クライアント IPv4専用サーバー デュアル・スタック・サーバー IPv6専用サーバー

IPv4専用クライアント

サポート対象(v4)

サポート対象(v4)

サポート対象外

デュアル・スタック・クライアント

サポート対象(v4)

サポート対象(v4、v6)

サポート対象(v6)

IPv6専用クライアント

サポート対象外

サポート対象(v6)

サポート対象


Oracle Database 11gにおけるIPv6のサポート

Oracle Database 11gのこのリリースのコンポーネントは、「IPv6のネットワーク接続」で説明した構成でIPv6をサポートしていますが、次の例外があります。

  • Oracle Real Application Clusters(Oracle RAC)およびOracle Clusterware

  • Oracle Fail Safe


関連項目:

IPv6のサポートの詳細は、各Oracle Databaseコンポーネントのマニュアルを参照してください。

SSLプロトコル付きTCP/IP

Secure Sockets Layer(SSL)プロトコル付きTCP/IPでは、クライアント上のOracleアプリケーションとリモートのOracle Databaseが、TCP/IPとSSLを介して通信できます。SSL付きTCP/IPを使用するためには、Oracle Advanced Securityが必要です。

SSLは、証明書や秘密鍵などの認証データをOracle Walletに格納します。クライアントがデータベース・サーバーと接続を開始すると、SSLは証明書を使用して両者間のハンドシェイクを実行します。ハンドシェイクの実行中、次の処理が行われます。

  • クライアントとデータベース・サーバーは、認証データ、暗号化方法およびデータ整合性タイプのセットで構成される暗号スイートについてネゴシエーションを行い、交換するメッセージに適用します。

  • 使用する構成によっては、データベース・サーバーはクライアントの公開鍵で暗号化したメッセージにサーバー自身の証明書を入れてクライアントに送信します。データベース・サーバーは、この同じメッセージを使用して、クライアントの証明書を送るように要求する場合もあります。クライアントは、それ自身の秘密鍵を使用してこのメッセージの暗号化を解除し、データベース・サーバーの証明書に認証局のシグネチャがあることを確認します。

  • 必要に応じてクライアントは、このユーザーの証明書をデータベース・サーバーに送信します。証明書によって、ユーザーの情報が正しいことと、公開鍵が実際にそのユーザーのものであることが保証されます。

データベースはこのユーザーの証明書を調べて、認証局のシグネチャがあることを確認します。


関連項目:

『Oracle Database Advanced Security管理者ガイド』

Named Pipesプロトコル

Named Pipesは、特にMicrosoft Windows LAN環境で使用することを念頭に設計されています。Named Pipesプロトコルは、分散アプリケーションを使用したクライアントとデータベース・サーバー間で、プロセス間通信を提供する高水準のインタフェースです。サーバー側のプロセスが名前付きパイプを生成し、クライアント側のプロセスが名前によってそれをオープンします。これによって互いに、一方が書き込む情報を他方が読み取ることができます。

リモートのOracle Databaseが、Named Pipesを使用したネットワーク通信をサポートするホスト・システム上で実行されている場合、Oracle Netにより、クライアント上のアプリケーションはNamed Pipesを使用してOracle Databaseと通信できるようになります。

Sockets Direct Protocol(SDP)

Sockets Direct Protocol(SDP)は、InfiniBandネットワーク・ピア間の業界標準のワイア・プロトコルです。InfiniBandネットワークでSDPを使用すると、データの中間的なレプリケーションが除去され、メッセージ交換の負荷がCPUからネットワーク・ハードウェアへ移動することにより、TCP/IPのオーバーヘッドが削減されます。