「こんにちは、アミーゴ!」

「こんにちは、ビラーボ!」

「今日はどんな新しいことを教えてくれるの?」

「いろいろあります。でもまずは、ネットワークとインターネットの利用について話し合おうと思います。興味はありますか?」

「そうです。銀河インターネットはとてもクールです。」

「それでは、歴史から始めましょう。21 世紀初頭、状況はこうでした…」

「インターネットに接続されているすべてのコンピューターには固有の番号があります。これは通常の 4 バイトの数字です。これは IP アドレスと呼ばれます。」

「しかし、人間は記憶力が弱く、2108458776 のようなものを思い出すのに苦労するため、各バイトを別々に書くことがよくあります。」

「4 バイトの数値 2108458776 を別々のバイトに分割すると、125.172.135.24 が得られます。思い出していただけると思いますが、各バイトは 8 ビットで構成され、0 から 255 までの数値を含めることができます。」

「それで、数字はそうやって書くのですか?」

「はい。このように書くと、(人間にとって) 4 バイトの数字を覚えやすくなります。」

「偶然にも、4 バイトのみを使用するという選択は、すぐに残酷なトリックを仕掛けました。インターネットに接続されているデバイスの数が急速に増加したため、すぐに数が足りなくなってしまいました。」

「彼らはどうやってそれを回避したのですか?」

「彼らは人間が通常行うことを行いました。」

「彼らは IP アドレスの新しい標準を考案し、誇らしげにそれを IPv6 と名付けました。」

「一意の数値を形成するために 4 バイトを使用する通常の IP アドレス (IPv4 と呼ばれる) とは異なり、新しい標準では 16 バイトが使用されます。」

「考えてみてください。人間は通常の数字 (2108458776 など) の 10 桁を覚えることができないため、数字を 4 つの部分に分割する必要がありましたが、その後 16 バイトで構成される数字を使用することを考えました。」

「そうね、人間って時々変なのよ。」

「そう、人間は人間だ」

「とはいえ、彼らは窮地を脱した。」

「彼らは数字を覚えるのに飽きて、数字を言葉に置き換えることにしました。」

「どうですか?例を挙げてもらえますか?」

「もちろん、web.mail.comgoogle.comnew.books.amazon.com、…」

「このような名前をドメインと呼びます。」

「このインターネットが適切に機能するために、各ドメイン名の IP アドレスを格納するドメイン ネーム システム (DNS) と呼ばれる特別なテーブルが作成されました。」

「仕組みは次のとおりです。」

1) ユーザーはブラウザにアドレス (例: web.mail.com )を入力します。

2) ブラウザは DNS にアクセスし、ドメイン名を使用して IP アドレスを取得します。

3) 必要な URL を含むリクエストがこの IP アドレスに送信されます。

「それはあまり単純ではないようです。」

「しかし、このアプローチにはいくつかの利点があります。」

1) 人間は言語化できる名前を覚えやすいと感じます。」

" 2) ドメイン名は、名前の先頭にサブドメインを追加することで階層的に構築できます。Java のパッケージ名とまったく同じです。"

" 3) Web サーバーの IP アドレスを変更する必要がある場合は、DNS レコードを変更するだけで済み、すべてが以前と同じように機能します。ユーザーは新しいアドレスを覚える必要はありません。"

「DNS は次のようになります。」

ドメイン名 IPアドレス
mail.com 128.35.36.189
web.mail.com 145.12.17.13
new.mail.com 192.155.15.3
Google COM 92.117.151.100
Google COM 193.168.0.1
docs.google.com 217.12.222.1

「理にかなっていますね。」

「とにかく、ドメインはコンピュータの名前です。しかし、コンピュータは必要ありません。コンピュータ上にあるものが必要なのです。これが URL の役割です。」

「当初、URL は実際には別のコンピュータ上のファイルへのリンクでした。例:」

http://info.codegym.cc/user/info/profile.html _ _ _ _
説明
http は、クライアント/サーバー通信のプロトコルです。
info.codegym.cc は、コンピュータのドメイン名です。
user/info/profile.html は、 コンピュータ上のファイルへのパスです。

「ネットワーク開発の初期段階では、Web サーバーは URL を使用して、どこかに保存されているファイルを提供することしかできませんでした。URL は実際には、ファイルへのグローバル パス (コンピューター名 + パス) でした。」

「その後、Web サーバー自体がファイルを生成し始めたとき、URL は少し変更され、Web サーバーへのリクエストになりました。リクエスト パラメーターも追加されました。」

「今日では、URL の末尾にファイル拡張子があることはほとんどありません。」現代の URL は、パラメータを備えた一意のリンクにすぎません。グローバル ファイル パスというよりはメソッド呼び出しに似ています。」

「古典的な最新の URL は次のようになります。」

URLの解析
http://codegym.cc/alpha/api/contacts ? _ _ _ _ userid=13&filter=none&page=3
URLの各部分の説明
codegym.cc はドメイン名です。インターネット上のコンピュータの一意の名前 (アドレス) です。
http はクライアント/サーバー通信用のプロトコルです
alpha/api/contacts は、  Web サーバーのリクエスト、またはサーバー上の Web ページのリクエストです。
userid=13 & filter=none & page=3 は リクエストパラメータを含む文字列です

「はい、覚えています。最近、URL について教えていただきました。」

「あと港についても。マンションの例を挙げましたね」

「『http』が何なのか教えてもらったほうがいいですね。『プロトコル』という文字があちこちに書かれていますが、それが何なのかよくわかりません。」

「わかりました。早速お話します。」

IPアドレス、ドメイン、URL - 1

HTTP はHyper Text Transfer Protocolの略で、ハイパーテキストを転送するためものです。」

「ハイパーテキストって何?」

「それはHTMLです。」

「大まかに言えば、プロトコルは通信のための一連のルールです。プロトコルは、Web サーバーに送信できるリクエストとその形式、および Web サーバーがどのように応答するかを記述します。」

「簡単に言えば、状況は次のとおりです。通常のテキスト ファイル、または必要に応じて大きなテキストの塊がクライアントとサーバーの間で送信されます。

リクエストがサーバーに届き、サーバーは各リクエストに対して応答を返します。」

「そのようなリクエストとレスポンスの例を次に示します。」

リクエスト
GET alpha/api/contacts HTTP/1.1
Host: codegym.cc
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en; rv:1.9b5) Gecko/2008050509 Firefox/3.0b5
Accept: text/html
Connection: close
説明
GET – request subtype
alpha/api/contacts – request to the web server
HTTP/1.1 – protocol version – HTTP/1.1
Host: codegym.cc – domain name
User-Agent: Mozilla/5… – unique browser name
Accept: text/html – requested document type: HTML
Connection: close – close the server connection after processing the request.

「最初の行は実際のリクエストです。これに続くのは、「ヘッダー フィールド」とも呼ばれる追加のリクエスト パラメーターです。

「応答の例は次のとおりです。」

応答
HTTP/1.1 200 OK
Date: Wed, 11 Feb 2009 11:20:59 GMT
Server: Apache
X-Powered-By: PHP/5.2.4-2ubuntu5wm1
Last-Modified: Wed, 11 Feb 2009 11:20:59 GMT
Content-Language: en
Content-Type: text/html; charset=utf-8
Content-Length: 1234
Connection: close
<html><body><a href="http://ample.com/about.html#contacts">Click here</a></body></html>
HTTP/1.1 200 OK - «200 OK» means everything is okay.
Date: Wed, 11 Feb 2009 - Date on which the request was processed
Server: Apache - Name of the web server
X-Powered-By: PHP - The server uses PHP
Last-Modified: Wed, 11 Feb 2009 - The time of the last update of the requested file
Content-Language: en - The language of the file
Content-Type: text/html; charset=utf-8 – This is an HTML-file with UTF-8 encoding
Content-Length: 1234 - The response is 1234 bytes long
Connection: close - The connection will be closed after the request is handled
<html><body><a href="http://ample - The HTML file itself.

「次の 2 つのことに注意していただきたいと思います。」

「まず、何をリクエストしても、それはサーバーへのファイルリクエストのように見えます。ファイルがサーバー上にあるか、サーバーがリクエストに応じてファイルを生成するかは関係ありません。」

「2 番目に、ファイル自体はHTTP 応答の一部として送信されます。言い換えると、サーバーの応答の先頭に追加データがあり、その後に提供されるファイルの本文が表示されます。

「面白いですね。すべてを理解できたかどうかはわかりません。後でもう一度読みます。」

「ああ、もう 1 つ小さな、しかし興味深いものについてお話したいと思います。それはクッキーです。」

"それらは何ですか?"

「HTTP プロトコルによれば、Cookie は、サーバーがクライアントに保存するためにクライアントに送信する小さな情報です。そして、後続のリクエストの一部としてサーバーに送り返されます。

「それで、それは何の意味があるのですか?」

「ユーザーが Web サイトのホームページにサインインしているとします。サーバーはこのユーザーのセッション オブジェクトをサーバー上に作成し、一意のセッション番号が Cookie としてクライアントに送信されます。クライアントからサーバーへの次のリクエスト中に、サーバーに送信すると、このセッション番号は他の Cookie とともにサーバーに送り返されます。これは、サーバーが新しいリクエストを送信したユーザーを認識できることを意味します。」

"なんて面白い!"

「はい。独自のサーブレットを作成するときに、このトピックを詳しく見ていきます。しかし、今は休憩しましょう。」

「何を言ってもいいよ。」