Internet Relay Chat - Internet Relay Chat

El primer servidor IRC, tolsun.oulu.fi, un servidor Sun-3 en exhibición cerca del centro de computación de la Universidad de Oulu . (2001)

Internet Relay Chat (IRC) es un sistema de chat ( mensajería instantánea ) basado en texto. Permite discusiones entre cualquier número de participantes en los llamados canales de conversación, así como discusiones entre solo dos socios, por ejemplo, en diálogos de preguntas y respuestas. Cualquier participante puede abrir un nuevo canal de conversación, y un solo usuario de computadora también puede participar en varios de estos canales simultáneos.

Para establecer o unirse a un chat, se requiere un programa de red, llamado cliente IRC, para acceder a un canal mediante la conexión a un servidor. El cliente de IRC puede ser un programa independiente en la computadora local (por ejemplo, mIRC, XChat) o tomar la forma de una interfaz de usuario especial dentro de un programa más grande, como un navegador de Internet; el navegador Opera , por ejemplo, incluye un cliente IRC, y clientes como Mibbit e IRCCloud o el código abierto KiwiIRC y The Lounge Chat del MIT pueden funcionar en conexión con muchos navegadores populares.

Se utiliza una red IRC de servidores interconectados que funcionan como estaciones repetidoras para mediar en las llamadas en el IRC. La característica esencial de esta red es su topología de comunicación BITNET, que permite solo una ruta de comunicación entre dos participantes cualesquiera. Históricamente, esto aseguraba una comunicación eficiente, porque en los primeros días del IRC, las líneas de datos intercontinentales tenían una capacidad muy limitada. La topología permitió que un mensaje de un cliente en un continente no se enviara individualmente para cada cliente en otro continente, sino solo una vez a un servidor local, que luego lo distribuyó a los clientes. A pesar de las capacidades de gestión limitadas, eran posibles "paisajes de charla" muy grandes. La desventaja es la falta de redundancia, que se manifiesta en las llamadas divisiones de red: si falla algún servidor, la red se divide automáticamente en partes separadas hasta que se establece una nueva conexión entre las partes.

Las redes de IRC más grandes consisten en varias docenas de servidores de IRC que conectan simultáneamente a más de 100,000 usuarios y administran decenas de miles de canales, en cada uno de los cuales varios miles de personas pueden participar simultáneamente. A pesar de estas enormes proporciones, el retraso en un texto enviado suele ser del orden de décimas de segundo y rara vez supera el tiempo de un segundo.

El uso de IRC ha ido disminuyendo de manera constante desde 2003, perdiendo el 60 por ciento de sus usuarios (de 1 millón a aproximadamente 400,000 en 2021) y la mitad de sus canales (de medio millón en 2003 a menos de 200,000 en 2021). En abril de 2011, las 100 principales redes de IRC atendían a más de medio millón de usuarios a la vez, albergando cientos de miles de canales que operaban en un total de aproximadamente 1 500 servidores de aproximadamente 3 200 servidores de IRC en todo el mundo. A junio de 2021, se sabe que operan 481 redes de IRC diferentes, de las cuales Libera Chat , de código abierto , fundada en mayo de 2021, tiene la mayor cantidad de usuarios, con 20,374 canales en 26 servidores; entre ellos, las 100 principales redes de IRC comparten más de 100 mil canales que operan en unos mil servidores.

Desde un punto de vista técnico, 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 . Como ya se ha comentado, los clientes de IRC pueden ser programas informáticos independientes o aplicaciones web que se ejecutan localmente en el navegador o en un servidor de terceros. Estos clientes se comunican con los servidores de chat para transferir mensajes a otros clientes. IRC está diseñado principalmente para la comunicación grupal en foros de discusión, llamados canales , pero también permite la comunicación uno a uno a través de mensajes privados , así como el chat y la transferencia de datos , incluido el intercambio de archivos .

El software cliente está disponible para todos los principales sistemas operativos que admiten el acceso a Internet.

Historia

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 Ciencia de Procesamiento de Información. Jarkko tenía la intención de ampliar el software BBS que administraba, para permitir noticias en el estilo de Usenet , discusiones en tiempo real y características BBS similares. La primera parte que implementó fue la parte del chat, que hizo con partes prestadas escritas por sus amigos Jyrki Kuoppala y Jukka Pihl. La primera red IRC se estaba ejecutando en un solo servidor llamado tolsun.oulu.fi. Oikarinen encontró inspiración en un sistema de chat conocido como Bitnet Relay , que operaba en BITNET .

Jyrki Kuoppala presionó a Oikarinen para que le pidiera a la Universidad de Oulu que liberara el código IRC para que también pudiera ejecutarse fuera de Oulu, y después de que finalmente lo liberaron, Jyrki Kuoppala inmediatamente instaló otro servidor. Esta fue la primera "red IRC". Oikarinen consiguió que algunos amigos de la Universidad de Helsinki y la Universidad de Tampere comenzaran a ejecutar servidores IRC cuando aumentó su número de usuarios y pronto le siguieron otras universidades. En ese momento, Oikarinen se dio cuenta de que el resto de las funciones de BBS probablemente no encajarían en su programa.

Oikarinen se puso en contacto con personas de la Universidad de Denver y la Universidad Estatal de Oregon . 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. IRC luego se hizo más grande y se usó 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.

EFnet

En agosto de 1990, tuvo lugar el primer gran desacuerdo en el mundo de la IRC. La "A-net" (red de la anarquía) incluía un servidor llamado eris.berkeley.edu. Todo estaba abierto, no requería contraseñas y no tenía límite en el número de conexiones. Como explica Greg "wumpus" Lindahl: "tenía una línea de servidor comodín, por lo que la gente estaba conectando servidores y colisionando con todo el mundo". La "Eris Free Network", EFnet , convirtió a la máquina eris en la primera en tener Q-alineada (Q para cuarentena) de IRC. En palabras de wumpus nuevamente: "Eris se negó a eliminar esa línea, así que formé EFnet. No fue una gran pelea; conseguí que todos los hubs se unieran, y casi todos los demás se dejaron llevar". A-net se formó con los servidores eris, mientras que EFnet se formó con los servidores que no son eris. El historial mostró que la mayoría de los servidores y usuarios optaron por EFnet. Una vez que A-net se disolvió, el nombre EFnet dejó de tener sentido y, una vez más, fue la única red de IRC.

Por esa época se utilizó el IRC para informar sobre el intento de golpe de Estado soviético de 1991 durante un apagón mediático . Anteriormente se usó de manera similar durante la Guerra del Golfo . Los registros de chat de estos y otros eventos se guardan en el archivo ibiblio .

Horquilla Undernet

Otro esfuerzo de bifurcación, el primero que realmente marcó una gran y duradera diferencia, fue iniciado por 'Wildthang' en los Estados Unidos en octubre de 1992 (bifurcó la versión 2.8.10 de EFnet ircd). Estaba destinado a ser solo 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 finales de mes, la red francesa y canadiense se conectó a la estadounidense, formando la red que luego vino. que se llamará "The Undernet ".

Los "infranetters" querían llevar la ircd más lejos en un intento de hacer que consumiera menos ancho de banda y tratar de resolver el caos de canales ( netsplits y adquisiciones ) que EFnet comenzó a sufrir. Para este último propósito, Undernet implementó marcas de tiempo, nuevas rutas y ofreció 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 EE. UU., Canadá, Francia, Croacia y Japón. El 15 de agosto, el nuevo registro de recuento de usuarios se estableció en 57 usuarios.

En mayo de 1993, se publicó RFC 1459 y detalla un protocolo simple para la operación cliente / servidor, canales, conversaciones uno a uno y uno a muchos. Es de destacar que un número significativo de extensiones como CTCP, colores y formatos no están incluidos en las especificaciones del protocolo, ni tampoco la codificación de caracteres, lo que llevó a divergir varias implementaciones de servidores y clientes. De hecho, la implementación del software varió significativamente de una red a otra, cada red implementaba sus propias políticas y estándares en sus propias bases de código.

Horquilla DALnet

Durante el verano de 1994, la propia Undernet se bifurcó. La nueva red se llamó DALnet (que lleva el nombre de su fundador: dalvenjah), formada para un mejor servicio al usuario y más protecciones para los usuarios y los canales. Uno de los cambios más significativos en DALnet fue el uso de apodos más largos (el límite original del ircd era de 9 letras). Alexei "Lefler" Kosut hizo las modificaciones de DALnet ircd. Por tanto, DALnet se basó en el servidor ircd de Undernet, aunque los pioneros de DALnet fueron los que abandonaron EFnet. Según James Ng, las personas iniciales de DALnet eran "operaciones en #StarTrek enfermas por las constantes divisiones / retrasos / adquisiciones / etc.".

DALnet ofreció rápidamente WallOps globales (mensajes IRCop que pueden ser vistos por usuarios que son + w (/ mode NickName + w)), apodos más largos, Q: apodos alineados (apodos que no se pueden usar, es decir, ChanServ, IRCop, NickServ, etc.) , global K: Lines (prohibición de una persona o un dominio completo de un servidor o de toda la red), solo comunicaciones de IRCop: GlobOps, modo + H que muestra que un IRCop es un "helpop", etc. Muchas 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.

Bifurcación de IRCnet

En julio de 1996, después de meses de guerras de llamas y discusiones sobre la lista de correo, hubo otra división debido al desacuerdo sobre cómo debería evolucionar el desarrollo de la ircd. Más notablemente, el lado "europeo" (la mayoría de esos servidores estaban en Europa) que luego se denominó IRCnet defendió retrasos en el nick y el canal, mientras que el lado de EFnet defendió las marcas de tiempo. También hubo desacuerdos sobre las políticas: la parte europea 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 la parte estadounidense.

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 evento también se conoce como "La Gran Escisión" en muchas sociedades de IRC. EFnet ha crecido desde entonces (en agosto de 1998) 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.

IRC moderno

IRC ha cambiado mucho a lo largo de su vida en Internet. El nuevo software de servidor ha agregado una multitud de nuevas funciones.

  • Servicios : bots operados en red para facilitar el registro de apodos y canales, envío de mensajes para usuarios fuera de línea y funciones de operador de red.
  • Modos adicionales: mientras que el sistema IRC original usaba un conjunto de modos de canal y de usuario estándar, los nuevos servidores agregan muchos modos nuevos para funciones como eliminar códigos de color del texto u ocultar la máscara de host de un usuario ("encubrimiento") para protegerlo de la negación de -Ataques de servicio .
  • Detección de proxy: la mayoría de los servidores modernos admiten la detección de usuarios que intentan conectarse a través de un servidor proxy inseguro (mal configurado o explotado) , al que luego se le puede negar la conexión. Este software de detección de proxy es utilizado por varias redes, aunque esa lista de proxies en tiempo real no existe desde principios de 2006.
  • Comandos adicionales: los comandos nuevos pueden ser, por ejemplo, comandos abreviados para emitir comandos a los Servicios, o comandos exclusivos del operador de red para manipular la máscara de host de un usuario.
  • Cifrado : para el tramo de cliente a servidor de la conexión, se puede usar TLS (los mensajes dejan de ser seguros una vez que se transmiten a otros usuarios en conexiones estándar, pero dificulta la escucha o las escuchas telefónicas en las sesiones de IRC de un individuo). Para la comunicación de cliente a cliente, se puede utilizar SDCC (Secure DCC).
  • Protocolo de conexión: IRC se puede conectar a través de IPv4 , la versión anterior del Protocolo de Internet , o por IPv6 , el estándar actual del protocolo.

A partir de 2016, se está llevando a cabo un nuevo esfuerzo de estandarización bajo un grupo de trabajo llamado IRCv3, que se enfoca en funciones de cliente más avanzadas como notificaciones instantáneas, mejor soporte de historial y seguridad mejorada. A partir de 2019, ninguna de las principales redes de IRC ha adoptado por completo el estándar propuesto.

Después de su era dorada durante la década de 1990 y principios de la de 2000 (240.000 usuarios en QuakeNet en 2004), IRC ha experimentado una disminución significativa, perdiendo alrededor del 60% de los usuarios entre 2003 y 2012, y los usuarios se mudaron a plataformas de redes sociales más nuevas como Facebook o Twitter . sino también a plataformas abiertas como XMPP, que se desarrolló en 1999. Ciertas redes como Freenode no han seguido la tendencia general y han cuadriplicado su tamaño durante el mismo período. Sin embargo, Freenode, que en 2016 tenía alrededor de 90.000 usuarios, desde entonces se ha reducido a unos 65.000 usuarios.

Las redes de IRC más grandes se han agrupado tradicionalmente como las "Cuatro Grandes", una designació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:

El IRC alcanzó los 6 millones de usuarios simultáneos en 2001 y los 10 millones de usuarios en 2003, cayendo a 371 mil en 2018.

A septiembre de 2021, las redes de IRC más grandes son:

  • Libera Chat  : alrededor de 47k usuarios en horas pico
  • IRCnet  : alrededor de 20.000 usuarios en las horas pico
  • Undernet  : alrededor de 15.000 usuarios en las horas pico
  • OFTC  : alrededor de 14k usuarios en horas pico
  • EFnet  : alrededor de 12.000 usuarios en las horas pico
  • Rizon  : alrededor de 11k usuarios en horas pico
  • QuakeNet  : alrededor de 10.000 usuarios en las horas pico
  • DALnet  : alrededor de 8.000 usuarios en las horas pico

Las 100 principales redes de IRC tienen alrededor de 220.000 usuarios conectados en las horas pico.

Cronología

Cronología de los principales servidores:

Información técnica

Una captura de pantalla de HexChat , un cliente de IRC para entornos GTK .
Xaric, un cliente de IRC basado en texto, en el uso de Mac OS X . Se muestran dos canales de IRC y una conversación privada con el autor del software.

IRC es un protocolo abierto que usa TCP y, opcionalmente, TLS . Un servidor de IRC puede conectarse a otros servidores de IRC para expandir la red de IRC. Los usuarios acceden a las redes de IRC conectando un cliente a un servidor. 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 de IRC no requieren que los usuarios registren una cuenta, pero se requiere un nick antes de conectarse.

IRC fue originalmente un protocolo de texto sin formato (aunque más tarde ampliada), que a petición fue asignado puerto 194 / TCP por IANA . Sin embargo, el estándar de facto siempre ha sido ejecutar IRC en 6667 / TCP y números de puerto cercanos (por ejemplo, puertos TCP 6660–6669, 7000) 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 se suponía que debía usar el texto. Esto puede causar problemas cuando los usuarios que utilizan diferentes clientes y / o diferentes plataformas desean conversar.

Todos los protocolos de IRC de cliente a servidor que se utilizan hoy en día descienden del protocolo implementado en la versión irc2.4.0 del servidor IRC2 y están documentados en RFC 1459. Desde que se publicó 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 se han adoptado ampliamente entre otras implementaciones.

Aunque se han publicado muchas especificaciones sobre el protocolo IRC, no existe una especificación oficial, ya que el protocolo sigue siendo dinámico. Prácticamente ningún cliente y muy pocos servidores se basan estrictamente en las RFC anteriores como referencia.

Microsoft hizo una extensión para IRC en 1998 a través del IRCX propietario . Más tarde dejaron de distribuir software compatible con IRCX y, en su lugar, desarrollaron el MSNP propietario .

La estructura estándar de una red de servidores IRC es un árbol . Los mensajes se enrutan solo a lo largo de las ramas necesarias del árbol, pero el estado de la red se envía a todos los servidores y, por lo general, existe un alto grado de confianza implícita entre los servidores. Sin embargo, esta arquitectura tiene varios problemas. Un servidor malintencionado o que se comporta mal puede causar un daño importante a la red y cualquier cambio en la estructura, ya sea intencional o como resultado de las condiciones en la red subyacente, requiere una división y unión a la red. Esto da como resultado una gran cantidad de tráfico en la red y mensajes falsos para salir / unirse a los usuarios y una pérdida temporal de comunicación con los usuarios en los servidores de división. 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 varios 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. Esta es una fortaleza en comparación con los protocolos que no son de multidifusión, como el Protocolo simple de transferencia de correo (SMTP) o el Protocolo de presencia y mensajería extensible (XMPP).

Un demonio de IRC también se puede utilizar en una red de área local (LAN). Por tanto, el IRC se puede utilizar para facilitar la comunicación entre personas dentro de la red de área local (comunicación interna).

Comandos y respuestas

IRC tiene una estructura basada en líneas. Los clientes envían mensajes de una sola línea al servidor, reciben respuestas a esos mensajes y reciben copias de algunos mensajes enviados por otros clientes. En la mayoría de los clientes, los usuarios pueden ingresar comandos prefijándolos con una '/'. Dependiendo del comando, estos pueden ser manejados completamente por el cliente o (generalmente para comandos que el cliente no reconoce) pasados ​​directamente al servidor, posiblemente con alguna modificación.

Debido a la naturaleza del protocolo, los sistemas automatizados no siempre pueden emparejar correctamente un comando enviado con su respuesta con total fiabilidad y están sujetos a conjeturas.

Canales

El medio básico de comunicarse con un grupo de usuarios en una sesión de IRC establecida es a través de un canal . Los canales en una red se pueden mostrar usando el comando IRC LIST , que enumera todos los canales actualmente disponibles que no tienen los modos + so + p configurados, en esa red en particular.

Los usuarios pueden unirse a un canal usando el comando JOIN , en la mayoría de los clientes disponible como / join #channelname . Los mensajes enviados a los canales unidos se transmiten a todos los demás usuarios.

Los canales que están disponibles en toda una red IRC tienen el prefijo '#', mientras que los locales de un servidor usan '&'. Otros tipos de canales menos comunes incluyen canales '+', canales 'sin modo' sin operadores, y '!' canales, una forma de sellos de tiempo de canal en redes normalmente no sellos de tiempo.

Modos

Los usuarios y los canales pueden tener modos representados por letras que distinguen entre mayúsculas y minúsculas y se configuran mediante el comando MODE . Los modos de usuario y los modos de canal están separados y pueden usar la misma letra para significar cosas diferentes (por ejemplo, el modo de usuario "i" es un modo invisible mientras que el modo de canal "i" es solo por invitación). Los modos generalmente se configuran y desarman usando el comando de modo que toma un objetivo (usuario o canal), un conjunto de modos para armar (+) o desarmar (-) y cualquier parámetro que los modos necesiten.

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 aplicarla al canal como un todo. Los modos que se aplican a los usuarios en un canal tienen un símbolo asociado que se usa para representar el modo en las respuestas de nombres (enviadas a los clientes al unirse por primera vez a un canal y al usar el comando de nombres) y en muchos clientes también se usa para representarlo en las respuestas del cliente. muestra la lista de usuarios en un canal o para mostrar un indicador propio para los modos de un usuario.

Para analizar correctamente los mensajes de modo entrantes y rastrear el 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 va con qué letra. En las primeras implementaciones de IRC, esto tenía que estar codificado en el cliente, pero ahora hay 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.

Existe una pequeña falla de diseño en el IRC con respecto a los modos que se aplican a los usuarios en los canales: el mensaje de nombres que se usa para establecer el estado inicial del canal solo puede enviar uno de esos modos por usuario en el canal, pero se pueden configurar varios de esos modos en un solo 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 menos prioridad (es decir, voz). Las soluciones para esto son posibles tanto en el lado del cliente como en el del servidor, pero ninguna está ampliamente implementada.

Modos estándar (RFC 1459)

Modos de usuario
Carta Símbolo Descripción
I Invisible: no se puede ver sin un canal común o sin conocer el nombre exacto
s Recibe avisos del servidor
w Recibe golpes
o El usuario es un operador de IRC (ircop)
Modos de canal
Carta Símbolo Parámetro (s) Descripción
o @ Nombre del usuario afectado Operador de canal: puede cambiar los modos de canal y expulsar a los usuarios del canal, entre otras cosas.
s Canal secreto: no se muestra en la lista de canales ni en el whois del usuario, excepto para los usuarios que ya están en el canal.
pag Canal privado: aparece en la lista de canales como "prv" según RFC 1459.
norte Los usuarios no pueden enviar mensajes al canal de forma externa
metro El canal está moderado (solo aquellos que tienen el operador del canal o el estado de voz en el canal pueden enviarle mensajes)
I Solo los usuarios con invitaciones pueden ingresar al canal.
t Solo los operadores de canal pueden cambiar el tema del canal.
l Número límite Limita la cantidad de usuarios que pueden estar en el canal (cuando está lleno, no pueden unirse nuevos usuarios)
B Máscara de prohibición (nick! User @ host con comodines permitidos) Prohibe las máscaras de host del canal
v + Nombre del usuario afectado Da un estado de voz de usuario en el canal (ver + m arriba)
k Nueva clave de canal Establece una clave de canal de manera que solo los usuarios que conocen la clave pueden ingresar

Muchos demonios y redes han agregado modos adicionales o han modificado el comportamiento de los modos en la lista anterior.

Operadores de canal

Un operador de canal es un cliente en un canal de IRC que administra el canal. Los operadores de canales de IRC pueden verse fácilmente por el símbolo o icono junto a su nombre (varía según la implementación del cliente, comúnmente un prefijo de símbolo "@", un círculo verde o una letra latina "+ o" / "o"). En la mayoría de las redes, un operador puede:

  • Patear a un usuario
  • Prohibir a un usuario
  • Otorgue a otro usuario el estado de operador del canal IRC o el estado de voz del canal IRC.
  • Cambie el tema del canal IRC mientras el modo de canal + t está configurado.
  • Cambie los bloqueos del modo de canal de IRC.

Operadores de IRC

También hay usuarios que mantienen derechos elevados en su servidor local o en toda la red; estos se denominan operadores de IRC, a veces abreviados como IRCops u Opers (que no deben confundirse con los operadores de canal). A medida que varía la implementación del IRCd, también lo hacen los privilegios del operador de IRC en el IRCd dado. RFC 1459 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 volver a conectar los servidores. Además, para evitar que usuarios malintencionados o incluso programas automatizados dañinos entren en el IRC, los operadores de IRC generalmente pueden desconectar clientes y prohibir completamente las direcciones IP o las subredes completas. Las redes que transportan servicios (NickServ et al.) Generalmente permiten que sus operadores de IRC también manejen asuntos básicos de "propiedad". Otros derechos privilegiados pueden incluir la anulación de las prohibiciones de canales (poder unirse a canales a los que no se les permitiría unirse, si no estuvieran abiertos), poder optar por sí mismos en canales donde no podrían sin ser operados, ser auto-optado en los canales siempre y así sucesivamente.

Máscaras de host

Una máscara de host es un identificador único de un cliente de IRC conectado a un servidor de IRC . Los servidores , servicios y otros clientes de IRC , incluidos los bots , pueden usarlo para identificar una sesión de IRC específica.

El formato de una máscara de host es nick!user@host. La máscara de host tiene un aspecto similar, pero no debe confundirse con una dirección de correo electrónico .

La parte del apodo es el apodo elegido por el usuario y se puede cambiar mientras está conectado. La parte del usuario es el nombre de usuario informado por ident en el cliente. Si ident no está disponible en el cliente, el nombre de usuario especificado cuando el cliente se conectó se usa después de tener un prefijo con una tilde .

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 de exponer la dirección IP o el nombre de host de un cliente, algunos demonios de IRC también proporcionan características de privacidad, como InspIRCd o el modo "+ x" de UnrealIRCd. Esto codifica 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.

Esquema de URI

Hay tres reconocidos identificador uniforme de recursos (URI) esquemas para Internet Relay Chat: irc, ircs, y irc6. Cuando son compatibles, permiten hipervínculos de varias formas, incluidos

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

(donde los elementos encerrados entre corchetes ([,]) son opcionales) para ser usados ​​(si es necesario) para conectarse al host especificado (o red, si lo conoce el cliente IRC) y unirse al canal especificado. (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á mediante 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 los canales que comienzan con un carácter alfanumérico , lo que permite omitirlo. Algunas implementaciones (por ejemplo, mIRC) lo harán incondicionalmente dando como resultado un extra (generalmente no intencionado) (por ejemplo, ## canal), si se incluye en la URL.

Algunas implementaciones permiten especificar varios canales, separados por comas.

Desafíos

Los problemas en el diseño original de IRC fueron que la cantidad de datos de estado compartidos era una limitación en su escalabilidad, la ausencia de identificaciones de usuario únicas que conducían al problema de colisión de apodos, la falta de protección contra netsplits por medio de enrutamiento cíclico, la compensación en escalabilidad por el bien de la información de presencia del usuario en tiempo real, las debilidades del protocolo proporcionan una plataforma para el abuso, sin transmisión de mensajes transparente y optimizable, y sin cifrado. Algunos de estos problemas se han abordado en Modern IRC .

Ataques

Debido a que las conexiones de IRC pueden no estar cifradas y generalmente abarcan períodos de tiempo prolongados, son un objetivo atractivo para los atacantes y piratas informáticos DoS / DDoS . Debido a esto, es necesaria una política de seguridad cuidadosa para garantizar que una red de IRC no sea susceptible a un ataque como una guerra de adquisición . Las redes de IRC también pueden ser usuarios o servidores de K-line o G-line que tienen un efecto perjudicial.

Algunos servidores de IRC admiten conexiones SSL / TLS por motivos de seguridad. Esto ayuda a detener el uso de programas de rastreo de paquetes para obtener las contraseñas de los usuarios de IRC, pero tiene poco uso fuera de este alcance debido a la naturaleza pública de los canales de 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 una marca de canal especial (como +S) para permitir solo a los usuarios conectados a SSL en el canal, mientras que no permiten la identificación del operador en texto claro, para aprovechar mejor las ventajas que proporciona SSL .

IRC sirvió como un laboratorio temprano para muchos tipos de ataques de Internet, como el uso de mensajes ICMP inalcanzables falsos para romper las conexiones IRC basadas en TCP ( nuking ) para molestar a los usuarios o facilitar las adquisiciones .

Prevención de abusos

Uno de los problemas técnicos más polémicos que rodean las implementaciones de IRC, que sobrevive hasta el día de hoy, es el mérito de los protocolos "Nick / Channel Delay" frente a los protocolos "Timestamp". 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 implementado 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 pudiera unirse a un servidor "dividido", donde un canal que existía en el otro lado de la red estaba vacío, y ganar el estado de operador, se convertiría en un operador de canal del canal "combinado" después de que finalizara la división netsplit ; si un usuario tomaba un apodo que existía en el otro lado de la red, el servidor mataría a ambos usuarios cuando se reincorporaran (es decir, 'nick-collision'). A menudo se abusaba de esto para "matar en masa" a todos los usuarios de un canal, creando así canales "sin acceso" en los que no había operadores presentes para hacer frente al 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 netsplits , que luego abusarían.

Las estrategias de retardo de nick (ND) y retardo de canal (CD) tienen como objetivo prevenir el abuso retrasando las reconexiones y los cambios de nombre. Después de que un usuario cierra la sesión y el apodo está 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 cierto ha pasado un 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 u obtener el estatus de operador en un canal y, por lo tanto, no puede ocurrir una colisión de un apodo o una 'fusión' de un canal. Hasta cierto punto, esto incomoda a los usuarios legítimos, que podrían verse obligados a usar brevemente un nombre diferente después de volver a unirse (es común agregar un guión bajo ).

El protocolo de marca de tiempo es una alternativa a los retrasos de nick / canal que resuelve colisiones utilizando la prioridad de marca de tiempo. A cada apodo y canal de la red se le asigna una marca de tiempo: la fecha y la hora en que se creó. Cuando ocurre un netsplit, dos usuarios de cada lado son libres de usar el mismo apodo o canal, pero cuando los dos lados se unen, solo uno puede sobrevivir. En el caso de los apodos, el usuario más nuevo, según su TS, muere; cuando un canal choca, los miembros (usuarios del canal) se fusionan, pero los operadores del canal en el lado "perdedor" de la división pierden su condición 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 todavía tienen problemas con "desincronizaciones" (donde dos servidores en la misma red no están de acuerdo con el estado actual de la red), y permitir demasiada indulgencia en lo que permitía el 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 la división se reincorporara, a pesar de que los usuarios que habían configurado esos modos perdieron 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 enfoque de sellado de tiempo. Los desacuerdos entre la marca de tiempo y ND / CD hicieron que varios servidores se separaran de EFnet y formaran la IRCnet más nueva . Después de la división, EFnet pasó a un protocolo TS, mientras que IRCnet usó ND / CD.

En versiones recientes de IRCnet ircd, así como ircds que usan el protocolo TS6 (incluido Charybdis), ND se ha extendido / 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, que está prohibido en los nicks (aunque algunos ircds, 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 un netsplit ("colisión de nick"), el primer servidor que vea esta colisión forzará a ambos clientes a cambiar su nick a su UID, evitando así que ambos clientes se desconecten. En IRCnet, el apodo también se bloqueará durante algún tiempo (ND) para evitar que ambos clientes vuelvan a cambiar al apodo original y, por lo tanto, vuelvan a colisionar.

Clientela

Software de cliente

Esquema de una red IRC con clientes normales (verde), bots (azul) y gorilas (naranja)

El software cliente existe para varios sistemas operativos o paquetes de software, así como para juegos internos o basados ​​en la web. 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.

Algunos programas que son extensibles a través de 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 v.22.3 de Emacs. Por lo tanto, cualquier plataforma que pueda ejecutar Emacs puede ejecutar ERC.

Varios navegadores web tienen clientes IRC integrados, como Opera ( versión 12.18 y anteriores ) y el complemento ChatZilla para Mozilla Firefox (para Firefox 56 y anteriores; incluido como un componente integrado de SeaMonkey ). 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 , Unreal Tournament (hasta Unreal Tournament 2004 ), Uplink , juegos basados ​​en Spring Engine , 0 AD y ZDaemon han incluido IRC.

La interfaz de chat de Ustream es IRC con autenticación personalizada, así como la de Twitch (anteriormente Justin.tv).

Bots

Un uso típico de los bots en IRC es proporcionar servicios de IRC o funcionalidad específica dentro de un canal, como albergar 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, spam o explotación.

Bravucón

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 a un servidor de IRC, actuando como un relé entre el servidor y el cliente, o simplemente para actuar como un proxy. Si el cliente pierde la conectividad de la 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 de IRC sin interrumpir su conexión con el servidor.

Además, como una forma de obtener un efecto de rebote, un cliente de IRC (típicamente basado en texto , por ejemplo Irssi ) se puede ejecutar 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 ningún cliente IRC real instalado ellos mismos, se conecten al IRC, y permite compartir sesiones de IRC.

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 (s) IRC constantemente y capaz de registrar la conversación en los canales que el usuario está interesado o para mantener la presencia de un canal en la red. Siguiendo el modelo de esta configuración, en 2004 se lanzó un cliente IRC que sigue al cliente-servidor , llamado Smuxi .

Los motores de búsqueda

Hay numerosos motores de búsqueda disponibles para ayudar al usuario a encontrar lo que busca en IRC. 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 (spider / webcrawler) es el caballo de batalla del motor de búsqueda. Es responsable de rastrear los servidores de 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 el texto del canal (texto que se muestra públicamente en los canales públicos). El método de almacenamiento suele ser algún tipo de base de datos relacional, como MySQL u Oracle .

El "motor de búsqueda" de front-end es la interfaz de usuario de la base de datos. Proporciona a los usuarios una forma de buscar en la base de datos de información indexada para recuperar los datos que están buscando. Estos motores de búsqueda front-end también se pueden codificar en numerosos lenguajes de programación.

La mayoría de los motores de búsqueda tienen su propia araña que es una única aplicación responsable de rastrear el IRC y de indexar los datos en sí; sin embargo, otros son indexadores "basados ​​en el usuario". Estos últimos dependen de los usuarios para instalar su "complemento" en su cliente de IRC; el complemento es lo que envía a la base de datos la información del canal de cualquier canal en el que se encuentre el usuario.

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 generalmente se implementan como bots y se dedican a un canal en particular o grupo de canales asociados.

Codificación de caracteres

IRC todavía carece de una convención estándar única aceptada a nivel mundial sobre cómo transmitir caracteres fuera del repertorio ASCII de 7 bits . Los servidores de IRC normalmente transfieren mensajes de un cliente a otro cliente 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 de IRC han utilizado en gran medida las mismas codificaciones de caracteres que también utilizaron los sistemas operativos (en particular, los derivados de Unix ) en las respectivas comunidades lingüísticas:

  • Era de 7 bits: en los primeros días de IRC, especialmente entre los usuarios de idiomas escandinavos y finlandeses , las variantes nacionales de ISO 646 eran las codificaciones de caracteres dominantes . Estos codifican caracteres no ASCII como Ä Ö Å ä ö å en las posiciones de código 0x5B 0x5C 0x5D 0x7B 0x7C 0x7D ( US-ASCII : [ \ ] { | } ). Es por eso que estos códigos siempre están permitidos en los apodos. Según RFC 1459, {| } en los apodos deben tratarse como equivalentes en minúsculas de [\] respectivamente. A finales de la década de 1990, el uso de codificaciones de 7 bits había desaparecido en favor de ISO 8859-1 , y algunas asignaciones de equivalencia se eliminaron de algunos demonios de IRC.
  • Era de los 8 bits: desde principios de la década de 1990, las codificaciones de 8 bits, como ISO 8859-1, se han vuelto de uso común para los idiomas europeos. Los usuarios rusos podían elegir entre KOI8-R , ISO 8859-5 y CP1251 , y desde aproximadamente el año 2000, las redes IRC rusas modernas convierten entre estas diferentes codificaciones de escritura cirílica de uso común .
  • Era de varios bytes: durante mucho tiempo, los canales de IRC de Asia oriental con guiones logográficos en China, Japón y Corea han estado utilizando codificaciones de varios bytes como EUC o ISO-2022-JP . Con la migración común de ISO 8859 a UTF-8 en plataformas Linux y Unix desde aproximadamente 2002, UTF-8 se ha convertido en un sustituto cada vez más popular de muchas de las codificaciones de 8 bits utilizadas anteriormente en los canales europeos. Algunos clientes de IRC ahora son capaces de leer mensajes tanto en ISO 8859-1 como en UTF-8 en el mismo canal, autodetectando heurísticamente qué codificación se usa. El cambio a UTF-8 comenzó en particular en el IRC de habla finlandesa ( Merkistö (finlandés) ).

Hoy en día, la codificación UTF-8 de Unicode / ISO 10646 sería el contendiente más probable para una codificación de caracteres estándar única en el futuro para toda la comunicación IRC, si tal estándar alguna vez relajó 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 juegos de caracteres codificados de uso común .

Compartición de archivos

Al igual que el intercambio de archivos P2P convencional , los usuarios pueden crear servidores de archivos que les permitan compartir archivos entre sí mediante el uso de scripts o bots de IRC personalizados para su cliente de IRC . A menudo, los usuarios se agrupan para distribuir warez a través de una red de bots de IRC.

Técnicamente, IRC no proporciona mecanismos de transferencia de archivos en sí; El intercambio de archivos es implementado por los clientes de IRC , normalmente 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. El uso común de este protocolo, sin embargo, a veces también causa spam DCC. Los comandos DCC también se han utilizado para explotar a los clientes vulnerables para que realicen una acción como desconectarse del servidor o salir del cliente.

Ver también

Citas

Bibliografía general

Otras lecturas

enlaces externos