Internet 交换交谈：服务器协议(RFC2813——Internet Relay Chat: Server Protocol)

Internet 交换交谈：服务器协议
(RFC2813——Internet Relay Chat: Server Protocol)

备忘录的状态：
这个备忘录提供了internet群体的信息。它并没有详细说明每一种internet的标准。这个备
忘录的适用范围是无拘束的。
版权通告：
copyright（c）internet Society (2000).  All Rights Reserved.
摘要：
以客户端——服务器为模板，irc协议允许服务器连接到另外的有效形成的网络。
本文档定义了服务器用于互相交流的协议。它原来只是一个客户端协议的超集，但是已经发
展的不同了。
正式的出版是在1993年5月作为rfc的一部分。从那时以来，大多数的为了使协议更加标
准的改变都可以在这篇文章中找到。更加标准的协议已经允许出现在万维网中，以使它可以
保持不断的更新，并且有别于原来的版本。

目录
1绪论	2
2．全球数据库	3
2．1服务器	3
2．2客户端	3
2．3信道	4
3．irc服务器的说明	4
3．1概要	4
3．2 特征代码	4
3．3信息	5
3．4数字回复	6
4信息细节	6
4．1连线注册	7
4．2信道操作：	11
4．3模式信息	13
5．执行细节	13
5．1连接失效	13
5．2接受客户端到服务器的连接	13
5．3终结一个服务器到服务器的连接	14
5．4中断服务器与客户端的连接	16
5．5中断之间的连接	16
5．6跟踪呢称变化	16
5．7跟踪最近使用过的用户名	17
5．8客户端的溢出控制	17
5．9无模块查找	17
6．当前问题	18
6．1可靠性	18
6．2标志	18
6．3运算法则	19
7．安全考虑	19
7．1证明	20
7．2完整性	20
8．相关支持和联接	20
9.鸣谢：	20
10．参考书目：	21
11．作者地址	22
12．版权说明	22
致谢：	23

1绪论

这篇文章是为了那些开发irc服务器的人而做的，但同时对那些以irc为工具的人也
是有用处的。

服务器提供了以《irc：体系》中定义的同时讨论为基础的三项服务：客户端位置（由
客户端协议[irc客户端]定义），信息传递（由这篇文章中的服务器协议定义），和信道的建设
主机与会议协商（详细条款请看[irc——信道]）。

2．全球数据库

尽管irc协议定义了一些公平的发散式的模式，但是每一个服务器保持了一个关于整
个irc网络的“全球状态数据库”。这个数据库理论上说对所有服务器来说都是独一无二的。

2．1服务器

服务器可以通过申请一个最长63个字母的独一无二的名字。查看协议的语法条款[3。
3。1]来确定那些字母在名字中是可以使用的，那些是不能使用的。

每一个服务器都是理论上都是被其他服务器所了解的，但是有一种可能，定义一个
假的主机名字联合其他服务器使用它的名字。在HOSTMASK的区域里，所有服务器都有一
个和HOSTMASK名字相符的名字，在HOSTMASK区域外的服务器，即使有一个跟
HOSTMASK一样的名字，也不可以登陆到irc中去。而区域外的服务器对于区域内的服务
器的状态则一无所知，相反的，它们被赋予一个HOSTMASK的名字。

2．2客户端

对于每一个客户端，所有的服务器都必须有以下信息：一个网络中独特的姓名标志
（它们的形式由客户端来决定），以及一个正在与客户端连接的服务器。

2．2．1用户

每一个用户有个独特的最长为9个字母的用户名。查看协议上的语法规则[3。3。1]
来判断什么是能够使用的，那些不能使用。作为用户名的附加段，每个服务器都要对用户保
留有以下信息：用户正在连接的服务器名，用户在该服务器上的用户名，以及服务器连接的
客户端名。

2．2．2服务

每一项服务都可以通过用户名和服务器名来区别与其他服务。用户名最多允许9个
字母。查看协议上的语法规则[3。3。1]来判断那些字符可以使用，那些不行。用来标志服
务名称的服务器名就是这项服务连接的服务器名。作为这项服务的补充，所有服务器必须都
了解这种服务形式。

服务通过它们特有的标志符形式来区别于用户名，但是更多的较重要的服务和用户
名对服务器的权限是不同的：服务可以调用服务器中保留的部分甚至全部全球数据库中的信
息，但是对它们的限制就更加严格（详见irc客户端协议）并且不允许加入信道。最后一点，
服务并不总是服从与防火墙的5。8中有详细叙述。

2．3信道

就象服务一样，信道也有它的相应规定[irc ——信道]并且没有必要让所有服务器了
解。当一个信道的存在被一个服务器所了解，服务器就一定要记录信道成员的轨迹和信道模
式。

3．irc服务器的说明

3．1概要

这里描述的协议是用来给服务器和服务器相连接的。关于客户端与服务器的连接，
请看irc——客户端协议规则。

但是，对于客户端的连接有比服务器之间连接更多的规定（但是通常别认为是不可
靠的）。

3．2 特征代码

这里并没有说明那些特殊的特征代码。协议是以一个由8个字节的代码组成的集合
构成的。每一条信息都可能由若干个这种8位字节的代码组成。但是，一些8个字节的代码
含义是用来做控制代码的，就象信息的分割符。

不管是什么样的8字节协议，分割符和关键字都是协议用来进行美国——ASCII码
的终端连接和远程登录连接。

因为irc是由北欧方面产生的，某些地区，字母{  }  |  ^被认为是等同于小键盘上
的{  }  \  ~字母。这在确定用户名和信道名是否相同时，回出现严重问题。

3．3信息

服务器和客户端发送各自的信息，当然，可能收到回复，也可能没有回复。大多数
服务器之间的联系不需要回复，因为大多数时候服务器会为客户端准备好工作进程。

每一条irc的信息都由三个主要部分组成：前缀（可以省略），命令，和命令参数（最
多15个字符）。前缀，命令和所有参数被一个ASCII码空格（0*20）隔开。

前缀是以一个ASCII码中的冒号（： 0*3b）来标识的，它必须是信息的第一个字
符。冒号和前缀之间不可以有空格。前缀是服务器用来标识信息的来源的。如果信息中的前
缀丢失，它就会被默认成是从它刚刚连接并接收到信息的那个服务器。客户端自己互相在发
送信息时，不应该使用前缀；如果它使用了，唯一有效的前缀就是正在使用这个客户端的已
经注册过的用户名。

当一个服务器接收信息时，它必须通过前缀来判别信息的来源。如果在服务器的中
央数据库中找不到前缀，那它一定是被丢弃了，并且如果这个前缀指明的服务器是一个不知
名的服务器，那么这个信息传来的的连接将被删除。在这种情况下删除连接是有点过分，但
是保持网络服务的严谨与制止未来可能发生的问题却是必要的。另外一种常见的问题：前缀
指向的信息来源是与实际不同（典型情况：来源指向的是另一个连接而不是信息来源。）如
果信息被服务器接收，而来源指向客户端，一条删除客户端的信息就会发送到各个服务器中
去。另外一种情况，信息由来的那个连接就应该会在客户端被删除，并且一定要在服务器内
删除。不管什么情况，这条信息都要被删除。

命令一定要是有效的irc命令或者是用ASCII码描述的三位字节。

Irc信息通常是以CR-LF（换行和回车）为结束的成行的命令，这些信息的长度不可
以超过512个字节，其中包括CR-LF。因此，命令和它的参数最多只能有510个字节。没
有可以用来延长命令行的方法。查看第5部分可以找到有关当前命令的执行。

3．3．1扩展格式的信息

有关协议的信息一定要从一系列的8位字节中提取出来。现在的办法是标志出两个
字符，CR，LF，用来提取信息。空信息通常被默默忽略掉,这就显示出CR-LF在预防额外
问题中的作用。

有效的信息被分成：若干部分（前缀），（命令），和参数表（参数）。

扩展BNF对这方面的表述可以在irc——客户端协议中找到[irc--客户端]。

附加前缀（[“！”user“@”host]）决不可以在服务器之间的连接中使用，它的使用
范围只有服务器到客户端的连接，这样，客户端即使不需要额外的疑问而直接得到信息的来
源。

3．4数字回复

绝大部分发送去服务器的信息是有一定顺序的。最普通的回复是数字回复，既可以
用来回复错误，也可以普通回复。数字回复作为一种信息，一定要包括有前缀，三个阿拉伯
数字，和回复的目标对象客户端不允许发送数字回复，服务器如果接收到这样的回复，就会
自动删除掉。在所有其他关系中，数字回复就象是一个普通的信息，除非它的关键字是用三
个阿拉伯数字组成的，而不是字符串。一些另类的数字回复可以在irc——客户端协议中找
到[irc——客户端]。

4信息细节

所有irc的服务器与客户端认可的信息都在irc---客户端协议中详细介绍过了。

当出现 错误：没有此服务器时，那就意味着目标信息没有被找到。如果是命令发
生这种错误，服务器决不可以发送回复。

客户端所连接的服务器要分析整个信息，回复适当的错误。如果服务器在分析信息
时，遇到一个致命的错误，那么一个错误的回复信息就会被送回，并且终止分析。致命的错
误通常是由错误命令引发的，目标来源对于服务器来说可能是未知的（服务器，客户端，信
道符合这个类型），也可能是不正确的参数，或者错误的权限。

如果全部参数都存在，那么每一个都必须检查它是否能够有效的并且合适的送回到
客户端。如果信息中使用的参数表是用逗号来做分隔符的，那么就要发送回复来得到每一条
条款。

在下面的例子中，有些信息是以完整形式给出的：

：姓名 命令参数菜单

这样的例子是用“姓名”来标志信息的，在服务器间来回的传递，它的本质是信息
的原始发送者的名字，这样，即使远程服务器也可以找到正确的路径。

描述从客户端到服务器的连接细节的信息在irc——客户端协议中有详细描述[irc—
—客户端]。下面文章的一些章节就是对这些文章的应用，它们对那些只描述服务器之间连
接和信息的执行的信息是个附加。在这里介绍的信息都是只用来做服务器之间连接的。

4．1连线注册

这里介绍的命令是用来向另外一个irc服务器连线注册的。

4．1．1密码信息

命令：路径
参数：<密码><提示信息><标志位>[<选项>]

PASS路径命令被用来设置一个连接密码。密码一定要在连线注册前设定。这就意
味着在PASS命令一定要在任何服务器命令之前。只有第一个PASS命令会被连接认可。

如果是从客户端接收到的信息，那么最后的三个参数就会被忽略（e。g服务器的一
个用户）。只有当它们是从服务器发送来得时候，它们才相互关联。

变量参数至少要有四个字节，最多有十四个字节。开始的四个字节一定要是阿拉伯
数字，简要说明协议中的变量，就是已被服务器获知的那些信息。这篇文章所描述的就是2。
1。0版本的协议，通常被标志成“0210”。剩下的可供选择的字母是执行时所要依靠的，并
且需要描述软件的版本号。

标志位参数是一个字符串，最长可以包括100个字符。它是由两个副串组成的，中
间以一个“|”分开（%x7c）。如果是现在，那么这第一个副字符串一定要是执行的名字。涉
及到的执行（请看第8部分，当前的支持与可靠性）使用irc字符串。如果要写另外一个执
行命令，就需要一个标志符，并且这个标志符应该是在RFC上已注册的。两个副串是可选
择的，但是字符“|”是必须的。这个字符不可以出现在任何一个副串中。

最后，最后的参数，<选项>,是用来做连接设置的。协议定义过的唯一选项，连接压
缩（使用字母“Z”），和一个误差保护位（使用字母“P”）。参看5。3。1。1（压缩的服务
器与服务器连接），5。3。1。2（自动保护位），分别相对与这些选项的更多信息。

数字回复：

错误 需要更多参数                 错误 已注册

例子：

PASS 更多的密码字数  0210010000  irc |abgh$z

4．1．2服务器信息

命令：服务器
参数：〈服务器名〉〈希望数值〉〈标记〉〈信息〉

这条命令是用来注册一个新的服务器用的，新的连接中，它作为以一个服务器的身
份向它的同行介绍自己。这个命令也可以用来在整个网络中传递服务器的信息。当一个新的
服务器连接到网上，它的相关信息就一定要遍告整个网络。

〈信息〉参数可以包含空格符。

〈希望数值〉是用来告知服务器其他服务器在那里，距离多远。当地的服务器会被
赋为0，每经过一个，值就增加。用一个完整的服务器列表，你可以建立一个完整的服务器
树型网络图，当然，如果有HOSTMASK建立的话，这就行不通了。

〈标志〉参数是服务器用来做标志的无符号数。这个标志符后来被用来表示一个服
务器，在传递服务器之间的用户名和服务信息时。服务器的标志符只有在点对点的服务器之
间连接时才有效，并且对于那个连接是独特的。并不是全球通用的。

服务器信息只有在连接注册时才被允许，或者是连接到其他服务器，在那种情况下，
服务器信息是介绍一个新服务器。

大多数错误都是在服务器信息返回时发生的，原因就是终端服务器中断了连接（目
标服务器）。由于这种事件的严重性，错误回复通常是返回“错误”命令，而不是数字回复。

如果服务器信息被分析，并且它试图向一个已经了解了的服务器介绍服务器时，那
么这个连接，从消息收到的那方，就一定要被关闭（按照正规的顺序）。因为一条通往那个
服务器的路线已经形成，并且会破坏已经形成的irc树型网络。在一些情况下，也可以由发
送消息的那一方停止信息。必须声明的是：这种错误也可能由于服务器的第二次启动产生，
协议中产生了这种问题是不可能修复的，通常需要人类的参与。这种错误是非常阴险的，因
为只要irc服务器中一个被孤立，就会产生这种错误。如果两个服务器中的一个被孤立，那
么连接就不能连接。

数字回复：

错误——已注册

举例
SERVER test.oulu.fi 1 1 :Experimental server ; New server
test.oulu.fi就是在介绍服务器本身，并且试图注册。
:tolsun.oulu.fi SERVER csd.bu.edu 5 34 :BU Central Server ; Server
                       tolsun.oulu.fi是到5步远的csd.bu.edu连接。当连接到csd.bu.edu
时，参数34将被tolsun.oulu.fi调用，来介绍新的用户或服务。

4．1．3呢称
      命令：呢称
      参数：<呢称><希望值><用户名><主机><服务器token><模式><真实姓名>

这种形式的呢称一定不会被使用者接收。但是，它可以作为呢称/使用者的替代，来
向其他服务器介绍新的使用者，刚刚加入irc中的。

这个信息是由三条不同的信息组合成的：呢称，用户，模式[irc——客户]。

希望值这个参数是服务器用来描述使用者距离服务器主机距离的。本地的连接希望值
是0。每次通过一个服务器，希望值就增加。

服务器代码这个参数替代了原来的用户中的参数服务器名。（查看4。1。2可以找到
更多资料）

  例子：
  NICK syrk 5 kalt millennium.stealth.net 34 +i :Christophe Kalt
                                        新的使用者有这个呢称“syrk”，用户名“kalt”，
从主机millennium.stealth.net连接到服务器       
34 ("csd.bu.edu" 根据前一个例子).

：krys NICK syrk                    ：呢称信息的另外一种形式，就象irc客户端协
议中定义的一样。在服务器之间使用：用户
krys把他的名字改为syrk。

4．1．4服务信息

命令：服务
参数：<服务名称><服务代码><分类><类型><希望值>〈信息〉

服务命令是用来介绍一条新服务。这种形式的服务信息不可以被客户端接受（不管有没有注
册）。但是，它一定要使用于服务器通告于其他服务器，有新信息假如irc网络服务。

服务代码是用来鉴别服务连接到的服务器。（详情请看4。1。2关于服务器代码）

希望值参数是被服务器用来测量，服务与服务器之间距离的。当地连接的希望值是0。每经
过一个服务器，希望值就加一。

分类参数被用来指定服务的明显度。服务只被有着与分类参数相符的服务器了解。因为与之
相匹配的服务器了解了这条服务，在服务器与提供服务的服务器之间的路径，一定要可以分
解成服务器名。没有任何限制时，就使用符号‘*’。

类型参数现在保存下来是为了将来使用。

数字回复：ERR_ALREADYREGISTRED            ERR_NEEDMOREPARAMS
           ERR_ERRONEUSNICKNAME
           RPL_YOURESERVICE                RPL_YOURHOST
           RPL_MYINFO
例子：
服务 [e-mail] 9*.fr 0 1:法文r在服务器9中注册，在通知其他服务器。这条服务只有服务
器的名字里有fr时才有效。

4．1．5退出
命令：退出
参数：

客户端的会议通常是以一个退出命令作为结束的。如果客户端发送出退出信息，那么服务器
一定要终止跟客户端的连接。如果退出信息发送出，这个就会被发送出，用来取代默认的信
息，通常是用户名或者服务名。

当网络中断（详情请看4。1。6）发生时，退出信息是由相关的两个服务器的名字组成的，
中间用一个空格分开。第一个名字，是还在连接的那个服务器的名字，第二个是已经断开的
服务器名字，或者是那个客户端连接到的服务器。
<Quit Message> =  ":" servername SPACE servername

由于"quit message"对“netsplits”来说有一个特殊意义，服务器不允许客户端使用“quit 
message”，用上面的形式。

如果，由于某些原因，在还没有任何“quit message”客户端连接被终止了（客户端停止，
或者是发生断线），服务器需要用一些信息来填补退出信息，这些信息导致了中断的发生。
比较常见的，通常报告系统特殊错误。

数字回复：
         无。

例子：:WiZ QUIT :Gone to have lunch   ; Preferred message format

4．1．6服务器退出信息

命令：SQUIT
参数：<服务器><注释>
它有两种用法：：

第一（详情请看Internet Relay Chat: Client Protocol）允许操作员断开当地的或者远程的连接。
这种形式的信息也是服务器用来断开连接的最后手段。

第二种用法被用来通知其他服务器，当网络中断发生时。换句话，就是告诉其他服务器有那
些服务器坏了。如果一个服务器想终止与其他服务器的连接，它就必须向其他服务器发送
SQUIT信息，用其他服务器名做参数，就是它想关闭连接的哪个。

注释通常用来存放那些可以放错误或者是相似信息的服务器。

被断开的两端的服务器都需要发出一个SQUIT信息（给所有与它们连接的服务器），给那些
连接背后的服务器。

同样的，QUIT信息可能被发送给其他还连接的服务器，为了所有连接的客户端。作为补充，
这条已经损失了一个成员的信道上的所有成员,都必须发送一个退出信息。信息是由这些成
员的服务器发出的。

如果一个服务器的连接断开了（另外一端的服务器死机了），那么监测到这个断开的服务器
就需要通知其他网络，连接已断开并且用恰当的文字填充注释。

当客户端由于SQUIT被中断，服务器就要把这个客户端的呢称加入已断开的名单，防止发
生呢称冲突。详情看5。7（跟踪最近使用的呢称）。

数字回复：
ERR_NOPRIVILEGES                ERR_NOSUCHSERVER
           ERR_NEEDMOREPARAMS
例子：SQUIT tolsun.oulu.fi :Bad Link ?  ;服务器tolsun。Oulu。fi由于错误连接被中断。
:Trillian SQUIT cm22.eng.umd.edu：Server out of control ;从trillian发送出的信息由于
服务器失去控制而被中断。

4．2信道操作：

这组信息和操作信道有关，他们的道具（信道模式），并且他们的内容（典型用户）。在这些
道具中，大量的关于信道状态是不可避免的，尤其是当使用者对反对断开作出连接的时候。
同时，它需要服务器保留一个呢称记录，来确定呢称在那里使用过，只要资料一更改，服务
器就会检测历史记录。

4．2．1加入信息
命令：JOIN
参数：<channel>[ %x7 <modes> ]
*( "," <channel>[ %x7 <modes> ] )
JOIN命令是客户端用来加入一个特殊信道时使用的。客户端是否被允许加入，就只由当地
的服务器鉴定产生结果：其他服务器只是单纯的填加这个用户，当它们收到这条信息时。

通常，用户在信道上的状态（信道模式0，o，v）可以加在信道名后面，用g分隔开。如果
这种信息不是被服务器接收到，那么这种数据通常是被忽略的。这种格式也不可以发送给客
户端，它只能用在服务器之间传输，并且应该被消除。

JOIN命令一定要通知所有服务器，因此服务器才知道如何找到信道上的用户。它允许理想
的PRIVMSG和NOTICE信息在信道上传输。

数字回复： ERR_NEEDMOREPARAMS              ERR_BANNEDFROMCHAN
           ERR_INVITEONLYCHAN               ERR_BADCHANNELKEY
           ERR_CHANNELISFULL                 ERR_BADCHANMASK
           ERR_NOSUCHCHANNEL                ERR_TOOMANYCHANNELS
           ERR_TOOMANYTARGETS               ERR_UNAVAILRESOURCE
           RPL_TOPIC
例子：
   :WiZ JOIN #Twilight_zone        WIZ的JOIN 信息

4．2．2N加入信息
命令：NJOIN
参数：<channel <nickname>
                         *( "," [ "@@" / "@" ] [ "+" ] <nickname> )

NJOIN命令只用在服务器之间。如果接受到这种信息是从客户端发送的，信息就会被忽略。
它主要用于服务器之间交换用户及信道信息。

尽管如此，同样的函数用JOIN也可以完成，但这条信息可以用来取代JOIN，并且比它更
有效。前缀“@@”表明用户是信道的创造者，符号“@”表明了信道的操作者，符号“+”
表明用户有权发声。

数字回复：ERR_NEEDMOREPARAMS              ERR_NOSUCHCHANNEL
           ERR_ALREADYREGISTRED
例子：:ircd.stealth.net NJOIN #Twilight_zone :@WiZ,+syrk,avalon
从ircd.stealth.net发送来的NJION信息说明用户正在加入#Twilight_zone channel: WiZ并且表
明了信道操作者的状态，syrk有发声权利，而avalon没有。

4．3模式信息
MODEL信息是irc中双重意义的命令。它允许用户名和信道的模式改变。

当解析MODEL信息时，建议先解析完整的信息，然后在进行改变。

这里需要服务器来改变信道模式，所以“channel creator”和“channel operator”都可以建立。

5．执行细节

在写入时，这个协议当前执行的就是irc服务器，version 2。1。0。早期的版本也可以执行
这篇文档中介绍的这些命令，但要注意数字回复的位置都改变了。不幸的是：预计向后兼容，
但是这篇文章中的某些操作在老版本中会被认为是不规则的。一个很明显的不同：
*信息中出现的LF和CR都标志着这条信息的结束。（取代了原来的CRLF）

文章余下的部分对于那些想要运行服务器的人来说相当重要，但当中的某些部分对服务器一
样适用。

5．1连接失效

想要监测什么时候一个连接已经中断，服务器一定要检测它的每一个连接。命令PING（看
irc客户端协议）可以被使用，如果其他服务器没有在指定时间回复信息。

如果一个连接没有及时回复，那么这个连接就会被用适当的程序终止。

5．2接受客户端到服务器的连接

5．2．1用户

如果服务器成功的注册了一个用户的连接，那么它就需要发送一条关于用户的明确的状态信
息：用户特征，被用来注册的那个（RPL——WELCOME），服务器名字和版本号（RPL—
—HOST），服务器产生信息（RPL——CREATED），可以信赖的用户和信道模式（RPL——
MYINFO），并且可以发送任何被认为是合理的信息。

特别的，服务器应该发送当前的用户/服务/服务器的值（作为每一个LUSER的回复），最后
加上MOTD（如果有的话，作为MOTD的回复）。

注册完成后，服务器一定要向其他服务器发送刚刚注册好的用户名（NICK 信息），以及其
他信息（USER 信息）就象它自己的一样，并且象服务器发现的那样（从DNS服务器发出）。
服务器不可以发送这种信息，成对的USER和NICK信息（就象irc——CLIENT中定义的
那样），但是一定要用扩展的NICK来替代，就象4。1。3中定义的那样。

5．2．2服务

在成功的注册了一个服务器的连接之后，服务器对于用户来说，就象是必须的。服务则有些
须不同，只有下面的信息被发送：
RPL_YOURESERVICE, RPL_YOURHOST, RPL_MYINFO

处理完这个，服务器一定要向其他服务器发送信息（SERVICE 信息），主要是服务的名字
和其他提供的信息（SERVICE 信息），还有服务器可以发觉的（从DNS服务器）。

5．3终结一个服务器到服务器的连接

终结一个服务器到服务器的连接是有危险的，因为这中间可能发生错误的地方太多了，——
最起码也会有信道状态问题。

当服务器接收到一个连接跟随着一个PASS/SERVER，被认为是可以信赖的，服务器就会回
复它自己的PASS/SERVER的信息，作为对那条信息的回复，就象是下面描述的一样。

当开始的服务器接收到一个PASS/SERVER信息时，在确认那个服务器的连接是否可信之
前，要先检测那个服务器的回复是否合理。

5．3．1连接设置

服务器连接是以一个普通的协议为基础的（这篇文章中定义的），但是对于特殊的连接，就
会有特殊的设置，用PASS信息（请看4。1。2）。

5．3．1．1压缩的服务器到服务器的连接

如果服务器想中断与其他服务器之间的连接，它就必须设置Z符号在PASS信息的参数前。
如果两个服务器需要压缩，并且两个服务器都能够初始化压缩串，那么剩余的连接都可以被
压缩。如果其中一个服务器不能初始化，那就会发送一个不能初始化的错误信息给另外一个
服务器，并且切断连接。

用于压缩的数据形式在IRC——1950（ZLIP），IRC——1951（DEFLATE），IRC——1952
（GZIP）中描述的那样。

5．3．1．2反对滥用保护

大多数服务器执行各式各样的保护，来反对可能滥用的行为（典型用户）。在一些网络工作
中，这些保护是必不可少的，但在其他工作中，则是多余的。为了所有服务器都能够执行，
并且以这样的形式来完成网络服务。“P”标志位通常在两个服务器连接中使用。如果这个
标志位现在存在，就说明服务器的保护是激活的，并且那个服务器需要所有与它相连的服务
器都激活此项。

建立普通的保护在5。7中描述（跟踪当前用户的呢称）和5。8（客户端的防火墙）。

5．3．2在连接是改变状态信息

在服务器之间改变状态信息的顺序是必需的。格式如下：
*众所周知的服务器
*众所周知的客户端信息
*众所周知的信道信息

关于服务器的信息是被额外的服务器信息发送的，客户端信息包括了呢称和服务，信道信息
包括NJOIN/MODE信息也一起被发送。

注意：信道标题在这里不可以被改变，因为标题会覆盖掉所有旧的标题信息，所以，最起码
要服务器两端一起修改。

通过一开始就传输的有关服务器的状态信息，任何已经出现的有关服务器的冲突就会发生，
在呢称冲突（由于另外的服务器也有相同的呢称）之前。归功于IRC网络服务只可以以非
循环图的形式表现，所以也有可能网络服务在其他的地方已经从新连接过了。在处理这种事
情时，服务器冲突发生的地方，就以为这网络要分裂了。

5．4中断服务器与客户端的连接

当一个客户端连接出乎意料的中断了，服务器就会在客户端上产生一个QUIT 信息。其他
的命令都不用。

5．5中断之间的连接

如果服务器到服务器之间的连接被中断了，不管是SQUIT或者“NATRUAL”原因，剩下
的IRC网络服务就一定由检测到中断的那个服务器来休正。中断的那个就要发送一个SQUIT
清单。（给这个连接之后的每一个服务器一个）（请看4。1。6）。

5．6跟踪呢称变化

所有IRC服务器都必须保存一份记录，有关呢称改变的。这很重要，尤其是对于服务器可
以在呢称改变是，用适当的命令来与它们保持联系。跟踪的信息：

*KILL（该呢称断线）
*MODE(+/- o,v on channels)
*KICK（该呢称被从信道上消除了）

其他命令不需要检查呢称改变。

在上述情况中，服务器要先检测现有的呢称，然后查看历史记录，那个呢称现在属于谁？这
就降低了出错的可能性，但是它还是会在服务器终止一个错误的客户端是发生。当实现一个
改变对上述命令的跟踪时，建议限定历史的时间范围，太旧的记录可以被忽略。

对于一个合情合理的历史记录，服务器就应该保存客户端以前的名称，如果它们想改变名称
的话。这种状况会有其他因素制约。（比如记忆体，等等）

5．7跟踪最近使用过的用户名

这种体制通常被认为是“NICK DELAY”，它已经被证实，可以减少用户名冲突的数量，就
是那些主要由网络分裂和再登陆引起的。

保持跟踪呢称的改变，服务器要随时跟踪最近使用过的用户，并且随时释放那些被网络分裂
和KILL信息加载过的用户名。这些呢称就会变成不可信的，对于服务器当地的客户端。并
且在一端特定的时间里不能被使用。

呢称不可使用的时间限制，是受许多因素影响的，这些因素大多与IRC网络服务和普通的
网络分裂的时间有关。对于所有服务器来说，这是个规矩。

5．8客户端的溢出控制

由于太多的网络服务连接IRC 服务器上，对于每一个客户端来说，提供连穿的信息是非常
容易的，不仅仅是溢出,同时也会降低对其他服务器服务的级别。不是对每个受害人都提供
保护，溢出保护被写进服务器，被应用到客户端，除了服务。当前采用的法则运算是这样的：

*检查客户端的信息记时器比当前的时间少（设置成相等看看是否相同）。

*从客户端读取信息

*如果记时器比当前的少10秒，分析当前信息，然后把每个信息都向后2秒。

*附加处罚可能用来一些特殊的信息，可以产生很多通过网络传输的输入。

5．9无模块查找

在一个真实时间的环境里，所必须的是，服务器进程做最少时间的等待，所以所有客户端服
务都是平等的。很明显，这就需要在读/写操作上执行无模块的IO。对于那些普通的服务器
连接，这并不难，但是还有些其他相关的操作，可能会导致服务器停止（比如读盘）。在那
些可能的地方，这种行为可能会导致时间超标。

5．9．1主机名查询（DNS）

使用标准的Berkeley伯克利资料库，或者其他的资料库，就意味着在某些事情中会产生大
量的中断，而且会出现回复暂停。为了防止这种事情发生，一个独立的DNS程序被写入了
为了当前的执行。程序被安装，连同当地的高速缓冲存储器一起，就可以达到无模块化的
IO操作，然后就可以被拖进主服务器IO回路。

5．9．2用户名（IDENT）查询

尽管有很多用户名资料库（执行见证协定[IDENT]），可以使用，并且包含了很多的其他的
程序，这就导致了问题的发生，因为它们以相同的方式操作，并且导致了很多频繁的延迟。
同样，解决方法就是写一个程序，它可以同其他服务器连接，并且可以使用NON-BLOCKING 
IO。

6．当前问题

这个协议中公认的问题就有很多，所有的问题都期待着能在不久的将来被解决。现在，这项
工作已经在进行中了。

6．1可靠性

广泛认同：如果协议在一个很大的地区使用，那它就不能很好的工作。最大的问题就是服务
器需要了解所有其他服务器和客户端的信息，只要它们一改变，就随之改变。保持服务器数
量低也是个有效的办法，只要如此，两点之间的距离就不会太长，生成的树型网络也就有效
的多。

6．2标志

当前的IRC协议有四个类型的标志：用户呢称，信道名，服务器名，服务名。每一个都有
自己的使用范围，并且在自己的范围里，没有复本。当前，如果用户把其中一个当作另外三
个，就会引起冲突。广泛的认同：这项操作需要重新设计，有这样一个计划：每一个标志有
它们自己的特殊的名字，就象解决循环树问题一样。

6．2．1呢称

IRC中关于呢称的方法对于用户来说，是非常方便的，尤其是在信道外聊天时。但是，存储
呢称的空间是有限的，并且一直存在，几个人用一个名字是不可以的。如果两个人选了一个
名字，那么其中的一个，或者两个人一起，会被KILL命令删除。（详情请看3。7。1IRC客
户端协议[IRC客户端]）

6．2．2信道

当前的信道规则：所有服务器都要知道所有信道，它们的位置和特性。由于执行不是很好，
不被干扰的事情还是需要担心的。信道冲突被看作是集体冲突（信道上两个网中的人有着一
样的名字被认为是信道中的成员），而不是象呢称冲突一样的单一事件。

协议定义了"安全信道"，这种信道不太可能发生信道冲突。其他信道模式保存下来为了向后
的兼容性。

6．3运算法则

服务器代码中的某些地方，不可以不用N^2这样的法则，因为要检测信道上的客户端。

在当前服务器的版本中，只有少数数据库包含了检测方法，现在大多数服务器，每一个都只
能假想周边的服务器是正确的。这就为大量问题打开了大门，如果一个连接中服务器有问题，
或者它正向网络中散发病毒。

当前，由于缺少独一无二的中央处理器和全球范围的标志，多种多样的问题都已经出现。这
种情况大多是由问题引发的，因为它们需要时间来传播信息，并且作用于网络。即使把它们
更改成独一无二的标志，也还是会产生问题，使信道连接中断。

7．安全考虑

7．1证明

服务器通常只有两种方法来鉴别加入的连接：检测密码和DNS查找。尽管这种方法是脆弱
的并且被公认为不够安全，它们的合并已经在过去被证实了：

*公共的网络只需要对用户进行很少的限制和约定，不需要很严格的测试。

*在控制环境下的私人网络，经常使用HOME-GROWN鉴定装置，但是在INTERNET上是
不可信的：只有在某些服务器上[IDENT]，或者其他私有的服务器上才是可用的。

同样的坚定应用与IRC 操作员的鉴定。

同样也会注意：就是那里有很多年不需要更强的鉴定，不需要更大的努力提供更好的鉴别用
户，当前的协议提供了足够的额外的鉴别方法，以客户端信息为基础，并且服从于服务器连
接，：服务器名，用户名，密码。

7．2完整性

路径和操作信息被发送进空白的文档，串层加密装置，（象TLS协议），可以用来保护这些
操作。

8．相关支持和联接

IRC相关讨论：主论区：[e-mail]
协议开发：[e-mail]
软件操作：
        ftp://ftp.irc.org/irc/server
        ftp://ftp.funet.fi/pub/unix/irc
        ftp://coombs.anu.edu.au/pub/irc
新闻组：alt.irc

9．鸣谢：
这篇文章部分是从RFC-1459[IRC]，是第一次正式的公布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.

   [ABNF]       Crocker, D. and P. Overell, "Augmented BNF for Syntax
                Specifications: ABNF", RFC 2234, November 1997.

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

   [IRC-ARCH]   Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
                April 2000.

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

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

   [ZLIB]       Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data
                Format Specification version 3.3", RFC 1950, May 1996.

   [DEFLATE]    Deutsch, P., "DEFLATE Compressed Data Format
                Specification version 1.3", RFC 1951, May 1996.

   [GZIP]       Deutsch, P., "GZIP file format specification version
                4.3", RFC 1952, May 1996.

   [IDENT]      St. Johns, M., "The Identification Protocol", RFC 1413,
                February 1993.

   [TLS]        Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246,
                January 1999.

11．作者地址

Christophe Kalt
   99 Teaneck Rd, Apt #117
   Ridgefield Park, NJ 07660
   USA

   EMail: [e-mail]

12．版权说明


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

   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.

致谢：
   Funding for the RFC Editor function is currently provided by the
   Internet Society.




RFC2813——Internet Relay Chat: Server Protocol            Internet 交换交谈：服务器协议