該備忘錄的狀態
該備忘錄為互聯網團體提供信息。它并不制定任何互聯網標準，可以被無限制的發布。
Copyright(c)TheInternetSociety(2000).AllRightsReserved.

摘要:
IRC(因特網延遲交談)協議用于文本交談，1989年它首次被實現并用于BBS用戶間的交談
1993年五月RFC1459(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--/
AD---4
2--///
B----C
//
3E
服務器：A,B,C,D,E客戶機：1,2,3,4
[圖一小型IRC網絡示例]
4.IRC協議服務
這個部分描述了IRC協議提供的服務。這些服務的組合可以實現實時會議。
4.1客戶機定位
為了相互交換消息，兩個客戶機必須能夠相互定位對方。
一連上服務器，客戶機就注冊一個標志，此標志此后被其它服務器和客戶機用來定位該客
戶機。服務器負責跟蹤所有使用的標志。
4.2消息延遲
IRC協議無法提供兩臺客戶機的直接連接，所有客戶機間的交流都被服務器延遲
4.3頻道收集和治理
一個頻道是一個由一個或更多的客戶機組成的命名組，這個組中的所有成員都接收發送給
這個頻道的消息。一個頻道由它的名字和目前的成員來標志，它也有一系列能被它的成員
使用的屬性。
頻道提供了向多個客戶機發送信息的方法。服務器收集頻道，提供必須的消息多路技術。服
務器也負責通過跟蹤頻道成員來治理頻道。服務器的確切角色在"InternetRelayChat:
ChannelManagement"[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相關討論郵件列表：
一般討論：irce-user@irc.org
協議開發：ircd-dev@irc.org
實現軟件：FTP://ftp.irc.org/irc/server
ftp://ftp.funet.fi/pub/unix/irc
ftp://coombs.anu.edu.au/pub/irc
新聞組:alt.irc
9.感謝
這篇文檔部分拷貝自第一次正式發布的IRC協議RFC1459[IRC]，它也受益于許多評論
和討論。非凡是以下人對這篇文檔作出了重要貢獻：
MatthewGreen,MichaelNeumayer,VolkerPaulsen,KurtRoeckx,Vesa
Ruokonen,MagnusTjernstrom,StefanZehl.
10.參考文獻
[KEYWordS]Bradner,S.,"KeywordsforuseinRFCstoIndicate
RequirementLevels",BCP14,RFC2119,March1997.
[IRC]Oikarinen,J.andD.Reed,"InternetRelayChat
[IRC-CLIENT]Kalt,C.,"InternetRelayChat:ClientProtocol",RFC
2812,April2000.
[IRC-SERVER]Kalt,C.,"InternetRelayChat:ServerProtocol",RFC
2813,April2000.
[IRC-CHAN]Kalt,C.,"InternetRelayChat:ChannelManagement",RFC
2811,April2000.
11.作者地址
ChristopheKalt
99TeaneckRd,Apt#117
RidgefieldPark,NJ07660
USA
EMail:kalt@stealth.net
12．完整版權說明
Copyright(C)TheInternetSociety(2000).AllRightsReserved.
Thisdocumentandtheinformationcontainedhereinisprovidedonan
"ASIS"basisandTHEINTERNETSOCIETYANDTHEINTERNETENGINEERING
TASKFORCEDISCLAIMSALLWARRANTIES,EXPRESSORIMPLIED,INCLUDING
BUTNOTLIMITEDTOANYWARRANTYTHATTHEUSEOFTHEINFORMATION
HEREINWILLNOTINFRINGEANYRIGHTSORANYIMPLIEDWARRANTIESOF
MERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE.

致謝

FundingfortheRFCEditorfunctioniscurrentlyprovidedbythe
InternetSociety.