アプリケーション層のプロトコル
HTTP が「ステートレス」であるとは、どういう意味か。
各要求の意味が、それ以前のやり取りに依存せず単独で解釈できるということ。 RFC 9110 は HTTP を「分散協調型のハイパテキスト情報システムのための、ステートレスな アプリケーションレベルのプロトコル」と規定している。
DNS の名前空間で、下位の管理はどのような形で委ねられるか。
名前はラベルの並びで表され、親のゾーンが子のゾーンへ到達するための情報（NS RR）を持つ形で委ねられる。
RFC 1122 のアプリケーション層には user protocols（Telnet・FTP・SMTP）と support protocols（SNMP・BOOTP・DNS）が含まれ、HTTP はステートレスな要求応答プロトコルで、DNS は名前空間・ネームサーバ・リゾルバの 3 つからなる。
| 区分 | RFC 1122 が挙げる例 |
|---|---|
| user protocols | Telnet, FTP, SMTP |
| support protocols | SNMP, BOOTP, DNS |
HTTP のステータスコードは 5 つのクラスに分かれる。
| クラス | 名称 |
|---|---|
| 1xx | Informational |
| 2xx | Successful |
| 3xx | Redirection |
| 4xx | Client Error |
| 5xx | Server Error |
1xx は最終応答の前に暫定的な情報を伝えるクラスである。他の 4 クラスの意味は 名称から読み取れる範囲を超えて記載しない（RFC 9110 §15 の本文を取得できていないため）。
RFC 1122 は、アプリケーション層をインターネットプロトコル群の最上位の層とし、 user protocols（Telnet、FTP、SMTP）と support protocols（SNMP、BOOTP、DNS）を含むとしている。 2 つの区分の違いは、ここで根拠にした記録には書かれていない。
RFC 9110 は HTTP を「分散協調型のハイパテキスト情報システムのための、ステートレスな アプリケーションレベルのプロトコル」と規定し、「1 つの接続の上でメッセージを交換するための ステートレスな要求応答プロトコル」として動作すると説明している。 状態を持たないとは、各要求がそれ以前のやり取りに頼らず単独で解釈できるという意味である。
規定されているのは GET、HEAD、POST、PUT、DELETE、CONNECT、OPTIONS、TRACE の 8 つである。
応答のステータスコードは上の図の 5 クラスに分かれる。
RFC 1035 は DNS の目的を「異なるホスト、ネットワーク、プロトコル族、インターネット、 管理組織をまたいで使える形で資源に名前を付ける仕組みを提供すること」と述べている。
RFC 1034 は DNS の構成要素を 3 つ挙げている。ドメイン名空間と資源レコード （木構造の名前空間と、名前に結び付いたデータの仕様）、ネームサーバ （ドメインの木構造とその情報を保持するサーバプログラム）、リゾルバ （クライアントの要求に応じてネームサーバから情報を取り出すプログラム）である。
名前空間はいくつかのゾーンに切り分けられ、ゾーンはその範囲に属するすべての名前について 権威を持つ。ゾーンの下端では NS レコードが下位ゾーンのサーバを指名しており、 親ゾーンは子ゾーンのサーバへ到達するのに必要な情報をすべて持っている。
名前空間は逆さの木として階層的に構成され、ドメイン名は「ラベルの並び」で表される。 実際のデータは資源レコード（RR）として保持され、代表的な型には A（ホストアドレス）、NS（権威あるネームサーバ）、MX（メールの配送先）、 CNAME（別名に対する正式名）、PTR（ドメイン名へのポインタ）がある。
前提
関連