データを確実に転送するためのプロトコルであるTCP/IP、及びそれに関連する技術について解説します。
“TCP/IP”とは、TCPとIPという2つのプロトコルの総称で、HTTPを実現するうえでなくてはならない技術です。
そもそも、「HTTPのデータを、クライアントからサーバまで転送する」とは、具体的にどのように実現しているのでしょうか？ 結論から言うと、HTTP通信では「データをある一定の大きさに区切って、それらを連続的に送りつける」ということが行われています。 しかし、この「区切って」「送る」という作業そのものをHTTPが行っているわけではありません。 これらは、IPと呼ばれる別のプロトコルが行っており、IPの世界では、区切られた小さなデータを「パケット」と呼んでいます。
そのパケットを、クライアントからサーバまで転送するわけですが、それら小分けにされたデータを転送すると、何が起こるでしょうか？ 「データの転送」をイメージする時、ある同じルートを行儀良く並んで流れていく様子を思い浮かべるかもしれませんが、実際にはクライアント-サーバ間を繋ぐネットワークは複数存在するため、複数のパケットを送信すると、送信先までそれぞれ別々のルートを辿ったり、運が悪ければ「後に送信したパケットの方が先に目的地に到着してしまう」という場合も起こりえます。 ところが、IPは「指定されたデータを、指定されたIPアドレスまで転送する」という仕事しか与えられていないため、データがいくつかのホストを経由していく中で、パケットを紛失したり消失していたり、あるいは受け取ったデータが破損していたとしても、IPは何もしてくれません。 IPは、パケット送信の「確実性」については何の保証もしてくれないのです。
そこで、その弱点をカバーするために、TCPという別のプロトコルを組み合わせて使います。 TCPでは、相手ホストに対して仮想的な通信路（コネクション）を貼ります。 IPが複数の経路を通してデータ送信していたのに対して、TCPでは「一本道」ができあがりますので、ネットワーク間で「1バイト単位」のデータ通信（バイトストリーム通信）ができるようになるのです。 すなわち、HTTPにおける『接続』の状態とは、「クライアント-サーバ間でTCP接続が確立された状態」ということになります。
TCPは、パケットごとに「TCPヘッダ」というものを追加し、「データの誤り・抜け・順序間違いなどはないかのチェック」「データに誤りがあればデータの再要請」「データの渋滞が起こらないように、送信タイミングの調整」などの処理を行っています。 しかし、これらの作業はすべてTCP側で処理してくれているため、たとえばエラーの再送信などが起こったとしても、HTTPからは全く気づきません。 すなわち、HTTPでは、「データが正しく送られているか」といったことには全く気を使わなくてもいいようにプロトコルが設計されているということになります。
1961年、アメリカのユタ州で3ヶ所の電話中継基地が爆破されるという事件が発生しました。 この時、アメリカの国防回線が完全に停止してしまったのです。 この事件で、仮に中央施設を破壊された場合にも通信を可能にするために、アメリカ国防総省下のARPA（高等研究計画局）は新たな通信システムの研究を開始しました。 インターネットが1ヶ所に全ての機能を集約するのではなく、分散型ネットワークの形を取っているのは、このような軍事的な想定によるものだったのです。
同じ頃に、データを通信する際、そのデータを小さなブロックに分割して、各ブロックに番号と宛先を付けて送り、受信側で小さなブロックを番号順に並べて再現する仕組みについての論文が発表されています。 これが、後にパケット通信方式と呼ばれるものとなるのです。 そして、1969年、カリフォルニア大学ロサンゼルス校（UCLA）、スタンフォード大学、カリフォルニア大学サンタバーバラ校、ユタ大学の4つのホストから成るネットワークが完成し、ARPANETと名付けられました。 これこそが、世界初のパケット交換方式によるネットワークであり、現在のインターネットの起源とも言えるものです。 その後、アメリカやヨーロッパの大学が次々とARPANETに接続するようになり、また他にも USENET, CSNET, BITNETなどのネットワークが続々と誕生しました。
1980年台になって、カルフォルニア大学バークレイ校でコンピュータのオペレーティンクシステムであるBSD UNIXにこのプロトコルを実装した事から、TCP/IPはUNIXの標準通信プロトコルとして広がりました。 現在では、UNIX以外のコンピュータでも標準的に使えるようになり、事実上の標準プロトコル（デファクトスタンダード）として利用されています。
TCPの接続から切断までのシーケンス図を以下に示します。
TCPの接続確立には、3ウェイハンドシェイクという方式が取られます。
SYNパケット（TCPパケットのうち、SYNビットを1にしたもの）」を送るACK+SYNパケット（ACKビットとSYNビットをそれぞれ1にしたもの）」を送るACKパケット」を送る
SYNとは、SYNchronize、すなわち「同期『の要求』」を意味します。
これに対し、ACKとは、ACKnowledge、すなわち「同期の『肯定』」を意味します。
上のリストからわかるように、1と2で「クライアント⇒サーバ間の同期」が確立し、また2と3で「サーバ⇒クライアント間の同期」が確立します。
つまり、1〜3で、「クライアント⇔サーバ間の同期」が確立するのです。
一方、TCPの切断では、切断したい側がFINパケットを送ります。
これはどちらから送っても構いません。
受信した側は、受信できたことを示すACKパケットを返します。
そして、受信側も切断の用意ができたらFINパケットを送り、送信側がACKパケットを返したら、TCP接続が切断したということになります。
TCPでは、相手ホストに対して仮想的な通信路（コネクション）を貼り、バイト単位でデータ通信を行うわけですが、この時、「ある一つのサーバに向かって同時に複数の接続したい（たとえばHTTPとFTPとtelnetを同時に利用したいような）場合はどうするのでしょうか？ ホストコンピュータと端末のマシンの間には、1本の「リンク」はできていますが、このままでは、受信した側がHTTPなのかFTPなのかtelnetなのかがわかりません。 つまり、ホストコンピュータは「どのクライアントからデータが来たのか」、あるいは「どのサーバにデータを渡していいのか」ということがわからないのです。
これを解決するために、TCPではポート番号というものを使って、どのアプリケーションにデータを渡すかを決定します。 ポート番号は1から65535まであり、通信の両端のアプリケーションを識別します。 このうち、1から1023まではサーバアプリケーション用に予約されていますが、それ以上の番号も使用することが可能です。 クライアントアプリケーションは1023より大きな番号が動的に割り当てられます。
このうち、よく使われるプロトコルのポート番号はWell-known-Portとして、RFC 1700にて定義されています。
たとえば、HTTPサーバには80番、FTPは21番、telnetサーバは23番となっています。
これにより、同じ端末間で複数のアプリケーションを同時に使用した場合でも、お互いのデータが混乱なく、相手のアプリケーションに伝わるようになっています。
（※） HTTPの既定ポート番号は80ですが、これ以外のポート番号を使用してもかまいません。
たとえば、HTTPの場合は、80から連想される8000や8080などがしばしば利用されていますが、FTPが利用されていなければ、ポート番号に21を使用したりしてもかまいません。
ただし、広く利用されるサーバでは、Well-known-Portのような有名な番号を割り当てると混乱のもととなるので、やめた方がよいでしょう。
IP とは、OSI モデルではネットワーク層にあたり、インターネットでデータをやり取りするためのプロトコルです。 IP では、送信されるデータはパケットと呼ばれるデータ単位に分割され、あるパケットが中継装置により中継されながら始点の端末から終点の端末まで送られる際に、各中継装置で次の IP パケットの送り先を適切だと思われるルートを自動的に探索しながら目的地まで順次転送していきます。 これをルーティングと言い、多くの場合ルータ (router) と呼ばれる機器がこの役目を担っています。 ルーティングは、パケットを繰り返し渡していく事によって、パケットを望んだところまで運んでいく事から、よく「バケツリレー」に例えられます。
この時、各パケットの先頭にはそのパケットの送信先等の外部情報が書き込まれた IP ヘッダが付与されます。 パケット送信先の住所にあたるものを IP アドレスと呼び、各端末ごとに割り付けられます。 現在の IP (IPv4) では、IP アドレスは 32 bit の長さをもっており、通常 8 bit (オクテット) 毎に 4 つに区切り、小数点付 10 進記法 (dotted decimal notation) で表されます (例: 192.168.1.2) 。
IP アドレスは、外部ネットワークから特定のネットワークを識別するためのネットワークアドレスと、特定のネットワークの内部に接続される端末コンピュータのアドレスを識別するためのホストアドレスからなっています。 そして、ネットワークの大きさに応じてクラス A からクラス C まで三つのクラスに分類されます。 その他、クラス D がマルチキャスト用に、クラス E が実験用に、それぞれ予約されています。
ネットワークアドレスが同じ IP アドレス同士は、直接通信を行う事ができます。 このようなホスト同士は「同じネットワーク上にいる」と表現される事もあります。 一方、送信先のホストが同じネットワーク上にいない場合は、ホストはそのネットワークと、その外側 (インターネット) とをつなぐゲートウェイと呼ばれるホストへパケットを送ります。 ゲートウェイは、送り先に最も近いと思われるゲートウェイへとパケットを転送します。 パケットを受け取ったゲートウェイは、もしその宛て先が自分のネットワーク内のものであれば、それを受け入れます。 違う場合には、再び最も近いと思われるゲートウェイへとパケットを転送するのです。 このようにして、パケットは最終的に目的地に到達する事ができるのです。
IP アドレスのクラス分けは、IP アドレスを二進数で表記するとよくわかります。
例えば、クラス C の IP アドレスは左から 3 ビットが 110 です。
続く 21 ビットがネットワークの区別のために用いられ、更に最後の 8 ビットでネットワーク内のホストを区別するのです。
先程の 192.168.1.2 は、192 が二進表記で 11000000 である事から、クラス C の IP アドレスである事がわかります。
| クラス | 対応する IP アドレス | 二進表記 | |||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| クラス A | 1.0.0.0 -> 126.255.255.255 | 0 | 7 ビット | 24 ビット | |||||||||||||||||||||||||||||
| クラス B | 128.0.0.0 -> 191.255.255.255 | 10 | 14 ビット | 16 ビット | |||||||||||||||||||||||||||||
| クラス C | 192.0.0.0 -> 223.255.255.255 | 110 | 21 ビット | 8 ビット | |||||||||||||||||||||||||||||
| クラス D | 224.0.0.0 -> 239.255.255.255 | 1110 | - | ||||||||||||||||||||||||||||||
| クラス E | 240.0.0.0 -> 254.255.255.255 | 11110 | - | ||||||||||||||||||||||||||||||
クラス A, B, C の IP アドレスに対して、ホスト部が全て 0 のものは、そのネットワーク全体を代表する番号を表します。
また全て 1 のものはそのネットワークに接続されている全てのホストへ同時に送信するためのアドレスで、ブロードキャストアドレスと呼ばれます。
また、127.0.0.1 はループバックアドレスといい、ネットワーク中のどのホストでも自分自身を指すというアドレスです。
IP アドレスは、TCP/IP 通信を行うためには必須のもので、その値はユニーク (一意) である事が求められます。 従って、ユーザが勝手にアドレスを使用するわけにはいきません。 IP アドレスが必要なユーザは、NIC という組織に申請をします。 それを受けて NIC は、世界的に統一した方針で IP アドレスを交付し、管理していくという形を取っています。 しかし、実際には NIC だけでは対応できないので、世界中に業務を委託された組織があります。 日本では、JPNIC が処理を行っています。
現在広く利用されているIPは、IPv4と呼ばれる方式ですが、IPv4におけるIPアドレスの「広さ」は32ビット分なので、およそ42.9億台のホストしか接続できません。 IPが使われ始めた頃は、この数は十分大きな数であったのですが、インターネットに接続するホストは年々爆発的に増大しており、遂に2011年、世界中に割り当てるためのIPアドレスの在庫がなくなって（※）しまいました。
（※） IPアドレスはIANAという組織が世界中のIPアドレスを管理しておりますが、「在庫がなくなった」とは新規配布するためのIPアドレスが尽きたという意味であり、「IPv4方式でインターネットができなくなった」という意味ではありません。
そのため、「次世代 IP」と言うべき技術が1990年代前半から考えられており、現在すでに利用されている技術には、以下のようなものがあります。
「IPv4というプロトコルそのものを置き換えよう」という考え方で、開発されたのがIPv6と呼ばれる方式です。 IPv6では、アドレスの長さをIPv4（32ビット）の4倍である128ビットにしています。 アドレスの長さを4倍にする事で、接続できるホスト数は実に296＝8穣（＝8兆×10000兆）倍になります。 IPv6についての最初のRFCは、1995年12月に発行されたRFC 1883ですが、実装の難しさや、既存のIPアプリケーションとの互換性等の問題から、一気に置き換わるということはありませんでした。 しかし、すでにIPv4アドレスは新規配布されなくなってしまうことがはっきりしているため、間違いなく徐々にIPv6に置き換わっていくものと思われます。
クラス C のアドレスを一つ取得すると、ネットワークアドレスとブロードキャストアドレスの分を除いた、全部で 254 個のホストが接続できます。 しかし、そのネットワークに接続するホストが高々 100 個しかない事がわかっている場合、クラス C のアドレスを確保しても、IP アドレスが無駄になってしまいます。 このように、一つの大きなネットワークから、小さなネットワーク、すなわち「サブネット」を構築したい際に、そのサブネットを取り出すために用いるのがサブネットマスクなのです。
ネットワーク番号とサブネットマスクを表す方法として、192.168.1.0/25 という記述法が用いられる事があります。
192.168.1.0/25 では、対象 IP アドレスと、25 ビットの 1 と残り 7 ビットの 0 を並べた 11111111 11111111 11111111 10000000 の AND (論理積) をとったものをネットワークアドレスとします。
すなわち、この場合 192.168.1.0 〜 192.168.1.127 までの 128 個の IP アドレスが同じネットワーク上にいることになり、これらの IP アドレスを確保する事ができます。
(※) サブネットマスクは、小数点つき 10 進記法で記述される事もあります。
a.b.c.d/25 の場合、サブネットマスクは 255.255.255.128 となります。
ここで簡単な例を示します。 以下のような、三つのホストがあるとします。
今、サブネットマスクが 255.255.255.128 だとして、これらのホストが同じネットワーク上にいるかどうかを調べましょう。
但し、三つの IP アドレスの最初の 24 ビットが全て同一であり、サブネットマスクの最初の 24 ビットが全て 255 なので、最後の 8 ビットのみについて検証します。
| Host A | Host B | Host C | |
|---|---|---|---|
| IP アドレス (10 進表記) | 111 | 121 | 131 |
| IP アドレス (2 進表記) | 01101111 | 01111001 | 10000011 |
| サブネットマスク (2 進表記) | 10000000 | 10000000 | 10000000 |
| AND (2 進表記) | 00000000 | 00000000 | 10000000 |
| AND (10 進表記) | 0 | 0 | 128 |
すなわち、Host A と Host B のネットワークアドレスは 192.168.1.0 になりますが、Host C は 192.168.1.128 となり、Host C だけが異なるネットワークにいるという事がわかるのです。
従って、Host A と Host B が通信を行う時は直接パケットを送る事ができますが、Host A (B) と Host C が通信を行う場合は、デフォルトゲートウェイにパケットを送信する事になります。
先に「IP アドレスはユニークである事が求められる」と書きましたが、この IP アドレスの一意性は、外部ネットワークに接続しているホストに求められる事です。 そのため、「LAN のような、外部から参照されない閉じたネットワーク内では、IP アドレスを任意に割り当てる事にしよう」と、概念が拡張される事になりました。 この時、NIC によって公式に管理されている IP アドレスをグローバル IP アドレスと呼び、それに対し閉じたネットワーク内で使用される IP アドレスをプライベート IP アドレスと言います。 NAT とは、このグローバル IP アドレスとプライベート IP アドレスを透過的に相互変換する技術です。 また、IP アドレスと同時にポート番号も変換するような技術を NAPTと言います。
(※) Linux 上で実装された NAPT は、IP マスカレードという名称で呼ばれました。 現在、これらの用語は混同して用いられていますが、実質的に同じ意味だと考えてよいでしょう。
DHCP は、RFC 951 で規定されている BOOTP を拡張したプロトコルで、ネットワーク上のシステムの IP アドレスを集中管理するために使用されます。 DHCP は RFC 2131 及び RFC 2132 にて規定されています。
通常、IP アドレスは、管理者から割り当てられたものを利用者が手動で設定しなければなりません。 しかし、この方式では、利用者が間違えて入力したり、管理者が重複したアドレスを指定させてしまうといった可能性があります。 そういった問題の原因を突き止めるのは大変なものとなるでしょう。 このような問題を起こさないためには、静的な IP アドレスを割り当てればよいのですが、ネットワークを使用していない時にはその IP アドレスが遊休状態になってしまうので、 IP アドレスが不足している現状ではあまり適した方法とは言えません。
DHCP では、クライアントの初回接続時に、IP アドレスや、デフォルトゲートウェイ、サブネットマスク等の情報を動的に割り当て、かつ接続終了時には自動的に IP アドレスを回収します。 回収した IP アドレスは、次に接続してきたコンピュータに割り当てます。 このようにして、利用者は設定する事なしにネットワークに接続でき、また管理者は多くのクライアントを容易に一元管理できるようになります。
DHCP では、クライアントに割り当てられた IP アドレスに利用可能期間を設ける事ができます。 これをリース期間と言います。 リース期間が終了すると、現在割り当てられている IP アドレスは破棄され、DHCP クライアントは再び DHCP サーバに再割り当てを要求しなければなりません。 このようにして、常に必要最小限の IP アドレスでのネットワークの運用が可能になります。
全てのネットワークは層（レイヤ）{layer}として構成される階層的な転送プロトコルを使用します。 通常、これらのレイヤをまとめたものをプロトコルスタック（あるいは「ネットワークプロトコルスタック」）と呼びます。
元々、転送プロトコルというものはそれぞれのコンピュータ会社が独自に定めていました。 しかし、コンピュータ間通信のニーズが高まると同時に、機種に依存しないプロトコルが求められてきたので、ITUやISOといった団体を中心に、異機種間のデータ通信を実現するためのネットワーク構造の設計方針として、OSI 7層構造モデル（あるいは「OSI基本参照モデル」や「OSI階層モデル」と呼ばれることもある）が策定されました。 以下の表をご覧ください。
| 階層No | 階層名 | 役割 |
|---|---|---|
| 第7層 | アプリケーション層 | アプリケーションを実現するためのプロトコルの集合 |
| 第6層 | プレゼンテーション層 | 異機種間でのデータの表現形式の違いを補性 |
| 第5層 | セッション層 | データのエラー発生時の同期・中断・再開を実現 |
| 第4層 | トランスポート層 | 相手マシンと通信し、データの確実な通信を保証 |
| 第3層 | ネットワーク層 | 各通信手段の入出力、ルーティングの管理 |
| 第2層 | データリンク層 | データを送受信する二つのノード間での正しい転送を保証 |
| 第1層 | 物理層 | 物理的に二点間を接続する経路を実現 |
下の図は「Ethernet+TCP/IP という環境で HTTP を利用する」といったケースにおける、プロトコルスタックと OSI 7 層構造モデルの対応を表したものです。
この図からわかる通り、現実に利用されている通信プロトコルはOSI 7層モデルの各層と一対一対応しておらず、実際には複数層を網羅的にサポートする形になっています。 TCP/IP以外にでも、現実の通信プロトコルの多くは、上記のように複数層をまたいだプロトコルの組み合わせで成り立っています。 それもそのはずで、実はTCP/IPの成立はOSIモデルよりも先であるため、TCP/IPは7階層構造にはなっていないのです。 OSIモデルは、現実から理想のプロトコルの役割分担を想定した1つの理想像なので、守らなければならないという制約のようなものがあるわけではありません。
ARP とは、Address Resolution Protocol の略で、TCP/IP ネットワークにおいて、IP アドレスから Ethernet の MAC アドレス（物理アドレス）を求めるのに使われるプロトコルです。
Ethernet 上にパケットを送出するためには、IP アドレスではなく、宛先の MAC アドレスを知らなければなりません。 そのために、ARP というプロトコルを使い、ARP テーブルを作成します。 ARP テーブルとは、一言で言うと IP アドレスと MAC アドレスの対照表です。
ARP は単純なプロトコルで、知りたい IP アドレスをパケットにセットして、 ブロードキャストを行います。 これは Ethernet ヘッダ中の宛先 MAC アドレスを“ff:ff:ff:ff:ff:ff”にして送信するというものです。 そのパケットは、そのネットワークにある全ての通信機器（ノード）が受信し、探している IP アドレスが自分のものの場合は、自分の MAC を応答します。 そうでない場合は単に無視します。
以下は、192.168.0.102 という IP アドレスを探している場合の概念図です。
一度探した IP アドレスは、ARP テーブルという対応表にキャッシュしておくことで再び検索をする手間と負荷を節約します。 現在の ARP テーブルは、プロンプトで“arp -a”と入力することで確認できます。
C:\hash>arp -a Interface: 192.168.0.100 --- 0x10003 Internet Address Physical Address Type 192.168.0.2 00-12-34-56-78-90 dynamic 192.168.0.80 00-ab-cd-ef-99-88 dynamic 192.168.0.101 00-a1-b2-c3-d4-e5 dynamic 192.168.0.102 00-12-34-56-78-ab dynamic 192.168.0.254 00-99-ff-99-ff-99 dynamic
通信にはデータの送信先の住所にあたる IP アドレスを使って行われると書きました。 最も初期のネットワークでは、他のマシンや周辺機器 (プリンタ等) に対してパケットを送る場合に、その数字を覚えていないといけなかったのです。 しかし、IP アドレスというものは単なる数字の羅列なので、いくつものアドレスを記憶するのには向いてません。 また、あるホストが別のネットワークへと移る場合、その IP アドレスは変更しなければなりませんが、そのような場合にはまた IP アドレスを覚え直さないといけませんでした。 このように、ネットワーク上のホストを識別する際に、 IP アドレスを使用するのは、マシンにとっては都合通いのですが、それを利用する人間にとってはいろいろと不便が生じるのです。
そこで、各ホストに名前をつけて通信を行う事が考えられました。 マシンに名前をつけておけば、覚えておくのに便利だし、それが別のネットワークに移った場合でも、IP アドレスとその名前のマッピングを変更しさえすれば、ユーザはいちいち気にする事なく、そのマシンにアクセスする事ができます。 この IP アドレスとホスト名のと対応表は、最初は hosts ファイルという一枚のファイルを用意する事でこれを実現していました。 この hosts ファイルは、実は現在も利用されていて、例えば Windows 等の OS にも入っています (Windows がインストールしてあるドライブを検索してみて下さい)。 hosts ファイルに IP アドレスと好きなホスト名の対を記述すれば、そこでつけた名前でマシンに接続する事ができます。
(※) HTTP/1.1 通信の場合、実際には Host ヘッダとの兼ね合いもあるので、接続できない可能性もあります。
しかし、インターネットが普及してくると、ホスト数が爆発的に増加し、それにつれて hosts ファイルの大きさも非常に大きくなり、一ヶ所で集中的に管理を行う事は難しくなってきました。
そこで考案されたのが DNS サービスです。
DNS サービスでは、ホスト名に組織毎の名前をつけて管理し、その管理も組織毎に分散して管理できるような仕組みが導入されました。
この組織毎の名称をドメイン名と言います。
インターネットで使用するホストの名称は、このドメイン名と、その組織内で使用するホスト名の組み合わせで呼びます。
ドメインは . で区切られ、例えば、studyinghttp.net という組織にある www というホストは、www.studyinghttp.net と表記されます。
また、その組織内に mail や ns というホストがあれば、それぞれ mail.studyinghttp.net, ns.studyinghttp.net と表記されます。
www.studyinghttp.net のように、特定のホストを表す正式なドメイン名を FQDN と言います。
本来「ホスト名」とは、www や mail のように、コンピュータに与えられた名前の事を言いますが、しばしば、ホスト名と FQDN は混同されるので、専門書籍等で「ホスト名」と書かれていた場合は、その文脈からどちらの意味なのかを正確に判断する必要があります。
www.studyinghttp.net という FQDN の最後尾のドメイン net は、トップレベルドメイン (TLD) と呼ばれ、以下セカンドレベルドメイン、サードレベルドメイン、…と呼ばれます。
ドメイン名は、階層構造になっており、管理が容易になっており、また重複を避けるのに役立ちます。
トップレベルドメインは、一般トップレベルドメイン (gTLD）と、国コードトップレベルドメイン (ccTLD）に分けられます。
このうち、gTLD は ICANN が管理する、一般に広く国際的に利用できるトップレベルドメインで、以下のようなものがあります。
| ドメイン | 解説 |
|---|---|
| ac | 教育関連ネットワーク |
| aero | 航空運輸業界用 |
| arpa | ARPANET, 現在はインターネットインフラ用に存在 |
| biz | ビジネス用 |
| co | 商業組織用 |
| com | 商業組織用, 現在は誰でも利用可能 |
| coop | 協同組合用 |
| edu | 米国高等教育機関用 |
| gov | 米国政府機関用 |
| info | 制限なし, 誰でも利用可能 |
| int | 国際機関用 |
| mil | 米国軍事機関用 |
| museum | 博物館・美術館等用 |
| name | 個人用, 誰でも利用可能 |
| nato | NATO |
| net | ネットワーク用, 現在は誰でも利用可能 |
| org | 非営利団体用, 現在は誰でも利用可能 |
| pro | 弁護士・医師・会計士等用 |
(※) 現在も gTLD についての議論は行われており、今度新しい gTLD が作られる可能性があります。
一方、jp のような ccTLD は、原則として ISO-3166 にて規定されている国コードを使用しており、各国の NIC が管理しています。
日本では JPNIC がこれに当たります。
ところで、FQDN の正しい文法では、www.studyinghttp.net. のように、最後に . をつける必要があります。
この最後のピリオドが何を表しているかというと、実は DNS の仕組みに大いに関係しているのです。
あるホスト名 (FQDN) を IP アドレスに変換するものをリゾルバ{resolver} と言いますが、このリゾルバは自身が知らないホスト名に出会った時は、まず世界中に 13 台しかないルートサーバに問い合わせに行きます。 このルート{root} を表しているものが、最後の "." なのです。
例えば、www.studyinghttp.net について調べるとします。 この時、リゾルバはまずルートサーバ (実際には、そのうちのいずれか) にアクセスします。 13 台のルートサーバは、gTLD と ccTLD の全ての DNS サーバについての情報を持っているので、TLD である "net" の情報を持つ DNS サーバについての情報を返してくれます。
この結果を受けて、次に "net" の情報を持つ DNS サーバにアクセスします。 このサーバは、sourceforge.net や php.net、そして studyinghttp.net 等、すなわち FQDN が ".net" で終わる DNS サーバがどこにあるかを全て知っているので、"studyinghttp.net" の情報を持つ DNS サーバについての情報を教えてもらいます。 同様にして、studyinghttp.net の DNS サーバから、www.studyinghttp.net がどこにあるかを教えてもらう事によって、最終的に www.studyinghttp.net を IP アドレスに変換する事ができるのです。 このような方法を再帰 (Recursive) 検索と言います。
(※) 一度、変換したホストを何度も変換するのはトラフィックの無駄になるので、変換を要求した DNS クライアントや、変換を中継した DNS サーバは、その変換結果をキャッシュする事ができます。
このような構造を木構造と言い、図にするとちょうど木を逆さまにしたようなものになります。 先ほど出てきた「ルート」という言葉は、まさに「根」という意味である事からも、理解していただけると思います。
DNS における問い合わせの方法は RFC によって標準化されていますが、世界中で最も利用されている DNS サーバとして、カリフォルニア大学バークレイ校で開発された BIND というものがあります。 これは、ホスト名から IP アドレスを変換する正引き (順引きと呼ばれる事もある) と、IP アドレスからホスト名に変換する逆引きの対応を記したゾーンファイルと呼ばれるファイルを用意する事で DNS を実現しています。
PPPとは、OSI 7層構造モデルでいうところの「データリンク層」に相当するプロトコルで、RFC 1661にて標準化されています。 最近では少なくなりましたが、かつてはISPが提供する電話番号にダイアルアップして、電話回線経由でWebを利用するといった形態がよく見られました。 以下の図をご覧ください。 このように、PPPを使うと、電話回線でやりとりするモデムを、まるでLANのインタフェースのように扱うことができるようになります。
PPPは、ユーザ認証ができたり、IPアドレスを動的に割り当てたりできる有用なプロトコルなので、ADSLサービスやFTTHサービスの常時接続環境でも利用できるように拡張されました。 これをPPPoEと言い、こちらもRFC 2516にて標準化されています。 現在、日本の多くのISPがPPPoEを採用しています。
, All Rights Reserved.