こんにちは。SI部の古谷です。
今回の技術ブログでは、HTTPプロトコルについて記述をさせて頂きます。
HTTP2.0が話題になりはじめていますが、実際に導入される前に基本の再入門になります。
HTTPの概要について
HTTPとは通信プロトコルの１つです。
インターネット上において、クライアントとサーバが相互通信を行なう為の仕組みになります。
まず、通信の流れとしては、Webサイトを閲覧したい人がサイトを公開しているWebサーバーへ「あなたのサイトを見たいです」と要求を出します。（リクエスト）
次に、Webサーバー側から、要求をした人に対して「サイトを見せてあげます」と返答が送られます。（レスポンス）
返答情報（レスポンス）にはWebサイトのコンテンツも含まれますので、返答された時点でブラウザ上にWebサイトが表示されることになります。
このやりとり（リクエストとレスポンス）に「HTTPプロトコル」が利用されており、私たちはWebサイトをみることができるのです。
実際のやり取りのイメージを見てみましょう。
リクエスト→レスポンスについて
HTTP通信は、クライアント側からWebサーバー側への「リクエスト」と、Webサーバー側からクライアント側への「レスポンス」によって、通信が成り立っている事を解説しました。
では、実際にどのようなデータがやりとりされているのでしょうか。
下図は、Casley Consulting 技術ブログにアクセスした際に、やりとりされているデータです。
リクエスト時には「リクエストヘッダ」というデータが送られ、レスポンス時には「レスポンスヘッダ」というデータが返ってきます。
- リクエストヘッダには
使用しているブラウザの情報など設定される
- レスポンスヘッダには
サーバの情報、正常に通信されているかなどの情報をが設定される
HTTP通信には、Headerだけではなく『Request body』,『Response body』というデータも同時に送信されています。
- リクエストボディーには
WEBサイトへのパラメータ（POST,PUTなど）が設定される
- レスポンスボディーには
WEBサイトのコンテンツ（HTML）などが設定される
メッセージの構造
ここまでの説明において、下記の関係が定義されています。
- リクエスト(Request)
クライアントからサーバへのリクエストメッセージを送信
- レスポンス(Response)
サーバからクライアントへのレスポンスメッセージを送信
ブラウザでの通信を行なうと、『Requestメッセージ』『Responseメッセージ』の構成でメッセージが出力されます。
リクエストメッセージの中身について
HTTP/1.1では、下記のメソッドが定義されています。
| メソッド | 内容 |
| GET | クライアントが指定したURLリソースを取得 |
| POST | GETとは反対にクライアントからサーバにデータを送信 |
| PUT | 指定したURLにリソースを保存、更新 |
| HEAD | ヘッダ情報のみ取得 |
| OPTION | 利用可能なメソッドなどのサーバ情報を取得 |
| DELETE | 指定したリソースの削除 |
| TRACE | リクエストのループバックでサーバまでのネットワーク経路をチェック |
| CONNECT | プロキシへのトンネル要求 |
通常のブラウジングなどにおいては、『GET』『POST』『HEAD』等を利用しますが、『PUT』『DELETE』などのメソッドは利用しません。
なぜなら左記のメソッドを利用する事でコンテンツの書き換えや削除といった改ざんが発生するからです。
通常、WEBサーバ上ではこれらのメソッドを使用出来なくしています。
リクエストメッセージの１行目にある記述が、リクエストラインになります。
リクエストラインに記述されている『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の指定もクライアントとサーバが対応して行く事で可能になります。
リクエストメッセージの２行目から空行までがヘッダパートになります。
クライアントからサーバに対して送信するリクエストの内容が詳細に記述されています。
⇒ ヘッダの書式は、【ヘッダ名：値】で記述されています。
以下にリクエストメッセージで主に使用されているヘッダを紹介します。
| ヘッダ名 | 説明 |
| 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エンコードやマルチパートエンコーディングを用いてクライアントからサーバへデータをエンコードし、ボディに埋め込み送信をします。
レスポンスメッセージの中身について
ステータスライン
レスポンスヘッダの１行目がステータスラインです。レスポンスメッセージ内容は、後述します。
ステータスラインには、通信プロトコルバージョンや通信の結果が含まれます。
※通信結果をステータスコードといいます。ステータスコードには、100番台から500番台の値を設定します。
| ステータスコード | 概要 | 説明 |
| 100番台 | 情報(Infomational) | 処理が接続されている事を通知。ほとんど利用されていない。 |
| 200番台 | 成功(Success) | リクエストの処理に成功した事を通知 |
| 300番台 | リダイレクト(Redirection) | リクエストを完遂するには、更に新たな動作が必要である事を通知 |
| 400番台 | クライアントエラー(Client Error) | リクエストの内容に問題があるためリクエスト処理に失敗した事を通知 |
| 500番台 | サーバエラー(Server Error) | リクエスト処理中にサーバにエラーが発生した事を通知 |
HTTPのような、リクエスト/レスポンス類のプロトコルでは、レスポンスに含まれるステータス（処理結果）が重要で単にリソースの転送に成功/失敗しただけではなく、失敗した場合は何が問題かの原因をサーバからクライアントへ通知する必要があります。
レスポンスヘッダ
レスポンスメッセージの２行目から空行までがレスポンスヘッダになります。
サーバからクライアントに対し返送されるレスポンス内容がより詳細に記述されています。
レスポンスヘッダの書式は、リクエストヘッダと同様です。
以下によく利用されるレスポンスヘッダを紹介します。
| ヘッダ名 | 説明 |
| 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を押さえておきたいですね。
