httpの「ステートレス」とは


2025/02/19

## 状況
- 「httpは本来ステートレスで」って説明したら、「そもそもステートレスって何？」と質問された。

## 目的
- ステートレス、ステートフルの考え方を理解する。　＃ステートレスは平等。退かぬ、媚びぬ、顧みぬ、って感じ
- httpの基本仕様を理解する　＃文書運搬規約でしかない
- httpで何がしたいか理解する　＃さっき送った文書に書いてある名前を相手に覚えてほしい
- httpに何をさせているか理解する　＃運搬内容にIDとか入れておいてもらっている

## ステートレス、ステートフルとは
ステート（state）：　状態、状況、様子、健康状態などを意味する英語の単語﻿
ステートレス、ステートフル　：　ステート（前後の状況）に応じて処理の仕方を変えるかという考え方、アーキテクチャ。変えない場合ステートレス。変える場合ステートフル。
→相手が誰であろうと、絶体絶命の状況であろうと、帝王に逃走はない、とか、誰にでも平等な対応でステートレス。
→この文書の対象読者なら、主にwebの文脈の言葉で、ログイン関係と思って良いはず。
→他の文脈だと、セキュリティの文脈で、ステートフルインスペクション、とかで出てくるけど、今は気にしなくて良いと思う。
→webサイトの挙動の例
- qiita　：　ログイン前後で「ログイン」ボタンの表示有無を制御　：　ステートフルな挙動
- デジタル庁HP　：　多分誰がアクセスしても同じ情報が表示される　：　ステートレスな挙動

https://www.digital.go.jp/

## httpの基本仕様
以下のページが必要十分に分かりやすく解説してくれています。

https://www.nic.ad.jp/ja/basics/terms/http.html

- 文書などの情報をやりとりする時に使われる通信手順(プロトコル)
- 1990年前後に開発
- 別途cookieなどの技術を組み合わせて使うことで複数回のやりとりを追跡


## httpで何がしたいのか
1990年以降、みんなが「web」を使い始めたので、「web」で通販とか商売したくなった。

→「認証」「認可」「アカウンティング」（AAA）などが必要になってきた。　＃今回の話。
→「機密性」なども必要になってきた。　＃また別の話。

＞別途**cookie**などの技術を組み合わせて使うことで複数回のやりとりを追跡
→クッキーってなにそれ？おいしいの？

「Cookie」：HTTPの状態管理メカニズム。webサーバーとクライアント間で状態を保持し、セッション管理やユーザー認証などの機能を実現。

2000年10月　RFC2965　https://tex2e.github.io/rfc-translater/html/rfc2965.html

2011年04月　RFC6265　https://tex2e.github.io/rfc-translater/html/rfc6265.html

ということで、HTTPクライアントとサーバー間でのセッション管理のために、
httpというプロトコルの開発後10年とか20年かけて技術的な拡張をしていったという感じですね。

↓万能ということではないよ、という話。法律対応で良くクッキーのポップアップ出るようになりましたね。
```
7. プライバシーに関する考慮事項
Cookieは、サーバーにユーザーを追跡させるためにしばしば批判されます。

8.1. 概観
Cookieには、多くのセキュリティ上の落とし穴があります。このセクションでは、いくつかの重要な問題について概説します。

   7. Privacy Considerations .........................................28
      7.1. Third-Party Cookies .......................................28
      7.2. User Controls .............................................28
      7.3. Expiration Dates ..........................................29
   8. Security Considerations ........................................29
      8.1. Overview ..................................................29
      8.2. Ambient Authority .........................................30
      8.3. Clear Text ................................................30
      8.4. Session Identifiers .......................................31
      8.5. Weak Confidentiality ......................................32
      8.6. Weak Integrity ............................................32
      8.7. Reliance on DNS ...........................................33
```

↓実装イメージ
```
1. はじめに
このドキュメントでは、HTTP CookieおよびSet-Cookieヘッダーフィールドを定義します。
Set-Cookieヘッダーフィールドを使用して、HTTPサーバーは名前/値のペアと関連するメタデータ（Cookieと呼ばれる）をユーザーエージェントに渡すことができます。
ユーザーエージェントがサーバーに後続のリクエストを行うと、ユーザーエージェントはメタデータとその他の情報を使用して、Cookieヘッダーで名前と値のペアを返すかどうかを決定します。
```
ということで、キーバリューの形式のテキストデータ、となります。json形式も可能。
自分のブラウザがどんなクッキーを食べているのか、何が書いてあるのか、見てみましょう。

chromeでの確認方法

https://support.google.com/chrome/answer/95647?hl=ja&co=GENIE.Platform%3DDesktop


## httpに何をさせているか

https://developer.mozilla.org/ja/docs/Web/HTTP/Cookies

結局、http自体は変わらず運搬しているだけ。
クライアント側は求められるデータの送信、もらったクッキーの保管をしているだけ。
httpサーバ、webサーバ側が、送られてきたデータから、クッキーを確認して、業務ロジックを実装、実行しているというだけ。
ログインなら、ログインのロジックを実装、実行し、ユーザ名をDBなどから取得して、画面に変数として埋め込んでブラウザに返却、などなど。

詰まり、あくまで「httpはステートレス」。記憶する主体はhttpサーバである。認証のデータはCookieとしてやり取りされる。


## 補足　httpの歴史

https://gihyo.jp/admin/serial/01/http3/0001

とても分かりやすく、また、最近の把握すべき用語である「QUIC」の説明もあります。

## 補足　なぜ「クッキー」？

https://ja.wikipedia.org/wiki/%E3%83%AB%E3%83%BC%E3%83%BB%E3%83%A2%E3%83%B3%E3%83%88%E3%82%A5%E3%83%AA

https://montulli.blogspot.com/2013/05/the-reasoning-behind-web-cookies.html

```
The name

I had heard the term "magic cookie" from an operating systems course from college.
The term has a somewhat similar meaning to the way Web Cookies worked 
and I liked the term "cookies" for aesthetic reasons.
Cookies was the first thing I came up with and the name stuck.   
```

由来はUNIXの機能みたいですね。
そして詰まりは、やり取りするデータ、くらいの意味合いみたいですね。

http://catb.org/jargon/html/C/cookie.html

以上