手で打って覚えるHTTPHTTP/1.1での接続(1)HTTP/1.1での接続(2)今回は前回に続いて、プロトコルについてです。前回はSMTPでしたが、今回はおそらく最もメジャーなプロトコルであるといっても過言ではないHTTPについてです。「デカいRFC」の読み方まずHTTPにはバージョンとして1.0と1.1があります。実質、今はほぼ100%のサイトが1.1だと思って良いでしょう。HTT1.1はRFC2068で提唱され、RFC2616にObsoleteされています。RFC2616(と、RFC2616をUpdateしているRFC2817とRFC5785)を読めば、HTTP1.1のことが把握できます。いってもでかいRFCなので、読むのはちょっと大変かもしれません。これくらいポピュラーなRFCになると日本語訳もたくさんあるので、原文と一緒に日本語訳も読むと、理解が速いかもしれません(訳だけ読むのはあまりオススメできません⁠)⁠。RFCを読むとき(特にプロトコルに関するRFCを読むとき)は、BNF記法の知識が必要になります。Form)の略で、正規表現のような、任意の文字列を表現するのに定められた記法です。BNF)といった発展形もあります。RFCではABNFがよく使われます。BNFを知ることはプロトコルを覚えることにも役立つので、ちょっと例を見てみます。1*DIGITとあります。""で括られているのはリテラル(文字列)です。*は繰り返し、DIGITは数字を意味するシンボルです。上記のBNFは、HTTP-Versionは「HTTP/数字1個以上.数字1個以上」と定義しているということになります。BNF記法自体、その定義がRFC内に書いてあるので、それを読めば最初はちょっと苦労するかもしれませんが、それほど苦労せず読めるようになると思います。RFC2616だと、2.1節にABNFの定義が記述してあります。HTTP/1.1の2大特徴さて、もっとRFC2616を読み進めてみます。19.6節に、HTTP/1.0との違いが簡単にまとめられています。HTTP/1.1の大きな特徴のひとつに、HOSTヘッダのサポートがあります。virtualなWebサーバをサポートするためのものです。basedか、そもそもバーチャルに対応していないという時代がありました。virtualという手法が考えられ、一気に広まりました。virtualなWebサーバとは、HOSTヘッダという「何々という名前のWebサーバに接続していますよ」という情報を宣言するためのヘッダによって、返却するコンテンツを制御するものです(簡単に言ってないような...⁠)⁠。basedでもたせているとします。接続したクライアントがHOSTヘッダで、どちらのサイトのホスト名を伝えるかによって、サーバはそれに適したコンテンツを返却します。www.barbaz.comであればwww.barbaz.comのコンテンツを返すということです。basedというのは、あるサーバに複数のIPをもたせてWebサーバをbindingしておき、どのIPに接続してくるかによって返却するコンテンツを制御するというものです。RFC2616の19.6.1.1には以下のように書いてあります。URIs.すなわち、HTTP/1.1の場合にはHOSTヘッダは必ずサポートしなければいけない、していないとHTTP/1.1非準拠である、ということになります。ひとつ、HTTP/1.1の大きな特徴に、Keep-Aliveの挙動があげられます。こちらは19.6.2に下記のように書いてあります。closeという新しいキーワードが作られました。virtual対応とKeep-Aliveのデフォルトの挙動)です。virtualがあるが故に、HTTPを手で打てるというのが結構重要なのです(インフラエンジニアにとっては、ですが⁠)⁠。いうと、ブラウザでWebの検証をする場合には、ブラウザはDNSで名前解決をして、その解決したIPに接続にいきます。接続先IPのAレコードであると同時に、HOSTヘッダで伝えられるホスト名でもあるのです。ところが、検証などをしている時には、この2つを連動させたくないということがよくあります。DNS側で、Aレコードの答えをクエリ元によって変化させるという解決もありますが、それよりは手でHTTPを話せるほうが楽でしょう。サイトのレンダリングの結果を見たいときには手でHTTPプロトコルを話しても意味がないですが。手で打って覚えるHTTPではさっそく、HTTPの実例を見てみましょう。host.上記は、www.google.comに対してHTTP/1.0でHOSTヘッダもコンテントネゴシエーションもなしで接続した例です。(空行)というのが、クライアントが送信している(telnetで入力している)部分になります。空行の入力があって、リクエストと解釈されるので注意が必要です。Foundというレスポンスが返ってきています。これはかいつまんで言うと、LocationヘッダにあるURLにリダイレクトしなさい、という意味になります。http://www.google.co.jp/とありますので、通常ブラウザであればこのURLに接続し直すことになります。HTTP/1.1での接続(1)次に、www.google.comに対してHTTP/1.1でHOSTヘッダも付けて接続してみましょう。HREF="http://www.google.co.jp/">here</A>.</BODY></HTML>ほとんど同じ内容になっていますが微妙に違います。(空行)が、クライアントから送信している(手入力した)部分です。空行を送るまではヘッダ扱いされます。host.はあくまでtelnetの出力でHTTPメッセージではありません⁠)⁠。Requestとして切断されます。HTTP/1.1での接続(2)さらに続いて、Keep-Aliveでないことを宣言してHTTP/1.1にて接続してみましょう。(空行)という内容をリクエストとして送っています。すると、レスポンスが返ったあとに接続が切断されていることがわかります。この例で重要なのは、telnetの引数に入れているホスト名と、HOSTヘッダで指定しているホスト名は「別にすることが可能」ということです。やろうと思えば、googleでないサーバに接続してgoogleのホスト名を指定することもできます。検証においてはこの「別にすることが可能」というのはとても重宝します(とはいっても自分に関係ないホストでやるのは良くないことですが⁠)⁠。今回は非常にざっくりですが、HTTPについて解説してみました。実際には他にもさまざまなヘッダやリクエスト、そしてレスポンスがあるので、ぜひいろいろと勉強してみてください。Ltd.ページ内容の全部あるいは一部を無断で利用することを禁止します⁠。個別にライセンスが設定されている記事等はそのライセンスに従います。