# Internet Relay Chat

IRC (Internet Relay Chat) :
| Familie: | Internetprotokollfamilie |
| Einsatzgebiet: | Messaging, Soziale Netze |
| Port: | 194/TCP Offiziell, nicht in Verwendung, 6665-6669/TCP Offiziell, 6667 am häufigsten verwendet 6697/TCP Offiziell, für TLS-Verbindungen |
| IRC im TCP/IP-Protokollstapel: Anwendung IRC Transport TCP Internet IP (IPv4, IPv6) Netzzugang Ethernet Token Bus Token Ring FDDI … ||
| Standards: | RFC 1459 (1993) RFC 2810–2813 (2000) RFC 7194 |
Internet Relay Chat, kurz IRC, bezeichnet ein textbasiertes Chat-System. Es ermöglicht Gesprächsrunden mit einer beliebigen Anzahl von Teilnehmern in sogenannten Gesprächskanälen („Channels“), aber auch Gespräche mit nur zwei Partnern (Query). Neue Channels können von jedem Teilnehmer eröffnet werden, ebenso kann man gleichzeitig an mehreren Channel-Gesprächen teilnehmen.
Für die Einwahl wird ein Netzwerkprogramm benötigt, wobei dieser „IRC-Client“ ein eigenständiges Programm am lokalen Rechner (z. B. mIRC, XChat) oder auch nur eine Benutzeroberfläche im Webbrowser sein kann.
Zur Vermittlung der Gespräche im IRC dient ein IRC-Netzwerk, das aus miteinander verbundenen Servern (den „Relais“-Stationen) besteht. Wesensmerkmal dieser Netzwerke ist seine vom BITNET übernommene Kommunikationstopologie, wonach zwischen zwei beliebigen Teilnehmern immer nur genau ein Kommunikationspfad existiert. Dies stellte historisch eine effiziente Kommunikation sicher, denn in der Anfangszeit des IRC hatten interkontinentale Datenleitungen eine stark begrenzte Kapazität. Die Topologie ermöglichte es, dass eine Nachricht eines Clients auf einem Kontinent nicht für jeden Client auf dem anderen Kontinent einzeln über die Interkontinentalleitung gesendet werden musste, sondern nur einmal an einen dortigen Server, der sie dann an die Clients weiterverteilte. So waren trotz beschränkter Leitungskapazitäten sehr große „Chatlandschaften“ möglich. Nachteil des Prinzips ist die fehlende Redundanz, die sich in Netsplits äußert: Fällt irgendein Server aus, zerfällt das Netzwerk automatisch in voneinander getrennte Teile, bis dazwischen wieder eine neue Verbindung hergestellt wurde.
Die größten IRC-Netzwerke bestehen aus mehreren Dutzend IRC-Servern, die gleichzeitig über 100.000 Benutzer verbinden und zehntausende Channels verwalten, an denen jeweils mehrere tausend Personen gleichzeitig teilnehmen können. Trotz dieser enormen Ausmaße ist die Verzögerung eines abgeschickten Textes für gewöhnlich in der Größenordnung von Zehntelsekunden und überschreitet nur in seltenen Fällen die Sekundenmarke.

## Entwicklung

Die ursprüngliche Idee eines Chat-Netzwerkes entstand im BITNET unter dem Namen Relay Chat. Dieses System wurde vom finnischen Studenten Jarkko Oikarinen, der an der Fakultät für Informatik der Universität Oulu studierte, im Sommer 1988 auf das Internet übertragen.
Mit der Zeit wuchs das Netzwerk zu einer solchen Größe heran, dass es zum einen zu technischen Problemen kam und zum anderen zu unübersichtlich und chaotisch wurde. Daher entstanden ab etwa 1993 weitere unabhängige, kleinere Netzwerke. Im Sommer 1996 wurde dann auch das ursprüngliche Netzwerk aufgrund von Differenzen der Betreiber geteilt. Diese Teile findet man heute im IRCnet (meistens europäische Betreiber) und im EFnet (hauptsächlich Betreiber in den USA) wieder. Heute gibt es tausende voneinander unabhängige Netze. Große Netze sind QuakeNet, EFnet, IRCnet, Undernet, Libera Chat und freenode, kleinere etwa DALnet, euIRCnet, FurNet, OFTC oder GameSurge. In allen Netzwerken können aufgrund von Netzwerkproblemen oder -überlastung auch Netsplits auftreten.
Die Netze unterscheiden sich in regionalen Schwerpunkten, Sprachen, Themen und angebotenen Services. Auch die Akzeptanz oder Toleranz gegenüber Sex und Kanälen für die Verteilung von Schwarzkopien spielt zunehmend eine Rolle. Das Chatsystem ist textbasiert, erlaubt jedoch über weitere Kommandos auch den Austausch von Dateien und sonstigen Informationen über eine Direct-Client-to-Client-Verbindung (DCC) zweier User. Automatisierte DCC-Downloadmöglichkeiten werden auch XDCC genannt.

## Protokoll

Beim ursprünglichen IRC kommt ein auf IP und TCP basierendes, textorientiertes Protokoll zum Einsatz.

### Nutzerinduzierte Befehle

Es ist beim IRC üblich, dass Benutzer direkt in die Kommunikation zwischen ihrem Client und dem IRC-Server eingreifen, indem sie eigene Nachrichten/Befehle schicken.
Ein Beispiel für einen oft verwendeten Befehl ist /whois Nickname, der üblicherweise genau so einfach in einem Textfeld des IRC-Clients eingegeben werden kann. Der vorangestellte Slash (/) signalisiert dem IRC-Client, dass es sich um eine Nachricht handelt, die er dem IRC-Server in dieser Form übermitteln soll. Der Client schickt dem Server also whois Nickname, wobei whois den Befehl und Nickname den Parameter darstellt.

### Kommunikation

Sämtliche Kommunikation zwischen Client und Server und den Servern untereinander wird über Nachrichten (messages) in Befehlsform mit einer Maximallänge von 512 Zeichen inklusive befehlsbeendendem Zeilenumbruch abgewickelt.
Eine Nachricht besteht aus einem Absender (prefix), einem Befehl (command) und zusätzlichen Befehlsparametern. Die Parameter und ob überhaupt welche nötig sind, hängen vom jeweiligen Befehl ab. Bei Befehlen vom Client zum Server wird der Absender üblicherweise weggelassen, da kein anderer Absender als der Client selbst in Frage kommt.
Server tauschen untereinander nur Nachrichten mit Absenderangabe aus, da Server oftmals Nachrichten nur durchrouten, und hierzu Ziel und Quelle einer Nachricht nötige Angaben sind.
Als Antwort auf eine Nachricht von einem Client kann ein Server eine Antwort-Nachricht (reply) schicken, die einen Reply-Code hat. Dabei handelt es sich um eine dreistellige Zahl mit fest definierter Bedeutung. Auch hier weicht jedoch mangels Absprache die Bedeutung von Netzwerk zu Netzwerk ab.
Das IRC-Protokoll verursacht standardmäßig zwischen den Servern durch die verhältnismäßig langen Namen der Befehle relativ viel Steuerungsaufwand (Overhead), der wiederum unnötig viel Datenverkehr zur Folge hat. Um die Kosten zu verringern, wird in einigen IRC-Netzen ein spezielles Server-zu-Server-Protokoll eingesetzt, das beispielsweise für die Kommunikation zwischen den Servern ein so genanntes Token anstatt des vollständigen Befehls vorsieht (zum Beispiel „P“ anstatt „PRIVMSG“).

### Erweiterungen

Für IRC gibt es viele eigenständige Protokoll-Erweiterungen. Viele Befehle wurden ergänzt oder deren Syntax erweitert. Oftmals sind auch die so genannten Channelmodes und Usermodes um neue Modi erweitert. Die Entwicklung dieser Erweiterungen ist jedoch weitgehend unabhängig voneinander und unorganisiert in den verschiedenen IRC-Netzwerken abgelaufen und hängt generell von der verwendeten IRC-Serversoftware ab.
Es existiert deshalb nur unzureichende Dokumentation und Standardisierung dieser Erweiterungen. RFC 1459 beschreibt das ursprüngliche Protokoll, wovon die meisten Mechanismen und Befehle bis heute gültig sind und die Basis für anderweitige Erweiterungen des Protokoll sind. Dennoch sind diverse beschriebene Details durch die Weiterentwicklungen der Server-Software in den einzelnen IRC-Netzwerken nicht mehr aktuell und auch an keiner Stelle in ihrer neuen Ausformung zentral dokumentiert.
Darüber hinaus existieren RFC 2810, RFC 2811, RFC 2812 und RFC 2813. Sie haben jedoch in der Praxis wenig bis keinerlei Bedeutung, da diese im Alleingang von Christophe Kalt, dem Programmierer von IRCnet Version 2.9, geschrieben wurden. Insbesondere im Bereich der Kommunikation zwischen Servern innerhalb eines Netzes werden teilweise auch verkürzte (und dadurch inkompatible) Abwandlungen des Protokolls eingesetzt.

### Verschlüsselung

IRC kann sowohl in der Grundform unverschlüsselt, aber auf den meisten Netzwerken auch über eine SSL/TLS-verschlüsselte Verbindung benutzt werden. Clientübergreifend besteht auch die Möglichkeit, Nachrichten clientseitig zu verschlüsseln.
Eine Möglichkeit bietet die Verschlüsselung mit FiSH. FiSH verschlüsselt Channels mittels eines symmetrischen Kryptosystems. Hierfür wird für den zu verschlüsselnden Channel ein Key festgelegt, der allen Teilnehmern mitgeteilt werden muss. Ohne den Key kann der Channel zwar betreten werden (sofern er kein Passwort erfordert oder der Channelmode +i (invite only) gesetzt ist), die darüber stattfindende Kommunikation ist aber unleserlich. Weiterhin bietet FiSH die Möglichkeit, private Gespräche (Query) zwischen zwei Teilnehmern abzusichern. Hier kommt ein asymmetrisches Kryptosystem zum Einsatz. Mittels Diffie-Hellman-Schlüsselaustausch wird ein Key zwischen den Teilnehmern ausgehandelt. FiSH-Plug-ins gibt es für gängige IRC-Clients wie mIRC, XChat oder irssi. Auf Android bietet AndroIRC FiSH-Support.
Eine weitere Möglichkeit der Verschlüsselung bietet Off-the-Record Messaging (OTR). Im Gegensatz zu FiSH setzt OTR ausschließlich auf ein Public-Key-Verfahren, ein asymmetrisches Kryptosystem. Auch hier kommt der Diffie-Hellman-Schlüsselaustausch zum Einsatz. Daher kann OTR auch nur das Query verschlüsseln, nicht jedoch die gesamte Kommunikation in einem Channel. OTR gibt es als Plug-in für Pidgin, XChat und irssi.

### Zeichensätze

Da kein Zeichensatz festgelegt ist (wie es z. B. bei XMPP der Fall ist) und es auch keine Möglichkeit gibt, den verwendeten auf Protokollebene anzugeben, kann es immer wieder zu falsch oder nicht dargestellten Zeichen durch verschiedene Zeichensätze kommen. Einige Clients versuchen, den von den Sendern benutzten Zeichensatz zu raten, dies kann aber prinzipbedingt nicht zuverlässig funktionieren, da bestimmte Bytefolgen in verschiedenen Zeichensätzen gültig sind, aber zu unterschiedlichen Interpretationen führen.

## Einstieg

Um am IRC teilnehmen zu können, wird ein IRC-Client als Chat-Programm benötigt, welcher die Verbindung zu einem IRC-Server aufbaut. Da IRC zu den etablierteren und älteren Standards im Internet zählt, ist die Auswahl an IRC-Clients heutzutage groß.
In den meisten IRC-Clients ist bereits eine Auswahl bekannterer IRC-Netzwerke und deren Server gespeichert, mit denen man sich verbinden kann. Nachdem die Verbindung mit einem Server hergestellt ist, besteht die Möglichkeit, sich die vorhandenen Channels mit dem LIST-Befehl auflisten zu lassen. Viele Netzwerke unterstützen dabei auch eine Suche mit Wildcards.

### Channels

Die Kommunikation mit einer Gruppe von Benutzern erfolgt innerhalb eines sogenannten Channels (englisch für Kanal). Channels werden mit einem vorangestellten # gekennzeichnet. Mit dem Befehl /list können die Channel des IRC-Servers angezeigt werden, mit dem man verbunden ist. Mit dem Befehl /join #channelname kann man einem Channel beitreten.
Wird ein noch nicht vorhandener Channel betreten, legt der IRC-Server diesen üblicherweise an und gibt dem Benutzer die Kontrollrechte über den Channel (Channel Operator, kurz ChanOP). Sobald der letzte Benutzer einen Channel verlässt, wird der Channel aufgelöst. Viele IRC-Netzwerke bieten allerdings für Channels Bots bzw. Services an, die den Channel in diesem Fall „verwalten“ und den entsprechenden Benutzern ihre Rechte zurückgeben, sobald sie den Channel erneut betreten, sowie auch ein feineres Management des Channels erlauben.
Dazu werden Nicknamen und Channelnamen registriert. In Supportchannels, oft ähnlich benannt wie #irchelp, #help, #hilfe oder #helpdesk, können sich Anwender erkundigen, wie die Kommandos hierzu im Einzelnen lauten.
Manche Netzwerke bieten solche Services nicht an, da dort kein prinzipielles Besitzrecht für einen Channel oder auch für einen Nickname zugestanden wird. Hier ist der „Gründer“ des Channels selbst dafür verantwortlich, sich seine Rechte zu erhalten.
Diese Tatsache sorgt mitunter für virtuelle Kriege, welche mit legalen wie auch illegalen Mitteln ausgetragen werden, um Kontrolle über einen Channel zu erlangen (Takeover).

### Verhaltensregeln

Auf der Webseite des jeweiligen Netzes oder in der MOTD, die beim Connect angezeigt wird, findet man zumeist Informationen über die zu beachtenden Verhaltensregeln und anderweitige netzwerkspezifische Besonderheiten.

### Sicherheit

Wie generell im Internet sollten Anwender auch im IRC auf Sicherheit achten, da die Annahme von Dateitransfers von unbekannten Nutzern oder Unachtsamkeit zum Ausspionieren von Passwörtern oder Virenbefall des eigenen Rechners führen können. Man sollte auch beachten, dass bei einer unverschlüsselten Verbindung (ohne SSL/TLS) ein Mitlauschen von Konversationen und Passwörtern möglich ist.