1.2 階層化
ネットワーク プロトコルは通常、異なる層で開発され、各層が異なる通信機能を担当します。TCP/IP などのプロトコル スイートは、さまざまなレベルで複数のプロトコルを組み合わせたものです。TCP/IP は、図 1-1 に示すように、通常 4 層のプロトコル システムとみなされます。
各層は、さまざまな機能を担当します。
1. リンク層 (データ リンク層またはネットワーク インターフェイス層とも呼ばれます) には、通常、オペレーティング システムのデバイス ドライバーと、コンピュータの対応するネットワーク インターフェイス カードが含まれます。これらは一緒になって、ケーブル (またはその他の伝送媒体) への物理インターフェイスの詳細を処理します。
2. ネットワーク層はインターネット層とも呼ばれ、パケットのルーティングなど、ネットワーク内のパケットのアクティビティを処理します。TCP/IP プロトコル スイートでは、ネットワーク層プロトコルには、IP プロトコル (インターネット プロトコル)、ICMP プロトコル (インターネット コントロール メッセージ プロトコル)、および IGMP プロトコル (インターネット グループ管理プロトコル) が含まれます。
3. トランスポート層は主に、2 つのホスト上のアプリケーションにエンドツーエンド通信を提供します。TCP/IP プロトコル スイートには、TCP (伝送制御プロトコル) と UDP (ユーザー データグラム プロトコル) という 2 つの異なる伝送プロトコルがあります。TCP は、2 つのホスト間で信頼性の高いデータ通信を提供します。この作業には、アプリケーションによって渡されたデータを適切な小さな部分に分割して下層のネットワーク層に渡すこと、受信パケットの確認応答、最終確認パケットを送信するためのタイムアウト クロックの設定などが含まれます。トランスポート層は信頼性の高いエンドツーエンド通信を提供するため、アプリケーション層はこれらの詳細をすべて無視できます。一方、UDP は、アプリケーション層に非常に単純なサービスを提供します。データグラムと呼ばれるパケットをあるホストから別のホストに送信するだけで、データグラムが相手側に到達することは保証されません。必要な信頼性はアプリケーション層によって提供される必要があります。これら 2 つのトランスポート層プロトコルはそれぞれ、後で説明するように、さまざまなアプリケーションでさまざまな用途があります。
4. アプリケーション層は、特定のアプリケーションの詳細を処理する責任があります。ほとんどすべての異なる TCP/IP 実装は、次の共通アプリケーションを提供します。
• Telnet リモート ログイン。
• FTP ファイル転送プロトコル。
• SMTP シンプルメール転送プロトコル。
• SNMP 簡易ネットワーク管理プロトコル。
他にも多くのアプリケーションがあり、その一部については後の章で説明します。イーサネットなどのローカル エリア ネットワーク (LAN) に 2 つのホストがあり、どちらも FTP プロトコルを実行しているとします。図 1-2 に、このプロセスに関係するすべてのプロトコルを示します。
ここでは、FTP クライアント プログラムと別の FTP サーバー プログラムをリストします。ほとんどのネットワーク アプリケーションはクライアント/サーバー モデルで設計されています。サーバーはクライアントに何らかのサービスを提供します。この場合は、サーバーが配置されているホスト マシン上のファイルにアクセスします。リモート ログイン アプリケーション Telnet では、顧客に提供されるサービスはサーバー ホストへのログインです。同じ層上で、双方は通信用に 1 つ以上の対応するプロトコルを持っています。たとえば、あるプロトコルでは TCP 層の通信が可能ですが、別のプロトコルでは 2 つの IP 層の通信が可能です。図 1-2 の右側では、アプリケーションは通常ユーザー プロセスであるのに対し、下位の 3 つの層は通常 (オペレーティング システム) カーネルで実行されることがわかります。これは必須ではありませんが、UNIX オペレーティング システムなどでは通常この方法で処理されます。図 1-2 では、最上層と 3 つの下位層の間にはもう 1 つの重要な違いがあります。アプリケーション層は、ネットワークを介したデータの送信ではなく、アプリケーションの詳細に関係します。下位の 3 つの層はアプリケーションについては何も知りませんが、通信の詳細はすべて処理します。
異なるレベルの 4 つのプロトコルを図 1-2 に示します。FTP はアプリケーション層プロトコル、TCP はトランスポート層プロトコル、IP はネットワーク層プロトコル、イーサネット プロトコルはリンク層で使用されます。TCP/IP プロトコル スイートは、さまざまなプロトコルのグループで構成されるプロトコル スイートです。このプロトコル スイートは TCP/IP と呼ばれることが多いですが、TCP と IP はプロトコルの 2 つにすぎません (このプロトコル スイートの別名はインターネット プロトコル スイートです)。
ネットワーク インターフェイス層とアプリケーション層の目的は明らかです。前者は通信媒体 (イーサネット、トークン リングなど) の詳細を処理し、後者は特定のユーザー アプリケーション (FTP、Telnet など) を処理します。ただし、表面上、ネットワーク層とトランスポート層の違いはそれほど明確ではありません。なぜ 2 つの異なるレベルに分けるのでしょうか? これを理解するには、単一のネットワークから一連のネットワークまで視野を広げる必要があります。
1980 年代、インターネットが成長した理由の 1 つは、孤立した 1 台のコンピューターだけで構成される「アイランド」にはあまり意味がないことに誰もが気づき、これらの孤立したシステムがグループ化されてネットワークを形成したことでした。この発展に伴い、1990 年代までに、単一のネットワークで構成されるこの新しくて大きな「島」もあまり意味がないことに徐々に気づきました。その結果、人々は複数のネットワークを接続して、インターネットと呼ばれるネットワークのネットワークを形成しました。インターネットは、同じプロトコル スイートを通じて相互接続されたネットワークのグループです。
インターネットを構築する最も簡単な方法は、ルーターを介して 2 つ以上のネットワークを接続することです。ネットワーク相互接続に使用する特殊なハードウェアボックスです。ルーターの利点は、さまざまな種類の物理ネットワーク (イーサネット、トークン リング、ポイントツーポイント リンク、FDDI (ファイバー分散データ インターフェイス) など) への接続を提供できることです。
这些盒子也称作IP路由器（IP Router），但我们这里使用路由器(Router)这个术语。
从历史上说，这些盒子称作网关（gateway），在很多TCP/IP文献中都使用这个术语。
现在网关这个术语只用来表示应用层网关：
一个连接两种不同协议族的进程（例如，TCP/IP和IBM的SNA），它为某个特定的应用程序服务（常常是电子邮件或文件传输）。
図 1-3 は、ルータを介して相互に接続された 2 つのネットワーク (イーサネットとトークン リング) で構成されるインターネットワークです。2 つのホストがルータを介して通信していますが、イーサネット ネットワーク上の任意のホストがトークン リング ネットワーク上の任意のホストと通信できます。図 1-3 では、エンド システム (両側の 2 台のホスト) と中間システム (中央のルータ) に分けることができます。アプリケーション層とトランスポート層はエンドツーエンドのプロトコルを使用します。この図では、エンド システムのみがこれら 2 つのプロトコル層を必要とします。ただし、ネットワーク層は、エンド システムとすべての中間システムの両方で使用されるホップバイホップ プロトコルを提供します。
TCP/IP プロトコル スイートでは、ネットワーク層 IP が信頼性の低いサービスを提供します。言い換えれば、パケットを送信元ノードから宛先ノードにできるだけ早く送信するだけで、信頼性の保証はありません。一方、TCP は、信頼性の低い IP 層の上に信頼性の高いトランスポート層を提供します。この信頼性の高いサービスを提供するために、TCP はタイムアウト再送信、エンドツーエンドの確認パケットの送受信などのメカニズムを使用します。トランスポート層とネットワーク層が異なる機能を担当していることがわかります。
定義上、ルーターには 2 つ以上のネットワーク インターフェイス層があります (2 つ以上のネットワークを接続するため)。複数のインターフェイスを備えたシステムは、英語ではマルチホームと呼ばれます。ホストは複数のインターフェイスを持つこともできますが、その機能が単に 1 つのインターフェイスから別のインターフェイスにパケットを送信することである場合を除き、通常はルーターとは呼ばれません。同様に、ルーターは、インターネット上でパケットを転送するために使用される特別なハードウェア ボックスを必ずしも指すわけではありません。ほとんどの TCP/IP 実装では、マルチインターフェイス ホストがルーターとして機能することもできますが、そのためにはホストを特別に構成する必要があります。この場合、システムをホスト (FTP や Telnet などのアプリケーションを実行している場合) またはルーター (あるネットワークから別のネットワークにパケットを転送する場合) と呼ぶことができます。さまざまな状況でさまざまな用語が使用されます。
インターネットの目的の 1 つは、アプリケーションからすべての物理的な詳細を隠すことです。これは、図 1-3 の 2 ネットワーク インターネットではすぐには明らかではありませんが、アプリケーション層は、1 つのホストがイーサネット ネットワーク上にあり、別のホストがトークン リング ネットワーク上にあることを気にすることはできません (また、気にしません)。ルーターを介して相互接続されています。さまざまなタイプの物理ネットワークが追加されると、ルーターが 20 台になる場合がありますが、アプリケーション層は同じままです。物理的な詳細を隠すことで、インターネットは非常に強力で便利になります。
ネットワークに接続するもう 1 つの方法は、ブリッジを使用することです。ブリッジはリンク層でネットワークを相互接続し、ルーターはネットワーク層でネットワークを相互接続します。ブリッジを使用すると、複数のローカル エリア ネットワーク (LAN) をグループ化して、上位層からは 1 つの LAN として認識できるようになります。TCP/IP はネットワークを接続するのにブリッジではなくルーターを優先するため、ここではルーターに焦点を当てます。[Perlman 1992] の第 12 章では、ルーターとブリッジを比較しています。
1.3 TCP/IP レイヤ化
TCP/IP プロトコル スイートには、多数のプロトコルがあります。図 1-4 は、本書で説明されている他のプロトコルを示しています。
TCP と UDP は 2 つの最も有名なトランスポート層プロトコルであり、どちらもネットワーク層プロトコルとして IP を使用します。TCP は信頼性の低い IP サービスを使用しますが、信頼性の高いトランスポート層サービスを提供します。本書の第 17 章から第 22 章では、TCP の内部動作の詳細について詳しく説明します。次に、第 26 章では Telnet と Rlogin、第 27 章では FTP、第 28 章では SMTP などの TCP アプリケーションをいくつか紹介します。これらのアプリケーションは通常、ユーザー プロセスです。
UDP はアプリケーションのデータグラムを送受信します。データグラムとは、送信者から受信者に送信される情報の単位 (たとえば、送信者が指定した特定のバイト数の情報) を指します。ただし、TCP とは異なり、UDP は信頼性が低く、データグラムがエラーなく安全に最終宛先に到達できることを保証できません。この本では、第 11 章で UDP について説明し、第 14 章 (DNS: ドメイン ネーム システム)、第 15 章 (TFTP: トリビアル ファイル転送プロトコル)、および第 16 章 (BOOTP: ブートストラップ プロトコル) で UDP を使用するアプリケーションを紹介します。SNMP も UDP プロトコルを使用しますが、他の多くのプロトコルを処理する必要があるため、本書ではその説明を第 25 章に取っておきます。
IP はネットワーク層の主要なプロトコルであり、TCP と UDP の両方で使用されます。TCP および UDP からのすべてのデータ セットは、エンド システムの IP 層およびすべての中間ルーターを介してインターネット上を移動します。図 1-4 に、IP に直接アクセスするアプリケーションを示します。これはまれですが、可能です (一部の古いルーティング プロトコルはこの方法で実装されていました。新しいトランスポート層プロトコルもこのアプローチを使用する可能性があります)。第 3 章では主に IP プロトコルについて説明しますが、内容をより的を絞ったものにするために、いくつかの詳細については後の章で説明します。第 9 章と第 10 章では、IP ルーティングがどのように実行されるかについて説明します。
ICMP は IP プロトコルの補助プロトコルです。IP 層はこれを使用して、エラー メッセージやその他の重要な情報を他のホストまたはルーターと交換します。第 6 章では、ICMP に関連する詳細について説明します。ICMP は主に IP によって使用されますが、アプリケーションが ICMP にアクセスすることも可能です。どちらも ICMP を使用する、2 つの一般的な診断ツールである Ping と Traceroute を分析します (第 7 章と第 8 章)。
IGMP はインターネット グループ管理プロトコルです。UDP データグラムを複数のホストにマルチキャストするために使用されます。第 12 章ではブロードキャスト (特定のネットワーク上のすべてのホストに UDP データグラムを送信する) とマルチキャストの一般的な特性について説明し、第 13 章では IGMP プロトコル自体について説明します。
ARP (アドレス解決プロトコル) および RARP (リバース アドレス解決プロトコル) は、一部のネットワーク インターフェイス (イーサネットやトークン リングなど) で、IP 層とネットワーク インターフェイス層で使用されるアドレスを変換するために使用される特別なプロトコルです。これら 2 つのプロトコルについては、それぞれ第 4 章と第 5 章で分析して紹介します。
1.4 インターネットアドレス
インターネット上のすべてのインターフェイスには、一意のインターネット アドレス (IP アドレスとも呼ばれます) が必要です。IP アドレスの長さは 32 ビットです。インターネット アドレスは、1、2、3 などのフラット アドレス空間を使用しません。IP アドレスには特定の構造があり、5 種類のインターネット アドレス形式を図 1-5 に示します。
これらの 32 ビット アドレスは通常、4 つの 10 進数として書かれ、各整数が 1 バイトに対応します。この表現方法を「ドット10進表記」といいます。たとえば、作成者のシステムはクラス B アドレスであり、140.252.13.33 として表されます。さまざまなタイプのアドレスを区別する最も簡単な方法は、最初の 10 進整数を調べることです。図 1-6 は、さまざまなアドレスの開始範囲と終了範囲をリストしたもので、最初の 10 進整数が太字で示されています。マルチインターフェイス ホストには、各インターフェイスに 1 つずつ、複数の IP アドレスがあることを再度指摘します。
インターネット上の各インターフェースには固有の IP アドレスが必要なため、管理機関はインターネットに接続されたネットワークに IP アドレスを割り当てる必要があります。この管理組織は、InterNIC と呼ばれるインターネット ネットワーク インフォメーション センター (Internet Network Information Center) です。InterNIC はネットワーク番号のみを割り当てます。ホスト番号の割り当てはシステム管理者の責任です。
Internet注册服务(IP地址和DNS域名)过去由NIC来负责，其网络地址是nic.ddn.mil。1993年4月1日，InterNIC成立。现在，NIC只负责处理国防数据网的注册请求，
所有其他的Internet用户注册请求均由InterNIC负责处理，其网址是：rs.internic.net。
事实上InterNIC由三部分组成：注册服务（rs.internic.net），目录和数据库服务（ds.internic.net），以及信息服务（is.internic.net）。
有关InterNIC的其他信息参见习题1.8。
IP アドレスには、ユニキャスト アドレス (単一のホストへの宛先)、ブロードキャスト アドレス (特定のネットワーク上のすべてのホストへの宛先)、およびマルチキャスト アドレス (同じグループ内のすべてのホストへの宛先) の 3 種類があります。第 12 章と第 13 章では、それぞれブロードキャストとマルチキャストについて詳しく説明します。セクション 3.4 では、IP ルーティングを導入した後、サブネットの概念をさらに紹介します。図 3-9 は、いくつかの特別な IP アドレスを示しています。ホスト番号とネットワーク番号はすべて 0 またはすべて 1 です。
1.5 ドメインネームシステム
ホスト上のネットワーク インターフェイスは IP アドレスによって識別でき、ホストにアクセスできますが、最も一般的なのはホスト名です。TCP/IP の世界では、ドメイン ネーム システム (DNS) は、IP アドレスとホスト名の間のマッピング情報を提供する分散データベースです。DNS については第 14 章で詳しく説明します。ここで、どのアプリケーションでも標準ライブラリ関数を呼び出して、指定された名前のホストの IP アドレスを確認できることを理解する必要があります。同様に、システムは逆の機能も提供します。つまり、ホストの IP アドレスを指定して、対応するホスト名を確認します。
ホスト名をパラメータとして受け取るほとんどのアプリケーションは、IP アドレスもパラメータとして受け取ることができます。たとえば、第 4 章では、Telnet を使用してリモートにログインするときに、ホスト名または IP アドレスのいずれかを指定できます。
1.6 梱包
アプリケーションが TCP を使用してデータを送信する場合、データはプロトコル スタックに入力され、ビット ストリームとしてネットワークに送信されるまで各層を通過します。各層は、受信データにヘッダー情報 (場合によっては末尾情報) を追加します (図 1-7 にそのプロセスを示します)。TCP によって IP に送信されるデータ単位は、TCP セグメントまたは単に TCP セグメントと呼ばれます。IP によってネットワーク インターフェイス層に送信されるデータ ユニットは、IP データグラムと呼ばれます。イーサネットを通じて伝送されるビットストリームはフレームと呼ばれます。図 1-7 のフレーム ヘッダーとフレーム トレーラーの下にマークされている数字は、一般的なイーサネット フレーム ヘッダーのバイト長です。次の章では、これらのフレーム ヘッダーの具体的な意味について詳しく説明します。
イーサネット データ フレームの物理的特性は、その長さが 46 ～ 1500 バイトでなければならないことです。最小長のデータ フレームについてはセクション 4.5 で、最大長のデータ フレームについてはセクション 2.8 で説明します。
所有的Internet标准和大多数有关TCP/IP的书都使用octet这个术语来表示字节。
使用这个过分雕琢的术语是有历史原因的，因为TCP/IP的很多工作都是在DEC-10系统上进行的，但是它并不使用8bit的字节。
由于现在几乎所有的计算机系统都采用8bit的字节，因此我们在本书中使用字节（byte）这个术语。
更准确地说，图1-7中IP和网络接口层之间传送的数据单元应该是分组（packet）。
分组既可以是一个IP数据报，也可以是IP数据报的一个片（fragment）。我们将在11.5节讨论IP数据报分片的详细情况。
UDP データは基本的に TCP データと同じです。唯一の違いは、UDP によって IP に送信される情報単位が UDP データグラム (UDP データグラム) と呼ばれ、UDP ヘッダーの長さが 8 バイトであることです。セクション 1.3 の図 1-4 を思い出してください。TCP、UDP、ICMP、および IGMP はすべてデータを IP に送信するため、IP はデータがどの層に属するかを示すために、生成された IP ヘッダーに何らかの識別子を追加する必要があります。この目的のために、IP はプロトコル フィールドと呼ばれるヘッダーに 8 ビットの値を格納します。1 は ICMP プロトコル、2 は IGMP プロトコル、6 は TCP プロトコル、17 は UDP プロトコルを表します。
同様に、多くのアプリケーションは TCP または UDP を使用してデータを転送できます。トランスポート層プロトコルは、メッセージの生成時にヘッダーにアプリケーション識別子を格納します。TCP と UDP はどちらも 16 ビットのポート番号を使用して、さまざまなアプリケーションを表します。TCP と UDP は、それぞれ送信元ポート番号と宛先ポート番号をメッセージ ヘッダーに格納します。ネットワーク インターフェイスは、IP、ARP、RARP データをそれぞれ送受信するため、データを生成したネットワーク層プロトコルを示すために、何らかの形式の識別をイーサネット フレーム ヘッダーに追加する必要があります。このため、イーサネット フレーム ヘッダーには 16 ビットのフレーム タイプ フィールドもあります。
1.7点
宛先ホストがイーサネット データ フレームを受信すると、データはプロトコル スタック内で下から上に上昇し始め、同時にプロトコルの各層によって追加されたメッセージ ヘッダーが削除されます。プロトコル ボックスの各層は、メッセージ ヘッダー内のプロトコル識別子をチェックして、データを受信するための上位層プロトコルを決定する必要があります。このプロセスは逆多重化と呼ばれ、図 1-8 はそれがどのように行われるかを示しています。
为协议ICMP和IGMP定位一直是一件很棘手的事情。在图1-4中，把它们与IP放在同一层上，那是因为事实上它们是IP的附属协议。
但是在这里，我们又把它们放在IP层的上面，这是因为ICMP和IGMP报文都被封装在IP数据报中。
对于ARP和RARP，我们也遇到类似的难题。
在这里把它们放在以太网设备驱动程序的上方，这是因为它们和IP数据报一样，都有各自的以太网数据帧类型。
但在图2-4中，我们又把ARP作为以太网设备驱动程序的一部分，放在IP层的下面，其原因在逻辑上是合理的。
这些分层协议盒并不都是完美的。
TCP の詳細をさらに説明すると、プロトコルが宛先ポート番号、送信元 IP アドレス、および送信元ポート番号によって実際に解凍されることがわかります。
1.8 クライアントサーバーモデル
ほとんどのネットワーク アプリケーションは、サーバーがクライアントに特定のサービスを提供することを目的として、一方の端がクライアント、もう一方の端がサーバーであることを想定して作成されています。このタイプのサービスは、定期的サービスと並行サービスの 2 つのタイプに分類できます。反復サーバーは次の手順で対話します:
I1. クライアント要求が到着するのを待ちます。
I2. 顧客のリクエストを処理します。
I3. リクエストを送信したクライアントにレスポンスを送信します。
I4. ステップ I1 に戻ります。
重複サーバーに関する主な問題は、I2 状態で発生します。現時点では、他のクライアントにサービスを提供できません。したがって、並行サーバーは次の手順を実行します:
C1. クライアント要求の到着を待ちます。
C2. この顧客のリクエストを処理するために新しいサーバーを起動します。この期間中に、基礎となるオペレーティング システムのサポートに応じて、新しいプロセス、タスク、またはスレッドが生成されることがあります。この手順がどのように実行されるかは、オペレーティング システムによって異なります。生成された新しいサーバーは、顧客からのすべてのリクエストを処理します。処理が完了したら、新しいサーバーを終了します。
C3. ステップ C1 に戻ります。並行サーバーの利点は、他のサーバーを生成してクライアント要求を処理する方法を使用することです。つまり、各クライアントには独自の対応するサーバーがあります。オペレーティング システムでマルチタスクが許可されている場合は、複数の顧客に同時にサービスを提供できます。クライアントではなくサーバーを分類する理由は、通常、クライアントが中継サーバーと通信しているのか、それとも並行サーバーと通信しているのかを区別できないためです。一般に、TCP サーバーは並行し、UDP サーバーは二重化されますが、いくつかの例外があります。UDP のサーバーへの影響についてはセクション 11.12 で、TCP のサーバーへの影響についてはセクション 18.11 で詳しく説明します。
1.9 ポート番号
前に指摘したように、TCP と UDP はアプリケーションを識別するために 16 ビットのポート番号を使用します。では、これらのポート番号はどのように選択されるのでしょうか? サーバーは通常、既知のポート番号によって識別されます。たとえば、すべての TCP/IP 実装では、すべての FTP サーバーの TCP ポート番号は 21、すべての Telnet サーバーの TCP ポート番号は 23、すべての TFTP (Trivial File Transfer Protocol) サーバーの UDP ポート番号は 69 です。TCP/IP 実装によって提供されるサービスは、1 ～ 1023 の既知のポート番号を使用します。これらの既知のポート番号は、Internet Assigned Numbers Authority (IANA) によって管理されています。
到1992年为止，知名端口号介于1～255之间。
256～1023之间的端口号通常都是由Unix系统占用，以提供一些特定的Unix服务—也就是说，提供一些只有Unix系统才有的、而其他操作系统可能不提供的服务。
现在IANA管理1～1023之间所有的端口号。
Internet扩展服务与Unix特定服务之间的一个差别就是Telnet和Rlogin。
它们二者都允许通过计算机网络登录到其他主机上。
Telnet是采用端口号为23的TCP/IP标准且几乎可以在所有操作系统上进行实现。
相反，Rlogin最开始时只是为Unix系统设计的（尽管许多非Unix系统现在也提供该服务），因此在80年代初，它的有名端口号为513。
ポート番号がマシン上で一意である限り、クライアントは通常、使用するポート番号を気にしません。クライアント ポート番号は、一時ポート番号 (つまり、短期間存在する) とも呼ばれます。これは、通常、ホストがオンになっている限りサーバーのサービスが実行されるのに対し、ユーザーがクライアント プログラムを実行するときにのみ存在するためです。ほとんどの TCP/IP 実装では、1024 ～ 5000 のポート番号が一時ポートに割り当てられます。5000 を超えるポート番号は、他のサーバー (インターネット上で一般的に使用されないサービス) 用に予約されています。一時ポートにポート番号を割り当てるこのような例は、後ほどたくさん見ることができます。
Solaris 2.2是一个很有名的例外。通常TCP和UDP的缺省临时端口号从32768开始。
セクション E.4 では、システム管理者が構成オプションを変更してこれらのデフォルトを変更する方法について詳しく説明します。ほとんどの Unix システム上のファイル /etc/services には、既知のポート番号が含まれています。Telnet サーバーとドメイン ネーム システムのポート番号を見つけるには、次のステートメントを実行できます。
Unix システムには予約済みポート番号の概念があります。スーパーユーザー権限を持つプロセスのみが、予約されたポート番号を自分自身に割り当てることができます。これらのポート番号の範囲は 1 ～ 1023 で、一部のアプリケーション (有名な Rlogin、セクション 26.2 など) はクライアントとサーバー間の認証の一部としてそれらを使用します。
1.10 標準化プロセス
実際に TCP/IP プロトコル スイートを管理しているのは誰ですか?また、新しい標準やその他の類似のものを定義しているのは誰ですか? 実際、インターネット技術を担当するグループは 4 つあります。
1. Internet Society (ISOC、Internet Society) は、インターネットの継続的な成長と発展を促進、支援、促進する専門組織であり、インターネットを世界的な研究コミュニケーションのインフラストラクチャとみなしています。
2. Internet Architecture Board (IAB、インターネット アーキテクチャ委員会) は、技術的な監督および調整を行う組織です。さまざまな専門分野の 15 人の国際ボランティアで構成されており、その役割はインターネット標準の最終編集と技術レビューを担当することです。IAB は ISOC と提携しています。
3. Internet Engineering Task Force (IETF、インターネット エンジニアリング タスク フォース) は、最新の標準を指向した組織であり、9 つの分野 (アプリケーション、ルーティングとアドレス指定、セキュリティなど) に分かれています。IETF は、インターネット標準となる仕様を開発します。IETF 会長を支援するために、Internet Engineering Steering Group (IESG) が設立されました。
4. インターネット調査タスクフォース (IRIF、インターネット調査タスクフォース) は、主に長期プロジェクトに関する調査を実施します。IRTF と IETF は両方とも IAB に加盟しています。[Crocker 1993] は、インターネット内の標準化プロセスに関するより詳細な情報を提供し、その初期の歴史についても説明しています。
1.11 RFC
インターネット上のすべての正式な標準は、RFC (Request for Comment) 文書で公開されています。さらに、多くの RFC は正式な標準ではなく、情報提供のみを目的として公開されています。RFC の長さは 1 ～ 200 ページです。各項目は、RFC 1122 などの番号で識別されます。番号が大きいほど、RFC の内容が新しくなります。すべての RFC は、電子メールまたは FTP 経由でインターネット上で自由に入手できます。次の電子メールを送信すると、RFC を入手する方法のリストが届きます。
最新の RFC インデックスは常に情報検索の開始点となります。この索引には、RFC が置き換えられたか、部分的に更新された時期がリストされます。以下にいくつかの重要な RFC 文書を示します。
1. Assigned Numbers RFC (Assigned Numbers RFC) には、すべてのインターネット プロトコルで使用される番号と定数がリストされています。この出版物の時点で、最新の RFC 番号は 1340 [Reynolds and Postel 1992] です。有名なインターネット ポート番号がすべてここにリストされています。この RFC が更新されると (通常は少なくとも年に 1 回)、索引リストには RFC 1340 が置き換えられた時期がリストされます。
2. インターネットの正式なプロトコル標準。現在は RFC 1600 [Postel 1994]。この RFC は、さまざまなインターネット プロトコルの標準化の現状について説明します。各プロトコルは、標準、標準草案、標準提案、実験標準、情報標準、および歴史的標準といういくつかの標準化状態のいずれかにあります。さらに、各プロトコルには、必須、推奨、オプション、使用制限、非推奨といった要件のレベルがあります。割り当てられた RFC と同様に、この RFC も定期的に更新されます。ぜひ最新版をご確認ください。
3. ホスト要件 RFC、1122 および 1123 [Braden 1989a、1989b]。RFC 1122 はリンク層、ネットワーク層、トランスポート層を対象とし、RFC 1123 はアプリケーション層を対象としています。これら 2 つの RFC は、以前の重要な RFC 文書に多数の修正と説明を提供します。多くの場合、プロトコルの詳細を確認したい場合のエントリ ポイントになります。これらには、「しなければならない」、「すべきである」、「してもよい」、「すべきではない」、または「してはならない」プロトコルの機能とその実装の詳細がリストされています。文献 [Borman 1993b] は、これら 2 つの RFC に関する有用な情報を提供します。RFC 1127 [Braden 1989c] は、ホスト要件 RFC の開発中の作業グループの議論と結論の非公式の概要を提供します。
4. ルーター要件 RFC、現在の公式バージョンは RFC 1009 [Braden and Postel 1987] ですが、新しいバージョンはほぼ完成しています [Almquist 1993]。これはホスト要件 RFC に似ていますが、ルータ要件のみを個別に説明しています。
1.12 標準簡易サービス
ほぼすべての実装が提供する標準的な単純なサービスがいくつかあります。本書では、これらのサービス プログラムのいくつかを使用しますが、クライアント プログラムは通常 Telnet を選択します。図 1-9 では、これらのサービスについて説明します。図からわかるように、TCP と UDP を使用して同じサービスを提供する場合、通常は同じポート番号が選択されます。
如果仔细检查这些标准的简单服务以及其他标准的TCP/IP服务（如Telnet、FTP、SMTP等）的端口号时，我们发现它们都是奇数。
这是有历史原因的，因为这些端口号都是从NCP端口号派生出来的（NCP，即网络控制协议，是ARPANET的运输层协议，是TCP的前身）。
NCP是单工的，不是全双工的，因此每个应用程序需要两个连接，需预留一对奇数和偶数端口号。
当TCP和UDP成为标准的运输层协议时，每个应用程序只需要一个端口号，因此就使用了NCP中的奇数。
1.13 インターネット
図 1-3 では、イーサネットとトークン リングという 2 つのネットワークで構成されるインターネットを示しています。セクション 1.4 と 1.9 では、世界規模のインターネット (インターネット) と IP アドレスの集中割り当て (InterNIC) の必要性について説明し、ウェルノウン ポート番号 (IANA) についても説明しました。「インターネット」という単語の最初の文字が大文字かどうかによって、意味が異なるかどうかが決まります。インターネットとは、共通のプロトコル スイートを使用して複数のネットワークを接続することを意味します。インターネットとは、TCP/IP を介して相互に通信する世界中のすべてのホスト (100 万以上) の集合を指します。インターネットはインターネットですが、インターネットとインターネットは同じではありません。
1.14 実装
事実上の標準の TCP/IP ソフトウェア実装は、カリフォルニア大学バークレー校のコンピューター システム研究グループによって提供されています。歴史的に、ソフトウェアは 4.x BSD システム (Berkeley Software Distribution) のネットワーク バージョンでリリースされました。そのソース コードは、他の多くの実装の基礎となります。図 1-10 に、さまざまな BSD バージョンのリリース日をリストし、重要な TCP/IP 機能を示します。左側にリストされている BSD ネットワーク バージョンの場合、プロトコル自体や多くのアプリケーションやツール (Telnet や FTP など) を含むすべてのネットワーク ソース コードが公開されています。
本書では、Berkeley ソース コードに基づいて開発された SunOS 4.x、SVR4、AIX 3.2 などのシステムを指すために「Berkeley 派生システム」を使用します。これらのシステムには多くの共通点があり、多くの場合、同じバグが含まれています。新しい輻輳制御アルゴリズム (セクション 21.7)、マルチキャスト (セクション 12.4)、「ロング ファット パイプ」の修正 (セクション 24.3)、およびその他の同様の研究など、インターネットに関するオリジナルの研究の多くは依然としてバークレー システムに適用されています。
1.15 アプリケーションプログラミングインターフェース
TCP/IP プロトコルを使用するアプリケーションは通常、ソケットと TLI (トランスポート層インターフェイス: Transport Layer Interface) という 2 つのアプリケーション プログラミング インターフェイス (API) を使用します。前者は、Berkeley バージョンから開発されたことを示す「Berkeley ソケット」と呼ばれることもあります。後者は元々 AT&T によって開発されたもので、独自の標準を定義する国際的なコンピュータ メーカーである X/Open による取り組みを認めて、XTI (X/Open Transport Layer Interface) と呼ばれることもあります。XTI は実際には TLI のスーパーセットです。この本はプログラミングの本ではありませんが、ほとんどの API (ソケット) が TCP/IP 機能を提供しているかどうかに関係なく、TCP/IP 機能を説明するための参照が時折登場します。ソケットと TLI に関するプログラミングの詳細はすべて [Stevens 1990] に記載されています。
1.16 テストネットワーク
図 1-11 は、本書のすべての例が実行されるテスト ネットワークです。読むときに簡単に参照できるように、この図はこの本のタイトル ページの前の挿入物にも再現されています。
この図 (作成者のサブネット) では、ほとんどの例が次の 4 つのシステム上で実行されます。図内のすべての IP アドレスはクラス B アドレスに属し、ネットワーク番号は 140.252 です。すべてのホスト名はドメイン .tuc.noao.edu に属します (noao は National Optical Astronomy Observatories の略、tuc は Tu cson の略です)。たとえば、右下のシステムの完全な名前は svr4.tuc.noao.edu で、その IP アドレスは 140.252.13.34 です。各ボックスの上にある名前は、ホストが実行しているオペレーティング システムです。このグループのシステム、ネットワーク上のホスト、ルーターは、さまざまな TCP/IP 実装を実行します。
noao.edu ドメインには、図 1-11 よりもはるかに多くのネットワークとホストがあることに注意してください。ここにリストされているのは、本書で使用されるシステムのみです。セクション 3.4 では、このネットワークで使用されるサブネットの形式について説明します。セクション 4.6 では、sun と netb の間のダイヤルアップ SLIP の関連詳細を紹介します。セクション 2.4 で SLIP について詳しく説明します。
1.17 概要
この章では、TCP/IP プロトコル スイートの概要を説明し、後の章で詳しく説明する用語やプロトコルの多くを紹介します。TCP/IP プロトコル スイートは、リンク層、ネットワーク層、トランスポート層、アプリケーション層の 4 つの層に分かれており、各層は異なる役割を担っています。TCP/IP では、ネットワーク層とトランスポート層の区別が最も重要です。ネットワーク層 (IP) はポイントツーポイント サービスを提供し、トランスポート層 (TCP および UDP) はエンドツーエンド サービスを提供します。 。インターネットはネットワークのネットワークです。インターネットの一般的な構成要素はルーターであり、IP 層でネットワークを接続します。最初の大文字のインターネットは、世界中に分散された大規模なインターネットを指し、10,000 以上のネットワークと 100 万以上のホストが含まれます。インターネットでは、各インターフェイスは IP アドレスによって識別されますが、ユーザーは IP アドレスではなくホスト名を使用することに慣れています。ドメイン ネーム システムは、ホスト名と IP アドレス間の動的なマッピングを提供します。ポート番号は、相互に通信するアプリケーションを識別するために使用されます。サーバーは既知のポート番号を使用しますが、クライアントは一時的に設定されたポート番号を使用します。