因特网延迟交谈：体系结构
（Internet Relay Chat: Architecture）
该备忘录的状态
该备忘录为互联网团体提供信息。它并不制定任何互联网标准，可以被无限制的发布。
Copyright(c)The Internet Society (2000).All Rights Reserved.
摘要:
IRC(因特网延迟交谈)协议用于文本交谈，1989年它首次被实现并用于BBS用户间的交谈
1993年五月RFC 1459(IRC)将它以文献形式正式确立下来，以后它就不断发展
这篇文献描述了目前IRC协议的结构以及它各个组成部分的在整个协议中的角色
其它文献详描述了这里定义的各种组成之间的协议
目录
1.介绍 2
2．组件 2
2.1服务器 3
2.2客户机 3
2.2.1用户客户机 3
2.2.2服务客户机 3
3.结构 3
4.IRC协议服务 3
4.1客户机定位 4
4.2消息延迟 4
4.3频道收集和管理 4
5.IRC 概念 4
5.1一对一交流 4
5.2和多个 4
5.2.1和一个频道 5
5.2.2向 一个主机/服务器掩网 5
5.2.3向一系列目标 5
5.3向所有 5
5.3.1客户机向客户机 5
5.3.2客户机向服务器 6
5.3.3服务器向服务器 6
6当前的问题 6
6.1可用范围 6
6.2可靠性 6
6.3网络拥塞 6
6.4保密问题 6
7．保密 7
8．目前的支持和获取渠道 7
9. 感谢 7
10.参考文献 7
11.作者地址 7
12．完整版权说明 8
致谢 8
1.介绍
IRC(Internet延迟交谈)协议用于文本交谈被设计出来已经有许多年了，这篇文档描述了
它目前的体系结构。
IRC协议是基于客户服务器模型的，可以很好地分布式地在许多机器上运行。一个典型
的设置涉及一个进程(服务器)，它作为中心点接受客户(或其它服务器)的连接，并且实现
要求的消息传送/多元技术和其它的功能。
这种分布模型，由于它要求每个服务器都拥有全局状态信息，限制了一个网络所能达到
的最大规模，因此是此协议最令人不能容忍的问题。现存的网络能够以难以置信的速度
持续增长，我们必须感谢硬件制造商们给了我们比以往更加强大的系统。
2．组件
接下来的几节定义了IRC协议的基本组件
2.1服务器
服务器是IRC的主干，因为它是协议中唯一能够将所有其它组件连接在一起的组件：它
为客户机提供连接的节点以使它们之间进行交谈[IRC-CLIENT],并且提供供其它服务器
连接的节点[IRC-SERVER]。服务器也负责提供IRC协议定义的基本服务。
2.2客户机
任何不是服务器并且连到一个服务器的机器都可以称作客户机。有两种客户机，它们用
于不同的目的。
2.2.1用户客户机
用户客户机一般是提供基于文本界面的程序，程序用来通过IRC进行交流。这种特
殊类型的客户机常被称作“用户机”。
2.2.2服务客户机
不像用户机，服务客户机没有设计为手工作用，也不用于交谈。它们对协议交谈功
能的使用受到更加的限制，却可以随意地使用来自服务器的更加秘密的数据.
服务机是典型的用来向用户机提供各种服务(不必和IRC自身相关)的自动机器。一
个例子是一个收集和IRC网络相连的用户机的来源的统计数据的服务。
3.结构
一组相互连接的服务器就定义了一个IRC网络，一台服务器构成最简单的IRC网络。
对IRC服务器来说，唯一允许的网络结构是一个生成树，每个服务器都作为对它可见的
网络的中心结点。
1--\
A D---4
2--/ \ /
B----C
/ \
3 E
服务器：A,B,C,D,E 客户机：1,2,3,4
[图一 小型IRC网络示例]
4.IRC协议服务
这个部分描述了IRC协议提供的服务。这些服务的组合可以实现实时会议。
4.1客户机定位
为了相互交换消息，两个客户机必须能够相互定位对方。
一连上服务器，客户机就注册一个标志，此标志此后被其它服务器和客户机用来定位该客
户机。服务器负责跟踪所有使用的标志。
4.2消息延迟
IRC协议无法提供两台客户机的直接连接，所有客户机间的交流都被服务器延迟
4.3频道收集和管理
一个频道是一个由一个或更多的客户机组成的命名组，这个组中的所有成员都接收发送给
这个频道的消息。一个频道由它的名字和目前的成员来标志，它也有一系列能被它的成员
使用的属性。
频道提供了向多个客户机发送信息的方法。服务器收集频道，提供必须的消息多路技术。服
务器也负责通过跟踪频道成员来管理频道。服务器的确切角色在"Internet Relay Chat:
Channel Management" [IRC-CHAN]中定义。
5.IRC 概念
这个部分专门描述IRC协议组织背后的真实概念，以及不同种类的消息如何被传送。
5.1一对一交流
一对一基础上的交流经常由客户机实现，因为大部分的阻塞是经由服务器进行的交谈。
为了提供一各客户机相互交谈的方法，要求所有服务器能够沿着生成树到达任何客户
机以单向发送消息。因此消息发送路径是生成树上任意两点之间的最短路径。
下面的例子都涉及上面的图一。
例一：1和2之间的消息只同时被服务器A看到，A直接将消息发送给2。
例二：1和3之间的消息同时被服务器A，B和客户机3看到。没有其它客户机或服
务器允许看到此消息。
例三：2和4之间的消息只被服务器A，B，C，D和客户机4看到。
5.2和多个
IRC的方根目的是提供简单有效的会议论坛。IRC提供了许多方法来实现，每个方法
都为各自的目的服务。
5.2.1和一个频道
在IRC里，频道和多播组角色等同，它们都动态生存而且实际上的谈话必须发送到
正支持给定频道上客户机的服务器。还有，消息将向每个本地链接只发送一次，因
为每个服务器都负责散发原始消息以保证它能到达所有收件人。
下面的例子都涉及图二
例四：任何包括客户机一在内的频道。任何发送给该频道的消息到达服务器并且不会
到达其它任何地方。
例五：二个客户机在一个频道里。所有消息经过的路径使它们看起来像频道、之外的
两个客户机之间的秘密消息。
例六：客户机1,2,3在一个频道里。所有发送给该的消息都发送给所有客户机和那些发
送给单个客户机的秘密消息所必须经过的服务器。如果客户机1发送一条消息，它返回
到客户机2然后经由服务器B到达客户机3。
5.2.2向 一个主机/服务器掩网
为了提供一种向大量相关客户机发送消息的机制，必须能够向主机/服务器掩网发送消
息。这些消息发送给掩码信息相符的那些主机和服务器。消息只被发送到客户机所在
的特定区域，和频道的方式差不多。
5.2.3向一系列目标
效率最差的一对多谈话方式是客户机向一系列目标谈话(客户机，频道，掩网)。
这种方式的实现是不言自明的：客户机给出消息目的地的列表，服务器将它分解并向
每个目的地发送一份消息拷贝。
这种方式没有频道方式有效率，因为列表可能被破坏而且不能保证沿着每条路径向下
发送每条消息的拷贝。
5.3向所有
一对所有式的消息最好是用广播消息来描述，这种消息是发送给所有客户机或服务
器或两者兼备。在一个包含客户机和服务器的大型网络上，一条消息就能引起大量
堵塞，因为它会努力被发送到所有想达到的目的地。
对某些种类的消息来说，没有其它选择只有向所有服务器广播，这样才能保持各个
服务器保存的状态信息之间的一致性。
5.3.1客户机向客户机
没有哪种消息能够导致来自单一客户机的消息发送给所有其它客户机。
5.3.2客户机向服务器
大部分引起状态信息(比如频道成员人数，频道状态，客户机状态等等)改变的命令
必须缺省地向所有服务器发送，而且这种分发不应被客户机改变。
5.3.3服务器向服务器
尽管大多数服务器之间的消息都向所有其它服务器分发，但只有当消息影响客户机，
频道或服务器时才有必要。因为在IRC里有一些基本的条目，因此几乎所有的来自
服务器的消息都向其它相连的服务器广播。
6当前的问题
这个协议有一些公认的问题，这个部分仅仅讲述那些和协议体系有关的问题。
6.1可用范围
当大范围应用时，此协议用得不太好，这一点已经得到广泛认同。主要原因是所有服务器
都必须知道其它服务器，客户机和频道并且关于它们的信息必须及时更新。
6.2可靠性
因为IRC服务器唯一允许的网络结构是生成树，因此两个服务器之间的连接是明显的而
且很容易断连。这个问题在“Internet延迟交谈：服务器协议”[IRC-SERVER]中有更加详
细的描述。
6.3网络拥塞
生成树结构引起的问题除了可用范围和可靠性两个问题之外，还有就是使IRC极容易导
致网络拥塞。这个问题是区域性的，直到下一代才能解决：如果拥塞和高流量导致两个
服务器之间的连接失败，不仅这种失败导致网络拥塞，而且它们之间的重连也将导致更
加严重的网络拥塞。
为了使这个问题的影响减到最小，服务器最好不要自动地太快地尝试重新连接，以避免
使情况恶化。
6.4保密问题
除了不能很好地适用大范围，以及服务器必须知道其它实体的所有信息外，优先级问题
也是引人注目的问题。特别是对频道，
7．保密
除了6.4节提到的保密问题外,安全和这个文档不相关。
8．目前的支持和获取渠道
IRC相关讨论邮件列表：
一般讨论：[email protected]
协议开发：[email protected]
实现软件：ftp://ftp.irc.org/irc/server
ftp://ftp.funet.fi/pub/unix/irc
ftp://coombs.anu.edu.au/pub/irc
新闻组: alt.irc
9. 感谢
这篇文档部分拷贝自第一次正式发布的IRC协议RFC 1459[IRC]，它也受益于许多评论
和讨论。特别是以下人对这篇文档作出了重要贡献：
Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa
Ruokonen, Magnus Tjernstrom, Stefan Zehl.
10.参考文献
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[IRC] Oikarinen, J. and D. Reed, "Internet Relay Chat
Protocol", RFC 1459, May 1993.
[IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC
2812, April 2000.
[IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC
2813, April 2000.
[IRC-CHAN] Kalt, C., "Internet Relay Chat: Channel Management", RFC
2811, April 2000.
11.作者地址
Christophe Kalt
99 Teaneck Rd, Apt #117
Ridgefield Park, NJ 07660
USA
EMail: [email protected]
12．完整版权说明
Copyright (C) The Internet Society (2000). All Rights Reserved.
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.
RFC2811——Internet Relay Chat: Channel Management
Internet延迟交谈：体系与结构
