mojix.org
URLの構造とその意味
昨日の「私はなぜツイッターをやらないのか」で、短縮URLがイヤだということを書いた。この「URL」というものはなんなのか、IT技術者ではない人はおそらく詳細を知らないと思うので、少し書いてみたい。
ウィキペディアの「Uniform Resource Locator」には、こうある。
＜インターネットを、様々なリソースがひしめき合う広大な土地のように捉えれば、URLはリソースの場所を特定する「住所」のようなものと考えることもできる＞。
URLとは、ネットにあるリソース（情報資源）の「住所」なのだ。その住所であるURLは、例えば昨日のエントリであれば、こうなっている。
http://mojix.org/2012/09/11/why-twitter
この文字列は、どういう意味なのだろうか。なぜこれをブラウザのURL欄に入れると、そのページが見れるのだろうか。
詳しくは、同じウィキペディアのページに書いてあるが、ちょっと専門的でむずかしい。ざっくり要点だけまとめると、次のような感じだ。
１） 「http」は、おおまかには「ウェブ」の意味。
２） 「mojix.org」の部分はホスト名といい、ネットにつながっている無数のコンピュータのうち、どのコンピュータであるかをあらわす。「mojix.org」という名前自体は「ドメイン名」で、ブラウザはまずこれをDNSサーバというものに投げて、「49.212.33.25」という「IPアドレス」を受け取る（これを「名前解決」という）。その後、ブラウザはそのIPアドレスを持つコンピュータに接続し、次の「パス名」のリソースを要求する。
３） 「/2012/09/11/why-twitter」はパス名。「mojix.org」というコンピュータに対して、「/2012/09/11/why-twitter」というページを寄こせ、と要求する。その結果、そのページの内容であるHTMLファイルが返ってきて、ブラウザはそれを表示する。
URLの文字列は、ざっとこの３つの部分に分けて理解すればいい。
ブラウザが「mojix.org」というホスト名のコンピュータに対して、「/2012/09/11/why-twitter」というパス名のリソースを要求するとき、以下のような「リクエスト（要求）」が送られている。
GET /2012/09/11/why-twitter HTTP/1.1
Host: mojix.org
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20100101 Firefox/15.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ja,en;q=0.7,en-us;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive
これの１行目の「GET」の部分を「メソッド」と呼ぶ（他に「POST」など何種類かある）。その次に「パス名」が来ている。リクエストでは、この１行目が重要。
２行目の「Host:」の行は、ホスト名が入る。これは、その一台のコンピュータの中にも複数のホスト（≒ウェブサイト）がしばしば入っているので、そのうちどれを対象にしているのかを指定する意味がある。サーバ側から見ると、このホスト名を使って内容を出し分ける「バーチャルホスト」技術のために、これが必要になる。
３行目の「User-Agent:」の行は、ブラウザの名前やバージョン、OS名などが入る。サーバ側から見ると、どういうブラウザや機器を使ってアクセスしているかがわかるので、モバイル機器の場合はモバイル用サイトに移動させる、といったこともできる。
他にも、場合によって、認証関連やクッキー関連など、リクエストにはいろいろなものが入りうる。
このリクエストに対して、サーバ側（「mojix.org」のコンピュータ側）から、以下のような「レスポンス（応答）」が送られてくる。
HTTP/1.1 200 OK
Date: Tue, 11 Sep 2012 13:01:51 GMT
Content-Type: text/html; charset=utf-8
Connection: keep-alive
Content-Length: 5234
Server: gevent/0.13 Python/2.7
（このあとに空行をはさんで、HTMLの内容がつづく）
１行目の「200 OK」は、正常な応答であることを示す。要求されたページがちゃんと見つかったので、それを返しますよ、という意味。正常でない場合は、例えば「404 Not Found」（それは見つかりません）などが返る。レスポンスでも、この１行目が重要。
２行目は応答した日時で、３行目は応答したコンテンツの形式（この場合はHTML）をあらわす。２行目以降は順番を問わず、出てくるものの内容も、場合によって変わる。クッキーを使っている場合、その関連ヘッダなどもレスポンスに入ってくる。
以上のような「リクエスト（要求）」と「レスポンス（応答）」の対が、ファイルごとに起きている。このリクエストとレスポンスは、ブラウザとサーバがともにルールを守ってやっているので、「意思疎通」ができている。ここで使っているルール、「プロトコル」が、この場合「HTTP（Hypertext Transfer Protocol）」であり、これがURLの最初の要素である「http」の意味だ。リクエストとレスポンスの１行目にも「HTTP/1.1」とあり、それがHTTPというルール（仕様）のバージョン1.1にしたがった通信であることを示している。
ひとつのHTMLページには、たいてい複数の画像や、複数のCSS、複数のJavaScriptファイルなどが埋め込み指定されている。よって、それを全部あわせたファイル数は、数十くらいになることも珍しくはない。つまり、ひとつのページを読み込むごとに、ブラウザとサーバとのあいだで、数十ものリクエスト・レスポンスが起きているのだ（同一サイト内の移動であれば、２ページ目以降はブラウザがあるていどキャッシュするので、通信はやや少なくなるが）。
特に、バナー広告の多い商業サイトなどでは、JavaScriptやFlashなどが多数埋め込まれ、それぞれの広告配信業者のサーバとのあいだで多数の通信が起きている。もし、広告が重すぎるとか、ジャマだと思う人は、ブラウザの設定でJavaScriptを切ってしまえば、だいぶ軽くなるはずだ（ただし、JavaScriptを切ってしまうと表示できないサイトも一部にある）。
また最近では、ブラウザのURLを遷移させずに、JavaScriptレベルでのHTTP通信を多用する「Webアプリケーション」型のサービスも増えてきている。こういうものの場合、ブラウザのURL欄は変わらないが、内部のJavaScriptレベルで、上記のリクエスト・レスポンスにあたる通信がおこなわれることになる。
以上、ざっくりした話にすぎないが、このくらいの仕組みだけでも、知っていると見通しがよくなると思う。
関連エントリ：
URLの「www.」はいらない
http://mojix.org/2011/08/01/no-www
ウィキペディアの「Uniform Resource Locator」には、こうある。
＜インターネットを、様々なリソースがひしめき合う広大な土地のように捉えれば、URLはリソースの場所を特定する「住所」のようなものと考えることもできる＞。
URLとは、ネットにあるリソース（情報資源）の「住所」なのだ。その住所であるURLは、例えば昨日のエントリであれば、こうなっている。
http://mojix.org/2012/09/11/why-twitter
この文字列は、どういう意味なのだろうか。なぜこれをブラウザのURL欄に入れると、そのページが見れるのだろうか。
詳しくは、同じウィキペディアのページに書いてあるが、ちょっと専門的でむずかしい。ざっくり要点だけまとめると、次のような感じだ。
１） 「http」は、おおまかには「ウェブ」の意味。
２） 「mojix.org」の部分はホスト名といい、ネットにつながっている無数のコンピュータのうち、どのコンピュータであるかをあらわす。「mojix.org」という名前自体は「ドメイン名」で、ブラウザはまずこれをDNSサーバというものに投げて、「49.212.33.25」という「IPアドレス」を受け取る（これを「名前解決」という）。その後、ブラウザはそのIPアドレスを持つコンピュータに接続し、次の「パス名」のリソースを要求する。
３） 「/2012/09/11/why-twitter」はパス名。「mojix.org」というコンピュータに対して、「/2012/09/11/why-twitter」というページを寄こせ、と要求する。その結果、そのページの内容であるHTMLファイルが返ってきて、ブラウザはそれを表示する。
URLの文字列は、ざっとこの３つの部分に分けて理解すればいい。
ブラウザが「mojix.org」というホスト名のコンピュータに対して、「/2012/09/11/why-twitter」というパス名のリソースを要求するとき、以下のような「リクエスト（要求）」が送られている。
GET /2012/09/11/why-twitter HTTP/1.1
Host: mojix.org
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20100101 Firefox/15.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ja,en;q=0.7,en-us;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive
これの１行目の「GET」の部分を「メソッド」と呼ぶ（他に「POST」など何種類かある）。その次に「パス名」が来ている。リクエストでは、この１行目が重要。
２行目の「Host:」の行は、ホスト名が入る。これは、その一台のコンピュータの中にも複数のホスト（≒ウェブサイト）がしばしば入っているので、そのうちどれを対象にしているのかを指定する意味がある。サーバ側から見ると、このホスト名を使って内容を出し分ける「バーチャルホスト」技術のために、これが必要になる。
３行目の「User-Agent:」の行は、ブラウザの名前やバージョン、OS名などが入る。サーバ側から見ると、どういうブラウザや機器を使ってアクセスしているかがわかるので、モバイル機器の場合はモバイル用サイトに移動させる、といったこともできる。
他にも、場合によって、認証関連やクッキー関連など、リクエストにはいろいろなものが入りうる。
このリクエストに対して、サーバ側（「mojix.org」のコンピュータ側）から、以下のような「レスポンス（応答）」が送られてくる。
HTTP/1.1 200 OK
Date: Tue, 11 Sep 2012 13:01:51 GMT
Content-Type: text/html; charset=utf-8
Connection: keep-alive
Content-Length: 5234
Server: gevent/0.13 Python/2.7
（このあとに空行をはさんで、HTMLの内容がつづく）
１行目の「200 OK」は、正常な応答であることを示す。要求されたページがちゃんと見つかったので、それを返しますよ、という意味。正常でない場合は、例えば「404 Not Found」（それは見つかりません）などが返る。レスポンスでも、この１行目が重要。
２行目は応答した日時で、３行目は応答したコンテンツの形式（この場合はHTML）をあらわす。２行目以降は順番を問わず、出てくるものの内容も、場合によって変わる。クッキーを使っている場合、その関連ヘッダなどもレスポンスに入ってくる。
以上のような「リクエスト（要求）」と「レスポンス（応答）」の対が、ファイルごとに起きている。このリクエストとレスポンスは、ブラウザとサーバがともにルールを守ってやっているので、「意思疎通」ができている。ここで使っているルール、「プロトコル」が、この場合「HTTP（Hypertext Transfer Protocol）」であり、これがURLの最初の要素である「http」の意味だ。リクエストとレスポンスの１行目にも「HTTP/1.1」とあり、それがHTTPというルール（仕様）のバージョン1.1にしたがった通信であることを示している。
ひとつのHTMLページには、たいてい複数の画像や、複数のCSS、複数のJavaScriptファイルなどが埋め込み指定されている。よって、それを全部あわせたファイル数は、数十くらいになることも珍しくはない。つまり、ひとつのページを読み込むごとに、ブラウザとサーバとのあいだで、数十ものリクエスト・レスポンスが起きているのだ（同一サイト内の移動であれば、２ページ目以降はブラウザがあるていどキャッシュするので、通信はやや少なくなるが）。
特に、バナー広告の多い商業サイトなどでは、JavaScriptやFlashなどが多数埋め込まれ、それぞれの広告配信業者のサーバとのあいだで多数の通信が起きている。もし、広告が重すぎるとか、ジャマだと思う人は、ブラウザの設定でJavaScriptを切ってしまえば、だいぶ軽くなるはずだ（ただし、JavaScriptを切ってしまうと表示できないサイトも一部にある）。
また最近では、ブラウザのURLを遷移させずに、JavaScriptレベルでのHTTP通信を多用する「Webアプリケーション」型のサービスも増えてきている。こういうものの場合、ブラウザのURL欄は変わらないが、内部のJavaScriptレベルで、上記のリクエスト・レスポンスにあたる通信がおこなわれることになる。
以上、ざっくりした話にすぎないが、このくらいの仕組みだけでも、知っていると見通しがよくなると思う。
関連エントリ：
URLの「www.」はいらない
http://mojix.org/2011/08/01/no-www