備忘錄的狀態：
這個備忘錄提供了internet群體的信息。它并沒有具體說明每一種internet的標準。這個備
忘錄的適用范圍是無拘束的。
版權通告：
copyright（c）internetSociety(2000).AllRightsReserved.
摘要：
以客戶端——服務器為模板，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更多的密碼字數0210010000ircabgh$z

4．1．2服務器信息

命令：服務器
參數：〈服務器名〉〈希望數值〉〈標記〉〈信息〉

這條命令是用來注冊一個新的服務器用的，新的連接中，它作為以一個服務器的身
份向它的同行介紹自己。這個命令也可以用來在整個網絡中傳遞服務器的信息。當一個新的
服務器連接到網上，它的相關信息就一定要遍告整個網絡。

〈信息〉參數可以包含空格符。

〈希望數值〉是用來告知服務器其他服務器在那里，距離多遠。當地的服務器會被
賦為0，每經過一個，值就增加。用一個完整的服務器列表，你可以建立一個完整的服務器
樹型網絡圖，當然，假如有HOSTMASK建立的話，這就行不通了。

〈標志〉參數是服務器用來做標志的無符號數。這個標志符后來被用來表示一個服
務器，在傳遞服務器之間的用戶名和服務信息時。服務器的標志符只有在點對點的服務器之
間連接時才有效，并且對于那個連接是獨特的。并不是全球通用的。

服務器信息只有在連接注冊時才被答應，或者是連接到其他服務器，在那種情況下，
服務器信息是介紹一個新服務器。

大多數錯誤都是在服務器信息返回時發生的，原因就是終端服務器中斷了連接（目
標服務器）。由于這種事件的嚴重性，錯誤回復通常是返回“錯誤”命令，而不是數字回復。

假如服務器信息被分析，并且它試圖向一個已經了解了的服務器介紹服務器時，那
么這個連接，從消息收到的那方，就一定要被關閉（按照正規的順序）。因為一條通往那個
服務器的路線已經形成，并且會破壞已經形成的irc樹型網絡。在一些情況下，也可以由發
送消息的那一方停止信息。必須聲明的是：這種錯誤也可能由于服務器的第二次啟動產生，
協議中產生了這種問題是不可能修復的，通常需要人類的參與。這種錯誤是非常陰險的，因
為只要irc服務器中一個被孤立，就會產生這種錯誤。假如兩個服務器中的一個被孤立，那
么連接就不能連接。

數字回復：

錯誤——已注冊

舉例
SERVERtest.oulu.fi11:EXPerimentalserver;Newserver
test.oulu.fi就是在介紹服務器本身，并且試圖注冊。
:tolsun.oulu.fiSERVERcsd.bu.edu534:BUCentralServer;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可以找到
更多資料）

例子：
NICKsyrk5kaltmillennium.stealth.net34+i:ChristopheKalt
新的使用者有這個呢稱“syrk”，用戶名“kalt”，
從主機millennium.stealth.net連接到服務器
34("csd.bu.edu"根據前一個例子).

：krysNICKsyrk：呢稱信息的另外一種形式，就象irc客戶端協
議中定義的一樣。在服務器之間使用：用戶
krys把他的名字改為syrk。

4．1．4服務信息

命令：服務
參數：<服務名稱><服務代碼><分類><類型><希望值>〈信息〉

服務命令是用來介紹一條新服務。這種形式的服務信息不可以被客戶端接受（不管有沒有注
冊）。但是，它一定要使用于服務器通告于其他服務器，有新信息假如irc網絡服務。

服務代碼是用來鑒別服務連接到的服務器。（詳情請看4。1。2關于服務器代碼）

希望值參數是被服務器用來測量，服務與服務器之間距離的。當地連接的希望值是0。每經
過一個服務器，希望值就加一。

分類參數被用來指定服務的明顯度。服務只被有著與分類參數相符的服務器了解。因為與之
相匹配的服務器了解了這條服務，在服務器與提供服務的服務器之間的路徑，一定要可以分
解成服務器名。沒有任何限制時，就使用符號‘*’。

類型參數現在保存下來是為了將來使用。

數字回復：ERR_ALREADYREGISTREDERR_NEEDMOREPARAMS
ERR_ERRONEUSNICKNAME
RPL_YOURESERVICERPL_YOURHOST
RPL_MYINFO
例子：
服務dir@irc.fr9*.fr01:法文r在服務器9中注冊，在通知其他服務器。這條服務只有服務
器的名字里有fr時才有效。

4．1．5退出
命令：退出
參數：

客戶端的會議通常是以一個退出命令作為結束的。假如客戶端發送出退出信息，那么服務器
一定要終止跟客戶端的連接。假如退出信息發送出，這個就會被發送出，用來取代默認的信
息，通常是用戶名或者服務名。

當網絡中斷（詳情請看4。1。6）發生時，退出信息是由相關的兩個服務器的名字組成的，
中間用一個空格分開。第一個名字，是還在連接的那個服務器的名字，第二個是已經斷開的
服務器名字，或者是那個客戶端連接到的服務器。
<QuitMessage>=":"servernameSPACEservername

由于"quitmessage"對“netsplits”來說有一個非凡意義，服務器不答應客戶端使用“quit
message”，用上面的形式。

假如，由于某些原因，在還沒有任何“quitmessage”客戶端連接被終止了（客戶端停止，
或者是發生斷線），服務器需要用一些信息來填補退出信息，這些信息導致了中斷的發生。
比較常見的，通常報告系統非凡錯誤。

數字回復：
無。

例子：:WiZQUIT:Gonetohavelunch;PReferredmessageformat

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

命令：SQUIT
參數：<服務器><注釋>
它有兩種用法：：

第一（詳情請看InternetRelayChat:ClientProtocol）答應操作員斷開當地的或者遠程的連接。
這種形式的信息也是服務器用來斷開連接的最后手段。

第二種用法被用來通知其他服務器，當網絡中斷發生時。換句話，就是告訴其他服務器有那
些服務器壞了。假如一個服務器想終止與其他服務器的連接，它就必須向其他服務器發送
SQUIT信息，用其他服務器名做參數，就是它想關閉連接的哪個。

注釋通常用來存放那些可以放錯誤或者是相似信息的服務器。

被斷開的兩端的服務器都需要發出一個SQUIT信息（給所有與它們連接的服務器），給那些
連接背后的服務器。

同樣的，QUIT信息可能被發送給其他還連接的服務器，為了所有連接的客戶端。作為補充，
這條已經損失了一個成員的信道上的所有成員,都必須發送一個退出信息。信息是由這些成
員的服務器發出的。

假如一個服務器的連接斷開了（另外一端的服務器死機了），那么監測到這個斷開的服務器
就需要通知其他網絡，連接已斷開并且用恰當的文字填充注釋。

當客戶端由于SQUIT被中斷，服務器就要把這個客戶端的呢稱加入已斷開的名單，防止發
生呢稱沖突。詳情看5。7（跟蹤最近使用的呢稱）。

數字回復：
ERR_NOPRIVILEGESERR_NOSUCHSERVER
ERR_NEEDMOREPARAMS
例子：SQUITtolsun.oulu.fi:BadLink?;服務器tolsun。Oulu。fi由于錯誤連接被中斷。
:TrillianSQUITcm22.eng.umd.edu：Serveroutofcontrol;從trillian發送出的信息由于
服務器失去控制而被中斷。

4．2信道操作：

這組信息和操作信道有關，他們的道具（信道模式），并且他們的內容（典型用戶）。在這些
道具中，大量的關于信道狀態是不可避免的，尤其是當使用者對反對斷開作出連接的時候。
同時，它需要服務器保留一個呢稱記錄，來確定呢稱在那里使用過，只要資料一更改，服務
器就會檢測歷史記錄。

4．2．1加入信息
命令：JOIN
參數：<channel>[%x7<modes>]
*(","<channel>[%x7<modes>])
JOIN命令是客戶端用來加入一個非凡信道時使用的。客戶端是否被答應加入，就只由當地
的服務器鑒定產生結果：其他服務器只是單純的填加這個用戶，當它們收到這條信息時。

通常，用戶在信道上的狀態（信道模式0，o，v）可以加在信道名后面，用g分隔開。假如
這種信息不是被服務器接收到，那么這種數據通常是被忽略的。這種格式也不可以發送給客
戶端，它只能用在服務器之間傳輸，并且應該被消除。

JOIN命令一定要通知所有服務器，因此服務器才知道如何找到信道上的用戶。它答應理想
的PRIVMSG和NOTICE信息在信道上傳輸。

數字回復：ERR_NEEDMOREPARAMSERR_BANNEDFROMCHAN
ERR_INVITEONLYCHANERR_BADCHANNELKEY
ERR_CHANNELISFULLERR_BADCHANMASK
ERR_NOSUCHCHANNELERR_TOOMANYCHANNELS
ERR_TOOMANYTARGETSERR_UNAVAILRESOURCE
RPL_TOPIC
例子：
:WiZJOIN#Twilight_zoneWIZ的JOIN信息

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

NJOIN命令只用在服務器之間。假如接受到這種信息是從客戶端發送的，信息就會被忽略。
它主要用于服務器之間交換用戶及信道信息。

盡管如此，同樣的函數用JOIN也可以完成，但這條信息可以用來取代JOIN，并且比它更
有效。前綴“@@”表明用戶是信道的創造者，符號“@”表明了信道的操作者，符號“+”
表明用戶有權發聲。

數字回復：ERR_NEEDMOREPARAMSERR_NOSUCHCHANNEL
ERR_ALREADYREGISTRED
例子：:ircd.stealth.netNJOIN#Twilight_zone:@WiZ,+syrk,avalon
從ircd.stealth.net發送來的NJION信息說明用戶正在加入#Twilight_zonechannel:WiZ并且表
明了信道操作者的狀態，syrk有發聲權利，而avalon沒有。

4．3模式信息
MODEL信息是irc中雙重意義的命令。它答應用戶名和信道的模式改變。

當解析MODEL信息時，建議先解析完整的信息，然后在進行改變。

這里需要服務器來改變信道模式，所以“channelcreator”和“channelOperator”都可以建立。

5．執行細節

在寫入時，這個協議當前執行的就是irc服務器，version2。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,vonchannels)
*KICK（該呢稱被從信道上消除了）

其他命令不需要檢查呢稱改變。

在上述情況中，服務器要先檢測現有的呢稱，然后查看歷史記錄，那個呢稱現在屬于誰？這
就降低了出錯的可能性，但是它還是會在服務器終止一個錯誤的客戶端是發生。當實現一個
改變對上述命令的跟蹤時，建議限定歷史的時間范圍，太舊的記錄可以被忽略。

對于一個合情合理的歷史記錄，服務器就應該保存客戶端以前的名稱，假如它們想改變名稱
的話。這種狀況會有其他因素制約。（比如記憶體，等等）

5．7跟蹤最近使用過的用戶名

這種體制通常被認為是“NICKDELAY”，它已經被證實，可以減少用戶名沖突的數量，就
是那些主要由網絡分裂和再登陸引起的。

保持跟蹤呢稱的改變，服務器要隨時跟蹤最近使用過的用戶，并且隨時釋放那些被網絡分裂
和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相關討論：主論區：ircd_users@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．鳴謝：
這篇文章部分是從RFC-1459[IRC]，是第一次正式的公布IRC協議。它自得于很多的觀點和
內容。非凡是下面的對本書作出極大貢獻：
MatthewGreen,MichaelNeumayer,VolkerPaulsen,KurtRoeckx,Vesa
Ruokonen,MagnusTjernstrom,StefanZehl.

10．參考書目：


[KEYWordS]Bradner,S.,"KeywordsforuseinRFCstoIndicate
RequirementLevels",BCP14,RFC2119,March1997.

[ABNF]Crocker,D.andP.Overell,"AugmentedBNFforSyntax
Specifications:ABNF",RFC2234,November1997.

[IRC]Oikarinen,J.andD.Reed,"InternetRelayChat
Protocol",RFC1459,May1993.

[IRC-ARCH]Kalt,C.,"InternetRelayChat:Architecture",RFC2810,
April2000.

[IRC-CLIENT]Kalt,C.,"InternetRelayChat:ClientProtocol",RFC
2812,April2000.

[IRC-CHAN]Kalt,C.,"InternetRelayChat:ChannelManagement",RFC
2811,April2000.

[ZLIB]Deutsch,P.andJ-L.Gailly,"ZLIBCompressedData
FormatSpecificationversion3.3",RFC1950,May1996.

[DEFLATE]Deutsch,P.,"DEFLATECompressedDataFormat
Specificationversion1.3",RFC1951,May1996.

[GZIP]Deutsch,P.,"GZIPfileformatspecificationversion
4.3",RFC1952,May1996.

[IDENT]St.Johns,M.,"TheIdentificationProtocol",RFC1413,
February1993.

[TLS]Dierks,T.andC.Allen,"TheTLSProtocol",RFC2246,
January1999.

11．作者地址

ChristopheKalt
99TeaneckRd,Apt#117
RidgefieldPark,NJ07660
USA

EMail:kalt@stealth.net

12．版權說明


Copyright(C)TheInternetSociety(2000).AllRightsReserved.

Thisdocumentandtranslationsofitmaybecopiedandfurnishedto
others,andderivativeworksthatcommentonorotherwiseexplainit
orassistinitsimplementationmaybeprepared,copied,published
anddistributed,inwholeorinpart,withoutrestrictionofany
kind,providedthattheabovecopyrightnoticeandthisparagraphare
includedonallsuchcopiesandderivativeworks.However,this
documentitselfmaynotbemodifiedinanyway,suchasbyremoving
thecopyrightnoticeorreferencestotheInternetSocietyorother
Internetorganizations,exceptasneededforthepurpoSEOf
developingInternetstandardsinwhichcasetheproceduresfor
copyrightsdefinedintheInternetStandardsprocessmustbe
followed,orasrequiredtotranslateitintolanguagesotherthan
English.

Thelimitedpermissionsgrantedaboveareperpetualandwillnotbe
revokedbytheInternetSocietyoritssuccessorsorassigns.

Thisdocumentandtheinformationcontainedhereinisprovidedonan
"ASIS"basisandTHEINTERNETSOCIETYANDTHEINTERNETENGINEERING
TASKFORCEDISCLAIMSALLWARRANTIES,EXPRESSORIMPLIED,INCLUDING
BUTNOTLIMITEDTOANYWARRANTYTHATTHEUSEOFTHEINFORMATION
HEREINWILLNOTINFRINGEANYRIGHTSORANYIMPLIEDWARRANTIESOF
MERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE.

致謝：
FundingfortheRFCEditorfunctioniscurrentlyprovidedbythe
InternetSociety.