今日は以下の本の第3章を読みます。
小林・坂本(著)、佐々木(監修),2017, イラスト図解式 この一冊で全部わかるWeb技術の基本, SBクリエイティブ, 東京 [https://amzn.asia/d/cfZkf5i]
3つのプロトコル(作法)
第3章には全部で15個の節に分かれていますが、俯瞰すると以下の3つに分けられます。
注意
ブログの記事にはしていませんが、第2章でも送受信のやりとりのプロトコルとして、 2-03節でTCP(Transmission Control Protocol)が扱われています。
第2章のTCPと第3章のHTTP違いは、OSI参照モデルにおけるレイヤー(階層)の違いです。
プロトコル名 | レイヤー名 | 階層番号 |
---|---|---|
TCP | トランスポート層 | 第4層 |
HTTP | アプリケーション層 | 第7層 |
39ページ中段の図においては、TCPは黒色の実線で「コの字型」に描かれています。 一方、HTTPは赤茶色の点線で、左右に描かれています。
第3章では、アプリケーション層のHTTPのみが扱われています。
ITエンジニアリングの場で設計すべきこと
上述の3つのプロトコルのうち、ITエンジニアリングの場で設計すべきは、 1つ目の「送受信のやりとりのプロトコル」と3つ目の「送受信される内容を一意に表すプロトコル」です。
2つ目の「送受信のやりとりのプロトコル」はwebブラウザとwebサーバー(のhttpエージェント)に任せることができるので、考える必要がありません。
1つ目の「送受信のやりとりのプロトコル」と3つ目の「送受信される内容を一意に表すプロトコル」は、 雛形としてのプロトコルは世界共通で決まっているとは言え、 具体的な内容は、プロジェクトごとに設計し、仕様に落とし込んでいく必要があります。
ゆえに、学びを深めていく必要性が高いのもこれらの点です。
区別 | 節番号 | 設計で考えるべきか否か | 学びを深める必要性(需要) |
---|---|---|---|
送受信される内容のプロトコル | 3-01~3-05, 3-12~3-13 | yes | 高い |
送受信のやりとりのプロトコル | 3-06~3-11 | no | 低い(専門的すぎる) |
送受信される内容を一意に表すプロトコル | 3-15 | yes | 高い |
補足 about HTTPS(3-10節と3-11節)
暗号化の方式の観点から、HTTPSについて補足します。
狭義の暗号化の方式
HTTPSでは安全性を確保するために通信が暗号化されますが、狭義の暗号化の方式は大別すると以下の2つです。
- 共通鍵方式
- 公開鍵方式
公開鍵方式は安全性が高いのですが、暗号化にも復号化にも時間とエネルギーが多く必要です(高コスト)。
一方、共通鍵方式は、公開鍵方式はに比べると少し安全性は低いのですが、暗号化も復号化も低コストで済みます。
ハイブリッド方式
そこで、HTTPSではこれらの両方を使うハイブリッド方式が採用されています。
ハイブリッド方式の手順は以下の通りです。
- 共通鍵方式で使う共通鍵を、公開鍵方式で暗号化して送る。
- 71ページの中段に書かれている(描かれている)『鍵の交換』の部分が該当します。
- 以後はその共通鍵を使って、暗号化&復号化を行う。
詳しくは「共通鍵方式 公開鍵方式 ハイブリッド」で検索してください。
補足 about クッキーとセッション(3-12節~3-14節)
クッキーとセッションの区別が分かりづらいという声をよく聞きます。
(かくいう私も、正直なところ、この記事を書くまでちゃんと理解しておりませんでした。 ゆえに間違ったことが書かれているかもしれません。その場合は、コメント欄でご指摘ください。)
必要性; 発展の経緯
そこで、webの発展の中でクッキーとセッションが必要になった経緯を記すことで、 クッキーとセッションの区別を付けていただければ幸いです。
- 1990年代にHTTPが誕生した当時は、HTTPはステートレスで十分だった。
- しかし、その後、webの発展に伴い、ステートフルな通信も必要になってきた。
- そこで、クッキー(cookie)に状態(state)を記述することで、通信をステートフルにすることができた。
- しかし、クッキーは直接的な記述(※)なので、盗聴されたときのリスクが高い。
- ※例えばクッキーに『username=hayatuyo;cart=123,456,789』と記述してある場合を考える。
- もし盗聴されると、"hayatuyo"はユーザー名と推測され、"123,456,789"はカートに入れてある商品(3つ)と推測されかねないので、これらは可能ならば隠蔽したい。
- ※例えばクッキーに『username=hayatuyo;cart=123,456,789』と記述してある場合を考える。
- そこで、クッキー上はランダムな文字列だけを記述し、中長期的に維持すべき情報の実態はwebサーバー側だけに置いておく方式が発明された。
- 例えば…
- クッキーには『session-id=5q2nr7o2xiirgssc』とのみ記述し、
- そのユーザーのカートの中身はwebサーバーにのみに置いておく。
- このような中長期的に情報を維持する必要がある時空間が「セッション」と呼ばれ、
- セッションを一意に特定するためのランダムな文字列が「セッションID」と呼ばれる。
- 例えば…
区別
誤解と批判を恐れずに、クッキーとセッションの区別を表にしてみました。 (ご批判はコメント欄からお願いいたします。)
保存領域 | 記述の性質 | 情報の実態の例 | 情報の実態そのものが漏洩した場合のリスク | 使い方 | |
---|---|---|---|---|---|
クッキー | クッキー | 直接的記述 | ニックネーム | 低い | 漏洩してもリスクの低い情報を直接的に記述する |
セッション | クッキー | 関節的記述 | ショッピングカートの中身 | 高い | 漏洩したらリスクの高い情報を関節的に記述する |
混乱の元?
個々まで読んでいただければ、区別が付くようになったと思います。
区別が曖昧な内は、74ページに記述されているように、 有効期限が設定されていないクッキーが「セッションcookie」と呼ばれることも混乱の一因かもしれません。
自転車に乗るように、繰り返し読んで少しずつ、無意識レベルで区別できるようになりましょう。