🐙

Webを支える技術としてのHTTP

2025/01/07に公開

 1. はじめに今回は「Webを支える技術」という本を読んだので、その内容の中でもHTTPに関する内容をまとめます。またこの本の出版が2010年であり、現在でも初版のままで少し内容が古くなっていたのでその部分は更新された内容を付け加えています。また他にもこの本を要約していた記事やHTTPに関する記事も大変参考にさせていただきました。筆者の方にはこの場をお借りして感謝申し上げます。参考文献の欄にリンクを貼っているのでぜひご覧ください。
https://amzn.asia/d/1jlwYYT

 2. そもそもWebとは？WebはWorld Wide Webの略で、直訳すると「世界規模のクモの巣」です。無数のコンテンツが蜘蛛の巣のように結び付けられていることから名付けられました。

Webを一言で言い表すと、インターネット上のさまざまな情報(テキスト・画像・動画など)の閲覧を可能にするシステムであります。

 2.1 インターネットとWebの違いインターネットはインターネットプロトコル(IP)を利用した通信網のことです。世界中のコンピュータやネットワークが相互接続されたグローバルなネットワークインフラとなり、データや情報をやり取りするための基盤（通信プロトコルや物理的接続を含む）を提供しています。サーバー間でのデータ転送、VPN接続、オンラインゲームなどで利用されます。
Webは、インターネット上に構築されたサービスの一つで、インターネットを利用したハイパーテキストの公開および閲覧システムのことのようです。正確には、Webはインターネットを利用した技術のひとつです。
まとめると、インターネットはIP通信を利用した通信網のことで、Webはインターネットを利用してハイパーテキストの公開や閲覧をするシステムのことです。インターネットを利用した技術には、EメールやIP電話などいろいろありますが、Webもそれらのひとつです。

 2.2 Webを構成する主な要素Webは主にURI, HTML, HTTPからなります。

URI: Web上のリソース（ページ、画像、動画など）を一意に特定する仕組み
例：https://example.com/index.html


HTML: Webページの構造や内容（見出し、段落、リンク、画像など）を記述するための言語
例：curl https://example.com/index.htmlとコマンドラインで打つと出力される。


HTTP: WebブラウザとWebサーバがリソースをやり取りするための通信ルール

 3. HTTPの仕組みと特徴HTTPとはHyperText Transfer Protocolの略で、WebサーバーとWebブラウザの間で通信を行うプロトコルです。

HTTPはTCP/IPをベースとしています。ここでは、
TCP/IPの基礎知識
HTTPのメッセージ構造
プロトコルとしてのHTTPを特徴づけるステートレス性
の３つについて説明をします。

 3.1 TCP/IPとは何かインターネットのネットワークプロトコルは階層型になっています。そうごとに抽象化して実装すれば物理的なケーブルがメタルなのか光なのかといった下位層の具体的なことに左右されることなく、上位層を実装できます。

 3.1.1 ネットワークインターフェース層一番下のネットワークインターフェースそうは物理的なケーブルやネットワークアダプタに相当する部分です。

 3.1.2 インターネット層この層が担当するのはネットワークでデータを実際にやりとりする部分です。TCP/IPではIPが担当します。IPでは基本的な通信単位を「バケット」と呼びます。指定したIPアドレスを送り先として、バケット単位でデータをやり取りして通信します。
IPでは、自分のネットワークインターフェースでデータを送り出すことだけを保証しています。送り出したデータが多数のルータを経由して最終的な送り先まで届くはどうかは保証しません。

 3.1.3 トランスポート層IPが保証しなかったデータの転送を保証するのがトランスポート層の役割です。TCP/IPではTCPが担当します。TCPでは接続先の相手に対してコネクションを張ります。このコネクションを使ってデータの抜け漏れをチェックし、データの到達を保証します。

TCPで接続したコネクションで転送するデータがどのアプリケーションに渡るかを決定するのがポート番号です。HTTPはデフォルトで80番ポートを使用します。

 3.1.4 アプリケーション層アプリケーション層は具体的なインターネットアプリケーション、例えばメールやDNS、そしてHTTPを実現する層です。

 3.2 HTTPのメッセージ構造リクエストメッセージとレスポンスメッセージをまとめて「HTTPメッセージ」といいます。

ここではリクエストメッセージ、レスポンスメッセージの順に解説します。

どちらもメッセージの構造は下の画像の通りなのでサッと目を通してください。

 3.2.1 リクエストメッセージ以下のような構造です。
GET /test HTTP/1.1
Host: example.jp
①リクエストライン

１行目は

メソッド（GET）

リクエストURI（/test）

プロトコルバージョン（HTTP/1.1）

からなります。
②ヘッダ

ヘッダはメッセージのメタデータです。各ヘッダは「名前: 値」という構成をしていて、Hostヘッダは必須です。
③ボディ

先の例では登場しませんでしたが、ヘッダの後にボディが続くことがあります。ボディにはそのメッセージを表す本質的な情報が入ります。例えばPOSTメッセージなどでリソースを新しく作成したり更新するときはリソースの表現そのものが入ります。

 3.2.2 レスポンスメッセージ以下のような構造です。
HTTP/1.1 200 OK
Content - Type : application/xhtml+xml: charset=utf-8

<html xmlns="http://www.w3.org/1999/xhtml>

...
</html>
①ステータスライン

1行目は
プロトコルバージョン（HTTP/1.1）
ステータスコード（200）
テキストフレーズ（OK）

からなります。
②ヘッダ

リクエストメッセージと同様です。今回でいうとContent-TypeヘッダでHTMLのMIMEメディアタイプとmその文字エンコーディング方式（utf-8）を指定しています。
③ボディ

ヘッダとボディは空行で区切られます。この例ではボディにHTMLが含まれています。ボディにはバイナリデータも入れられます。

 3.2.3 HTTPメソッド以下に9つのHTTPメソッドを記載しておきます。この中でも主に使うのは6,7つほどです。下のTRACE, CONNECTはほとんど利用しません。


メソッド
主な用途
特徴


GET
リソースの取得
リクエストのデータはURLに含まれ、データの取得専用。副作用を持たない（安全性あり）。

HEAD
リソースのヘッダー情報のみを取得
GETと同様だが、ボディ（内容）は返さない。効率的にリソースの存在や更新を確認可能。

POST
リソースの作成・データの送信
データの送信やサーバー側でのリソース作成に使用。送信データはリクエストボディに含まれる。

PUT
リソースの完全な置き換え
指定したリソースを作成または完全に更新。既存リソースがない場合は新規作成される。

PATCH
リソースの部分更新
指定リソースの一部だけを更新するために使用。

DELETE
リソースの削除
指定したリソースを削除する。

OPTIONS
サーバーがサポートするメソッドや設定を確認
特定リソースやサーバー全体のサポート状況を取得するためのメソッド。

TRACE
サーバーとの通信経路を確認
リクエストがどのように処理されたかを確認するために使うが、セキュリティ上の問題で使用は非推奨。

CONNECT
トンネルを確立して通信を行う
主にHTTPS通信時にプロキシ経由で安全な接続を確立するために使用。


 3.2.4 ステータスコード

カテゴリ
説明
例


1xx

情報：処理が継続中であることを通知。
100 Continue, 101 Switching Protocols

2xx

成功：リクエストが正常に処理されたことを通知。
200 OK, 201 Created, 204 No Content

3xx

リダイレクト：リソースの移動や他のURLへの誘導。
301 Moved Permanently, 302 Found, 304 Not Modified

4xx

クライアントエラー：クライアント側のリクエストに問題あり。
400 Bad Request, 401 Unauthorized, 404 Not Found

5xx

サーバーエラー：サーバー側の処理に失敗。
500 Internal Server Error, 502 Bad Gateway

!特に3xx, 4xx, 5xxの場合は要注意です。

リダイレクト（3xx）：SEOにおいて適切にリダイレクトを設定することが重要です（特に301 vs 302）。

エラーコード（4xx, 5xx）：エラーの原因を迅速に特定し、適切なレスポンスを返すことがユーザー体験を向上させます。

 3.3 プロトコルとしてのHTTPを特徴づけるステートレス性HTTPは1回のリクエストとレスポンスが完結するプロトコルです。

ステートレス性とは、通信プロトコルが個々のリクエストとレスポンスを独立したものとして扱い、サーバがリクエストとリクエストの間で状態（ユーザーの履歴やセッション情報など）を保持しない性質のことです。

 3.3.1 ステートフルなやり取り客：こんにちは。
店員：いらっしゃいませ。〇〇バーガーへようこそ。
客：ハンバーガーセットをお願いします。
店員：サイドメニューは何になさいますか？
客：ポテトで。
店員：ドリンクは何になさいますか？
客：コーラで。
店員：プラス50円でドリンクをLサイズにできますがいかがですか？
客：Mでいいです。
店員：以上でよろしいでしょうか？
客：はい。
店員：かしこまりました。

 3.3.2 ステートレスなやり取り客：こんにちは。
店員：いらっしゃいませ。〇〇バーガーへようこそ。
客：ハンバーガーセットをお願いします。
店員：サイドメニューは何になさいますか？
客：ハンバーガーセットをポテトでお願いします。
店員：ドリンクは何になさいますか？
客：ハンバーガーセットをポテトとコーラでお願いします。
店員：プラス50円でドリンクをLサイズにできますがいかがですか？
客：ハンバーガーセットをポテトとコーラ(M)でお願いします。
店員：以上でよろしいでしょうか？
客：ハンバーガーセットをポテトとコーラ(M)でお願いします。以上。
店員：かしこまりました。
どうでしょうか。私たちの日常会話とは全く違うことがわかりますこの例から次のことがわかります。

- ステートフルなやり取りは簡潔

- ステートレスややり取りは冗長

- ステートフルなやり取りでは。サーバがクライアントのそれまでの注文を覚えている

- ステートレスなやり取りでは、クライアントは毎回全ての注文を繰り返ししている
ステートフルなやり取りはサーバ（店員）がクライアントのそれまでの注文を覚えていることが前提となっています。しかしこの前提があることで、サーバが重くなってしまうことは想像に容易いでしょう。

 3.3.3 ステートレス性のメリットこの問題を解決するのがステートレスなアーキテクチャです。ステートレスではクライアントがリクエストメッセージに必要な情報を全て含めます。この利点は以下のとおりです。


シンプルさ：サーバがリクエスト間の状態を管理しないため、設計が簡単で拡張性が高い。



スケーラビリティ：サーバが状態を保持しないことで、複数のサーバ間で負荷分散が容易になる。



リソース効率：サーバがクライアントの状態を記憶しないため、メモリやストレージの消費が少ない。

このシンプルさこそがHTTPの醍醐味です。

 3.3.4 ステートレス性の欠点もちろん欠点も存在します。
パフォーマンスの低下
送信するデータ量が多くなる
認証など、サーバに負荷がかかる処理を繰り返す
このようにメッセージの冗長性が故に、どうしてもデータ量が多くなるという欠点はあります。
しかし、それでもこのシンプルさこそがHTTPのいちばんの特長です。

 4. HTTPの歴史とバージョンの変遷インターネットの基盤として欠かせないHTTP（HyperText Transfer Protocol）。その歴史は1990年代初頭に始まり、現在も進化を続けています。ここではHTTPの誕生から最新バージョンまでの歴史と特徴を解説します。より深く知りたい方は詳細からご確認ください。


バージョン
時期
特徴


HTTP/0.9
1990
使用可能なメソッドはGETのみ。
テキストのみを転送できる。
リクエストはメソッド名とリソースのパスだけのワンラインプロトコル。
レスポンスはファイル自身のみでヘッダやステータスコードもない。

HTTP/1.0
1996
プロトコルのバージョンをスタートラインに含む。
レスポンスのステータスラインでリクエストの成功失敗を判定する。
ヘッダにメタデータを含めることでHTML以外のファイルも転送可能に。

HTTP/1.1
1997
通信内容を暗号化するためのTLSというプロトコルをサポート。
パイプライン機能の追加などによる通信のレイテンシの削減。
約20年以上にわたり広く使われ、現在も多くのシステムで活用されている。

HTTP/2
2015
高速化されたプロトコル。
テキスト形式ではなくバイナリ形式のプロトコル。
同じコネクションで複数のリクエストを並行して処理できる。

HTTP/3
2018
トランスポート層にTCP/TLSの代わりにQUICというプロトコルを使用。
QUICにより従来よりハンドシェイクが早い。
一層の高速化が実装される。

HTTPの歴史と詳細
 4.1 HTTPの誕生と初期バージョン
 4.1.1 HTTP/0.9 - 最初のプロトコル登場年：1991年

開発者：ティム・バーナーズ＝リー（World Wide Webの発明者）

特徴：
テキストのみのデータ転送に対応。
非常にシンプルな設計で、GETメソッドのみをサポート。
ヘッダーの概念がなく、リクエストも単純な一行で構成されていました。

例：
GET /index.html

 4.1.2 HTTP/1.0 - 実用化への第一歩登場年：1991年

特徴：

ヘッダーの導入により、より柔軟な通信が可能に
新しいメソッド（POST, HEAD）が追加
テキスト以外のリソース（画像やファイル）の転送に対応
ステートレス性の影響でリクエストごとに新しいTCP接続が必要 → 遅延が発生すると言う課題が残る

 4.2 HTTP/1.1 - 長期にわたる標準登場年：1997年

RFC: RFC 2068（1997年）、RFC 2616（1999年）

主な改良点：

持続的接続（Persistent Connection）：1つのTCP接続を複数のリクエストで利用可能にし、効率を向上

パイプライン化：リクエストを並列で送信することで、待ち時間を短縮

新しいヘッダー：キャッシュ制御（Cache-Control）や条件付きリクエスト（If-Modified-Since）の導入で効率的な通信を実現

新メソッド：PUT, DELETE, OPTIONS など
評価：約20年以上にわたり広く使われ、現在も多くのシステムで活用されています。

 4.3 HTTP/2 - 高速化の新時代登場年：2015年

RFC: RFC 7540

背景: Webページの複雑化により、HTTP/1.1のパフォーマンス限界が顕著になりました。

主な特徴：
バイナリプロトコル:テキストベースからバイナリベースへ移行し、効率性を向上
マルチプレックス通信:単一のTCP接続で複数のリクエスト/レスポンスを同時処理
ヘッダー圧縮:HTTPヘッダーのデータ量を削減することで、転送効率を向上
サーバープッシュ:必要になるリソースを事前にクライアントへ送信。
評価:ページロードの高速化に大きく貢献し、モバイル時代に適した仕様となりました。

 4.4 HTTP/3 - 新たなネットワークプロトコル登場年：2020年

RFC: RFC 9114

背景: HTTP/2の問題点であるTCPの制約（ヘッドオブラインブロッキングなど）を克服しています。

主な特徴：
QUICプロトコル:TCPの代わりにUDPをベースに設計。接続の高速化（0-RTT）とパケットロス耐性を強化。
セキュリティの標準化:TLS 1.3を標準搭載
一層の低遅延化:特にモバイル環境や不安定なネットワークで威力を発揮
評価:高速性と安定性を兼ね備え、次世代のWeb通信の主流へ。

 4.5 まとめHTTPは、Webの成長とともに進化してきました。そのバージョンごとの変更は、常にWebのニーズに応えるための改良の積み重ねです。
HTTP/1.1: 長期にわたる標準としてインターネットの発展を支えた。

HTTP/2: パフォーマンス改善にフォーカスし、高速化を実現。

HTTP/3: モバイル時代に対応する新たな基盤としての地位を確立。
Web技術の進化に合わせ、HTTPもさらに進化を続けるでしょう。今後登場する可能性のある新しいバージョンにより、どのような未来が開けるのか注目していきたいです。

 5. 参考文献https://qiita.com/yutoo89/items/1203fdfeef76278570ea

https://zenn.dev/rayto312/articles/6c84f7be173f8c

https://www.bbc.co.uk/bitesize/articles/zgwnsbk

メソッド	主な用途	特徴
GET	リソースの取得	リクエストのデータはURLに含まれ、データの取得専用。副作用を持たない（安全性あり）。
HEAD	リソースのヘッダー情報のみを取得	GETと同様だが、ボディ（内容）は返さない。効率的にリソースの存在や更新を確認可能。
POST	リソースの作成・データの送信	データの送信やサーバー側でのリソース作成に使用。送信データはリクエストボディに含まれる。
PUT	リソースの完全な置き換え	指定したリソースを作成または完全に更新。既存リソースがない場合は新規作成される。
PATCH	リソースの部分更新	指定リソースの一部だけを更新するために使用。
DELETE	リソースの削除	指定したリソースを削除する。
OPTIONS	サーバーがサポートするメソッドや設定を確認	特定リソースやサーバー全体のサポート状況を取得するためのメソッド。
TRACE	サーバーとの通信経路を確認	リクエストがどのように処理されたかを確認するために使うが、セキュリティ上の問題で使用は非推奨。
CONNECT	トンネルを確立して通信を行う	主にHTTPS通信時にプロキシ経由で安全な接続を確立するために使用。

カテゴリ	説明	例
1xx	情報：処理が継続中であることを通知。	100 Continue, 101 Switching Protocols
2xx	成功：リクエストが正常に処理されたことを通知。	200 OK, 201 Created, 204 No Content
3xx	リダイレクト：リソースの移動や他のURLへの誘導。	301 Moved Permanently, 302 Found, 304 Not Modified
4xx	クライアントエラー：クライアント側のリクエストに問題あり。	400 Bad Request, 401 Unauthorized, 404 Not Found
5xx	サーバーエラー：サーバー側の処理に失敗。	500 Internal Server Error, 502 Bad Gateway

バージョン	時期	特徴
HTTP/0.9	1990	使用可能なメソッドは`GET`のみ。テキストのみを転送できる。リクエストはメソッド名とリソースのパスだけのワンラインプロトコル。レスポンスはファイル自身のみでヘッダやステータスコードもない。
HTTP/1.0	1996	プロトコルのバージョンをスタートラインに含む。レスポンスのステータスラインでリクエストの成功失敗を判定する。ヘッダにメタデータを含めることでHTML以外のファイルも転送可能に。
HTTP/1.1	1997	通信内容を暗号化するためのTLSというプロトコルをサポート。パイプライン機能の追加などによる通信のレイテンシの削減。約20年以上にわたり広く使われ、現在も多くのシステムで活用されている。
HTTP/2	2015	高速化されたプロトコル。テキスト形式ではなくバイナリ形式のプロトコル。同じコネクションで複数のリクエストを並行して処理できる。
HTTP/3	2018	トランスポート層にTCP/TLSの代わりにQUICというプロトコルを使用。 QUICにより従来よりハンドシェイクが早い。一層の高速化が実装される。

1. はじめに

2. そもそもWebとは？

2.1 インターネットとWebの違い

2.2 Webを構成する主な要素

3. HTTPの仕組みと特徴

3.1 TCP/IPとは何か

3.1.1 ネットワークインターフェース層

3.1.2 インターネット層

3.1.3 トランスポート層

3.1.4 アプリケーション層

3.2 HTTPのメッセージ構造

3.2.1 リクエストメッセージ

3.2.2 レスポンスメッセージ

3.2.3 HTTPメソッド

3.2.4 ステータスコード

3.3 プロトコルとしてのHTTPを特徴づけるステートレス性

3.3.1 ステートフルなやり取り

3.3.2 ステートレスなやり取り

3.3.3 ステートレス性のメリット

3.3.4 ステートレス性の欠点

4. HTTPの歴史とバージョンの変遷

4.1 HTTPの誕生と初期バージョン

4.1.1 HTTP/0.9 - 最初のプロトコル

4.1.2 HTTP/1.0 - 実用化への第一歩

4.2 HTTP/1.1 - 長期にわたる標準

4.3 HTTP/2 - 高速化の新時代

4.4 HTTP/3 - 新たなネットワークプロトコル

4.5 まとめ

5. 参考文献

Discussion