Интернет жедел чат және хабар алмасу протоколы

Кіріспе

Реалдық уақыт режиміндегі Интернет-чат және хабар алмасу протоколы

IRC (Internet Relay Chat) – жылдам хабар алмасуға арналған, мәтінге негізделген чат жүйесі. IRC топтық коммуникация үшін, «арналар» деп аталатын талқылау форумдарында жасалған, бірақ жеке хабарламалар арқылы жеке хабар алмасуға, сондай-ақ файлдарды бөлісуді қоса алғанда, чат және деректерді беруге де мүмкіндік береді. Интернет-релейлік чат мәтін түріндегі байланысты жеңілдету үшін қосымша деңгей протоколы ретінде іске асырылады. Чат процесі клиент-сервер желілік моделі бойынша жұмыс істейді. Пайдаланушылар веб-қосымша, жеке компьютерлік бағдарлама немесе үлкен бағдарламаның бір бөлігі ретінде IRC серверіне қосылады, ол үлкен IRC желісінің бөлігі болуы мүмкін. Қосылуға қолданылатын бағдарламалардың мысалдары: Mibbit, IRCCloud, KiwiIRC және mIRC. IRC қолдану 2003 жылдан бері үздіксіз төмендеп келеді, пайдаланушылардың 60 пайызын жоғалтты.

Тарих

IRC 1988 жылдың тамызында Jarkko Oikarinen Финляндиядағы Оулу университетінің OuluBox деп аталатын BBS-де MUT (MultiUser Talk) деп аталатын бағдарламаны алмастыру үшін құрылды, онда ол Ақпаратты өңдеу ғылымдары кафедрасында жұмыс істеді. Jarkko өзі басқаратын BBS бағдарламалық жасақтамасын кеңейтіп, Usenet стиліндегі жаңалықтарды, нақты уақыт пікірталастарын және ұқсас BBS мүмкіндіктерін қамтамасыз етуді жоспарлады. Ол алғашқыда әңгімелесу бөлігін жасады, оны достары Жирки Куоппала мен Юкка Пиль жазған кодты пайдаланып іске асырды. Алғашқы IRC желісі tolsun.oulu.fi деп аталатын бір серверде жұмыс істеді. Оикаринен BITNET желісінде жұмыс істейтін Bitnet Relay деп аталатын чат жүйесінен шабыттанды. Жирки Куоппала Оикариненді Оулу университетінен IRC кодын Оулудан тыс жерлерде де іске қосуға рұхсат сұрауға ынталандырды, және олар оны жариялағаннан кейін, Жирки Куоппала бірден тағы бір серверді орнатты. Осылайша алғашқы "IRC желісі" пайда болды. Оикаринен пайдаланушылар саны артып, басқа университеттер де осы жолға түскен кезде Хельсинки және Тампере университеттеріндегі достарына IRC серверлерін іске қосуға көмектесті. Осы кезде Оикаринен бағдарламасына BBS мүмкіндіктерінің қалғаны сыймайтынын түсінді. "Онда wildcard серверлік желі болды, сондықтан адамдар серверлерді қосып, есімдері соқтығысып жатты". "Eris Free Network", EFnet, Эрис машинасының IRC-ден Q-қапталғанын (Q – карантин үшін) бірінші рет жасады. Wumpus сөзімен айтқанда, бұрын да, Мысыр шығанағындағы соғыс кезінде осыған ұқсас жағдай болған. Осы және басқа да оқиғалардың чат-журналдары ibiblio архивінде сақталады.

Техникалық ақпарат

IRC – ашық протокол, ол TCP арқылы пайдаланушылардың клиентті серверге қосып IRC желілеріне қол жеткізуін қамтамасыз етеді. mIRC, HexChat және irssi сияқты көптеген клиенттік және бастапқы IRCd сияқты серверлік іске асырулар бар. Көптеген IRC серверлері пайдаланушылардан тіркелуді талап етпейді, бірақ қосылу үшін никнейм қажет. IRC бастапқыда қарапайым мәтіндік протокол болды. Алайда, де-факто стандарт IRC-ді 6667/TCP және жақын порттар нөмірлерінде (мысалы, TCP порттары 6660–6669, 7000) іске асыруды қадағалап, IRCd бағдарламалық жасақтамасын root құқықтарымен іске қосудан аулақ болу үшін белгіленді. Протокол символдардың 8 биттік екенін көрсеткен, бірақ мәтіннің кодировкасын нақтыламады. Бұл әртүрлі клиенттерді және/немесе платформаларды пайдаланатын пайдаланушылардың арасында қиындықтар тудыруы мүмкін. Бүгінгі күні қолданылатын клиент-серверлік IRC протоколдарының барлығы IRC2 серверінің irc2.4.0 нұсқасында іске асырылған және RFC 1459 құжаттамасында сипатталған протоколдан туындаған. RFC 1459 жарияланғаннан кейін, irc2.10 іске асырылымындағы жаңа мүмкіндіктер бірнеше қайта қарастырылған протокол құжаттарының (RFC 2810, RFC 2811, RFC 2812 және RFC 2813) жариялануына әкелді. Алайда, бұл протокол өзгерістері басқа іске асыруларда кеңінен қабылданбады. IRC протоколы бойынша көптеген спецификациялар жарияланғанымен, протокол өзгермелі болып қала беретіндіктен ресми спецификация жоқ. Көптеген клиенттер және аздаған серверлер жоғарыда аталған RFC-ге сілтеме ретінде қатаң түрде сүйенбейді. Microsoft 1998 жылы IRC-ге меншікті IRCX кеңейтімдерін жасады. Кейіннен IRCX қолдайтын бағдарламалық жасақтаманы таратуды тоқтатты, оның орнына MSNP-ні меншікті протокол ретінде әзірледі. IRC серверлері желісінің стандартты құрылымы – ағаш. Хабарламалар ағаштың қажетті тармақтары арқылы ғана бағытталады, бірақ желінің күйі барлық серверлерге жіберіледі және серверлер арасында жоғары деңгейде сенімділік бар. Алайда, бұл архитектурада бірқатар мәселелер бар. Бұзылған немесе қасақана зиян келтіретін сервер желіге елеулі зиян келтіруі мүмкін, ал құрылымдағы кез келген өзгерістер, қасақана болсын немесе негізгі желідегі жағдайлардың нәтижесінде болсын, желінің бөлінуіне және қосылуына әкеледі. Бұл желілік трафиктің артуына, пайдаланушыларға жалған қосылу/үзілу хабарламаларына және желіні бөлу кезінде пайдаланушылардың байланысының уақытша жоғалуына әкеледі. Үлкен желіге серверді қосу желіде үлкен өткізу қабілетінің жүктемесін және серверде үлкен жад жүктемесін білдіреді. Бірақ, орнатылғаннан кейін, әрбір хабарлама бірнеше алушыға мультикастқа ұқсас түрде жіберіледі, яғни әрбір хабарлама желілік байланыс арқылы бір рет өтеді. Бұл Simple Mail Transfer Protocol (SMTP) немесе Extensible Messaging and Presence Protocol (XMPP) сияқты мультикаст емес протоколдармен салыстырғанда артықшылық болып табылады. IRC демоны жергілікті желіде (LAN) пайдаланылуы мүмкін. Осылайша, IRC жергілікті желідегі адамдар арасындағы байланысты жеңілдету үшін қолданылуы мүмкін (ішкі байланыс).

IRC is an open protocol that uses TCP Users access IRC networks by connecting a client to a server. There are many client implementations, such as mIRC, HexChat and irssi, and server implementations, e. g. the original IRCd. Most IRC servers do not require users to register an account but a nickname is required before being connected. IRC was originally a plain text protocol However, the de facto standard has always been to run IRC on 6667/TCP and nearby port numbers (for example TCP ports 6660–6669, 7000) to avoid having to run the IRCd software with root privileges. The protocol specified that characters were 8 bit but did not specify the character encoding the text was supposed to use. This can cause problems when users using different clients and/or different platforms want to converse. All client to server IRC protocols in use today are descended from the protocol implemented in the irc2.4.0 version of the IRC2 server, and documented in RFC 1459. Since RFC 1459 was published, the new features in the irc2.10 implementation led to the publication of several revised protocol documents (RFC 2810, RFC 2811, RFC 2812 and RFC 2813); however, these protocol changes have not been widely adopted among other implementations. Although many specifications on the IRC protocol have been published, there is no official specification, as the protocol remains dynamic. Virtually no clients and very few servers rely strictly on the above RFCs as a reference. Microsoft made an extension for IRC in 1998 via the proprietary IRCX. They later stopped distributing software supporting IRCX, instead developing the proprietary MSNP. The standard structure of a network of IRC servers is a tree. Messages are routed along only necessary branches of the tree but network state is sent to every server and there is generally a high degree of implicit trust between servers. However, this architecture has a number of problems. A misbehaving or malicious server can cause major damage to the network and any changes in structure, whether intentional or a result of conditions on the underlying network, require a net split and net join. This results in a lot of network traffic and spurious quit/join messages to users and temporary loss of communication to users on the splitting servers. Adding a server to a large network means a large background bandwidth load on the network and a large memory load on the server. Once established, however, each message to multiple recipients is delivered in a fashion similar to multicast, meaning each message travels a network link exactly once. This is a strength in comparison to non multicasting protocols such as Simple Mail Transfer Protocol (SMTP) or Extensible Messaging and Presence Protocol (XMPP). An IRC daemon can be used on a local area network (LAN). IRC can thus be used to facilitate communication between people within the local area network (internal communication).

Командалар мен жауаптар

IRC жолға негізделген құрылымға ие. Клиенттер серверге бір жолдық хабарламалар жібереді, осы хабарламаларға жауаптарды алады және басқа клиенттер жіберген кейбір хабарламалардың көшірмелерін алады. Көптеген клиенттерде пайдаланушылар командаларды "/" символымен бастап енгізе алады. Командаға байланысты, олар клиент тарапынан толыққанды орындалуы мүмкін немесе (әдетте клиент танымайтын командалар үшін) кейбір өзгерістермен серверге тікелей жіберіледі. Протоколдың ерекшелігіне байланысты, автоматтандырылған жүйелер жіберілген команданы оның жауабымен толық сенімділікпен дұрыс байланыстыра алмайды және шамалап болжауға бейім.

Каналдары

IRC сессиясында пайдаланушылар тобымен байланысудың негізгі тәсілі – арна арқылы. Желідегі арналарды IRC командасы LIST көмегімен қарауға болады, ол осы желіде +s немесе +p режимдері қойылмаған барлық қолжетімді арналарды тізімдейді. Пайдаланушылар JOIN командасын пайдаланып арнаға қосыла алады, көптеген клиенттерде ол /join #channelname түрінде қолжетімді. Қосылған арналарға жіберілген хабарламалар басқа барлық пайдаланушыларға жіберіледі. Басқа, сирек кездесетін арна түрлеріне операторлары жоқ, "модельсіз" арналар болып табылатын "+" арналар, сондай-ақ әдетте уақыт белгісі қойылмайтын желілерде уақыт белгісімен жазылатын "!" арналар жатады.

IRC операторлары

Сондай-ақ, жергілікті серверде немесе бүкіл желіде жоғары құқықтарды сақтайтын пайдаланушылар бар; оларды IRC операторлары деп атайды, кейде IRCops немесе Opers деп қысқартылады (арна операторларымен шатаспау керек). IRCd-ді іске асыру әртүрлі болғандықтан, IRC операторының берілген IRCd-дегі артықшылықтары да әртүрлі болады. RFC 1459 IRC серверлері, қызметтері және басқа клиенттер, соның ішінде боттар, оны белгілі бір IRC сессиясын анықтау үшін пайдалана алады. Хост маскасының форматы nick!user@host. Хост маскасы электрондық пошта мекенжайына ұқсас көрінеді, бірақ оны осымен шатастыруға болмайды. Nick бөлігі - бұл пайдаланушы таңдаған лақап аты және оны қосылған кезде өзгертуге болады. User бөлігі - бұл клиенттегі ident баяндаған пайдаланушы аты. Егер клиентте ident қолжетімді болмаса, клиент қосылған кезде көрсетілген пайдаланушы аты тильдамен префикстелгеннен кейін қолданылады. Host бөлігі - клиент қосылатын хост аты. Егер клиенттің IP-адресі сервер жарамды хост атына қарай анықтай алмаса, ол хост атының орнына қолданылады. Клиенттің IP-адресі немесе хост атын ашудың құпиялылық салдарынан кейбір IRC демондары InspIRCd немесе UnrealIRCd-тің "+x" режимі сияқты құпиялылық мүмкіндіктерін ұсынады. Бұл клиенттің IP-адресін хэштейді немесе клиенттің хост атының бір бөлігін жасырады, оны IRCops-тан басқа пайдаланушылар оқи алмайды. Пайдаланушылар қосымша анонимділікті қамтамасыз ету үшін хост маскасында көрсетілетін «виртуалды хостты» (немесе «vhost») сұрауы мүмкін. Кейбір IRC желілері, мысалы Libera Chat немесе Freenode, оларды пайдаланушының топқа немесе жобаға қатысты екенін көрсету үшін «күлдір» ретінде пайдаланады.

Қиындықтар

IRC-нің бастапқы дизайнындағы мәселелер: оның кеңейтілуіне шектеу келтіретін ортақ деректердің көп мөлшері, бірегей пайдаланушы идентификацияларының болмауы салдарынан лақап аттарының қақтығысы, циклдық маршрутизация арқылы желінің бөлінуінен қорғаудың жетіспеуі, кеңейтілудің нақты уақыт пайдаланушы ақпаратының болуы үшін құрбандығы, протоколдың нашарлығының зәулімдікке мүмкіндік беруі, хабар алмасудың ашық және оңтайландырылмауы және шифрлаудың жоқтығы еді. Бұл мәселелердің кейбіреулері қазіргі заманғы IRC-де шешілді.

Шабуылдар

IRC қосылымдары шифрланбаған болуы мүмкін және көбінесе ұзақ уақытқа созылады, сондықтан олар DoS/DDoS шабуылдары мен хакерлер үшін тартымды нысана болып табылады. Осы себепті, IRC желісінің басқару соғысы сияқты шабуылға ұшырамайтынына көз жеткізу үшін мұқият қауіпсіздік саясаты қажет. IRC желілері зиян келтіретін пайдаланушыларға немесе серверлерге K желісі немесе G желісі арқылы да әсер етуі мүмкін. Кейбір IRC серверлері қауіпсіздік мақсатында SSL/TLS қосылымдарын қолдайды. Бұл IRC пайдаланушыларының құпия сөздерін алу үшін пакеттерді ұстау бағдарламаларын пайдалануды тоқтатуға көмектеседі, бірақ IRC арналарының ашық сипатына байланысты осы шеңберден тыс пайдасы шамалы. SSL қосылымдары үшін клиент пен сервердің де қолдауы қажет (ол пайдаланушыдан SSL бинарларын және IRC клиентіне арналған жаңартуларды немесе модульдерді компьютерлеріне орнатуды талап етуі мүмкін). Кейбір желілер серверлер арасындағы қосылымдар үшін SSL қолданады және арнада тек SSL арқылы қосылған пайдаланушыларға ғана рұқсат беру үшін арнайы арна белгісін (+S сияқты) ұсынады, сонымен қатар SSL ұсынатын артықшылықтарды толық пайдалану үшін операторды ашық мәтінде анықтауға рұқсат бермейді. IRC көптеген интернеттік шабуылдарды сынау үшін алғашқы лаборатория ретінде қызмет етті, мысалы, жалған ICMP қол жеткізе алмайтын хабарламаларды пайдалану арқылы TCP негізіндегі IRC қосылымдарын бұзу (нукинг) – пайдаланушыларды қынжырту немесе басқаруды жеңілдету үшін.

Зорлық-зомбылықтың алдын алу

IRC-ті іске асырумен байланысты ең көп дау тудыратын техникалық мәселелердің бірі, ол осы күнге дейін сақталып келеді, – «Nick/Channel Delay» және «Timestamp» протоколдарының тиімділігі. Екі әдіс те қызмет көрсетуден бас тарту шабуылдарын шешу үшін жасалған, бірақ олар мүлдем басқаша көзқарастарды ұсынады. IRC протоколының бастапқы мәселесі екі сервер бөлініп, қайта қосылған кезде, желідегі екі жағы өз арналарын біріктіріп алатын. Егер пайдаланушы «бөлінген» серверге қосылып, екінші жақтағы арна бос болса және оператор мәртебесін алса, желі қайта біріккеннен кейін ол «біріктірілген» арнаның операторы болады. Егер пайдаланушы екінші жақтағы лақап атты алса, сервер қайта қосылғанда екі пайдаланушыны да жояды («лақап соқтығысуы»). Бұл жиі «жаппай жою» үшін қолданылып, операторлар жоқ «бос» арналарды құрады, осылайша зиянды әрекеттерге қарсы шаралар қабылдау мүмкін болмайды. IRC-де проблемалар туындатудан бөлек, бұл адамдарды IRC серверлеріне қарсы қызмет көрсетуден бас тарту шабуылдарын жасауға итермеледі, нәтижесінде желілер бөлінеді, оларды олар одан әрі теріс пайдаланатын. Nick delay (ND) және channel delay (CD) стратегиялары қайта қосылу мен лақап аттарын өзгертуді кешіктіру арқылы осы теріс пайдалануды болдырмауға бағытталған. Пайдаланушы тіркелгісінен шыққаннан кейін және лақап аты қолжетімді болғаннан кейін, немесе арнаның барлық пайдаланушылары шығып кеткеннен кейін (желілер бөлінген кезде жиі болатын жағдай), сервер белгілі бір уақыт өткенге дейін (кешігу) ешкімге сол лақап атты пайдалануға немесе сол арнаға қосылуға рұқсат бермейді. Бұл стратегияның мақсаты – егер желі бөлінген жағдайда да, зиянкес пайдаланушы лақап атты иелене алмайды немесе оператор мәртебесін ала алмайды, сондықтан лақап соқтығысуы немесе арнаның «біріктірілуі» болмайды. Бұл кейбір жағдайларда заңды пайдаланушыларға ыңғайсыздық тудыруы мүмкін, олар қайта қосылғаннан кейін қысқа мерзімге басқа атауды пайдалануға мәжбүр болуы мүмкін (астын сызу белгісін қосу жиі қолданылады). Timestamp протоколы – бұл nick/channel delay-ге балама, ол соқтығыстарды уақыт белгісіне негізделген басымдық арқылы шешеді. Желідегі әр лақап атқа және арнаға оның құрылған күні мен уақыты – уақыт белгісі тағайындалады. Желі бөлінген кезде әр жақтағы екі пайдаланушы бірдей лақап атты немесе арнаны пайдалана алады, бірақ екі жақ біріккенде, тек біреуі ғана сақталады. Лақап аттары үшін, timestamp бойынша жаңа пайдаланушы жойылады; арна соқтығысқанда, мүшелер (арнадағы пайдаланушылар) біріктіріледі, бірақ бөлінудің «жоғалған» жағындағы арна операторлары оператор мәртебесін жоғалтады. TS протоколы ND/CD-ге қарағанда әлдеқайда күрделі, дизайн және іске асыру тұрғысынан да, бірнеше түзетулерге қарамастан, кейбір іске асыруларда әлі де «десинхронизация» (бір желідегі екі сервер желінің қазіргі күйі туралы келіспейді) және «жоғалған» жақтың рұқсат еткенінен артық жұмсақтыққа мүмкіндік беру сияқты проблемалар бар. Мысалы, TS протоколының бастапқы нұсқаларында, пайдаланушылар жоғалған арнада тыйым салу немесе басқа режимдерді орнатқан жағдайда, олар оператор мәртебесін жоғалтқан болса да, бұл режимдер біріктірілген кезде сақталмайтын. Кейбір қазіргі TS негізделген IRC серверлері террористік әрекеттерді одан әрі шектеу үшін timestamp-пен қатар ND және/немесе CD формаларын да қолданады. Көптеген желілер қазір timestamp әдісін қолданады. Timestamp және ND/CD арасындағы келіспеушіліктер EFnet желісінен бірнеше серверлердің бөлініп, жаңа IRCnet желісін құруына себеп болды. Бөлінгеннен кейін EFnet TS протоколына көшті, ал IRCnet ND/CD қолданды. IRCnet ircd-нің соңғы нұсқаларында, сондай-ақ TS6 протоколын пайдаланатын ircd-лерде (Charybdis сияқты), ND кеңейтілді/SAVE деп аталатын механизммен ауыстырылды. Бұл механизм әрбір клиентке IRC серверіне қосылған кезде бірегей идентификатор (UID) тағайындайды. Бұл идентификатор санмен басталады, ол лақап аттарында қолданылмайды (бірақ кейбір ircd-лер, атап айтқанда IRCnet және InspIRCd, клиенттерге лақап ретінде өздерінің UID-ін пайдалануға мүмкіндік береді). Егер бірдей лақап аты бар екі клиент желінің әртүрлі жақтарынан қосылса («лақап соқтығысуы»), соқтығысты бірінші байқаған сервер екі клиентті де лақап аттарын UID-іне өзгертуге мәжбүр етеді, осылайша екеуі де ажыратылмайды. IRCnet-те лақап аты да біршама уақытқа (ND) бұғатталады, екі клиенттің де бастапқы лақап атына қайта оралуына жол бермейді, осылайша қайтадан соқтығысудың алдын алады.

One of the most contentious technical issues surrounding IRC implementations, which survives to this day, is the merit of "Nick/Channel Delay" vs. "Timestamp" protocols. Both methods exist to solve the problem of denial of service attacks, but take very different approaches. The problem with the original IRC protocol as implemented was that when two servers split and rejoined, the two sides of the network would simply merge their channels. If a user could join on a "split" server, where a channel that existed on the other side of the network was empty, and gain operator status, they would become a channel operator of the "combined" channel after the netsplit ended; if a user took a nickname that existed on the other side of the network, the server would kill both users when rejoining (a "nick collision"). This was often abused to "mass kill" all users on a channel, thus creating "opless" channels where no operators were present to deal with abuse. Apart from causing problems within IRC, this encouraged people to conduct denial of service attacks against IRC servers in order to cause netsplits, which they would then abuse. The nick delay (ND) and channel delay (CD) strategies aim to prevent abuse by delaying reconnections and renames. After a user signs off and the nickname becomes available, or a channel ceases to exist because all its users parted (as often happens during a netsplit), the server will not allow any user to use that nickname or join that channel, until a certain period of time (the delay) has passed. The idea behind this is that even if a netsplit occurs, it is useless to an abuser because they cannot take the nickname or gain operator status on a channel, and thus no collision of a nickname or "merging" of a channel can occur. To some extent, this inconveniences legitimate users, who might be forced to briefly use a different name after rejoining (appending an underscore is popular). The timestamp protocol is an alternative to nick/channel delays which resolves collisions using timestamped priority. Every nickname and channel on the network is assigned a timestampthe date and time when it was created. When a netsplit occurs, two users on each side are free to use the same nickname or channel, but when the two sides are joined, only one can survive. In the case of nicknames, the newer user, according to their TS, is killed; when a channel collides, the members (users on the channel) are merged, but the channel operators on the "losing" side of the split lose their channel operator status. TS is a much more complicated protocol than ND/CD, both in design and implementation, and despite having gone through several revisions, some implementations still have problems with "desyncs" (where two servers on the same network disagree about the current state of the network), and allowing too much leniency in what was allowed by the "losing" side. Under the original TS protocols, for example, there was no protection against users setting bans or other modes in the losing channel that would then be merged when the split rejoined, even though the users who had set those modes lost their channel operator status. Some modern TS based IRC servers have also incorporated some form of ND and/or CD in addition to timestamping in an attempt to further curb abuse. Most networks today use the timestamping approach. The timestamp versus ND/CD disagreements caused several servers to split away from EFnet and form the newer IRCnet. After the split, EFnet moved to a TS protocol, while IRCnet used ND/CD. In recent versions of the IRCnet ircd, as well as ircds using the TS6 protocol (including Charybdis), ND has been extended/replaced by a mechanism called SAVE. This mechanism assigns every client a UID upon connecting to an IRC server. This ID starts with a number, which is forbidden in nicks (although some ircds, namely IRCnet and InspIRCd, allow clients to switch to their own UID as the nickname). If two clients with the same nickname join from different sides of a netsplit ("nick collision"), the first server to see this collision will force both clients to change their nick to their UID, thus saving both clients from being disconnected. On IRCnet, the nickname will also be locked for some time (ND) to prevent both clients from changing back to the original nickname, thus colliding again.

Боттар

IRC-де боттарды қолданудың ең көп таралғаны – IRC қызметтерін ұсыну немесе арна ішінде белгілі бір мүмкіндіктерді іске қосу, мысалы, чат негізіндегі ойынды ұйымдастыру немесе сыртқы оқиғалар туралы хабарлау. Дегенмен, кейбір IRC боттары қызметтен тоқтату, спам тарату немесе әрекет ету сияқты қастандық шабуылдар жасау үшін пайдаланылуы мүмкін.

Қақпашы

Серверде демон ретінде іске қосылып, тұрақты прокси ретінде жұмыс істейтін бағдарлама BNC немесе баунсер деп аталады. Оның мақсаты – IRC серверімен байланысты сақтап, сервер мен клиент арасында релелік қызмет атқару немесе қарапайым прокси ретінде жұмыс істеу. Егер клиент желілік байланысын жоғалтса, баунсер байланысты үзілмей сақтап, барлық трафикті кейінірек жеткізу үшін архивке сақтайды, соның арқасында пайдаланушы серверге қосылысын бұзбай IRC сессиясын қайта бастай алады. Сонымен қатар, баунсер сияқты әсерге қол жеткізу үшін IRC клиентін (әдетте мәтіндік, мысалы Irssi) пайдаланушы ssh арқылы қосылатын үнемі қосулы серверде іске қосуға болады. Бұл ssh функционалдығы ғана бар, бірақ IRC клиенті орнатылмаған құрылғылардың IRC-ге қосылуына және IRC сессияларын бөлісуге мүмкіндік береді. IRC клиенті ssh байланысы жабылғанда тоқтамауы үшін, оны GNU Screen немесе tmux сияқты терминал мультиплексоры ішінде іске қосуға болады, осылайша IRC желісіне үздіксіз байланыста болып, пайдаланушыға қызықты арналардағы әңгімелерді тіркеуге немесе арнаның желіде болуын сақтауға мүмкіндік береді. Осы жүйеге негізделген 2004 жылы Smuxi деп аталатын клиент-серверлік IRC клиенті іске қосылды.

Іздеу жүйелері

Пайдаланушыға IRC-де іздегенін табуға көмектесетін көптеген іздеу жүйелері бар. Әдетте іздеу жүйесі екі бөліктен тұрады: "артқы бөлік" (немесе "тараушы/құбылаушы") және алдыңғы "іздеу жүйесі". Артқы бөлік (тараушы/веб-құбылаушы) – іздеу жүйесінің негізгі бөлігі. Ол 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 бойынша, лақап аттарындағы { | } символдары тиісінше [ \ ] символдарының кіші әріптерімен теңестірілуі керек. Техникалық тұрғыдан алғанда, IRC өзі файлдарды беру механизмдерін қамтамасыз етпейді; файлдарды бөлісу IRC клиенттері арқылы жүзеге асырылады, әдетте, Тікелей Клиенттен Клиентке (DCC) протоколын қолданады, онда файлдарды беру клиенттер арасындағы жеке хабарламалар алмасу арқылы келісіледі. IRC клиенттерінің көпшілігі DCC файлдарын беруді қолдайды, сондықтан файлдарды бөлісу IRC-нің ажырамас бөлігі болып саналады. Алайда, осы протоколдың кең таралған қолданысы кейде DCC спамына да алып келеді. DCC командалары сондай-ақ әрекеттерді орындау үшін, мысалы, серверден ажылу немесе клиенттен шығу үшін осал клиенттерді пайдалану үшін қолданылды.