■ OSIモデルとTCP/IPモデル

まずネットワークモデルの復習からだ。

またですか。

「また」と言ったかね、ネット君？
では理解しているであろうネット君に質問する。OSIモデルとTCP/IPモデルの最大の違いは何かね？

えっへっへ。そんな事なら上のモデルを見れば一発ですよ。
OSIは７層なのに対して、TCP/IPは４層です。

違う。
最大の相違点はOSIモデルは実装レベルではないという点だ。

…そういえば、そんなことを第37回で言っていたような。

設計図と、実際に作り上げたものは違う、という言い方のほうがいいかな。
あくまで「こういう形にしよう」という標準であって、実際のプロトコル・スイートと完全に一致しない。

そうですね、TCP/IPモデルの場合、レイヤ１・２がインタフェース層、レイヤ５・６・７がアプリケーション層とかいってまとまってますもんね。

特にレイヤ５・６・７はTCP/IPの場合まとめて１つのプロトコルで実装されているので明確な線引きが難しい。

えぇ〜っと。例えばTCP/IPのアプリケーション層のプロトコルだと、HTTPがありますけど。
HTTPは３つの層の役割をすべてこなすってことですか？

うむ。50回目ともなるとさすがにこなれてきたな。なかなかいいぞ。

えへへ。

ようやっと人並みってところだがな。

ぐぐぅ。辛口だ。

ともかく、その通りだ。レイヤ４まではこの層はコレ、と説明できたが、ここから先はアプリケーションやサービスによってやったりやらなかったり、色々だ。なので曖昧な説明が多くなるかと思うが我慢したまえ。

曖昧ですか。

詳しい話はレイヤ７以降で、プロトコル別の説明する。

了解です。

■ セッション

レイヤ５はセションもしくはセッション層と呼ばれるレイヤだ。
ネット君、sessionの意味は？

え〜っと。
「話し合い」「打ち合わせ」「会議」「学期」などと、Excite辞書が。 ▼ link

うむ。話し合いだ。つまりプロセス間の話し合いの管理がセッション層の役割だ。
以前、ペンフレンドとの文通の話をしたな。

キャシーとの話ですね。第５回の時の。

まだ似非外国人との文通は続いているのかね？
ともかく、話し合いの開始、維持、終了を管理するということだ。

似非じゃないですよ、コネティカット出身ですって。
でも……そういえば写真を送ってくれる約束をしたんだけど……。

そこまでだネット君。ゼミ生が悲嘆にくれる所は見たくないので、あとで家に帰ってから考えてくれ。

は、はぁ。博士がそうおっしゃるなら。
それで、話し合いの管理って具体的に何をするんですか？

うむ。セッションというものをまず理解してもらうことからいこう。
例えばFTPは２つのコネクションを使ってファイルのやり取りを行う。

２つのコネクションによって、ユーザ認証から始まって、ディレクトリの情報、ファイル交換、交換後のディレクトリの情報、そしてまたファイル交換……と必要な分のファイル交換が行われるわけだ。

ディレクトリの情報や、ファイルが「話す言葉」の「会話」なんですね。

うむ。そして必要な分だけファイル交換が終わったら、コネクションを切断する。
このような会話(セッション)全体の管理を行うのがレイヤ５の役割だ。

管理って一言でいわれてもパッとしませんけど。

まず、セッションの確立だな。
アプリケーションと一言で言っても、いくつものプロセスから成り立っていることもある。通信するプロセスが複数ある場合もあるのでプロセスごとのデータが混ざらないようにプロセスの識別を行う必要がある。

プロセスの識別？ データが混ざらないように？
……どっかで聞いたような…？

うむ。つまりポート番号を決定して、レイヤ４に渡すわけだ。

あぁ、なるほど。

そうすると、TCPがコネクションを接続してくれるわけだ。

UDPの場合は？

UDPはいきなり送りつける事になる。ともかくその時点からセッションがスタートする。

次はセッションの維持ですよね、何をするんですか？

会話として成立するように制御を行うわけだ。ダイアログ制御という。

(1)の図は会話として成立するが、(2)は返事がこないうちに新しい話題をしてしまっている。
これは会話として成立しているといえるかな？

会話とはいえないですよね。一方的に好き勝手喋ってるだけで。

うむ、つまり要求と応答の役割分担の取り決めを行う必要がある、ということだ。

ん〜っと。これってTCPの確認応答と同じ形ですよね。
シーケンス番号と確認応答番号で送るデータの順番を管理して。

まぁ似ているが、同じではない。
TCPは双方が同時に送れる全二重通信だ。

TCPが確認応答を使って制御するのは、あくまでもデータを元の順序で正確に送るためだ。
データの流れ自体を制御するわけではないので、上の図のようにすれ違いでデータを送りあうことだってある。

う〜ん、そうかぁ。確かに上の図はすれ違ってるけど、TCPとしてはおかしい所がないものなぁ。

そうだ。別に悪くはない。だが上の図のようなすれ違いをしてもらっては困るアプリケーションだってある。そのためにダイアログ制御を行う必要がある。

「今度はこっちが喋る番」・「聞く番」とかで役割を変えるわけですね。

そういうことだ。

なるほどです。

さらにセッションの管理としては、チェックポイントを決めて、中断からの復旧や同期の制御を行う。

ちぇっくぽいんと？
中断からの復旧や同期？

まぁ、簡単に言えばセーブポイントだな。

対話をいったん打ち切って、チェックポイントの設置を行う。いったん今までの対話を保存して、あらたに同期を取り直すわけだ。
何かあった場合、少なくともこのチェックポイントまでは戻れるようにな。

ははぁ。あれですね。
Wordが自動で作成する「~$なんとか」とかいうファイルみたいな奴ですね、自動保存して最悪そこまでは元に戻せるように。

なかなかいい例だ。Wordの文書作成を、Wordと人との対話と考えればその「~$なんとか」の自動保存がチェックポイントと言えるだろう。

あれのおかげで、数時間かけて作成してるファイルが飛んでしまって絶叫することがなくなりますもんね。

それは誰でも一度は通る道だがな。
ともかく、これは一例で、アプリケーションによってこれらの制御を行う、行わないがある。これらがセッションの管理と呼ばれるものだな。

なるほど。

そしてデータを転送し終わったらセッションの切断を行って会話終了、だ。

セッションの開始でポートを決定して開いたから、ポートを閉じて終了、ですね。

■ セッションとコネクション

つまり、レイヤ５ではデータ転送の流れを管理するわけだ。

う〜ん、コネクションとの区別がいまいちわからないんですけど。

そうだな。かなり混同しやすい概念だな。
かなり曖昧な概念だし、コネクションと同じ説明をセッションでしてるのを聞いたこともある。

そうですよね、なんかどちらも同じ接続じゃんか、って話になっちゃいそうです。

役割が違う。コネクションの接続・切断はデータ転送用回線の接続・切断を示すのに対して、セッションはもう一段上のデータ転送の開始と終了を表すのだよ。

ううぅ？

簡単に言えば、コネクションはデータを送る、セッションは会話を成立させるかな。

ん〜。

ややこしいのは、コネクションを接続してデータを届けるようにできないと、会話であるセッションを開始できない。
大体のセッションは、１つのセッションにつき１つのコネクションですんでしまう、という点かな。

ははぁ、なんとなくわかったようなわからないような。

HTTPで例をあげよう。
例えば、この「３分間ネットワーキング第49回」だが、HTMLファイルと画像(Flash含む)からなりたってるな。

そうですね。

HTMLファイルと画像１枚１枚を送るのはコネクションで作られた通信路。
全体で１つのページとして扱い、管理するのがセッション。

管理するって、実際に表示するとかですか？

いや、表示はブラウザの仕事だ。
通常のHTTPではHTMLファイル、画像１枚１枚の転送全体を管理することはあまりないが、SSLなどではセッションで暗号が管理される。

ははぁ、暗号の管理。
ん〜っと、HTTPのHTMLファイルや画像などを暗号化する鍵を、ページ全体で同じのを使う、とかそういうことですか？

うむ、そう考えてもらって問題ない。

つまり、コネクションをまとめたものが、セッションって感じですか？

うぅむ、まとめたというかなんというか。確かにSSLではそんな感じだな。

■ レイヤ５プロトコル

TCP/IPでは特にレイヤ５で特定したプロトコルというものは存在しない。

あれ？ SSLは？

そうだな、SSLは確かにレイヤ５に近い位置にあるプロトコルだな。
ともかく、TCP/IP以外でいうならば、NFSやRPCなどがある。

えぬえふえす、あらーるぴーしーですか。

AppleTalkプロトコル・スイートなら、AppleTalk Session Protocolと呼ばれるプロトコルがある。

そりゃまたストレートな名前ですね。

うむ。まぁ正直TCP/IPではそんなに気にする必要のないレイヤだ。
詳しく覚えておく必要はない。

今回の分を否定するような事言わないでくださいよ。
いいんですか、それで？

いい。本当にそうだからな。セッションについて必要な場合はそのプロトコルでまた個別に説明することになるしな。
さて、今日はこんなところで終わりにしよう。

はい。

次回はレイヤ６だ。

了解です。
３分間ネットワーキングでした〜♪