本記事の目的
本記事では、WebブラウザからWebサーバーにアクセスするときに使うHTTP通信について、実際にはどのように動いているのかというところを解剖していきます。
HTTPとは
HTTP とは「Hyper Text Transfer Protocol」の略であり、HTMLを始めとするWeb通信に必要な情報をやり取りするためのルールを定めた規約です。
インターネットを使用しているときに、「404 Not Found」や「500 Internal Server Error」などの状況に出くわしたことがある方も多いと思います。これらは全てWebサーバーからのレスポンスであり、HTTPによって、 クライアントからのリクエストとサーバーからのレスポンスの方式が定められています。
HTTP解剖① 「リクエスト」と「レスポンス」の書式
HTTP通信では、クライアントとサーバー間のリクエストおよびレスポンスの方式を定めています。この「リクエスト」と「レスポンス」を行うときに、それぞれ 決まった書式で必要な情報を送る決まり になっています。
リクエストの書式
リクエストには、「リクエストライン」、「リクエストヘッダー」、「ボディー」の３つの要素が含まれています。
リクエストライン
リクエストラインには、「要求方法」と「要求先のURL」の情報が入っています。
実際にブラウザの「開発者ツール」を利用して中身を見てみましょう。今回は、ブラウザとして Firefox を利用し、「www.google.com」にアクセスした場合を例にして解剖していきます。
まず開発者ツールを開くと、下のようなツールが出てきます。
ここで、今回アクセスした「www.google.com」のところを見てみると、「ヘッダー」というタブでリクエストに関する情報を見ることができます。
ここに表示されている「GET」がリクエストラインで言うところの「要求方法」であり、「https:://www.google.com」が「要求先URL」です。
※HTTPメソッドについて
上で示した「GET」は「要求方法」であると説明しました。このように、HTTP通信では、Webサーバーに対し、どのような種類の要求をするのかによって、「GET」や「POST」などの決められた要求方法を用います。これらを「HTTPメソッド」と呼びます。以下に代表的なHTTPメソッドを示します。
リクエストヘッダー
リクエストの情報２つ目は「リクエストヘッダー」です。同じく開発者ツールで「要求ヘッダー」というところを見てみると、ヘッダーとして持っている情報を見ることができます。
これらのヘッダー情報はリクエストの際の追加情報となります。掻い摘んで説明すると、「Hostヘッダー」は要求先のホスト名です。「User-Agent」は対象のブラウザを判別するための情報です。「Cookieヘッダー」は以前に送られてきたものと同じCookie情報が載っています。Cookieにはログインしたユーザーと結びつける情報が格納されていることがあるので、注意が必要です。
ボディ
ボディには、HTMLのForm要素に入力された値など、リクエストの際に一緒に送信するデータの情報が入っています。
レスポンスの書式
レスポンスにも同じく決まった情報があります。「ステータスライン」、「ヘッダー」、「ボディ」です。
ステータスライン
ステータスラインには、リクエストに対して結果がどの様なものだったかを返すための情報が入っています。先ほどの開発者ツールをもう一度見てみると、「200 OK」という文言があるのが分かります。これは、 正常にリクエストが処理され、レスポンスが返されたことを示します。
※HTTPステータスコードについて
上の「200 OK」の様なコードを「HTTPステータスコード」と言います。HTTP通信では様々なステータスコードを用いてレスポンスを返しています。以下をご参照ください。
レスポンスヘッダー
以下を見てください。
これは開発者ツールで「応答ヘッダー」という項目を開いた時の状態です。ここに表示されている項目は、レスポンスの時の追加情報となります。掻い摘んで説明すると、「Content-Typeヘッダー」は、レスポンスとして返すコンテンツの種類を示しています。この場合は、「text/html」となっているので、htmlを返していることが分かります。「Dateヘッダー」は、レスポンスの日付を示します。「Set-Cookieヘッダー」は、ブラウザに返すCookieの情報が入っています。これを用いて、次回のリクエストを行うことでユーザーを追跡することが可能になります。
ボディ
以下を見てください。
レスポンスで返す実際のコンテンツ情報は、「ボディ」として返します。開発者ツールで、「応答」というところを見てみると、レスポンスとして返されたHTMLのテキストなどが記載されていることが分かります。
HTTP解剖② HTTPからHTTPSへのリダイレクト
今では、セキュリティの観点から、「HTTP通信」ではなく、「HTTPS通信」で通信を行うことが当たり前になっています。Webサーバーによっては、「http://~」でアクセスしようとすると、自動的に「https://~」にリダイレクトされるものもあります。
では、このHTTPS通信とは、どの様な仕組みで行われているのでしょうか。
HTTPプロトコル と SSLプロトコルの組み合わせ
まず、HTTPS通信と言っても、HTTPとSSLという２つのルールを組み合わせてできたルールに則って行う通信となっています。「SSL」は「Secure Socket Layer」の略であり、通信を暗号化して送るためのプロトコルになります。つまり、HTTPS通信とは、 クライアントからサーバーへの通信を暗号化して行うことができる方法 ということになります。
通信を暗号化することにより、盗聴や改ざんのリスクを減らすことができます。更に、SSLプロトコルを使用するときは、「SSLサーバー証明書」という証明書が必要なため、他人によるなりすましのリスクも減らすことができます。
これにはWebサーバーが 認証局（CA：Certification Authority） と呼ばれる第三者の機関からSSLサーバ証明書を発行してもらう必要があります。
このSSLサーバー証明書には、サーバー所有者の情報や暗号化通信に必要な鍵、発行者の署名データなどが含まれます。
各ブラウザごとにそのサイトがHTTPS通信で安全に通信が行えるサイトなのかどうかを確認することができます。Forefoxの場合は、URLの左側に鍵マークがあるので、そこを押すことでサーバー証明書の内容なども確認できます。
「詳細を表示」から証明書を確認できます。 中には身元の不確かな機関から発行された証明書を利用しているサイトも存在する可能性もあるので、証明書の内容をしっかりと確認する必要があります。
「SSL」に関する詳しい解説は以下のサイトが参考になります。
SSL/TLS総合解説サイト
また、SSLでの暗号化通信に用いられる「公開鍵暗号方式」や「共通鍵暗号方式」については、以下のサイトが参考になります。
SSL（HTTPS）の仕組みを図解で分かりやすく説明
まとめ
HTTP通信の仕組みを理解してからは、Webアプリケーションの実装中にエラーが起きた際など、どこに問題点があるのかを順を追って検証することができる様になり、効率が上がってきています。エンジニアの駆け出しとして必須の知識だと改めて感じました。