IRC ( Internet Relay Chat ) es un sistema de chat basado en texto para mensajería instantánea . IRC está diseñado para la comunicación grupal en foros de discusión, llamados canales , [1] pero también permite la comunicación uno a uno a través de mensajes privados [2] así como el chat y la transferencia de datos , [3] incluyendo el intercambio de archivos . [4]
Internet Relay Chat se implementa como un protocolo de capa de aplicación para facilitar la comunicación en forma de texto. El proceso de chat funciona en un modelo de red cliente-servidor . Los usuarios se conectan mediante un cliente (que puede ser una aplicación web , un programa de escritorio independiente o integrado en parte de un programa más grande) a un servidor IRC, que puede ser parte de una red IRC más grande. Algunos ejemplos de programas utilizados para conectarse incluyen Mibbit , IRCCloud , KiwiIRC y mIRC .
El uso de IRC ha estado disminuyendo de manera constante desde 2003, perdiendo el 60 por ciento de sus usuarios. [5] En abril de 2011, las 100 principales redes de IRC atendían a más de 200.000 usuarios a la vez. [6]
IRC fue creado por Jarkko Oikarinen en agosto de 1988 para reemplazar un programa llamado MUT (MultiUser Talk) en un BBS llamado OuluBox en la Universidad de Oulu en Finlandia , donde trabajaba en el Departamento de Ciencias de Procesamiento de Información. Jarkko pretendía extender el software BBS que administraba, para permitir noticias al estilo Usenet , discusiones en tiempo real y características BBS similares. La primera parte que implementó fue la parte de chat, que hizo con partes prestadas escritas por sus amigos Jyrki Kuoppala y Jukka Pihl. La primera red IRC se ejecutaba en un solo servidor llamado tolsun.oulu.fi. [7] Oikarinen encontró inspiración en un sistema de chat conocido como Bitnet Relay , que operaba en BITNET . [8]
Jyrki Kuoppala presionó a Oikarinen para que pidiera a la Universidad de Oulu que liberara el código IRC para que también pudiera funcionar fuera de Oulu y, después de que finalmente lo liberaran, Jyrki Kuoppala instaló inmediatamente otro servidor. Esta fue la primera "red IRC". Oikarinen consiguió que algunos amigos de la Universidad Tecnológica de Helsinki y la Universidad Tecnológica de Tampere [8] comenzaran a ejecutar servidores IRC cuando su número de usuarios aumentó y pronto otras universidades siguieron su ejemplo. En ese momento, Oikarinen se dio cuenta de que el resto de las características de BBS probablemente no encajarían en su programa. [7]
Oikarinen se puso en contacto con personas de la Universidad de Denver y la Universidad Estatal de Oregón . Tenían su propia red IRC en funcionamiento y querían conectarse a la red finlandesa. Habían obtenido el programa de uno de los amigos de Oikarinen, Vijay Subramaniam, la primera persona no finlandesa en utilizar IRC. Luego, IRC creció y se utilizó en toda la red nacional finlandesa ( FUNET ) y luego se conectó a Nordunet , la rama escandinava de Internet. En noviembre de 1988, IRC se había extendido por Internet y, a mediados de 1989, había unos 40 servidores en todo el mundo. [7]
En agosto de 1990, el primer desacuerdo importante tuvo lugar en el mundo de IRC. La "A-net" (Anarchy net) incluía un servidor llamado eris.berkeley.edu. Era completamente abierto, no requería contraseñas y no tenía límite en el número de conexiones. Como explica Greg "wumpus" Lindahl: [9] "tenía una línea de servidores comodín, por lo que la gente se conectaba a los servidores y se ponía en contacto con todos". La "Eris Free Network", EFnet , hizo que la máquina eris fuera la primera en ser puesta en cuarentena desde IRC. En palabras de wumpus nuevamente: [9] "Eris se negó a eliminar esa línea, así que formé EFnet. No fue una gran pelea; logré que todos los nodos se unieran, y casi todos los demás se sumaron". A-net se formó con los servidores eris, mientras que EFnet se formó con los servidores que no eran eris. La historia mostró que la mayoría de los servidores y usuarios se quedaron con EFnet. Una vez que A-net se disolvió, el nombre EFnet dejó de tener sentido y una vez más fue la única red IRC. [7]
En esa época, el IRC se utilizó para informar sobre el intento de golpe de estado soviético de 1991 durante un apagón informativo . [10] Anteriormente se había utilizado de manera similar durante la Guerra del Golfo . [11] Los registros de chat de estos y otros eventos se conservan en el archivo ibiblio . [12]
Otro esfuerzo de bifurcación, el primero que marcó una diferencia duradera, fue iniciado por "Wildthang" en los Estados Unidos en octubre de 1992. (Se derivó de la versión 2.8.10 de EFnet ircd). Se suponía que sería simplemente una red de prueba para desarrollar bots, pero rápidamente se convirtió en una red "para amigos y sus amigos". En Europa y Canadá se estaba trabajando en una nueva red separada y en diciembre los servidores franceses se conectaron a los canadienses y, a fines de mes, la red francesa y canadiense se conectó a la estadounidense, formando la red que luego se llamaría "The Undernet ". [7]
Los "undernetters" querían llevar el ircd más allá en un intento de hacer que utilizara menos ancho de banda y tratar de solucionar el caos de canales ( netsplits y takeovers ) que EFnet comenzó a sufrir. Para este último propósito, Undernet implementó marcas de tiempo, un nuevo enrutamiento y ofreció el CService, un programa que permitía a los usuarios registrar canales y luego intentaba protegerlos de los alborotadores. La primera lista de servidores presentada, del 15 de febrero de 1993, incluye servidores de los EE. UU., Canadá, Francia, Croacia y Japón. El 15 de agosto, el nuevo récord de recuento de usuarios se estableció en 57 usuarios. [7]
En mayo de 1993 se publicó el RFC 1459 [13] , que detalla un protocolo simple para la operación cliente/servidor, canales, conversaciones uno a uno y uno a muchos. [7] Una cantidad significativa de extensiones como CTCP, colores y formatos no están incluidas en las especificaciones del protocolo, ni tampoco la codificación de caracteres, [14] lo que llevó a que las distintas implementaciones de servidores y clientes divergieran. La implementación del software varió significativamente de una red a otra, y cada red implementó sus propias políticas y estándares en sus propias bases de código.
Durante el verano de 1994, Undernet se bifurcó. La nueva red se llamó DALnet (en honor a su fundador: dalvenjah), y se formó para brindar un mejor servicio al usuario y más protección a los usuarios y canales. Uno de los cambios más significativos en DALnet fue el uso de apodos más largos (el límite original de ircd era de 9 letras). Las modificaciones de ircd de DALnet fueron realizadas por Alexei "Lefler" Kosut. Por lo tanto, DALnet se basó en el servidor ircd de Undernet, aunque los pioneros de DALnet fueron desertores de EFnet. Según James Ng, la gente inicial de DALnet eran "operadores de #StarTrek hartos de las constantes divisiones/retrasos/adquisiciones/etc." [7]
DALnet rápidamente ofreció WallOps globales (mensajes IRCop que pueden ser vistos por usuarios que son +w (/mode NickName +w)), apodos más largos, apodos Q:Lined (apodos que no se pueden usar, es decir, ChanServ, IRCop, NickServ, etc.), K:Lines globales (prohibición de una persona o un dominio completo de un servidor o de toda la red), comunicaciones solo IRCop: GlobOps, modo +H que muestra que un IRCop es un "helpop", etc. Gran parte de las nuevas funciones de DALnet fueron escritas a principios de 1995 por Brian "Morpher" Smith y permiten a los usuarios tener apodos, controlar canales, enviar notas y más. [7]
En julio de 1996, después de meses de guerras de comentarios y discusiones en la lista de correo, hubo otra división debido a un desacuerdo sobre cómo debería evolucionar el desarrollo del ircd. En particular, el lado "europeo" (la mayoría de esos servidores estaban en Europa) que luego se llamó a sí mismo IRCnet defendía retrasos en los apodos y los canales, mientras que el lado de EFnet defendía las marcas de tiempo. [7] También hubo desacuerdos sobre políticas: el lado europeo había comenzado a establecer un conjunto de reglas que dirigían lo que los IRCops podían y no podían hacer, un punto de vista al que se oponía el lado estadounidense. [15]
La mayoría (no todos) de los servidores de IRCnet estaban en Europa, mientras que la mayoría de los servidores de EFnet estaban en los EE.UU. Este acontecimiento también se conoce como "La Gran División" en muchas sociedades de IRC. Desde entonces (a fecha de agosto de 1998) EFnet ha crecido y ha superado el número de usuarios que tenía entonces. En el otoño (norte) del año 2000, EFnet tenía unos 50.000 usuarios e IRCnet 70.000. [7]
El IRC ha cambiado mucho a lo largo de su existencia en Internet. El nuevo software de servidor ha añadido multitud de nuevas funciones.
A partir de 2016 [update], un nuevo esfuerzo de estandarización está en marcha bajo un grupo de trabajo llamado IRCv3, que se centra en características de cliente más avanzadas, como notificaciones instantáneas, mejor soporte de historial y seguridad mejorada. [19] A partir de 2019 [update], ninguna red IRC importante ha adoptado completamente el estándar propuesto. [20]
En junio de 2021, [update]se sabe que operan 481 redes IRC diferentes, [21] de las cuales Libera Chat , de código abierto, fundada en mayo de 2021, es la que tiene más usuarios, con 20 374 canales en 26 servidores; entre ellas, las 100 principales redes IRC comparten más de 100 mil canales que operan en alrededor de mil servidores. [22]
Después de su época dorada durante la década de 1990 y principios de la década de 2000 (240.000 usuarios en QuakeNet en 2004), IRC ha experimentado un declive significativo, perdiendo alrededor del 60% de los usuarios entre 2003 y 2012, y los usuarios se han trasladado a plataformas de redes sociales como Facebook o Twitter , [5] pero también a plataformas abiertas como XMPP, que se desarrolló en 1999. Algunas redes como Freenode no han seguido la tendencia general y han más que cuadriplicado su tamaño durante el mismo período. [5] Sin embargo, Freenode, que en 2016 tenía alrededor de 90.000 usuarios, ha disminuido desde entonces a unos 9.300 usuarios. [23]
Las redes de IRC más grandes se han agrupado tradicionalmente como las "Cuatro Grandes" [24] [25] [26] [27] , una denominación para las redes que encabezan las estadísticas. Las cuatro grandes redes cambian periódicamente, pero debido a la naturaleza comunitaria de IRC hay una gran cantidad de otras redes entre las que los usuarios pueden elegir.
Históricamente los "Cuatro Grandes" fueron: [24] [25] [26]
IRC alcanzó los 6 millones de usuarios simultáneos en 2001 y los 10 millones de usuarios en 2004-2005, descendiendo a alrededor de 350.000 en 2021. [ cita requerida ]
Las 100 principales redes IRC tienen alrededor de 230.000 usuarios conectados en las horas pico. [28]
Cronología de los principales servidores:
IRC es un protocolo abierto que utiliza TCP [13] y, opcionalmente, TLS . Un servidor IRC puede conectarse a otros servidores IRC para expandir la red IRC. [29] Los usuarios acceden a las redes IRC conectando un cliente a un servidor. [30] Hay muchas implementaciones de cliente, como mIRC , HexChat e irssi , e implementaciones de servidor, por ejemplo, el IRCd original . La mayoría de los servidores IRC no requieren que los usuarios registren una cuenta, pero se requiere un apodo antes de conectarse. [31]
IRC fue originalmente un protocolo de texto simple [13] (aunque luego se amplió), al que, a pedido, la IANA le asignó el puerto 194 / TCP . [32] Sin embargo, el estándar de facto siempre ha sido ejecutar IRC en 6667/TCP [33] y números de puerto cercanos (por ejemplo, los puertos TCP 6660–6669, 7000) [34] para evitar tener que ejecutar el software IRCd con privilegios de root .
El protocolo especificaba que los caracteres eran de 8 bits, pero no especificaba la codificación de caracteres que debía utilizar el texto. [14] Esto puede causar problemas cuando los usuarios que usan diferentes clientes o diferentes plataformas desean conversar.
Todos los protocolos de IRC cliente-servidor que se utilizan hoy en día son descendientes del protocolo implementado en la versión irc2.4.0 del servidor IRC2, y documentado en el RFC 1459. Desde que se publicó el RFC 1459, las nuevas características de la implementación de irc2.10 llevaron a la publicación de varios documentos de protocolo revisados (RFC 2810, RFC 2811, RFC 2812 y RFC 2813); sin embargo, estos cambios de protocolo no han sido ampliamente adoptados entre otras implementaciones. [ cita requerida ]
Aunque se han publicado muchas especificaciones sobre el protocolo IRC, no existe ninguna especificación oficial, ya que el protocolo sigue siendo dinámico. Prácticamente ningún cliente y muy pocos servidores dependen estrictamente de las RFC anteriores como referencia. [ cita requerida ]
Microsoft creó una extensión para IRC en 1998 a través del sistema propietario IRCX . [35] Posteriormente dejaron de distribuir software compatible con IRCX y en su lugar desarrollaron el sistema propietario MSNP .
La estructura estándar de una red de servidores IRC es un árbol . [36] Los mensajes se enrutan a lo largo de solo las ramas necesarias del árbol, pero el estado de la red se envía a cada servidor [37] y generalmente hay un alto grado de confianza implícita entre servidores. Sin embargo, esta arquitectura tiene una serie de problemas. Un servidor malintencionado o con mal comportamiento puede causar daños importantes a la red [38] y cualquier cambio en la estructura, ya sea intencional o resultado de las condiciones en la red subyacente, requiere una división de red y una unión a la red. Esto da como resultado mucho tráfico de red y mensajes falsos de salida/unión a los usuarios [39] y una pérdida temporal de comunicación con los usuarios en los servidores que se dividen. Agregar un servidor a una red grande significa una gran carga de ancho de banda de fondo en la red y una gran carga de memoria en el servidor. Sin embargo, una vez establecido, cada mensaje a múltiples destinatarios se entrega de una manera similar a la multidifusión , lo que significa que cada mensaje viaja por un enlace de red exactamente una vez. [40] Esto es una ventaja en comparación con protocolos que no son de multidifusión, como el Protocolo simple de transferencia de correo (SMTP) [ cita requerida ] o el Protocolo extensible de mensajería y presencia (XMPP) [ cita requerida ] .
Se puede utilizar un demonio IRC en una red de área local (LAN). De esta forma, se puede utilizar IRC para facilitar la comunicación entre personas dentro de la red de área local (comunicación interna). [41] [42]
El IRC tiene una estructura basada en líneas. Los clientes envían mensajes de una sola línea al servidor, [43] reciben respuestas a esos mensajes [44] y reciben copias de algunos mensajes enviados por otros clientes. En la mayoría de los clientes, los usuarios pueden introducir comandos anteponiéndoles un '/'. Según el comando, estos pueden ser gestionados completamente por el cliente o (generalmente para los comandos que el cliente no reconoce) pasarse directamente al servidor, posiblemente con alguna modificación. [45]
Debido a la naturaleza del protocolo, los sistemas automatizados no siempre pueden emparejar correctamente un comando enviado con su respuesta con total confiabilidad y están sujetos a conjeturas. [46]
El medio básico para comunicarse con un grupo de usuarios en una sesión IRC establecida es a través de un canal . [47] Los canales de una red se pueden mostrar usando el comando IRC LIST , [48] que enumera todos los canales actualmente disponibles que no tienen los modos +s o +p establecidos, en esa red en particular.
Los usuarios pueden unirse a un canal mediante el comando JOIN , [49] disponible en la mayoría de los clientes como /join #channelname . Los mensajes enviados a los canales unidos se retransmiten a todos los demás usuarios. [47]
Los canales que están disponibles en toda una red IRC tienen como prefijo '#', mientras que los locales de un servidor usan '&'. [50] Otros tipos de canales menos comunes incluyen los canales '+' (canales 'sin modalidad' sin operadores) [51] y los canales '!', una forma de canal con marca de tiempo en redes que normalmente no la tienen. [52]
Los usuarios y canales pueden tener modos que se representan mediante letras individuales que distinguen entre mayúsculas y minúsculas [53] y se configuran mediante el comando MODE . [54] Los modos de usuario y los modos de canal son independientes y pueden usar la misma letra para significar cosas diferentes (por ejemplo, el modo de usuario "i" es el modo invisible, mientras que el modo de canal "i" es solo por invitación. [55] ) Los modos generalmente se configuran y desconfiguran mediante el comando mode que toma un objetivo (usuario o canal), un conjunto de modos para configurar (+) o desconfigurar (-) y cualquier parámetro que necesiten los modos.
Algunos modos de canal toman parámetros y otros modos de canal se aplican a un usuario en un canal o agregan o eliminan una máscara (por ejemplo, una máscara de prohibición) de una lista asociada con el canal en lugar de aplicarse al canal como un todo. [56] Los modos que se aplican a los usuarios en un canal tienen un símbolo asociado que se utiliza para representar el modo en las respuestas de nombres [57] (enviadas a los clientes cuando se unen por primera vez a un canal [49] y el uso del comando de nombres) y en muchos clientes también se utilizan para representarlo en la lista de usuarios que se muestra en el cliente en un canal o para mostrar un indicador propio para los modos de un usuario.
Para analizar correctamente los mensajes de modo entrantes y hacer un seguimiento del estado del canal, el cliente debe saber qué modo es de qué tipo y, para los modos que se aplican a un usuario en un canal, qué símbolo corresponde a qué letra. En las primeras implementaciones de IRC, esto tenía que estar codificado en el cliente. Sin embargo, ahora existe una extensión estándar de facto del protocolo llamada ISUPPORT que envía esta información al cliente en el momento de la conexión utilizando el número 005. [58] [59]
Hay un pequeño fallo de diseño en IRC en relación con los modos que se aplican a los usuarios en los canales: el mensaje de nombres utilizado para establecer el estado inicial del canal sólo puede enviar un modo de este tipo por usuario en el canal, [57] pero se pueden establecer múltiples modos de este tipo en un único usuario. Por ejemplo, si un usuario tiene tanto el estado de operador (+o) como el estado de voz (+v) en un canal, un nuevo cliente no podrá ver el modo con menor prioridad (es decir, voz). Existen soluciones alternativas para esto tanto en el lado del cliente como del servidor; una solución común es utilizar la extensión "multi-prefijo" de IRCv3. [60]
Muchos demonios y redes han agregado modos adicionales o han modificado el comportamiento de los modos en la lista anterior. [62] [63] [64] [65]
Un operador de canal es un cliente de un canal IRC que administra el canal. Los operadores de canales IRC se pueden identificar fácilmente por el símbolo o icono que aparece junto a su nombre (varía según la implementación del cliente, normalmente un prefijo del símbolo "@", un círculo verde o una letra latina "+o"/"o"). En la mayoría de las redes, un operador puede:
También hay usuarios que mantienen derechos elevados en su servidor local, o en toda la red; estos son llamados operadores de IRC, [66] a veces abreviados como IRCops u Opers (que no deben confundirse con operadores de canal). Como la implementación del IRCd varía, también lo hacen los privilegios del operador de IRC en el IRCd en cuestión. RFC 1459 [66] afirma que los operadores de IRC son "un mal necesario" para mantener un estado limpio de la red, y como tal necesitan poder desconectar y reconectar servidores. Además, para evitar que usuarios maliciosos o incluso programas automatizados dañinos ingresen a IRC, los operadores de IRC generalmente pueden desconectar clientes y prohibir completamente direcciones IP o subredes completas. Las redes que brindan servicios (NickServ et al.) generalmente permiten que sus operadores de IRC también manejen asuntos básicos de "propiedad". Otros derechos privilegiados pueden incluir anular prohibiciones de canales (poder unirse a canales a los que no se les permitiría unirse si no estuvieran operados), poder operar en canales en los que no podrían hacerlo sin estar operados, tener operadores automáticos en canales siempre, etc.
Una máscara de host es un identificador único de un cliente IRC conectado a un servidor IRC . [67] [68] Los servidores IRC , servicios y otros clientes, incluidos los bots , pueden usarlo para identificar una sesión IRC específica.
El formato de una máscara de host es . La máscara de host es similar a una dirección de correo electróniconick!user@host , pero no debe confundirse con ella .
La parte nick es el apodo elegido por el usuario y puede cambiarse mientras está conectado. La parte user es el nombre de usuario informado por ident en el cliente. [69] Si ident no está disponible en el cliente, se utiliza el nombre de usuario especificado cuando el cliente se conectó después de haber sido prefijado con una tilde . [70]
La parte del host es el nombre de host desde el que se conecta el cliente. Si el servidor no puede resolver la dirección IP del cliente en un nombre de host válido , se utiliza en lugar del nombre de host.
Debido a las implicaciones de privacidad que implica exponer la dirección IP o el nombre de host de un cliente, algunos daemons de IRC también proporcionan funciones de privacidad, como el modo "+x" de InspIRCd o UnrealIRCd. Esto convierte en hash la dirección IP de un cliente o enmascara parte del nombre de host de un cliente, haciéndolo ilegible para otros usuarios que no sean IRCops. Los usuarios también pueden tener la opción de solicitar un "host virtual" (o "vhost"), que se mostrará en la máscara de host para permitir un mayor anonimato. Algunas redes de IRC, como Libera Chat o Freenode , las utilizan como "capas" para indicar que un usuario está afiliado a un grupo o proyecto. [71]
Hay tres esquemas de identificadores uniformes de recursos (URI) provisionales reconocidos para Internet Relay Chat: irc, ircs, y irc6. [72] Cuando son compatibles, permiten hipervínculos de varias formas, incluidos
irc://<host>[:<puerto>]/[<canal>[?<palabra clave del canal>]]ircs://<host>[:<puerto>]/[<canal>[?<palabra clave del canal>]]irc6://<host>[:<puerto>]/[<canal>[?<palabra clave del canal>]]
(donde los elementos entre corchetes ([,]) son opcionales) que se utilizará para (si es necesario) conectarse al host especificado (o red, si el cliente IRC lo conoce) y unirse al canal especificado. [73] (Esto se puede utilizar dentro del propio cliente o desde otra aplicación, como un navegador web). irc es el URI predeterminado, irc6 especifica una conexión que se realizará utilizando IPv6 e ircs especifica una conexión segura.
Según la especificación, el símbolo de almohadilla habitual (#) se antepondrá a los nombres de canales que comiencen con un carácter alfanumérico , lo que permite omitirlo. Algunas implementaciones (por ejemplo, mIRC) lo harán de manera incondicional, lo que dará como resultado un carácter adicional (por lo general no deseado) (por ejemplo, ##channel), si se incluye en la URL.
Algunas implementaciones permiten especificar múltiples canales, separados por comas. [74]
Los problemas en el diseño original de IRC eran la cantidad de datos de estado compartidos [75] [76] que era una limitación en su escalabilidad, [77] la ausencia de identificaciones de usuario únicas que conducían al problema de la colisión de apodos, [78] la falta de protección contra divisiones de red por medio del enrutamiento cíclico, [79] [80] la compensación en escalabilidad por el bien de la información de presencia del usuario en tiempo real, [81] las debilidades del protocolo que proporcionaban una plataforma para el abuso, [82] la falta de paso de mensajes transparente y optimizable, [83] y la falta de cifrado. [84] Algunos de estos problemas se han abordado en Modern IRC .
Debido a que las conexiones IRC pueden no estar cifradas y suelen durar largos períodos de tiempo, son un objetivo atractivo para los atacantes DoS/DDoS y los piratas informáticos . Por ello, es necesaria una política de seguridad cuidadosa para garantizar que una red IRC no sea susceptible a un ataque como una guerra de adquisición . Las redes IRC también pueden utilizar la línea K o G de usuarios o servidores que tengan un efecto perjudicial.
Algunos servidores IRC admiten conexiones SSL/TLS por motivos de seguridad. Esto ayuda a detener el uso de programas rastreadores de paquetes para obtener las contraseñas de los usuarios de IRC, pero tiene poca utilidad más allá de este ámbito debido a la naturaleza pública de los canales IRC. Las conexiones SSL requieren soporte tanto del cliente como del servidor (que puede requerir que el usuario instale binarios SSL y parches o módulos específicos del cliente IRC en sus computadoras). Algunas redes también utilizan SSL para conexiones de servidor a servidor y proporcionan un indicador de canal especial (como +S) para permitir solo usuarios conectados a SSL en el canal, mientras que no se permite la identificación del operador en texto claro, para aprovechar mejor las ventajas que proporciona SSL. [85] [86]
IRC sirvió como un laboratorio temprano para muchos tipos de ataques de Internet, como el uso de mensajes ICMP inalcanzables falsos para romper conexiones IRC basadas en TCP ( nuking ) para molestar a los usuarios o facilitar tomas de control .
Uno de los problemas técnicos más polémicos en torno a las implementaciones de IRC, que sobrevive hasta el día de hoy, es el mérito de los protocolos de "retardo de canal/apoyo" frente a los de "sello de tiempo". Ambos métodos existen para resolver el problema de los ataques de denegación de servicio, pero adoptan enfoques muy diferentes. El problema con el protocolo IRC original tal como se implementó era que cuando dos servidores se dividían y volvían a unirse, los dos lados de la red simplemente fusionaban sus canales. Si un usuario podía unirse a un servidor "dividido", donde un canal que existía en el otro lado de la red estaba vacío, y obtener el estado de operador, se convertiría en un operador de canal del canal "combinado" después de que terminara la división de la red ; si un usuario adoptaba un apodo que existía en el otro lado de la red, el servidor mataría a ambos usuarios al volver a unirse (una "colisión de apodos"). Esto se abusaba a menudo para "matar en masa" a todos los usuarios de un canal, creando así canales "sin operadores" en los que no había operadores presentes para lidiar con el abuso. Además de causar problemas dentro de IRC, esto alentó a las personas a realizar ataques de denegación de servicio contra servidores de IRC para causar divisiones de red , que luego abusarían.
Las estrategias de retraso de apodo (ND) y retraso de canal (CD) tienen como objetivo evitar el abuso al retrasar las reconexiones y los cambios de nombre. Después de que un usuario se desconecta y el apodo se vuelve disponible, o un canal deja de existir porque todos sus usuarios se separaron (como sucede a menudo durante un netsplit ), el servidor no permitirá que ningún usuario use ese apodo o se una a ese canal, hasta que haya transcurrido un cierto período de tiempo (el retraso ). La idea detrás de esto es que incluso si ocurre un netsplit , es inútil para un abusador porque no puede tomar el apodo ni obtener el estado de operador en un canal y, por lo tanto, no puede ocurrir una colisión de un apodo o "fusión" de un canal. Hasta cierto punto, esto incomoda a los usuarios legítimos, que pueden verse obligados a usar brevemente un nombre diferente después de volver a unirse (agregar un guión bajo es popular).
El protocolo de marca de tiempo es una alternativa a los retrasos de nick/canal que resuelve las colisiones utilizando una prioridad con marca de tiempo. A cada nick y canal de la red se le asigna una marca de tiempo (la fecha y la hora en que se creó). Cuando se produce una división de red, dos usuarios de cada lado tienen la libertad de usar el mismo nick o canal, pero cuando los dos lados se unen, solo uno puede sobrevivir. En el caso de los nicks, el usuario más nuevo, según su TS, muere; cuando un canal colisiona, los miembros (usuarios del canal) se fusionan, pero los operadores del canal del lado "perdedor" de la división pierden su estado de operador de canal.
TS es un protocolo mucho más complicado que ND/CD, tanto en diseño como en implementación, y a pesar de haber pasado por varias revisiones, algunas implementaciones aún tienen problemas con "dessincronizaciones" (cuando dos servidores en la misma red no están de acuerdo sobre el estado actual de la red), y permiten demasiada indulgencia en lo que se permitía al lado "perdedor". Bajo los protocolos TS originales, por ejemplo, no había protección contra los usuarios que establecían prohibiciones u otros modos en el canal perdedor que luego se fusionarían cuando el canal dividido se volviera a unir, a pesar de que los usuarios que habían establecido esos modos perdían su estado de operador de canal. Algunos servidores IRC modernos basados en TS también han incorporado alguna forma de ND y/o CD además de la marca de tiempo en un intento de frenar aún más el abuso.
La mayoría de las redes actuales utilizan el método de marca de tiempo. Los desacuerdos entre la marca de tiempo y ND/CD hicieron que varios servidores se separaran de EFnet y formaran la nueva IRCnet . Después de la división, EFnet pasó a un protocolo TS, mientras que IRCnet utilizó ND/CD.
En versiones recientes del ircd de IRCnet, así como en los ircd que utilizan el protocolo TS6 (incluido Charybdis), el ND se ha ampliado/reemplazado por un mecanismo llamado SAVE. Este mecanismo asigna a cada cliente un UID al conectarse a un servidor IRC. Este ID comienza con un número, lo cual está prohibido en los apodos (aunque algunos ircd, a saber, IRCnet e InspIRCd, permiten a los clientes cambiar a su propio UID como apodo).
Si dos clientes con el mismo apodo se unen desde diferentes lados de una red dividida ("colisión de apodos"), el primer servidor que detecte esta colisión obligará a ambos clientes a cambiar su apodo por su UID, lo que evitará que ambos clientes se desconecten. En IRCnet, el apodo también se bloqueará durante un tiempo (ND) para evitar que ambos clientes vuelvan a cambiar al apodo original y vuelvan a colisionar.
Existe software cliente para varios sistemas operativos o paquetes de software, así como para juegos web o internos. Hay muchos clientes diferentes disponibles para los distintos sistemas operativos, incluidos Windows , Unix y Linux , macOS y sistemas operativos móviles (como iOS y Android ). En Windows, mIRC es uno de los clientes más populares. [87] Algunas distribuciones de Linux vienen con un cliente IRC preinstalado, como Linux Mint , que viene con HexChat preinstalado.
Algunos programas que se pueden ampliar mediante complementos también sirven como plataformas para clientes de IRC. Por ejemplo, un cliente llamado ERC , escrito completamente en Emacs Lisp , está incluido en la versión 22.3 de Emacs. Por lo tanto, cualquier plataforma que pueda ejecutar Emacs puede ejecutar ERC.
Varios navegadores web tienen clientes IRC integrados, como:
Los clientes basados en web, como Mibbit y KiwiIRC de código abierto, pueden ejecutarse en la mayoría de los navegadores.
Juegos como War§ow , [88] Unreal Tournament (hasta Unreal Tournament 2004 ), [89] Uplink , [90] juegos basados en Spring Engine , 0 AD y ZDaemon han incluido IRC. [91]
La interfaz de chat de Ustream es IRC con autenticación personalizada [92], así como la de Twitch (anteriormente Justin.tv). [93] [94]
Un uso típico de los bots en IRC es proporcionar servicios de IRC o funcionalidades específicas dentro de un canal, como por ejemplo alojar un juego basado en chat o proporcionar notificaciones de eventos externos. Sin embargo, algunos bots de IRC se utilizan para lanzar ataques maliciosos, como denegación de servicio, envío de spam o explotación. [95]
Un programa que se ejecuta como un demonio en un servidor y funciona como un proxy persistente se conoce como BNC o bouncer. El propósito es mantener una conexión con un servidor IRC, actuando como un relé entre el servidor y el cliente, o simplemente actuar como un proxy. [ cita requerida ] Si el cliente pierde la conectividad de red, el BNC puede permanecer conectado y archivar todo el tráfico para su posterior entrega, lo que permite al usuario reanudar su sesión IRC sin interrumpir su conexión con el servidor. [ 96 ]
Además, como una forma de obtener un efecto similar al de un rebotador, un cliente de IRC (normalmente basado en texto , por ejemplo Irssi ) puede ejecutarse en un servidor siempre activo al que el usuario se conecta a través de ssh . Esto también permite que los dispositivos que solo tienen funcionalidad ssh, pero no tienen un cliente de IRC instalado, se conecten al IRC y permite compartir sesiones de IRC. [97]
Para evitar que el cliente IRC se cierre cuando se cierra la conexión ssh, el cliente puede ejecutarse dentro de un multiplexor de terminal como GNU Screen o tmux , permaneciendo así conectado a la(s) red(es) IRC constantemente y pudiendo registrar conversaciones en canales que le interesen al usuario, o mantener la presencia de un canal en la red. Siguiendo el modelo de esta configuración, en 2004 se lanzó un cliente IRC que seguía el modelo cliente-servidor , llamado Smuxi . [98] [99]
Hay numerosos motores de búsqueda disponibles para ayudar al usuario a encontrar lo que busca en IRC. [100] [101] Generalmente el motor de búsqueda consta de dos partes, un "back-end" (o "araña/rastreador") y un "motor de búsqueda" front-end.
El back-end (araña/rastreador web) es el caballo de batalla del motor de búsqueda. Es responsable de rastrear los servidores IRC para indexar la información que se envía a través de ellos. La información que se indexa generalmente consiste únicamente en texto del canal (texto que se muestra públicamente en canales públicos). El método de almacenamiento suele ser algún tipo de base de datos relacional, como MySQL u Oracle . [ cita requerida ]
El "motor de búsqueda" de interfaz es la interfaz de usuario de la base de datos. Proporciona a los usuarios una forma de buscar en la base de datos información indexada para recuperar los datos que están buscando. Estos motores de búsqueda de interfaz también pueden codificarse en numerosos lenguajes de programación.
La mayoría de los motores de búsqueda tienen su propio spider, que es una aplicación única responsable de rastrear IRC e indexar los datos; sin embargo, otros son indexadores "basados en el usuario". Estos últimos dependen de que los usuarios instalen su "complemento" en su cliente IRC; el complemento es lo que envía a la base de datos la información del canal en el que se encuentre el usuario. [ cita requerida ]
Muchos usuarios han implementado sus propios motores de búsqueda ad hoc utilizando las funciones de registro integradas en muchos clientes de IRC. Estos motores de búsqueda suelen implementarse como bots y están dedicados a un canal en particular o a un grupo de canales asociados.
El IRC aún carece de una única convención estándar globalmente aceptada sobre cómo transmitir caracteres fuera del repertorio ASCII de 7 bits . Los servidores IRC normalmente [ aclaración necesaria ] transfieren mensajes de un cliente a otro cliente simplemente como secuencias de bytes, sin ninguna interpretación o recodificación de caracteres . El protocolo IRC (a diferencia de, por ejemplo, MIME o HTTP ) carece de mecanismos para anunciar y negociar opciones de codificación de caracteres. Esto ha puesto la responsabilidad de elegir el códec de caracteres apropiado en el cliente. En la práctica, los canales IRC han utilizado en gran medida las mismas codificaciones de caracteres que también utilizaban los sistemas operativos (en particular, los derivados de Unix ) en las respectivas comunidades lingüísticas:
En la actualidad, la codificación UTF-8 de Unicode / ISO 10646 sería la más probable candidata a convertirse en una única codificación de caracteres estándar futura para todas las comunicaciones IRC, si dicha norma alguna vez relajara la restricción de tamaño de mensaje de 510 bytes. UTF-8 es compatible con ASCII y cubre el superconjunto de todos los demás estándares de conjuntos de caracteres codificados de uso común .
De forma muy similar a la compartición de archivos P2P convencional , los usuarios pueden crear servidores de archivos que les permitan compartir archivos entre sí mediante el uso de bots de IRC personalizados o scripts para su cliente de IRC . A menudo, los usuarios se agrupan para distribuir warez a través de una red de bots de IRC. [102]
Técnicamente, IRC no proporciona mecanismos de transferencia de archivos por sí mismo; el intercambio de archivos lo implementan los clientes de IRC , generalmente utilizando el protocolo Direct Client-to-Client (DCC), en el que las transferencias de archivos se negocian mediante el intercambio de mensajes privados entre clientes. La gran mayoría de los clientes de IRC cuentan con soporte para transferencias de archivos DCC, de ahí la opinión de que el intercambio de archivos es una característica integral de IRC. [103] Sin embargo, el uso común de este protocolo a veces también causa spam DCC. Los comandos DCC también se han utilizado para explotar a clientes vulnerables para que realicen una acción como desconectarse del servidor o salir del cliente.
Encontré información en varios lugares y recibí información de varias personas para escribir esto. Las personas que me ayudaron con esto incluyen: Greg "wumpus" Lindahl, Vesa "vesa" Ruokonen, James Ng, Tuomas Heino, Richard (eagle`s on undernet), Ari Lemmke
El Open Proxy Monitor que proporcionaba la red IRC Blitzed se ha apagado... La base de datos era tan grande que resulta casi imposible para el equipo hacer una copia de seguridad o encontrar una nueva ubicación para continuar con el servicio. Además, la mayoría de los miembros del equipo ya no tienen tiempo para mantener el servicio en funcionamiento.
El Grupo de trabajo IRCv3 es un grupo de autores de software de cliente y servidor IRC que trabajan para mejorar, mantener y estandarizar el protocolo IRC mediante extensiones compatibles con versiones anteriores.
como las Cuatro Grandes (EFnet, IRCnet, Undernet y DALnet), intentar listar los miles de canales con Ircle siempre provoca la desconexión debido a la avalancha de información, mientras que otros clientes normalmente pueden lograr la hazaña si se encuentra en una conexión Ethernet directa.
en día hay cientos de redes IRC independientes, pero las "cuatro grandes" son EFNet, UnderNet, Dalnet e IRCnet.
EFnet, UnderNET, DALnet e IRCnet conforman las cuatro grandes.
se han agrupado tradicionalmente como las "Cuatro Grandes": EFNet, IrcNet, QuakeNet y UnderNet.
mIRC es uno de los clientes IRC de Windows más populares.
URL del canal IRC (P1613) (ver usos )
