こんにちは。SI部の古谷です。

今回の技術ブログでは、HTTPプロトコルについて記述をさせて頂きます。

HTTP2.0が話題になりはじめていますが、実際に導入される前に基本の再入門になります。

HTTPの概要について

HTTPとは通信プロトコルの1つです。

インターネット上において、クライアントとサーバが相互通信を行なう為の仕組みになります。

まず、通信の流れとしては、Webサイトを閲覧したい人がサイトを公開しているWebサーバーへ「あなたのサイトを見たいです」と要求を出します。(リクエスト)

次に、Webサーバー側から、要求をした人に対して「サイトを見せてあげます」と返答が送られます。(レスポンス)

返答情報(レスポンス)にはWebサイトのコンテンツも含まれますので、返答された時点でブラウザ上にWebサイトが表示されることになります。

このやりとり(リクエストとレスポンス)に「HTTPプロトコル」が利用されており、私たちはWebサイトをみることができるのです。

実際のやり取りのイメージを見てみましょう。

network_01

リクエスト→レスポンスについて

HTTP通信は、クライアント側からWebサーバー側への「リクエスト」と、Webサーバー側からクライアント側への「レスポンス」によって、通信が成り立っている事を解説しました。

では、実際にどのようなデータがやりとりされているのでしょうか。

下図は、Casley Consulting 技術ブログにアクセスした際に、やりとりされているデータです。


request_response

リクエスト時には「リクエストヘッダ」というデータが送られ、レスポンス時には「レスポンスヘッダ」というデータが返ってきます。

  • リクエストヘッダには
    使用しているブラウザの情報など設定される
  • レスポンスヘッダには
    サーバの情報、正常に通信されているかなどの情報をが設定される

HTTP通信には、Headerだけではなく『Request body』,『Response body』というデータも同時に送信されています。

  • リクエストボディーには
    WEBサイトへのパラメータ(POST,PUTなど)が設定される
  • レスポンスボディーには
    WEBサイトのコンテンツ(HTML)などが設定される

メッセージの構造

ここまでの説明において、下記の関係が定義されています。

  • リクエスト(Request)
    クライアントからサーバへのリクエストメッセージを送信
  • レスポンス(Response)
    サーバからクライアントへのレスポンスメッセージを送信

ブラウザでの通信を行なうと、『Requestメッセージ』『Responseメッセージ』の構成でメッセージが出力されます。

network_02

リクエストメッセージの中身について

HTTP/1.1では、下記のメソッドが定義されています。

メソッド 内容
GET クライアントが指定したURLリソースを取得
POST GETとは反対にクライアントからサーバにデータを送信
PUT 指定したURLにリソースを保存、更新
HEAD ヘッダ情報のみ取得
OPTION 利用可能なメソッドなどのサーバ情報を取得
DELETE 指定したリソースの削除
TRACE リクエストのループバックでサーバまでのネットワーク経路をチェック
CONNECT プロキシへのトンネル要求

通常のブラウジングなどにおいては、『GET』『POST』『HEAD』等を利用しますが、『PUT』『DELETE』などのメソッドは利用しません。

なぜなら左記のメソッドを利用する事でコンテンツの書き換えや削除といった改ざんが発生するからです。

通常、WEBサーバ上ではこれらのメソッドを使用出来なくしています。

リクエストメッセージの1行目にある記述が、リクエストラインになります。

リクエストラインに記述されている『GET』がメソッドになり、サーバ上のリソースに対する処理内容を示します。『GET』を指定する事で、リソースの要求を行ないます。

リクエストラインに記述されている、リクエストURLにはリソースの位置情報を指定します。一般的にリクエストURLにはスキームやオーソリティを除いたパス以降のURLを指定します。

例えば、『https://www.casleyconsulting.co.jp/blog-engineer/』にアクセスする場合、リクエストURLには「/blog-engineer/」を指定します。なお、プロトコル名やホスト名を含んだ絶対URLを指定する事も可能です。

末尾のHTTPバージョンには、通信規格であるHTTPのバージョンが記述されています。このバージョンはクライアント側とサーバ側で同じ規格を利用する必要性があります。

一般的に現在のバージョンはHTTP/1.1を利用していますが、旧バージョンのHTTP/1.0やこれから注目を集める、HTTP/2.0の指定もクライアントとサーバが対応して行く事で可能になります。

リクエストメッセージの2行目から空行までがヘッダパートになります。

クライアントからサーバに対して送信するリクエストの内容が詳細に記述されています。

⇒ ヘッダの書式は、【ヘッダ名:値】で記述されています。

以下にリクエストメッセージで主に使用されているヘッダを紹介します。

ヘッダ名 説明
Accept クライアントの右傾入れ可能なコンテンツタイプをサーバに通知
Accept-Charset クライアントの受け入れ可能な文字セットを通知
Accept-Encoding クライアントの受け入れ可能な文字エンコーディングをサーバに通知
Accept-Language クライアントの受け入れ可能な言語をサーバに通知
Authorization クライアントの認証情報をサーバに通知
Cookie クライアントのCookieをサーバに返却
Expect クライアントが期待するサーバの動作を通知
From リクエストしたユーザの電子メールアドレス
Host リクエストしたリソースがあるWebサーバのホスト名やポート番号を通知
if-Match 条件に合致した時だけリクエストを処理するようサーバに要求
if-Modified-Since 指定日時移行にリソースが更新されていたらリクエストの処理をサーバに要求
if-None-Match if-Matchの反対、条件に合致しない時だけリクエストを処理するようサーバに要求
if-Unmodified-Since if-Modified-Sinceの反対、指定日時以降にリソースが更新されていなかったらリクエストの処理をサーバに要求
Max-Forwards リクエストの最大転送数を指定
proxy-Authorization プロキシサーバに大してクライアント承認の情報を通知
Range リソースの一部をレンジ(範囲)で要求
Referer リクエストの参照元をサーバに通知
TE レスポンスの受け入れ可能な転送エンコーディングをサーバに通知
User-Agent ブラウザタイプやバージョンなどの情報をサーバに通知

ヘッダの種類については、レスポンスメッセージでしか利用しないヘッダや転送されるコンテンツに関するエンティティヘッダもあります。

※エンティティヘッダについては、またの機会にご紹介しようと思います。

HTTP/1.1で定義されているヘッダだけでも40種類近くあり、それ以外では拡張用のヘッダも存在しています。

必須のHTTPヘッダは、『Host』のみでその他のヘッダ情報は、オプション情報になります。

リクエストボディー

ヘッダの後の空行を挟んで続くのがリクエストボディーになります。また、リクエストボディーについては省略が可能です。

『POST』を指定した場合、URLエンコードやマルチパートエンコーディングを用いてクライアントからサーバへデータをエンコードし、ボディに埋め込み送信をします。

レスポンスメッセージの中身について

ステータスライン

レスポンスヘッダの1行目がステータスラインです。レスポンスメッセージ内容は、後述します。

ステータスラインには、通信プロトコルバージョンや通信の結果が含まれます。

※通信結果をステータスコードといいます。ステータスコードには、100番台から500番台の値を設定します。

ステータスコード 概要 説明
100番台 情報(Infomational) 処理が接続されている事を通知。ほとんど利用されていない。
200番台 成功(Success) リクエストの処理に成功した事を通知
300番台 リダイレクト(Redirection) リクエストを完遂するには、更に新たな動作が必要である事を通知
400番台 クライアントエラー(Client Error) リクエストの内容に問題があるためリクエスト処理に失敗した事を通知
500番台 サーバエラー(Server Error) リクエスト処理中にサーバにエラーが発生した事を通知

HTTPのような、リクエスト/レスポンス類のプロトコルでは、レスポンスに含まれるステータス(処理結果)が重要で単にリソースの転送に成功/失敗しただけではなく、失敗した場合は何が問題かの原因をサーバからクライアントへ通知する必要があります。

レスポンスヘッダ

レスポンスメッセージの2行目から空行までがレスポンスヘッダになります。

サーバからクライアントに対し返送されるレスポンス内容がより詳細に記述されています。

レスポンスヘッダの書式は、リクエストヘッダと同様です。

以下によく利用されるレスポンスヘッダを紹介します。

ヘッダ名 説明
Accept-Ranges リクエストされたリソースをレンジ(範囲)で転送出来るかを通知
Age リソースが生成されてからの経過時間を秒単位で返却
ETag リソースが更新されたか見地する為のエンティティタグ値
Location リダイレクト先のURL
Proxy-Authenticate プロキシサーバからクライアントに対してリクエストの再送を要求し、同時にプロキシサーバがサポートしている認証方式を通知
Retry-After リクエストの再送をしてほしい時間をクライアントに通知
Server サーバのソフト情報やバージョン情報
Vary サーバがレスポンス内容を決定するコンテントネゴシエーションを行なったさいに用いたリクエストURI以外のヘッダのリスト
www-Authenticate クライアントに対してリクエストの再送を要求し、同時にサーバがサポートしている認証方式を通知

レスポンスボディ

ヘッダの後に空行を挟んで続くのがレスポンスメッセージのボディになります。

サーバからクライアントに対して転送したいデータがある場合に使用します。

ラウジングにおいては、ボディを使ってHTMLテキストや画像といった重要なコンテンツを転送します。

レスポンスメッセージにおいてもボディは省略される場合があります。

その他

ヘッダの行数や文字数は、ブラウザやWEBサーバによって異なり、一般的に8kbや16kbの上限値を設けてあります。

WEBアプリケーションを作成する際にヘッダ内容を考慮する事で、サーバチューニングを活用して適切に設定する事により転送速度や処理速度が向上し、より多くのクライアントをさばく事が出来る様になります。

ツールのご紹介

Google Developer Console, Fire Fox DeveloperConsoleなどを利用しますが、HTTP通信をキャプチャーする事も可能なアプリケーションやコマンドもあります。

  • [Charles]http://www.charlesproxy.com
  • [ngrep]コマンドもあります

サーバーに対して通信した情報をわかりやすくキャプチャします。

HTTP/2.0について

最後に、HTTP/2.0について軽く触れておきます。

現在、IETF(Internet Engineering Task Force)にて標準化作業が進められているHTTP/2.0。

1999年にHTTP1.1が規定されて以来、14年ぶりに改訂されることになった新プロトコルの概要と、Webサービスが今後どう変わるのかについての最新情報が紹介されました。

HTTP/2.0はインターネット技術の標準化を推進する任意団体IETFのアプリケーションワーキンググループにて標準化が進められています。

IETFには、Google、Microsoft、Mozilla、Twitterなどの協賛企業が名を連ねています。

HTTP/2.0は、Googleが開発したプロトコルSPDY(スピーディ)がベースとなっています。

GoogleがSPDYを世に送り出した背景には、インターネット環境の大きな変化がありました。

インターネットの利用がPCからモバイルへと変化しつつある中で、HTTPというプロトコルをモバイルに最適化し、Webの表示を高速化するという目的で作られたのがSPDYでした。

HTTP/1.1の特徴を維持し互換性を保持した上で、新しいシンタックスを導入しフレーム化することを目的としてHTTP/2.0は、このSPDYのアイデアをもとにHTTP/2.0の仕様策定が進められています。

近い将来HTTP/2.0が主流になってくると思いますがHTTP/1.1を理解する事で、HTTP/2.0に柔軟に対応出来ると思います。

___

いかがでしたでしょうか?

HTTP/2.0が主流になる前に、今一度HTTP/1.1を押さえておきたいですね。