ＨＴＴＰとＷｅｂページの関係
ＨＴＴＰは，ＷｅｂブラウザとＷｅｂサーバとの間でのデータ交換のための通信プロトコルです。Ｗｅｂページ閲覧は、通常はＨＴＴＰで行われます。
ＨＴＴＰはアプリケーション層のプロトコルで、下位プロトコルはＴＣＰです。ＴＣＰヘッダのポート番号８０によりＨＴＴＰが呼び出されます。
ＷｅｂブラウザでＵＲＬ「http://www.example.co.jp/webtext/index.html」と入力すると、まずＤＮＳにより、ドメイン名 www.example.co.jp に対応するＩＰアドレス 150.111.222.26 を取得します。
ＨＴＴＰは、このメッセージをＴＣＰを用いてＷｅｂサーバ www.example.co.jp に送ります。
Ｗｅｂサーバは、サーバ内のＨＴＭＬファイル /webtext/index.html をＨＴＴＰによりＷｅｂページに返送します。
Ｗｅｂブラウザは、送られてきたファイルを解析して、ディスプレイに表示します。この処理をレンダリングといいます。
- ＵＲＬ入力だけでなく、リンク部分をクリックしたとき，フォームで「送る」をクリックしたときなどでもＷｅｂブラウザが自動的にＨＴＭＬにより送受信します。
- Ｗｅｂページは、通常はマークアップ言語ＨＴＭＬで記述されたハイパーテキストです。ＨＴＴＰは、Ｗｅｂブラウザ⇔Ｗｅｂサーバ間のデータ交換プロトコルでファイル形式を限定しません。
ＨＴＴＰ（HyperText Transfer Protocol）
ここまでに、ＷｅｂブラウザとＷｅｂサーバ間の接続が確立しているとします。
ＨＴＴＰリクエスト（要求）
ＷｅｂブラウザからＷｅｂサーバへの要求です。次のような形式になっています。
- メソッド
ＧＥＴ、ＰＯＳＴ、ＨＥＡＤなどを指定します。 - ターゲット
閲覧したいＷｅｂページ。ＵＲＬのパスの部分です。 - バージョン
現在では、HTTP/1.1とHTTP/2があります。HTTP/2に関しては後述します。 - ヘッダフィールド
ホスト名（Ｗｅｂサーバ名のドメイン名）です。 - メッセージ本体
次のような項目を、必要に応じて指定できます。
Param：パラメータの指定
Accept-Language：受理可能な言語
Authorization：認証の必要なユーザＩＤ、パスワード
Cookie：持っているクッキー情報
If-Modified-Since：指定日時以降に更新されていれば実行
User-Agent：Ｗｅｂブラウザの名称・バージョン
ＧＥＴ、ＰＯＳＴ
ＨＴＴＰリクエストでよく使われるメソッドにＧＥＴとＰＯＳＴがあります。
どちらも同じ機能で、結果としてＨＴＴＰリクエストを発行するのですが、リクエストの記述や送信データの制限などが異なります。
- パラメータを付加するとき、
ＧＥＴでは、通常はＵＲＬをhttp:///webtext/index.html?name=kogure&sex=man ...と記述するので、
ＨＴＴＰリクエストでは、
ＧＥＴ：/webtext/index.html?name=kogure&sex=man ...
となります。
ＰＯＳＴでは、通常はＨＴＭＬでのＦＯＲＭで作成し、そこからＷｅｂサーバに渡すので、
ＰＯＳＴ：/webtext/index.html ...
Param：name=kogure, sex=man （メッセージ本体に記述）
になります。
ＧＥＴではパラメータを直接見ることができますが、ＰＯＳＴでは何らかの手段を講じないと見えません。<\li> - ＧＥＴで送信できるのはバイナリデータだけでデータ量に制限があります。Ｗｅｂブラウザからの送信なので、重要な制限ではありませんが、画像などをＷｅｂサーバに送って修正してもらうような場合にはＰＯＳＴを用います。画像サービスＷｅｂページ作成者側の留意点です。
- パラメータ指定したＷｅｂページをブックマーク（お気に入り）に保存するとき、ＧＥＴならばＵＲＬにパラメータが記述しているので、同じページが再現できますが、ＰＯＳＴではパラメータを指定しなかったときの画面になります。
ＨＴＴＰレスポンス（応答）
Ｗｅｂサーバからの応答です。ＨＴＴＰリクエストと同じ形式です。
- ステータスコード
「200 OK」要求が成功した場合
「404 Not Found」Ｗｅｂページが存在しない
「401 Unauthorized」認証エラー
「403 Forbidden」アクセス権限がない
「500 Internal Server Error」サーバ内部のエラー発生による処理中断 - ヘッダフィールド
Content-Language：使用言語
Content-Encoding：エンコーディング（UTF-8, Shift-JISなど）
Date：レスポンス作成日時
Last-Modified：ページの最終更新日時
Set-Cockie：保存するクッキーの情報
Cache-Control：キャッシュの可否、ＴＴＬ（保存期間）など
WWW-Authenticate：要求する認証の種類などの情報 - メッセージ本体
ＷｅｂページのＨＴＭＬ文書のソースリストです。Ｗｅｂブラウザは、これを解釈してディスプレイに表示します。
伝送手段の改善
Ｗｅｂページは、ＨＴＭＬファイルだけでなく、画像、ＣＳＳ、スクリプトなどの多数のファイルがあり、それらがすべてダウンロードしないとレンダリングできません(部分的に開始することはできますが）。
ＷｅｂサーバはＨＴＭＬファイルの内部をしりません。ＷｅｂブラウザがＨＴＭＬファイルを解析する過程でどのファイルが必要かわかるのですから、そのたびにＨＴＴＰリクエストとＨＴＴＰレスポンスが行われます。
また、Ｗｅｂページの中にはＦＯＲＭでデータを入力させ、その結果を返すものもあります。この場合もＨＴＴＰリクエストとＨＴＴＰレスポンスが行われます。
ＨＴＴＰはＴＣＰの上位プロトコルです。当初のＨＴＴＰ規格では、
ＴＣＰでパソコンとＷｅｂサーバ間でのコネクションの確立をする。
ＨＴＴＰリクエストを送り、ＨＴＴＰレスポンスを返す。
ＴＣＰでコネクションの切断をする。
というように、コネクションの確立と切断を頻繁に行う必要がありました（左図）。
このような非効率を解消するために、ＨＴＴＰ／１．１では次の改善が行われました。
- ＨＴＴＰ Keep Alive（中図）
- 1つのＴＣＰコネクションに複数のＨＴＴＰリクエストを実行できる機能です。これによりコネクションの確立を１回だけで済ませられます。コネクションの確立にはハンドシェイクなど負荷が高い処理ですので、大きな効果があります。
- ＨＴＴＰパイプライン（右図）
- 複数のＴＣＰコネクションを１つにまとめる並列ＴＣＰコネクション技術を用いて、ＨＴＴＰレスポンスを待たずに次のＨＴＴＰリクエストを連続的に送り、Ｗｅｂサーバも連続的にＨＴＴＰレスポンスを返す機能です。
ＨＴＭＬファイルを解析して、他のファイル群がわかるのですから、最初の１回はＨＴＴＰレスポンスを待つ必要がありますが、それ以降は連続で行うことができます。
ＨＴＴＰ／２
HTTP/1.1との互換性を保ちつつ、Ｗｅｂ効率化向上のための多様なな機能をサポートするプロトコルです。２０１５年にＩＥＴＦ（Internet Engineering Task Force）によりRFC7540として策定されました。
ＨＴＴＰ／２を利用するにはＷｅｂブラウザとＷｅｂサーバがこれに対応している必要がありますが、現在のＷｅｂブラウザはほとんど対応しています。
- ストリームの多重化
- ＨＴＴＰパイプラインはＨＴＴＰ／１．１でもあった技術ですが、リクエストとレスポンスを同時に行うことはできませんでした。それを1つの接続上にストリームと呼ばれる仮想的な双方向シーケンスを作ることにより、まだリクエストが続いている間にレスポンスを返すことができます。
- ストリームの優先度
- ＨＴＴＰパイプラインには「サーバはリクエストの順番通りにレスポンスを返さなければならない」という制限があります。HTTP/2ではクライアントがPRIORITYフレー ムを用いてストリームに優先度を付けることができるようになりました。
レンダリングに必要なＨＴＭＬやＣＳＳを優先し、あまり関係しないJavascriptなどは後回しにすることにより、ディスプレイ表示の開始を早めることができます。 - ヘッダフィールドの圧縮
- Ｗｅｂページの高度化により、ヘッダフィールドの容量が大きくなりました。コンテンツとともにヘッダフィールドも圧縮すること、以前送信した内容は差分だけを送信することなどの工夫がされました。
- フロー制御
- ＴＣＰのフロー制御に加えて、ストリーム毎にフロー制御が可能になりました。
ＨＴＴＰとセッション
ここでは、Ｗｅｂページからリンクなどにより他のページに移動するときの、前ページで指定した情報の受渡しをテーマにします。
ＨＴＭＬはステートレスのプロトコルです。ステートレスとは、セッションの概念をもたないということ、個々のＨＴＴＰの通信は独立で、以前の状態を保持しないということです。
例えば、本人確認が必要なＷｅｂサイトにアクセスするとき、最初のＷｅｂページでユーザＩＤやパスワードを入力したとします。そのページから他のページに移動するとき、特に手段を講じないならば、移動したＷｅｂページは、前のページへのアクセスとは独立しており、誰からのアクセスかを判別できないので、移動したページでもユーザＩＤやパスワードを入力しなければなりません。
ユーザＩＤとパスワードだけでしたら、前のページでのリンクのＵＲＬにそれらをパラメータとして記述すれば、後のページに渡すことができましょう。しかし、買物サイトのように、商品、送り先、支払方法など多くの情報を渡すときは、パラメータにするのは不適切です。
前のページまでの情報をファイルにしておき、後のページでそれを読み込むような手段になります。
このような方法だと、後のページでファイルを特定する仕組みが重要になります。
しかも、本の注文をしながら、過去の注文の配達状況を知りたいというように、同じ利用者が同時にこのサイトにアクセスしている場合も考えられます。ユーザＩＤとパスワードだけだと、どちらのデータなのか不明になることもあります。
ここでのセッションとは、利用者が一連の操作の開始から終了まで、すなわち、最初のページを閲覧してから注文のページを完了するまで、あるいは中断するまでの期間を指します。その間を一つのセッションだとして管理します。
すなわち、最初のページにアクセスしたときにセッションＩＤを付けてファイルとの対応を作ります。そして次ページからは、セッションＩＤにより対応するファイルを特定すればよいのです。
ステートレスなＨＴＴＰをセッションＩＤにより仮想的にステートフルな環境にするのだといえます。
クッキー（Cookie）
「ファイルを作る」方法のうち、代表的なものがクッキーです。
Ｗｅｂサーバが得た情報をＷｅｂブラウザ側に保存し、他のＷｅｂページで読み込む方法です。
ＨＴＴＰリクエスト／ＨＴＴＰレスポンスのメッセージ本体にもCookieオプションがあるように、ＨＴＴＰでの標準機能になっています。
クッキーは同一セッション内での連続した処理にも使えますし，これまでの閲覧履歴を入れておくような断続的な情報記録にも使えます。Ｗｅｂブラウザを閉じるたび（セッションが切れるたび）に消去されるクッキーを一時的クッキー，有効期限を決めておきそれまで残るクッキーを永続的クッキーといいます。
クッキーは便利なのですが，個人情報を記録していることもありますし，これ自体には暗号化の機能もないので，セキュリティの面で慎重な取扱が必要になります。
Ｗｅｂサーバの機能
Ｗｅｂサーバは，単にＷｅｂページを保管して閲覧要求に応じるだけでなく，多様な機能を必要とします。
Ｗｅｂサーバ管理ソフト
Ｗｅｂサーバを管理するソフトウェアです。Ｗｅｂサーバというとき物理的なサーバを指すよりもＷｅｂサーバ管理ソフトを指すことが多くなってきました。
代表的なＷｅｂサーバ管理ソフトには、ＯＳＳ（オープンソースソフトウェア）のApache、マイクロソフトのＩＩＳ（Internet Information Services）などがあります。
サーバ側でのＨＴＭＬ生成
単に事前に作成したファイルをそのままＷｅｂブラウザで表示するコンテンツを静的コンテンツといいます。それに対して、ＦＯＲＭなどで指定したデータにより表示される画面が変わるような動的に生成されるコンテンツを動的コンテンツといいます。
動的コンテンツには、JavaScriptのようにＷｅｂブラウザ側で動作するクライアントサイドタイプと、Ｗｅｂサーバ側で動作する（Ｗｅｂサーバ側でＨＴＭＬファイルを生成してＷｅｂブラウザに送る）サーバサイドタイプがあります。
このサーバサイドタイプの処理がＷｅｂサーバの機能の一つです。これには、ＣＧＩやＩＳＡＰＩなどがあります。
ＣＧＩ（Common Gateway Interface）
ＨＴＭＬだけでは，提供できるサービスが限定されます。特にインタラクティブな利用をするには，ＨＴＭＬのフォームによりデータを入力させ，それによって，ＨＴＭＬとは独立したプログラムにより処理をして，その結果をＷｅｂブラウザに戻すような機能が必要になります。
その機能の標準的なプロトコルがＣＧＩです。また、ＣＧＩで呼ばれるプログラムのことをＧＣＩということもあります。
ＩＳＡＰＩ（Internet Server Application Programming Interface）は、ＨＴＭＬ内で記述したスクリプトをサーバ内で処理してその結果をＨＴＭＬに渡すしくみです。そのプログラムをサーブレットともいいます。これも含めてＣＧＩということもあります。
ＣＧＩ／ＩＳＡＰＩでは、このようなインタフェースをもつ言語なら何でもよいのですが、ＰＨＰ、Ｐｅｒｌ、Ｒｕｂｙなどの軽量言語が多く使用されます。
ＨＴＴＰでの認証
ＷｅｂブラウザとＷｅｂサーバ間の通信では、個人情報など秘密なデータの送受信もあります。秘密通信に特化したＨＴＴＰには後述のＨＴＴＰＳがありますが、ＨＴＴＰ自体も単純なセキュリティ対策がとられています。
ＨＴＴＰレスポンスのヘッダフィールドにWWW-Authenticate（要求する認証の種類などの情報）があり、次のような認証方法が選択できます。
ＨＴＴＰリクエストヘッダフィールドAuthorizationで認証に必要なユーザＩＤ、パスワードなどを与えることができます。
認証に失敗すると、「401 Unauthorized」認証エラーのステータスコードが表示されます。
- Anoonymous認証
- 匿名（anoonymous）でのアクセスを許すもので，ほとんど認証はしていません。時によっては電子メールアドレスを聞くことがありますが，それも真偽をチェックしません。昔の平和な時代に共同利用するために行われた方式だといえます。
- Basic認証
- Ｗｅｂサーバ側ではパスワードを暗号化して保管しますが，ＷｅｂブラウザとＷｅｂサーバの間では暗号化せずに通信します。
- Digest認証
- ユーザ名とパスワードを，ＭＤ５というハッシュ関数を用いて暗号化します。
ＨＴＴＰＳ（HTTP over SSL/TLS）
通信の暗号化では，ＳＳＬ（Secure Sockets Layer）およびその後継のＴＬＳ（Transport Layer Security）が広く用いられています。→参照：>ＳＳＬ／ＴＬＳ
ＨＴＴＰＳは、ＨＴＴＬをＳＳＬ／ＴＬＳに対応したものです。すなわち、ＷｅｂブラウザとＷｅｂサーバの間の双方向の通信にＳＳＬ／ＴＬＳによる暗号化や認証を取り込んだものです。
それ以外にＨＴＴＰＳがＨＴＴＰと異なるのは、ＨＴＴＰの下位プロトコルがＴＣＰなのに対して、ＨＴＴＰＳではＳＳＬなことです。すなわち、ＴＣＰでのコネクション確立をする以前に、セッションの確立（暗号方式の確認）が行われます。
ＨＴＴＰＳを利用するには、次のことが必要になります。
サーバ側では、サーバ認証を受けること。ＷｅｂサイトをＨＴＭＬＳ対応にすること。
利用者側はＵＲＬで https://～ のように記述すること。
ＨＴＴＰＳでの通信ができるＷｅｂページを開くと右下に鍵マークが表示され、それをクリックすると電子証明書が表示されます。
近年はＨＴＴＰＳへの移行が推奨されており、それに対応していないＷｅｂページを開くとＵＲＬ欄に非対応の表示が出るＷｅｂブラウザが多くなっています。
