IRC sous FreeBSD vs Linux : comparatif pour administrateurs

J'ai administre des serveurs IRC sur FreeBSD de 2003 a 2015. Puis j'ai migre vers Linux — pas par choix technique, mais parce que les hebergeurs qui proposent du FreeBSD se rarefient. La verite impopulaire : pour heberger un serveur IRC, FreeBSD est techniquement superieur. Mais Linux est plus pratique, mieux supporte, et plus facile a trouver en hebergement. Le choix depend de vos priorites.

Le contexte historique

Historiquement, les grands reseaux IRC tournaient sur FreeBSD. EFnet, IRCnet, et Undernet utilisaient FreeBSD sur la majorite de leurs serveurs dans les annees 2000. La raison principale etait kqueue — le systeme d'I/O asynchrone de FreeBSD — qui etait significativement plus performant que poll() et select() sous Linux pour gerer des milliers de connexions simultanees.

L'arrivee d'epoll sous Linux (kernel 2.6, 2003) a comble l'ecart. Aujourd'hui, les performances I/O sont comparables. Mais FreeBSD conserve des avantages dans d'autres domaines : pile reseau optimisee, Jails, et PF (Packet Filter).

kqueue vs epoll

# kqueue (FreeBSD) et epoll (Linux) sont deux mecanismes
# d'I/O event notification pour gerer des milliers
# de connexions simultanees.

# kqueue :
# - Disponible depuis FreeBSD 4.1 (2000)
# - Gere les events fichier, socket, timer, signal,
#   process dans une seule API unifiee
# - Un seul appel systeme pour enregistrer et attendre
# - Supporte les edge-triggered et level-triggered events

# epoll (Linux) :
# - Disponible depuis Linux 2.6 (2003)
# - Specifique aux file descriptors
# - Trois appels systeme : epoll_create, epoll_ctl, epoll_wait
# - Supporte edge-triggered et level-triggered

# Pour un IRCd, les deux sont equivalents en performance.
# UnrealIRCd et InspIRCd utilisent automatiquement
# le meilleur mecanisme disponible sur la plateforme.

# La difference pratique en 2025 :
# kqueue est plus elegant (API unifiee)
# epoll est plus repandu (plus de documentation, d'outils)
# Pour IRC, l'impact est negligeable — un IRCd ne fait
# pas assez d'I/O pour que la difference soit mesurable
# en dessous de 50 000 connexions simultanees.

# io_uring (Linux 5.1+) est le successeur d'epoll.
# Plus performant pour les workloads I/O intensifs.
# Aucun IRCd ne l'utilise encore car epoll suffit.

Jails vs containers

# FreeBSD Jails (disponibles depuis FreeBSD 4.0, 2000) :
# - Isolation au niveau OS (filesystem, reseau, process)
# - Plus simple que les containers Linux
# - Pas de daemon supplementaire (pas de dockerd)
# - Chaque jail a sa propre IP et son propre filesystem

# Creer une jail pour un IRCd :
jail -c name=ircd path=/jails/ircd \
  host.hostname=irc.jail \
  ip4.addr="203.0.113.10" \
  allow.raw_sockets \
  exec.start="/bin/sh /etc/rc" \
  exec.stop="/bin/sh /etc/rc.shutdown"

# Linux containers (Docker) :
docker run -d --name ircd \
  -p 6697:6697 \
  -v /data/ircd:/home/ircd/unrealircd/conf \
  unrealircd/unrealircd:latest

# Comparaison :
# Jails :
#   + Natif FreeBSD, pas de logiciel supplementaire
#   + Overhead quasi nul
#   + ZFS integration (snapshots, clones)
#   - Moins flexible que Docker (pas d'images hub)
#   - FreeBSD seulement

# Docker :
#   + Ecosysteme d'images pre-construites
#   + Portabilite entre distributions Linux
#   + Orchestration (Docker Compose, Kubernetes)
#   - Overhead du daemon Docker
#   - Surface d'attaque supplementaire (dockerd root)
#   - Reseau overlay complexe

PF vs iptables/nftables

# PF (Packet Filter) — FreeBSD :
# /etc/pf.conf

# Variables :
irc_ports = "{ 6667 6697 6900 }"
table  persist

# Regles :
# Bloquer les IPs dans la table bruteforce :
block in quick from 

# Limiter les connexions IRC :
pass in on egress proto tcp to port $irc_ports \
  flags S/SA keep state \
  (max-src-conn 5, max-src-conn-rate 3/30, \
   overload  flush global)

# Explication :
# max-src-conn 5 : max 5 connexions par IP
# max-src-conn-rate 3/30 : max 3 nouvelles connexions
#   en 30 secondes
# overload  : IP ajoutee a la table si depasse
# flush global : ferme toutes les connexions de cette IP

# C'est 3 lignes de PF. L'equivalent en iptables :

# iptables (Linux) :
iptables -A INPUT -p tcp -m multiport \
  --dports 6667,6697,6900 \
  -m conntrack --ctstate NEW \
  -m recent --set --name IRC

iptables -A INPUT -p tcp -m multiport \
  --dports 6667,6697,6900 \
  -m conntrack --ctstate NEW \
  -m recent --update --seconds 30 --hitcount 3 \
  --name IRC -j DROP

iptables -A INPUT -p tcp -m multiport \
  --dports 6667,6697,6900 \
  -m connlimit --connlimit-above 5 \
  --connlimit-mask 32 -j DROP

# PF est plus lisible et plus expressif.
# nftables (successeur d'iptables) est mieux
# mais PF reste plus elegant pour ce type de regles.

PF est objectivement mieux concu que iptables pour le rate limiting et la gestion des tables dynamiques. L'overload mechanism de PF est exactement ce dont un serveur IRC a besoin pour gerer les connection floods. Sous Linux, vous obtenez le meme resultat avec plus de lignes et moins de lisibilite.

Performance reseau

FreeBSD a historiquement une pile reseau (network stack) plus optimisee que Linux pour les workloads de type serveur. Les differences :

• Buffer management : Le systeme de mbufs de FreeBSD est mature et optimise pour le throughput reseau. Linux utilise sk_buff, qui est aussi performant mais avec une API differente.
• TCP tuning : FreeBSD a des valeurs par defaut plus conservatrices mais mieux ajustees pour les serveurs. Linux necessite plus de tuning sysctl pour atteindre les memes performances.
• NUMA awareness : Linux est meilleur pour les systemes multi-socket grace a une gestion NUMA plus avancee. Moins pertinent pour IRC (un seul processus, rarement multi-socket).

# Tuning FreeBSD pour IRC :
# /etc/sysctl.conf
kern.ipc.somaxconn=4096        # Backlog d'ecoute
kern.ipc.maxsockbuf=16777216   # Buffer socket max
net.inet.tcp.sendbuf_max=16777216
net.inet.tcp.recvbuf_max=16777216
net.inet.tcp.msl=5000          # TIME_WAIT plus court
net.inet.tcp.maxtcptw=40000    # Limite TIME_WAIT
security.bsd.see_other_uids=0  # Isolation process

# Tuning Linux pour IRC :
# /etc/sysctl.d/99-irc.conf
net.core.somaxconn = 4096
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_max_syn_backlog = 4096
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_tw_reuse = 1
fs.file-max = 100000

En pratique

Le choix entre FreeBSD et Linux pour IRC depend de facteurs non-techniques autant que techniques :

• Hebergement : Trouver un VPS FreeBSD est plus difficile et souvent plus cher. La plupart des hebergeurs mainstream (OVH, Hetzner, Vultr) proposent FreeBSD, mais le support est de seconde classe compare a Linux.
• Communaute : La documentation Linux pour les IRCds est plus abondante. Les guides d'installation supposent Linux. Si vous avez un probleme specifique FreeBSD, la communaute est plus petite.
• Competences : Si vous connaissez deja FreeBSD, utilisez FreeBSD. Si vous connaissez Linux, utilisez Linux. L'IRCd tourne aussi bien sur les deux. Le facteur limitant, c'est votre capacite a debugger l'OS, pas les performances de l'OS.
• ZFS : Si vous voulez ZFS (snapshots, compression, integrity), FreeBSD l'integre nativement et parfaitement. Linux a ZFS via OpenZFS mais c'est un module hors-arbre avec des complications de licence.