イラスト図解式 この一冊で全部わかるWeb技術の基本 第3章

今日は以下の本の第3章を読みます。

小林・坂本（著）、佐々木（監修）,2017, イラスト図解式 この一冊で全部わかるWeb技術の基本, SBクリエイティブ, 東京 [https://amzn.asia/d/cfZkf5i]

3つのプロトコル（作法）

第3章には全部で15個の節に分かれていますが、俯瞰すると以下の3つに分けられます。

• 送受信される内容のプロトコル
  • 3-01～3-05, 3-12～3-13
• 送受信のやりとりのプロトコル
  • 3-06～3-11
• 送受信される内容を一意に表すプロトコル
  • 3-15

注意

ブログの記事にはしていませんが、第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ではこれらの両方を使うハイブリッド方式が採用されています。

ハイブリッド方式の手順は以下の通りです。

1. 共通鍵方式で使う共通鍵を、公開鍵方式で暗号化して送る。
   • 71ページの中段に書かれている（描かれている）『鍵の交換』の部分が該当します。
2. 以後はその共通鍵を使って、暗号化&復号化を行う。

詳しくは「共通鍵方式 公開鍵方式 ハイブリッド」で検索してください。

補足 about クッキーとセッション（3-12節～3-14節）

クッキーとセッションの区別が分かりづらいという声をよく聞きます。

（かくいう私も、正直なところ、この記事を書くまでちゃんと理解しておりませんでした。 ゆえに間違ったことが書かれているかもしれません。その場合は、コメント欄でご指摘ください。）

必要性; 発展の経緯

そこで、webの発展の中でクッキーとセッションが必要になった経緯を記すことで、 クッキーとセッションの区別を付けていただければ幸いです。

1. 1990年代にHTTPが誕生した当時は、HTTPはステートレスで十分だった。
2. しかし、その後、webの発展に伴い、ステートフルな通信も必要になってきた。
3. そこで、クッキー（cookie）に状態（state）を記述することで、通信をステートフルにすることができた。
4. しかし、クッキーは直接的な記述（※）なので、盗聴されたときのリスクが高い。
   • ※例えばクッキーに『username=hayatuyo;cart=123,456,789』と記述してある場合を考える。
     • もし盗聴されると、"hayatuyo"はユーザー名と推測され、"123,456,789"はカートに入れてある商品（3つ）と推測されかねないので、これらは可能ならば隠蔽したい。
5. そこで、クッキー上はランダムな文字列だけを記述し、中長期的に維持すべき情報の実態はwebサーバー側だけに置いておく方式が発明された。
   • 例えば…
     • クッキーには『session-id=5q2nr7o2xiirgssc』とのみ記述し、
     • そのユーザーのカートの中身はwebサーバーにのみに置いておく。
   • このような中長期的に情報を維持する必要がある時空間が「セッション」と呼ばれ、
   • セッションを一意に特定するためのランダムな文字列が「セッションID」と呼ばれる。

区別

誤解と批判を恐れずに、クッキーとセッションの区別を表にしてみました。 （ご批判はコメント欄からお願いいたします。）

	保存領域	記述の性質	情報の実態の例	情報の実態そのものが漏洩した場合のリスク	使い方
クッキー	クッキー	直接的記述	ニックネーム	低い	漏洩してもリスクの低い情報を直接的に記述する
セッション	クッキー	関節的記述	ショッピングカートの中身	高い	漏洩したらリスクの高い情報を関節的に記述する

混乱の元？

個々まで読んでいただければ、区別が付くようになったと思います。

区別が曖昧な内は、74ページに記述されているように、 有効期限が設定されていないクッキーが「セッションcookie」と呼ばれることも混乱の一因かもしれません。

自転車に乗るように、繰り返し読んで少しずつ、無意識レベルで区別できるようになりましょう。