📢 Webサイト閉鎖と移転のお知らせ
このWebサイトは2026年9月に閉鎖いたします。
新しい記事は移転先で追加しております。（旧サイトでは記事を追加しておりません）
| 14行目: | 14行目: | ||
<br> | <br> | ||
また、HTTPはオンデマンドでWebページを更新するために、文書の一部をフェッチするのにも使用される。<br> | また、HTTPはオンデマンドでWebページを更新するために、文書の一部をフェッチするのにも使用される。<br> | ||
<br><br> | |||
== HTTPの基本 == | |||
==== 単純な構造 ==== | |||
HTTP/2のような、HTTPメッセージをフレームにカプセル化することにより複雑さが加わったとしても、HTTPは一般的にシンプルで人間が読めるように設計されている。<br> | |||
<br> | |||
HTTPメッセージは人間が読んで理解することができ、開発者にとってはテストが容易になる。<br> | |||
<br> | |||
==== 拡張可能性 ==== | |||
HTTP/1.0で導入されたHTTPヘッダは、このプロトコルの拡張を容易にする。<br> | |||
<br> | |||
クライアントとサーバが新しいヘッダのセマンティクスについて合意するだけで、新しい機能を導入することもできる。<br> | |||
<br> | |||
==== HTTPはステートレス、かつ、非セッションレス ==== | |||
HTTPはステートレスである。<br> | |||
同じコネクション上で連続して実行される2つのリクエストの間にはリンクがない。<br> | |||
<br> | |||
例えば、eコマースのショッピングバスケットを使用する場合、特定のページと首尾一貫してやりとりしようとするユーザにとって問題となる見込みがある。<br> | |||
しかし、HTTPのコア自体はステートレスであるが、HTTPクッキーはステートフルなセッションの使用を可能にする。<br> | |||
<br> | |||
ヘッダの拡張性を使用して、HTTPクッキーはワークフローに追加されて、各HTTPリクエストで同じコンテキスト、つまり、同じ状態を共有するセッション生成を可能にする。<br> | |||
<br> | |||
==== HTTPとコネクション ==== | |||
コネクションはトランスポート層で制御されるため、基本的にHTTPの範囲外である。<br> | |||
HTTPは基礎となるトランスポートプロトコルがコネクションベースであることを要求しているわけではない。<br> | |||
インターネット上で最も一般的な2つのトランスポートプロトコルの内、TCPは信頼性があり、UDPは信頼性がない。<br> | |||
したがって、HTTPは、コネクションベースであるTCP標準に依存している。<br> | |||
<br> | |||
クライアントとサーバがHTTPリクエスト / レスポンスのペアを交換する前に、TCPコネクションを確立する必要がある。<br> | |||
HTTP/1.0のデフォルトの動作は、HTTPリクエスト / レスポンスのペアごとに別々のTCPコネクションをオープンすることである。<br> | |||
これは、複数のリクエストが連続して送信される場合、1つのTCPコネクションを共有するよりも効率が悪い。<br> | |||
<br> | |||
この欠陥を軽減するために、HTTP/1.1ではパイプライン化（実装が難しいことが判明）と持続的接続が導入された。<br> | |||
基礎となるTCP接続は、Connectionヘッダを使用して部分的に制御できる。<br> | |||
HTTP/2はさらに一歩進み、単一のコネクション上でメッセージを多重化することにより、コネクションをより効率的にする。<br> | |||
<br> | |||
現在では、HTTPにより適したトランスポートプロトコルを設計するための実験が進行中である。<br> | |||
例えば、GoogleはUDPをベースに、より信頼性が高く効率的なトランスポートプロトコルを提供するQUICの実験を行っている。<br> | |||
<br><br> | |||
== HTTPで制御できること == | |||
HTTPのこの拡張可能な性質は、時代とともに、Webの制御と機能性の向上を可能にしてきた。<br> | |||
キャッシュや認証方法は、HTTPの歴史の初期に扱われていた機能である。<br> | |||
対照的に、オリジン制約を緩和する機能は、2010年代に追加された。<br> | |||
<br> | |||
HTTPで制御可能な一般的な機能を、以下に示す。<br> | |||
* キャッシュ | |||
*: ドキュメントをどのようにキャッシュするかは、HTTPで制御できる。 | |||
*: サーバはプロキシやクライアントに、何をどれくらいの期間キャッシュするかを指示することができる。 | |||
*: <br> | |||
*: クライアントは中間キャッシュプロキシに、保存されたドキュメントを無視するように指示できる。 | |||
* オリジン制約の緩和 | |||
*: 盗聴やその他のプライバシー侵害を防ぐため、WebブラウザはWebサイト間の厳格な分離を強制している。 | |||
*: 同じオリジンからのページのみが、Webページの全ての情報にアクセスできる。 | |||
*: このような制約はサーバにとって負担であるが、HTTPヘッダは、サーバ側でこの厳密な分離を緩和することができ、ドキュメントが異なるドメインからの情報のパッチワークになることを可能にする。 | |||
* 認証 | |||
*: ページによっては、特定のユーザのみがアクセスできるように保護されている場合がある。 | |||
*: BASIC認証は、WWW-Authenticateや同様のヘッダを使用する、または、HTTPクッキーを使用して特定のセッションを設定することにより、HTTPによって提供される場合がある。 | |||
* プロキシとトンネリング | |||
*: サーバやクライアントは、ほとんどの場合はイントラネット上にあり、他のコンピュータから本来のIPアドレスを隠している。 | |||
*: そして、HTTPリクエストは、このネットワークの障壁を越えるためにプロキシを経由する。 | |||
*: <br> | |||
*: また、全てのプロキシがHTTPプロキシというわけではない。 | |||
*: 例えば、SOCKSプロトコルは、より低いレベルで動作する。 | |||
*: FTPのような他のプロトコルは、これらのプロキシで処理することができる。 | |||
* セッション | |||
*: HTTPクッキーを使うことにより、リクエストとサーバの状態を結びつけることができる。 | |||
*: 基本的なHTTPは、ステートのないプロトコルであるにもかかわらず、セッションを作成する。 | |||
*: これは、eコマースのショッピングのみでなく、ユーザによる出力の設定を可能にするあらゆるサイトに役立つ。 | |||
<br><br> | <br><br> | ||