HTTPプロトコルについて調べてみる
ebi_yuそもそもHTTPとは
Hypertext Transfer Protocolの略。
もとはWebページを閲覧するためにhtml(HyperText Markup Language)を転送するためのプロトコル。
現在は、画像データ/API呼び出し/認可など、様々なプロトコルに使われる。
HTTPプロトコルにはいくつかバージョンがあり、HTTP/1.1、HTTP/2が主流(最近、HTTP/3が登場したが対応してないサービスも多い)
Webシステムに使用するプロトコルについて
下記ページが詳しい。
https/httpはアプリケーション層の通信プロトコル
ユーザがwebページにアクセスすると
1. リクエストがhttpsプロトコルでとぶ
2. TCP/UDPプロトコルに変換
3. IPプロトコルに変換
4. Ethernetプロトコルに変換され、サービスが動いているサーバに届く。
サービスが動いているサーバ → ユーザへのリスポンスの場合は逆
TCPコネクションの確立
HTTP/HTTPs通信が確立する前に、TCPコネクションを確立する必要がある
(通信が届いているかの信頼度をあげるため)
ebi_yuHTTPSとは
HTTP通信を暗号化した通信プロトコル。
HTTP/2、HTTP/3ではhttpsが必須。
前提: 秘密鍵/公開鍵について
公開鍵
データを暗号化するための鍵。
最初の通信の際にブラウザに渡して、HTTP通信で送るデータなどを暗号化してもらう
秘密鍵
公開鍵で暗号化されたデータを復号するために使用する鍵。
公開鍵で暗号化されたデータは秘密鍵でしか復号できない。
基本的に外部に公開しないで、サービスを提供するサーバのみが持っている
前提: サーバ証明書について
公開鍵を含む電子証明書。
サーバ証明書が信頼できることは中間 or ルート証明書で確認する。
(中間 or ルート証明書証明書に含まれる公開鍵によってサーバ証明書を復号化できるか検証する)
最終的には信頼された機関によって発行されたルート証明書によって、証明書の信頼性が
確認される
ルート証明書は、標準のブラウザでデフォルトで組み込まれている。
HTTPSの暗号化方式
1. TCPコネクションの確立
前項を参照
2. サーバ証明書(公開鍵)の受信
サーバ証明書(公開鍵)を含むがサーバから送られてくる。
サーバ証明書をルート証明書に含まれる秘密鍵で復号し、サーバの公開鍵を取得する
3. 共通鍵の公開鍵での暗号化
公開鍵でブラウザ側で生成した共通鍵を暗号化する。
暗号した共通鍵をサーバ側に送信する。
サーバ側でサーバの秘密鍵を使って、送られてきた共通鍵を取り出す。
4. 共通鍵を使用した暗号化通信の確立
以後のサーバとブラウザの通信は共通鍵によって暗号化されたデータを送り合う
ebi_yuHTTP/1.1
- 登場時期: 1997年
-
特徴:
- 接続ごとに1つのリクエスト/レスポンスのみ処理。
- ヘッダ情報がプレーンテキスト。
- パイプライン処理により、複数のリクエストを順番に処理可能だが、先行するリクエストのレスポンスが完了するまで後続のレスポンスは待機（ヘッド・オブ・ライン・ブロッキング）。
HTTP/2
- 登場時期: 2015年
-
特徴:
- 同一接続上での多重化により、複数のリクエスト/レスポンスが並行して処理可能。
- ヘッダ情報の圧縮によりデータ転送量の削減。
- サーバプッシュ機能により、クライアントの要求前にサーバからリソースを送信可能。
- バイナリ形式での通信により、パフォーマンス向上。
HTTP/3
- 登場時期: 2020年
-
特徴:
- UDPベースの新しいトランスポートプロトコルQUICを使用。
- 接続の確立が高速。
- ヘッド・オブ・ライン・ブロッキングの更なる削減。
- パケットの暗号化が標準。
HTTP/3の対応状況について
ブラウザ/サービスが立っているサーバ(webサーバ)どちらでもHTTP/3に対応している必要がある 。
主要ブラウザはHTTP/3 対応済みっぽい
サーバサービスの対応はサービスによる
nginx
cloud front
kong
サポートされてない?