Page semi-protected

인터넷 릴레이 채팅

Internet Relay Chat
"IRC"가 여기로 리디렉션됩니다. 기타 용도에 대해서는 IRC(동음이의)를 참조하십시오. 위키백과 관련 IRC 채널은 위키백과를 참조하십시오.IRC.
인터넷 릴레이 채팅
통신 규약
약어IRC
목적인스턴트 메시징
개발자Jarkko Oikarinen
서론1988년 8월; 35년 전(1988-08)
영향받은아직 대체되지 않았습니다.
IRCv3(표준공정작업반)
OSI 계층응용계층
포트6667, 6697
RFC(들)RFC 1459
인터넷 프로토콜 제품군
응용계층
수송층
인터넷 계층
링크층
Oulu 대학 컴퓨터 센터 근처에 전시된 첫 번째 IRC 서버인 tolsun.oulu.fi

인터넷 릴레이 채팅(IRC)은 인스턴트 메시징을 위한 텍스트 기반 채팅 시스템입니다. IRC는 채널이라고 불리는 토론 포럼에서의 그룹 커뮤니케이션을 위해 설계되었지만 [1]파일 공유를 [3]포함한 채팅 및 데이터 전송뿐만 아니라 개인 메시지를[2] 통한 일대일 통신도 가능합니다.[4]

인터넷 중계 채팅은 텍스트 형태의 통신을 용이하게 하기 위해 응용 계층 프로토콜로 구현됩니다. 채팅 프로세스는 클라이언트-서버 네트워킹 모델에서 작동합니다. 사용자는 클라이언트(웹 앱, 독립형 데스크톱 프로그램, 또는 대규모 프로그램의 일부에 내장된 클라이언트)를 사용하여 대규모 IRC 네트워크의 일부인 IRC 서버에 연결합니다. 연결하는 데 사용되는 프로그램의 예로는 Mibbit, IRCCloud, KiwiIRC, mIRC 등이 있습니다.

IRC 사용량은 2003년 이후 지속적으로 감소하여 사용자의 60%를 잃었습니다.[5] 2011년 4월, 상위 100대 IRC 네트워크는 한 번에 200,000명 이상의 사용자에게 서비스를 제공했습니다.[6]

히스토리

참고 항목: IRCd § 내역

IRC는 1988년 8월 Jarkko Oikarinen이 핀란드 Oulu 대학의 OuluBox라는 BBS에서 MUT(Multi User Talk)라는 프로그램을 대체하기 위해 만들어졌으며, 그곳에서 정보처리과학부에서 일하고 있었습니다. Jarkko는 자신이 관리한 BBS 소프트웨어를 확장하여 유즈넷 스타일의 뉴스, 실시간 토론 및 유사한 BBS 기능을 허용하고자 했습니다. 그가 구현한 첫 번째 부분은 그의 친구인 Jyrki Kuoppala와 Jukka Pihl이 쓴 빌린 부분으로 한 채팅 부분이었습니다. 최초의 IRC 네트워크는 tolsun.oulu.fi 이라는 단일 서버에서 실행되고 있었습니다. Oikarinen은 BITNET에서 작동하는 Bitnet Relay로 알려진 채팅 시스템에서 영감을 찾았습니다.[8]

Jyrki Kuoppala는 Oikarinen에게 Oulu University에 IRC 코드를 해제하여 Oulu 외부에서도 실행할 수 있도록 요청했고, 마침내 IRC 코드를 해제한 후 Jyrki Kuoppala는 즉시 다른 서버를 설치했습니다. 이것이 최초의 "IRC 네트워크"였습니다. Oikarinen은 헬싱키 대학과 탐페레 대학에서 IRC 서버를 실행하기 시작한 친구들을 확보했습니다. 그의 사용자 수가 증가하고 다른 대학들이 곧 따라오자 Oikarinen은 IRC 서버를 실행하기 시작했습니다. 이때 Oikarinen은 BBS의 나머지 기능들이 아마도 그의 프로그램에 맞지 않을 것이라는 것을 깨달았습니다.[7]

오이카리넨은 덴버 대학교와 오리건 주립 대학교의 사람들과 연락을 취했습니다. 그들은 자신의 IRC 네트워크를 실행하고 있었고 핀란드 네트워크에 연결하기를 원했습니다. 그들은 오이카리넨의 친구 중 한 명인 비제이 수브라마니암(Vijay Subramaniam)에게서 프로그램을 얻었는데, 이 프로그램은 핀란드인이 아닌 사람들 중 최초로 IRC를 사용했습니다. 그 후 IRC는 더 커졌고 핀란드 전국 네트워크에서 사용되었습니다.FUNET—그리고 나서 인터넷의 스칸디나비아 지사인 Nordunet에 연결됩니다. 1988년 11월, IRC는 인터넷을 통해 퍼졌고, 1989년 중반에는 전 세계에 40여 개의 서버가 있었습니다.[7]

EFnet

1990년 8월, IRC 세계에서 첫 번째 주요한 의견 불일치가 발생했습니다. "A-net"(아키넷)에는 eris라는 이름의 서버가 포함되어 있습니다.berkeley.edu . 모두 열려 있었고 비밀번호가 필요하지 않았으며 연결 횟수에 제한이 없었습니다. Greg "wumpus" Lindahl이 설명한 바와 같이,[9] "와일드카드 서버 라인이 있어서, 사람들은 서버를 연결하고 모든 사람들을 닉콜링하고 있었습니다." EFnet인 "Eris Free Network"는 Eris 머신을 IRC에서 Q-line(검역용 Q)으로 최초로 만들었습니다. Wumpus의 말에 다시 [9]"Eris는 그 선을 제거하기를 거부했고, 그래서 저는 EFnet을 만들었습니다. 그것은 큰 싸움이 아니었습니다. 저는 모든 허브를 가입시켰고, 다른 사람들은 거의 다 수행했습니다." EFnet은 Eris 서버로 구성된 반면 EFnet은 Eris 서버가 아닌 서버로 구성되었습니다. 기록에 따르면 대부분의 서버와 사용자가 EFnet을 사용한 것으로 나타났습니다. 일단 A-net이 해체되자 EFnet이라는 이름은 무의미해졌고, 다시 한번 유일한 IRC 네트워크였습니다.[7]

그 무렵 IRC는 1991년 소련 쿠데타 시도를 언론 정전 기간 내내 보도하는 데 사용되었습니다.[10] 이전에 걸프 전쟁 동안 비슷한 방식으로 사용되었습니다.[11] 이러한 이벤트 및 기타 이벤트의 채팅 로그는 ibiblio 아카이브에 보관됩니다.[12]

언더넷 포크

지속적인 변화를 가져온 또 다른 포크 노력은 1992년 10월 미국의 "Wildthang"에 의해 시작되었습니다(이는 EFnet ircd 버전 2.8.10으로 시작되었습니다). 단순히 봇을 개발하기 위한 테스트 네트워크가 목적이었지만, 빠르게 "친구와 친구를 위한 네트워크"로 성장했습니다. 유럽과 캐나다에서는 별도의 새로운 네트워크가 작업 중이었고 12월에는 프랑스 서버가 캐나다 서버에 연결되었고, 월말에는 프랑스와 캐나다 네트워크가 미국 네트워크에 연결되어 나중에 "The Undernet"이라고 불리는 네트워크를 형성했습니다.[7]

"언더넷"들은 ircd를 좀 더 발전시켜서 대역폭을 덜 사용하게 하고 EFnet이 겪기 시작한 채널 혼란(넷 분할 및 인수)을 해결하기를 원했습니다. 후자의 목적을 위해 언더넷은 타임스탬프, 새로운 라우팅을 구현하고 CS 서비스를 제공했습니다. 이 프로그램은 사용자가 채널을 등록할 수 있도록 한 다음 문제를 일으키는 사람들로부터 그들을 보호하려고 시도했습니다. 1993년 2월 15일부터 제시된 최초의 서버 목록에는 미국, 캐나다, 프랑스, 크로아티아 및 일본의 서버가 포함되어 있습니다. 8월 15일, 새로운 사용자 수 기록은 57명의 사용자로 설정되었습니다.[7]

1993년 5월, RFC 1459가[13] 발표되었고 클라이언트/서버 운영, 채널, 일대일 및 일대다 대화를 위한 간단한 프로토콜에 대해 자세히 설명합니다.[7] CTCP, 색상 및 형식과 같은 많은 확장 기능이 프로토콜 사양에 포함되지 않고,[14] 문자 인코딩도 포함되지 않아 서버 및 클라이언트의 다양한 구현이 다양하게 이루어졌다는 점이 눈에 띕니다. 소프트웨어 구현은 네트워크마다 매우 다양했는데, 각 네트워크는 고유한 코드 기반에서 고유한 정책과 표준을 구현했습니다.

DALnet 포크

1994년 여름 동안 언더넷은 그 자체로 포크되었습니다. 새로운 네트워크는 더 나은 사용자 서비스와 더 많은 사용자 및 채널 보호를 위해 형성된 DALnet(설립자 이름: dalvenjah)이라고 불립니다. DALnet에서 더 중요한 변화 중 하나는 더 긴 별명(원래 ircd 제한은 9글자)을 사용한 것입니다. DALnet ircd 수정은 Alexei "Lfler" Kosut에 의해 이루어졌습니다. 따라서 DALnet은 Undernet ircd 서버를 기반으로 했지만, 비록 DALnet 선구자들은 EFnet 포기자들이었습니다. 제임스 응(James Ng)에 따르면 초기 DALnet 사람들은 "끊임없는 분열/지연/인수 등으로 인해 #StarTrek에 있는 사람들"이었습니다.[7]

DALnet은 빠르게 글로벌 월옵스(+w(/mode NickName +w)인 사용자가 볼 수 있는 IRCop 메시지), 더 긴 닉네임, Q:Lineed 닉네임(사용할 수 없는 닉네임)을 제공했습니다. ChanServ, IRCop, NickServ 등), 글로벌 K:회선(서버 또는 전체 네트워크에서 한 사람 또는 전체 도메인 금지), IRCop은 통신만 가능: GlobOps, +H 모드 등 IRCop이 "헬프롭"임을 보여줍니다. DALnet의 많은 새로운 기능들은 Brian "Morpher" Smith에 의해 1995년 초에 작성되었으며 사용자들이 별명, 채널 제어, 메모 등을 소유할 수 있게 해줍니다.[7]

IRCnet 포크

1996년 7월, 몇 달간의 불꽃 전쟁과 메일링 리스트에 대한 논의 끝에, ircd의 개발이 어떻게 발전해야 하는지에 대한 의견 차이로 인해 또 한 번 분열이 있었습니다. 가장 주목할 만한 점은, 나중에 IRCnet이라고 명명한 "유럽" 측(대부분의 서버가 유럽에 있음)이 닉과 채널 지연을 주장한 반면, EFnet 측은 타임스탬프를 주장했습니다.[7] 정책에 대해서도 이견이 있었는데, 유럽 측은 IRCops가 할 수 있는 것과 할 수 없는 것을 지시하는 일련의 규칙을 수립하기 시작했는데, 이는 미국 측이 반대하는 관점이었습니다.[15]

IRCnet 서버의 대부분(전부는 아니지만)은 유럽에 있었고, EFnet 서버의 대부분은 미국에 있었습니다. 이 행사는 많은 IRC 사회에서 "The Great Split"이라고도 알려져 있습니다. EFnet은 그 이후(1998년 8월 기준) 성장하여 당시 사용자 수를 넘어섰습니다. 2000년 (북부) 가을, EFnet은 약 50,000명의 사용자와 IRCnet은 70,000명이었습니다.[7]

모던 IRC

IRC는 인터넷에서의 삶에 많은 변화를 가져왔습니다. 새로운 서버 소프트웨어는 다양한 새로운 기능을 추가했습니다.

  • 서비스: 닉네임 및 채널 등록을 용이하게 하는 네트워크 운영 봇, 오프라인 사용자를 위한 메시지 전송 및 네트워크 운영자 기능.
  • 추가 모드: 기존의 IRC 시스템은 표준 사용자 및 채널 모드를 사용했지만, 새로운 서버는 서비스 거부 공격으로부터 보호하기 위해 텍스트에서 컬러 코드를 [16]제거하거나 사용자의 호스트 마스크("클로킹")를 모호하게 하는 등의 기능을 위해 많은 새로운 모드를 추가합니다.[17]
  • 프록시 탐지: 대부분의 최신 서버는 안전하지 않은(잘못 구성되거나 악용된) 프록시 서버를 통해 연결을 시도하는 사용자 탐지를 지원하며, 이 경우 연결이 거부될 수 있습니다. 이 프록시 탐지 소프트웨어는 여러 네트워크에서 사용되지만 프록시의 실시간 목록은 2006년 초부터 비활성화됩니다.[18]
  • 추가 명령: 새 명령은 서비스에 명령을 내리는 약어 명령, 사용자의 호스트 마스크를 조작하는 네트워크 운영자 전용 명령 등이 될 수 있습니다.[citation needed]
  • 암호화: 클라이언트와 서버 간 연결의 다리에는 TLS가 사용될 수 있습니다(표준 연결에서 다른 사용자에게 전달되면 메시지의 보안이 중단되지만 개인의 IRC 세션을 도청하거나 도청하는 것은 어렵습니다). 클라이언트 간 통신에는 SDCC(Secure DCC)를 사용할 수 있습니다.[citation needed]
  • 연결 프로토콜: IRC는 인터넷 프로토콜의 구 버전인 IPv4 또는 프로토콜의 현재 표준인 IPv6을 통해 연결될 수 있습니다.

2016년 현재 IRCv3라는 작업 그룹에서 새로운 표준화 작업이 진행 중이며, 이 작업은 즉각적인 알림, 더 나은 기록 지원 및 향상된 보안과 같은 더 발전된 클라이언트 기능에 초점을 맞추고 있습니다.[19] 2019년 현재 제안된 표준을 완전히 채택한 주요 IRC 네트워크는 없습니다.[20]

2021년 6월 현재 운영 중인 것으로 알려진 IRC 네트워크는 481개이며,[21] 이 중 2021년 5월에 설립된 오픈 소스 LiberaChat이 26개 서버에 20,374개의 채널로 가장 많은 사용자를 보유하고 있으며, 그 중 상위 100개의 IRC 네트워크는 약 1,000개의 서버에서 10만 개 이상의 채널을 공유하고 있습니다.[22]

1990년대와 2000년대 초반의 황금기(2004년 QuakeNet의 24만 사용자) 이후, IRC는 2003년과 2012년 사이에 약 60%의 사용자를 잃으면서 상당한 감소를 보였고, 사용자들은 페이스북이나 트위터와 같은 새로운 소셜 미디어 플랫폼으로 [5]이동했지만 1999년에 개발된 XMPP와 같은 오픈 플랫폼으로도 이동했습니다. 프리노드와 같은 특정 네트워크는 전체적인 추세를 따르지 않았으며 같은 기간 동안 크기가 4배 이상 증가했습니다.[5] 그러나 2016년 약 9만 명의 사용자를 보유했던 프리노드는 이후 약 9,300명의 사용자로 감소했습니다.[23]

가장 큰 IRC 네트워크는 전통적으로 "빅 4"로 분류되어 왔습니다.[24][25][26][27] 이는 통계의 상위를 차지하는 네트워크를 의미합니다. 4대 네트워크는 주기적으로 변화하지만 IRC의 커뮤니티 특성상 사용자가 선택할 수 있는 다른 네트워크가 많습니다.

역사적으로 "빅 4"는 다음과 같습니다.[24][25][26]

IRC는 2001년 600만명, 2004~2005년 1000만명의 동시 접속자를 기록했으며 2021년에는 약 350,000명으로 감소했습니다.[citation needed]

2023년 10월 기준으로 IRC 네트워크의 상위는 다음과 같습니다.

  • Libera Chat – 피크 시간대에 약 32,000명의 사용자가 이용 가능
  • OFTC – 피크 시간대 약 31,000명의 사용자
  • IRCnet – 피크 시간대 약 18,000명의 사용자
  • Undernet – 피크 시간대 약 16,000명의 사용자
  • EFnet – 피크 시간대 약 11,000명의 사용자
  • Rizon – 피크 시간대 약 9,000명의 사용자
  • 무료 노드 – 피크 시간대 약 8.5k 사용자
  • DALnet – 피크 시간대 약 8,000명의 사용자 수
  • QuakeNet – 피크 시간대 약 7,000명의 사용자
  • hackint – 피크 시간대 약 6.5k 사용자
  • ChatZona – 피크 시간대에 약 5.5만 명의 사용자가 발생함

상위 100개 IRC 네트워크는 피크 시간에 약 230,000명의 사용자가 연결되어 있습니다.[28]

타임라인

주요 서버의 타임라인:

기술정보

참고 항목: IRCd
GTK 환경용 IRC 클라이언트 HexChat의 스크린샷
텍스트 기반 IRC 클라이언트인 Irssi

IRC는 TCP와[13] 선택적으로 TLS를 사용하는 개방형 프로토콜입니다. IRC 서버는 다른 IRC 서버에 연결하여 IRC 네트워크를 확장할 수 있습니다.[29] 사용자는 클라이언트를 서버에 연결하여 IRC 네트워크에 액세스합니다.[30] mIRC, HexChat 및 irsi와 같은 많은 클라이언트 구현체와 원래 IRCd와 같은 서버 구현체가 있습니다. 대부분의 IRC 서버는 사용자가 계정을 등록할 필요가 없지만 연결되기 전에 닉네임이 필요합니다.[31]

IRC는 원래 일반 텍스트 프로토콜[13](후에 확장되었지만)이었고, 요청에 따라 IANA에 의해 포트 194/TCP가 할당되었습니다.[32] 그러나 루트 권한을 가진 IRCd 소프트웨어를 실행할 필요가 없도록 6667/TCP[33] 및 인근 포트 번호(예: TCP 포트 6660–6669, 7000)[34]에서 IRC를 실행하는 것이 사실상의 표준이었습니다.

프로토콜은 문자가 8비트임을 지정했지만 텍스트를 인코딩하는 문자는 지정하지 않았습니다.[14] 이로 인해 다른 클라이언트 및/또는 다른 플랫폼을 사용하는 사용자가 대화를 원할 때 문제가 발생할 수 있습니다.

현재 사용되고 있는 모든 클라이언트-투-서버 IRC 프로토콜은 IRC2 서버의 irc2.4.0 버전에 구현된 프로토콜의 후속 버전이며 RFC 1459에 문서화되어 있습니다. RFC 1459가 출판된 이후, irc2.10 구현의 새로운 기능들은 몇몇 수정된 프로토콜 문서들(RFC 2810, RFC 2811, RFC 2812 및 RFC 2813)의 출판으로 이어졌지만, 이러한 프로토콜 변경들은 다른 구현들 사이에서는 널리 채택되지 않았습니다.[citation needed]

IRC 프로토콜에 대한 많은 사양이 발표되었지만 프로토콜이 동적인 상태를 유지하기 때문에 공식적인 사양은 없습니다. 실질적으로 어떤 클라이언트도 없고 매우 적은 수의 서버가 위의 RFC를 참고로 하여 엄격하게 의존합니다.[citation needed]

마이크로소프트는 1998년 독자적인 IRCX를 통해 IRC를 확장했습니다.[35] 그들은 나중에 IRCX를 지원하는 소프트웨어 배포를 중단하고 대신 독자적인 MSNP를 개발했습니다.

IRC 서버 네트워크의 표준 구조는 트리입니다.[36] 메시지는 트리의 필요한 가지만 따라 라우팅되지만 네트워크 상태는 모든 서버에[37] 전송되며 일반적으로 서버 간 신뢰도가 높습니다. 그러나 이 아키텍처에는 여러 가지 문제가 있습니다. 잘못된 동작이나 악의적인 서버는[38] 네트워크에 큰 손상을 줄 수 있으며, 의도적이든 기본 네트워크의 조건의 결과이든 간에 구조를 변경하려면 넷 분할 및 넷 조인이 필요합니다. 이로 인해 많은 네트워크 트래픽이 발생하고[39] 사용자에게 잘못된 종료/가입 메시지가 전송되며 분할 서버에서 사용자에게 일시적으로 통신이 끊깁니다. 대규모 네트워크에 서버를 추가한다는 것은 네트워크의 백그라운드 대역폭 부하가 크고 서버의 메모리 부하가 크다는 것을 의미합니다. 그러나 일단 설정된 각 메시지는 멀티캐스트와 유사한 방식으로 전달되며, 이는 각 메시지가 네트워크 링크를 한 번만 이동한다는 것을 의미합니다.[40] 이는 SMTP([citation needed]Simple Mail Transfer Protocol) 또는 XMPP(Extensible Messaging and Presence Protocol)와 같은 비멀티캐스트 프로토콜과 비교할 때 강점입니다.[citation needed]

IRC 데몬은 LAN(Local Area Network)에서도 사용할 수 있습니다. 따라서 IRC는 로컬 지역 네트워크(내부 통신) 내에서 사람들 간의 통신을 용이하게 하는 데 사용될 수 있습니다.[41][42]

명령 및 응답

주 기사: 인터넷 릴레이 채팅 명령 목록

IRC는 라인 기반 구조를 가지고 있습니다. 클라이언트는 한 줄짜리 메시지를 서버로 보내고,[43] 해당 메시지에[44] 대한 회신을 수신하며, 다른 클라이언트가 보낸 일부 메시지의 복사본을 수신합니다. 대부분의 클라이언트에서 사용자는 명령어에 '/'의 접두사를 붙여 입력할 수 있습니다. 명령어에 따라, 이들은 전적으로 클라이언트에 의해 처리되거나 (일반적으로 클라이언트가 인식하지 못하는 명령의 경우) 서버로 직접 전달될 수 있으며, 아마도 약간의 수정이 있을 것입니다.[45]

프로토콜의 특성상 자동화된 시스템은 전송된 명령을 항상 완전한 신뢰성을 가진 응답과 올바르게 쌍을 이룰 수 없으며 추측의 대상이 됩니다.[46]

채널

확립된 IRC 세션에서 사용자 그룹과 통신하는 기본 수단은 채널을 통해 이루어집니다.[47] 네트워크의 채널은 특정 네트워크에서 모드 +s 또는 +p가 설정되지 [48]않은 현재 사용 가능한 모든 채널을 나열하는 IRC 명령 LIST를 사용하여 표시할 수 있습니다.

사용자는 /join #channelname으로 사용 가능한 대부분의 클라이언트에서 JOIN 명령을 사용하여 채널에 참여할 수 있습니다.[49] 가입된 채널로 전송된 메시지는 다른 모든 사용자에게 전달됩니다.[47]

전체 IRC 네트워크를 통해 사용할 수 있는 채널은 '#'로 접두사가 붙고, 서버에 로컬로 연결된 채널은 '&'[50]을 사용합니다. 다른 덜 일반적인 채널 유형에는 연산자가[51] 없는 '모델리스' 채널인 '+' 채널과 일반적으로 타임스탬프가 없는 네트워크의 타임스탬프 채널 형태인 '!' 채널이 있습니다.[52]

모드

사용자 및 채널은 개별 대소문자 구분[53] 문자로 표시되며 MODE 명령을 사용하여 설정되는 모드를 가질 수 있습니다.[54] 사용자 모드와 채널 모드는 별개이며 동일한 문자를 사용하여 다른 것을 의미할 수 있습니다(예: 사용자 모드 "i"는 보이지 않는 모드이고 채널 모드 "i"는 초대 전용).[55] 일반적으로 모드는 대상(사용자 또는 채널), 설정(+) 또는 설정 해제(-)할 모드 집합 및 모드에 필요한 모든 파라미터를 사용하여 설정 및 해제됩니다.

일부 채널 모드는 파라미터를 취하고 다른 채널 모드는 채널의 사용자에게 적용하거나, 전체적으로 채널에 적용하는 것이 아니라 채널과 연관된 목록에서 마스크(예: 금지 마스크)를 추가하거나 제거합니다.[56] 채널의 사용자에게 적용되는 모드에는 이름 응답[57](채널에[49] 처음 가입하고 names 명령을 사용할 때 클라이언트에게 전송됨)으로 모드를 표시하는 데 사용되는 관련 기호가 있으며 많은 클라이언트에서 채널의 클라이언트의 표시된 사용자 목록에 모드를 표시하거나 사용자의 모드에 대한 고유 표시기를 표시하는 데 사용됩니다.

수신 모드 메시지를 올바르게 구문 분석하고 채널 상태를 추적하려면 클라이언트는 어떤 모드가 어떤 유형인지, 어떤 기호가 어떤 채널의 사용자에게 적용되는지 알아야 합니다. IRC의 초기 구현에서 이것은 클라이언트에서 하드 코드화되어야 했지만, 지금은 숫자 005를 사용하여 연결 시에 클라이언트에 이 정보를 전송하는 ISUPort라는 프로토콜에 대한 사실상의 표준 확장이 있습니다.[58][59]

IRC에는 채널의 사용자에게 적용되는 모드에 관한 작은 설계 결함이 있습니다. 초기 채널 상태를 설정하는 데 사용되는 이름 메시지는 채널의 사용자당 하나의 모드만 전송할 수 있지만 [57]단일 사용자에게 여러 개의 모드를 설정할 수 있습니다. 예를 들어, 사용자가 채널에서 운영자 상태(+o)와 음성 상태(+v)를 모두 유지하면 새 클라이언트는 우선 순위가 낮은 모드(즉, 음성)를 볼 수 없습니다. 이에 대한 해결책은 클라이언트와 서버 모두에서 가능합니다. 일반적인 해결책은 IRCv3 "멀티 프리픽스" 확장을 사용하는 것입니다.[60]

표준(RFC 1459) 모드

사용자모드
편지 기호. 묘사
i 보이지 않음—일반적인 채널이 없거나 정확한 이름을 알지 못하면 볼 수 없음
s 서버 통지를 받습니다.
w 월롭을[61] 받습니다.
o 사용자가 IRC 운영자(ircop)입니다.
채널 모드
편지 기호. 매개변수 묘사
o @ 영향을 받는 사용자 이름 채널 운영자—채널 모드를 변경하고 사용자를 채널 밖으로 쫓아낼 수 있습니다.
s 비밀 채널—채널 목록에 표시되지 않거나 이미 채널에 있는 사용자를 제외한 사용자
p 사설 채널—RFC 1459에 따라 "prv"로 채널 목록에 나열됨
n 사용자가 외부로 채널에 메시지를 보낼 수 없습니다.
m 채널이 조정됨(채널 운영자 또는 채널의 음성 상태를 보유한 사용자만 메시지를 보낼 수 있음)
i 초대된 사용자만 채널에 입장할 수 있습니다.
t 채널 운영자만 채널 주제를 변경할 수 있습니다.
l 리미트넘버 채널에서 사용할 수 있는 사용자 수 제한(전체 상태일 때 새로운 사용자는 가입할 수 없음)
b 마스크 금지(wildcard 허용된 nick!user@host) 채널에서 호스트 마스크 금지
v + 영향을 받는 사용자 이름 채널에서 사용자 음성 상태를 제공합니다(위 +m 참조).
k 새채널키 키를 아는 사용자만 입력할 수 있도록 채널 키를 설정합니다.

많은 데몬과 네트워크는 위 목록에서 추가 모드를 추가하거나 모드의 동작을 수정했습니다.[62][63][64][65]

채널 오퍼레이터

채널 운영자는 채널을 관리하는 IRC 채널의 클라이언트입니다. IRC 채널 운영자는 이름 옆에 있는 기호나 아이콘으로 쉽게 볼 수 있습니다(일반적으로 "@" 기호 접두사, 녹색 원 또는 라틴 문자 "+o"/"o"). 대부분의 네트워크에서 운영자는 다음을 수행할 수 있습니다.

  • 사용자를 발로 차.
  • 사용자를 금지합니다.
  • 다른 사용자에게 IRC 채널 운영자 상태 또는 IRC 채널 음성 상태를 지정합니다.
  • 채널 모드 +t가 설정된 상태에서 IRC Channel 항목을 변경합니다.
  • IRC 채널 모드 잠금을 변경합니다.

IRC 연산자

주 기사: 인터넷 중계 채팅 운영자

또한 로컬 서버 또는 전체 네트워크에서 높은 권한을 유지하는 사용자도 있습니다. 이러한 사용자를 IRC operator([66]IRC operator)라고 하며, 때로는 IRCops(IRCops) 또는 Operers(채널 operator와 혼동하지 않도록)로 줄여 부르기도 합니다. IRCd의 구현이 다양해짐에 따라, 주어진 IRCd에 대한 IRC 운영자의 권한도 마찬가지입니다. RFC 1459는[66] IRC 운영자들이 네트워크의 깨끗한 상태를 유지하기 위해 "필요한 악"이며, 따라서 그들이 서버의 연결을 끊고 다시 연결할 수 있어야 한다고 주장합니다. 또한 악의적인 사용자나 심지어 유해한 자동화 프로그램이 IRC에 들어가는 것을 방지하기 위해 IRC 운영자는 일반적으로 클라이언트의 연결을 끊고 IP 주소를 완전히 금지하거나 서브넷을 완료할 수 있습니다. 서비스를 제공하는 네트워크(NickService et al.)는 일반적으로 IRC 운영자가 기본적인 "소유권" 문제를 처리할 수 있도록 허용합니다. 추가 권한에는 채널 금지(Opper되지 않은 경우 참여할 수 없는 채널에 참여할 수 없음)를 우선하는 것, Opper되지 않으면 참여할 수 없는 채널에서 스스로를 열 수 있음, 채널에서 항상 자동으로 오핑되는 것 등이 포함될 수 있습니다.

호스트 마스크

호스트 마스크는 IRC 서버에 연결된 IRC 클라이언트의 고유 식별자입니다.[67][68] IRC 서버, 서비스 및 봇을 포함한 기타 클라이언트는 이를 사용하여 특정 IRC 세션을 식별할 수 있습니다.

호스트 마스크의 형식은 다음과 같습니다. nick!user@host. 호스트 마스크는 전자 메일 주소와 유사하지만 혼동해서는 안 됩니다.

닉 부분은 사용자가 선택한 닉네임으로 연결된 상태에서 변경될 수 있습니다. 사용자 부분은 클라이언트에서 id가 보고한 사용자 이름입니다.[69] 클라이언트에서 ID를 사용할 수 없는 경우 연결된 클라이언트에서 지정된 사용자 이름은 타일로 접두사를 붙인 후 사용됩니다.[70]

호스트 부분은 클라이언트가 연결하는 호스트 이름입니다. 클라이언트의 IP 주소를 서버에서 유효한 호스트 이름으로 확인할 수 없는 경우 호스트 이름 대신 사용됩니다.

클라이언트의 IP 주소 또는 호스트 이름을 노출하는 개인 정보 보호 관련성 때문에, 일부 IRC 데몬은 Insp와 같은 개인 정보 보호 기능도 제공합니다.IRCd 또는 UnrealIRCd's "+x" mode. 클라이언트 IP 주소를 해시하거나 클라이언트 호스트 이름의 일부를 마스킹하므로 IRCops 이외의 사용자는 읽을 수 없습니다. 사용자는 추가 익명성을 허용하기 위해 호스트 마스크에 "가상 호스트"(또는 "vhost")를 표시하도록 요청할 수도 있습니다. LiberaChat 또는 Freenode와 같은 일부 IRC 네트워크는 사용자가 그룹 또는 프로젝트에 소속되어 있음을 나타내는 "클로크"로 사용합니다.[71]

URI 스킴

인터넷 릴레이 채팅에는 세 가지 임시 인식된 URI(Uniform Resource Identifier) 체계가 있습니다. irc, ircs,그리고. irc6.[72]지원되는[72] 경우 다음과 같은 다양한 형태의 하이퍼링크를 허용합니다. 

irc://<host>[:<port>]/[<channel>[?<channel_keyword>] ircs://<host>[:<port>]/[<channel>[?<channel_keyword>] irc6://<host>[:<port>]/[<channel>[?<채널_keyword>]

(괄호 안에 동봉된 항목([,])은 선택 사항)으로 지정된 호스트(또는 네트워크, IRC 클라이언트에 알려진 경우)에 연결하고 지정된 채널에 가입하는 데 사용됩니다.[73] (이것은 클라이언트 자체 내에서 또는 웹 브라우저와 같은 다른 응용 프로그램에서 사용할 수 있습니다.) irc는 기본 URI이고, irc6는 IPv6를 사용하여 연결할 것을 지정하며, ircs는 보안 연결을 지정합니다.

사양에 따라 일반 해시 기호(#)는 영숫자로 시작하는 채널 이름 앞에 붙여져 생략할 수 있습니다. 일부 구현(예: mIRC)은 URL에 포함된 경우 무조건 추가(예: ##채널)를 발생시킵니다.

일부 구현에서는 쉼표로 구분하여 여러 채널을 지정할 수 있습니다.[74]

과제들

IRC의 원래 설계에서 문제는 확장성에 대한 제한으로 공유된 상태 데이터의[75][76] 양,[77] 별명 충돌 문제로 이어지는 고유한 사용자 ID의 부재,[78] 순환 라우팅을 통한 네트 스플릿으로부터의 보호 부족,[79][80] 실시간 사용자 존재 정보를 위한 확장성의 상충,[81] 프로토콜의 취약성은 남용의 플랫폼을 제공하고,[82] 투명하고 최적화 가능한 메시지 전달이 [83]없으며, 암호화가 되지 않습니다.[84] 이러한 문제 중 일부는 모던 IRC에서 다루었습니다.

어택스

IRC 연결은 암호화되지 않고 일반적으로 장기간에 걸쳐 있기 때문에 DoS/DDoS 공격자와 해커에게 매력적인 대상이 됩니다. 이 때문에 IRC 네트워크가 인수전과 같은 공격을 받지 않도록 세심한 보안 정책이 필요합니다. IRC 네트워크는 또한 K-라인 또는 G-라인 사용자 또는 서버에 해를 끼칠 수 있습니다.

일부 IRC 서버는 보안 목적으로 SSL/TLS 연결을 지원합니다. 이는 IRC 사용자의 비밀번호를 얻기 위한 패킷 스나이퍼 프로그램의 사용을 중지하는 데 도움이 되지만, IRC 채널의 공공성 때문에 이 범위를 넘어서는 사용은 거의 없습니다. SSL 연결에는 클라이언트 및 서버 지원이 모두 필요합니다(사용자가 자신의 컴퓨터에 SSL 바이너리 및 IRC 클라이언트 특정 패치 또는 모듈을 설치해야 할 수 있음). 일부 네트워크는 서버 간 연결을 위해 SSL을 사용하며, 다음과 같은 특수 채널 플래그를 제공합니다. +S)는 SSL이 제공하는 이점을 더 잘 활용하기 위해 채널에서 SSL 연결 사용자만 허용하고, 명확한 텍스트로 운영자 식별을 허용하지 않습니다.[85][86]

IRC는 가짜 ICMP 도달 불능 메시지를 사용하여 TCP 기반 IRC 연결을 끊거나 인수를 용이하게 하는 등 여러 종류의 인터넷 공격을 위한 초기 실험실 역할을 했습니다.

남용방지

현재까지도 남아있는 IRC 구현을 둘러싼 가장 논쟁적인 기술적 문제 중 하나는 "닉/채널 지연" 대 "타임스탬프" 프로토콜의 장점입니다. 두 가지 방법 모두 서비스 거부 공격의 문제를 해결하기 위해 존재하지만 매우 다른 접근 방식을 취합니다. 구현된 원래 IRC 프로토콜의 문제점은 두 서버가 분할하여 다시 결합할 때 네트워크의 양측이 단순히 채널을 병합하는 것이었습니다. 사용자가 망의 반대편에 존재하던 채널이 비어 있는 '분할' 서버에 가입하여 운영자 지위를 얻을 수 있다면 망분할이 종료된 후 '결합' 채널의 채널 운영자가 되는 것이고, 망의 반대편에 존재하던 닉네임을 사용자가 사용하였다면, 서버가 다시 가입할 때 두 사용자를 모두 죽일 것입니다("닉 충돌"). 이는 종종 채널의 모든 사용자를 "대량 살상"하기 위해 악용되어 남용을 처리할 운영자가 존재하지 않는 "무작위" 채널을 만들었습니다. 이는 IRC 내에서 문제를 일으키는 것 외에도 사람들이 IRC 서버에 대해 서비스 거부 공격을 수행하여 넷 스플릿을 발생시키고 이를 악용하도록 장려했습니다.

닉 딜레이(ND) 및 채널 딜레이(CD) 전략은 재연결 및 이름 변경을 지연시켜 남용을 방지하는 것을 목표로 합니다. 사용자가 서명을 종료하고 닉네임을 사용할 수 있게 되거나 모든 사용자가 분할되어 채널이 존재하지 않는 경우(망 분할 중에 자주 발생하는 경우), 서버는 특정 기간(지연)이 경과할 때까지 해당 닉네임을 사용하거나 해당 채널에 가입할 수 없습니다. 망 분열이 일어나도 애칭을 가져가거나 채널의 운영자 지위를 얻을 수 없어 애칭 충돌이나 채널의 '병합'이 일어나지 않기 때문에 악용자에게는 무용지물이라는 생각이 깔려 있습니다. 이로 인해 합법적인 사용자는 다시 가입한 후 다른 이름을 잠시 사용해야 할 수도 있습니다(밑줄 표시가 인기 있음).

타임스탬프 프로토콜은 타임스탬프된 우선순위를 사용하여 충돌을 해결하는 닉/채널 지연의 대안입니다. 네트워크의 모든 닉네임과 채널에는 타임스탬프(타임스탬프가 생성된 날짜와 시간)가 할당됩니다. 네트 스플릿이 발생하면 각 면에 있는 두 명의 유저가 자유롭게 같은 닉네임이나 채널을 사용할 수 있지만, 양 면이 합쳐지면 한 명만 살아남을 수 있습니다. 닉네임의 경우, TS에 따라 새로운 사용자가 사망합니다. 채널이 충돌하면 멤버(채널의 사용자)가 병합되지만 분할의 "잃어버린" 쪽에 있는 채널 운영자는 채널 운영자 지위를 잃게 됩니다.

TS는 설계와 구현 모두에서 ND/CD보다 훨씬 더 복잡한 프로토콜이며, 몇 번의 수정을 거쳤음에도 불구하고 일부 구현에서는 여전히 "디싱크"(동일한 네트워크의 두 서버가 네트워크의 현재 상태에 대해 의견이 일치하지 않는 경우)에 문제가 있습니다. losing 측이 허용한 것에 대해 너무 많은 선처를 허용한 것입니다. 예를 들어, 원래 TS 프로토콜에서는 사용자가 채널 운영자 지위를 잃었음에도 불구하고, 분할이 다시 결합될 때 병합될 손실 채널에서 금지 또는 다른 모드를 설정하는 것에 대한 보호가 없었습니다. 일부 최신 TS 기반 IRC 서버는 남용을 더욱 억제하기 위해 타임스탬프 외에 ND 및/또는 CD 형태를 통합하기도 했습니다.

오늘날 대부분의 네트워크는 타임스탬프 방법을 사용합니다. 타임스탬프 대 ND/CD 불일치로 인해 여러 서버가 EFnet에서 분리되어 새로운 IRCnet을 형성하게 되었습니다. 분할 후, EFnet은 TS 프로토콜로 이동했고, IRCnet은 ND/CD를 사용했습니다.

최근 버전의 IRCnet ircd뿐만 아니라 TS6 프로토콜(Charybdis 포함)을 사용하는 ircd에서도 ND는 SAVE라는 메커니즘으로 확장/대체되었습니다. 이 메커니즘은 IRC 서버에 연결할 때 모든 클라이언트에 UID를 할당합니다. 이 ID는 숫자로 시작하는데, 숫자는 닉(IRCnet 및 Insp 등 일부 ircs)에서는 금지됩니다.IRCd, 고객이 닉네임으로 자신의 UID로 전환할 수 있도록 허용).

동일한 닉네임을 가진 두 클라이언트가 netsplit의 서로 다른 면에서 가입하는 경우("닉 충돌"), 이 충돌을 가장 먼저 확인하는 서버는 두 클라이언트 모두의 닉을 UID로 변경하도록 강제하여 두 클라이언트의 연결이 끊기지 않도록 합니다. IRCnet에서는 두 클라이언트가 원래 닉네임으로 다시 변경되지 않도록 해당 닉네임이 일정 시간(ND) 동안 잠기게 되어 다시 충돌합니다.

클라이언트

클라이언트 소프트웨어

자세한 정보: 인터넷 릴레이 채팅 클라이언트 비교
일반 클라이언트(녹색), 봇(파란색) 및 바운더리(주황색)가 있는 IRC 네트워크 방식

클라이언트 소프트웨어는 웹 기반 또는 내부 게임뿐만 아니라 다양한 운영 체제 또는 소프트웨어 패키지를 위해 존재합니다. Windows, Unix 및 Linux, macOS 및 모바일 운영 체제(iOS 및 Android 등)를 포함한 다양한 운영 체제에서 다양한 클라이언트를 사용할 수 있습니다. Windows에서 mIRC는 가장 인기 있는 클라이언트 중 하나입니다.[87] 일부 리눅스 배포판에는 IRC 클라이언트가 미리 설치되어 있으며, 예를 들어 HexChat이 미리 설치되어 있습니다.

플러그인을 통해 확장 가능한 일부 프로그램은 IRC 클라이언트를 위한 플랫폼 역할도 합니다. 예를 들어, 전적으로 Emacs Lisp로 작성된 ERC라는 클라이언트는 Emacs의 v.22.3에 포함되어 있습니다. 따라서 Emacs를 실행할 수 있는 모든 플랫폼은 ERC를 실행할 수 있습니다.

다음과 같은 여러 웹 브라우저에 IRC 클라이언트가 내장되어 있습니다.

Mibbit 및 오픈 소스 KiwiIRC와 같은 웹 기반 클라이언트는 대부분의 브라우저에서 실행될 수 있습니다.

War §ow, Unreal Tournament (2004년 언리얼 토너먼트까지), Uplink, Spring Engine 기반 게임, 0 A.D. 및 ZDaemon과 같은 게임에는 IRC가 포함되어 있습니다.

Ustream의 채팅 인터페이스는 Twitch(이전의 Justin.tv )뿐만 아니라 사용자 인증 기능을 갖춘 IRC입니다.

봇들

메인 기사: IRC bot

IRC에서 봇의 일반적인 용도는 채팅 기반 게임을 호스팅하거나 외부 이벤트의 알림을 제공하는 것과 같은 채널 내에서 IRC 서비스 또는 특정 기능을 제공하는 것입니다. 그러나 일부 IRC 봇은 서비스 거부, 스팸 또는 공격과 같은 악의적인 공격을 시작하는 데 사용됩니다.[96]

바커

주 기사 : BNC (소프트웨어)

서버에서 데몬으로 실행되고 영구 프록시로 기능하는 프로그램을 BNC 또는 바운서라고 합니다. 목적은 IRC 서버에 대한 연결을 유지하거나, 서버와 클라이언트 사이의 릴레이 역할을 하거나, 단순히 프록시 역할을 하는 것입니다.[citation needed] 클라이언트가 네트워크 연결을 끊으면 BNC는 연결 상태를 유지하고 나중에 전송하기 위해 모든 트래픽을 보관할 수 있으므로 사용자가 서버에 대한 연결을 중단하지 않고 IRC 세션을 재개할 수 있습니다.[97]

또한, 바운스와 같은 효과를 얻기 위한 방법으로, IRC 클라이언트(일반적으로 텍스트 기반, 예를 들어 Irsi)는 사용자가 ssh를 통해 접속하는 Always-on 서버에서 실행될 수 있습니다. 또한 ssh 기능만 있지만 실제 IRC 클라이언트가 직접 설치되지 않은 장치는 IRC에 연결할 수 있으며 IRC 세션을 공유할 수 있습니다.[98]

ssh 연결이 닫힐 때 IRC 클라이언트가 종료되는 것을 방지하기 위해 클라이언트를 GNU Screen 또는 tmux와 같은 터미널 멀티플렉서 내부에서 실행할 수 있으므로 IRC 네트워크에 지속적으로 연결되어 사용자가 관심 있는 채널에 대화를 기록하거나 네트워크에서 채널의 존재를 유지할 수 있습니다. 이러한 설정을 모델로 하여 2004년에 클라이언트-서버를 따르는 Smuxi라는 IRC 클라이언트가 출시되었습니다.[99][100]

검색 엔진

사용자가 IRC에서 찾고 있는 것을 찾는 데 도움이 되는 수많은 검색 엔진이 있습니다.[101][102] 일반적으로 검색 엔진은 "백엔드"(또는 "스파이더/크롤러")와 프론트엔드 "검색 엔진"의 두 부분으로 구성됩니다.

백엔드(거미/웹크롤러)는 검색 엔진의 작업 말입니다. IRC 서버를 크롤링하여 IRC 서버 간에 전송되는 정보를 색인화하는 역할을 합니다. 인덱싱된 정보는 일반적으로 채널 텍스트(공용 채널에 공개적으로 표시되는 텍스트)로만 구성됩니다. 저장 방법은 일반적으로 MySQL 또는 Oracle과 같은 일종의 관계형 데이터베이스입니다.[citation needed]

프론트 엔드 "검색 엔진"은 데이터베이스에 대한 사용자 인터페이스입니다. 색인화된 정보의 데이터베이스를 검색하여 찾고 있는 데이터를 검색할 수 있는 방법을 사용자에게 제공합니다. 이러한 프론트 엔드 검색 엔진은 다양한 프로그래밍 언어로 코딩할 수도 있습니다.

대부분의 검색 엔진은 IRC를 크롤링하고 데이터 자체를 인덱싱하는 단일 응용 프로그램인 자체 스파이더를 가지고 있지만 다른 것들은 "사용자 기반" 인덱싱입니다. 후자는 IRC 클라이언트에 "추가 기능"을 설치하기 위해 사용자에게 의존합니다. 추가 기능은 사용자가 우연히 접속한 채널의 채널 정보를 데이터베이스에 전송하는 것입니다.[citation needed]

많은 사용자들은 많은 IRC 클라이언트에 내장된 로깅 기능을 사용하여 자신만의 임시 검색 엔진을 구현했습니다. 이러한 검색 엔진은 일반적으로 봇으로 구현되며 특정 채널 또는 관련 채널 그룹에 전용됩니다.

문자 인코딩

IRC는 여전히 7비트 ASCII 레퍼토리 밖에서 문자를 전송하는 방법에 대해 세계적으로 인정되는 단일 표준 규칙이 없습니다. IRC 서버는 일반적으로[clarification needed] 문자의 해석이나 기록 없이 바이트 시퀀스와 같이 클라이언트에서 다른 클라이언트로 메시지를 전송합니다. IRC 프로토콜(예: IRC 프로토콜과 달리). MIME 또는 HTTP)에는 문자 인코딩 옵션을 알리고 협상하기 위한 메커니즘이 없습니다. 이로 인해 클라이언트에서 적절한 문자 코덱을 선택해야 합니다. 실제로 IRC 채널은 각 언어 커뮤니티의 운영 체제(특히 유닉스 파생형)에서도 사용되었던 동일한 문자 인코딩을 주로 사용했습니다.

  • 7비트 시대: IRC 초기에는 특히 스칸디나비아어와 핀란드어 사용자들 사이에서 ISO 646의 국가적 변형이 지배적인 문자 인코딩이었습니다. 이것들은 비 ASC를 인코딩합니다.II characters like Ä Ö Å ä ö å at code positions 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[citation needed] 및 CP1251을 선택할 수 있었고, 약 2000년부터 현대 러시아 IRC 네트워크는 일반적으로 사용되는 키릴 문자의 이들 상이한 인코딩 사이에서 변환됩니다.
  • Multi-byte era : 오래전부터 중국, 일본, 한국 등에서 logographic script를 가진 동아시아 IRC 채널에서는 EUC나 ISO-2022-JP와 같은 Multi-byte 인코딩을 사용하고 있습니다. 약 2002년부터 리눅스와 유닉스 플랫폼에서 ISO 8859에서 UTF-8로 일반적으로 마이그레이션되면서 UTF-8은 유럽 채널에서 이전에 사용되었던 많은 8비트 인코딩의 대체물이 되었습니다. 일부 IRC 클라이언트는 ISO 8859-1 또는 UTF-8에 있는 메시지를 동일한 채널에서 읽을 수 있으며, 어떤 인코딩이 사용되는지 자동으로 감지할 수 있습니다. UTF-8로의 전환은 특히 핀란드어를 사용하는 IRC(Merkistö(핀란드어)에서 시작되었습니다.

오늘날 유니코드/ISO 10646의 UTF-8 인코딩은 모든 IRC 통신을 위한 단일 표준 문자 인코딩의 가장 유력한 경쟁자가 될 것입니다. 만약 그러한 표준이 510바이트 메시지 크기 제한을 완화한다면 말입니다. UTF-8은 ASCII와 호환되며 일반적으로 사용되는 모든 다른 코드 문자 집합 표준의 상위 집합을 다룹니다.

파일공유

기존의 P2P 파일 공유와 마찬가지로 사용자는 맞춤형 IRC 봇 또는 IRC 클라이언트용 스크립트를 사용하여 서로 파일을 공유할 수 있는 파일 서버를 만들 수 있습니다. 종종 사용자들은 IRC 봇 네트워크를 통해 웨어즈를 배포하기 위해 함께 그룹을 형성합니다.[103]

기술적으로 IRC는 파일 전송 메커니즘 자체를 제공하지 않습니다. 파일 공유는 일반적으로 클라이언트 간의 개인 메시지 교환을 통해 파일 전송이 협상되는 DCC(Direct Client-to-Client) 프로토콜을 사용하여 IRC 클라이언트에 의해 구현됩니다. 대부분의 IRC 클라이언트는 DCC 파일 전송을 지원하므로 파일 공유가 IRC의 필수 기능이라고 생각합니다.[104] 그러나 이 프로토콜의 일반적인 사용은 때때로 DCC 스팸을 유발하기도 합니다. DCC 명령은 취약한 클라이언트를 이용하여 서버와의 연결을 끊거나 클라이언트를 종료하는 등의 작업을 수행하는 데에도 사용되었습니다.

참고 항목

인용

  1. ^ "One-to-many". Internet Relay Chat Protocol. p. 11. sec. 3.2. doi:10.17487/RFC1459. RFC 1459.
  2. ^ "One-To-One Communication". Internet Relay Chat: Architecture. p. 5. sec. 5.1. doi:10.17487/RFC2810. RFC 2810.
  3. ^ Rollo, Troy. "A Description of the DCC Protocol". IRCHelp.org. Retrieved 8 April 2011.
  4. ^ Wang, Wallace (25 October 2004). "Instant Messaging and Online Chat Rooms: Internet Relay Chat (IRC)". Steal this File Sharing Book (1st ed.). San Francisco, California: No Starch Press. pp. 61–67. ISBN 978-1-59327-050-6.
  5. ^ a b c "IRC is dead, long live IRC". Pingdom. 24 April 2012. Archived from the original on 15 August 2017. Retrieved 25 April 2016.
  6. ^ "IRC Networks – Top 100". irc.netsplit.de. Retrieved 26 October 2023.
  7. ^ a b c d e f g h i j k Stenberg, Daniel (29 March 2011). "History of IRC (Internet Relay Chat)". Retrieved 25 April 2016. I did not experience all of this. I found information on various places and I received information from various people in order to write this. People that have helped me with this include: Greg "wumpus" Lindahl, Vesa "vesa" Ruokonen, James Ng, Tuomas Heino, Richard (eagle`s on undernet), Ari Lemmke
  8. ^ Oikarinen, Jarkko. "Founding IRC". Retrieved 8 April 2011.
  9. ^ a b "History of IRC (Internet Relay Chat)". daniel.haxx.se. Retrieved 22 July 2023.
  10. ^ "IRC transcripts from the time of the 1991 Soviet coup d'état attempt". Chapel Hill, North Carolina: ibiblio. Archived from the original on 28 June 2009. Retrieved 8 April 2011.
  11. ^ "IRC logs of events of the Gulf War". Chapel Hill, North Carolina: ibiblio. Retrieved 8 April 2011.
  12. ^ "Logs of major events in the online community". Chapel Hill, North Carolina: ibiblio. Retrieved 8 April 2011.
  13. ^ a b c "Introduction". Internet Relay Chat Protocol. p. 4. sec. 1. doi:10.17487/RFC1459. RFC 1459.
  14. ^ a b c "Character codes". Internet Relay Chat Protocol. p. 7. sec. 2.2. doi:10.17487/RFC1459. RFC 1459.
  15. ^ Engen, Vegard (May 2000). "The Great Split". IRC.org. Retrieved 25 April 2016.
  16. ^ "Channel Modes". UnrealIRCd documentation wiki. Retrieved 6 January 2018.
  17. ^ "Cloaking". UnrealIRCd documentation wiki. Retrieved 6 January 2018.
  18. ^ "Blitzed Open Proxy Monitor Shuts Down". The Open Proxy Monitor which has been provided by the Blitzed IRC network has been shut down…The database was so large that it is near to impossible for the team to backup, or find a new location to continue the service. Added to that, most of the team members do not possess the time anymore to keep the service running.
  19. ^ "IRCv3". IRCv3 Working Group. 2016. Retrieved 25 April 2016. The IRCv3 Working Group is a collection of IRC client and server software authors working to enhance, maintain and standardize the IRC protocol using backwards-compatible extensions.
  20. ^ "Networks - IRCv3". 2019. Retrieved 9 August 2019.
  21. ^ "IRC Networks - in alphabetical order". netsplit.de. Retrieved 12 January 2022.
  22. ^ "IRC Networks - Top 100". netsplit.de. Retrieved 12 January 2022.
  23. ^ "netsplit.de top 10". Retrieved 15 January 2021.
  24. ^ a b Charalabidis, Alex (15 December 1999). "IRCing On The Macintosh: Ircle". The Book of IRC: The Ultimate Guide to Internet Relay Chat (1st ed.). San Francisco, California: No Starch Press. p. 61. ISBN 978-1-886411-29-6. On large networks such as the Big Four— EFnet, IRCnet, Undernet, and DALnet— trying to list the thousands of channels with Ircle always causes you to disconnect due to the flood of information, while other clients can usually manage the feat, if you are on a direct Ethernet connection.
  25. ^ a b Jones, Steve, ed. (10 December 2002). "Internet Relay Chat". Encyclopedia of New Media: An Essential Reference to Communication and Technology (1st ed.). Thousand Oaks, California: SAGE Publications. p. 257. ISBN 978-0-7619-2382-4. Today there are hundreds of independent IRC networks, but the "Big Four" are EFNet, UnderNet, Dalnet, and IRCnet.
  26. ^ a b Rittner, Don (3 March 1999). The iMac Book (1st ed.). Scottsdale, Arizona: Coriolis Group. p. 215. ISBN 978-1-57610-429-3. There are several large networks: EFnet, UnderNET, DALnet, and IRCnet make up the Big Four.
  27. ^ Turban, Efraim; Leidner, Dorothy; McLean, Ephraim; Wetherbe, James (7 February 2005). "Communication". Information Technology for Management: Transforming Organizations in the Digital Economy (5th ed.). Hoboken, New Jersey: John Wiley & Sons. pp. 106–107. ISBN 978-0-471-70522-2. The largest networks have traditionally been grouped as the "Big Four": EFNet, IrcNet, QuakeNet, and UnderNet.
  28. ^ "IRC Networks – Top 100". irc.netsplit.de. netsplit.de. Retrieved 15 January 2021.
  29. ^ "Servers". Internet Relay Chat Protocol. p. 4. sec. 1.1. doi:10.17487/RFC1459. RFC 1459.
  30. ^ "Clients". Internet Relay Chat: Architecture. p. 3. sec. 2.2. doi:10.17487/RFC2810. RFC 2810.
  31. ^ "Clients". Internet Relay Chat Protocol. p. 5. sec. 1.2. doi:10.17487/RFC1459. RFC 1459.
  32. ^ "Port Numbers". Marina del Rey, California: Internet Assigned Numbers Authority. 6 April 2011. Retrieved 5 April 2021.
  33. ^ "Connect message". Internet Relay Chat Protocol. p. 29. sec. 4.3.5. doi:10.17487/RFC1459. RFC 1459.
  34. ^ Lucas, Mark; Singh, Abhishek; Cantrell, Chris (5 October 2006). "Defining a Firewall". In Henmi, Anne (ed.). Firewall Policies and VPN Configurations. Rockland, Massachusetts: Syngress Publishing. p. 93. ISBN 978-1-59749-088-7.
  35. ^ Abraham, Dalen (June 1998). Extensions to the Internet Relay Chat Protocol (IRCX). IETF. I-D draft-pfenning-irc-extensions-04. Retrieved 8 April 2011.
  36. ^ "Architecture". Internet Relay Chat: Architecture. pp. 3 – 4. sec. 3. doi:10.17487/RFC2810. RFC 2810.
  37. ^ "Introduction". Internet Relay Chat: Architecture. p. 2. sec. 1. doi:10.17487/RFC2810. RFC 2810.
  38. ^ "Algorithms". Internet Relay Chat Protocol. p. 64. sec. 9.3. doi:10.17487/RFC1459. RFC 1459.
  39. ^ "Network Congestion". Internet Relay Chat: Architecture. pp. 7 – 8. sec. 6.3. doi:10.17487/RFC2810. RFC 2810.
  40. ^ "To A Channel". Internet Relay Chat: Architecture. pp. 5 – 6. sec. 5.2.1. doi:10.17487/RFC2810. RFC 2810.
  41. ^ "IRC daemons for LAN". Retrieved 2 October 2014.
  42. ^ "Running an own IRC server". Retrieved 2 October 2014.
  43. ^ "Message format in 'pseudo' BNF". Internet Relay Chat Protocol. p. 8. sec. 2.3.1. doi:10.17487/RFC1459. RFC 1459.
  44. ^ "Numeric replies". Internet Relay Chat Protocol. p. 10. sec. 2.4. doi:10.17487/RFC1459. RFC 1459.
  45. ^ IRC 대화방
  46. ^ "IRC List Modes – List mode extension showing pair confusion for lists". 25 November 2009. Retrieved 8 April 2011.
  47. ^ a b "To a group (channel)". Internet Relay Chat Protocol. p. 11. sec. 3.2.2. doi:10.17487/RFC1459. RFC 1459.
  48. ^ "List message". Internet Relay Chat Protocol. p. 24. sec. 4.2.6. doi:10.17487/RFC1459. RFC 1459.
  49. ^ a b "Join message". Internet Relay Chat Protocol. p. 19. sec. 4.2.1. doi:10.17487/RFC1459. RFC 1459.
  50. ^ "Channel Scope". Internet Relay Chat: Channel Management. pp. 3 – 4. sec. 2.2. doi:10.17487/RFC2811. RFC 2811.
  51. ^ "Channel Properties". Internet Relay Chat: Channel Management. p. 4. sec. 2.3. doi:10.17487/RFC2811. RFC 2811.
  52. ^ "Channel lifetime". Internet Relay Chat: Channel Management. p. 5. sec. 3. doi:10.17487/RFC2811. RFC 2811.
  53. ^ "Channel Modes". Internet Relay Chat: Channel Management. p. 7. sec. 4. doi:10.17487/RFC2811. RFC 2811.
  54. ^ "Mode message". Internet Relay Chat Protocol. p. 21. sec. 4.2.3. doi:10.17487/RFC1459. RFC 1459.
  55. ^ "Channel modes". Internet Relay Chat Protocol. pp. 21 – 22. sec. 4.2.3.1. doi:10.17487/RFC1459. RFC 1459.
  56. ^ "Channel Access Control". Internet Relay Chat: Channel Management. pp. 10 – 11. sec. 4.3. doi:10.17487/RFC2811. RFC 2811.
  57. ^ a b "Command responses: 353 RPL_NAMREPLY". Internet Relay Chat Protocol. p. 51. doi:10.17487/RFC1459. RFC 1459.
  58. ^ Roeckx, Kurt (14 October 2004). "The 005 numeric: ISUPPORT". irc.org. Retrieved 10 April 2011.
  59. ^ Brocklesby, Edward (September 2002). IRC RPL_ISUPPORT Numeric Definition. IETF. I-D draft-brocklesby-irc-isupport-03. Retrieved 10 April 2011.
  60. ^ "'multi-prefix' Extension - IRCv3".
  61. ^ "Operwall message". Internet Relay Chat Protocol. p. 41. sec. 5.6. doi:10.17487/RFC1459. RFC 1459.
  62. ^ Butcher, Simon (12 January 2005). "IRC User Modes List". alien.net.au. Retrieved 10 April 2011.
  63. ^ Butcher, Simon (12 January 2005). "IRC Channel Modes List". alien.net.au. Retrieved 10 April 2011.
  64. ^ Butcher, Simon (12 January 2005). "IRC Server Modes List". alien.net.au. Retrieved 10 April 2011.
  65. ^ Olsen, Tommy. "IRCd Modes". webtoman.com. Archived from the original on 15 October 2011. Retrieved 10 April 2011.
  66. ^ a b "Operators". Internet Relay Chat Protocol. p. 5. sec. 1.2.1. doi:10.17487/RFC1459. RFC 1459.
  67. ^ Thiedeke, Udo (23 September 2003). "Nicola Döring, Alexander Schestag". Virtuelle Gruppen: Charakteristika und Problemdimensionen (in German) (2nd ed.). Springer VS [de]. pp. 314, 337. ISBN 978-3-531-33372-4. Retrieved 30 March 2010.
  68. ^ Rogers, Russ (1 December 2004). "The Mind of Terror". In Devost, Matthew G. (ed.). Hacking a Terror Network: The Silent Threat of Covert Channels (1st ed.). Rockland, Massachusetts: Syngress Publishing. p. 10. ISBN 978-1-928994-98-5. Retrieved 30 March 2010.
  69. ^ Petersen, Julie K., ed. (29 May 2002). "Internet Relay Chat". The Telecommunications Illustrated Dictionary (2nd ed.). CRC Press. p. 500. ISBN 978-0-8493-1173-4. Retrieved 30 March 2010.
  70. ^ "Frequently-Asked Questions". freenode. Archived from the original on 26 March 2010. Retrieved 30 March 2010.
  71. ^ "IRC/Cloaks". Meta-wiki. Retrieved 27 November 2011.
  72. ^ "Uniform Resource Identifier (URI) Schemes". Internet Assigned Numbers Authority. Retrieved 14 October 2012.
  73. ^ Butcher, Simon (January 2003). Uniform Resource Locator Schemes for Internet Relay Chat Entities. IETF. I-D draft-butcher-irc-url-04. Retrieved 10 April 2011.
  74. ^ "node-irc". npm. 26 January 2020. Retrieved 30 July 2021.
  75. ^ "Size". A Discussion on Computer Network Conferencing. pp. 5 – 6. sec. 2.5.1. doi:10.17487/RFC1324. RFC 1324.
  76. ^ "Scalability". Internet Relay Chat: Architecture. p. 7. sec. 6.1. doi:10.17487/RFC2810. RFC 2810.
  77. ^ Loesch 2003 1.2.1 성장
  78. ^ "User identification". A Discussion on Computer Network Conferencing. p. 10. sec. 5.4.1. doi:10.17487/RFC1324. RFC 1324.
  79. ^ "Trees and cycles". A Discussion on Computer Network Conferencing. p. 10. sec. 5.4.2. doi:10.17487/RFC1324. RFC 1324.
  80. ^ Loesch 2003 1.2.2 네트워크 장애
  81. ^ "State Information problems". A Discussion on Computer Network Conferencing. p. 4. sec. 2.1. doi:10.17487/RFC1324. RFC 1324.
  82. ^ Loesch 2003 1.2.3 사회학 및 보안 측면
  83. ^ "Message passing". A Discussion on Computer Network Conferencing. p. 7. sec. 5.2.1. doi:10.17487/RFC1324. RFC 1324.
  84. ^ "Conference security". A Discussion on Computer Network Conferencing. p. 8. sec. 5.2.4. doi:10.17487/RFC1324. RFC 1324.
  85. ^ "Getting Help on EsperNet". The EsperNet IRC Network. Retrieved 31 July 2012.
  86. ^ brandon (18 May 2010). "New Feature: SSL For Users". DALnet. Retrieved 31 July 2012.
  87. ^ Smith, Roderick W. (8 April 2000). "The Internet: Using IRC to Get Help". The Multi-Boot Configuration Handbook. Handbook Series. Upper Saddle River, New Jersey: Que Publishing. p. 289. ISBN 978-0-7897-2283-6. Retrieved 25 July 2010. mIRC is one of the most popular Windows IRC clients.
  88. ^ "Opera Browser Wiki: IRC Client". Archived from the original on 17 March 2011. Retrieved 10 April 2011.
  89. ^ "Warsow Wiki: IRC Module". Archived from the original on 25 April 2011. Retrieved 10 April 2011.
  90. ^ Guenter, Daniel (21 June 2004). "UT2004 Review". BCCHardware. Retrieved 10 April 2011.
  91. ^ "The Ultimate Uplink Guide". Retrieved 10 April 2011.
  92. ^ "ZDaemon – The Doom Wiki: Other utilities". Retrieved 10 April 2011.
  93. ^ "How to setup [sic] an IRC client to connect and login [sic] to Ustream". Ustream-Helpers. 29 January 2012. Archived from the original on 21 March 2013. Retrieved 27 April 2013.
  94. ^ Mauldor (20 June 2010). "Ustream vs. Justin.tv". LiquidSilver. Retrieved 13 July 2011.
  95. ^ "Twitch IRC". Twitch Help Center. 7 April 2017. Archived from the original on 12 February 2019. Retrieved 30 October 2017.
  96. ^ Canavan, John. "The Evolution of Malicious IRC Bots" (PDF). www.symantec.com. Symantec Security Response.
  97. ^ "psyBNC Readme". psybnc.at. Retrieved 10 April 2011.
  98. ^ Carey, Chris (18 July 2009). "IRC with irssi-proxy + screen". chriscarey.com. Retrieved 10 April 2011.
  99. ^ "Detachable Frontend (Core Rewrite) / UML / Windows Port (kicking Glade)". smuxi.org. 25 December 2004. Retrieved 25 July 2010.
  100. ^ "About Smuxi". smuxi.org. Retrieved 10 April 2011.
  101. ^ Mutton, Paul (27 July 2004). "Users and Channels". IRC Hacks (1st ed.). Sebastopol, California: O'Reilly Media. pp. 44–46. ISBN 978-0-596-00687-7.
  102. ^ Wang, Wallace (25 October 2004). "Instant Messaging and Online Chat Rooms: Internet Relay Chat (IRC)". Steal this File Sharing Book (1st ed.). San Francisco, California: No Starch Press. pp. 65–67. ISBN 978-1-59327-050-6.
  103. ^ Vamosi, Robert (8 May 2002). "Pirated movies: Now playing on a server near you". ZDNet. Retrieved 10 April 2011.
  104. ^ Sasaki, Darla (4 April 2002). "IRC 101: What Is It & How Do I Use It?". Macobserver.com. Retrieved 10 April 2011.

일반 서지학

더보기

외부 링크

Wikibook Internet Technologies에는 IRC라는 주제의 페이지가 있습니다.
위키미디어 커먼즈에는 IRC와 관련된 미디어가 있습니다.
  • 컬리의 IRC
  • IRC 수치 목록
  • IRC의 역사
  • IRC.org – 기술 및 역사 IRC6 정보; IRC 역사에 관한 기사
  • IRChelp.org – IRC(Internet Relay Chat) 도움말 아카이브; IRC 관련 문서의 대규모 아카이브
  • IRCv3 – 프로토콜에 새로운 기능을 추가하고 사양을 작성하는 개발자 작업 그룹
  • 2020년 10월 8일 Wayback Machine – IRC(Internet Relay Chat) 네트워크 및 과거 데이터가 포함된 채널 검색 엔진에서 IRC-Source 아카이브
  • irc.netsplit.de – 과거 데이터가 포함된 IRC(Internet Relay Chat) 네트워크 목록