Internet Relay Chat
Origem: Wikipédia, a enciclopédia livre.
- Nota: Se foi redirecionado para esta página e não é a que procura, consulte: IRC (desambiguação).
Internet Relay Chat (IRC) é um protocolo de comunicação bastante utilizado na Internet. Ele é utilizado basicamente como bate-papo (chat) e troca de arquivos, permitindo a conversa em grupo ou privada, sendo o predecessor dos mensageiros instantâneos actuais.
Para conseguir utilizar este protocolo, é necessário, primeiro, ter um cliente de IRC, que é um programa que se comunica com um servidor de uma rede de IRC. No sistema operativo Windows, o mais famoso é o mIRC.
Os servidores não são simples servidores, também podem ser unidos numa rede. Grandes redes podem juntar, num horário de pico, dezenas de milhares de pessoas. A especificação do protocolo é disponibilizada pelo RFC 2812.
Índice |
[editar] Informação Técnica
O IRC é um protocolo aberto que usa o TCP e opcionalmente SSL. Um servidor de IRC pode ser ligado a outros servidores de forma a expandir a rede de IRC. Para que os utilizadores tenham acesso às redes de IRC é necessário ligar a um dos servidores utilizando um cliente apropriado. Existem muitas implementações do IRC em clientes e servidores sendo que a maioria dos servidores de IRC não requerem que o utilizador se identifique, no entanto o utilizador terá de escolher um apelido antes de efectuar a ligação.
O IRC é um protocolo de texto simples, o que quer dizer que é possível (embora algo inconveniente) usar o IRC através de um cliente como o netcat ou o telnet. Embora o protocolo use uma versão ligeiramente alterada do ASCII como codificação de caracteres, não tem suporte para quaisquer caracteres não ASCII sendo que isso leva ao uso de outros tipos de codificação de caracteres incompatíveis (como o ISO 8859-1 e UTF-8).
Devido ao uso de ligações em forma de árvore entre os servidores de IRC não existe redundância e como tal uma falha num servidor ou ligação pode causar o que é chamado de netsplit.
[editar] Evolução
Todos os protocolos cliente-servidor de IRC em uso descendem do protocolo implementado na versão 2.8 do IRC2server, documentado na RFC 1459. Desde que a RFC 1459 foi publicada, as novas funcionalidades do irc 2.10 levaram à publicação de outras propostas de protocolos; RFC 2810, RFC 2811, RFC 2812 e RFC 2813, no entanto estas alterações não foram largamente adoptadas pelas outras implementações. O IRC 2.10 é largamente usado na rede IRCnet. O protocolo IRC foi estendido pela Microsoft em 1998 através do seu protocolo IRCX que resolve muitos dos problemas que as redes de IRC têm, juntamente com algumas funcionalidades que a maioria dos utilizadores sentiu “estarem à frente do tempo”. Embora muitas especificações do protocolo IRC tenham sido publicadas, não existe especificação oficial como o protocolo permanece dinâmico. Virtualmente nenhum cliente e muitos poucos servidores se restringem apenas às RFCs mencionadas como referência.
Enquanto os protocolos cliente-servidor são pelo menos similarmente funcionais, os protocolos servidor-servidor variam largamente (TS5, P10, e ND/CD são vários dos protocolos mais usados), tornando a ligação entre dois servidores com implementações diferentes muito difícil. Alguns servidores “ponte” existem para permitirem a ligação, de por exemplo, servidores 2.10 a servidores TS5, mas estes são normalmente acompanhados de restrições no que toca ao uso de partes de cada protocolo, e não estão largamente adoptados.
Nas suas primeiras versões, o IRC não tinha muitas das funcionalidades existentes hoje em dia, como canais com nomes e operadores de canais. Os canais eram numerados – canal 4 e 57, por exemplo – e o tópico do canal descrevia o tipo de conversação que tomava lugar no canal. Uma consequência deste tipo de numeração é que ao entrar no canal 0 faz com que o cliente deixe todos os canais em que está no momento: sendo “CHANNEL 0” o comando original para deixar o canal corrente.
A primeira grande alteração ao IRC ocorreu na versão 2.5 com a adição de nomes aos canais – “+canal” sendo que mais tarde viria a ser substituído por “#canal” na versão 2.7, tendo os canais numéricos sido completamente removidos e implementados os bans de canal (modo +b). O irc2.8 adicionou a forma “&canal” sendo que esta representa todos os canais que existem no servidor corrente, ao invés de serem globais a toda a rede; e “!canal” representando os canais que teoricamente estariam a salvo de sofrer as consequências da exploração indevida pelos utilizadores através dos netsplits, sendo esta a versão a partir da qual quase todas as implementações derivam.
Edições baseadas na versão 2.8 incluem:
- 2.8.1+CS, desenvolvido por Comstud
- 2.8+th, conjunto de correcções de Taner, que mais tarde viria a tornar-se
- 2.8/hybrid, originalmente desenvolvido por Jon Lusky (Rodder) e Diana Bruce (Dianora), tendo mais tarde incorporado uma extensa equipa de desenvolvimento.
- 2.9, 2.10, 2.11, ... continuam o desenvolvimento da base de código original, principalmente para o uso na rede IRCnet. Esta linha de desenvolvimento produziu 4 especificações de IRC (RFC) editadas após a RFC 1459, que documentam este protocolo de servidor exclusivamente.
2.8.21+CS e 2.8/hybrid continuam a ser usadas na rede EFnet, com o ircd-ratbox (uma versão do 2.8/hybrid) desde 2004 sendo um dos mais populares.
O servidor de IRC da rede Undernet, ircu, é um dos poucos servidores que não descendem do irc2.8, mas sim do código base do irc2.7.
Muitos dos servidores modernos de IRC foram programados do zero, como o csircd (também pela autoria de Comstud), ConferenceRoom, Microsoft Exchange Chat Service, e IRCPlus/IRCXPro.
[editar] Canais e Modos
A forma mais típica de comunicação numa sessão de IRC é a conversação num canal onde os utilizadores podem juntar-se e enviar mensagens as quais são depois reenviadas para todos os outros utilizadores do mesmo canal. Os canais que estão disponíveis através de toda a rede de IRC são precedidos de um ‘#’, enquanto os canais locais de um servidor são precedidos por ‘&’. Outros tipos de canais (não standard) incluem canais ‘+’ – ‘sem modos’, canais sem operadores, e canais ‘!’, uma forma de canal com timestamping em redes sem timestamp.
Ambos utilizadores e canais podem ter modos que são no fundo um tipo de atributos ou opções. Os modos são abreviados por letras para que seja possível agrupa-los de forma concisa. Um exemplo de um modo de utilizador é o ‘i’, que quer dizer invisível. (Não é possível saber se um dado utilizador invisível está num canal, amenos que se junte ao canal ou use o comando whois no seu apelido). Um exemplo simples de um modo de canal é ‘m’ (moderado), o qual específica que apenas utilizadores com ‘voice’ e operadores de canal podem falar no canal. Existem cinco tipos de modos de canais, quatro dos quais aceitam um argumento, tipo A que aceita um argumento para adicionar/remover valores de uma lista (tal como ‘b’); tipo B que aceita um argumento para alterar o valor entre ‘ligado’ e ‘desligado’ (tal como ‘k’); tipo C que aceita um argumento apenas quando o modo está ‘ligado’ (tal como ‘l’); tipo D que não aceita argumentos e é simplesmente uma opção booleana (tal como ‘m’, ‘n’, e ‘t’); e tipo E (normalmente chamado modo ‘class’ ou ‘prefixo’) que dá ou tira um privilégio de um utilizador num canal (tal como ‘o’).
Os modos do tipo E (classes de canais) especificam quais os utilizadores que têm privilégios num canal, e qual o nível dos privilégios que têm. Originalmente apenas os modos de operadores de canal (modo ‘o’) e ‘voice’ (modo ‘v’) existiam. Os privilégios dos operadores de canal (normalmente abreviados por chanop ou simplesmente ‘op’) permitem expulsar utilizadores (kick), colocar modos, e alterar o tópico do canal se este estiver ‘+t’. Os privilégios dos utilizadores com ‘voice’ permitem ao utilizador falar no canal se este estiver moderado (modo ‘m’). Outros modos adicionais destas classes são: ‘fundador’ (modo ‘q’) criado pela Microsoft na sua implementação IRCX (e mais tarde usado pelo UnrealIrcd); ‘half-operator’ (também referido como ‘halfop’, modo ‘h’) que é similar a um operador de canal, excepto que os utilizadores com este privilégio não podem colocar certos modos e apenas podem expulsar utilizadores normais; ‘protegido’ (modo ‘a’); ‘administrator’ (modo ‘a’ ou ‘u’); e muitos mais.
Cada classe de canal tem associado um prefixo que é mostrado ao lado do apelido de cada utilizador que estiver associado com o canal. Os prefixos mais comuns são ‘@’ para operadores de canal, ‘+’ para ‘voices’, ‘%’ para ‘half-op’, ‘.’ ou ‘~’ para os fundadores, ‘&’ para utilizadores protegidos, e ‘!’ ou ‘*’ para administrador.
A maioria das redes de IRC tem uma série de modos extra não especificados em qualquer dos documentos RFC. No entanto existe uma maneira elegante para os clientes se adaptarem, uma lista de todos os modos de utilizadores e canais é enviada para os clientes na resposta RPL_MYINFO quando o utilizador efectua o logon. Em adição, a lista de modos de canal (e o tipo de argumentos que estes aceitam), e os prefixos para as classes de modo são especificados na resposta do protocolo (RPL_PROTOCTL ou 005) enviado por parte da maioria dos servidores de IRC quando um cliente liga. Esta mensagem é usada para informar os clientes quais são as funcionalidades que o servidor aceita e quais são os limites (por exemplo, o número máximo de utilizadores que pode ter na lista de notificação, ou o tamanho máximo do apelido do utilizador). Existem também utilizadores cujos privilégios se estendem para servidores inteiros ou mesmo redes de servidores; estes são chamados de operadores de IRC (também muitas vezes referidos como IRCop). Nalgumas implementações do IRC, aos os operadores de IRC é também garantido o privilégio de operador de canal em todos os canais embora muitas pessoas acreditem que a administração dos canais e a administração da rede deva ser mantida separada e que o estatuto de operador de IRC não deve conferir o direito em interferir na operação de um canal particular.
Devido às ligações ao IRC não serem encriptadas e tipicamente estarem activas durante um longo período, são um alvo atractivo para actividades maliciosas. Devido a este facto, uma política de segurança eficaz é necessária para que uma rede de IRC não seja susceptível a ataques como os tradicionais takeovers. As redes de IRC também podem colocar k-line ou g-line a utilizadores ou redes que tendam a ter efeitos negativos para com as mesmas.
O IRC serviu como um laboratório para muitos tipos de ataques na Internet, como usar mensagens ICMP do tipo unreachable para desligar ligações TCP ao IRC (o chamado “nuke”) para chatear utilizadores ou facilitar takeovers.
[editar] Prevenção de abuso:timestamping vs. nick/channel delay
Uma das dificuldades técnicas do IRC mais contenciosa, e que ainda hoje persiste, é o mérito dos protocolos “Nick/Channel Delay” vs. “TimeStamp”. Ambos os métodos existem para resolver o problema dos ataques de negação de serviço (Denial of Service), mas têm soluções muito diferentes.
O problema com o protocolo original do IRC como implementado era que quando dois servidores se separavam e voltavam a ligar-se, os dois lados da rede simplesmente juntavam os canais. Se um utilizador entrasse num servidor separado da rede, num canal que existisse em ambos os lados da rede e estivesse vazio, ganhasse estatuto de operador de canal, este tornar-se-ia operador de canal dos canais “combinados” da junção da rede; se um utilizador utilizasse um apelido que existisse no outro lado da rede, o servidor desligaria ambos quando ocorresse a junção.
Isto era muitas vezes usado para fazer “mass-ban/kick” sobre todos os utilizadores de um canal, criando assim canais sem operadores de canal: aonde não existiam operadores disponíveis para tomar conta do abuso. Além de criar problemas dentro do IRC, isto encorajava as pessoas a efectuarem ataques de negação de serviço contra servidores de IRC para causar netsplits, os quais seriam então abusados.
[editar] Protocolo Nick/Channel Delay
A solução do protocolo de espera de nick/canal (conhecida do inglês como "Nick/Channel delay" e abreviada ND/CD) para este problema era simples. Após um utilizador ter saído da rede e o apelido tornando-se disponível, ou um canal ter deixado de existir porque todos os seus utilizadores o tinham deixado (como regularmente acontece num netsplit), o servidor não permitiria nenhum utilizador usar esse apelido ou entrar naquele canal, respectivamente, até que um certo período de tempo tivesse ocorrido (delay). A ideia por trás disto era que mesmo que um netsplit ocorresse, seria inútil para um utilizador mal intencionado porque não poderiam mudar o apelido ou ganhar privilégios de operador de canal, não havendo assim colisões de apelido caso uma junção de um canal ocorresse. Até certo ponto, isto torna-se inconveniente para utilizadores legítimos que podem ser obrigados a usar, durante um breve tempo, um nome diferente depois de voltar ao canal.
[editar] Protocolo Timestamping
A alternativa, o timestamp ou protocolo TS, tomou uma aproximação diferente. A todos os apelido e canais numa rede era atribuído um timestamp – a data e tempo da sua criação. Quando um netsplit ocorria, dois utilizadores nos dois lados da rede eram livres de usar o mesmo apelido e canal, mas quando os dois lados eram juntos, apenas um poderia sobreviver. No caso dos apelidos, o utilizador mais recente, de acordo com a sua marca de tempo, seria desligado; quando um canal colidisse, os membros do canal eram juntos, mas os operadores de canais ficavam a perder sendo-lhes retirado o estatuto de operador.
O protocolo TS é muito mais complicado que o ND/CD, tanto em desenho como em implementação, e apesar de terem sido várias as revisões, algumas implementações ainda têm problemas de dessincronização (referido como “desyncs”, aonde todos os servidores na mesma rede discordam à cerca do estado corrente da rede), permitindo muita leniedade no que era permitido pelo lado que perdia. No protocolo TS original, por exemplo, não existia protecção contra utilizadores que colocassem bans ou outros modos no canal no lado afectado pelo netsplit, que depois viriam a ser juntos quando os servidores se ligassem novamente, mesmo sabendo que os utilizadores que tivessem colocado esses modos não estivessem mais com estatuto de operador. Alguns servidores de IRC modernos que implementam o TS também incorporam alguma forma do ND e ou CD em adição ao timestamping numa tentativa de restringir os abusos.
Não existe, e muito provavelmente não existirá, um consenso entre timestamping e o protocolo ND/CD; no entanto a maioria das redes hoje em dia usam o método de timestamping. Parte das dificuldades e das discordâncias causaram com que uma série de servidores se separassem da rede EFnet e formassem a nova IRCnet (usando a Efnet o protocolo TS, e a IRCnet o ND/CD), sendo que os apoiantes de ambos os lados ficaram conhecidos pelos seus argumentos quentes relativamente aos méritos das suas soluções.
[editar] Clientes
Acredita-se que o mIRC seja o cliente de IRC mais popular em sistemas operativos baseados no Windows. Contudo, com a introdução, nos últimos anos, de clientes tais como o Bersirc, KVIrc, Trillian, Solar IRC, e X-Chat, o mIRC começou a ter mais concorrência. Veja uma lista mais completa de clientes de IRC.
[editar] Bots
Existem muitos clientes automatizados, chamados de bots (robôs). O primeiro bot foi escrito por Greg Lindahl, e foi programado com o objectivo de moderar o jogo de Wumpus.
Os bots de IRC costumam ter como objectivo e funções servir como pontos de contacto de informação permanentes, podendo enviar certos dados a um utilizador, após este executar um determinado comando pré-definido no código do bot; e agentes de protecção nos canais onde servem, pois como são mais rápidos quando comparados com humanos, podem proteger os canais de publicidade, kicks e bans excessivos, ao expulsar e banir utilizadores. Existem também usuários mal-intencionados, cujos bots são programados para fazer "flood" ou um ataque DDOS.
[editar] Redes
Actualmente existem milhares de redes de IRC no mundo. Correm em várias implementações de servidores de IRC, e são administradores por vários grupos de operadores de IRC, mas o protocolo exposto aos utilizadores de IRC é muito semelhante, e todas as redes de IRC podem ser acedidas com o mesmo cliente de IRC.
Algumas das maiores redes de IRC no mundo incluem redes como:
- AustNet
- DALnet
- EFnet
- Freenode (relacionada com informática)
- IRCnet
- OpenBrasil
- Quakenet
- RedeIdeal
- Undernet
- Brasnet
Veja uma lista mais completa, ordenadas por região, das redes de IRC.
