Network Working Group C. Kalt
Request for Comments: 2813 April 2000
Updates: 1459
Category: Informational
Network Working Group C. Kalt
Request for Comments: 2813 April 2000
Updates: 1459
Category: Informational
Internet Relay Chat: Server Protocol
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
摘要
While based on the client-server model, the IRC (Internet Relay Chat) protocol allows servers to connect to each other effectively forming a network.
基于客户机-服务器模型，IRC（Internet中继聊天）协议允许服务器相互连接，形成有效的网络。
This document defines the protocol used by servers to talk to each other. It was originally a superset of the client protocol but has evolved differently.
本文档定义了服务器用于相互通信的协议。它最初是客户端协议的一个超集，但现在有了不同的发展。
First formally documented in May 1993 as part of RFC 1459 [IRC], most of the changes brought since then can be found in this document as development was focused on making the protocol scale better. Better scalability has allowed existing world-wide networks to keep growing and reach sizes which defy the old specification.
1993年5月作为RFC 1459[IRC]的一部分首次正式记录，此后的大部分变化都可以在本文件中找到，因为开发的重点是提高协议的规模。更好的可扩展性使现有的全球网络能够不断增长，并达到与旧规范不同的规模。
Table of Contents
目录
1. Introduction ............................................... 3
2. Global database ............................................ 3
2.1 Servers ................................................ 3
2.2 Clients ................................................ 4
2.2.1 Users ............................................. 4
2.2.2 Services .......................................... 4
2.3 Channels ............................................... 4
3. The IRC Server Specification ............................... 5
3.1 Overview ............................................... 5
3.2 Character codes ........................................ 5
3.3 Messages ............................................... 5
3.3.1 Message format in Augmented BNF ................... 6
3.4 Numeric replies ........................................ 7
4. Message Details ............................................ 7
4.1 Connection Registration ................................ 8
4.1.1 Password message .................................. 8
4.1.2 Server message .................................... 9
4.1.3 Nick .............................................. 10
4.1.4 Service message ................................... 11
4.1.5 Quit .............................................. 12
4.1.6 Server quit message ............................... 13
4.2 Channel operations ..................................... 14
4.2.1 Join message ...................................... 14
4.2.2 Njoin message ..................................... 15
4.2.3 Mode message ...................................... 16
5. Implementation details .................................... 16
5.1 Connection 'Liveness' .................................. 16
5.2 Accepting a client to server connection ................ 16
5.2.1 Users ............................................. 16
5.2.2 Services .......................................... 17
5.3 Establishing a server-server connection. ............... 17
5.3.1 Link options ...................................... 17
5.3.1.1 Compressed server to server links ............ 18
5.3.1.2 Anti abuse protections ....................... 18
5.3.2 State information exchange when connecting ........ 18
5.4 Terminating server-client connections .................. 19
5.5 Terminating server-server connections .................. 19
5.6 Tracking nickname changes .............................. 19
5.7 Tracking recently used nicknames ....................... 20
5.8 Flood control of clients ............................... 20
5.9 Non-blocking lookups ................................... 21
5.9.1 Hostname (DNS) lookups ............................ 21
5.9.2 Username (Ident) lookups .......................... 21
6. Current problems ........................................... 21
6.1 Scalability ............................................ 21
6.2 Labels ................................................. 22
1. Introduction ............................................... 3
2. Global database ............................................ 3
2.1 Servers ................................................ 3
2.2 Clients ................................................ 4
2.2.1 Users ............................................. 4
2.2.2 Services .......................................... 4
2.3 Channels ............................................... 4
3. The IRC Server Specification ............................... 5
3.1 Overview ............................................... 5
3.2 Character codes ........................................ 5
3.3 Messages ............................................... 5
3.3.1 Message format in Augmented BNF ................... 6
3.4 Numeric replies ........................................ 7
4. Message Details ............................................ 7
4.1 Connection Registration ................................ 8
4.1.1 Password message .................................. 8
4.1.2 Server message .................................... 9
4.1.3 Nick .............................................. 10
4.1.4 Service message ................................... 11
4.1.5 Quit .............................................. 12
4.1.6 Server quit message ............................... 13
4.2 Channel operations ..................................... 14
4.2.1 Join message ...................................... 14
4.2.2 Njoin message ..................................... 15
4.2.3 Mode message ...................................... 16
5. Implementation details .................................... 16
5.1 Connection 'Liveness' .................................. 16
5.2 Accepting a client to server connection ................ 16
5.2.1 Users ............................................. 16
5.2.2 Services .......................................... 17
5.3 Establishing a server-server connection. ............... 17
5.3.1 Link options ...................................... 17
5.3.1.1 Compressed server to server links ............ 18
5.3.1.2 Anti abuse protections ....................... 18
5.3.2 State information exchange when connecting ........ 18
5.4 Terminating server-client connections .................. 19
5.5 Terminating server-server connections .................. 19
5.6 Tracking nickname changes .............................. 19
5.7 Tracking recently used nicknames ....................... 20
5.8 Flood control of clients ............................... 20
5.9 Non-blocking lookups ................................... 21
5.9.1 Hostname (DNS) lookups ............................ 21
5.9.2 Username (Ident) lookups .......................... 21
6. Current problems ........................................... 21
6.1 Scalability ............................................ 21
6.2 Labels ................................................. 22
6.2.1 Nicknames ......................................... 22
6.2.2 Channels .......................................... 22
6.2.3 Servers ........................................... 22
6.3 Algorithms ............................................. 22
7. Security Considerations .................................... 23
7.1 Authentication ......................................... 23
7.2 Integrity .............................................. 23
8. Current support and availability ........................... 24
9. Acknowledgements ........................................... 24
10. References ................................................ 24
11. Author's Address .......................................... 25
12. Full Copyright Statement ................................... 26
6.2.1 Nicknames ......................................... 22
6.2.2 Channels .......................................... 22
6.2.3 Servers ........................................... 22
6.3 Algorithms ............................................. 22
7. Security Considerations .................................... 23
7.1 Authentication ......................................... 23
7.2 Integrity .............................................. 23
8. Current support and availability ........................... 24
9. Acknowledgements ........................................... 24
10. References ................................................ 24
11. Author's Address .......................................... 25
12. Full Copyright Statement ................................... 26
This document is intended for people working on implementing an IRC server but will also be useful to anyone implementing an IRC service.
本文档适用于致力于实现IRC服务器的人员，但对任何实现IRC服务的人员也很有用。
Servers provide the three basic services required for realtime conferencing defined by the "Internet Relay Chat: Architecture" [IRC-ARCH]: client locator (via the client protocol [IRC-CLIENT]), message relaying (via the server protocol defined in this document) and channel hosting and management (following specific rules [IRC-CHAN]).
服务器提供“Internet中继聊天：体系结构”[IRC-ARCH]：客户端定位器（通过客户端协议[IRC-client]）、消息中继（通过本文档中定义的服务器协议）和频道托管和管理（遵循特定规则[IRC-CHAN]）定义的实时会议所需的三项基本服务。
Although the IRC Protocol defines a fairly distributed model, each server maintains a "global state database" about the whole IRC network. This database is, in theory, identical on all servers.
尽管IRC协议定义了一个相当分布式的模型，但每台服务器都维护一个关于整个IRC网络的“全局状态数据库”。理论上，该数据库在所有服务器上都是相同的。
Servers are uniquely identified by their name which has a maximum length of sixty three (63) characters. See the protocol grammar rules (section 3.3.1) for what may and may not be used in a server name.
服务器通过其名称进行唯一标识，名称的最大长度为六十三（63）个字符。请参阅协议语法规则（第3.3.1节），了解服务器名称中可能使用和可能不使用的内容。
Each server is typically known by all other servers, however it is possible to define a "hostmask" to group servers together according to their name. Inside the hostmasked area, all the servers have a name which matches the hostmask, and any other server with a name matching the hostmask SHALL NOT be connected to the IRC network outside the hostmasked area. Servers which are outside the area have no knowledge of the individual servers present inside the area, instead they are presented with a virtual server which has the hostmask for name.
每个服务器通常为所有其他服务器所知，但是可以定义“主机掩码”以根据服务器名称将服务器分组在一起。在hostmasked区域内，所有服务器都有一个与hostmask匹配的名称，任何其他名称与hostmask匹配的服务器都不得连接到hostmasked区域外的IRC网络。区域外的服务器不知道区域内的各个服务器，而是显示一个虚拟服务器，该服务器的名称为hostmask。
For each client, all servers MUST have the following information: a netwide unique identifier (whose format depends on the type of client) and the server to which the client is connected.
对于每个客户端，所有服务器都必须具有以下信息：netwide唯一标识符（其格式取决于客户端的类型）和客户端连接到的服务器。
Each user is distinguished from other users by a unique nickname having a maximum length of nine (9) characters. See the protocol grammar rules (section 3.3.1) for what may and may not be used in a nickname. In addition to the nickname, all servers MUST have the following information about all users: the name of the host that the user is running on, the username of the user on that host, and the server to which the client is connected.
每个用户都有一个唯一的昵称，最大长度为九（9）个字符，与其他用户不同。请参阅协议语法规则（第3.3.1节），了解昵称中可能使用和可能不使用的内容。除昵称外，所有服务器必须具有有关所有用户的以下信息：用户运行的主机的名称、该主机上用户的用户名以及客户端连接到的服务器。
Each service is distinguished from other services by a service name composed of a nickname and a server name. The nickname has a maximum length of nine (9) characters. See the protocol grammar rules (section 3.3.1) for what may and may not be used in a nickname. The server name used to compose the service name is the name of the server to which the service is connected. In addition to this service name all servers MUST know the service type.
每个服务都有一个由昵称和服务器名组成的服务名来区别于其他服务。昵称的最大长度为九（9）个字符。请参阅协议语法规则（第3.3.1节），了解昵称中可能使用和可能不使用的内容。用于组成服务名称的服务器名称是服务所连接的服务器的名称。除此服务名称外，所有服务器都必须知道服务类型。
Services differ from users by the format of their identifier, but more importantly services and users don't have the same type of access to the server: services can request part or all of the global state information that a server maintains, but have a more restricted set of commands available to them (See "IRC Client Protocol" [IRC-CLIENT] for details on which) and are not allowed to join channels. Finally services are not usually subject to the "Flood control" mechanism described in section 5.8.
服务与用户的标识符格式不同，但更重要的是，服务和用户对服务器的访问类型不同：服务可以请求服务器维护的部分或全部全局状态信息，但对其可用的命令集更为有限（请参阅“IRC客户端协议”[IRC-Client]有关的详细信息，请参阅）和不允许加入频道。最后，服务通常不受第5.8节所述“防洪”机制的约束。
Alike services, channels have a scope [IRC-CHAN] and are not necessarily known to all servers. When a channel existence is known to a server, the server MUST keep track of the channel members, as well as the channel modes.
与服务类似，通道也有一个作用域[IRC-CHAN]，不一定所有服务器都知道。当服务器知道通道存在时，服务器必须跟踪通道成员以及通道模式。
The protocol as described herein is for use with server to server connections. For client to server connections, see the IRC Client Protocol specification.
本文所述的协议用于服务器到服务器的连接。有关客户端到服务器的连接，请参阅IRC客户端协议规范。
There are, however, more restrictions on client connections (which are considered to be untrustworthy) than on server connections.
但是，与服务器连接相比，客户端连接（被认为不可信）受到更多的限制。
No specific character set is specified. The protocol is based on a a set of codes which are composed of eight (8) bits, making up an octet. Each message may be composed of any number of these octets; however, some octet values are used for control codes which act as message delimiters.
没有指定特定的字符集。该协议基于一组由八（8）位组成的代码，组成一个八位字节。每条消息可以由任意数量的八位字节组成；但是，某些八位字节值用于充当消息分隔符的控制代码。
Regardless of being an 8-bit protocol, the delimiters and keywords are such that protocol is mostly usable from US-ASCII terminal and a telnet connection.
无论是8位协议，定界符和关键字都是这样的，即该协议主要可从US-ASCII终端和telnet连接使用。
Because of IRC's Scandinavian origin, the characters {}|^ are considered to be the lower case equivalents of the characters []\~, respectively. This is a critical issue when determining the equivalence of two nicknames, or channel names.
由于IRC起源于斯堪的纳维亚，字符{}|^被认为分别是字符[]\~的小写等价物。在确定两个昵称或频道名称的等效性时，这是一个关键问题。
Servers and clients send each other messages which may or may not generate a reply. Most communication between servers do not generate any reply, as servers mostly perform routing tasks for the clients.
服务器和客户端相互发送消息，这些消息可能会生成回复，也可能不会生成回复。服务器之间的大多数通信不会生成任何回复，因为服务器主要为客户端执行路由任务。
Each IRC message may consist of up to three main parts: the prefix (OPTIONAL), the command, and the command parameters (maximum of fifteen (15)). The prefix, command, and all parameters are separated by one ASCII space character (0x20) each.
每个IRC消息最多可由三个主要部分组成：前缀（可选）、命令和命令参数（最多十五（15））。前缀、命令和所有参数分别由一个ASCII空格字符（0x20）分隔。
The presence of a prefix is indicated with a single leading ASCII colon character (':', 0x3b), which MUST be the first character of the message itself. There MUST be NO gap (whitespace) between the colon and the prefix. The prefix is used by servers to indicate the true origin of the message. If the prefix is missing from the message, it is assumed to have originated from the connection from which it was received. Clients SHOULD not use a prefix when sending a message from themselves; if they use one, the only valid prefix is the registered nickname associated with the client.
前缀的存在由单个前导ASCII冒号字符（“：”，0x3b）表示，该字符必须是消息本身的第一个字符。冒号和前缀之间不能有空格。服务器使用前缀指示消息的真实来源。如果消息中缺少前缀，则假定该前缀来自接收该前缀的连接。客户端从自身发送消息时不应使用前缀；如果他们使用一个，唯一有效的前缀是与客户端关联的注册昵称。
When a server receives a message, it MUST identify its source using the (eventually assumed) prefix. If the prefix cannot be found in the server's internal database, it MUST be discarded, and if the prefix indicates the message comes from an (unknown) server, the link from which the message was received MUST be dropped. Dropping a link in such circumstances is a little excessive but necessary to maintain the integrity of the network and to prevent future problems. Another common error condition is that the prefix found in the server's internal database identifies a different source (typically a source registered from a different link than from which the message arrived). If the message was received from a server link and the prefix identifies a client, a KILL message MUST be issued for the client and sent to all servers. In other cases, the link from which the message arrived SHOULD be dropped for clients, and MUST be dropped for servers. In all cases, the message MUST be discarded.
当服务器接收到消息时，它必须使用（最终假定的）前缀标识其源。如果在服务器的内部数据库中找不到前缀，则必须将其丢弃；如果前缀指示消息来自（未知）服务器，则必须删除接收消息的链接。在这种情况下断开链路有点过分，但为了保持网络的完整性和防止将来出现问题，这是必要的。另一个常见的错误情况是，在服务器的内部数据库中找到的前缀标识不同的源（通常是从与消息到达的链接不同的链接注册的源）。如果消息是从服务器链接接收的，并且前缀标识客户端，则必须为客户端发出KILL消息并发送到所有服务器。在其他情况下，应该为客户端删除消息到达的链接，为服务器删除该链接。在所有情况下，都必须丢弃该消息。
The command MUST either be a valid IRC command or a three (3) digit number represented in ASCII text.
该命令必须是有效的IRC命令或以ASCII文本表示的三（3）位数字。
IRC messages are always lines of characters terminated with a CR-LF (Carriage Return - Line Feed) pair, and these messages SHALL NOT exceed 512 characters in length, counting all characters including the trailing CR-LF. Thus, there are 510 characters maximum allowed for the command and its parameters. There is no provision for continuation message lines. See section 5 for more details about current implementations.
IRC消息始终是以CR-LF（回车换行）对终止的字符行，这些消息的长度不得超过512个字符，包括尾部CR-LF在内的所有字符。因此，该命令及其参数最多允许510个字符。没有关于连续消息行的规定。有关当前实现的更多详细信息，请参见第5节。
The protocol messages must be extracted from the contiguous stream of octets. The current solution is to designate two characters, CR and LF, as message separators. Empty messages are silently ignored, which permits use of the sequence CR-LF between messages without extra problems.
协议消息必须从连续的八位字节流中提取。当前的解决方案是指定两个字符CR和LF作为消息分隔符。空消息被静默忽略，这允许在消息之间使用序列CR-LF，而不会产生额外的问题。
The extracted message is parsed into the components <prefix>, <command> and list of parameters (<params>).
提取的消息被解析为组件<prefix>、<command>和参数列表（<params>）。
The Augmented BNF representation for this is found in "IRC Client Protocol" [IRC-CLIENT].
在“IRC客户端协议”[IRC-Client]中可以找到此协议的扩展BNF表示。
The extended prefix (["!" user "@" host ]) MUST NOT be used in server to server communications and is only intended for server to client messages in order to provide clients with more useful information about who a message is from without the need for additional queries.
扩展前缀（[“！”user“@”host]）不得用于服务器到服务器的通信，仅用于服务器到客户端的邮件，以便向客户端提供有关邮件发件人的更有用信息，而无需进行其他查询。
Most of the messages sent to the server generate a reply of some sort. The most common reply is the numeric reply, used for both errors and normal replies. The numeric reply MUST be sent as one message consisting of the sender prefix, the three digit numeric, and the target of the reply. A numeric reply is not allowed to originate from a client; any such messages received by a server are silently dropped. In all other respects, a numeric reply is just like a normal message, except that the keyword is made up of 3 numeric digits rather than a string of letters. A list of different replies is supplied in "IRC Client Protocol" [IRC-CLIENT].
发送到服务器的大多数消息都会生成某种回复。最常见的回复是数字回复，用于错误回复和正常回复。数字回复必须作为一条由发件人前缀、三位数字和回复目标组成的消息发送。数字回复不允许来自客户端；服务器接收到的任何此类消息都会被静默删除。在所有其他方面，数字回复与普通邮件一样，只是关键字由3个数字组成，而不是由一串字母组成。“IRC客户端协议”[IRC-Client]中提供了不同回复的列表。
All the messages recognized by the IRC server and client are described in the IRC Client Protocol specification.
IRC客户端协议规范中描述了IRC服务器和客户端识别的所有消息。
Where the reply ERR_NOSUCHSERVER is returned, it means that the target of the message could not be found. The server MUST NOT send any other replies after this error for that command.
如果返回reply ERR_NOSUCHSERVER，则表示无法找到消息的目标。该命令出现此错误后，服务器不得发送任何其他回复。
The server to which a client is connected is required to parse the complete message, returning any appropriate errors. If the server encounters a fatal error while parsing a message, an error MUST be sent back to the client and the parsing terminated. A fatal error may follow from incorrect command, a destination which is otherwise unknown to the server (server, client or channel names fit this category), not enough parameters or incorrect privileges.
客户端连接到的服务器需要解析完整的消息，并返回任何适当的错误。如果服务器在解析消息时遇到致命错误，则必须将错误发送回客户端并终止解析。错误的命令、服务器未知的目标（服务器、客户端或通道名称适合此类别）、参数不足或权限不正确可能导致致命错误。
If a full set of parameters is presented, then each MUST be checked for validity and appropriate responses sent back to the client. In the case of messages which use parameter lists using the comma as an item separator, a reply MUST be sent for each item.
如果提供了完整的参数集，则必须检查每个参数的有效性，并将适当的响应发送回客户端。对于使用参数列表并使用逗号作为项目分隔符的邮件，必须为每个项目发送回复。
In the examples below, some messages appear using the full format:
在以下示例中，某些消息使用完整格式显示：
:Name COMMAND parameter list
：Name命令参数列表
Such examples represent a message from "Name" in transit between servers, where it is essential to include the name of the original sender of the message so remote servers may send back a reply along the correct path.
此类示例表示在服务器之间传输的来自“Name”的消息，其中必须包含消息的原始发件人的名称，以便远程服务器可以沿正确路径发回回复。
The message details for client to server communication are described in the "IRC Client Protocol" [IRC-CLIENT]. Some sections in the following pages apply to some of these messages, they are additions to the message specifications which are only relevant to server to
“IRC客户端协议”[IRC-client]中描述了客户端到服务器通信的消息详细信息。以下页面中的某些部分适用于其中一些消息，它们是对消息规范的补充，这些规范仅与服务器相关
server communication, or to the server implementation. The messages which are introduced here are only used for server to server communication.
服务器通信，或到服务器实现。这里介绍的消息仅用于服务器到服务器的通信。
The commands described here are used to register a connection with another IRC server.
这里描述的命令用于注册与另一个IRC服务器的连接。
Command: PASS
Parameters: <password> <version> <flags> [<options>]
Command: PASS
Parameters: <password> <version> <flags> [<options>]
The PASS command is used to set a 'connection password'. The password MUST be set before any attempt to register the connection is made. Currently this means that servers MUST send a PASS command before any SERVER command. Only one (1) PASS command SHALL be accepted from a connection.
PASS命令用于设置“连接密码”。在尝试注册连接之前，必须设置密码。目前，这意味着服务器必须在发送任何服务器命令之前发送PASS命令。一个连接只能接受一（1）个PASS命令。
The last three (3) parameters MUST be ignored if received from a client (e.g. a user or a service). They are only relevant when received from a server.
如果从客户端（如用户或服务）接收到最后三（3）个参数，则必须忽略。它们仅在从服务器接收时才相关。
The <version> parameter is a string of at least four (4) characters, and up to fourteen (14) characters. The first four (4) characters MUST be digits and indicate the protocol version known by the server issuing the message. The protocol described by this document is version 2.10 which is encoded as "0210". The remaining OPTIONAL characters are implementation dependent and should describe the software version number.
<version>参数是至少四（4）个字符的字符串，最多十四（14）个字符。前四（4）个字符必须是数字，表示发出消息的服务器已知的协议版本。本文件描述的协议为2.10版，编码为“0210”。其余可选字符取决于实现，应描述软件版本号。
The <flags> parameter is a string of up to one hundred (100) characters. It is composed of two substrings separated by the character "|" (%x7C). If present, the first substring MUST be the name of the implementation. The reference implementation (See Section 8, "Current support and availability") uses the string "IRC". If a different implementation is written, which needs an identifier, then that identifier should be registered through publication of an RFC. The second substring is implementation dependent. Both substrings are OPTIONAL, but the character "|" is REQUIRED. The character "|" MUST NOT appear in either substring.
<flags>参数是最多一百（100）个字符的字符串。它由两个子字符串组成，由字符“|”（%x7C）分隔。如果存在，则第一个子字符串必须是实现的名称。参考实现（参见第8节“当前支持和可用性”）使用字符串“IRC”。如果编写了需要标识符的不同实现，那么应该通过发布RFC来注册该标识符。第二个子字符串依赖于实现。两个子字符串都是可选的，但字符“|”是必需的。字符“|”不得出现在任一子字符串中。
Finally, the last parameter, <options>, is used for link options. The only options defined by the protocol are link compression (using the character "Z"), and an abuse protection flag (using the character
最后，最后一个参数<options>用于链接选项。协议定义的唯一选项是链路压缩（使用字符“Z”）和滥用保护标志（使用字符“Z”）
"P"). See sections 5.3.1.1 (Compressed server to server links) and 5.3.1.2 (Anti abuse protections) respectively for more information on these options.
“P”）。有关这些选项的更多信息，请分别参见第5.3.1.1节（压缩服务器到服务器链接）和第5.3.1.2节（防滥用保护）。
Numeric Replies:
数字回复：
ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED
ERR_needmore参数ERR_已注册
Example:
例子：
PASS moresecretpassword 0210010000 IRC|aBgH$ Z
通过moresecretpassword 0210010000 IRC | aBgH$Z
Command: SERVER
Parameters: <servername> <hopcount> <token> <info>
Command: SERVER
Parameters: <servername> <hopcount> <token> <info>
The SERVER command is used to register a new server. A new connection introduces itself as a server to its peer. This message is also used to pass server data over whole net. When a new server is connected to net, information about it MUST be broadcasted to the whole network.
SERVER命令用于注册新服务器。一个新的连接将自己作为一个服务器介绍给它的对等方。此消息还用于通过整个网络传递服务器数据。当一台新服务器连接到网络时，有关它的信息必须广播到整个网络。
The <info> parameter may contain space characters.
<info>参数可能包含空格字符。
<hopcount> is used to give all servers some internal information on how far away each server is. Local peers have a value of 0, and each passed server increments the value. With a full server list, it would be possible to construct a map of the entire server tree, but hostmasks prevent this from being done.
<hopcount>用于向所有服务器提供有关每个服务器距离的一些内部信息。本地对等点的值为0，每个传递的服务器都会增加该值。有了完整的服务器列表，就可以构建整个服务器树的映射，但主机掩码阻止了这一操作。
The <token> parameter is an unsigned number used by servers as an identifier. This identifier is subsequently used to reference a server in the NICK and SERVICE messages sent between servers. Server tokens only have a meaning for the point-to-point peering they are used and MUST be unique for that connection. They are not global.
<token>参数是服务器用作标识符的无符号数字。此标识符随后用于引用尼克中的服务器以及服务器之间发送的服务消息。服务器令牌仅对所使用的点对点对等具有意义，并且对于该连接必须是唯一的。它们不是全球性的。
The SERVER message MUST only be accepted from either (a) a connection which is yet to be registered and is attempting to register as a server, or (b) an existing connection to another server, in which case the SERVER message is introducing a new server behind that server.
服务器消息只能从（a）尚未注册并试图注册为服务器的连接，或（b）到另一台服务器的现有连接接受，在这种情况下，服务器消息将在该服务器后面引入新服务器。
Most errors that occur with the receipt of a SERVER command result in the connection being terminated by the destination host (target SERVER). Because of the severity of such event, error replies are usually sent using the "ERROR" command rather than a numeric.
接收服务器命令时发生的大多数错误都会导致目标主机（目标服务器）终止连接。由于此类事件的严重性，通常使用“error”命令而不是数字命令发送错误回复。
If a SERVER message is parsed and it attempts to introduce a server which is already known to the receiving server, the connection, from which that message arrived, MUST be closed (following the correct procedures), since a duplicate route to a server has been formed and the acyclic nature of the IRC tree breaks. In some conditions, the connection from which the already known server has registered MAY be closed instead. It should be noted that this kind of error can also be the result of a second running server, problem which cannot be fixed within the protocol and typically requires human intervention. This type of problem is particularly insidious, as it can quite easily result in part of the IRC network to be isolated, with one of the two servers connected to each partition therefore making it impossible for the two parts to unite.
如果解析服务器消息并尝试引入接收服务器已知的服务器，则必须关闭该消息到达的连接（遵循正确的过程），因为已形成到服务器的重复路由，并且IRC树的非循环性质已中断。在某些情况下，可能会关闭已知服务器已注册的连接。应该注意的是，这种错误也可能是第二台正在运行的服务器造成的，该问题无法在协议中修复，通常需要人工干预。这类问题特别隐蔽，因为它很容易导致IRC网络的一部分被隔离，两台服务器中的一台连接到每个分区，因此这两个部分不可能联合起来。
Numeric Replies:
数字回复：
ERR_ALREADYREGISTRED
错误已经登记
Example:
例子：
SERVER test.oulu.fi 1 1 :Experimental server ; New server test.oulu.fi introducing itself and attempting to register.
SERVER test.oulu.fi 1 1：实验服务器；新服务器test.oulu.fi自我介绍并尝试注册。
:tolsun.oulu.fi SERVER csd.bu.edu 5 34 :BU Central Server ; Server tolsun.oulu.fi is our uplink for csd.bu.edu which is 5 hops away. The token "34" will be used by tolsun.oulu.fi when introducing new users or services connected to csd.bu.edu.
：tolsun.oulu.fi服务器csd.bu.edu 5 34:bu中央服务器；服务器tolsun.oulu.fi是我们csd.bu.edu的上行线路，距离csd.bu.edu只有5跳。tolsun.oulu.fi在引入连接到csd.bu.edu的新用户或服务时将使用令牌“34”。
Command: NICK
Parameters: <nickname> <hopcount> <username> <host> <servertoken>
<umode> <realname>
Command: NICK
Parameters: <nickname> <hopcount> <username> <host> <servertoken>
<umode> <realname>
This form of the NICK message MUST NOT be allowed from user connections. However, it MUST be used instead of the NICK/USER pair to notify other servers of new users joining the IRC network.
用户连接不允许使用这种形式的尼克消息。但是，必须使用它而不是尼克/用户对来通知其他服务器新用户加入IRC网络。
This message is really the combination of three distinct messages: NICK, USER and MODE [IRC-CLIENT].
此消息实际上是三条不同消息的组合：NICK、USER和MODE[IRC-CLIENT]。
The <hopcount> parameter is used by servers to indicate how far away a user is from its home server. A local connection has a hopcount of 0. The hopcount value is incremented by each passed server.
服务器使用<hopcount>参数指示用户与其主服务器的距离。本地连接的跃点计数为0。每个传递的服务器都会增加hopcount值。
The <servertoken> parameter replaces the <servername> parameter of the USER (See section 4.1.2 for more information on server tokens).
<servertoken>参数替换用户的<servername>参数（有关服务器令牌的更多信息，请参阅第4.1.2节）。
Examples:
示例：
NICK syrk 5 kalt millennium.stealth.net 34 +i :Christophe Kalt ; New user with nickname "syrk", username "kalt", connected from host "millennium.stealth.net" to server "34" ("csd.bu.edu" according to the previous example).
NICK syrk 5 kalt millennium.隐身.net 34+i:Christophe kalt；昵称为“syrk”、用户名为“kalt”的新用户，从主机“millennium.Steave.net”连接到服务器“34”（“根据前面的示例，是csd.bu.edu”）。
:krys NICK syrk ; The other form of the NICK message, as defined in "IRC Client Protocol" [IRC-CLIENT] and used between servers: krys changed his nickname to syrk
：krys NICK syrk；NICK消息的另一种形式，在“IRC客户端协议”[IRC-Client]中定义并在服务器之间使用：krys将他的昵称改为syrk
Command: SERVICE
Parameters: <servicename> <servertoken> <distribution> <type>
<hopcount> <info>
Command: SERVICE
Parameters: <servicename> <servertoken> <distribution> <type>
<hopcount> <info>
The SERVICE command is used to introduce a new service. This form of the SERVICE message SHOULD NOT be allowed from client (unregistered, or registered) connections. However, it MUST be used between servers to notify other servers of new services joining the IRC network.
SERVICE命令用于引入新服务。客户端（未注册或已注册）连接不允许使用这种形式的服务消息。但是，必须在服务器之间使用它来通知其他服务器加入IRC网络的新服务。
The <servertoken> is used to identify the server to which the service is connected. (See section 4.1.2 for more information on server tokens).
<servertoken>用于标识服务所连接的服务器。（有关服务器令牌的更多信息，请参见第4.1.2节）。
The <hopcount> parameter is used by servers to indicate how far away a service is from its home server. A local connection has a hopcount of 0. The hopcount value is incremented by each passed server.
服务器使用<hopcount>参数指示服务与其主服务器的距离。本地连接的跃点计数为0。每个传递的服务器都会增加hopcount值。
The <distribution> parameter is used to specify the visibility of a service. The service may only be known to servers which have a name matching the distribution. For a matching server to have knowledge of the service, the network path between that server and the server to which the service is connected MUST be composed of servers whose names all match the mask. Plain "*" is used when no restriction is wished.
<distribution>参数用于指定服务的可见性。只有名称与分发版匹配的服务器才能知道该服务。要使匹配服务器了解服务，该服务器与服务所连接的服务器之间的网络路径必须由名称均与掩码匹配的服务器组成。如果不希望限制，则使用普通“*”。
The <type> parameter is currently reserved for future usage.
<type>参数当前保留供将来使用。
Numeric Replies:
数字回复：
ERR_ALREADYREGISTRED ERR_NEEDMOREPARAMS ERR_ERRONEUSNICKNAME RPL_YOURESERVICE RPL_YOURHOST RPL_MYINFO
ERR\u已注册ERR\u需要更多参数ERR\u erroroneusnickname RPL\u youre服务RPL\u主机RPL\u MYINFO
Example:
例子：
SERVICE dict@irc.fr 9 *.fr 0 1 :French Dictionary r" registered on server "9" is being announced to another server. This service will only be available on servers whose name matches "*.fr".
服务dict@irc.fr9*.fr 0 1:在服务器“9”上注册的法语词典r“正在向另一台服务器发布。此服务仅在名称与“*.fr”匹配的服务器上可用。
Command: QUIT
Parameters: [<Quit Message>]
Command: QUIT
Parameters: [<Quit Message>]
A client session ends with a quit message. The server MUST close the connection to a client which sends a QUIT message. If a "Quit Message" is given, this will be sent instead of the default message, the nickname or service name.
客户端会话以退出消息结束。服务器必须关闭与发送退出消息的客户端的连接。如果给出“退出消息”，则将发送该消息，而不是默认消息、昵称或服务名称。
When "netsplit" (See Section 4.1.6) occur, the "Quit Message" is composed of the names of two servers involved, separated by a space. The first name is that of the server which is still connected and the second name is either that of the server which has become disconnected or that of the server to which the leaving client was connected:
当出现“netsplit”（见第4.1.6节）时，“退出消息”由两个相关服务器的名称组成，用空格分隔。第一个名称是仍然连接的服务器的名称，第二个名称是断开连接的服务器的名称，或者是离开的客户端连接到的服务器的名称：
<Quit Message> = ":" servername SPACE servername
<Quit Message> = ":" servername SPACE servername
Because the "Quit Message" has a special meaning for "netsplits", servers SHOULD NOT allow a client to use a <Quit Message> in the format described above.
由于“退出消息”对“netsplits”有特殊含义，服务器不应允许客户端使用上述格式的<Quit Message>。
If, for some other reason, a client connection is closed without the client issuing a QUIT command (e.g. client dies and EOF occurs on socket), the server is REQUIRED to fill in the quit message with some sort of message reflecting the nature of the event which caused it to happen. Typically, this is done by reporting a system specific error.
如果由于某些其他原因，客户端连接在客户端未发出QUIT命令的情况下关闭（例如，客户端死亡，套接字上发生EOF），则服务器需要使用某种类型的消息填充QUIT消息，以反映导致其发生的事件的性质。通常，这是通过报告特定于系统的错误来完成的。
Numeric Replies:
数字回复：
None.
没有一个
Examples:
示例：
:WiZ QUIT :Gone to have lunch ; Preferred message format.
：不干了：去吃午饭了；首选消息格式。
Command: SQUIT
Parameters: <server> <comment>
Command: SQUIT
Parameters: <server> <comment>
The SQUIT message has two distinct uses.
SQUIT消息有两种不同的用途。
The first one (described in "Internet Relay Chat: Client Protocol" [IRC-CLIENT]) allows operators to break a local or remote server link. This form of the message is also eventually used by servers to break a remote server link.
第一种（在“Internet中继聊天：客户端协议”[IRC-Client]中描述）允许操作员断开本地或远程服务器链接。这种形式的消息最终也会被服务器用来断开远程服务器链接。
The second use of this message is needed to inform other servers when a "network split" (also known as "netsplit") occurs, in other words to inform other servers about quitting or dead servers. If a server wishes to break the connection to another server it MUST send a SQUIT message to the other server, using the name of the other server as the server parameter, which then closes its connection to the quitting server.
此消息的第二个用途是在发生“网络剥离”（也称为“netsplit”）时通知其他服务器，换句话说，通知其他服务器退出或服务器死机。如果服务器希望断开与另一台服务器的连接，则必须使用另一台服务器的名称作为服务器参数，向另一台服务器发送一条短消息，然后关闭与退出服务器的连接。
The <comment> is filled in by servers which SHOULD place an error or similar message here.
<comment>由服务器填写，服务器应在此处放置错误或类似消息。
Both of the servers which are on either side of the connection being closed are REQUIRED to send out a SQUIT message (to all its other server connections) for all other servers which are considered to be behind that link.
处于正在关闭的连接两侧的两台服务器都需要为被认为位于该链接后面的所有其他服务器发送一条斜视消息（到其所有其他服务器连接）。
Similarly, a QUIT message MAY be sent to the other still connected servers on behalf of all clients behind that quitting link. In addition to this, all channel members of a channel which lost a member due to the "split" MUST be sent a QUIT message. Messages to channel members are generated by each client's local server.
类似地，退出消息可以代表退出链接后面的所有客户端发送到其他仍然连接的服务器。除此之外，由于“拆分”而丢失成员的通道的所有通道成员都必须发送退出消息。发送给通道成员的消息由每个客户端的本地服务器生成。
If a server connection is terminated prematurely (e.g., the server on the other end of the link died), the server which detects this disconnection is REQUIRED to inform the rest of the network that the connection has closed and fill in the comment field with something appropriate.
如果服务器连接过早终止（例如，链路另一端的服务器死机），则检测到此断开连接的服务器需要通知网络其余部分连接已关闭，并在注释字段中填写适当的内容。
When a client is removed as the result of a SQUIT message, the server SHOULD add the nickname to the list of temporarily unavailable nicknames in an attempt to prevent future nickname collisions. See
当客户端由于一条短消息而被删除时，服务器应将该昵称添加到暂时不可用的昵称列表中，以防止将来的昵称冲突。看见
section 5.7 (Tracking recently used nicknames) for more information on this procedure.
第5.7节（跟踪最近使用的昵称）了解有关此程序的更多信息。
Numeric replies:
数字回复：
ERR_NOPRIVILEGES ERR_NOSUCHSERVER ERR_NEEDMOREPARAMS
ERR_NOPRIVILEGES ERR_nosuch服务器ERR_needmore参数
Example:
例子：
SQUIT tolsun.oulu.fi :Bad Link ? ; the server link tolson.oulu.fi has been terminated because of "Bad Link".
SQUIT tolsun.oulu.fi：链接错误；由于“坏链接”，服务器链接tolson.oulu.fi已终止。
:Trillian SQUIT cm22.eng.umd.edu :Server out of control ; message from Trillian to disconnect "cm22.eng.umd.edu" from the net because "Server out of control".
：Trillian SQUIT cm22.eng.umd.edu:服务器失控；来自Trillian的消息，由于“服务器失控”，导致“cm22.eng.umd.edu”与网络断开连接。
This group of messages is concerned with manipulating channels, their properties (channel modes), and their contents (typically users). In implementing these, a number of race conditions are inevitable when users at opposing ends of a network send commands which will ultimately clash. It is also REQUIRED that servers keep a nickname history to ensure that wherever a <nick> parameter is given, the server check its history in case it has recently been changed.
这组消息与操纵频道、频道属性（频道模式）及其内容（通常是用户）有关。在实现这些功能的过程中，当网络两端的用户发送最终会发生冲突的命令时，一些竞争条件是不可避免的。还要求服务器保留昵称历史记录，以确保无论在哪里给定<nick>参数，服务器都会检查其历史记录，以防最近发生更改。
Command: JOIN
Parameters: <channel>[ %x7 <modes> ]
*( "," <channel>[ %x7 <modes> ] )
Command: JOIN
Parameters: <channel>[ %x7 <modes> ]
*( "," <channel>[ %x7 <modes> ] )
The JOIN command is used by client to start listening a specific channel. Whether or not a client is allowed to join a channel is checked only by the local server the client is connected to; all other servers automatically add the user to the channel when the command is received from other servers.
客户端使用JOIN命令开始侦听特定通道。是否允许客户端加入通道仅由客户端连接到的本地服务器进行检查；当从其他服务器接收到命令时，所有其他服务器会自动将用户添加到通道。
Optionally, the user status (channel modes 'O', 'o', and 'v') on the channel may be appended to the channel name using a control G (^G or ASCII 7) as separator. Such data MUST be ignored if the message wasn't received from a server. This format MUST NOT be sent to clients, it can only be used between servers and SHOULD be avoided.
或者，可以使用控件G（^G或ASCII 7）作为分隔符，将频道上的用户状态（频道模式“O”、“O”和“v”）附加到频道名称。如果未从服务器接收到消息，则必须忽略此类数据。此格式不得发送到客户端，只能在服务器之间使用，应避免使用。
The JOIN command MUST be broadcast to all servers so that each server knows where to find the users who are on the channel. This allows optimal delivery of PRIVMSG and NOTICE messages to the channel.
JOIN命令必须广播到所有服务器，以便每个服务器知道在何处查找频道上的用户。这允许将PRIVMSG和NOTICE消息最佳地传递到通道。
Numeric Replies:
数字回复：
ERR_NEEDMOREPARAMS ERR_BANNEDFROMCHAN ERR_INVITEONLYCHAN ERR_BADCHANNELKEY ERR_CHANNELISFULL ERR_BADCHANMASK ERR_NOSUCHCHANNEL ERR_TOOMANYCHANNELS ERR_TOOMANYTARGETS ERR_UNAVAILRESOURCE RPL_TOPIC
ERR\u需要更多参数ERR\u来自Chan ERR\u Investended Only Chan ERR\u Bad Channel Key ERR\u Channel Is Full ERR\u Bad Chan Mask ERR\u Nos此类通道错误\u Tooman通道错误\u Tooman目标错误\u Unavail Resource RPL\u主题
Examples:
示例：
:WiZ JOIN #Twilight_zone ; JOIN message from WiZ
:WiZ JOIN #Twilight_zone ; JOIN message from WiZ
Command: NJOIN
Parameters: <channel> [ "@@" / "@" ] [ "+" ] <nickname>
*( "," [ "@@" / "@" ] [ "+" ] <nickname> )
Command: NJOIN
Parameters: <channel> [ "@@" / "@" ] [ "+" ] <nickname>
*( "," [ "@@" / "@" ] [ "+" ] <nickname> )
The NJOIN message is used between servers only. If such a message is received from a client, it MUST be ignored. It is used when two servers connect to each other to exchange the list of channel members for each channel.
NJOIN消息仅在服务器之间使用。如果从客户端接收到这样的消息，则必须忽略它。当两台服务器相互连接以交换每个通道的通道成员列表时，将使用该选项。
Even though the same function can be performed by using a succession of JOIN, this message SHOULD be used instead as it is more efficient. The prefix "@@" indicates that the user is the "channel creator", the character "@" alone indicates a "channel operator", and the character '+' indicates that the user has the voice privilege.
即使可以通过使用一系列连接来执行相同的功能，也应该使用此消息，因为它更有效。前缀“@@”表示用户是“频道创建者”，字符“@”单独表示“频道操作员”，字符“+”表示用户具有语音权限。
Numeric Replies:
数字回复：
ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL ERR_ALREADYREGISTRED
ERR_needmore参数ERR_nosuch channel ERR_已注册
Examples:
示例：
:ircd.stealth.net NJOIN #Twilight_zone :@WiZ,+syrk,avalon ; NJOIN message from ircd.stealth.net announcing users joining the #Twilight_zone channel: WiZ with channel operator status, syrk with voice privilege and avalon with no privilege.
：ircd.steave.net NJOIN#曙光地带：@WiZ，+syrk，avalon；来自ircd.steave.net的NJOIN消息宣布用户加入#暮光之城#频道：WiZ拥有频道运营商身份，syrk拥有语音权限，avalon没有权限。
The MODE message is a dual-purpose command in IRC. It allows both usernames and channels to have their mode changed.
模式消息是IRC中的一个两用命令。它允许更改用户名和频道的模式。
When parsing MODE messages, it is RECOMMENDED that the entire message be parsed first, and then the changes which resulted passed on.
在解析模式消息时，建议首先解析整个消息，然后传递导致的更改。
It is REQUIRED that servers are able to change channel modes so that "channel creator" and "channel operators" may be created.
要求服务器能够更改频道模式，以便创建“频道创建者”和“频道运营商”。
A the time of writing, the only current implementation of this protocol is the IRC server, version 2.10. Earlier versions may implement some or all of the commands described by this document with NOTICE messages replacing many of the numeric replies. Unfortunately, due to backward compatibility requirements, the implementation of some parts of this document varies with what is laid out. One notable difference is:
A在撰写本文时，该协议目前唯一的实现是IRC服务器，版本2.10。早期版本可能会实现本文档中描述的部分或全部命令，并使用通知消息替换许多数字回复。不幸的是，由于向后兼容性的要求，本文档的某些部分的实现会因布局的不同而有所不同。一个显著的区别是：
* recognition that any LF or CR anywhere in a message marks the end of that message (instead of requiring CR-LF);
* 确认消息中的任何LF或CR标志着该消息的结束（而不是要求CR-LF）；
The rest of this section deals with issues that are mostly of importance to those who wish to implement a server but some parts also apply directly to clients as well.
本节的其余部分将讨论对那些希望实现服务器的人来说最重要的问题，但有些部分也直接应用于客户机。
To detect when a connection has died or become unresponsive, the server MUST poll each of its connections. The PING command (See "IRC Client Protocol" [IRC-CLIENT]) is used if the server doesn't get a response from its peer in a given amount of time.
要检测连接何时死机或无响应，服务器必须轮询其每个连接。如果服务器在给定的时间内没有从其对等方获得响应，则使用PING命令（请参阅“IRC客户端协议”[IRC-Client]）。
If a connection doesn't respond in time, its connection is closed using the appropriate procedures.
如果一个连接没有及时响应，它的连接将使用适当的过程关闭。
When a server successfully registers a new user connection, it is REQUIRED to send to the user unambiguous messages stating: the user identifiers upon which it was registered (RPL_WELCOME), the server name and version (RPL_YOURHOST), the server birth information (RPL_CREATED), available user and channel modes (RPL_MYINFO), and it MAY send any introductory messages which may be deemed appropriate.
当服务器成功注册新的用户连接时，需要向用户发送明确的消息，说明：注册它的用户标识符（RPL_欢迎）、服务器名称和版本（RPL_YOURHOST）、服务器出生信息（RPL_已创建）、可用用户和通道模式（RPL_MYINFO），它可以发送任何被认为合适的介绍性信息。
In particular the server SHALL send the current user/service/server count (as per the LUSER reply) and finally the MOTD (if any, as per the MOTD reply).
特别是，服务器应发送当前用户/服务/服务器计数（根据LUSER回复），最后发送MOTD（如果有，根据MOTD回复）。
After dealing with registration, the server MUST then send out to other servers the new user's nickname (NICK message), other information as supplied by itself (USER message) and as the server could discover (from DNS servers). The server MUST NOT send this information out with a pair of NICK and USER messages as defined in "IRC Client Protocol" [IRC-CLIENT], but MUST instead take advantage of the extended NICK message defined in section 4.1.3.
在处理注册后，服务器必须向其他服务器发送新用户的昵称（NICK消息）、自身提供的其他信息（用户消息）以及服务器可以发现的信息（从DNS服务器）。服务器不得将此信息与“IRC客户端协议”[IRC-Client]中定义的一对尼克和用户消息一起发送出去，而是必须利用第4.1.3节中定义的扩展尼克消息。
Upon successfully registering a new service connection, the server is subject to the same kind of REQUIREMENTS as for a user. Services being somewhat different, only the following replies are sent: RPL_YOURESERVICE, RPL_YOURHOST, RPL_MYINFO.
成功注册新服务连接后，服务器将遵守与用户相同的要求。服务有所不同，只发送以下回复：RPL_YOURESERVICE、RPL_yourshost、RPL_MYINFO。
After dealing with this, the server MUST then send out to other servers (SERVICE message) the new service's nickname and other information as supplied by the service (SERVICE message) and as the server could discover (from DNS servers).
处理完此问题后，服务器必须向其他服务器（服务消息）发送新服务的昵称和服务提供的其他信息（服务消息）以及服务器可以发现的其他信息（从DNS服务器）。
5.3 Establishing a server-server connection.
5.3 正在建立服务器连接。
The process of establishing a server-to-server connection is fraught with danger since there are many possible areas where problems can occur - the least of which are race conditions.
建立服务器到服务器连接的过程充满了危险，因为有许多可能出现问题的领域，其中最不可能的是竞争条件。
After a server has received a connection following by a PASS/SERVER pair which were recognized as being valid, the server SHOULD then reply with its own PASS/SERVER information for that connection as well as all of the other state information it knows about as described below.
在服务器接收到一个连接，该连接后面跟着一个被识别为有效的PASS/server对之后，服务器应使用该连接的自身PASS/server信息以及它知道的所有其他状态信息进行回复，如下所述。
When the initiating server receives a PASS/SERVER pair, it too then checks that the server responding is authenticated properly before accepting the connection to be that server.
当发起服务器接收到PASS/server对时，它也会检查响应的服务器是否已正确验证，然后再接受与该服务器的连接。
Server links are based on a common protocol (defined by this document) but a particular link MAY set specific options using the PASS message (See Section 4.1.1).
服务器链接基于通用协议（由本文档定义），但特定链接可使用PASS消息设置特定选项（见第4.1.1节）。
If a server wishes to establish a compressed link with its peer, it MUST set the 'Z' flag in the options parameter to the PASS message. If both servers request compression and both servers are able to initialize the two compressed streams, then the remainder of the communication is to be compressed. If any server fails to initialize the stream, it will send an uncompressed ERROR message to its peer and close the connection.
如果服务器希望与其对等方建立压缩链接，则必须在选项参数中将“Z”标志设置为PASS消息。如果两台服务器都请求压缩，并且两台服务器都能够初始化这两个压缩流，则通信的其余部分将被压缩。如果任何服务器未能初始化流，它将向其对等服务器发送未压缩的错误消息并关闭连接。
The data format used for the compression is described by RFC 1950 [ZLIB], RFC 1951 [DEFLATE] and RFC 1952 [GZIP].
RFC1950[ZLIB]、RFC1951[DEFLATE]和RFC1952[GZIP]描述了用于压缩的数据格式。
Most servers implement various kinds of protections against possible abusive behaviours from non trusted parties (typically users). On some networks, such protections are indispensable, on others they are superfluous. To require that all servers implement and enable such features on a particular network, the 'P' flag is used when two servers connect. If this flag is present, it means that the server protections are enabled, and that the server REQUIRES all its server links to enable them as well.
大多数服务器都实施了各种保护措施，以防止来自不受信任方（通常是用户）的可能的滥用行为。在一些网络上，这样的保护是必不可少的，而在另一些网络上，这样的保护是多余的。为了要求所有服务器在特定网络上实现并启用此类功能，在两台服务器连接时使用“P”标志。如果此标志存在，则表示服务器保护已启用，并且服务器需要其所有服务器链接才能启用这些保护。
Commonly found protections are described in sections 5.7 (Tracking recently used nicknames) and 5.8 (Flood control of clients).
第5.7节（追踪最近使用的昵称）和第5.8节（客户防洪）描述了常见的保护措施。
The order of state information being exchanged between servers is essential. The REQUIRED order is as follows:
服务器之间交换状态信息的顺序至关重要。所需订单如下：
* all known servers;
* 所有已知服务器；
* all known client information;
* 所有已知的客户信息；
* all known channel information.
* 所有已知的频道信息。
Information regarding servers is sent via extra SERVER messages, client information with NICK and SERVICE messages and channels with NJOIN/MODE messages.
有关服务器的信息通过额外的服务器消息、带有NICK和SERVICE消息的客户端信息以及带有NJOIN/MODE消息的频道发送。
NOTE: channel topics SHOULD NOT be exchanged here because the TOPIC command overwrites any old topic information, so at best, the two sides of the connection would exchange topics.
注意：此处不应交换频道主题，因为TOPIC命令会覆盖任何旧的主题信息，因此连接的双方最多只能交换主题。
By passing the state information about servers first, any collisions with servers that already exist occur before nickname collisions caused by a second server introducing a particular nickname. Due to the IRC network only being able to exist as an acyclic graph, it may be possible that the network has already reconnected in another location. In this event, the place where the server collision occurs indicates where the net needs to split.
通过首先传递有关服务器的状态信息，与已经存在的服务器的任何冲突都会发生在第二台服务器引入特定昵称导致的昵称冲突之前。由于IRC网络只能作为非循环图存在，因此网络可能已经在另一个位置重新连接。在此事件中，服务器冲突发生的位置指示网络需要拆分的位置。
When a client connection unexpectedly closes, a QUIT message is generated on behalf of the client by the server to which the client was connected. No other message is to be generated or used.
当客户端连接意外关闭时，客户端连接到的服务器将代表客户端生成退出消息。不得生成或使用其他消息。
If a server-server connection is closed, either via a SQUIT command or "natural" causes, the rest of the connected IRC network MUST have its information updated by the server which detected the closure. The terminating server then sends a list of SQUITs (one for each server behind that connection). (See Section 4.1.6 (SQUIT)).
如果服务器-服务器连接关闭，无论是通过SQUIT命令还是“自然”原因，连接的IRC网络的其余部分必须由检测到关闭的服务器更新其信息。然后，终止服务器发送一个斜视列表（该连接后面的每个服务器一个）。（见第4.1.6节（喷射））。
All IRC servers are REQUIRED to keep a history of recent nickname changes. This is important to allow the server to have a chance of keeping in touch of things when nick-change race conditions occur with commands manipulating them. Messages which MUST trace nick changes are:
所有IRC服务器都需要保留最近昵称更改的历史记录。这对于允许服务器有机会在发生nick change race条件时通过命令操纵它们保持联系非常重要。必须跟踪更改的消息包括：
* KILL (the nick being disconnected)
* 杀死（断开刻痕）
* MODE (+/- o,v on channels)
* 模式（+/-o，v在通道上）
* KICK (the nick being removed from channel)
* 踢（从通道中移除刻痕）
No other commands need to check nick changes.
没有其他命令需要检查尼克更改。
In the above cases, the server is required to first check for the existence of the nickname, then check its history to see who that nick now belongs to (if anyone!). This reduces the chances of race conditions but they can still occur with the server ending up affecting the wrong client. When performing a change trace for an above command it is RECOMMENDED that a time range be given and entries which are too old ignored.
在上述情况下，服务器需要首先检查昵称是否存在，然后检查其历史记录以查看nick现在属于谁（如果有的话！）。这降低了出现竞争情况的可能性，但在服务器影响到错误的客户机的情况下仍然可能发生竞争情况。在对上述命令执行更改跟踪时，建议给出一个时间范围，并忽略太旧的条目。
For a reasonable history, a server SHOULD be able to keep previous nickname for every client it knows about if they all decided to change. This size is limited by other factors (such as memory, etc).
为了获得合理的历史记录，如果所有客户机都决定更改，服务器应该能够为其知道的每个客户机保留以前的昵称。此大小受其他因素（如内存等）的限制。
This mechanism is commonly known as "Nickname Delay", it has been proven to significantly reduce the number of nickname collisions resulting from "network splits"/reconnections as well as abuse.
这种机制通常被称为“昵称延迟”，它已被证明可以显著减少因“网络拆分”/“重新连接”以及滥用而导致的昵称冲突的数量。
In addition of keeping track of nickname changes, servers SHOULD keep track of nicknames which were recently used and were released as the result of a "network split" or a KILL message. These nicknames are then unavailable to the server local clients and cannot be re-used (even though they are not currently in use) for a certain period of time.
除了跟踪昵称更改外，服务器还应跟踪最近使用的昵称，以及由于“网络分裂”或KILL消息而发布的昵称。这些昵称对服务器本地客户端不可用，并且在一定时间内不能重复使用（即使它们当前未被使用）。
The duration for which a nickname remains unavailable SHOULD be set considering many factors among which are the size (user wise) of the IRC network, and the usual duration of "network splits". It SHOULD be uniform on all servers for a given IRC network.
昵称保持不可用的持续时间应考虑许多因素，其中包括IRC网络的大小（用户方面）和通常的“网络拆分”持续时间。对于给定的IRC网络，它在所有服务器上都应该是统一的。
With a large network of interconnected IRC servers, it is quite easy for any single client attached to the network to supply a continuous stream of messages that result in not only flooding the network, but also degrading the level of service provided to others. Rather than require every 'victim' to provide their own protection, flood protection was written into the server and is applied to all clients except services. The current algorithm is as follows:
通过一个由互连的IRC服务器组成的大型网络，连接到网络的任何单个客户端都很容易提供连续的消息流，这不仅会导致网络泛滥，还会降低提供给他人的服务级别。与要求每个“受害者”提供自己的保护不同，flood protection被写入服务器，并应用于除服务之外的所有客户端。目前的算法如下：
* check to see if client's `message timer' is less than current time (set to be equal if it is);
* 检查客户端的“消息计时器”是否小于当前时间（如果小于，则设置为相等）；
* read any data present from the client;
* 读取客户提供的任何数据；
* while the timer is less than ten (10) seconds ahead of the current time, parse any present messages and penalize the client by two (2) seconds for each message;
* 当计时器比当前时间提前不到十（10）秒时，解析任何当前消息，并对每条消息惩罚客户端两（2）秒；
* additional penalties MAY be used for specific commands which generate a lot of traffic across the network.
* 对于在网络上产生大量流量的特定命令，可能会使用额外的惩罚。
This in essence means that the client may send one (1) message every two (2) seconds without being adversely affected. Services MAY also be subject to this mechanism.
这本质上意味着客户端可以每两（2）秒发送一（1）条消息，而不会受到不利影响。服务也可能受此机制的约束。
In a real-time environment, it is essential that a server process does as little waiting as possible so that all the clients are serviced fairly. Obviously this requires non-blocking IO on all network read/write operations. For normal server connections, this was not difficult, but there are other support operations that may cause the server to block (such as disk reads). Where possible, such activity SHOULD be performed with a short timeout.
在实时环境中，服务器进程必须尽可能少地等待，以便公平地为所有客户端提供服务。显然，这需要在所有网络读/写操作上使用非阻塞IO。对于正常的服务器连接，这并不困难，但是还有其他可能导致服务器阻塞的支持操作（如磁盘读取）。在可能的情况下，应在短时间内执行此类活动。
Using the standard resolver libraries from Berkeley and others has meant large delays in some cases where replies have timed out. To avoid this, a separate set of DNS routines were written for the current implementation. Routines were setup for non-blocking IO operations with local cache, and then polled from within the main server IO loop.
在某些回复超时的情况下，使用Berkeley和其他公司的标准解析器库意味着大量延迟。为了避免这种情况，为当前实现编写了一组单独的DNS例程。使用本地缓存为非阻塞IO操作设置例程，然后从主服务器IO循环中轮询。
Although there are numerous ident libraries (implementing the "Identification Protocol" [IDENT]) for use and inclusion into other programs, these caused problems since they operated in a synchronous manner and resulted in frequent delays. Again the solution was to write a set of routines which would cooperate with the rest of the server and work using non-blocking IO.
尽管有许多ident库（实现“Identification Protocol”[ident]）可供使用并包含在其他程序中，但这些库以同步方式运行并导致频繁的延迟，因此会导致问题。同样，解决方案是编写一组例程，这些例程将与服务器的其余部分协作，并使用非阻塞IO工作。
There are a number of recognized problems with this protocol, all of which are hoped to be solved sometime in the near future during its rewrite. Currently, work is underway to find working solutions to these problems.
该协议存在许多公认的问题，所有这些问题都希望在不久的将来重写时得到解决。目前，正在努力找到解决这些问题的有效办法。
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 and clients and that information regarding them be updated as soon as it changes. It is also desirable to keep the number of servers low so that the path length between any two points is kept minimal and the spanning tree as strongly branched as possible.
人们普遍认为，当在大型竞技场中使用时，该协议的扩展性不够好。主要问题来自这样一个要求：所有服务器都知道所有其他服务器和客户端的信息，并且一旦这些信息发生变化，就会立即更新这些信息。还希望保持较低的服务器数量，以使任意两点之间的路径长度保持最小，并使生成树尽可能具有强分支。
The current IRC protocol has 4 types of labels: the nickname, the channel name, the server name and the service name. Each of the four types has its own domain and no duplicates are allowed inside that domain. Currently, it is possible for users to pick the label for any of the first three, resulting in collisions. It is widely recognized that this needs reworking, with a plan for unique names for nicks that don't collide being desirable as well as a solution allowing a cyclic tree.
当前的IRC协议有4种类型的标签：昵称、通道名称、服务器名称和服务名称。这四种类型中的每一种都有自己的域，在该域中不允许重复。目前，用户可以为前三个标签中的任何一个选择标签，从而导致冲突。人们普遍认为，这需要重新设计，需要一个不冲突的刻痕唯一名称计划，以及一个允许循环树的解决方案。
The idea of the nickname on IRC is very convenient for users to use when talking to each other outside of a channel, but there is only a finite nickname space and being what they are, it's not uncommon for several people to want to use the same nick. If a nickname is chosen by two people using this protocol, either one will not succeed or both will be removed by use of KILL (See Section 3.7.1 of "IRC Client Protocol" [IRC-CLIENT]).
IRC上昵称的概念非常方便用户在频道外相互交谈时使用，但昵称空间有限，因此，多人使用同一个昵称并不罕见。如果使用此协议的两个人选择了一个昵称，则其中一个昵称不会成功，或者两个昵称都将通过KILL删除（参见“IRC客户端协议”[IRC-Client]第3.7.1节）。
The current channel layout requires that all servers know about all channels, their inhabitants and properties. Besides not scaling well, the issue of privacy is also a concern. A collision of channels is treated as an inclusive event (people from both nets on channel with common name are considered to be members of it) rather than an exclusive one such as used to solve nickname collisions.
当前频道布局要求所有服务器了解所有频道、其居民和属性。除了不能很好地扩展之外，隐私问题也是一个值得关注的问题。频道冲突被视为包含性事件（来自频道上两个网络的具有共同名称的人被视为其成员），而不是用于解决昵称冲突的独占事件。
This protocol defines "Safe Channels" which are very unlikely to be the subject of a channel collision. Other channel types are kept for backward compatibility.
该协议定义了“安全通道”，这些通道不太可能成为通道冲突的主体。保留其他通道类型是为了向后兼容。
Although the number of servers is usually small relative to the number of users and channels, they too are currently REQUIRED to be known globally, either each one separately or hidden behind a mask.
尽管相对于用户和频道的数量而言，服务器的数量通常很小，但它们目前也需要在全球范围内被了解，要么单独存在，要么隐藏在掩码后面。
In some places within the server code, it has not been possible to avoid N^2 algorithms such as checking the channel list of a set of clients.
在服务器代码中的某些地方，无法避免N^2算法，例如检查一组客户端的通道列表。
In current server versions, there are only few database consistency checks, most of the time each server assumes that a neighbouring server is correct. This opens the door to large problems if a connecting server is buggy or otherwise tries to introduce contradictions to the existing net.
在当前的服务器版本中，只有很少的数据库一致性检查，大多数情况下，每台服务器都假定相邻的服务器是正确的。如果连接的服务器有缺陷或试图给现有网络带来矛盾，这就为大问题打开了大门。
Currently, because of the lack of unique internal and global labels, there are a multitude of race conditions that exist. These race conditions generally arise from the problem of it taking time for messages to traverse and effect the IRC network. Even by changing to unique labels, there are problems with channel-related commands being disrupted.
目前，由于缺乏独特的内部和全球标签，存在多种种族条件。这些竞态条件通常是由于消息穿越并影响IRC网络需要时间的问题而产生的。即使更改为唯一标签，与通道相关的命令也会出现中断的问题。
Servers only have two means of authenticating incoming connections: plain text password, and DNS lookups. While these methods are weak and widely recognized as unsafe, their combination has proven to be sufficient in the past:
服务器只有两种验证传入连接的方法：纯文本密码和DNS查找。虽然这些方法很弱，并且被广泛认为是不安全的，但它们的组合在过去已被证明是足够的：
* public networks typically allow user connections with only few restrictions, without requiring accurate authentication.
* 公共网络通常只允许用户连接，而不需要精确的身份验证。
* private networks which operate in a controlled environment often use home-grown authentication mechanisms not available on the internet: reliable ident servers [IDENT], or other proprietary mechanisms.
* 在受控环境中运行的专用网络通常使用internet上不可用的本地身份验证机制：可靠的身份验证服务器[ident]或其他专有机制。
The same comments apply to the authentication of IRC Operators.
同样的评论也适用于IRC运营商的身份验证。
It should also be noted that while there has been no real demand over the years for stronger authentication, and no real effort to provide better means to safely authenticate users, the current protocol offers enough to be able to easily plug-in external authentication methods based on the information that a client can submit to the server upon connection: nickname, username, password.
还应注意的是，虽然多年来没有对更强大的认证的实际需求，也没有真正努力提供更好的方法来安全认证用户，当前的协议提供了足够的功能，可以根据客户机在连接时可以提交给服务器的信息（昵称、用户名、密码）轻松插入外部身份验证方法。
Since the PASS and OPER messages of the IRC protocol are sent in clear text, a stream layer encryption mechanism (like "The TLS Protocol" [TLS]) could be used to protect these transactions.
由于IRC协议的PASS和OPER消息以明文形式发送，因此可以使用流层加密机制（如“TLS协议”[TLS]）来保护这些事务。
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月。
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[ABNF]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[IRC] Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol", RFC 1459, May 1993.
[IRC]Oikarinen，J.和D.Reed，“互联网中继聊天协议”，RFC 1459，1993年5月。
[IRC-ARCH] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810, April 2000.
[IRC-ARCH]Kalt，C.，“互联网中继聊天：架构”，RFC 28102000年4月。
[IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC 2812, April 2000.
[IRC-CLIENT]Kalt，C.，“互联网中继聊天：客户端协议”，RFC28122000年4月。
[IRC-CHAN] Kalt, C., "Internet Relay Chat: Channel Management", RFC 2811, April 2000.
[IRC-CHAN]Kalt，C.，“互联网中继聊天：频道管理”，RFC 28112000年4月。
[ZLIB] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996.
[ZLIB]Deutsch，P.和J-L.Gailly，“ZLIB压缩数据格式规范3.3版”，RFC 1950，1996年5月。
[DEFLATE] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, May 1996.
[DEFLATE]Deutsch，P.，“DEFLATE压缩数据格式规范1.3版”，RFC1951，1996年5月。
[GZIP] Deutsch, P., "GZIP file format specification version 4.3", RFC 1952, May 1996.
[GZIP]Deutsch，P.，“GZIP文件格式规范版本4.3”，RFC1952，1996年5月。
[IDENT] St. Johns, M., "The Identification Protocol", RFC 1413, February 1993.
[识别]圣约翰，M.，“识别协议”，RFC 1413，1993年2月。
[TLS] Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246, January 1999.
[TLS]Dierks，T.和C.Allen，“TLS协议”，RFC 2246，1999年1月。
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编辑功能的资金目前由互联网协会提供。