Network Working Group                                           C. Kalt
Request for Comments: 2810                                   April 2000
Updates: 1459
Category: Informational

Internet Relay Chat: アーキテクチャ

IRC

  • RFC 1459 (Internet Relay Chat Protocol)
  • RFC 2810 (Internet Relay Chat: Architecture)
  • RFC 2811 (Internet Relay Chat: Channel Management)
  • RFC 2812 (Internet Relay Chat: Client Protocol)
  • RFC 2813 (Internet Relay Chat: Server Protocol)
  • RFC 7194 (Default Port for Internet Relay Chat (IRC) via TLS/SSL)

本メモの位置づけ

このメモは、インターネットコミュニティーのための情報を提供するものです。このメモは、いかなる種類のインターネット標準も規定するものではありません。このメモの配布は無制限です。

著作権について

Copyright (C) The Internet Society (2000). All Rights Reserved.

概要

IRC（Internet Relay Chat）プロトコルは、テキストベースの会議で使用するためのプロトコルです。1989年に BBS でユーザ同士がチャットをするために実装されて以来、発展してきました。

1993年5月に RFC 1459 [IRC] で初めて正式に文書化されたこのプロトコルは、進化を続けています。この文書は、現在の IRC プロトコルのアーキテクチャとその異なるコンポーネントの役割を説明する更新版です。他の文書では、ここで定義された様々なコンポーネント間で使用されるプロトコルを詳細に説明しています。

1. 序説

IRC（Internet Relay Chat）プロトコルは、テキストベースの会議で使用するために何年もかけて設計されています。 この文書では、その現在のアーキテクチャについて説明します。

IRC プロトコルはクライアント・サーバモデルをベースにしており、多くのマシン上で分散して動作させるのに適しています。 典型的なセットアップは、クライアント（または他のサーバ）が接続するための中心点を形成する単一のプロセス（サーバ）を含み、必要なメッセージ配信/多重化および他の機能を実行します。

各サーバーがグローバルな状態情報のコピーを持つ必要があるこの分散モデルは、ネットワークが到達できる最大規模を制限する重大なハンディキャップであり、今でもプロトコルの最も重大な問題点です。既存のネットワークが驚異的なスピードで成長し続けることができたとすれば、私たちはより強力なシステムを提供し続けてくれたハードウェアメーカーに感謝しなければなりません。

2. コンポーネント

以下の章では、IRC プロトコルの基本的な構成要素を定義しています。

2.1 サーバ

サーバは IRC のバックボーンを形成し、他のすべてのコンポーネントを一緒にリンクすることができるプロトコルの唯一のコンポーネントです：これはクライアントがお互いに話すために接続するポイント [IRC-CLIENT] と、他のサーバが接続するポイント [IRC-SERVER] を提供します。また、サーバーは、IRC プロトコルで定義された基本的なサービスを提供する役割を担っています。

2.2 クライアント

クライアントとは、他のサーバではないサーバに接続するものです。クライアントには2種類あり、それぞれ異なる目的を持ちます。

2.2.1 ユーザクライアント

ユーザクライアントは、一般に IRC を介して対話的に通信するために使用されるテキストベースのインタフェースを提供するプログラムです。この特定のタイプのクライアントは、しばしば "ユーザ" と呼ばれます。

2.2.2 サーバクライアント

サービスクライアントは、ユーザとは異なり、手動で使用したり、会話したりすることは意図されていません。サービスクライアントは、プロトコルのチャット機能により限定的にアクセスし、オプションでサーバからよりプライベートなデータにアクセスすることができます。

サービスとは、通常、何らかのサービス（必ずしも IRC そのものとは関係ない）をユーザに提供するために使用されるオートマトンです。例としては、IRC ネットワークに接続しているユーザの出身地に関する統計を収集するサービスがあります。

3. アーキテクチャ

IRC ネットワークは、互いに接続されたサーバのグループによって定義されます。単一のサーバは、最も単純な IRC ネットワークを形成します。

IRC サーバに許されるネットワーク構成は、各サーバがネットワークの残りの部分に対して中心ノードとして機能するスパニングツリーのものだけです。

    1--\
        A        D---4
    2--/ \      /
          B----C
         /      \
        3        E

 Servers: A, B, C, D, E Clients: 1, 2, 3, 4

 [ 図1. 小規模 IRC ネットワークの例 ]

IRC プロトコルは、2つのクライアントが直接通信する手段を提供しません。クライアント間のすべてのコミュニケーションはサーバによって中継されます。

4. IRC プロトコルサービス

ここでは、IRC プロトコルが提供するサービスについて説明します。これらのサービスを組み合わせることで、リアルタイムの会議が可能になります。

4.1 クライアントの位置

メッセージを交換するためには、2つのクライアントが互いの位置を特定できる必要があります。

サーバに接続すると、クライアントはラベルを使用して登録し、他のサーバやクライアントがそのクライアントの位置を知るために使用します。サーバは、使用されているすべてのラベルを追跡する責任があります。

4.2 メッセージの中継

IRC プロトコルは、2つのクライアントが直接通信する手段を提供しません。クライアント間のすべてのコミュニケーションはサーバによって中継されます。

4.3 チャネルのホスティングと管理

チャネルは、そのチャネルに宛てられたメッセージをすべて受信し、1人または複数のユーザからなる名前付きグループです。チャネルは、その名前と現在のメンバーによって特徴付けられ、また、そのメンバ（の一部）が操作できる一連のプロパティも持っています。

チャネルは、1つのメッセージを複数のクライアントに送信するための手段を提供します。サーバはチャネルをホストし、必要なメッセージの多重化を提供します。また、サーバはチャネルのメンバーを追跡することによって、チャネルを管理する責任があります。サーバの正確な役割については、"Internet Relay Chat: チャネル管理" [IRC-CHAN] に定義されています。

5. IRC コンセプト

このセクションでは、IRC プロトコルの構成の背後にある実際の概念と、異なるクラスのメッセージがどのように配信されるかを説明することに専念します。

5.1 1対1のコミュニケーション

サーバとサーバのトラフィックのほとんどは、サーバ同士が会話しているわけではないので、1対1の通信は通常クライアントによって行われます。クライアントが互いに会話する手段を提供するために、すべてのサーバは、任意のクライアントに到達するために、スパニングツリーに沿って正確に1方向にメッセージを送信できることが必要です。したがって、メッセージが配送される経路は、スパニングツリー上の任意の2点間の最短経路となります。

    1--\
        A        D---4
    2--/ \      /
          B----C
         /      \
        3        E

 Servers: A, B, C, D, E Clients: 1, 2, 3, 4

 [ 図1. 小規模 IRC ネットワークの例 ]

以下の例は、すべて上記の図1を参照しています。

例1：クライアント 1 と 2 間のメッセージは、サーバ A だけが見ることができ、サーバー A はそれをそのままクライアント 2 に送ります。

例2：クライアント 1 とクライアント 3 間のメッセージは、サーバ A と B、およびクライアント 3 が見ることができます。他のクライアントやサーバはそのメッセージを見ることができません。

例3：クライアント 2 と 4 間のメッセージは、サーバ A、B、C、D とクライアント 4 のみによって見られます。

5.2 1対多

IRC の主な目的は、簡単かつ効率的にコンファレンス（1対多の会話）を行うことができるフォーラムを提供することです。IRC はこれを実現するためにいくつかの手段を提供しており、それぞれが独自の目的をもっています。

5.2.1 1対チャネル

IRC では、チャネルはマルチキャストグループと同等の役割を持っています。その存在は動的で、チャネル上で行われる実際の会話は、与えられたチャネル上のユーザをサポートしているサーバにのみ送信されなければなりません。さらに、各サーバはすべての受信者に確実に届くようにオリジナルメッセージをファンする責任があるので、メッセージはすべてのローカルリンクに一度だけ送信されなければなりません。

    1--\
        A        D---4
    2--/ \      /
          B----C
         /      \
        3        E

 Servers: A, B, C, D, E Clients: 1, 2, 3, 4

 [ 図1. 小規模 IRC ネットワークの例 ]

以下の例は、すべて図1を参照しています。

例4：クライアントが1人いる任意のチャネル。そのチャネルへのメッセージはサーバに行き、それ以外の場所には行きません。

例5：2人のクライアントがチャネルにいる場合。すべてのメッセージは、チャネルの外にいる2つのクライアント間のプライベートメッセージであるかのように経路を通過します。

例6：クライアント 1、2、3 がチャネルにいる場合。チャネルへのすべてのメッセージは、すべてのクライアントと、それが単一のクライアントへのプライベートメッセージである場合、メッセージが通過しなければならないサーバにのみ送信されます。クライアント 1 がメッセージを送信すると、クライアント 2 に戻り、サーバ B を経由してクライアント 3 に届きます。

5.2.2 1対ホスト/サーバマスク

多くの関連ユーザにメッセージを送る仕組みを提供するために、ホストとサーバのマスクメッセージが用意されています。 これらのメッセージは，ホストやサーバの情報がマスクに一致するユーザに送信されます。メッセージは，チャネルと同じように，ユーザがいる場所にのみ送信されます．

5.2.3 1対リスト

1対多の会話で最も効率の悪いスタイルは、クライアントがターゲットの 'リスト'（クライアント、チャネル、マスク）と会話することです。これがどのように行われるかは、ほとんど自明です：クライアントはメッセージの配送先のリストを与え、サーバはそれを分割し、与えられた各配送先にメッセージの個別のコピーを送信します。

この場合、宛先リストが分割され、各経路で重複して送信されないことを確認せずにディスパッチが送信される可能性があるため、チャネルを使用する場合よりも効率的ではありません。

5.3 1 対全

1対全のメッセージはブロードキャストメッセージと呼ばれ、すべてのクライアントまたはサーバ、あるいはその両方に送信されます。ユーザとサーバからなる大規模なネットワークでは、1つのメッセージによって、希望するすべての宛先に到達するために、ネットワーク上で多くのトラフィックが送信されることになります。

メッセージのクラスによっては、各サーバが保持する状態情報がサーバ間で一貫性を持つように、すべてのサーバにブロードキャストする以外の選択肢はありません。

5.3.1 クライアント->クライアント

1つのメッセージから、他のすべてのクライアントにメッセージが送信されるようなメッセージのクラスは存在しません。

5.3.2 クライアント->サーバ

状態情報の変更をもたらすほとんどのコマンド（チャンネルメンバーシップ、チャンネルモード、ユーザステータスなど）は、デフォルトですべてのサーバに送信されなければならず、この配布はクライアントによって変更されないものとします。

5.3.3 サーバ->サーバ

サーバ間のほとんどのメッセージは、すべての "他の" サーバに配信されますが、これはユーザ、チャネル、サーバに影響を与えるメッセージにのみ必要です。これらは IRC で見られる基本的な項目なので、あるサーバから発信されたほぼすべてのメッセージは、接続されている他のすべてのサーバにブロードキャストされます。

6. 現在の問題点

このプロトコルには多くの認識された問題がありますが、このセクションではプロトコルのアーキテクチャに関する問題のみを取り上げます。

6.1 スケーラビリティ

このプロトコルは、大規模なアリーナで使用する場合、十分にスケールしないことが広く認識されています。主な問題は、すべてのサーバが他のすべてのサーバ、クライアント、チャネルについて知っており、それらに関する情報が変更されるとすぐに更新されるという要件から来るものです。

6.2 信頼性

IRC サーバに許されるネットワーク構成はスパニングツリーのみであるため、2つのサーバ間の各リンクは明らかに深刻な障害点となります。この問題は、"Internet Relay Chat: サーバプロトコル" [IRC-SERVER] で詳しく説明されています。

6.3 ネットワークの混雑状況

また、スケーラビリティや信頼性の問題、スパニングツリーアーキテクチャに関連する問題として、IRC のプロトコルやアーキテクチャはネットワークの輻輳に対して非常に脆弱であることが挙げられます。この問題は常態化しており、次世代では解決すべき問題です。輻輳と大量のトラフィックによって2つのサーバ間のリンクに障害が発生すると、この障害によってネットワークトラフィックが増大するだけでなく、2つのサーバの再接続（最終的には別の場所）にもトラフィックが発生します。

これらの問題の影響を最小限に抑えるため、状況を悪化させないよう、サーバが自動的に高速な再接続を試みないことが強く推奨されます。

6.4 プライバシ

サーバは他のエンティティに関するすべての情報を知る必要があるため、うまく拡張できないことに加え、プライバシーの問題も懸念されます。特にチャネルについては、ユーザがオンラインかどうかよりも、関連する情報の方がかなり明らかになるためです。

7. セキュリティへの配慮

6.4 プライバシーの章で述べたプライバシーの問題を除けば、セキュリティは本書とは無関係と考えられます。

8. 現在のサポートと可用性

Mailing lists for IRC related discussion:

  • General discussion: ircd-users@irc.org
  • Protocol development: ircd-dev@irc.org

Software implementations:

Newsgroup: alt.irc

9. 謝辞

この文書の一部は、IRC プロトコルを最初に正式に文書化した RFC 1459 [IRC] からコピーされたものです。また、多くのレビューとコメントから恩恵を受けています。 特に、以下の方々がこの文書に大きな貢献をされました。

Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa Ruokonen, Magnus Tjernstrom, Stefan Zehl.

10. 参考

[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[IRC] Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol", RFC 1459, May 1993.

[IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC 2812, April 2000.

[IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC 2813, April 2000.

[IRC-CHAN] Kalt, C., "Internet Relay Chat: Channel Management", RFC 2811, April 2000.