Quand votre serveur subit une attaque, « on se fait DDoS » n'est pas exploitable ; « SYN flood, quatre millions de paquets par seconde, sources usurpées, ciblant le port 443 » l'est. La différence entre les deux tient à une capture de paquets de trente secondes et un examen structuré de celle-ci. Ce guide couvre la capture en toute sécurité sur une machine déjà saturée (tcpdump, pas l'interface graphique de Wireshark), le workflow de tri dans Wireshark (Protocol Hierarchy, Conversations, I/O Graphs) et les signatures de filtres d'affichage des vecteurs d'attaque courants, pour terminer sur la façon de transformer les constats en mitigation.

Les attaques DDoS se répartissent en trois grandes familles : les floods volumétriques qui saturent votre tuyau, les attaques de protocole qui épuisent l'état des connexions, et les floods applicatifs qui ressemblent à du trafic légitime. Chacune épuise une ressource différente, chacune exige donc une défense différente, et aucune couche à elle seule n'arrête les trois. Ce guide met en correspondance les formes d'attaque courantes avec la ressource qu'elles visent et la mitigation qui fonctionne réellement contre elles, explique ce qu'un pare-feu sur le serveur peut arrêter et ce qu'il ne peut pas, et se termine par un plan d'action concret pour la réponse à incident quand votre serveur est attaqué.

Le ping n'est qu'une partie de ce que ressent un joueur. Un aller-retour complet traverse l'échantillonnage de l'entrée, le dernier kilomètre, le transit et le peering, une file d'attente sur le serveur, puis l'attente du prochain tick de simulation avant que le monde ne réagisse. Ce guide détaille d'où vient réellement le délai ressenti, comment le tick rate et le netcode changent la donne, pourquoi le jitter et le packet loss nuisent plus qu'un ping élevé mais stable, et le levier que l'hébergeur maîtrise le plus : placer le serveur près des joueurs, sur du matériel qui tient son tick rate.

Netplan est la couche YAML qui configure le réseau sur Ubuntu Server : vous décrivez adresses, routes et DNS dans un seul fichier, et un générateur transforme cela en configuration pour systemd-networkd. Ce cours accéléré est écrit pour un serveur dédié avec une IP publique statique, sans Wi-Fi, et SSH comme seul point d'entrée. Il couvre l'emplacement des fichiers, la règle de permission 600 réservée à root, un exemple complet de configuration statique IPv4 et IPv6, les commandes generate, try et apply qui évitent de vous verrouiller vous-même dehors, ainsi que les VLANs, les bonds, les bridges, et le fichier cloud-init qui n'arrête pas d'écraser les modifications des utilisateurs.

NetworkManager is the daemon that configures the network on every RHEL-family server, and since RHEL dropped the old network-scripts it is the only supported way to do it. This crash course runs it the way a dedicated server uses it: headless, static, over SSH, with nmcli and keyfiles instead of a desktop applet. You will learn the device-and-profile model that clears up most nmcli confusion, a full static IPv4 and IPv6 setup you can paste and adapt, where profiles live on disk across RHEL 8, 9, and 10, and how to change the network on a remote box without locking yourself out.