Network Working Group C. Kalt
Request for Comments: 2810 April 2000
Updates: 1459
Category: Informational
Network Working Group C. Kalt
Request for Comments: 2810 April 2000
Updates: 1459
Category: Informational
Internet Relay Chat: Architecture
Internet中继聊天：体系结构
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
The IRC (Internet Relay Chat) protocol is for use with text based conferencing. It has been developed since 1989 when it was originally implemented as a mean for users on a BBS to chat amongst themselves.
IRC（Internet中继聊天）协议用于基于文本的会议。它是从1989年开始开发的，当时它最初是作为用户在BBS上相互聊天的一种手段实现的。
First formally documented in May 1993 by RFC 1459 [IRC], the protocol has kept evolving. This document is an update describing the architecture of the current IRC protocol and the role of its different components. Other documents describe in detail the protocol used between the various components defined here.
该协议于1993年5月首次由RFC 1459[IRC]正式记录，并不断发展。本文档是一个更新，描述了当前IRC协议的体系结构及其不同组件的作用。其他文件详细描述了此处定义的各种组件之间使用的协议。
Table of Contents
目录
1. Introduction ............................................... 2
2. Components ................................................. 2
2.1 Servers ................................................ 2
2.2 Clients ................................................ 3
2.2.1 User Clients ...................................... 3
2.2.2 Service Clients ................................... 3
3. Architecture ............................................... 3
4. IRC Protocol Services ...................................... 4
4.1 Client Locator ......................................... 4
4.2 Message Relaying ....................................... 4
4.3 Channel Hosting And Management ......................... 4
5. IRC Concepts ............................................... 4
5.1 One-To-One Communication ............................... 5
5.2 One-To-Many ............................................ 5
5.2.1 To A Channel ...................................... 5
5.2.2 To A Host/Server Mask ............................. 6
1. Introduction ............................................... 2
2. Components ................................................. 2
2.1 Servers ................................................ 2
2.2 Clients ................................................ 3
2.2.1 User Clients ...................................... 3
2.2.2 Service Clients ................................... 3
3. Architecture ............................................... 3
4. IRC Protocol Services ...................................... 4
4.1 Client Locator ......................................... 4
4.2 Message Relaying ....................................... 4
4.3 Channel Hosting And Management ......................... 4
5. IRC Concepts ............................................... 4
5.1 One-To-One Communication ............................... 5
5.2 One-To-Many ............................................ 5
5.2.1 To A Channel ...................................... 5
5.2.2 To A Host/Server Mask ............................. 6
5.2.3 To A List ......................................... 6
5.3 One-To-All ............................................. 6
5.3.1 Client-to-Client .................................. 6
5.3.2 Client-to-Server .................................. 7
5.3.3 Server-to-Server .................................. 7
6. Current Problems ........................................... 7
6.1 Scalability ............................................ 7
6.2 Reliability ............................................ 7
6.3 Network Congestion ..................................... 7
6.4 Privacy ................................................ 8
7. Security Considerations .................................... 8
8. Current Support And Availability ........................... 8
9. Acknowledgements ........................................... 8
10. References ................................................ 8
11. Author's Address .......................................... 9
12. Full Copyright Statement .................................. 10
5.2.3 To A List ......................................... 6
5.3 One-To-All ............................................. 6
5.3.1 Client-to-Client .................................. 6
5.3.2 Client-to-Server .................................. 7
5.3.3 Server-to-Server .................................. 7
6. Current Problems ........................................... 7
6.1 Scalability ............................................ 7
6.2 Reliability ............................................ 7
6.3 Network Congestion ..................................... 7
6.4 Privacy ................................................ 8
7. Security Considerations .................................... 8
8. Current Support And Availability ........................... 8
9. Acknowledgements ........................................... 8
10. References ................................................ 8
11. Author's Address .......................................... 9
12. Full Copyright Statement .................................. 10
The IRC (Internet Relay Chat) protocol has been designed over a number of years for use with text based conferencing. This document describes its current architecture.
IRC（Internet中继聊天）协议经过多年的设计，可用于基于文本的会议。本文档描述了它当前的体系结构。
The IRC Protocol is based on the client-server model, and is well suited to running on many machines in a distributed fashion. A typical setup involves a single process (the server) forming a central point for clients (or other servers) to connect to, performing the required message delivery/multiplexing and other functions.
IRC协议基于客户机-服务器模型，非常适合以分布式方式在许多机器上运行。典型的设置涉及单个进程（服务器），形成客户端（或其他服务器）连接的中心点，执行所需的消息传递/多路复用和其他功能。
This distributed model, which requires each server to have a copy of the global state information, is still the most flagrant problem of the protocol as it is a serious handicap, which limits the maximum size a network can reach. If the existing networks have been able to keep growing at an incredible pace, we must thank hardware manufacturers for giving us ever more powerful systems.
这种分布式模型要求每台服务器都有一份全局状态信息，这仍然是协议中最明显的问题，因为它是一个严重的障碍，限制了网络可以达到的最大规模。如果现有网络能够以令人难以置信的速度持续增长，我们必须感谢硬件制造商为我们提供了更强大的系统。
The following paragraphs define the basic components of the IRC protocol.
以下段落定义了IRC协议的基本组件。
The server forms the backbone of IRC as it is the only component of the protocol which is able to link all the other components together: it provides a point to which clients may connect to talk to
服务器构成了IRC的主干，因为它是协议中唯一能够将所有其他组件链接在一起的组件：它提供了一个客户端可以连接到的通信点
each other [IRC-CLIENT], and a point for other servers to connect to [IRC-SERVER]. The server is also responsible for providing the basic services defined by the IRC protocol.
彼此[IRC-CLIENT]，以及其他服务器连接到[IRC-SERVER]的点。服务器还负责提供IRC协议定义的基本服务。
A client is anything connecting to a server that is not another server. There are two types of clients which both serve a different purpose.
客户机是连接到不是另一台服务器的服务器的任何东西。有两种类型的客户机，它们都有不同的用途。
User clients are generally programs providing a text based interface that is used to communicate interactively via IRC. This particular type of clients is often referred as "users".
用户客户端通常是提供基于文本的界面的程序，用于通过IRC进行交互通信。这种特殊类型的客户端通常被称为“用户”。
Unlike users, service clients are not intended to be used manually nor for talking. They have a more limited access to the chat functions of the protocol, while optionally having access to more private data from the servers.
与用户不同的是，服务客户端既不用于手动使用，也不用于通话。他们对协议聊天功能的访问更为有限，同时可以选择从服务器访问更多的私有数据。
Services are typically automatons used to provide some kind of service (not necessarily related to IRC itself) to users. An example is a service collecting statistics about the origin of users connected on the IRC network.
服务通常是用于向用户提供某种服务（不一定与IRC本身相关）的自动机。一个例子是收集有关IRC网络上连接的用户来源的统计信息的服务。
An IRC network is defined by a group of servers connected to each other. A single server forms the simplest IRC network.
IRC网络由一组相互连接的服务器定义。单个服务器构成了最简单的IRC网络。
The only network configuration allowed for IRC servers is that of a spanning tree where each server acts as a central node for the rest of the network it sees.
IRC服务器允许的唯一网络配置是生成树配置，其中每台服务器充当它所看到的网络其余部分的中心节点。
1--\
A D---4
2--/ \ /
B----C
/ \
3 E
1--\
A D---4
2--/ \ /
B----C
/ \
3 E
Servers: A, B, C, D, E Clients: 1, 2, 3, 4
服务器：A、B、C、D、E客户端：1、2、3、4
[ Fig. 1. Sample small IRC network ]
[图1.小型IRC网络示例]
The IRC protocol provides no mean for two clients to directly communicate. All communication between clients is relayed by the server(s).
IRC协议不允许两个客户端直接通信。客户端之间的所有通信都由服务器中继。
This section describes the services offered by the IRC protocol. The combination of these services allow real-time conferencing.
本节介绍IRC协议提供的服务。这些服务的组合允许实时会议。
To be able to exchange messages, two clients must be able to locate each other.
为了能够交换消息，两个客户端必须能够相互定位。
Upon connecting to a server, a client registers using a label which is then used by other servers and clients to know where the client is located. Servers are responsible for keeping track of all the labels being used.
连接到服务器后，客户机使用标签进行注册，然后其他服务器和客户机使用该标签了解客户机的位置。服务器负责跟踪所使用的所有标签。
The IRC protocol provides no mean for two clients to directly communicate. All communication between clients is relayed by the server(s).
IRC协议不允许两个客户端直接通信。客户端之间的所有通信都由服务器中继。
A channel is a named group of one or more users which will all receive messages addressed to that channel. A channel is characterized by its name and current members, it also has a set of properties which can be manipulated by (some of) its members.
通道是一个由一个或多个用户组成的命名组，所有用户都将接收发往该通道的消息。通道以其名称和当前成员为特征，它还具有一组可由（某些）其成员操纵的属性。
Channels provide a mean for a message to be sent to several clients. Servers host channels, providing the necessary message multiplexing. Servers are also responsible for managing channels by keeping track of the channel members. The exact role of servers is defined in "Internet Relay Chat: Channel Management" [IRC-CHAN].
通道提供了将消息发送到多个客户端的方法。服务器承载通道，提供必要的消息多路复用。服务器还负责通过跟踪通道成员来管理通道。服务器的确切角色在“Internet中继聊天：频道管理”[IRC-CHAN]中定义。
This section is devoted to describing the actual concepts behind the organization of the IRC protocol and how different classes of messages are delivered.
本节专门描述IRC协议组织背后的实际概念，以及不同类别的消息是如何传递的。
Communication on a one-to-one basis is usually performed by clients, since most server-server traffic is not a result of servers talking only to each other. To provide a means for clients to talk to each other, it is REQUIRED that all servers be able to send a message in exactly one direction along the spanning tree in order to reach any client. Thus the path of a message being delivered is the shortest path between any two points on the spanning tree.
一对一的通信通常由客户机执行，因为大多数服务器通信不是服务器之间只通信的结果。为了为客户机提供一种相互对话的方式，要求所有服务器能够沿着生成树向一个方向发送消息，以便到达任何客户机。因此，正在传递的消息的路径是生成树上任意两点之间的最短路径。
The following examples all refer to Figure 1 above.
以下示例均参考上述图1。
Example 1: A message between clients 1 and 2 is only seen by server A, which sends it straight to client 2.
示例1：客户端1和客户端2之间的消息仅由服务器A看到，它直接发送给客户端2。
Example 2: A message between clients 1 and 3 is seen by servers A & B, and client 3. No other clients or servers are allowed see the message.
示例2：客户端1和3之间的消息由服务器A和B以及客户端3看到。不允许其他客户端或服务器看到该消息。
Example 3: A message between clients 2 and 4 is seen by servers A, B, C & D and client 4 only.
示例3：客户端2和4之间的消息仅由服务器A、B、C&D和客户端4看到。
The main goal of IRC is to provide a forum which allows easy and efficient conferencing (one to many conversations). IRC offers several means to achieve this, each serving its own purpose.
IRC的主要目标是提供一个论坛，允许进行简单高效的会议（一对多对话）。IRC提供了几种实现这一目标的方法，每种方法都有自己的目的。
In IRC the channel has a role equivalent to that of the multicast group; their existence is dynamic and the actual conversation carried out on a channel MUST only be sent to servers which are supporting users on a given channel. Moreover, the message SHALL only be sent once to every local link as each server is responsible to fan the original message to ensure that it will reach all the recipients.
在IRC中，信道具有与多播组相同的角色；它们的存在是动态的，在一个频道上进行的实际对话必须只发送给在给定频道上支持用户的服务器。此外，消息只应发送一次到每个本地链接，因为每个服务器负责扇形原始消息，以确保它将到达所有收件人。
The following examples all refer to Figure 2.
以下示例均参考图2。
Example 4: Any channel with 1 client in it. Messages to the channel go to the server and then nowhere else.
示例4：任何包含1个客户端的通道。发送到该频道的消息将发送到服务器，而不会发送到其他地方。
Example 5: 2 clients in a channel. All messages traverse a path as if they were private messages between the two clients outside a channel.
示例5：一个通道中有两个客户端。所有消息都会遍历一条路径，就像它们是通道外部两个客户端之间的私有消息一样。
Example 6: Clients 1, 2 and 3 in a channel. All messages to the channel are sent to all clients and only those servers which must be traversed by the message if it were a private message to a single client. If client 1 sends a message, it goes back to client 2 and then via server B to client 3.
示例6：通道中的客户端1、2和3。发送到通道的所有消息都将发送到所有客户端，如果消息是发送到单个客户端的私有消息，则仅发送到消息必须遍历的服务器。如果客户机1发送消息，它将返回到客户机2，然后通过服务器B发送到客户机3。
To provide with some mechanism to send messages to a large body of related users, host and server mask messages are available. These messages are sent to users whose host or server information match that of the mask. The messages are only sent to locations where users are, in a fashion similar to that of channels.
为了提供向大量相关用户发送消息的机制，可以使用主机和服务器掩码消息。这些消息将发送给主机或服务器信息与掩码匹配的用户。消息仅发送到用户所在的位置，发送方式与频道类似。
The least efficient style of one-to-many conversation is through clients talking to a 'list' of targets (client, channel, mask). How this is done is almost self explanatory: the client gives a list of destinations to which the message is to be delivered and the server breaks it up and dispatches a separate copy of the message to each given destination.
一对多对话中效率最低的方式是通过客户机与目标（客户机、频道、掩码）的“列表”对话。如何做到这一点几乎是不言自明的：客户机给出了消息要传递到的目的地列表，服务器将其拆分，并将消息的单独副本发送到每个给定目的地。
This is not as efficient as using a channel since the destination list MAY be broken up and the dispatch sent without checking to make sure duplicates aren't sent down each path.
这不如使用通道有效，因为目标列表可能会被分解，发送分派时没有检查以确保不会沿每条路径发送重复项。
The one-to-all type of message is better described as a broadcast message, sent to all clients or servers or both. On a large network of users and servers, a single message can result in a lot of traffic being sent over the network in an effort to reach all of the desired destinations.
一对所有类型的消息最好描述为广播消息，发送到所有客户端或服务器或两者。在一个由用户和服务器组成的大型网络上，一条消息可能会导致大量流量通过网络发送，以达到所有预期目的地。
For some class of messages, there is no option but to broadcast it to all servers so that the state information held by each server is consistent between servers.
对于某些类别的消息，除了将其广播到所有服务器之外别无选择，这样每个服务器持有的状态信息在服务器之间是一致的。
There is no class of message which, from a single message, results in a message being sent to every other client.
没有一类消息会从单个消息中导致消息被发送到每个其他客户端。
Most of the commands which result in a change of state information (such as channel membership, channel mode, user status, etc.) MUST be sent to all servers by default, and this distribution SHALL NOT be changed by the client.
默认情况下，大多数导致状态信息（如频道成员资格、频道模式、用户状态等）更改的命令必须发送到所有服务器，客户端不得更改此分发。
While most messages between servers are distributed to all 'other' servers, this is only required for any message that affects a user, channel or server. Since these are the basic items found in IRC, nearly all messages originating from a server are broadcast to all other connected servers.
虽然服务器之间的大多数消息都分发到所有“其他”服务器，但这仅适用于影响用户、通道或服务器的任何消息。由于这些是IRC中的基本项，因此几乎所有来自服务器的消息都会广播到所有其他连接的服务器。
There are a number of recognized problems with this protocol, this section only addresses the problems related to the architecture of the protocol.
本协议存在许多公认的问题，本节仅讨论与协议架构相关的问题。
It is widely recognized that this protocol does not scale sufficiently well when used in a large arena. The main problem comes from the requirement that all servers know about all other servers, clients and channels and that information regarding them be updated as soon as it changes.
人们普遍认为，当在大型竞技场中使用时，该协议的扩展性不够好。主要问题来自这样一个要求：所有服务器都知道所有其他服务器、客户机和频道，并且一旦这些信息发生变化，就会立即更新这些信息。
As the only network configuration allowed for IRC servers is that of a spanning tree, each link between two servers is an obvious and quite serious point of failure. This particular issue is addressed more in detail in "Internet Relay Chat: Server Protocol" [IRC-SERVER].
由于IRC服务器允许的唯一网络配置是生成树配置，因此两台服务器之间的每条链路都是一个明显且相当严重的故障点。“Internet中继聊天：服务器协议”[IRC-Server]中更详细地讨论了这个特定问题。
Another problem related to the scalability and reliability issues, as well as the spanning tree architecture, is that the protocol and architecture for IRC are extremely vulnerable to network congestions. This problem is endemic, and should be solved for the next generation: if congestion and high traffic volume cause a link between two servers to fail, not only this failure generates more network traffic, but the reconnection (eventually elsewhere) of two servers also generates more traffic.
与可伸缩性和可靠性问题以及生成树体系结构相关的另一个问题是，IRC的协议和体系结构极易受到网络拥塞的影响。这是一个普遍存在的问题，应该为下一代解决：如果拥塞和高流量导致两台服务器之间的链路出现故障，不仅这种故障会产生更多的网络流量，而且两台服务器的重新连接（最终在别处）也会产生更多的流量。
In an attempt to minimize the impact of these problems, it is strongly RECOMMENDED that servers do not automatically try to reconnect too fast, in order to avoid aggravating the situation.
为了尽量减少这些问题的影响，强烈建议服务器不要自动尝试过快地重新连接，以免使情况恶化。
Besides not scaling well, the fact that servers need to know all information about other entities, the issue of privacy is also a concern. This is in particular true for channels, as the related information is quite a lot more revealing than whether a user is online or not.
除了不能很好地扩展之外，服务器需要知道关于其他实体的所有信息，隐私问题也是一个值得关注的问题。这对于频道来说尤其如此，因为相关信息比用户是否在线更能说明问题。
Asides from the privacy concerns mentioned in section 6.4 (Privacy), security is believed to be irrelevant to this document.
除了第6.4节（隐私）中提到的隐私问题外，安全性被认为与本文件无关。
Mailing lists for IRC related discussion:
General discussion: ircd-users@irc.org
Protocol development: ircd-dev@irc.org
Mailing lists for IRC related discussion:
General discussion: ircd-users@irc.org
Protocol development: ircd-dev@irc.org
Software implementations:
ftp://ftp.irc.org/irc/server
ftp://ftp.funet.fi/pub/unix/irc
ftp://coombs.anu.edu.au/pub/irc
Software implementations:
ftp://ftp.irc.org/irc/server
ftp://ftp.funet.fi/pub/unix/irc
ftp://coombs.anu.edu.au/pub/irc
Newsgroup: alt.irc
新闻组：alt.irc
Parts of this document were copied from the RFC 1459 [IRC] which first formally documented the IRC Protocol. It has also benefited from many rounds of review and comments. In particular, the following people have made significant contributions to this document:
本文件的部分内容是从RFC 1459[IRC]中复制的，该文件首先正式记录了IRC协议。它还受益于多轮审查和评论。特别是，以下人员对本文件做出了重大贡献：
Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa Ruokonen, Magnus Tjernstrom, Stefan Zehl.
马修·格林、迈克尔·纽梅尔、沃尔克·保尔森、库尔特·罗克斯、维萨·鲁科宁、马格纳斯·特杰恩斯特罗姆、斯特凡·泽尔。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[IRC] Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol", RFC 1459, May 1993.
[IRC]Oikarinen，J.和D.Reed，“互联网中继聊天协议”，RFC 1459，1993年5月。
[IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC 2812, April 2000.
[IRC-CLIENT]Kalt，C.，“互联网中继聊天：客户端协议”，RFC28122000年4月。
[IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC 2813, April 2000.
[IRC-SERVER]Kalt，C.，“互联网中继聊天：服务器协议”，RFC 28132000年4月。
[IRC-CHAN] Kalt, C., "Internet Relay Chat: Channel Management", RFC 2811, April 2000.
[IRC-CHAN]Kalt，C.，“互联网中继聊天：频道管理”，RFC 28112000年4月。
Christophe Kalt 99 Teaneck Rd, Apt #117 Ridgefield Park, NJ 07660 USA
克里斯托夫·卡尔特美国新泽西州里奇菲尔德公园117号公寓蒂内克路99号，邮编：07660
EMail: kalt@stealth.net
EMail: kalt@stealth.net
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。