「伸び悩んでいる3年目Webエンジニアのための、Python Webアプリケーション自作入門」を更新しました
本を更新しました
チャプター「HTTPとは？」 を更新しました。
続きを読みたい方は、ぜひBookの「いいね」か「筆者フォロー」をお願いします ;-)
以下、書籍の内容の抜粋です。
HTTPについて学ぶ
さて、前章まででApacheとChromeの真似っ子をして、「エセWebサーバー」を作ってきました。
これをもう少し「最低限まともなWebサーバー」に進化させていきたいのですが、「最低限まともなWebサーバー」とは一体どういうものなんでしょうか？
ここから先へ進むにはどうしても HTTP の説明をしなければいけないので、また少しお付き合いください。
ここを抜ければ、「あとはじゃんじゃん書くだけ！」という感じになってきます。
HTTPとは？
前章までで、皆さんはTCPについては学びましたね。
（おさらいしておくと、TCPは「漏れなく順序よく」送るためのルールでした。）
「漏れなく順序よく」送れるということは、送ったメッセージはそっくりそのまま相手にちゃんと伝わることが保証されるわけですが、ではそのTCPを使って 「何を」（＝どんなメッセージを）伝えれば良いでしょうか？
ここで、GoogleというWebサービスに対して、クライアントがサーバーへリクエストを伝えるときのことを考えてみましょう。
リクエストで伝えたい内容は、
hogeというワードで検索したい。Cookieはhogeを使う。
だとしましょう。(Cookieは本書後半で詳説します）
それぞれのクライアントが皆思い思いの形式でこれらの情報を伝えてくると、サーバーは困ったことになります。
例えば、
クライアント1) 日本語まじり...
Cookieはfugaね、今回はwww.google.com/searchで検索ワードはhoge
クライアント2) 区切り文字がコンマだったり数字だったりコロンだったりする...
1.www 2.google 3.com 4.search, word:: hoge, cookie=fuga
などのように毎回違う形式でリクエストを送られてくると、サーバーはリクエストのどの部分がどの情報を示しているのかわからなくなってしまうのです。
そこで、世界的に約束事（＝プロトコル）が制定されました。
「Webサービスを利用する際は、TCPを使った上で、こういうフォーマットでメッセージを送りましょう」
という約束事です。
先程のクライアントのリクエストの場合であれば、
GET /search?q=hoge HTTP/1.1
Cookie: fuga
と送ることになっています。
世界中の全てのクライアントがこの形式で送ってくるとわかっていれば、お互いに見ず知らずの相手でも、Webサーバー側もメッセージを適切にパース（分解）して情報を取り出せるという寸法です。
この約束事を HTTP(HyperText Transfer Protocol) と呼びます。
コラム: トランスポート層のプロトコルと、アプリケーション層のプロトコル
「何を」伝えるか に関するプロトコルは、提供したいサービスによって変わってきます。
なぜなら、何を相手に伝えなければいけないかは、サービスによって変わってくるからです。
例えば、 メールを送るサービス であれば、
- 自分のメールアドレス
- 宛先メールアドレス
- タイトル
- 本文
などを相手に伝える必要があるでしょう。
同様に、 Webサービス であれば、
- リクエストするWebページのURL
- リクエストの種類（Webページが見たいのか、入力したフォームのデータを送りたいのか、など）
- HTTPを使うのか、HTTPSを使うのか
- Cookieの値は何か（Cookieについては本書後半で詳説します）
などを相手に伝える必要があります。
当然、メールを送るサービスとWebサービスでは違うフォーマットで相手にメッセージを伝えることになりますし、それはプロトコルが変わってくるということを意味しています。
（ちなみにメールを送るときはSMTP、メールを受け取るときはPOPというプロトコルが使われます）
しかし、HTTPもSMTPもPOPも、全てメッセージのフォーマットに関する約束事であり、送る側も受け取る側も、メッセージは「漏れなく順序よく」届くことは大前提として作られています。
つまり、HTTPもSMTPもPOPも、 TCP通信を行うことを前提としたプロトコル ということになります。
「どうやって送るか」のプロトコルがまずあって、その上に「何を送るか」のプロトコルがあるという構造になっているわけです。
このようなプロトコルの階層構造のモデルとして有名なものとして、OSI参照モデルがあります。
OSI参照モデルでは、「どうやって送るか」に関するプロトコルを トランスポート層 、「何を送るか」に関するプロトコルを アプリケーション層 と呼んでいます。
なので、先輩エンジニアが
「それってトランスポート層の問題ってこと？」
などと言った場合には、
「レスポンスの中身とか順番の話は今していなくて、メッセージを漏れなく順序よく届ける仕組みのところの話をしていますよ」
という意味になります。
こういった一言の意味を即座に正確に理解できるかが、中級者と上級者を分ける一つの要素になるでしょう。
※ OSI参照モデルは今はもう古くなってしまっていると言われており、最近のインターネットで使われているプロトコルを全てOSI参照モデルのレイヤーに当てはめるのは困難ですが、プロトコルに階層構造があるという考え方だけは身につけておきましょう
HTTPのルールはどこに書いてある？
世界的に利用されているこのHTTPというルールですが、これは IETF という団体によって制定されています。
IETFという団体はHTTP以外にもたくさんのインターネット技術に関するプロトコルや仕様類に関する制定を行っており、詳細な仕様や説明は RFC というドキュメントとして発行されます。
RFCはネット上で簡単に検索することができ、誰でも読むことができます。
HTTP/1.1（本書で取り扱うHTTP）のルールについては、 RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235という6つのドキュメントに分割されて定義されています。
例えば、その中でもHTTPの基本について書かれた RFC7230 は、こちら から読むことが出来ます。
これらのRFCにHTTPの全容が書かれていますので、こちらを読んで勉強しましょう。
・・・といって、RFCのリンクを開いた方は早速心が折れたと思います。
RFCは、世界中のインターネット技術の拠り所、いわば法律のように機能するようなレベルのドキュメントのため、プロトコルが制定された背景から目的、細部の細部の仕様まで体系的にまとめられており、全て把握するのは困難です。
まず全部英語だしちょっときつい。
しかし、こういうリファレンスは概要を掴んだ上でかいつまんで読む分には意外と理解できたりするものです。
エンジニアとしてレベルアップしていく上で、一次ソースを理解できるというのは非常に非常に大事なスキルです。
RFCに限らず、フレームワークやライブラリの使い方を調べるのに、公式リファレンスをきちんと読めるかどうかは、上級者にステップアップするには必須のスキルといっていいでしょう。
ですので、以下ではまず私の言葉でHTTPの概要を説明しつつ、折に触れてRFCの該当の箇所もついでに読んでみる、というスタイルで解説を進めていきます。
また、RFCを参照する際は、簡単のために原文ではなく、下記の日本語訳サイトを利用します。
HTTPにおける2種類のメッセージ
HTTPというプロトコルでは、リクエストとレスポンスでそれぞれ別のルール（フォーマット）が定められています。
この2種類のフォーマットについて、それぞれ順に見ていきましょう。
ちなみに単に「リクエスト」といった場合、一般には「(フォーマットや通信方法は問わず)クライアントからサーバーへのメッセージ」を指すことが多いですが、その中でもHTTPのルールに従って送られるメッセージのことを HTTPリクエスト と呼びます。
「レスポンス」についても同様に、HTTPのルールに従ったレスポンスを特に HTTPレスポンス と呼びます。
Discussion