HTTP
HTMLをやり取りするためのプロトコル・・・だった
HTTP/1.0
初版
HTTP/1.1
1.0に不足していた機能を追加したもの
主流になった
HTTP/2
ヘッダ圧縮などを行うことで、1.1より高速化
HTTP/3
トランスポート層にQUICを採用する事でさらに高速化 プロトコルの特徴
テキストベース
一方向通信
常にクライアントからのリクエストから通信が開始する
サーバーはレスポンスのみを返す
ステートレス
HTTPリクエスト
リクエスト行、ヘッダフィールド、リクエストボディで構成される。
table:ヘッダフィールド
Accept-Language 人間の言語を指定する
Authorization 認証情報を指定する
Content-Type サーバーにデータを送信する時のフォーマットを指定する
Host リクエストのホスト名
Referer ひとつ前のリクエストのURLを指定する。ユーザーがWebページをどう巡回しているのかを調べるために使う
User-Agent クライアントの情報を指定する
リクエストボディ
サーバーに送るデータの本体
中身のフォーマットはContent-Typeによってまちまち
例えば、application/x-www-form-urlencoded（Formタグ由来の送信）だとkey1=val1&key2=val2のような形式になる
HTTPレスポンス
ステータス行、ヘッダフィールド、レスポンスボディで構成される。
table:ステータスコード
1xx 情報レスポンス
2xx 成功レスポンス
3xx リダイレクトレスポンス
4xx クライアントエラーレスポンス
5xx サーバーエラーレスポンス
例えば、ブラウザでURLを叩く時、http://hoge.com/fuga/ に対して、http://hoge.com/fugaでアクセスしても正常に動作する。これは、まず301応答が帰ってきて、Bodyに記載されている本来のURL（/が付いてるほう）に対してリダイレクトを行っている動作となっている（RESTクライアントで叩いたりすると、リダイレクトされないので301応答が見える）
table:ヘッダフィールド
Cache-Control キャッシュに関する情報
Content-Type 応答データの形式
Location 3xx系ステータスである場合の、リダイレクト先など
Server サーバーの情報が入るが、セキュリティの観点から消す場合もあるのだそう
Cookie
サーバーからクライアントへ、値を保存する技術
保存した情報は、key1=val1; key2=val2のような形で、クライアントのリクエストに毎回付与されてやり取りされる
table:ヘッダフィールド
Set-Cookie クライアントに値を保存するよう指示する
Cookie 保存されてる情報
If-Modified-Since
コンテンツの最終更新日時を利用した、キャッシュ戦略
table:ヘッダフィールド
Last-Modified コンテンツの最終更新日時を（クライアントに）通知する
If-Modified-Since リクエスト時に、Last-Modifiedで通知された更新日時を渡す
サーバは、If-Modified-Sinceで通知された更新日時と、実ファイルの更新日時を比較して、更新されていなければステータスコード304を返す。（304を受信したクライアントは、キャッシュを用いる）
ETag
コンテンツ内容のハッシュを利用した、キャッシュ戦略
table:ヘッダフィールド
ETag 応答コンテンツのハッシュ値
IF-None-Match リクエスト時に、ETagで通知されたハッシュを渡す
基本的な考え方はIf-Modified-Sinceとほぼ同じで、ETagと一致しているかどうか（データが同じかどうか）で更新を判断する
こっちの方が優先して使われている。