| 通信プロトコル | |
| 略語 | IRCC の |
|---|---|
| 目的 | インスタントメッセージ |
| 開発者 | ヤルコ・オイカリネン |
| 導入 | 1988年8月 |
| 影響を受けた | Discord IRCv3 (標準化プロセスワーキンググループ) |
| OSI層 | アプリケーション層 |
| ポート | 6667、6697 |
| RFC(複数) | RFC 1459 |

IRC(インターネットリレーチャット)は、インスタントメッセージング用のテキストベースのチャットシステムです。IRCは、チャネルと呼ばれるディスカッションフォーラムでのグループ通信用に設計されています[1]が、プライベートメッセージ[2]を介した1対1の通信や、チャットやデータ転送[3]、ファイル共有[4]も可能にします。
インターネット リレー チャットは、テキスト形式での通信を容易にするためのアプリケーション層プロトコルとして実装されています。チャット プロセスは、クライアント サーバー ネットワーク モデルで動作します。ユーザーは、 Web アプリ、スタンドアロンのデスクトップ プログラム、またはより大きなプログラムの一部に埋め込まれたクライアントを使用して、より大きな IRC ネットワークの一部である IRC サーバーに接続します。接続に使用されるプログラムの例としては、Mibbit、IRCCloud、KiwiIRC、mIRCなどがあります。
IRCの利用は2003年以降着実に減少しており、利用者の60%が失われています。[5] 2011年4月には、上位100のIRCネットワークが一度に20万人以上のユーザーにサービスを提供していました。[6]
歴史
IRC は、フィンランドのオウル大学情報処理科学科に勤務していたJarkko Oikarinenによって1988 年 8 月に作成されました。OuluBox というBBS上の MUT (MultiUser Talk) というプログラムを置き換えるものでした。Jarkko は、自分が管理していた BBS ソフトウェアを拡張して、 Usenetスタイルのニュース、リアルタイムのディスカッション、および同様の BBS 機能を実現することを意図していました。彼が最初に実装したのはチャット部分で、友人の Jyrki Kuoppala と Jukka Pihl が作成した部分を借用して実装しました。最初の IRC ネットワークは、tolsun.oulu.fi という単一のサーバーで実行されていました。[7] Oikarinen は、 BITNET上で動作するBitnet Relayというチャット システムにインスピレーションを得ました。[8]
Jyrki Kuoppala は Oikarinen に、オウル大学に IRC コードを解放してオウル以外でも実行できるように依頼するよう働きかけ、最終的に解放されると、Jyrki Kuoppala はすぐに別のサーバーを設置しました。これが最初の「IRC ネットワーク」でした。Oikarinen は、ユーザー数が増えるとヘルシンキ工科大学とタンペレ工科大学[8]の友人に IRC サーバーの運用を依頼し、他の大学もすぐに追随しました。この時点で、Oikarinen は、BBS の残りの機能はおそらく自分のプログラムには合わないだろうと気づきました。[7]
オイカリネンはデンバー大学とオレゴン州立大学の人々に連絡を取った。彼らは独自のIRCネットワークを運用しており、フィンランドのネットワークに接続したいと考えていた。彼らはオイカリネンの友人の一人、ヴィジェイ・スブラマニアンからプログラムを入手していた。スブラマニアンはIRCを使用した最初のフィンランド人以外の人物だった。その後IRCは大きくなり、フィンランドの全国ネットワークであるFUNET全体で使用されるようになり、その後インターネットのスカンジナビア支部であるNordunetに接続した。1988年11月、IRCはインターネット全体に広がり、1989年半ばには世界中に約40のサーバーがあった。[7]
EFネット
1990 年 8 月、IRC の世界で最初の大きな意見の相違が起こりました。「A-net」(Anarchy net) には、eris.berkeley.edu というサーバーが含まれていました。これはすべてオープンで、パスワードは不要で、接続数に制限はありませんでした。Greg "wumpus" Lindahl は次のように説明しています。[9]「ワイルドカード サーバー ラインがあったため、人々はサーバーを接続して、全員のニックネームを衝突させていました。」 「Eris Free Network」、EFnet により、eris マシンは IRC から Q ライン (Q は quarine の略) で最初に削除されました。再び wumpus の言葉を借りると、[9]「Eris がそのラインを削除することを拒否したため、EFnet を作成しました。大した争いではありませんでした。私はすべてのハブに参加してもらいましたが、他のほとんどの人もそれに従いました。」 A-net は eris サーバーで作成され、EFnet は eris 以外のサーバーで作成されました。歴史が示すように、ほとんどのサーバーとユーザーは EFnet を選択しました。 A-netが解散すると、EFnetという名前は意味を失い、再び唯一のIRCネットワークとなった。[7]
その頃、IRCはメディア統制下で1991年のソ連クーデター未遂事件を報道するために使われた。[10]湾岸戦争の時も同様に使われた。[11]これらやその他の出来事のチャットログはibiblioアーカイブに保存されている。[12]
アンダーネットフォーク
もう一つのフォークの取り組み、そして永続的な変化をもたらした最初の取り組みは、1992年10月に米国の「Wildthang」によって開始されました。(これはEFnet ircdバージョン2.8.10からフォークしました)。これはボットを開発するためのテストネットワークとしてのみ意図されていましたが、すぐに「友人とその友人のための」ネットワークに成長しました。ヨーロッパとカナダでは別の新しいネットワークが開発され、12月にフランスのサーバーがカナダのサーバーに接続され、その月の終わりまでにフランスとカナダのネットワークが米国のネットワークに接続され、後に「アンダーネット」と呼ばれるようになったネットワークが形成されました。[7]
「アンダーネット」は、IRCD をさらに進化させて帯域幅の使用を抑え、EFnet が悩まされ始めたチャネルの混乱 (ネットスプリットと乗っ取り) を解決しようとしました。後者の目的のために、アンダーネットはタイムスタンプと新しいルーティングを実装し、CService を提供しました。これは、ユーザーがチャネルを登録して、トラブルメーカーから保護できるようにするプログラムです。1993 年 2 月 15 日に最初に提示されたサーバー リストには、米国、カナダ、フランス、クロアチア、日本のサーバーが含まれています。8 月 15 日には、新しいユーザー数記録が 57 人にまで達しました。[7]
1993年5月、RFC 1459 [13]が発行され、クライアント/サーバー操作、チャネル、1対1および1対多の会話のためのシンプルなプロトコルの詳細が規定されました。[7] CTCP、色、形式などの拡張機能の多くはプロトコル仕様に含まれておらず、文字エンコードも含まれていません。 [14]そのため、サーバーとクライアントの実装が多様化しました。ソフトウェアの実装はネットワークごとに大きく異なり、各ネットワークは独自のコードベースで独自のポリシーと標準を実装していました。
DALnet フォーク
1994 年の夏、アンダーネット自体が分岐しました。新しいネットワークはDALnet (創設者 dalvenjah にちなんで命名) と呼ばれ、ユーザー サービスの向上とユーザーおよびチャネルの保護強化を目的として形成されました。DALnet の重要な変更点の 1 つは、より長いニックネームの使用です (元の ircd の制限は 9 文字でした)。DALnet ircd の変更は Alexei "Lefler" Kosut によって行われました。DALnet はこのようにアンダーネット ircd サーバーをベースとしていましたが、DALnet の先駆者たちは EFnet を放棄した人たちでした。James Ng によると、初期の DALnet の人々は「#StarTrek のオペレーション担当者で、絶え間ない分裂/遅延/乗っ取りなどにうんざりしていた」そうです。[7]
DALnet はすぐに、グローバル WallOps (+w (/mode NickName +w) のユーザーが閲覧できる IRCop メッセージ)、より長いニックネーム、Q:Lined ニックネーム (使用できないニックネーム、つまり ChanServ、IRCop、NickServ など)、グローバル K:Lines (サーバーまたはネットワーク全体から 1 人のユーザーまたはドメイン全体のアクセスを禁止)、IRCop のみの通信: GlobOps、IRCop が「helpop」であることを示す +H モードなどを提供しました。DALnet の新しい機能の多くは、1995 年初頭に Brian "Morpher" Smith によって作成され、ユーザーがニックネームを所有したり、チャネルを制御したり、メモを送信したりできるようになりました。[7]
IRCnet フォーク
1996 年 7 月、メーリング リストでの何ヶ月にも及ぶ炎上と議論の末、IRCD の開発をどのように進めるべきかという意見の相違から、またも分裂が起こりました。最も顕著なのは、後にIRCnetと名乗るようになった「ヨーロッパ」(サーバーのほとんどはヨーロッパにあった) 側がニックネームとチャネルの遅延を主張したのに対し、EFnet 側はタイムスタンプを主張したことです。[7]また、ポリシーについても意見の相違がありました。ヨーロッパ側は、IRCops ができること、できないことを指示する一連のルールを確立し始めていましたが、米国側はこれに反対していました。[15]
IRCnet サーバーのほとんど (すべてではない) はヨーロッパにあり、EFnet サーバーのほとんどが米国にありました。この出来事は、多くの IRC 協会で「大分裂」としても知られています。EFnet はその後 (1998 年 8 月現在) 成長し、当時のユーザー数を超えました。2000 年の (北半球の) 秋には、EFnet のユーザー数は約 50,000 人、IRCnet のユーザー数は 70,000 人でした。[7]
現代のIRC
IRC はインターネット上での登場以来、大きく変化してきました。新しいサーバー ソフトウェアにより、多数の新機能が追加されました。
- サービス: ニックネームやチャンネルの登録、オフラインユーザーへのメッセージの送信、ネットワークオペレーター機能などを容易にするネットワーク操作ボット。
- 追加モード: オリジナルのIRCシステムでは標準的なユーザーモードとチャンネルモードが使用されていましたが、新しいサーバーでは、テキストからカラーコードを削除する、[16]や、サービス拒否攻撃から保護するためにユーザーのホストマスクを隠す (「クローキング」) などの機能のための新しいモードが多数追加されています。[17]
- プロキシ検出: 最近のサーバーのほとんどは、安全でない(設定ミスや不正利用された)プロキシサーバー経由で接続しようとするユーザーの検出をサポートしており、接続を拒否することができます。このプロキシ検出ソフトウェアはいくつかのネットワークで使用されていますが、プロキシのリアルタイムリストは2006年初頭から廃止されています。[18]
- 追加コマンド: 新しいコマンドには、サービスにコマンドを発行するための短縮コマンドや、ユーザーのホストマスクを操作するためのネットワーク オペレータ専用のコマンドなどがあります。[引用が必要]
- 暗号化: クライアントからサーバーへの接続ではTLSが使用される場合があります (標準接続で他のユーザーに中継されたメッセージは安全ではなくなりますが、個人の IRC セッションを盗聴したり盗聴したりすることは困難になります)。クライアント間の通信では、SDCC (Secure DCC) を使用できます。[引用が必要]
- 接続プロトコル: IRC には、インターネット プロトコルの古いバージョンであるIPv4経由で、またはプロトコルの現在の標準であるIPv6経由で接続できます。
2016年現在[update]、IRCv3と呼ばれるワーキンググループの下で、インスタント通知、より優れた履歴サポート、セキュリティの向上など、より高度なクライアント機能に焦点を当てた新しい標準化の取り組みが進行中です。[19] 2019年現在[update]、主要なIRCネットワークで提案された標準を完全に採用しているものはありません。[20]
2021年6月現在、[update]481の異なるIRCネットワークが稼働していることが知られていますが[21]、そのうち2021年5月に設立されたオープンソースのLibera Chatは、26のサーバーで20,374のチャンネルを運営しており、最も多くのユーザーを抱えています。上位100のIRCネットワークは、約1,000のサーバーで10万を超えるチャンネルを共有しています。[22]
1990年代から2000年代初頭の黄金時代(2004年のQuakeNetのユーザー数は24万人)の後、IRCは大幅な衰退を経験し、2003年から2012年の間に約60%のユーザーを失い、ユーザーはFacebookやTwitterなどのソーシャルメディアプラットフォームに移行しましたが、[5] 1999年に開発されたXMPPなどのオープンプラットフォームにも移行しました。Freenodeなどの一部のネットワークは全体的な傾向に従わず、同じ期間に規模が4倍以上に拡大しました。[5]しかし、2016年に約9万人のユーザーを抱えていたFreenodeは、その後約9,300人に減少しました。[23]
最も大きな IRC ネットワークは、伝統的に「ビッグ フォー」[24] [25] [26] [27]としてグループ化されてきました。これは、統計的にトップのネットワークの呼称です。ビッグ フォー ネットワークは定期的に変わりますが、IRC のコミュニティの性質上、ユーザーが選択できるネットワークは他にも多数あります。
歴史的に「ビッグ4」は以下の通りであった。[24] [25] [26]
IRC の同時ユーザー数は 2001 年に 600 万人に達し、2004 年から 2005 年にかけて 1,000 万人に達しましたが、2021 年には約 35 万人に減少しました。[出典が必要]
上位100のIRCネットワークには、ピーク時に約23万人のユーザーが接続しています。[28]
タイムライン
主要ネットワークのタイムライン:
- EFnet、1990年から現在
- アンダーネット、1992年から現在
- DALnet、1994年から現在
- freenode、1995年から現在
- IRCnet、1996年から現在
- QuakeNet、1997年から現在
- オープンで自由なテクノロジーコミュニティ、2001年から現在
- リゾン、2002年から現在
- Libera Chat、2021年から現在
技術情報


IRCはTCP [13]とオプションでTLSを使用するオープンプロトコルです。IRCサーバーは他のIRCサーバーに接続してIRCネットワークを拡張できます。[29]ユーザーはクライアントをサーバーに接続することでIRCネットワークにアクセスします。[30] mIRC、HexChat、irssiなどの多くのクライアント実装と、オリジナルのIRCdなどのサーバー実装があります。ほとんどのIRCサーバーでは、ユーザーがアカウントを登録する必要はありませんが、接続する前にニックネームが必要です。 [31]
IRCはもともとプレーンテキストプロトコル[13](後に拡張されましたが)であり、要求に応じてIANAからポート194/TCPが割り当てられました。[32]しかし、事実上の標準として、IRCソフトウェアをルート権限で実行することを避けるために、IRCを6667/TCP [33]および近くのポート番号(たとえば、TCPポート6660〜6669、7000)[34]で実行することが常に行われてきました。
プロトコルでは文字が8ビットであると指定されていましたが、テキストが使用する文字エンコーディングは指定されていませんでした。[14]これにより、異なるクライアントや異なるプラットフォームを使用しているユーザーが会話する場合に問題が発生する可能性があります。
現在使用されているすべてのクライアントからサーバーへの IRC プロトコルは、IRC2 サーバーの irc2.4.0 バージョンで実装され、RFC 1459 に文書化されているプロトコルから派生したものです。RFC 1459 が公開されて以来、irc2.10 実装の新しい機能により、いくつかの改訂されたプロトコル ドキュメント (RFC 2810、RFC 2811、RFC 2812、および RFC 2813) が公開されましたが、これらのプロトコルの変更は他の実装では広く採用されていません。[引用が必要]
IRC プロトコルに関する仕様は多数公開されていますが、プロトコルは動的であるため、公式仕様は存在しません。上記の RFC を厳密に参照として頼っているクライアントは事実上なく、サーバーもごくわずかです。[引用が必要]
マイクロソフトは1998年に独自のIRCXを介してIRCの拡張機能を作成しました。[35]その後、同社はIRCXをサポートするソフトウェアの配布をやめ、代わりに独自のMSNPを開発しました。
IRCサーバーのネットワークの標準的な構造はツリーです。 [ 36]メッセージはツリーの必要なブランチに沿ってのみルーティングされますが、ネットワーク状態はすべてのサーバーに送信され[37]、サーバー間には一般に高いレベルの暗黙の信頼があります。ただし、このアーキテクチャには多くの問題があります。不正な動作をするサーバーや悪意のあるサーバーはネットワークに重大な損害を与える可能性があり[38]、意図的なものであろうと基盤となるネットワークの状態の結果であろうと、構造を変更するにはネット分割とネット参加が必要です。これにより、大量のネットワークトラフィックが発生し、ユーザーに誤った終了/参加メッセージが送信され[39]、分割サーバーのユーザーとの通信が一時的に途絶えます。大規模ネットワークにサーバーを追加すると、ネットワークのバックグラウンド帯域幅の負荷が大きくなり、サーバーのメモリ負荷も大きくなります。ただし、いったん確立されると、複数の受信者への各メッセージはマルチキャストに似た方法で配信されます。つまり、各メッセージはネットワークリンクを1回だけ通過します。[40]これは、シンプルメール転送プロトコル(SMTP)[引用が必要]や拡張メッセージングおよびプレゼンスプロトコル(XMPP)[引用が必要]などの非マルチキャストプロトコルと比較した場合の強みです。
IRCデーモンはローカルエリアネットワーク(LAN)上で使用できます。したがって、IRCはローカルエリアネットワーク内の人々間の通信(内部通信)を容易にするために使用できます。[41] [42]
コマンドと応答
IRCは行ベースの構造を持っています。クライアントはサーバーに1行のメッセージを送信し、[43]それらのメッセージへの返信を受信し、 [44]他のクライアントから送信されたメッセージのコピーを受信します。ほとんどのクライアントでは、ユーザーはコマンドの前に「/」を付けて入力できます。コマンドに応じて、これらはクライアントによって完全に処理されるか、(クライアントが認識しないコマンドの場合)サーバーに直接渡され、場合によっては何らかの変更が加えられます。[45]
プロトコルの性質上、自動化システムは送信されたコマンドとその応答を常に完全に正確に組み合わせることができるとは限らず、推測に頼ることになります。[46]
チャンネル
確立されたIRCセッションでユーザーグループと通信する基本的な手段は、チャンネルを使用することです。[47]ネットワーク上のチャンネルは、IRCコマンドLISTを使用して表示できます。[48]このコマンドは、その特定のネットワーク上でモード+sまたは+pが設定されていない現在利用可能なすべてのチャンネルを一覧表示します。
ユーザーはJOINコマンド[49]を使ってチャンネルに参加することができます。ほとんどのクライアントでは/join #channelnameとして利用できます。参加したチャンネルに送信されたメッセージは、他のすべてのユーザーに中継されます。[47]
IRCネットワーク全体で利用可能なチャンネルには「#」という接頭辞が付き、サーバーローカルのチャンネルには「&」が付きます。[50]その他のあまり一般的ではないチャンネルタイプには、「+」チャンネル(演算子のない「モードレス」チャンネル)[51]や、「!」チャンネル(通常はタイムスタンプのないネットワーク上のタイムスタンプ付きチャンネルの一種)があります。[52]
モード
ユーザーとチャンネルには、大文字と小文字を区別する個別の文字[53]で表されるモードがあり、 MODEコマンドを使用して設定されます。[54]ユーザー モードとチャンネル モードは別々であり、同じ文字を使用して異なる意味を表すことができます (たとえば、ユーザー モード "i" は非表示モードですが、チャンネル モード "i" は招待専用です。[55] )。モードは通常、ターゲット (ユーザーまたはチャンネル)、設定 (+) または設定解除 (-) するモードのセット、およびモードに必要なパラメーターを受け取る mode コマンドを使用して設定および設定解除されます。
一部のチャネル モードはパラメーターを受け取り、他のチャネル モードはチャネルのユーザーに適用されたり、チャネル全体に適用するのではなく、チャネルに関連付けられたリストからマスク (禁止マスクなど) を追加または削除したりします。[56]チャネルのユーザーに適用されるモードには、names 応答[57] (チャネルに初めて参加したときにクライアントに送信される[49]および names コマンドの使用) でモードを表すために使用される関連シンボルがあり、多くのクライアントでは、チャネル内のユーザーのクライアントの表示リストでモードを表すために、またはユーザーのモードの独自のインジケーターを表示するために使用されます。
受信モードメッセージを正しく解析し、チャンネルの状態を追跡するために、クライアントはどのモードがどのタイプであるか、またチャンネル上のユーザーに適用されるモードのどのシンボルがどの文字に対応するかを知る必要がある。IRCの初期の実装では、これはクライアントにハードコードする必要がありましたが、現在ではISUPPORTと呼ばれるプロトコルの事実上の標準拡張があり、接続時に数値005を使用してこの情報をクライアントに送信します。[58] [59]
IRC には、チャンネル上のユーザーに適用されるモードに関して、小さな設計上の欠陥があります。チャンネルの初期状態を確立するために使用される名前メッセージは、チャンネル上のユーザーごとに 1 つのモードしか送信できませんが、[57] 1 人のユーザーに複数のモードを設定できます。たとえば、ユーザーがチャンネルでオペレーター ステータス (+o) と音声ステータス (+v) の両方を保持している場合、新しいクライアントは優先度の低いモード (つまり音声) を表示できません。この問題の回避策は、クライアント側とサーバー側の両方で可能です。一般的な解決策は、IRCv3 の「マルチプレフィックス」拡張機能を使用することです。[60]
標準 (RFC 1459) モード
多くのデーモンやネットワークでは、追加のモードを追加したり、上記のリストにあるモードの動作を変更したりしています。[62] [63] [64] [65]
チャンネルオペレーター
チャンネルオペレータは、IRC チャンネルを管理するクライアントです。IRC チャンネル オペレータは、名前の横にある記号またはアイコンで簡単に見分けることができます (クライアントの実装によって異なりますが、通常は「@」記号のプレフィックス、緑色の円、またはラテン文字の「+o」/「o」)。ほとんどのネットワークでは、オペレータは次のことができます。
- ユーザーをキックします。
- ユーザーを禁止します。
- 別のユーザーに IRC チャネル オペレータ ステータスまたは IRC チャネル音声ステータスを付与します。
- チャネル モード +t が設定されているときに IRC チャネルのトピックを変更します。
- IRC チャネル モードのロックを変更します。
オペレーター
また、ローカル サーバーまたはネットワーク全体に対して高い権限を持つユーザーもいます。これらは IRC オペレーター[66]と呼ばれ、 IRCops または Opers (チャネル オペレーターと混同しないでください) と略されることもあります。IRCd の実装はさまざまであるため、特定の IRCd における IRC オペレーターの権限も異なります。RFC 1459 [66]では、IRC オペレーターはネットワークをクリーンな状態に保つための「必要悪」であり、サーバーの切断と再接続を行う必要があるとされています。さらに、悪意のあるユーザーや有害な自動プログラムが IRC に侵入するのを防ぐため、IRC オペレーターは通常、クライアントを切断し、IP アドレスまたはサブネット全体を完全に禁止することができます。サービス (NickServ など) を運ぶネットワークでは、通常、IRC オペレーターが基本的な「所有権」の問題も処理できます。さらなる特権権限には、チャンネル禁止の無効化(操作されていない場合は参加できないチャンネルに参加できる)、操作されていないと参加できないチャンネルで自分自身を操作できること、チャンネルで常に自動操作できることなどが含まれます。
ホストマスク
ホストマスクは、 IRCサーバーに接続されたIRCクライアントの一意の識別子です。[67] [68] IRCサーバー、サービス、およびボットを含む他のクライアントは、特定のIRCセッションを識別するためにホストマスクを使用できます。
ホストマスクの形式は です。ホストマスクは電子メール アドレスnick!user@hostに似ていますが、混同しないでください。
ニックネーム部分はユーザーが選択したニックネームで、接続中に変更される可能性があります。ユーザー部分は、クライアントのidentによって報告されたユーザー名です。 [69] identがクライアントで利用できない場合は、クライアントが接続したときに指定されたユーザー名にチルダをプレフィックスとして付けて使用されます。[70]
ホスト部分は、クライアントが接続しているホスト名です。クライアントのIP アドレスがサーバーによって 有効なホスト名に解決できない場合は、ホスト名の代わりに使用されます。
クライアントの IP アドレスやホスト名を公開することはプライバシーに影響を及ぼすため、一部のIRC デーモンは、 InspIRCd や UnrealIRCd の「+x」モードなどのプライバシー機能も提供しています。これはクライアントの IP アドレスをハッシュ化するか、クライアントのホスト名の一部をマスクして、IRCops 以外のユーザーには読み取れないようにします。ユーザーは、匿名性をさらに高めるために、ホストマスクに表示される「仮想ホスト」(または「vhost」) を要求することもできます。Libera ChatやFreenodeなどの一部の IRC ネットワークでは、ユーザーがグループまたはプロジェクトに所属していることを示すために、これを「クローク」として使用しています。[71]
URI スキーム
インターネットリレーチャットには、暫定的に認められたURI(Uniform Resource Identifier )スキームが3つあります: irc、、ircsおよびですirc6。[72]サポートされている場合、さまざまな形式の
ハイパーリンクが許可されます。
irc://<ホスト>[:<ポート>]/[<チャンネル>[?<チャンネルキーワード>]] ircs://<ホスト>[:<ポート>]/[<チャンネル>[?<チャンネルキーワード>]] irc6://<ホスト>[:<ポート>]/[<チャンネル>[?<チャンネルキーワード>]]
(角括弧([,])で囲まれた項目はオプションです)は、必要に応じて指定されたホスト(またはIRCクライアントが知っている場合はネットワーク)に接続し、指定されたチャンネルに参加するために使用されます。[73](これはクライアント自体で使用することも、Webブラウザなどの別のアプリケーションから使用することもできます)。ircはデフォルトのURIで、irc6はIPv6を使用して接続することを指定し、ircsは安全な接続を指定します。
仕様によれば、英数字で始まるチャンネル名の前に通常のハッシュ記号(#) が付加され、省略できるようになります。一部の実装 (mIRC など)では、URL に含まれていると、無条件にこれが行われ、(通常は意図しない) 余分な部分 (##channel など) が生成されます。
いくつかの実装では、カンマで区切って複数のチャネルを指定できる。[74]
課題
IRCの当初の設計上の問題点としては、共有状態データの量[75] [76]がスケーラビリティの制限となること、[77]固有のユーザーIDが欠如しているためニックネーム衝突問題が発生すること、[78]サイクリックルーティングによるネットスプリットからの保護が欠如していること、 [79] [80]リアルタイムのユーザープレゼンス情報と引き換えにスケーラビリティが犠牲になること、[81]プロトコルの脆弱性により悪用のプラットフォームが提供されること、[82]透過的で最適化可能なメッセージパッシングがないこと、[83]暗号化がないことなどが挙げられます。[84]これらの問題のいくつかは、 Modern IRCで解決されています。
攻撃
IRC 接続は暗号化されず、通常は長時間にわたるため、DoS/DDoS 攻撃者やハッカーにとって魅力的なターゲットとなります。このため、IRC ネットワークが乗っ取り戦争などの攻撃を受けないようにするには、慎重なセキュリティ ポリシーが必要です。IRCネットワークには、悪影響を及ぼす K ラインまたはG ラインのユーザーやサーバーが存在する可能性もあります。
一部の IRC サーバーは、セキュリティ上の目的でSSL/TLS接続をサポートしています。これは、IRC ユーザーのパスワードを取得するためにパケット スニファープログラムが使用されるのを防ぐのに役立ちますが、IRC チャネルの公開性のため、この範囲を超えてはあまり役に立ちません。SSL 接続には、クライアントとサーバーの両方のサポートが必要です (ユーザーが SSL バイナリと IRC クライアント固有のパッチまたはモジュールをコンピューターにインストールする必要がある場合があります)。一部のネットワークでは、サーバー間接続に SSL を使用し、+SSSL 接続ユーザーのみをチャネルに許可し、クリア テキストでのオペレーターの識別を許可しない特別なチャネル フラグ (など) を提供して、SSL の利点をより有効に活用しています。[85] [86]
IRC は、偽のICMP到達不能メッセージを使用してTCPベースの IRC 接続を切断(ヌーキング) し、ユーザーを困らせたり乗っ取りを容易にしたりするなど、さまざまな種類のインターネット攻撃の初期の実験室としての役割を果たしました。
虐待防止
IRC 実装に関する最も論争の多い技術的問題のうち、今日まで残っているものの 1 つは、「ニックネーム/チャネル遅延」プロトコルと「タイムスタンプ」プロトコルの利点です。どちらの方法もサービス拒否攻撃の問題を解決するために存在しますが、アプローチは大きく異なります。実装された元の IRC プロトコルの問題は、2 つのサーバーが分割されて再結合すると、ネットワークの両側でチャネルが単純に結合されるという点です。ユーザーが「分割」サーバーに参加し、ネットワークの反対側に存在するチャネルが空いている場合、オペレーター ステータスを取得できれば、ネット分割が終了した後に「結合」チャネルのチャネル オペレーターになります。ユーザーがネットワークの反対側に存在するニックネームを取得した場合、サーバーは再結合時に両方のユーザーを強制終了します (「ニックネーム衝突」)。これは、チャネル上のすべてのユーザーを「大量強制終了」するために悪用されることがよくありました。その結果、悪用に対処するオペレーターがいない「オペレーターレス」チャネルが作成されました。これは IRC 内で問題を引き起こすだけでなく、ネットスプリットを引き起こしてそれを悪用する ために IRC サーバーに対してサービス拒否攻撃を実行する人々を奨励しました。
ニックネーム遅延(ND) とチャンネル遅延(CD) 戦略は、再接続と名前の変更を遅らせることで不正使用を防ぐことを目的としています。ユーザーがサインオフしてニックネームが使用可能になった後、またはすべてのユーザーが離脱したためにチャンネルが存在しなくなった後 (ネットスプリット中によく発生します)、サーバーは一定の時間 (遅延) が経過するまで、どのユーザーもそのニックネームを使用したり、そのチャンネルに参加したりすることを許可しません。この背後にある考え方は、ネットスプリットが発生しても、不正使用者にとっては役に立たないということです。不正使用者はニックネームを取得したり、チャンネルでオペレーター ステータスを取得したりできないため、ニックネームの衝突やチャンネルの「マージ」は発生しません。ある程度、これは正当なユーザーに不便をかけます。正当なユーザーは、再参加後に一時的に別の名前を使用せざるを得なくなる可能性があります (アンダースコアを追加するのが一般的です)。
タイムスタンプ プロトコルは、ニックネーム/チャンネル遅延の代替手段であり、タイムスタンプ付きの優先順位を使用して衝突を解決します。ネットワーク上のすべてのニックネームとチャンネルには、タイムスタンプ (作成された日時) が割り当てられます。ネットスプリットが発生すると、各側の 2 人のユーザーは同じニックネームまたはチャンネルを自由に使用できますが、両側が結合されると、1 人だけが生き残ることができます。ニックネームの場合、TS に従って新しいユーザーが強制終了されます。チャンネルが衝突すると、メンバー (チャンネル上のユーザー) は結合されますが、分割の「負けた」側のチャンネル オペレーターはチャンネル オペレーターのステータスを失います。
TS は、設計と実装の両面で ND/CD よりもはるかに複雑なプロトコルであり、いくつかの改訂を経ているにもかかわらず、一部の実装では依然として「同期解除」(同じネットワーク上の 2 つのサーバーがネットワークの現在の状態について意見が一致しない) の問題があり、「負けた」側で許可される内容があまりにも寛容すぎるという問題があります。たとえば、元の TS プロトコルでは、負けたチャンネルでユーザーが禁止やその他のモードを設定することに対する保護はなく、それらのモードを設定したユーザーはチャンネル オペレーターのステータスを失いますが、分割が再結合したときにそれらのモードがマージされます。最近の TS ベースの IRC サーバーの中には、不正使用をさらに抑制するために、タイムスタンプに加えて何らかの形式の ND や CD も組み込まれているものもあります。
今日のほとんどのネットワークは、タイムスタンプ方式を使用しています。タイムスタンプと ND/CD の不一致により、いくつかのサーバーがEFnetから分離し、新しいIRCnetを形成しました。分離後、EFnet は TS プロトコルに移行し、IRCnet は ND/CD を使用しました。
最近のバージョンの IRCnet ircd および TS6 プロトコルを使用する ircd (Charybdis を含む) では、ND は SAVE と呼ばれるメカニズムによって拡張/置き換えられています。このメカニズムは、IRC サーバーに接続するとすべてのクライアントにUID を割り当てます。この ID は数字で始まりますが、ニックネームでは禁止されています (ただし、一部の ircd、つまり IRCnet および InspIRCd では、クライアントがニックネームとして独自の UID に切り替えることができます)。
同じニックネームを持つ 2 つのクライアントがネットスプリットの異なる側から参加した場合 (「ニックネーム衝突」)、この衝突を最初に発見したサーバーは両方のクライアントにニックネームを UID に変更するように強制し、両方のクライアントが切断されるのを防ぎます。IRCnet では、両方のクライアントが元のニックネームに戻って再び衝突するのを防ぐために、ニックネームは一定期間ロックされます (ND)。
クライアント
クライアントソフトウェア

クライアントソフトウェアは、様々なオペレーティングシステムやソフトウェアパッケージ、ウェブベースやゲーム内に存在します。Windows 、Unix、Linux、macOS 、モバイルオペレーティングシステム( iOSやAndroidなど)など、さまざまなオペレーティングシステムでさまざまなクライアントが利用可能です。Windowsでは、mIRCが最も人気のあるクライアントの1つです。[ 87] Linuxディストリビューションの中には、 HexChatがプリインストールされたLinux Mintなど、IRCクライアントがプリインストールされたものもあります。
プラグインを通じて拡張可能なプログラムの中には、IRC クライアントのプラットフォームとしても機能するものがあります。たとえば、完全にEmacs Lispで書かれたERCというクライアントは、Emacs のバージョン 22.3 に含まれています。したがって、Emacs を実行できるプラットフォームであれば、どのプラットフォームでも ERC を実行できます。
多くのWeb ブラウザには、次のような IRC クライアントが組み込まれています。
- Operaにはかつてクライアントがありましたが、現在はIRCをサポートしていません。
- Mozilla Firefox用のChatZillaアドオン(Firefox 56 以前用。SeaMonkey の組み込みコンポーネントとして含まれています)。
Mibbitやオープンソースの KiwiIRCなどの Web ベースのクライアントは、ほとんどのブラウザで実行できます。
War§ow、[88] Unreal Tournament ( Unreal Tournament 2004まで)、[89] Uplink、[90] Spring Engineベースのゲーム、0AD、ZDaemonなどのゲームにはIRCが組み込まれています。[91]
Ustreamのチャットインターフェースはカスタム認証付きのIRC [92]であり、 Twitch(旧Justin.tv)のチャットインターフェースも同様である。 [93] [94]
ボット
IRCにおけるボットの典型的な用途は、チャットベースのゲームをホストしたり、外部イベントの通知を提供したりといった、 IRCサービスや特定の機能をチャンネル内で提供することです。しかし、一部のIRCボットは、サービス拒否、スパム、または悪用などの悪質な攻撃を開始するために使用されます。[95]
バウンサー
サーバー上でデーモンとして実行され、永続的なプロキシとして機能するプログラムは、BNC またはバウンサーとして知られています。その目的は、IRC サーバーへの接続を維持し、サーバーとクライアント間のリレーとして機能したり、単にプロキシとして機能することです。[要出典]クライアントがネットワーク接続を失った場合、BNC は接続を維持し、すべてのトラフィックを後で配信するためにアーカイブします。これにより、ユーザーはサーバーへの接続を中断することなく IRC セッションを再開できます。[96]
さらに、バウンサーのような効果を得る方法として、IRCクライアント(通常はテキストベース、たとえばIrssi)を、ユーザーがssh経由で接続する常時接続サーバー上で実行することもできます。これにより、ssh機能のみを持ち、実際のIRCクライアントがインストールされていないデバイスでもIRCに接続でき、IRCセッションを共有できます。[97]
SSH接続が閉じられたときにIRCクライアントが終了しないようにするには、クライアントをGNU Screenやtmuxなどのターミナルマルチプレクサ内で実行します。これにより、IRCネットワークに常に接続したまま、ユーザーが関心のあるチャネルでの会話を記録したり、ネットワーク上でチャネルの存在を維持したりすることができます。この設定をモデルにして、2004年にクライアントサーバーに従うIRCクライアントであるSmuxiがリリースされました。[98] [99]
検索エンジン
IRC 上でユーザーが探しているものを見つけるのに役立つ検索エンジンは数多くあります。[100] [101]一般に、検索エンジンは「バックエンド」(または「スパイダー/クローラー」) とフロントエンドの「検索エンジン」の 2 つの部分で構成されています。
バックエンド (スパイダー/ウェブクローラー) は、検索エンジンの主力です。IRC サーバーをクロールして、サーバー間で送信される情報をインデックス化する役割を担います。インデックス化される情報は通常、チャネル テキスト (パブリック チャネルで公開されるテキスト) のみで構成されます。保存方法は、通常、MySQLやOracleなどのリレーショナル データベースです。[要出典]
フロントエンドの「検索エンジン」は、データベースへのユーザー インターフェイスです。これにより、ユーザーはインデックス付けされた情報のデータベースを検索して、探しているデータを取得できます。これらのフロントエンド検索エンジンは、さまざまなプログラミング言語でコーディングすることもできます。
ほとんどの検索エンジンには、IRC をクロールしてデータ自体をインデックス化する単一のアプリケーションである独自のスパイダーがあります。ただし、他の検索エンジンは「ユーザー ベース」のインデックス作成ツールです。後者は、ユーザーが IRC クライアントに「アドオン」をインストールすることに依存しています。アドオンは、ユーザーがたまたま使用しているチャネルのチャネル情報をデータベースに送信します。[引用が必要]
多くのユーザーは、多くの IRC クライアントに組み込まれているログ機能を使用して、独自のアドホック検索エンジンを実装しています。これらの検索エンジンは通常、ボットとして実装され、特定のチャネルまたは関連するチャネルのグループ専用です。
文字エンコーディング
IRC には、7 ビットASCIIレパートリー外の文字を転送する方法に関する、世界的に受け入れられている単一の標準規則がまだありません。IRC サーバーは通常[明確化が必要]、文字の解釈や再コード化を行わずに、クライアントから別のクライアントにメッセージをバイト シーケンスとして転送します。IRC プロトコル ( MIMEやHTTPなどとは異なり) には、文字エンコード オプションを通知およびネゴシエートするメカニズムがありません。このため、適切な文字コーデックを選択する責任はクライアントにあります。実際には、IRC チャネルでは、それぞれの言語コミュニティのオペレーティング システム (特にUnix派生) でも使用されているのと同じ文字エンコードが主に使用されています。
- 7ビット時代: IRCの初期の頃、特にスカンジナビア語とフィンランド語のユーザーの間では、ISO 646の国別バリアントが文字エンコーディングとして主流でした。これらは、Ä Ö Å ä ö å などの非ASCII文字をコード位置0x5B 0x5C 0x5D 0x7B 0x7C 0x7D ( US-ASCII : [ \ ] { | } ) にエンコードします。そのため、これらのコードはニックネームで常に許可されています。RFC 1459によれば、ニックネームの { | } はそれぞれ [ \ ] の小文字として扱われるべきです。[14] 1990年代後半までに、7ビットエンコーディングの使用はISO 8859-1に取って代わられ、そのような等価マッピングは一部のIRCデーモンから削除されました。
- 8 ビット時代: 1990 年代初頭から、 ISO 8859-1などの 8 ビット エンコーディングがヨーロッパ言語で一般的に使用されるようになりました。ロシアのユーザーはKOI8-R、ISO 8859-5 [引用が必要]、CP1251のいずれかを選択でき、2000 年頃から、現代のロシアの IRC ネットワークはキリル文字で一般的に使用されるこれらの異なるエンコーディング間で変換を行っています。
- マルチバイト時代:中国、日本、韓国の表語文字を使用する東アジアの IRC チャンネルでは、長い間、EUCやISO-2022-JPなどのマルチバイト エンコーディングが使用されてきました。2002 年頃から Linux および Unix プラットフォームで ISO 8859 からUTF-8への移行が一般的になり、UTF-8 はヨーロッパのチャンネルで以前使用されていた多くの 8 ビット エンコーディングの代替としてますます普及してきました。一部の IRC クライアントは現在、同じチャンネルで ISO 8859-1 と UTF-8 の両方のメッセージを読み取ることができ、どちらのエンコーディングが使用されているかをヒューリスティックに自動検出します。UTF-8 への移行は、特にフィンランド語圏の IRC (Merkistö (フィンランド語) ) で始まりました。
現在、 Unicode / ISO 10646の UTF-8 エンコードは、 510 バイトのメッセージ サイズ制限が緩和された場合、すべての IRC 通信の将来の標準文字エンコードとして最も有力な候補となるでしょう。UTF-8 は ASCII と互換性があり、一般的に使用される他のすべてのコード化文字セット標準のスーパーセットをカバーしています。
ファイル共有
従来のP2Pファイル共有と同様に、ユーザーはカスタマイズされたIRCボットやIRCクライアントのスクリプトを使用して、ファイルサーバーを作成し、互いにファイルを共有することができます。多くの場合、ユーザーはIRCボットのネットワークを介してグループを組み、ウェアーズを配布します。 [102]
技術的には、IRC自体はファイル転送のメカニズムを提供していません。ファイル共有はIRCクライアントによって実装され、通常はDirect Client-to-Client(DCC)プロトコルを使用して、クライアント間でプライベートメッセージを交換することでファイル転送がネゴシエートされます。大多数のIRCクライアントはDCCファイル転送をサポートしているため、ファイル共有はIRCの不可欠な機能であるという見方があります。[103]ただし、このプロトコルが一般的に使用されているため、DCCスパムが発生することもあります。DCCコマンドは、脆弱なクライアントを悪用して、サーバーから切断したり、クライアントを終了したりするなどのアクションを実行させるためにも使用されています。
参照
- チャットルーム
- クライアント間プロトコル
- インスタント メッセージング プロトコルの比較
- IRC クライアントの比較
- ハムネット・プレイヤーズ
- インターネットスラング
- IRC コマンドのリスト
- 配信チャンネル
- マトリックス(プロトコル)とXMPP、代替チャットプロトコル
引用
- ^ 「 1対多」。インターネットリレーチャットプロトコル。p. 11. sec. 3.2。doi : 10.17487/RFC1459。RFC 1459。
- ^ 「One- To -One Communication」。インターネットリレーチャット:アーキテクチャ。p. 5. sec. 5.1。doi : 10.17487/RFC2810。RFC 2810。
- ^ Rollo, Troy. 「DCC プロトコルの説明」IRCHelp.org 。2011年4 月 8 日閲覧。
- ^ Wang, Wallace (2004 年 10 月 25 日)。「インスタント メッセージングとオンライン チャット ルーム: インターネット リレー チャット (IRC)」。このファイル共有の本を盗んでください(第 1 版)。カリフォルニア州サンフランシスコ: No Starch Press。61~ 67 ページ。ISBN 978-1-59327-050-6。
- ^ abc 「IRCは死んだ、IRCは長生きする」Pingdom 2012年4月24日。2017年8月15日時点のオリジナルよりアーカイブ。2016年4月25日閲覧。
- ^ 「IRCネットワーク – トップ100」。irc.netsplit.de 。 2023年10月26日閲覧。
- ^ abcdefghijk Stenberg, Daniel. 「IRC (インターネット リレー チャット) の歴史」 。 2016 年4 月 25 日閲覧。
これらすべてを私が経験したわけではありません。この記事を書くために、さまざまな場所で情報を見つけ、さまざまな人から情報を得ました。この件で私を助けてくれた人たちには、Greg "wumpus" Lindahl、Vesa "vesa" Ruokonen、James Ng、Tuomas Heino、Richard (eagle`s on undernet)、Ari Lemmke などがいます。
- ^ ab Oikarinen, Jarkko . 「IRC の設立」mIRC . 2011 年 4 月 27 日時点のオリジナルよりアーカイブ。2011年4 月 8 日閲覧。
- ^ ab 「IRC(インターネットリレーチャット)の歴史」. daniel.haxx.se . 2023年7月22日閲覧。
- ^ 「1991年のソビエトクーデター未遂事件時のIRC記録」ノースカロライナ州チャペルヒル:ibiblio。2009年6月28日時点のオリジナルよりアーカイブ。2011年4月8日閲覧。
- ^ 「湾岸戦争のIRCログ」ノースカロライナ州チャペルヒル:ibiblio 。 2011年4月8日閲覧。
- ^ 「オンラインコミュニティにおける主要なイベントのログ」ノースカロライナ州チャペルヒル:ibiblio 。 2011年4月8日閲覧。
- ^ abc 「はじめに」。インターネットリレーチャットプロトコル。p. 4. sec. 1. doi : 10.17487/RFC1459 . RFC 1459。
- ^ abc 「文字コード」。インターネットリレーチャットプロトコル。p. 7. sec. 2.2. doi : 10.17487/RFC1459 . RFC 1459。
- ^ Engen, Vegard (2000年5月). 「The Great Split」. IRC.org . 2016年4月25日閲覧。
- ^ 「チャンネルモード」。UnrealIRCdドキュメント wiki。2018年1 月 6 日閲覧。
- ^ 「クローキング」。UnrealIRCdドキュメント wiki。2018年1 月 6 日閲覧。
- ^ 「Blitzed Open Proxy Monitor がシャットダウン」。Blitzed
IRC ネットワークによって提供されていた Open Proxy Monitor がシャットダウンされました。データベースが非常に大きいため、チームがバックアップしたり、サービスを継続するための新しい場所を見つけたりすることはほぼ不可能です。それに加えて、チーム メンバーのほとんどには、サービスを継続する時間がありません。
- ^ "IRCv3". IRCv3 ワーキンググループ。2016 年。2016 年4 月 25 日閲覧。IRCv3
ワーキンググループは、下位互換性のある拡張機能を使用して IRC プロトコルを強化、維持、標準化するために取り組んでいる IRC クライアントおよびサーバー ソフトウェア作成者の集まりです。
- ^ 「ネットワーク - IRCv3」。2019年。 2019年8月9日閲覧。
- ^ 「IRC ネットワーク - アルファベット順」. netsplit.de . 2022 年1 月 12 日閲覧。
- ^ 「IRCネットワーク - トップ100」。netsplit.de 。 2022年1月12日閲覧。
- ^ 「netsplit.de top 10」。2021年1月15日閲覧。
- ^ ab アレックス・チャララビディス (1999 年 12 月 15 日)。「Macintosh での IRC: Ircle」。IRCの本: インターネット リレー チャットの究極ガイド(第 1 版)。カリフォルニア州サンフランシスコ: No Starch Press。61 ページ。ISBN 978-1-886411-29-6
EFnet、IRCnet、Undernet、DALnet などの Big Four のような大規模ネットワークでは、Ircle を使用して何千ものチャネルを一覧表示しようとすると、情報量が多すぎて常に切断されますが、直接 Ethernet 接続を使用している場合は、他のクライアントでは通常、この問題に対処できます
。 - ^ ab ジョーンズ、スティーブ編 (2002 年 12 月 10 日)。「インターネット リレー チャット」。ニュー メディア百科事典: コミュニケーションとテクノロジーの必須リファレンス(第 1 版)。カリフォルニア州サウザンドオークス: SAGE 出版。p. 257。ISBN 978-0-7619-2382-4現在、
何百もの独立した IRC ネットワークがありますが、「ビッグ 4」は EFNet、UnderNet、Dalnet、および IRCnet です。
- ^ ab リトナー、ドン(1999年3月3日)。iMac Book(第1版)。アリゾナ州スコッツデール:コリオリスグループ。p. 215。ISBN 978-1-57610-429-3大規模なネットワークはいくつかあり、
EFnet、UnderNET、DALnet、IRCnet が Big Four を構成しています。
- ^ Turban, Efraim; Leidner, Dorothy; McLean, Ephraim; Wetherbe, James (2005 年 2 月 7 日)。「コミュニケーション」。経営のための情報技術: デジタル経済における組織の変革(第 5 版)。ニュージャージー州ホーボーケン: John Wiley & Sons。pp. 106–107。ISBN 978-0-471-70522-2従来、
最大のネットワークは、EFNet、IrcNet、QuakeNet、および UnderNet の「ビッグ 4」としてグループ化されてきました。
- ^ 「IRC ネットワーク – トップ 100」。irc.netsplit.de . netsplit.de . 2021 年1 月 15 日閲覧。
- ^ 「サーバー」。インターネットリレーチャットプロトコル。p. 4. sec. 1.1. doi : 10.17487/RFC1459 . RFC 1459。
- ^ 「クライアント」。インターネットリレーチャット: アーキテクチャ。p. 3. sec. 2.2. doi : 10.17487/RFC2810 . RFC 2810。
- ^ 「クライアント」。インターネットリレーチャットプロトコル。p. 5. sec. 1.2. doi : 10.17487/RFC1459 . RFC 1459。
- ^ 「ポート番号」。カリフォルニア州マリナデルレイ:インターネット割り当て番号局。2011年4月6日。 2021年4月5日閲覧。
- ^ 「接続メッセージ」。インターネットリレーチャットプロトコル。p. 29. sec. 4.3.5. doi : 10.17487/RFC1459 . RFC 1459。
- ^ Lucas, Mark; Singh, Abhishek; Cantrell, Chris (2006 年 10 月 5 日)。「ファイアウォールの定義」。Henmi, Anne (編) 著『ファイアウォール ポリシーと VPN 構成』。マサチューセッツ州ロックランド: Syngress Publishing。p. 93。ISBN 978-1-59749-088-7。
- ^ Abraham, Dalen (1998 年 6 月). インターネットリレーチャットプロトコル (IRCX) の拡張. IETF . ID draft-pfenning-irc-extensions-04 . 2011 年4 月 8 日閲覧。
- ^ 「アーキテクチャ」。インターネットリレーチャット: アーキテクチャ。pp. 3 – 4. sec. 3. doi : 10.17487/RFC2810。RFC 2810。
- ^ 「はじめに」。インターネットリレーチャット:アーキテクチャ。p. 2. sec. 1. doi : 10.17487/RFC2810 . RFC 2810。
- ^ 「アルゴリズム」。インターネットリレーチャットプロトコル。p. 64. sec. 9.3. doi : 10.17487/RFC1459 . RFC 1459。
- ^ 「ネットワーク輻輳」。インターネットリレーチャット:アーキテクチャ。pp. 7 – 8. sec. 6.3。doi : 10.17487/RFC2810。RFC 2810。
- ^ 「 To A Channel」。インターネットリレーチャット:アーキテクチャ。pp. 5 – 6. sec. 5.2.1。doi : 10.17487/RFC2810。RFC 2810。
- ^ 「LAN 用 IRC デーモン」 。2014年10 月 2 日閲覧。
- ^ 「独自の IRC サーバーを実行する」 。2014年10 月 2 日閲覧。
- ^ 「疑似 BNF のメッセージ形式」。インターネット リレー チャット プロトコル。p. 8. sec. 2.3.1。doi : 10.17487/RFC1459。RFC 1459。
- ^ 「数値応答」。インターネットリレーチャットプロトコル。p. 10. sec. 2.4。doi : 10.17487/RFC1459。RFC 1459。
- ^ IRC チャットルーム
- ^ 「IRC リスト モード – リストのペアの混乱を示すリスト モード拡張」 2009 年 11 月 25 日。 2011 年4 月 8 日閲覧。
- ^ ab 「グループ(チャネル)へ」。インターネットリレーチャットプロトコル。p. 11. sec. 3.2.2。doi : 10.17487/RFC1459。RFC 1459。
- ^ 「リストメッセージ」。インターネットリレーチャットプロトコル。p. 24. sec. 4.2.6。doi : 10.17487/RFC1459。RFC 1459。
- ^ ab 「参加メッセージ」。インターネットリレーチャットプロトコル。p. 19. sec. 4.2.1。doi : 10.17487/RFC1459。RFC 1459。
- ^ 「チャネルスコープ」。インターネットリレーチャット:チャネル管理。pp. 3 – 4. sec. 2.2. doi : 10.17487/RFC2811 . RFC 2811。
- ^ 「チャネルプロパティ」。インターネットリレーチャット:チャネル管理。p. 4. sec. 2.3. doi : 10.17487/RFC2811 . RFC 2811。
- ^ 「チャネルの有効期間」。インターネットリレーチャット:チャネル管理。p. 5. sec. 3. doi : 10.17487/RFC2811。RFC 2811。
- ^ 「チャンネルモード」。インターネットリレーチャット:チャンネル管理。p. 7. sec. 4. doi : 10.17487/RFC2811 . RFC 2811。
- ^ 「モードメッセージ」。インターネットリレーチャットプロトコル。p. 21. sec. 4.2.3。doi : 10.17487/RFC1459。RFC 1459。
- ^ 「チャネルモード」。インターネットリレーチャットプロトコル。pp. 21 – 22。sec. 4.2.3.1。doi : 10.17487/RFC1459。RFC 1459。
- ^ 「チャネル アクセス制御」。インターネット リレー チャット: チャネル管理。pp. 10 – 11. sec. 4.3。doi : 10.17487/RFC2811。RFC 2811。
- ^ ab "コマンド応答: 353 RPL_NAMREPLY". インターネットリレーチャットプロトコル。p. 51. doi : 10.17487/RFC1459 . RFC 1459。
- ^ Roeckx, Kurt (2004 年 10 月 14 日). 「The 005 numeric: ISUPPORT」. irc.org . 2011 年4 月 10 日閲覧。
- ^ Brocklesby, Edward (2002 年 9 月). IRC RPL_ISUPPORT 数値定義. IETF . ID draft-brocklesby-irc-isupport-03 . 2011 年4 月 10 日閲覧。
- ^ 「'マルチプレフィックス' 拡張 - IRCv3」。
- ^ 「Operwall メッセージ」。インターネット リレー チャット プロトコル。p. 41. sec. 5.6. doi : 10.17487/RFC1459。RFC 1459。
- ^ Butcher, Simon (2005 年 1 月 12 日). 「IRC ユーザー モード リスト」. alien.net.au . 2011 年4 月 10 日閲覧。
- ^ Butcher, Simon (2005 年 1 月 12 日). 「IRC チャンネル モード リスト」. alien.net.au . 2011 年4 月 10 日閲覧。
- ^ Butcher, Simon (2005 年 1 月 12 日). 「IRC サーバー モード リスト」. alien.net.au . 2011 年4 月 10 日閲覧。
- ^ Olsen, Tommy. 「IRCd Modes」. webtoman.com. 2011年10月15日時点のオリジナルよりアーカイブ。2011年4月10日閲覧。
- ^ ab "Operators". インターネットリレーチャットプロトコル。p. 5. sec. 1.2.1. doi : 10.17487/RFC1459 . RFC 1459。
- ^ ニコラ、デーリング;アレクサンダー・シェスタグ (2003 年 9 月 23 日)。 「Soziele Norman の美徳グループ: ein empirische Analyze am Beispiel ausghewähiter Chat-Channels」。 Thiedeke、Udo (編)。Virtuelle Gruppen: Charakteristika und Problemdimensionen (ドイツ語) (第 2 版)。スプリンガーVS 。 314、337ページ。ISBN 978-3-531-33372-4. 2010年3月30日閲覧。
- ^ ロジャース、ラス (2004 年 12 月 1 日)。「恐怖の心」。デヴォスト、マシュー G. (編)。『テロネットワークのハッキング: 秘密のチャンネルの静かな脅威』 (第 1 版)。マサチューセッツ州ロックランド: Syngress Publishing。p. 10。ISBN 978-1-928994-98-5. 2010年3月30日閲覧。
- ^ Petersen, Julie K. 編 (2002 年 5 月 29 日)。「インターネット リレー チャット」。電気通信図解辞典(第 2 版)。CRCプレス。p. 500。ISBN 978-0-8493-1173-4. 2010年3月30日閲覧。
- ^ 「よくある質問」. freenode . 2010年3月26日時点のオリジナルよりアーカイブ。2010年3月30日閲覧。
- ^ 「IRC/Cloaks」メタウィキ。 2011年11月27日閲覧。
- ^ 「Uniform Resource Identifier (URI) Schemes」。Internet Assigned Numbers Authority 。 2012年10月14日閲覧。
- ^ Butcher, Simon (2003 年 1 月). インターネットリレーチャットエンティティの Uniform Resource Locator スキーム。IETF。ID draft -butcher-irc-url-04。2011年4 月 10 日閲覧。
- ^ “node-irc”. npm . 2020年1月26日. 2021年7月30日閲覧。
- ^ 「サイズ」。コンピュータネットワーク会議に関する議論。pp. 5 – 6. sec. 2.5.1。doi : 10.17487/RFC1324。RFC 1324。
- ^ 「スケーラビリティ」。インターネットリレーチャット:アーキテクチャ。p. 7. sec. 6.1。doi : 10.17487/RFC2810。RFC 2810。
- ^ ローシュ 2003 1.2.1 成長
- ^ 「ユーザー識別」。コンピュータネットワーク会議に関する議論。p. 10. sec. 5.4.1。doi : 10.17487/RFC1324。RFC 1324。
- ^ 「ツリーとサイクル」。コンピュータネットワーク会議に関する議論。p. 10. sec. 5.4.2。doi : 10.17487/RFC1324。RFC 1324。
- ^ Loesch 2003 1.2.2 ネットワーク障害
- ^ 「状態情報の問題」。コンピュータネットワーク会議に関する議論。p. 4. sec. 2.1. doi : 10.17487/RFC1324。RFC 1324。
- ^ Loesch 2003 1.2.3 社会学的および安全保障的側面
- ^ 「メッセージ パッシング」。コンピュータ ネットワーク会議に関する議論。p. 7. sec. 5.2.1。doi : 10.17487/RFC1324。RFC 1324。
- ^ 「会議のセキュリティ」。コンピュータネットワーク会議に関する議論。p. 8. sec. 5.2.4. doi : 10.17487/RFC1324。RFC 1324。
- ^ 「EsperNet でヘルプを受ける」。EsperNet IRC ネットワーク。2012年7 月 31 日閲覧。
- ^ brandon (2010 年 5 月 18 日). 「新機能: ユーザー向け SSL」. DALnet . 2012 年7 月 31 日閲覧。
- ^ Smith, Roderick W. (2000 年 4 月 8 日)。「インターネット: IRC を使ってヘルプを得る」。マルチブート構成ハンドブック。ハンドブック シリーズ。アッパー サドル リバー、ニュージャージー: Que Publishing。p . 289。ISBN 978-0-7897-2283-6. 2010 年7 月 25 日閲覧。mIRC
は最も人気のある Windows IRC クライアントの 1 つです。
- ^ 「Warsow Wiki: IRC モジュール」。2011 年 4 月 25 日時点のオリジナルよりアーカイブ。2011 年4 月 10 日閲覧。
- ^ Guenter, Daniel (2004 年 6 月 21 日). 「UT2004 Review」. BCCHardware . 2011 年4 月 10 日閲覧。
- ^ 「The Ultimate Uplink Guide」 。 2011年4月10日閲覧。
- ^ 「ZDaemon – The Doom Wiki: その他のユーティリティ」 。2011年4 月 10 日閲覧。
- ^ 「IRC クライアントを設定して Ustream に接続し、ログインする方法」。Ustream-Helpers。2012 年 1 月 29 日。2013 年 3 月 21 日時点のオリジナルよりアーカイブ。2013年4 月 27 日閲覧。
- ^ Mauldor (2010年6月20日). 「Ustream vs. Justin.tv」. LiquidSilver . 2011年7月13日閲覧。
- ^ “Twitch IRC”. Twitch ヘルプセンター. 2017年4月7日. 2019年2月12日時点のオリジナルよりアーカイブ。 2017年10月30日閲覧。
- ^ Canavan, John. 「悪意のある IRC ボットの進化」(PDF)。Symantec。Symantec Security Response。2006年 3 月 15 日時点のオリジナル(PDF)からのアーカイブ。
- ^ 「psyBNC Readme」. psybnc.at . 2011年4月10日閲覧。
- ^ Carey, Chris (2009 年 7 月 18 日). 「irssi-proxy + screen を使用した IRC」. chriscarey.com . 2011 年4 月 10 日閲覧。
- ^ 「Detachable Frontend (Core Rewrite) / UML / Windows Port (kicking Glade)」. smuxi.org. 2004 年 12 月 25 日. 2010 年7 月 25 日閲覧。
- ^ 「Smuxiについて」 smuxi.org . 2011年4月10日閲覧。
- ^マトン、ポール ( 2004年 7 月 27 日)。「ユーザーとチャネル」。IRC Hacks (第 1 版)。カリフォルニア州セバストポル: O'Reilly Media。pp . 44–46。ISBN 978-0-596-00687-7。
- ^ Wang, Wallace (2004 年 10 月 25 日)。「インスタント メッセージングとオンライン チャット ルーム: インターネット リレー チャット (IRC)」。このファイル共有の本を盗め(第 1 版)。カリフォルニア州サンフランシスコ: No Starch Press。65~ 67 ページ。ISBN 978-1-59327-050-6。
- ^ Vamosi, Robert (2002 年 5 月 8 日)。「海賊版映画: お近くのサーバーで再生中」ZDNet。2011年4 月 10 日閲覧。
- ^ Sasaki, Darla (2002 年 4 月 4 日)。「IRC 101: IRC とは何か、どのように使用するのか?」Macobserver.com。2011年4 月 10 日閲覧。
一般的な参考文献
- Reed, Darren (1992 年 5 月) 。コンピュータ ネットワーク会議に関する議論。IETF。doi : 10.17487 /RFC1324。RFC 1324。2009年10月30 日閲覧。
- Oikarinen, ヤッコ;ダレン、リード (1993 年 5 月)。インターネット リレー チャット プロトコル。IETF。土井: 10.17487/RFC1459。RFC 1459 。2009 年10 月 30 日に取得。
- Kalt, Christophe (2000 年 4 月)。インターネット リレー チャット: アーキテクチャ。IETF。doi : 10.17487 /RFC2810。RFC 2810。2009年10月30日閲覧。
- Kalt, Christophe (2000 年 4 月)。インターネット リレー チャット: チャネル管理。IETF。doi : 10.17487 / RFC2811。RFC 2811。2009年10月30日閲覧。
- Loesch, Carl (2003 年 7 月 17 日)。「同期会議システムが提供する機能」。psyc.eu。2011年4 月 10 日閲覧。
さらに読む
- Kalt, Christophe (2000 年 4 月)。インターネット リレー チャット: クライアント プロトコル。IETF。doi : 10.17487 /RFC2812。RFC 2812。2009年10月30日閲覧。
- Kalt, Christophe (2000 年 4 月)。インターネット リレー チャット: サーバー プロトコル。IETF。doi : 10.17487 /RFC2813。RFC 2813。2009年10月30日閲覧。
- 「オンラインコミュニティにおける主要なイベントのログ」。ノースカロライナ州チャペルヒル:ibiblio 。 2011年4月8日閲覧。
- Butcher, Simon. 「IRC 技術情報」。alien.net.au。2011年4 月 10 日閲覧。
外部リンク
- IRC 数値リスト
- IRCの歴史
- IRC.org – IRC6 の技術および歴史に関する情報、IRC の歴史に関する記事
- IRChelp.org – インターネット リレー チャット (IRC) ヘルプ アーカイブ。IRC 関連ドキュメントの大規模なアーカイブ
- IRCv3 – プロトコルに新しい機能を追加し、その仕様を記述する開発者のワーキンググループ
- IRC-Source 2020年10月8日アーカイブWayback Machine – 履歴データを備えたインターネットリレーチャット(IRC)ネットワークおよびチャンネル検索エンジン
- irc.netsplit.de – 履歴データを含むインターネット リレー チャット (IRC) ネットワーク リスト
