アプリケーションプロトコル「HTTP(HyperText Transfer Protocol)」のポイント

連載 [第3回] :

2018年9月5日(水)

はじめに

今回は、アプリケーションプロトコル「HTTP(HyperText Transfer Protocol)」について解説します。HTTPはテキストや画像などの情報をやり取りする目的で規格化されたプロトコルです。インターネット上に構成されている世界規模の情報網「WWW(World Wide Web)」を支える通信プロトコルとして広く利用されています。主要なアプリケーションプロトコルの1つとして挙げられることから、試験で出題される機会が多くあります。

HTTPのポイント

HTTPのバージョン

HTTPはスイスの欧州原子核研究機構(CERN)により原型であるバージョン0.9(HTTP/0.9)が考案された後、バージョン1(HTTP/1.0)が標準化され、RFC1945として公開されました。現在はRFC7230からRFC7235まで連番で公開されているバージョン1.1(HTTP/1.1)と、RFC7540で公開されているバージョン2(HTTP/2)が主流となっています。なお、HTTP/2はHTTP/1.1と互換性を保ちつつ通信の効率化・最適化を実現する規格であり、HTTP/1.1を完全に置き換えることを目的としていません。そのため、HTTPについて学ぶ際にはHTTP/1.1を中心に学習すると良いでしょう。本記事の内容もHTTP/1.1について取り上げています。

HTTP/2の主な特徴は、以下のとおりです。

HTTPのヘッダを圧縮してデータ量を削減する
クライアントからのリクエストなしにデータを送信する、サーバプッシュのサポート
HTTPパイプライン(リクエスト・レスポンスの並列的な処理)の最適化

HTTPの基本構文

HTTPはクライアント(ブラウザなど)がリクエストを送信し、サーバ(Webサーバなど)がレスポンスを返すクライアントサーバ方式で情報をやり取りします。また、HTTPのメッセージフォーマットは、以下のフィールドで構成されています(図1)。

図1：HTTPのメッセージフォーマット

各フィールドの概要を表1に示します。

表1：HTTPの各フィールドの概要

フィールド名	概要
スタートライン	リクエストやレスポンスの内容が含まれるフィールド。リクエストの場合はリクエストライン、レスポンスの場合はステータスラインとも呼ばれる
ヘッダフィールド	クライアントやサーバ、エンティティ(メッセージボディに含まれるデータ)に関する情報が入るフィールド。HTTP通信の詳細な情報が確認できる
メッセージボディ	オプション扱いのフィールドで、HTTP以外の伝えたい情報がある場合は空行を挿入した後にこのフィールドが付与される。リクエストとレスポンスのどちらにも付与される可能性がある

次に、各フィールドの詳細を確認します。

・スタートライン
スタートライン(リクエストライン・ステータスライン)のフィールドは、図2のパラメータで構成されます。これらのうち、メソッド、リクエストURI(Uniform Resource Identifier)、ステータスコードは重要なパラメータです。

図2：スタートラインの構文

メソッドはリクエストの種別です。代表的なメソッドを表2に示します。GETメソッドとPOSTメソッドでは変数を格納する場所が異なり、用途に応じて使い分けられる点に気を付けましょう。

表2：代表的なメソッド

メソッド名	役割
GET	サーバに情報を要求する。変数をスタートラインに含めて送信するため、ブックマークやプロキシサーバなどの通信ログに変数の値が見えてしまう問題がある
POST	サーバに情報を要求する。変数をメッセージボディに含めることから、GETメソッドの問題を防ぐことができる
HEAD	サーバに情報を要求するが、HTTPのみでメッセージボディは要求しない。GETメソッドよりも通信量を減らせることから、状態監視などで利用される
CONNECT	プロキシサーバに指定した通信を透過的に通すよう要求する。Webサーバと直接HTTPS通信を行いたい場合などに利用される

リクエストURIにはメソッドの対象が記述され、リクエストターゲットとも呼ばれます。リクエストURIのフォーマットを図3に示します。

図3：リクエストURIの構文

通常のWebアクセスではHostsヘッダなどで接続先のサーバが指定されるため、パス名やファイル名のみが指定されることが多いです。一方、プロキシサーバを経由する場合は接続先を明記するため、http://から指定されます。

ステータスコードは、リクエストの処理結果をクライアントに通知します。3桁の数字で構成され、3桁目の値でカテゴリ分けされています(表3)。トラブルが発生した際のトラブルシューティングに活用することもできます。ステータスコードの詳細はRFC7231に記載してありますので、気になる方は参照してください。

表3：ステータスコードの役割と概要

ステータスコード	役割	概要
1xx	通知	リクエストを処理している最中に、何らかの情報をクライアントに通知したい場合に送信される。リクエストの処理は継続される
2xx	成功	リクエストの処理が成功した場合に送信される
3xx	リダイレクト	転送先を案内する場合に送信される。新サイトに誘導したい場合や自動的にトップページへ遷移させたい場合などに利用される。転送先はLocationヘッダで指定される
4xx	失敗(クライアント)	クライアント側が原因でリクエストの処理が失敗した場合に送信される
5xx	失敗(サーバ)	サーバ側が原因でリクエストの処理が失敗した場合に送信される

HTTPのセッション維持

HTTPはリクエスト・レスポンスをやり取りして通信を行いますが、やり取りした情報はリクエスト・レスポンス間で引き継ぐことができません(図4)。

図4：HTTPではリクエスト・レスポンス間で情報を引き継げない

そのため、複数のリクエスト・レスポンスで情報を引き継いで処理したい場合はセッションを維持するための仕組みが必要となります。これにはCookieを利用する方法が一般的です。

Cookieはサーバとやり取りした情報をクライアント側に保持させ、その情報を用いてリクエスト・レスポンス間で情報を引き継ぎます。Netscape社の独自仕様として開発されましたが、現在はRFC6265で標準化されています。Cookieはサーバ側からSet-Cookieヘッダが送信されることでクライアント側に保持されます。一方、クライアント側はリクエスト内のCookieヘッダにCookieの情報を含めることで、保持している情報をサーバ側に通知します。このやり取りを繰り返すことで、情報の引き継ぎを実現します(図5)。

図5：Cookieを用いたセッション維持

Set-Cookieヘッダで利用できるパラメータを表4に示します。

表4：Set-Cookieで利用できるパラメータ

パラメータ名	役割
name	クライアント側のCookieに保持させる変数名と値を指定
domain	Cookieを利用できるドメインを指定。複数のサブドメインでCookieを利用したい場合に指定する。指定がない場合はそのホストでのみ利用できる
secure	HTTPSを利用した通信でのみCookieのやり取りを認める。指定がない場合はHTTPでもやり取りされるため、セキュリティ上必須のパラメータ
httponly	HTTPやHTTPSの通信でのみCookieのやり取りを認める。javascriptでのやり取りを防ぐことができるため、セキュリティ上指定することが望ましい

なお、HTTPのセッション維持にはURLリライティングと呼ばれる方式もありました。これはHTML内のリンクにIDを埋め込む方法で、初期の携帯電話などCookieが利用できない端末向けの方法として利用されていました。しかしこの方法はIDの扱いが安全でなく、セキュリティ上の問題があることから現在ではほとんど見かけません。

過去問題の確認

それでは、HTTPに関連した過去問題を確認してみましょう。まずは午前問題からです。

午前問題

問20　Webアプリケーションの脆弱性を悪用する攻撃手法のうち，Webページ上で入力した文字列がPerlのsystem関数やPHPのexec関数などに渡されることを利用し，不正にシェルスクリプトや実行形式のファイルを実行させるものは，どれに分類されるか。

ア HTTPヘッダインジェクション
イ OSコマンドインジェクション
ウクロスサイトリクエストフォージェリ
エセッションハイジャック

（平成27年度秋期午前Ⅱ問題　問20（試験問題から引用））

HTTPのセキュリティ関する問題です。「入力した文字列が～実行させる」の1文から、コマンドを実行させる攻撃方法、すなわちOSコマンドインジェクションの(イ)であるとわかります。この攻撃を防ぐには、クライアント側で入力された文字列がサーバ側でコマンドとして解釈されないように無害化するサニタイジングと呼ばれる仕組みを導入する必要があります。

その他の選択肢もHTTPの脆弱性を突く代表的な攻撃方法です。近年はセキュリティの問題も多く出題されているため、選択肢にある攻撃方法は全て確認しておきましょう。

問14　WebDAVの特徴はどれか。

ア HTTP上のSOAPによってソフトウェア同士が通信して，ネットワーク上に分散したアプリケーションを連携させることができる。
イ HTTPを拡張したプロトコルを使って，サーバ上のファイルの参照や作成，削除及びバージョン管理が行える。
ウ WebアプリケーションからIMAPサーバにアクセスして，ブラウザから添付ファイルを含む電子メールの操作ができる。
エブラウザで“ftp://”から始まるURLを指定して，ソフトウェアなどの大容量ファイルのダウンロードができる。

（平成28年度秋期午前Ⅱ問題　問14（試験問題から引用））

WebDAVに関する問題です。WebDAV(Web-based Distributed Authoring and Versioning)は、Webサーバ上でファイル管理を行えるよう、HTTPを拡張したプロトコルです。解答は(イ)です。

午前問題ではHTTPに関連した通信プロトコルについても出題されるため、過去問題などで気になる単語を見かけた場合は調べておくと良いでしょう。

午後問題

続いて、午後問題を確認します。こちらから平成27年度秋期ネットワークスペシャリスト試験午後Ⅱ問題をダウンロードして、問1の設問2を解いてみてください。

設問2(1)

語句の穴埋め問題です。問題文中の図5の構成を確認すると、PCや新業務サーバのクライアント側のアクセスを中継装置が受信して通信アダプタに送り、通信アダプタは受け取ったリクエストをサーバ側の設備に中継しています。クライアント側の通信を中継するプロキシサーバをフォワードプロキシ、サーバ側への通信を中継するプロキシサーバをリバースプロキシと呼ぶことから、この通信の流れを大まかに描くと図6のようになります。以上より、(う)中継装置、(え)通信アダプタ、(お)リバースが解答になります。

図6：問題文中の図6における通信の流れ

設問2(2)

稼動情報取得のトリガに関する問題です。下線部(a)は④を指しているので、④の通信の概要を確認します。これは、5ページ上部の4つ目のドット(・)部分に記述されています。この記述からは、段階的に更新頻度を短縮させる計画があることが読み取れます(図7)。もし、顧客側の機器で更新頻度を短縮させる作業を行う場合は顧客の拠点が多く、また顧客側の都合もあるため設定変更が非常に煩雑になります。しかし、K社データセンター内の新業務サーバの設定変更で対応できると対象装置は新業務サーバだけとなり、また自社設備であることから作業の都合を付けやすいため、運用上の利点があると考えられます。以上より、解答は「稼動情報の収集周期の変更が容易である。」となります。

図7：5ページ上部の4つ目のドット(・)部分

設問2(3)

タイムスタンプの時刻に関する問題です。問題文中の図6例Ⅱのシーケンスは設備から更新情報が取得できた場合です。If-Modified-Sinceヘッダの付与される条件は5ページ下部の2つ目のドット(・)部分や、6ページ上部のドット(・)部分に記述されています。なお、If-Modified-Sinceヘッダにはキャッシュの更新日時が入ります。対象データの更新日時が指定された時間よりも新しい場合はそのデータを送信するように依頼します。また、Last-Modifiedヘッダには対象データの更新日時が入ります。例ⅡのシーケンスではLast-ModifiedヘッダにTcが含まれてレスポンスが返信されていることから、解答は「Tc」となります。

設問2(4)

TbとTb’の時間が異なる条件を考える問題です。問題文中の図5にあるとおり、通信アダプタは1分間隔の定期更新を行っています。一方、中継装置は不定期もしくは5分間隔～1時間間隔の定期更新を行っています(図8)。そのため、通信アダプタの保持するキャッシュが中継装置のキャッシュよりも新しくなる確率が高くなります。以上のことから、解答は「中継装置より通信アダプタのキャッシュの更新頻度が高く新しいから」となります。

図8：中継装置と通信アダプタの稼働情報の取得条件

設問2(5)

問題文中の図6例Ⅲの状況、すなわち設備から更新情報を取得できなかった場合を2つ考える問題です。１つは5ページ上部の4つ目のドット(・)部分に記述されています(図9)。この場合は、レスポンスそのものが返信されません。もう1つは設備の稼働情報がIf-Modified-Sinceヘッダの更新日時と同じだった場合です。この場合、設備は「304 Not Modified」を返信し、メッセージボディに情報を含めません。以上より、解答は「設備とTCPコネクションが確立できない場合」と「設備がNot Modifiedを応答した場合」となります。

図9：5ページ上部の4つ目のドット(・)部分

設問2(6)

問題文中の図6例Ⅰの周期を長くした場合、すなわち通信アダプタの更新頻度を長くした場合の影響を考える問題です。設問2(4)において、通信アダプタのキャッシュしている稼働情報の方が中継装置の情報よりも新しい場合が多いことが確認できています。また、設問2(5)において、設備が通電されていない場合、通信アダプタには最新の稼働情報がキャッシュされないことが確認できています。これらから推測すると、設備が通電されていない状態から復旧した場合、更新頻度が長いと最新の稼働情報を取得するまでに時間がかかることになります。つまり、古い情報が保持されている時間が長くなると言えます。以上より、解答は「電源断などで設備との通信ができない場合の稼動情報が古くなる」となります。