HTTPについてどれだけのことを知っていますか？
私はWebを使う上で、これまでHTTPについて何も意識したことがなかったです。
HTTPとはWebの仕組みには欠かせないプロトコルとなります。
プロトコルとは、通信規約のようなもので、ルールのような感じです。
HTTPの仕組みを知ることでWebについての理解を深めていけます。
今回はWebには欠かせないHTTPについてを解説していきます。
- Webシステムの開発をする予定の方
- Webについて知りたい
- HTTPが何かわからない
HTTPとは？
冒頭で、HTTPとはWebシステムで欠かせないプロトコルと説明しました。
もう少し掘り下げると、HTTPはクライアントとサーバ間で通信のやりとりを行うプロトコルになります。
図で説明した通り、ブラウザとWebサーバ間はHTTP通信によって実現されます。
今このサイトを表示しているのも、HTTP通信でWebサーバに要求しているので、ブラウザで閲覧できているのです。
本サイトを含む、WebのURLについて頭に「https」と付いているはず。
（例）https://hachi-system888.com/
これはHTTP通信のことを表します。
httpsの「s」とは、通信を暗号化するという意味です。
httpだと第三者から通信を盗み見られることがあります。（これを盗聴といいます）
なので、今ではhttpsにするのが常識です。
HTTPの仕組み
HTTPの基本を知ったところで、次からは具体的な仕組みを解説していきます。
HTTPがどのような仕組みで動いているかを理解すると、より理解を深めることができるでしょう。
クライアント/サーバモデル
HTTPの大前提として、クライアントとサーバで構築されていることを理解しないといけません。
簡潔に説明すると下記です。
- クライアント：Webブラウザ
- サーバ：Webサーバ
前節でも説明した通り、クライアントがWebサーバに対してページを要求します。
それに対して、Webサーバはクライアントへページを返します。
つまり、Webブラウザだけでは閲覧したいWebページは見れないということ。
ですが、クライアント側は特にWebサーバの存在を意識する必要がありません。
Webブラウザを利用すれば簡単に閲覧したいWebページが表示できます。
これこそがWebの長所であり、クライアント/サーバモデルになるのです。
クライアントとサーバの両者は分離しており、っその架け橋となるのがHTTPになります。
リクエスト/レスポンス
リクエストとレスポンスは聞いたことがある、という方も多いと思います。
リクエストとは、クライアントからサーバへ要求すること。
その名の通り、「～のページを表示して」というリクエストをサーバへ投げます。
それに対して、レスポンスとはサーバからクライアントへ返すもの。
クライアントからのリクエストに対して、その要求に応えるために結果を返します。
- リクエスト：クライアント→サーバ
- レスポンス：サーバ→クライアント
サーバはステータスコードという番号と結果をクライアントに返します。
- 200番台：リクエスト成功
- 300番台：リソースの移動
- 400番台：リクエストの誤り
- 500番台：サーバエラー
200番台だとリクエストが成功したという意味になります。
300番台はリソースのURIが変更したことを表し、自動で新たなURIへ移動します。
400番台はクライアント側によるリクエストの誤りを指します。
例えば、URIの指定の間違いなど。
500番台はサーバ側で何か異常が出ている場合。
ステータスコードによって、対処方法が変わってくるのと、番号でどのようなエラーが出ているのかなどを詳細に知ることができます。
HTTPの設計
HTTPはステートレスの作りとなっています。
ステートレスとは、
「サーバがクライアントのアプリケーション状態を保存しない」制約のことです。
Webを支える技術 P80より引用
と説明があります。
サーバ側でクライアントの情報を保持しないということは、クライアントの状態をサーバ側で管理しないということ。
クライアントはリクエストの度に自分の状態をサーバへ伝える必要があります。
これがHTTPの設計です。
では逆にステートレスの反対のステートフルとはどのようなものか。
ステートフルは、サーバ側がアプリケーションの状態を保持します。
すなわち、クライアント側は次々に新しいリクエストだけを送ればよくて、サーバ側ではクライアントの情報を保持しないといけません。
ステートフルの長所
ステートフルは私たちの生活でのやり取りと同じになります。
例えば、コンビニを例にしてみましょう。
店員：いらっしゃいませ。
客：チキンを一つ。
店員：かしこまりました。
客：あとおでんもね。
店員：かしこまりました。以上でしょうか？
客：クレジットで支払える？
店員：ご利用できます。
客：クレジット払いで。
店員：かしこまりました。
店員はチキンとおでんが注文されていることを知っています。
なので、客は毎回チキンを注文したりおでんを二度言ったりはしません。
ステートフルの長所は、利用者が次々に注文をできるということ。
利用者、Webでいうクライアントの負担が少ない方式です。
ステートフルの短所
ですが、ステートフルには短所が存在します。
それは多数の人からの注文に応えるのに負荷がかかるということ。
先の例でもし客が三人や四人から同時に注文が入った場合はどうでしょう？
通常、コンビニではありえませんがWebではそうはいきません。
多数のクライアントから同時に要求されることもあります。
すべてのクライアントに対応するためには、あまりにもサーバの負荷が大きすぎます。
ステートレスの長所
では、次はステートレスのコンビニでのやりとりです。
店員：いらっしゃいませ。
客：チキンを一つ。
店員：かしこまりました。
客：チキンを一つ。あとおでんもね。
店員：かしこまりました。以上でしょうか？
客：チキンを一つとおでん。クレジットで支払える？
店員：ご利用できます。
客：チキンを一つとおでんをクレジット払いで。
店員：かしこまりました。
かなり冗長なやりとりですよね？
ステートレスな注文をしなくてはいけないなら、コンビニも客足が遠のきそうです。
ですがステートレスなやりとりをすることで、複数人から注文に対応できます。
それぞれの人が注文をすべて毎回伝えるので、店員側の負担が減りますね。
これがHTTPでよりよい設計となるのです。
多数の要求に応えるためには個々のクライアントに少しずつ負担をしてもらうのがよいでしょう。
ステートレスの短所
ステートレスの短所といえば、冗長なやりとりになってしまうというところでしょうか。
現実世界でステートレスを取り入れたならば、人と話すのが億劫になりそうです。
せっかく人間には素晴らしい脳があるのにもったいないですね。
ステートレスはコンピュータでかつ、大多数のクライアント要求に応えるためのものだと覚えておきましょう。
まとめ
HTTPはシンプルが一番！
この一言につきます。
シンプルがゆえにここまでWebという技術やHTTPの人気が高まったのでしょう。
シンプルはWebだけではなくて、通常のアプリケーションにも適用できます。
構造がシンプルならば、ユーザも理解しやすく保守性も上がる。
アプリケーション開発を行う際は、常にシンプルを意識していくとよいでしょう。
参考文献
- Webを支える技術
-
山本陽平著
技術評論社
関連記事
コメント