学習目標
通信の各層がどこまで保証するかを説明できるようにする。パケットが届いたこと、暗号化されたこと、注文が1回だけ確定したことは別の問題である。
役割の比較
| 技術 | 主な役割 | それだけでは保証しないもの |
|---|---|---|
| DNS | 名前に対応する情報を解決 | 通信内容の暗号化、業務処理の成功 |
| IP | ネットワークをまたぐパケット配送 | 到着、順序、再送 |
| TCP | 順序のある信頼できるバイトストリーム | メッセージ境界、業務の1回だけの実行 |
| TLS | 通信の機密性・完全性と相手認証の基盤 | アプリ内の権限制御、入力値の安全性 |
| HTTP | 資源に対する要求・応答の意味 | タイムアウト時に処理が未実行であること |
TCPの再送や順序制御はアプリの取引単位とは違う。TLSで守られた通信でも、利用者の権限チェックがなければ他人のデータを参照できてしまう。TCP RFC 9293、TLS 1.3 RFC 8446
HTTPメソッドの性質
| メソッド | 安全なメソッドか | 冪等か | 代表的な意味 |
|---|---|---|---|
| GET | はい | はい | 表現の取得 |
| HEAD | はい | はい | GET相当のヘッダを取得、本文なし |
| PUT | いいえ | はい | 対象資源の状態を指定した内容にする |
| DELETE | いいえ | はい | 対象資源との対応を除去 |
| POST | いいえ | 一般には保証しない | 資源固有の処理を依頼 |
ここで「安全」は暗号的安全性ではなく、利用者が状態変更を要求しないというHTTPの意味論。「冪等」は同一要求を複数回行ったときの意図した効果が1回と同じことで、毎回の応答コードまで同一である必要はない。GETに業務上の削除操作を割り当てるのは意味論に反する。RFC 9110 第9章
応答がないとき何が分かるか
判断例
注文POSTの後にタイムアウトした。未処理だと決めつけて新規注文を送り直すと二重登録になる可能性がある。独自の要求IDを付け、サーバがIDの初回受付と結果を管理する設計なら、同一IDの再試行を同じ処理として扱える。IDの範囲、保存期間、同一IDで異なる本文を送った場合、並行到着時の一意性も定める。これはPOST全体に標準で備わる性質ではなく、アプリの契約として実装する補強策である。
転送時間の計算例
100MBを100Mbit/sで送る。ここではMを10の6乗、1Byte＝8bit、ヘッダや再送を無視すると、100×8/100＝8秒。実効速度が帯域の80%なら10秒。往復遅延、接続確立、サーバ処理は別途加わる。MBとMiB、Mbit/sを混同しない。
間違えやすい点
- TCPが信頼性を持つからといって、切断後に相手アプリがどこまで処理したかは分からない。
- HTTPSだから安全な入力とは限らない。SQLインジェクションなどは別の対策が必要。
- HTTPがステートレスでも、アプリはCookie等を用いてセッションを管理できる。
- 全てのHTTPがTCP上とは限らない。HTTP/3はQUICを使うため、接続図では前提のバージョンを明記する。
確認問題
- DELETEを2回実行して2回目が404でも、ただちに冪等性違反か？ → いいえ。意図した削除効果で判断する。
- タイムアウトは注文が失敗した証拠か？ → いいえ。結果照会や重複を防ぐ再試行設計が必要。
出典と適用上の注意
図は独自の業務シーケンス。HTTP/3の経路は公式RFC 9114参照。TLSの古い版やSSLを前提にした過去問は、当時の条件と現在の設計を区別する。