Webアーキテクチャ設計の基本を学ぼう1（HTTP編）

Webアーキテクチャ

Webサーバをレプリケーションするにあたって、Webアーキテクチャの基本からおさらいしようと思い、ITproの連載記事を、自分なりにわかり易くまとめてみることにしました。

基本中の基本ですが、意外に抜けてる部分も多いです。


■情報システムの主な基本アーキテクチャは３種類

・ホスト・システム
・クライアント/サーバーシステム
・Webシステム

C/Sシステムにおける、クライアント・マシンへの「アプリケーション配布問題」を解決する選択肢として注目されたのが，Webシステム。

Webシステムは，WebクライアントとWeb サーバーがHTTPに従って通信する一種のC/Sシステムである。
ソフトウエア上の観点で言えば，クライアント・ソフトはHTTPで通信する機能を持つWebブラウザであり，サーバー・ソフトはHTTP待ち受け機能を持つ常駐ソフト（HTTPD）である。

　WebシステムはC/Sシステムの一種だが，業務処理の大半はサーバー側で実行する。なぜならWebブラウザには，HTMLの指定に従い画面を表示したり，スクリプト言語「JavaScript」の記述に従い簡単な処理をしたりする機能しかないからである。

　HTMLやJavaScriptのデータは，WebブラウザがHTTPDからその都度入手する。そのため，HTTPDから送り出すHTMLや JavaScriptの内容を書き換えるだけで，自動的にWebブラウザ上の表示内容や動作が変わる。これが，Webシステムではアプリケーションの配布を意識する必要が無い理由である。

　3種類のアーキテクチャのうち，最近の主流は「Webシステム」である。そのWebシステムで使われる通信ルールが「HTTP」。


■ HTTPの基本仕組み

　HTTPはTCP/IP上で利用できるプロトコルの一つ。
ほかのプロトコルと区別するために，TCP ポート80番でやり取りする。HTTP自体はテキスト・ベースのシンプルなプロトコル。

　具体的な処理の流れ
①Webブラウザは，WebサーバーのTCPポート80番に接続し，コンテンツ提供などをリクエスト
②Webサーバーは，該当するコンテンツを探し，レスポンス

HTTPは，上りとなるリクエストと，下りとなるレスポンスが，必ず一対となる。


    簡単な確認作業

  • コマンド・プロンプトから「telnet」と入力

  • プロンプトが表示されたら「open localhost 80」と入力

  • 接続成功

  • 「GET / HTTP/1.0 (エンター・キー2回)」入力


  • 「HTTP/1.1 200 OK」レスポンス出力

　一般的なWebシステムでのやり取りを目で見られるようにするには，HTTP通信の中継機能を持ち，リクエスト/レスポンスのログを出力できる「プロキシ」を利用する。

　プロキシを導入し，WebブラウザのURLバーに例えば「http://www.google.co.jp/」と入力すると，Webサーバーに対して「GET http://www.google.co.jp/ HTTP/1.0」で始まるリクエスト・メッセージが送付されることを確認できる。


リクエスト・メッセージの先頭には，処理内容を示す命令（この場合は「GET」）が記されている。これらの命令を「メソッド」と呼ぶ。Webブラウザが利用するメソッドは，主にGETとPOSTである。GETメソッドはHTTPDからコンテンツを取得する場合に，POSTメソッドはフォーム経由で HTTPDにデータを送付する場合に，それぞれ多用する。メソッド名の直後には，処理対象となるURLを指定する。

　2行目から続く「Accept：…」や「User-Agent：…」などは「ヘッダー」である。これらヘッダーには，クライアントで受け入れられるコンテンツの種類（Accept）や，Webブラウザの種類などを指定する。

　GETメソッドには存在しないが，POSTメソッドでは，ヘッダー部の直後に空行（リターン・コードだけの行）をはさんで，「ボディ」と呼ぶデータ部が続く。ボディには，Webサーバーに送信するデータが含まれる。例えば，フォームに入力した値や，添付したファイルの内容などを格納する。

　一方のレスポンス・メッセージは，「HTTP/1.0 200 OK」などの行で始まる。

　2行目以降には，リクエスト・メッセージと同じように，ヘッダー，空行，ボディが続く。レスポンス・メッセージ中のヘッダーには，コンテンツの種類（Content-Type）やキャッシュ可否（Cache-Control）などが指定されている。これらのヘッダー情報は，主にWebブラウザが活用する。

　例えばHTTP/1.1でキャッシュを許可するCache-Control: publicヘッダーがあれば，取得したコンテンツは有効期限が来るまでWebブラウザやキャッシュ・サーバーが蓄積する。ホスト上にしかデータを蓄積しないホスト・システムと比べると，情報漏洩のリスクを抱えたポイントが多くなる場合がある。また，これまで見てきたHTTPの振る舞いから分かるように，WebブラウザはHTTPDにリクエストしないと，原則として画面を表示できない。C/Sシステムと違って，オフライン環境では事実上使えないことになる。


■セッション

　リクエストとレスポンスの仕組みはシンプルで理解しやすいが，実際のシステムでは問題が生じることがある。
　例えば電子商取引サイトで商品を購入する場合。
商品画面でモノを選んで［購入］ボタンを押すと，バスケットの内容を一覧表示する確認画面が現れ，［購入］ボタンを押すと発送先や支払方法などを指定する決済画面が表示される。この場合，商品画面で選んだモノの情報を確認画面に，確認画面で承認したことを決済画面に，それぞれ引き継いでいく必要がある。こうした処理を実現するには，特定のWebブラウザから送られてきた一連のリクエスト/レスポンスをまとめて扱うことが必要だ。この一連のリクエスト/レスポンス群を「セッション」と呼ぶ。

　Webシステムでは，セッションをどのように管理するかが重要である。
（1）セッションを見分けるための識別子（セッション識別子）をどう作るか
（2）セッション識別子をWebブラウザとHTTPDとの間でどう送受信するか
（3）セッションで使う情報をどう保持するか
この3点は，セキュリティ，性能，耐障害性などに大きく影響する。

セッション識別子を送受信する方法には，クッキー（HTTPの「Set-Cookie」ヘッダーや「Cookie」ヘッダー）に格納する方法，URLに付加する方法，隠し属性（Hidden）タグに格納する方法などが考えられる。一般的には，クッキーを利用することが多い。Webブラウザの制約などでクッキーを利用できない場合に限り，他の方法を検討するとよいだろう（他の方法を選ぶ場合はセキュリティ上の課題を解決しておく必要がある）。

　（3）のセッション情報は，一般的にセキュリティを考慮してサーバー側に格納する。格納場所としては，APコンテナが備える専用領域（セッション・オブジェクトと呼ぶ），データベース，ファイルなどがある。どこに格納するかで，性能や耐障害性に影響が出てくるため，注意が必要である。一般的には，開発の容易さからセッション・オブジェクトが多用される。


■ファイルダウンロード/アップロード

　HTTPは，HTMLファイル以外に，画像ファイルやPDFファイルなど多様なデータのダウンロードに活用されている。このとき重要な役割を果たすのが，“Content-Type”というレスポンス・ヘッダーである。“Content-Type: text/html; charset=UTF-8”とある場合は，“UTF-8”という文字表現形式のHTMLデータをダウンロードするという意味になる。
　“text/html”という部分は，ダウンロードするコンテンツの種類を表す。これを「MIMEタイプ」と呼ぶ。GIF形式の画像であればMIMEタイプは“image/gif”である。
　HTTPDは，リクエストされたファイルの拡張子が“.html”ならば“text/html”を，“.gif”ならば“image/gif”を，それぞれ自動的にContent-Typeヘッダーにセットしている。どの拡張子にどのMIMEタイプをセットするかは，HTTPDに設定する（図2）。例えば拡張子“.pdf”にMIMEタイプ“application/pdf”をセットする場合，Apacheでは設定ファイル“httpd.conf”に「AddType application/pdf .pdf」と記述する（mime.typesファイルに設定する方法もある）。

Webブラウザは，Content-Typeヘッダーの値に応じて，ファイルを画面に表示したり，プラグイン・ソフトに引き渡したりする

　Webブラウザは，受け取ったMIMEタイプをサポートしていればそのまま表示するし，サポートしなければダイアログ・ボックスを表示してファイルをダウンロードする。WebブラウザにMIMEタイプとアプリケーションの関係を設定しておけば，受信したファイルをアプリケーションで開くことも可能だ。
　アップロードする場合は，Webフォームの送信に使うPOSTメソッドの出番である。「MIMEマルチパート」と呼ぶ形式でフォームにファイルを添付してサーバーに送り込む。

                              • システム可用性編へつづく