Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску
Первый IRC-сервер, tolsun.oulu.fi, сервер Sun-3, выставленный рядом с компьютерным центром Университета Оулу . (2001)

Internet Relay Chat ( IRC ) - это протокол прикладного уровня , который упрощает обмен данными в текстовой форме. Процесс чата работает по сетевой модели клиент / сервер. IRC-клиенты - это компьютерные программы, которые пользователи могут установить в своей системе, или веб-приложения, запускаемые локально в браузере или на стороннем сервере. Эти клиенты связываются с серверами чата для передачи сообщений другим клиентам. [1] IRC - в основном предназначена для группового общения в дискуссионных форумах, называемых каналами , [2] , но и позволяет один на один коммуникации через личные сообщения [3] , а также чат и передачи данных ,[4] включая обмен файлами . [5]

Клиентское программное обеспечение доступно для всех основных операционных систем, поддерживающих доступ в Интернет. [6] По состоянию на апрель 2011 года 100 крупнейших сетей IRC обслуживали одновременно более полумиллиона пользователей [7], причем сотни тысяч каналов [7] работали в общей сложности примерно на 1500 серверах [7] из примерно 3200 серверов по всему миру. [8] Использование IRC неуклонно снижается с 2003 года, теряя 60% своих пользователей (с 1 миллиона до примерно 400 000 в 2012 году) и половину своих каналов (с полумиллиона в 2003 году). [9] [ требуется обновление ]

История [ править ]

IRC был создан Яркко Оикариненом в августе 1988 года, чтобы заменить программу под названием MUT (MultiUser Talk) на BBS под названием OuluBox в Университете Оулу в Финляндии , где он работал в Департаменте науки обработки информации. Яркко намеревался расширить администрируемое им программное обеспечение BBS, чтобы можно было получать новости в стиле Usenet , обсуждения в реальном времени и аналогичные функции BBS. Первой частью, которую он реализовал, была часть чата, которую он сделал с помощью заимствованных частей, написанных его друзьями Юрки Куоппала и Юккой Пилом. Первая сеть IRC работала на одном сервере с именем tolsun.oulu.fi. [10] Оикаринен нашел вдохновение в системе чата, известной как Bitnet Relay., который работал в сети BITNET . [11]

Юрки Куоппала подтолкнул Оикаринена попросить университет Оулу освободить код IRC, чтобы его можно было запускать за пределами Оулу, и после того, как они, наконец, выпустили его, Юрки Куоппала немедленно установил другой сервер. Это была первая «IRC-сеть». У Оикаринена были друзья из Хельсинкского университета и Университета Тампере, которые начали использовать серверы IRC, когда число его пользователей увеличилось, а вскоре последовали и другие университеты. В это время Оикаринен понял, что остальные функции BBS, вероятно, не впишутся в его программу. [10]

Оикаринен связался с людьми из Денверского университета и Университета штата Орегон . У них была собственная сеть IRC, и они хотели подключиться к финской сети. Они получили программу от одного из друзей Оикаринена, Виджая Субраманиама - первого человека не из Финляндии, который использовал IRC. Затем IRC расширился и стал использоваться во всей финской национальной сети Funet, а затем подключился к Nordunet , скандинавскому ответвлению Интернета. В ноябре 1988 г. IRC распространился по Интернету, а к середине 1989 г. во всем мире насчитывалось около 40 серверов. [10]

EFnet [ править ]

В августе 1990 года в мире IRC произошли первые серьезные разногласия. «A-net» (сеть анархии) включает сервер с именем eris.berkeley.edu. Он был открыт, не требовал паролей и не имел ограничений на количество подключений. Как объясняет Грег «wumpus» Линдал: «у него была линия серверов с подстановочными знаками, поэтому люди подключали серверы и сталкивались с ником всех». "Свободная сеть Эрис", EFnet, сделал машину eris первой, которая была подвергнута Q-lined (Q для карантина) от IRC. Еще раз повторим слова wumpus: «Эрис отказалась удалить эту линию, поэтому я сформировал EFnet. Это не было серьезной борьбой; я заставил все хабы присоединиться, и почти все остальные были унесены». Сеть A-net была создана с серверами eris, а EFnet - с серверами, отличными от eris. История показывает, что большинство серверов и пользователей используют EFnet. После расформирования A-net название EFnet стало бессмысленным, и снова это была единственная IRC-сеть. [10]

Примерно в то время IRC использовался для репортажей о попытке советского государственного переворота 1991 года во время отключения СМИ . [12] Ранее он использовался аналогичным образом во время войны в Персидском заливе . [13] Журналы чатов этих и других событий хранятся в архиве ibiblio . [14]

Вилка Undernet [ править ]

Еще одна попытка форка, первая, которая действительно произвела большие и устойчивые изменения, была инициирована Wildthang в США в октябре 1992 года (она возникла из EFnet ircd версии 2.8.10). Это должно было быть просто тестовой сетью для разработки ботов, но быстро превратилось в сеть «для друзей и их друзей». В Европе и Канаде велась работа над отдельной новой сетью, и в декабре французские серверы подключились к канадским, а к концу месяца французская и канадская сети были подключены к американской, образуя сеть, которая позже появилась. называться « Ундернет ». [10]

«Сторонники нижнего уровня» хотели развить ircd дальше, пытаясь уменьшить нагрузку на полосу пропускания и попытаться разобраться в хаосе каналов ( расщепления и поглощения ), от которого начал страдать EFnet. Для последней цели Undernet реализовал временные метки, новую маршрутизацию и предложил CService - программу, которая позволяла пользователям регистрировать каналы, а затем пыталась защитить их от нарушителей спокойствия. Первый представленный список серверов от 15 февраля 1993 года включает серверы из США, Канады, Франции, Хорватии и Японии. 15 августа был установлен новый рекорд по количеству пользователей - 57 пользователей. [10]

В мае 1993 года был опубликован RFC 1459 [1], в котором подробно описывается простой протокол для работы клиент / сервер, каналов, разговоров «один-к-одному» и «один-ко-многим». [10] Примечательно, что значительное количество расширений, таких как CTCP, цвета и форматы, не включены в спецификации протокола, равно как и кодировка символов [15], что привело к расхождению в различных реализациях серверов и клиентов. Фактически, реализация программного обеспечения значительно варьировалась от одной сети к другой, каждая сеть реализовывала свои собственные политики и стандарты в своей собственной кодовой базе.

Форк DALnet [ править ]

Летом 1994 года Undernet была разветвлена. Новая сеть получила название DALnet (названная в честь ее основателя: dalvenjah), созданная для лучшего обслуживания пользователей и большей защиты пользователей и каналов. Одним из наиболее значительных изменений в DALnet стало использование более длинных псевдонимов (исходное ограничение ircd составляло 9 букв). Модификации DALnet ircd выполнил Алексей "Lefler" Косут. Таким образом, DALnet был основан на ircd-сервере Undernet, хотя пионеры DALnet отказались от EFnet. По словам Джеймса Нг, первые люди из DALnet были «операторы #StarTrek, больные из-за постоянных разделений / задержек / поглощений и т. Д.». [10]

DALnet быстро предложил глобальные WallOps (сообщения IRCop, которые могут видеть пользователи с + w (/ mode NickName + w)), более длинные псевдонимы, Q: линейные псевдонимы (псевдонимы, которые нельзя использовать, например, ChanServ, IRCop, NickServ и т. Д.) , global K: Lines (запрет одного человека или всего домена на сервере или во всей сети), связь только IRCop: GlobOps, режим + H, показывающий, что IRCop - это «помощник» и т. д. Многие из новых функций DALnet были написаны в начале 1995 года Брайаном «Морфер» Смитом и позволил пользователям владеть псевдонимами, управлять каналами, отправлять записки и многое другое. [10]

Форк IRCnet [ править ]

В июле 1996 года, после месяцев ожесточенных войн и обсуждений в списке рассылки, произошел еще один раскол из-за разногласий по поводу того, как должна развиваться разработка ircd. В частности, «европейская» сторона (большинство этих серверов находилось в Европе), которая позже назвала себя IRCnet, выступала за задержки по нику и каналу, тогда как сторона EFnet выступала за временные метки. [10] Были также разногласия по поводу политики: европейская сторона начала устанавливать свод правил, определяющих, что IRCops могут и не могут делать, точка зрения, против которой выступала американская сторона. [16]

Большинство (не все) серверов IRCnet находились в Европе, в то время как большинство серверов EFnet находились в США. Это событие также известно как «Великий раскол» во многих сообществах IRC. EFnet с тех пор (по состоянию на август 1998 г.) вырос и превысил количество пользователей, которых у него было тогда. Осенью 2000 года (северной) у EFnet было около 50 000 пользователей, а у IRCnet - 70 000. [10]

Современный IRC [ править ]

IRC сильно изменился за свою жизнь в Интернете. Новое серверное программное обеспечение добавило множество новых функций.

  • Услуги : Сетевые боты для облегчения регистрации псевдонимов и каналов, отправки сообщений для автономных пользователей и функций оператора сети.
  • Дополнительные режимы: в то время как исходная система IRC использовала набор стандартных пользовательских и канальных режимов, новые серверы добавляют много новых режимов для таких функций, как удаление цветовых кодов из текста [17] или скрытие маски хоста пользователя («маскировка») для защиты от атаки типа «отказ в обслуживании» . [18]
  • Обнаружение прокси: большинство современных серверов поддерживают обнаружение пользователей, пытающихся подключиться через небезопасный (неправильно настроенный или эксплуатируемый) прокси-сервер , которому затем может быть отказано в подключении. Это программное обеспечение для обнаружения прокси-серверов используется несколькими сетями, хотя этот список прокси-серверов в реальном времени не функционирует с начала 2006 года [19].
  • Дополнительные команды: новые команды могут быть такими, как сокращенные команды для выдачи команд службам, команды только оператора сети для управления маской хоста пользователя. [ необходима цитата ]
  • Шифрование : для этапа соединения клиент-сервер может использоваться TLS (сообщения перестают быть безопасными после их ретрансляции другим пользователям по стандартным соединениям, но это затрудняет перехват или прослушивание индивидуальных сеансов IRC). Для связи между клиентом можно использовать SDCC (Secure DCC). [ необходима цитата ]
  • Протокол подключения: к IRC можно подключиться через IPv4 , старую версию интернет-протокола , или через IPv6 , текущий стандарт протокола.

С 2016 года в рамках рабочей группы IRCv3 проводится новая работа по стандартизации, которая фокусируется на более продвинутых клиентских функциях, таких как мгновенные уведомления, улучшенная поддержка истории и повышенная безопасность. [20] По состоянию на 2019 год ни одна из крупных сетей IRC полностью не приняла предложенный стандарт. [21]

После золотой эры в 1990-х и начале 2000-х годов (240 000 пользователей QuakeNet в 2004 году) IRC пережил значительный спад, потеряв около 60% пользователей в период с 2003 по 2012 год, при этом пользователи переходят на новые платформы социальных сетей, такие как Facebook или Twitter , [9], но также и для открытых платформ, таких как XMPP, который был разработан в 1999 году. Некоторые сети, такие как Freenode , не следовали общей тенденции и за тот же период увеличились в размере более чем в четыре раза. [9] По состоянию на 2016 год Freenode является крупнейшей сетью IRC, насчитывающей около 90 000 пользователей. [22]

Крупнейшие сети IRC традиционно относят к «большой четверке» [23] [24] [25] [26] - обозначение сетей, которые возглавляют статистику. Сети Большой четверки периодически меняются, но из-за того, что IRC является сообществом, пользователи могут выбирать из большого количества других сетей.

Исторически «большой четверкой» были: [23] [24] [25]

  • EFnet
  • IRCnet
  • Undernet
  • ДАЛнет

IRC достигла 6 миллионов одновременных пользователей в 2001 году и 10 миллионов пользователей в 2003 году, опустившись до 371k в 2018. [ править ]

По состоянию на октябрь 2018 года крупнейшими IRC-сетями являются:

  • freenode  - около 90 тыс. пользователей в часы пик
  • IRCnet  - около 30 тыс. Пользователей в часы пик
  • EFnet  - около 18 тыс. Пользователей в часы пик
  • Undernet  - около 17 тыс. Пользователей в часы пик
  • QuakeNet  - около 15 тыс. Пользователей в часы пик
  • Rizon  - около 14 тыс. Пользователей в часы пик
  • OFTC  - около 13 тыс. Пользователей в часы пик
  • DALnet  - около 8 тыс. Пользователей в часы пик

Сегодня к 100 ведущим сетям IRC подключено около 370 тыс. Пользователей в часы пик. [27]

Хронология [ править ]

EFnet
Undernet
ДАЛнет
Freenode
IRCnet
QuakeNet
Сообщество открытых и свободных технологий
Ризон
1990 г.
1992 г.
1994 г.
1996 г.
1998 г.
2000 г.
2002 г.
2004 г.
2006 г.
2008 г.
2010 г.
2012 г.
2014 г.
2016 г.
2018 г.
2020 г.
IRC сети

Техническая информация [ править ]

Снимок экрана HexChat , IRC-клиента для сред GTK .
Xaric, текстовый IRC - клиент, используется на Mac OS X . Показаны два канала IRC и личная беседа с автором программного обеспечения.

IRC - это открытый протокол , использующий TCP [1] и, опционально, TLS . Сервер IRC может подключаться к другим серверам IRC для расширения сети IRC. [28] Пользователи получают доступ к сетям IRC, подключая клиента к серверу. [29] Есть много реализаций клиента, такие как Mirc , HexChat и Irssi и реализации серверов, например оригинальную IRCd . Большинство серверов IRC не требуют, чтобы пользователи регистрировали учетную запись, но перед подключением требуется ник . [30]

IRC - был первоначально простой текст протокола [1] (хотя позже расширен), который по запросу был назначен порт 194 / TCP от IANA . [31] Однако, де факто стандартом всегда было запустить IRC на 6667 / TCP [32] и соседних номеров портов (например , TCP портов 6660-6669, 7000) [33] , чтобы избежать того , чтобы запустить IRCD программное обеспечение с корнем привилегии .

Протокол указывал, что символы были 8-битными, но не указывал кодировку символов, которую должен использовать текст. [15] Это может вызвать проблемы, когда пользователи, использующие разные клиенты и / или разные платформы, хотят общаться.

Все используемые сегодня протоколы IRC между клиентом и сервером являются производными от протокола, реализованного в версии irc2.4.0 сервера IRC2 и задокументированного в RFC 1459 . После публикации RFC 1459 новые функции в реализации irc2.10 привели к публикации нескольких пересмотренных протокольных документов ( RFC 2810 , RFC 2811 , RFC 2812 и RFC 2813 ); однако эти изменения протокола не получили широкого распространения среди других реализаций. [ необходима цитата ]

Хотя многие спецификации протокола IRC были опубликованы, официальной спецификации нет, поскольку протокол остается динамичным. Практически ни один клиент и очень мало серверов строго полагаются на приведенные выше RFC в качестве справочной информации. [ необходима цитата ]

Microsoft сделала расширение для IRC в 1998 году через проприетарный IRCX . [34] Позже они прекратили распространение программного обеспечения, поддерживающего IRCX, вместо этого разработали проприетарный MSNP .

Стандартная структура сети IRC-серверов представляет собой дерево . [35] Сообщения маршрутизируются только по необходимым ветвям дерева, но состояние сети отправляется на каждый сервер [36], и, как правило, между серверами существует высокая степень неявного доверия. Однако у этой архитектуры есть ряд проблем. Неправильно функционирующий или злонамеренный сервер может нанести серьезный ущерб сети [37], и любые изменения в структуре, будь то намеренные или вызванные условиями в базовой сети, требуют разделения сети и соединения сети. Это приводит к большому сетевому трафику и ложным сообщениям о выходе / присоединении для пользователей [38]и временная потеря связи с пользователями на разделяющих серверах. Добавление сервера в большую сеть означает большую фоновую нагрузку на полосу пропускания в сети и большую нагрузку на память на сервере. Однако после создания каждое сообщение нескольким получателям доставляется аналогично многоадресной рассылке , то есть каждое сообщение проходит по сетевому каналу ровно один раз. [39] Это преимущество по сравнению с протоколами без многоадресной рассылки, такими как Simple Mail Transfer Protocol (SMTP) [ необходима цитата ] или Extensible Messaging and Presence Protocol (XMPP) [ необходима цитата ] .

Демон IRC также может использоваться в локальной сети (LAN). Таким образом, IRC можно использовать для облегчения общения между людьми в локальной сети (внутреннее общение). [40] [41]

Команды и ответы [ править ]

IRC имеет линейную структуру. Клиенты отправляют однострочные сообщения на сервер, [42] получают ответы на эти сообщения [43] и получают копии некоторых сообщений, отправленных другими клиентами. В большинстве клиентов пользователи могут вводить команды, добавляя к ним префикс '/'. В зависимости от команды они могут либо полностью обрабатываться клиентом, либо (как правило, для команд, которые клиент не распознает) передаваться непосредственно на сервер, возможно, с некоторыми изменениями. [ необходима цитата ]

Из-за природы протокола автоматизированные системы не всегда могут правильно связать отправленную команду с ее ответом с полной надежностью и подвержены угадыванию. [44]

Каналы [ править ]

Основным средством связи с группой пользователей в установленном сеансе IRC является канал . [45] Каналы в сети могут быть отображены с помощью команды IRC LIST , [46], которая перечисляет все доступные в настоящее время каналы, для которых не установлены режимы + s или + p, в этой конкретной сети.

Пользователи могут присоединиться к каналу с помощью JOIN команды, [47] в большинстве клиентов доступны как / присоединиться #channelname . Сообщения, отправленные по объединенным каналам, затем ретранслируются всем другим пользователям. [45]

Каналы, доступные во всей сети IRC, имеют префикс "#", а каналы, локальные для сервера, используют "&". [48] К другим менее распространенным типам каналов относятся каналы со знаком «+» - «немодальные» каналы без операторов [49] - и «!». каналы, форма канала с меткой времени в сетях, обычно не имеющих метки времени. [50]

Режимы [ править ]

У пользователей и каналов могут быть режимы , которые представлены одиночными буквами с учетом регистра [51] и устанавливаются с помощью команды MODE . [52] Пользовательские режимы и режимы каналов разделены и могут использовать одну и ту же букву для обозначения разных вещей (например, пользовательский режим «i» является невидимым режимом, в то время как режим канала «i» доступен только по приглашению. [53] ) Режимы обычно устанавливаются и не устанавливаются. используя команду режима, которая принимает цель (пользователя или канал), набор режимов, которые нужно установить (+) или отключить (-), и любые параметры, необходимые режимам.

Некоторые режимы каналов принимают параметры, а другие режимы каналов применяются к пользователю на канале или добавляют или удаляют маску (например, маску запрета) из списка, связанного с каналом, вместо применения ко всему каналу в целом. [54] Режимы, которые применяются к пользователям на канале, имеют связанный символ, который используется для представления режима в ответах имен [55] (отправляются клиентам при первом подключении к каналу [47] и использовании команды имен) и во многих клиенты также использовались для его представления в отображаемом клиентом списке пользователей в канале или для отображения собственного индикатора для пользовательских режимов.

Чтобы правильно анализировать входящие сообщения режима и отслеживать состояние канала, клиент должен знать, какой режим относится к какому типу, а также для режимов, которые применяются к пользователю на канале, какой символ соответствует какой букве. В ранних реализациях IRC это должно было быть жестко закодировано на клиенте, но теперь существует стандартное расширение де-факто для протокола под названием ISUPPORT, которое отправляет эту информацию клиенту во время соединения с использованием числового 005. [56] [57]

В IRC есть небольшая конструктивная ошибка в отношении режимов, которые применяются к пользователям на каналах: сообщение с именами, используемое для установления начального состояния канала, может отправлять только один такой режим для каждого пользователя на канале [55], но несколько таких режимов могут быть установлены на одном канале. Один пользователь. Например, если пользователь имеет статус оператора (+ o) и статус голоса (+ v) на канале, новый клиент не сможет видеть режим с меньшим приоритетом (например, голосовой). Обходные пути для этого возможны как на стороне клиента, так и на стороне сервера, но ни один из них не применяется широко.

Стандартные ( RFC 1459 ) режимы [ править ]

Многие демоны и сети добавили дополнительные режимы или изменили поведение режимов в приведенном выше списке. [59] [60] [61] [62]

Операторы канала [ править ]

Канала Оператор является клиентом на IRC канале , который управляет каналом. Операторов канала IRC можно легко увидеть по символу или значку рядом с их именем (зависит от реализации клиента, обычно это префикс символа «@», зеленый кружок или латинская буква «+ o» / «o»). В большинстве сетей оператор может:

  • Ударить пользователя
  • Забанить пользователя
  • Дайте другому пользователю статус оператора канала IRC или статус голоса канала IRC.
  • Измените тему канала IRC, когда установлен режим канала + t.
  • Измените блокировки режима канала IRC.

Операторы IRC [ править ]

Есть также пользователи, которые имеют повышенные права на своем локальном сервере или во всей сети; их называют операторами IRC [63], которые иногда сокращают до IRCops или Opers (не путать с операторами каналов). Поскольку реализация IRCd меняется, меняются и привилегии оператора IRC на данном IRCd. RFC 1459 [63]утверждает, что операторы IRC являются «необходимым злом» для поддержания чистого состояния сети, и поэтому они должны иметь возможность отключать и повторно подключать серверы. Кроме того, чтобы предотвратить проникновение злонамеренных пользователей или даже вредоносных автоматизированных программ в IRC, операторам IRC обычно разрешается отключать клиентов и полностью запрещать IP-адреса или целые подсети. Сети, предоставляющие услуги (NickServ и др.), Обычно позволяют своим операторам IRC также решать основные вопросы «владения». Дополнительные привилегированные права могут включать в себя отмену запретов каналов (возможность присоединяться к каналам, к которым они не могли бы присоединиться, если бы они не были задействованы), возможность использовать себя на каналах, где они не могли бы работать без управления, автоматическое включение по каналам всегда и пр.

Маски хоста [ править ]

Маска хоста - это уникальный идентификатор клиента IRC, подключенного к серверу IRC . [64] [65] IRC- серверы , службы и другие клиенты, включая ботов , могут использовать его для идентификации определенного сеанса IRC.

Формат маски хоста nick!user@host. Маска хоста похожа на, но ее не следует путать с адресом электронной почты .

Часть псевдонима - это псевдоним, выбранный пользователем, который может быть изменен при подключении. Пользовательская часть - это имя пользователя, сообщаемое идентификатором на клиенте. [66] Если идентификатор недоступен на клиенте, имя пользователя, указанное при подключении клиента, используется после префикса тильды . [67]

Часть хоста - это имя хоста, с которого подключается клиент. Если IP-адрес клиента не может быть преобразован сервером в действительное имя хоста , он используется вместо имени хоста.

Из-за последствий для конфиденциальности раскрытия IP-адреса или имени хоста клиента некоторые демоны IRC также предоставляют функции конфиденциальности, такие как InspIRCd или режим UnrealIRCd «+ x». Это хеширует IP-адрес клиента или маскирует часть имени хоста клиента, делая его нечитаемым для пользователей, кроме IRCops . Пользователи также могут иметь возможность запросить «виртуальный хост» (или «vhost»), который будет отображаться в маске хоста, чтобы обеспечить дополнительную анонимность. Некоторые сети IRC, такие как Freenode, используют их как «маскировку», чтобы указать, что пользователь связан с группой или проектом. [68]

Схема URI [ править ]

Есть три признанных унифицированный идентификатор ресурса (URI) схемы для Internet Relay Chat: irc, ircsи irc6. [69] Когда они поддерживаются, они допускают гиперссылки в различных формах, в том числе

irc: // <хост> [: <порт>] / [<канал> [? <ключевое_слово_канала>]]ircs: // <хост> [: <порт>] / [<канал> [? <ключевое_слово_канала>]]irc6: // <хост> [: <порт>] / [<канал> [? <ключевое_слово_канала>]]

(где элементы, заключенные в квадратные скобки ([,]), являются необязательными) для использования (при необходимости) для подключения к указанному хосту (или сети, если это известно IRC-клиенту) и присоединения к указанному каналу. [70] (Это можно использовать в самом клиенте или из другого приложения, такого как веб-браузер). irc - это URI по умолчанию, irc6 указывает соединение, которое должно быть выполнено с использованием IPv6, а ircs указывает безопасное соединение.

Согласно спецификации, обычный символ решетки (#) будет добавлен к именам каналов, которые начинаются с буквенно - цифрового символа, что позволяет его опустить. Некоторые реализации (например, mIRC) будут делать это безоговорочно, приводя к (обычно непреднамеренному) дополнительному (например, каналу ##), если он включен в URL-адрес.

Некоторые реализации позволяют указывать несколько каналов через запятую. [71]

Проблемы [ править ]

Проблемы первоначального дизайна IRC заключались в том, что количество совместно используемых данных состояния [72] [73] являлось ограничением его масштабируемости [74], отсутствие уникальных идентификаторов пользователей, приводящее к проблеме коллизии псевдонимов, [75] отсутствие защиты от netsplits посредством циклической маршрутизации, [76] [77] компромисса в масштабируемости ради информации о присутствии пользователя в реальном времени, [78] слабых мест протокола, обеспечивающих платформу для злоупотреблений, [79] отсутствие прозрачной и оптимизируемой передачи сообщений , [80] и без шифрования. [81] Некоторые из этих проблем были рассмотрены в Modern IRC .

Атаки [ править ]

Поскольку соединения IRC могут быть незашифрованными и обычно охватывают длительные периоды времени, они являются привлекательной целью для атакующих DoS / DDoS и хакеров . Из-за этого необходима тщательная политика безопасности, чтобы гарантировать, что сеть IRC не подвержена атакам, таким как война за захват . Сети IRC могут также иметь пользователей или серверов K-line или G-line, которые оказывают вредное воздействие.

Некоторые серверы IRC поддерживают соединения SSL / TLS в целях безопасности. Это помогает остановить использование программ- снифферов пакетов для получения паролей пользователей IRC, но мало используется за пределами этой области из-за общедоступности каналов IRC. Для SSL-соединений требуется поддержка как клиента, так и сервера (для этого может потребоваться, чтобы пользователь установил на своих компьютерах двоичные файлы SSL и определенные для IRC-клиента исправления или модули). Некоторые сети также используют SSL для межсерверных соединений и предоставляют специальный флаг канала (например, +S), чтобы разрешать использование на канале только пользователей, подключенных по протоколу SSL, при этом запрещая идентификацию оператора открытым текстом, чтобы лучше использовать преимущества, предоставляемые SSL. . [82] [83]

IRC служил первой лабораторией для многих видов интернет-атак, таких как использование поддельных сообщений о недоступности ICMP для разрыва IRC-соединений на основе TCP ( ядерное уничтожение ), чтобы раздражать пользователей или облегчить захват .

Предотвращение злоупотреблений [ править ]

Один из наиболее спорных технических вопросов, связанных с реализациями IRC, который сохранился до сих пор, - это заслуга протоколов «Nick / Channel Delay» и «Timestamp». Оба метода существуют для решения проблемы атак типа «отказ в обслуживании», но используют очень разные подходы. Проблема с исходным протоколом IRC в том виде, в котором он был реализован, заключалась в том, что при разделении и воссоединении двух серверов две стороны сети просто объединяли свои каналы. Если бы пользователь мог присоединиться к «разделенному» серверу, где канал, который существовал на другой стороне сети, был пуст, и получить статус оператора, он стал бы оператором канала «комбинированного» канала после netsplit.закончился; если пользователь взял псевдоним, который существовал на другой стороне сети, сервер убил бы обоих пользователей при повторном присоединении (т. е. «ник-коллизия»). Этим часто злоупотребляли для «массового уничтожения» всех пользователей на канале, создавая таким образом «бесполезные» каналы, где не было операторов, которые могли бы справиться со злоупотреблениями. Помимо возникновения проблем внутри IRC, это побуждало людей проводить атаки типа «отказ в обслуживании» против серверов IRC, чтобы вызвать расщепления сети , которыми они затем могли бы злоупотреблять.

Задержка ник (НД) и канал задержка стратегия (CD) направлены на предотвращение злоупотреблений путем задержки переподключения и переименовывает. После того, как пользователь выйдет из системы и псевдоним станет доступным, или канал прекратит свое существование, потому что все его пользователи разошлись (как это часто бывает во время netsplit ), сервер не позволит никому из пользователей использовать этот псевдоним или присоединиться к этому каналу до тех пор, пока не наступит определенный период. период времени ( задержка ) прошел. Идея заключается в том, что даже если нетсплитЭто бесполезно для злоумышленника, потому что он не может получить псевдоним или статус оператора на канале, и, таким образом, не может произойти конфликт псевдонима или «слияние» канала. В некоторой степени это причиняет неудобства законным пользователям, которые могут быть вынуждены на короткое время использовать другое имя после повторного присоединения ( популярно добавление подчеркивания ).

Протокол отметок времени является альтернативой задержкам ников / каналов, которые разрешают конфликты с использованием приоритета с отметками времени. Каждому нику и каналу в сети присваивается временная метка - дата и время, когда он был создан. Когда происходит netsplit, два пользователя с каждой стороны могут использовать один и тот же псевдоним или канал, но когда две стороны объединяются, только один может выжить. В случае с никнеймами новый пользователь, согласно их TS, будет убит; когда канал конфликтует, участники (пользователи на канале) объединяются, но операторы канала на «проигрышной» стороне разделения теряют свой статус оператора канала.

TS - гораздо более сложный протокол, чем ND / CD, как по дизайну, так и по реализации, и, несмотря на то, что он прошел несколько изменений, в некоторых реализациях все еще есть проблемы с «рассинхронизацией» (когда два сервера в одной сети расходятся во мнениях о текущем состоянии сеть) и слишком снисходительно относиться к тому, что позволяла «проигравшая» сторона. В исходных протоколах TS, например, не было защиты от пользователей, устанавливающих запреты или другие режимы в проигрывающем канале, которые затем будут объединены при повторном присоединении разделения, даже если пользователи, которые установили эти режимы, потеряли свой статус оператора канала. Некоторые современные IRC-серверы на базе TS также включают некоторую форму ND и / или CD в дополнение к меткам времени в попытке еще больше обуздать злоупотребления.

Большинство сетей сегодня используют подход с метками времени. Разногласия между отметками времени и ND / CD привели к тому, что несколько серверов отделились от EFnet и сформировали новый IRCnet . После разделения EFnet перешла на протокол TS, а IRCnet использовала ND / CD.

В последних версиях IRCnet ircd, а также ircds, использующих протокол TS6 (включая Charybdis), ND был расширен / заменен механизмом SAVE. Этот механизм присваивает каждому клиенту UID при подключении к серверу IRC. Этот идентификатор начинается с номера, который запрещен в никах (хотя некоторые ircds, а именно IRCnet и InspIRCd, позволяют клиентам переключаться на свой собственный UID в качестве псевдонима).

Если два клиента с одинаковым псевдонимом присоединяются с разных сторон netsplit («конфликт ников»), первый сервер, который увидит это столкновение, заставит обоих клиентов изменить свой ник на свой UID, тем самым спасая обоих клиентов от отключения. В IRCnet псевдоним также будет заблокирован на некоторое время (ND), чтобы оба клиента не смогли вернуться к исходному нику, что приведет к повторному конфликту.

Клиенты [ править ]

Клиентское программное обеспечение [ править ]

Схема IRC-сети с обычными клиентами (зеленый), ботами (синий) и баунсерами (оранжевый)

Клиентское программное обеспечение существует для различных операционных систем или программных пакетов, а также для сетевых или внутренних игр. Доступно множество различных клиентов для различных операционных систем, включая Windows , Unix и Linux , Mac OS X и мобильные операционные системы (например, iOS и Android ). В Windows mIRC - один из самых популярных клиентов. [84]

Некоторые программы, расширяемые с помощью плагинов, также служат платформами для клиентов IRC. Например, клиент под названием ERC , полностью написанный на Emacs Lisp , включен в версию 22.3 Emacs. Следовательно, любая платформа, на которой может работать Emacs, может запускать ERC.

Ряд веб-браузеров имеют встроенные клиенты IRC, такие как Opera ( версия 12.18 и более ранняя ) [85] и надстройка ChatZilla для Mozilla Firefox (для Firefox 56 и более ранних версий ; входит в качестве встроенного компонента SeaMonkey ) . Веб-клиенты, такие как Mibbit и KiwiIRC с открытым исходным кодом, могут работать в большинстве браузеров.

Такие игры, как War§ow , [86] Unreal Tournament (до Unreal Tournament 2004 ), [87] Uplink , [88] игры, основанные на Spring Engine , 0 AD и ZDaemon включали IRC. [89]

Интерфейс чата Ustream - это IRC с пользовательской аутентификацией [90], а также интерфейс Twitch (ранее Justin.tv). [91] [92]

Боты [ править ]

Типичное использование ботов в IRC - предоставление услуг IRC или определенных функций в канале, таких как размещение игры на основе чата или предоставление уведомлений о внешних событиях. Однако некоторые IRC-боты используются для запуска злонамеренных атак, таких как отказ в обслуживании, рассылка спама или эксплуатация. [93]

Вышибала [ править ]

Программа, которая работает как демон на сервере и функционирует как постоянный прокси-сервер , известна как BNC или bouncer. Цель состоит в том, чтобы поддерживать соединение с IRC-сервером, действуя как ретранслятор между сервером и клиентом, или просто действовать как прокси. [ необходима цитата ] Если клиент потеряет подключение к сети, BNC может оставаться подключенным и архивировать весь трафик для последующей доставки, позволяя пользователю возобновить сеанс IRC, не прерывая подключение к серверу. [94]

Кроме того, для получения эффекта вышибалы IRC-клиент (обычно текстовый , например Irssi ) может быть запущен на постоянно активном сервере, к которому пользователь подключается через ssh . Это также позволяет устройствам, которые имеют только функции ssh, но не установлен фактический клиент IRC, подключаться к IRC, и это позволяет совместно использовать сеансы IRC. [95]

Чтобы IRC-клиент не завершал работу при закрытии ssh-соединения, клиент может быть запущен внутри терминального мультиплексора, такого как GNU Screen или tmux , таким образом, оставаясь постоянно подключенным к IRC-сетям и имея возможность регистрировать разговоры в каналах, которые пользователь заинтересован в том, чтобы поддерживать присутствие канала в сети. По образцу этой установки в 2004 году был запущен IRC-клиент, следующий по модели клиент-сервер , названный Smuxi . [96] [97]

Поисковые системы [ править ]

Доступны многочисленные поисковые системы, которые помогают пользователю найти то, что они ищут в IRC. [98] [99] Обычно поисковая машина состоит из двух частей: «внутренней» (или «поисковой системы») и внешней «поисковой машины».

Серверная часть (паук / веб-краулер) - это рабочая лошадка поисковой системы. Он отвечает за сканирование серверов 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 , {| } в псевдонимах следует рассматривать как строчные эквиваленты [\] соответственно. [15] К концу 1990-х годов использование 7-битных кодировок исчезло в пользу ISO 8859-1., и такие сопоставления эквивалентности были удалены из некоторых демонов IRC.
  • 8-битная эра: с начала 1990-х годов для европейских языков стали широко использоваться 8-битные кодировки, такие как ISO 8859-1 . Российские пользователи могли выбирать между KOI8-R , ISO 8859-5 [ необходима ссылка ] и CP1251 , и примерно с 2000 года современные российские IRC-сети осуществляют преобразование между этими различными обычно используемыми кодировками кириллицы .
  • Многобайтовая эпоха: в течение долгого времени восточноазиатские IRC-каналы с логографическими скриптами в Китае, Японии и Корее использовали многобайтовые кодировки, такие как EUC или ISO-2022-JP . С общим переходом с ISO 8859 на UTF-8 на платформах Linux и Unix примерно с 2002 года, UTF-8 становится все более популярной заменой многих из ранее используемых 8-битных кодировок в европейских каналах. Некоторые клиенты IRC теперь могут читать сообщения как в ISO 8859-1, так и в UTF-8 в одном канале, эвристически автоматически определяя используемую кодировку. Переход на UTF-8 начался, в частности, в финскоязычном IRC ( Merkistö (финский) ).

Сегодня кодировка UTF-8 Unicode / ISO 10646 будет наиболее вероятным претендентом на единую будущую стандартную кодировку символов для всей связи IRC, если такой стандарт когда-либо ослабит ограничение на размер сообщения в 510 байт. UTF-8 совместим с ASCII и охватывает расширенный набор всех других широко используемых стандартов набора кодированных символов .

Обмен файлами [ править ]

Подобно обычному обмену файлами P2P , пользователи могут создавать файловые серверы, которые позволяют им обмениваться файлами друг с другом, используя настраиваемые боты или сценарии IRC для своих клиентов IRC . Часто пользователи объединяются, чтобы распространять варез через сеть IRC-ботов. [100]

Технически IRC сам по себе не предоставляет механизмов передачи файлов ; совместное использование файлов осуществляется IRC- клиентами , обычно с использованием протокола Direct Client-to-Client (DCC), в котором передача файлов согласовывается посредством обмена личными сообщениями между клиентами. Подавляющее большинство клиентов IRC поддерживают передачу файлов DCC, отсюда и мнение, что совместное использование файлов является неотъемлемой особенностью IRC. [101] Обычное использование этого протокола, однако, иногда также вызывает спам DCC. Команды DCC также использовались для использования уязвимых клиентов для выполнения таких действий, как отключение от сервера или выход из клиента.

См. Также [ править ]

  • Чат-комната
  • Клиент-клиентский протокол
  • Сравнение протоколов обмена мгновенными сообщениями
  • Сравнение IRC-клиентов
  • Сравнение мобильных IRC-клиентов
  • Игроки Hamnet
  • Интернет-сленг
  • Список команд IRC
  • Канал обслуживания

Ссылки [ править ]

  1. ^ a b c d «Введение» . Протокол интернет-ретрансляции чата . п. 4. сек. 1. дои : 10,17487 / RFC1459 . RFC 1459 .
  2. ^ "Один ко многим" . Протокол интернет-ретрансляции чата . п. 11. сек. 3.2. DOI : 10,17487 / RFC1459 . RFC 1459 .
  3. ^ «Индивидуальное общение» . Интернет-чат с ретрансляцией: Архитектура . п. 5. сек. 5.1. DOI : 10,17487 / RFC2810 . RFC 2810 .
  4. ^ Ролло, Трой. «Описание протокола DCC» . irchelp.org . Проверено 8 апреля 2011 года .
  5. Ван, Уоллес (25 октября 2004 г.). «Обмен мгновенными сообщениями и онлайн-чаты: Интернет-ретранслятор (IRC)» . Украдите эту книгу для обмена файлами (1-е изд.). Сан-Франциско, Калифорния : Пресс без крахмала . С.  61–67 . ISBN 978-1-59327-050-6.
  6. ^ "SAGE IRC Channel" . Sage - Специальная группа по интересам USENIX для системных администраторов. Архивировано из оригинала 7 февраля 2012 года . Проверено 18 апреля 2011 года .
  7. ^ a b c «Сети IRC - 100 лучших» . irc.netsplit.de . Проверено 8 апреля 2011 года .
  8. ^ "Серверы IRC - Резюме" . irc.netsplit.de. Архивировано из оригинального 22 апреля 2011 года . Проверено 8 апреля 2011 года .
  9. ^ a b c "IRC мертв, да здравствует IRC" . Пингдом . 24 апреля 2012 . Проверено 25 апреля 2016 года .
  10. ^ a b c d e f g h i j k Даниэль Стенберг (29 марта 2011 г.). «История IRC (Internet Relay Chat)» . Проверено 25 апреля 2016 года . Я всего этого не испытал. Я нашел информацию в разных местах и ​​получил информацию от разных людей, чтобы написать это. Мне в этом помогли: Грег "wumpus" Линдал, Веса "vesa" Руоконен, Джеймс Нг, Туомас Хейно, Ричард (орел в сети), Ари Леммке
  11. ^ Oikarinen, Яркко . «Основание IRC» . Проверено 8 апреля 2011 года .
  12. ^ "Стенограммы IRC со времени попытки советского государственного переворота 1991 года" . Чапел-Хилл, Северная Каролина : ibiblio . Архивировано из оригинального 28 июня 2009 года . Проверено 8 апреля 2011 года .
  13. ^ "Журналы IRC событий войны в Персидском заливе" . Чапел-Хилл, Северная Каролина : ibiblio . Проверено 8 апреля 2011 года .
  14. ^ «Журналы основных событий в онлайн-сообществе» . Чапел-Хилл, Северная Каролина : ibiblio . Проверено 8 апреля 2011 года .
  15. ^ a b c «Коды символов» . Протокол интернет-ретрансляции чата . п. 7. сек. 2.2. DOI : 10,17487 / RFC1459 . RFC 1459 .
  16. ^ Энген Vegard (май 2000). «Великий раскол» . IRC.org . Проверено 25 апреля 2016 года .
  17. ^ "Режимы канала" . Вики по документации UnrealIRCd . Проверено 6 января 2018 .
  18. ^ «Маскировка» . Вики по документации UnrealIRCd . Проверено 6 января 2018 .
  19. ^ "Blitzed Open Proxy Monitor выключается" . Open Proxy Monitor, который был предоставлен сетью Blitzed IRC, был отключен ... База данных была настолько большой, что для команды было почти невозможно выполнить резервное копирование или найти новое место для продолжения обслуживания. Кроме того, у большинства членов команды больше нет времени, чтобы поддерживать работу службы.
  20. ^ "IRCv3" . Рабочая группа IRCv3. 2016 . Проверено 25 апреля 2016 года . Рабочая группа IRCv3 - это собрание авторов клиентского и серверного программного обеспечения IRC, работающих над улучшением, поддержкой и стандартизацией протокола IRC с использованием обратно-совместимых расширений.
  21. ^ «Сети - IRCv3» . 2019 . Дата обращения 9 августа 2019 .
  22. ^ "Топ-10 netsplit.de" . Проверено 25 апреля 2016 года .
  23. ^ a b Харалабидис, Алекс (15 декабря 1999 г.). «IRCing на Macintosh: Ircle». Книга IRC: полное руководство по ретрансляционному чату в Интернете (1-е изд.). Сан-Франциско, Калифорния : Пресс без крахмала. п. 61 . ISBN 978-1-886411-29-6. В больших сетях, таких как Большая четверка - EFnet, IRCnet, Undernet и DALnet - попытка перечислить тысячи каналов с помощью Ircle всегда приводит к отключению из-за потока информации, в то время как другие клиенты обычно могут справиться с этим, если вы находятся на прямом соединении Ethernet.
  24. ^ а б Джонс, Стив, изд. (10 декабря 2002 г.). «Интернет-чат». Энциклопедия новых средств массовой информации: существенная ссылка на коммуникацию и технологии (1-е изд.). Таузенд-Оукс, Калифорния : Публикации SAGE . п. 257 . ISBN 978-0-7619-2382-4. Сегодня существуют сотни независимых сетей IRC, но «большую четверку» составляют EFNet, UnderNet, Dalnet и IRCnet.
  25. ^ a b Риттнер, Дон (3 марта 1999 г.). Книга iMac (1-е изд.). Скоттсдейл, Аризона : Группа Кориолиса. п. 215. ISBN 978-1-57610-429-3. Существует несколько крупных сетей: EFnet, UnderNET, DALnet и IRCnet составляют большую четверку.
  26. ^ Тюрбан, Ефраим; Лейднер, Дороти; Маклин, Ефрем; Уэтерби, Джеймс (7 февраля 2005 г.). "Коммуникация". Информационные технологии для управления: трансформация организаций в цифровой экономике (5-е изд.). Хобокен, Нью-Джерси : John Wiley & Sons . С. 106–107. ISBN 978-0-471-70522-2. Крупнейшие сети традиционно объединяются в «большую четверку»: EFNet, IrcNet, QuakeNet и UnderNet.
  27. ^ «Сети IRC - 100 лучших» . irc.netsplit.de . netsplit.de . Проверено 29 октября 2018 года .
  28. ^ "Серверы" . Протокол интернет-ретрансляции чата . п. 4. сек. 1.1. DOI : 10,17487 / RFC1459 . RFC 1459 .
  29. ^ «Клиенты» . Интернет-чат с ретрансляцией: Архитектура . п. 3. сек. 2.2. DOI : 10,17487 / RFC2810 . RFC 2810 .
  30. ^ «Клиенты» . Протокол интернет-ретрансляции чата . п. 5. сек. 1.2. DOI : 10,17487 / RFC1459 . RFC 1459 .
  31. ^ "Номера портов" . Марина-дель-Рей, Калифорния : Управление по присвоению номеров в Интернете . 6 апреля 2011 . Проверено 8 апреля 2011 года .
  32. ^ "Подключить сообщение" . Протокол интернет-ретрансляции чата . п. 29. сек. 4.3.5. DOI : 10,17487 / RFC1459 . RFC 1459 .
  33. ^ Лукас, Марк; Сингх, Абхишек; Кантрелл, Крис (5 октября 2006 г.). «Определение брандмауэра». В Хенми, Энн (ред.). Политики межсетевого экрана и конфигурации VPN . Рокленд, Массачусетс : Syngress Publishing . п. 93. ISBN 978-1-59749-088-7.
  34. Авраам, Дален (июнь 1998 г.). Расширения протокола Internet Relay Chat Protocol (IRCX) . IETF . ID draft-pfenning-irc-extensions-04 . Проверено 8 апреля 2011 года .
  35. ^ «Архитектура» . Интернет-чат с ретрансляцией: Архитектура . стр. 3 - 4. сек. 3. DOI : 10,17487 / RFC2810 . RFC 2810 .
  36. ^ «Введение» . Интернет-чат с ретрансляцией: Архитектура . п. 2. сек. 1. дои : 10,17487 / RFC2810 . RFC 2810 .
  37. ^ «Алгоритмы» . Протокол интернет-ретрансляции чата . п. 64. сек. 9.3. DOI : 10,17487 / RFC1459 . RFC 1459 .
  38. ^ "Перегрузка сети" . Интернет-чат с ретрансляцией: Архитектура . С. 7 - 8. сек. 6.3. DOI : 10,17487 / RFC2810 . RFC 2810 .
  39. ^ "К каналу" . Интернет-чат с ретрансляцией: Архитектура . С. 5 - 6. сек. 5.2.1. DOI : 10,17487 / RFC2810 . RFC 2810 .
  40. ^ "Демоны IRC для LAN" . Проверено 2 октября 2014 года .
  41. ^ «Запуск собственного IRC-сервера» . Проверено 2 октября 2014 года .
  42. ^ "Формат сообщения в 'псевдо' BNF" . Протокол интернет-ретрансляции чата . п. 8. сек. 2.3.1. DOI : 10,17487 / RFC1459 . RFC 1459 .
  43. ^ "Числовые ответы" . Протокол интернет-ретрансляции чата . п. 10. сек. 2.4. DOI : 10,17487 / RFC1459 . RFC 1459 .
  44. ^ "Режимы списка IRC - расширение режима списка, показывающее путаницу пар для списков" . 25 ноября 2009 . Проверено 8 апреля 2011 года .
  45. ^ a b «Группе (каналу)» . Протокол интернет-ретрансляции чата . п. 11. сек. 3.2.2. DOI : 10,17487 / RFC1459 . RFC 1459 .
  46. ^ "Список сообщений" . Протокол интернет-ретрансляции чата . п. 24. сек. 4.2.6. DOI : 10,17487 / RFC1459 . RFC 1459 .
  47. ^ a b «Присоединиться к сообщению» . Протокол интернет-ретрансляции чата . п. 19. сек. 4.2.1. DOI : 10,17487 / RFC1459 . RFC 1459 .
  48. ^ "Объем канала" . Интернет-чат с ретрансляцией: управление каналами . стр. 3 - 4. сек. 2.2. DOI : 10,17487 / RFC2811 . RFC 2811 .
  49. ^ «Свойства канала» . Интернет-чат с ретрансляцией: управление каналами . п. 4. сек. 2.3. DOI : 10,17487 / RFC2811 . RFC 2811 .
  50. ^ «Время жизни канала» . Интернет-чат с ретрансляцией: управление каналами . п. 5. сек. 3. DOI : 10,17487 / RFC2811 . RFC 2811 .
  51. ^ "Режимы канала" . Интернет-чат с ретрансляцией: управление каналами . п. 7. сек. 4. DOI : 10,17487 / RFC2811 . RFC 2811 .
  52. ^ "Сообщение режима" . Протокол интернет-ретрансляции чата . п. 21. сек. 4.2.3. DOI : 10,17487 / RFC1459 . RFC 1459 .
  53. ^ "Режимы канала" . Протокол интернет-ретрансляции чата . С. 21 - 22. сек. 4.2.3.1. DOI : 10,17487 / RFC1459 . RFC 1459 .
  54. ^ «Контроль доступа к каналу» . Интернет-чат с ретрансляцией: управление каналами . С. 10 - 11. сек. 4.3. DOI : 10,17487 / RFC2811 . RFC 2811 .
  55. ^ a b "Ответы на команду: 353 RPL_NAMREPLY" . Протокол интернет-ретрансляции чата . п. 51. DOI : 10,17487 / RFC1459 . RFC 1459 .
  56. ^ Roeckx, Курт (14 октября 2004). «Число 005: ISUPPORT» . irc.org . Проверено 10 апреля 2011 года .
  57. ^ Brocklesby, Эдвард (сентябрь 2002). IRC RPL_ISUPPORT Числовое определение . IETF . ID draft-brocklesby-irc-isupport-03 . Проверено 10 апреля 2011 года .
  58. ^ "Сообщение Operwall" . Протокол интернет-ретрансляции чата . п. 41. сек. 5.6. DOI : 10,17487 / RFC1459 . RFC 1459 .
  59. Мясник, Саймон (12 января 2005 г.). «Список пользовательских режимов IRC» . alien.net.au . Проверено 10 апреля 2011 года .
  60. Мясник, Саймон (12 января 2005 г.). «Список режимов канала IRC» . alien.net.au . Проверено 10 апреля 2011 года .
  61. Мясник, Саймон (12 января 2005 г.). «Список режимов IRC-сервера» . alien.net.au . Проверено 10 апреля 2011 года .
  62. ^ Олсен, Томми. «Режимы IRCd» . webtoman.com. Архивировано из оригинального 15 октября 2011 года . Проверено 10 апреля 2011 года .
  63. ^ a b «Операторы» . Протокол интернет-ретрансляции чата . п. 5. сек. 1.2.1. DOI : 10,17487 / RFC1459 . RFC 1459 .
  64. ^ Thiedeke, Удо (23 сентября 2003). "Никола Деринг, Александр Шестаг" . Virtuelle Gruppen: Charakteristika und Problemdimensionen (на немецком языке) (2-е изд.). Спрингер В.С.  [ де ] . стр. 314, 337. ISBN 978-3-531-33372-4. Проверено 30 марта 2010 года .
  65. Rogers, Russ (1 декабря 2004 г.). «Разум террора» . В Девост, Мэтью Г. (ред.). Взлом террористической сети: тихая угроза скрытых каналов (1-е изд.). Рокленд, Массачусетс : Syngress Publishing . п. 10. ISBN 978-1-928994-98-5. Проверено 30 марта 2010 года .
  66. ^ Петерсен, Джули К., изд. (29 мая 2002 г.). «Интернет-чат» . Иллюстрированный словарь по телекоммуникациям (2-е изд.). CRC Press . п. 500. ISBN 978-0-8493-1173-4. Проверено 30 марта 2010 года .
  67. ^ «Часто задаваемые вопросы» . freenode . Архивировано из оригинального 26 марта 2010 года . Проверено 30 марта 2010 года .
  68. ^ "IRC / Cloaks" . Мета-вики . Проверено 27 ноября 2011 года .
  69. ^ «Схемы универсального идентификатора ресурса (URI)» . Управление по присвоению номеров в Интернете . Проверено 14 октября 2012 года .
  70. Мясник, Саймон (январь 2003 г.). Унифицированные схемы указателя ресурсов для объектов чата с ретрансляцией через Интернет . IETF . ID draft-butcher-irc-url-04 . Проверено 10 апреля 2011 года .
  71. ^ https://www.npmjs.com/package/node-irc
  72. ^ "Размер" . Обсуждение компьютерных сетевых конференций . С. 5 - 6. сек. 2.5.1. DOI : 10,17487 / RFC1324 . RFC 1324 .
  73. ^ «Масштабируемость» . Интернет-чат с ретрансляцией: Архитектура . п. 7. сек. 6.1. DOI : 10,17487 / RFC2810 . RFC 2810 .
  74. ^ Loesch 2003 1.2.1 Рост
  75. ^ «Идентификация пользователя» . Обсуждение компьютерных сетевых конференций . п. 10. сек. 5.4.1. DOI : 10,17487 / RFC1324 . RFC 1324 .
  76. ^ «Деревья и циклы» . Обсуждение компьютерных сетевых конференций . п. 10. сек. 5.4.2. DOI : 10,17487 / RFC1324 . RFC 1324 .
  77. ^ Loesch 2003 1.2.2 Сбои сети
  78. ^ "Государственные информационные проблемы" . Обсуждение компьютерных сетевых конференций . п. 4. сек. 2.1. DOI : 10,17487 / RFC1324 . RFC 1324 .
  79. ^ Loesch 2003 1.2.3 Социологические аспекты и аспекты безопасности
  80. ^ "Передача сообщений" . Обсуждение компьютерных сетевых конференций . п. 7. сек. 5.2.1. DOI : 10,17487 / RFC1324 . RFC 1324 .
  81. ^ "Конференц-безопасность" . Обсуждение компьютерных сетевых конференций . п. 8. сек. 5.2.4. DOI : 10,17487 / RFC1324 . RFC 1324 .
  82. ^ «Получение помощи в EsperNet» . Сеть EsperNet IRC . Проверено 31 июля 2012 года .
  83. ^ Брэндон (18 мая 2010 г.). «Новая функция: SSL для пользователей» . ДАЛнет . Проверено 31 июля 2012 года .
  84. ^ Смит, Родерик В. (8 апреля 2000 г.). «Интернет: использование IRC для получения помощи» . Справочник по настройке мультизагрузки . Серия справочников. Река Аппер Сэдл, Нью-Джерси : Que Publishing . п. 289 . ISBN 978-0-7897-2283-6. Проверено 25 июля 2010 года . mIRC - один из самых популярных клиентов Windows IRC.
  85. ^ "Opera Browser Wiki: IRC-клиент" . Архивировано из оригинального 17 марта 2011 года . Проверено 10 апреля 2011 года .
  86. ^ "Warsow Wiki: модуль IRC" . Архивировано из оригинального 25 апреля 2011 года . Проверено 10 апреля 2011 года .
  87. ^ Гюнтер, Daniel (21 июня 2004). «Обзор UT2004» . BCCHardware . Проверено 10 апреля 2011 года .
  88. ^ "Полное руководство по восходящей линии связи" . Проверено 10 апреля 2011 года .
  89. ^ "ZDaemon - The Doom Wiki: Другие утилиты" . Проверено 10 апреля 2011 года .
  90. ^ «Как настроить [sic] IRC-клиент для подключения и входа [sic] в Ustream» . Устрим-Помощники. 29 января 2012 . Проверено 27 апреля 2013 года .
  91. ^ Mauldor (20 июня 2010). "Ustream против Justin.tv" . LiquidSilver . Проверено 13 июля 2011 года .
  92. ^ "Twitch IRC" . Справочный центр Twitch . 7 апреля 2017 . Проверено 30 октября 2017 года .
  93. ^ Канаван, Джон. «Эволюция вредоносных IRC-ботов» (PDF) . www.symantec.com . Symantec Security Response.
  94. ^ "PsyBNC Readme" . psybnc.at . Проверено 10 апреля 2011 года .
  95. Кэри, Крис (18 июля 2009 г.). «IRC с irssi-прокси + экран» . chriscarey.com . Проверено 10 апреля 2011 года .
  96. ^ «Съемный интерфейс (переписывание ядра) / порт UML / Windows (удар по Glade)» . smuxi.org. 25 декабря 2004 . Проверено 25 июля 2010 года .
  97. ^ "О Smuxi" . smuxi.org . Проверено 10 апреля 2011 года .
  98. ^ Баранина, Пол (27 июля 2004). «Пользователи и каналы». IRC Hacks (1-е изд.). Севастополь, Калифорния : O'Reilly Media . С. 44–46. ISBN 978-0-596-00687-7.
  99. Ван, Уоллес (25 октября 2004 г.). «Обмен мгновенными сообщениями и онлайн-чаты: Интернет-ретранслятор (IRC)» . Украдите эту книгу для обмена файлами (1-е изд.). Сан-Франциско, Калифорния : Пресс без крахмала . С.  65–67 . ISBN 978-1-59327-050-6.
  100. ^ Vamosi, Роберт (8 мая 2002). «Пиратские фильмы: воспроизводится на сервере рядом с вами» . ZDNet . Проверено 10 апреля 2011 года .
  101. Сасаки, Дарла (4 апреля 2002 г.). «IRC 101: что это такое и как им пользоваться?» . Macobserver.com . Проверено 10 апреля 2011 года .

Библиография [ править ]

  • Рид, Даррен (май 1992 г.). Обсуждение компьютерных сетевых конференций . IETF . DOI : 10,17487 / RFC1324 . RFC 1324 . Проверено 30 октября 2009 года .
  • Оикаринен, Яркко ; Рид, Даррен (май 1993 г.). Протокол интернет-ретрансляции чата . IETF . DOI : 10,17487 / RFC1459 . RFC 1459 . Проверено 30 октября 2009 года .
  • Кальт, Кристоф (апрель 2000 г.). Интернет-чат с ретрансляцией: Архитектура . IETF . DOI : 10,17487 / RFC2810 . RFC 2810 . Проверено 30 октября 2009 года .
  • Кальт, Кристоф (апрель 2000 г.). Интернет-чат с ретрансляцией: управление каналами . IETF . DOI : 10,17487 / RFC2811 . RFC 2811 . Проверено 30 октября 2009 года .
  • Леш, Карл (17 июля 2003 г.). «Функциональные возможности, предоставляемые системами синхронной конференц-связи» . psyc.eu . Проверено 10 апреля 2011 года . Цитировать журнал требует |journal=( помощь )

Дальнейшее чтение [ править ]

  • Кальт, Кристоф (апрель 2000 г.). Интернет-чат с ретрансляцией: клиентский протокол . IETF . DOI : 10,17487 / RFC2812 . RFC 2812 . Проверено 30 октября 2009 года .
  • Кальт, Кристоф (апрель 2000 г.). Интернет-чат с ретрансляцией: протокол сервера . IETF . DOI : 10,17487 / RFC2813 . RFC 2813 . Проверено 30 октября 2009 года .
  • «Журналы основных событий в онлайн-сообществе» . Чапел-Хилл, Северная Каролина : ibiblio . Проверено 8 апреля 2011 года .
  • Мясник, Саймон. «Техническая информация IRC» . alien.net.au . Проверено 10 апреля 2011 года .

Внешние ссылки [ править ]

  • IRC в Curlie
  • Список номеров IRC
  • История IRC
  • IRC.org - техническая и историческая информация о IRC6; Статьи по истории IRC
  • IRChelp.org - архив справки Internet Relay Chat (IRC); Большой архив документов по IRC
  • IRCv3 - рабочая группа разработчиков, которые добавляют новые функции в протокол и пишут для них спецификации
  • IRC-Source - Internet Relay Chat (IRC) сеть и поисковая система каналов с историческими данными
  • irc.netsplit.de - список сетей Internet Relay Chat (IRC) с историческими данными