});これまで、暗号化アルゴリズムなどの前提知識はさほど必要としない部分を中心に説明してきたが、ここより先には、少しずつ暗号アルゴリズムに絡んだ話が増えてくる。RFCなどでは数式で表現されている内容も、できるだけ図示するように心掛け、可能な限りかみ砕いて説明していくので、あきらめずに読み進んでいただければと思う。SSL/TLSにおけるセッションとコネクションSSL/TLSにおけるサーバとクライアント間での暗号化通信では、基本的にセッション型のモデルを用いる。通信の信頼性を高めるという考えに立てば、これは至って正当な考え方である。セッション型の通信管理モデルを用いる場合、プロトコル内でセッション管理を行う必要がある。SSL/TLSでは、このために「セッション」と「コネクション」という、2つの管理すべき接続状態を規定している。最初にこの2者について説明しよう。SSL/TLSを使い暗号化された通信を行うためには、通信の開始に先立って、まず初めに利用可能な暗号アルゴリズム、電子証明書の有無など、暗号化の条件に関して両者が合意しなければならない。いわゆる“ネゴシエーション”と呼ばれる過程だ。このネゴシエーションという作業は、一般に時間とCPU処理と通信量のかかる「コストの高い」処理である。そのため、通信処理の効率を考えれば、できる限り不要なネゴシエーションは行うべきではない。いった視点に立ち、SSL/TLSでは、ネゴシエーションによる通信条件の合意と、実際の通信チャネルの管理を、それぞれ概念として独立させている。このうち前者が「セッション」であり、また後者が「コネクション」である。セッションとコネクションについて、もうすこし詳しく個条書きにすると、次のようになる。Protocolで生成、通信終了まで存在する時間と手間のかかる暗号化通信のためのネゴシエーションを減らす工夫である実際の通信を行う「コネクション」は、セッションに従属して存在する●コネクション実際の通信を行う通信チャネルで、トランスポート層に相当するセッションでの合意に基づき、実際の通信状態の管理を行う通信中でも必要に応じて、生成、破棄されるすべてのコネクションには親となる1つのセッションが存在する図20には、サーバプロセスとクライアントプロセス間における、セッションとコネクションの関係を図示してみた。サーバプロセスとクライアントプロセス間でのネゴシエーションの結果、まずセッションαが設定されている。そのインスタンスとしてコネクションx、yがそれぞれ実際の通信チャネルとして存在する。同じプロセス間で、異なるセッションβも設定されている。こちらのセッションにはコネクションzが通信チャネルとして存在している。セッションは暗号化の方法を合意した関係。コネクションはそれに基づいて設定される実際の通信チャネル前出の個条書きにある、セッションが「合意した関係」であり、コネクションが「通信チャネル」であることの意味は、この図からより具体的に把握できるかと思う。この図から分かるように、セッションそのものは物理的な存在物ではない。SSL/TLSの世界では、「合意した関係」を論理的な接続と見なして、あたかも物理的なものであるかのような取り扱いをする。以降を読み進めるに当たっては、この点にも留意しておくといいだろう。具体的なアプリケーションの構成要素と、セッションやコネクションがどのような関係になるのかは、アプリケーションの実装状況によって異なる。ここでは、その一例としてブラウザのウィンドウとの関係で考えてみる。図21はPCから2つのWebサーバに接続し、Webサーバ1では2つのウィンドウ、Webサーバ2では1つのウィンドウを開いたときの状態例だ。同一のWebサーバかそうでないかによらず、セッションは各ウィンドウごとに設定され、また1つのセッションで必要に応じて複数のコネクションが利用される。Webブラウザ画面とセッション/コネクションの対応イメージコネクションを張るに当たっては、実際にはTCP/IPのソケットが用いられている。ソケットの接続先はWebサーバの443番ポートであり、またローカルポートはその時点で空いているポートが割り当てられる。個々のコネクションはソケットディスクリプタによって識別できるので、各コネクションが混乱することはない。次に、セッション、コネクションのそれぞれのレベルで管理している情報について見ていこう。メールマガジンをご購読ください。申し込みページへITmediaはアイティメディア株式会社の登録商標です。