Optymalizacja serwera Minecraft pod odporność na ataki

Większość administratorów serwerów Minecraft myśli o ochronie DDoS jako o czymś zewnętrznym. Filtr ruchu, firewall, anti-DDoS serwis. Wszystko to jest słuszne i potrzebne. Ale jest rzecz, którą często się pomija: sam serwer musi być zoptymalizowany tak, żeby wytrzymywał obciążenie.

Logika jest prosta. Jeśli twój serwer w normalnym trybie działa na 90% zasobów, wystarczy niewielki skok, żeby padł. Jeśli natomiast serwer używa 40-50% zasobów, ma zapas wytrzymałości. Ten zapas (headroom) decyduje, czy serwer przeżyje atak, czy padnie przy pierwszych oznakach obciążenia.

W tym artykule rozkminiamy konkretne kroki optymalizacji, które dają maksymalny zapas wydajności.

Dlaczego wydajność = odporność

Podczas ataku DDoS na serwer Minecraft dzieje się kilka rzeczy naraz:

• Rośnie liczba połączeń TCP (SYN flood, bot join)
• Zwiększa się zużycie CPU na obróbkę pakietów
• Pauzy GC stają się dłuższe przez wzrost obiektów w pamięci
• TPS siada, tick loop zwalnia
• Gracze zaczynają lagować, timeoutować i reconnectować, generując jeszcze więcej obciążenia

To efekt kaskadowy. Serwer, który i tak pracował na granicy, wchodzi w spiralę degradacji. A serwer z zapasem wydajności może strawić skok, podczas gdy zewnętrzna ochrona odsiewa boty.

Więcej o tym, jak odróżnić lagi od ataku, przeczytasz w artykule o diagnostyce lagów.

Flagi JVM: fundament wydajności

Java Virtual Machine to środowisko, w którym działa serwer Minecraft. Ustawienia JVM wprost wpływają na prędkość pracy, stabilność GC (garbage collection) i zachowanie pod obciążeniem.

Aikar's Flags

Standard branżowy dla serwerów Minecraft. Te flagi konfigurują G1 Garbage Collector pod wzorce obciążenia specyficzne dla Minecrafta:

java -Xms10G -Xmx10G \
  -XX:+UseG1GC \
  -XX:+ParallelRefProcEnabled \
  -XX:MaxGCPauseMillis=200 \
  -XX:+UnlockExperimentalVMOptions \
  -XX:+DisableExplicitGC \
  -XX:+AlwaysPreTouch \
  -XX:G1NewSizePercent=30 \
  -XX:G1MaxNewSizePercent=40 \
  -XX:G1HeapRegionSize=8M \
  -XX:G1ReservePercent=20 \
  -XX:G1MixedGCCountTarget=4 \
  -XX:InitiatingHeapOccupancyPercent=15 \
  -XX:G1MixedGCLiveThresholdPercent=90 \
  -XX:G1RSetUpdatingPauseTimePercent=5 \
  -XX:SurvivorRatio=32 \
  -XX:+PerfDisableSharedMem \
  -XX:MaxTenuringThreshold=1 \
  -jar server.jar --nogui

Kluczowe punkty:

• -Xms i -Xmx takie same: eliminuje dynamiczną zmianę rozmiaru heapa. JVM od razu alokuje całą pamięć i nie marnuje czasu na rozszerzanie pod obciążeniem. Krytycznie ważne przy ataku, kiedy memory pressure gwałtownie rośnie.
• G1NewSizePercent=30 i G1MaxNewSizePercent=40: powiększony young generation. Minecraft tworzy ogromną liczbę krótkożyjących obiektów (chunk data, packet buffers, entity ticks). Duży young gen pozwala je zbierać tanio, bez full GC.
• G1HeapRegionSize=8M: optymalny rozmiar regionu dla serwerów z 8-12 GB. Dla serwerów z 4 GB i mniej lepiej zostawić domyślną wartość.
• AlwaysPreTouch: JVM przy starcie "dotyka" każdej strony pamięci, wymuszając na OS realne przydzielenie pamięci fizycznej. Bez tej flagi podczas ataku może się zdarzyć sytuacja, że JVM próbuje dostać pamięć, a OS oddał ją już innym procesom.

Ile RAM-u przydzielać

Popularny błąd: "im więcej RAM-u, tym lepiej". Nieprawda.

Dla G1GC istnieje wprost zależność: większy heap = dłuższe pauzy GC. Serwer z 32 GB heapa może dostawać pauzy GC 500-800 ms, co zamienia się w zauważalne fryzy.

Rekomendacje:

• Vanilla/Paper do 30 graczy: 4-6 GB
• Paper/Purpur 30-100 graczy: 8-12 GB
• Duże sieci 100+ graczy: 12-16 GB na instancję
• Proxy (Velocity/BungeeCord): 512 MB - 2 GB

Nie przydzielaj więcej niż 16 GB na jedną instancję. Jeśli potrzebujesz więcej zasobów, lepsze będzie horyzontalne skalowanie przez kilka serwerów za proxy.

Diagnostyka problemów z GC

Jak stwierdzić, że GC przeszkadza serwerowi? Włącz logowanie:

-Xlog:gc*:file=gc.log:time,uptime:filecount=5,filesize=10M

Albo użyj Spark:

/spark gc

Oznaki problemów:

• Pauzy GC dłuższe niż 100 ms pojawiają się częściej niż raz na minutę
• Full GC się dzieje w ogóle (przy prawidłowej konfiguracji G1GC nie powinno)
• Heap occupancy stale powyżej 70%

Jeśli widzisz te objawy, najprawdopodobniej problem tkwi w jednym z trzech: za mało RAM-u na liczbę pluginów i graczy, wyciek pamięci w jakimś pluginie, lub nieprawidłowe flagi JVM.

GraalVM vs OpenJDK

Dla Minecrafta 1.17+ warto rozważyć GraalVM. Jego kompilator JIT generuje bardziej optymalny kod natywny, co daje przyrost 10-15% w MSPT (milliseconds per tick). Przy ataku te 10-15% mogą okazać się różnicą między stabilnymi 20 TPS a spadkiem do 15.

# Instalacja GraalVM
sdk install java 21.0.2-graalce

Przy wyborze wersji Javy zwróć uwagę: Paper 1.20.5+ wymaga Javy 21. Używaj dokładnie tej wersji, którą rekomenduje jądro twojego serwera. Instalacja zbyt nowej albo zbyt starej Javy może prowadzić do nieoczekiwanych problemów z wydajnością i kompatybilnością pluginów.

Ustawienia Paper/Purpur

Paper (i jego fork Purpur) zawiera dziesiątki ustawień wpływających na wydajność. Prawidłowa konfiguracja zmniejsza bazowe obciążenie i uwalnia zasoby na obróbkę skoków.

paper-global.yml

chunk-loading:
  autoconfig-send-distance: true
  enable-frustum-priority: false
  global-max-chunk-load-rate: 300.0
  global-max-chunk-send-rate: 80.0
  global-max-concurrent-loads: 6.0
  max-concurrent-sends: 2
  min-load-radius: 2
  player-max-chunk-load-rate: 100.0
  player-max-concurrent-loads: 4.0
  target-player-chunk-send-rate: 40.0

• global-max-chunk-load-rate: ogranicza prędkość ładowania chunków. Przy bot flood na serwer wchodzą dziesiątki botów naraz, każdy triggeruje ładowanie chunków. Bez limitu natychmiast zjada CPU i dysk.
• global-max-concurrent-loads: krytycznie ważne. Ogranicza równoległe ładowanie chunków. Domyślna wartość jest za wysoka dla serwerów pod atakiem.

paper-world-defaults.yml

entities:
  spawning:
    spawn-limits:
      monsters: 50
      animals: 8
      water-animals: 3
      water-ambient: 2
      water-underground-creature: 3
      axolotls: 3
      ambient: 1
    tick-rates:
      monsters: 2
      animals: 4
      water-animals: 4
      water-ambient: 8
      ambient: 8
  entity-per-chunk-save-limit:
    experience_orb: 16
    arrow: 8
    area_effect_cloud: 4

environment:
  optimize-explosions: true
  treasure-maps:
    enabled: false
    find-already-discovered:
      loot-tables: true
      villager-trade: true

chunks:
  max-auto-save-chunks-per-tick: 6
  delay-chunk-unloads-by: 10s
  entity-per-chunk-save-limit:
    area_effect_cloud: 8
    arrow: 16
    dragon_fireball: 3
    egg: 8
    ender_pearl: 8
    experience_orb: 16
    fireball: 8
    small_fireball: 8
    snowball: 8

tick-rates:
  mob-spawner: 2
  sensor:
    villager:
      secondarypoisensor: 80
  behavior:
    villager:
      validatenearbypoi: 60

misc:
  redstone-implementation: ALTERNATE_CURRENT
  fix-curing-zombie-villager-discount-exploit: true

Kluczowe zmiany:

• Mob spawn limits zmniejszone: mniej mobów = mniej tików entity = większy zapas CPU. Podczas ataku liczy się każdy procent CPU.
• Entity tick rates zwiększone: moby sprawdzane są rzadziej. Wizualnie różnica niewidoczna, ale obciążenie CPU spada znacząco.
• optimize-explosions: używa zoptymalizowanego algorytmu do liczenia eksplozji. Armaty TNT nie położą serwera.
• redstone-implementation: ALTERNATE_CURRENT: alternatywna implementacja redstone od Earthcomputera. 2-3 razy szybsza od waniliowej.
• Treasure maps wyłączone: generacja map skarbów może wywołać kolosalne obciążenie na chunk generation.

server.properties

view-distance=8
simulation-distance=5
max-players=100
network-compression-threshold=256
rate-limit=0

• view-distance=8: dla większości serwerów 10 chunków to przesada. 8 to dobry balans. Każdy dodatkowy chunk view distance zwiększa obciążenie kwadratowo.
• simulation-distance=5: osobno od view distance. Entity i redstone tykają tylko w tym promieniu.
• network-compression-threshold=256: pakiety mniejsze niż 256 bajtów nie są kompresowane. Oszczędza CPU na kompresji małych pakietów.

spigot.yml

settings:
  save-user-cache-on-stop-only: true
  moved-wrongly-threshold: 0.0625
  moved-too-quickly-multiplier: 10.0
  timeout-time: 60
  restart-on-crash: true

world-settings:
  default:
    entity-activation-range:
      animals: 16
      monsters: 24
      raiders: 48
      misc: 8
      water: 8
      villagers: 16
      flying-monsters: 48
    merge-radius:
      item: 4.0
      exp: 6.0
    mob-spawn-range: 6
    nerf-spawner-mobs: true
    arrow-despawn-rate: 300
    trident-despawn-rate: 300

Więcej ustawień bezpieczeństwa dla Paper i Spigot opisano w osobnym artykule.

Ustawienia jądra Linux (sysctl)

Jeśli serwer Minecraft działa na dedykowanym serwerze lub VPS z Linuksem, ustawienia jądra mogą kardynalnie wpłynąć na odporność na ataki sieciowe.

Bufory sieciowe

# /etc/sysctl.d/99-minecraft.conf

# Zwiększamy bufory socketów
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.rmem_default = 1048576
net.core.wmem_default = 1048576

# Bufory TCP (min, default, max)
net.ipv4.tcp_rmem = 4096 1048576 16777216
net.ipv4.tcp_wmem = 4096 1048576 16777216

Po co to potrzebne: domyślne bufory w Linuksie są przewidziane pod zwykłe serwerowe zadania. Serwer Minecraft z 50+ graczami generuje znaczący ruch sieciowy. Powiększone bufory zapobiegają utracie pakietów przy skokach.

Backlog i kolejki połączeń

# Rozmiar kolejki przychodzących połączeń
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535

# Rozmiar kolejki urządzenia sieciowego
net.core.netdev_max_backlog = 65535

Krytycznie ważne przy DDoS. Kiedy na serwer leci strumień pakietów SYN, kolejka połączeń się zapełnia. Z domyślnym somaxconn=128 legitni gracze nie mogą się podłączyć, nawet jeśli serwer jest w stanie ich obsłużyć. Zwiększenie backlogu do 65535 daje serwerowi czas na obróbkę kolejki.

Tuning TCP

# Ponowne użycie socketów TIME_WAIT
net.ipv4.tcp_tw_reuse = 1

# Szybka utylizacja TIME_WAIT
net.ipv4.tcp_fin_timeout = 15

# Keepalive do wykrywania martwych połączeń
net.ipv4.tcp_keepalive_time = 300
net.ipv4.tcp_keepalive_intvl = 15
net.ipv4.tcp_keepalive_probes = 5

# SYN flood protection
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_tw_buckets = 2000000

• tcp_tw_reuse: pozwala ponownie używać socketów w stanie TIME_WAIT dla nowych połączeń. Podczas ataku, kiedy boty łączą się i odłączają, bez tego ustawienia sockety TIME_WAIT mogą wyczerpać dostępne porty.
• tcp_syncookies: obowiązkowo włączyć. To wbudowana w jądro Linuksa ochrona przed SYN flood. Kiedy kolejka SYN się przepełnia, jądro zaczyna używać SYN cookies zamiast przydzielać zasoby na każdy SYN.
• tcp_fin_timeout=15: domyślnie 60 sekund. Przy ataku tysiące półotwartych połączeń wisi w FIN_WAIT, zajmując pamięć jądra.

Limity file descriptorów

# /etc/security/limits.conf
minecraft soft nofile 1048576
minecraft hard nofile 1048576

# Albo w systemd unit
[Service]
LimitNOFILE=1048576

Każde połączenie TCP z serwerem = jeden file descriptor. Domyślny limit 1024 albo 4096 skończy się natychmiast przy ataku. Zwiększaj do miliona.

Zastosowanie ustawień

sudo sysctl -p /etc/sysctl.d/99-minecraft.conf

Optymalizacja pluginów

Pluginy to główny konsument zasobów po samym jądrze serwera. Jeden źle napisany plugin może zjadać więcej CPU niż wszystkie pozostałe razem wzięte.

Diagnostyka ciężkich pluginów

/timings on
# Poczekaj 5-10 minut
/timings paste

Spark to bardziej zaawansowana alternatywa:

/spark profiler start
# Poczekaj 5-10 minut
/spark profiler stop

Patrz na dwa parametry:

1. Tick time contribution - ile milisekund każdy plugin dokłada do tika
2. Thread activity - czy plugin nie blokuje głównego wątku synchronicznymi operacjami

Typowe problemy

Dynmap: generacja mapy świata wywołuje kolosalne obciążenie na CPU i dysk. Jeśli używasz, ogranicz prędkość renderu:

# configuration.txt
renderacceleratethreshold: 10
parallelrendercnt: 2
updaterate: 5000

Pluginy ekonomii z MySQL: synchroniczne zapytania do BD blokują główny wątek. Każdy tik, póki idzie zapytanie SQL, serwer stoi. Upewnij się, że plugin wspiera async-zapytania lub używaj HikariCP connection pool.

WorldEdit/WorldGuard: masowe operacje WorldEdit mogą wywoływać fryzy. Używaj FAWE (FastAsyncWorldEdit) zamiast standardowego WorldEdit.

Pluginy skanujące chunki: niektóre pluginy (Ore Obfuscator, niektóre anticheaty) przechodzą przez bloki w chunkach. To droga operacja. Sprawdź, czy można ograniczyć promień lub częstotliwość skanowania.

Ogólne zasady

• Każdy plugin musi być uzasadniony. "Na wszelki wypadek" - słaby powód.
• Testuj pluginy na testowym serwerze pod obciążeniem przed instalacją na produkcji.
• Aktualizuj pluginy. Deweloperzy często naprawiają wycieki pamięci i optymalizują wydajność w aktualizacjach.
• Nie używaj więcej niż jednego pluginu do tego samego zadania.

Scheduler zadań pluginów

Wiele pluginów używa Bukkit schedulera do wykonywania okresowych zadań. Problem w tym, że domyślnie zadania odpalają się co tik (50 ms). Jeśli masz 30 pluginów i każdy z nich odpala 2-3 zadania co tik, to już 60-90 dodatkowych obróbek na tik.

Sprawdź przez Spark, jakie scheduled tasks odpalają się najczęściej. Niektóre pluginy pozwalają skonfigurować częstotliwość przez konfigurację. Dla tych, które nie pozwalają, rozważ alternatywy albo fork z poprawką.

Folia (eksperymentalny fork Paper) rozwiązuje ten problem przez wielowątkowość, ale wsparcie pluginów tam jest jeszcze ograniczone. Dla większości serwerów Paper/Purpur pozostaje najlepszym wyborem.

Pre-generacja chunków

Generacja nowych chunków to jedna z najcięższych operacji dla serwera Minecraft. Każdy nowy chunk wymaga generacji terenu, struktur, biomów, oświetlenia. Jeden tik generacji może zająć 50-200 ms.

Podczas ataku, jeśli na serwer wchodzą boty i rozlatują się w różne strony, każdy z nich triggeruje generację nowych chunków. Natychmiast zabija to TPS.

Rozwiązanie: Chunky

/chunky radius 5000
/chunky start

Chunky pre-generuje chunki w podanym promieniu. Po generacji te chunki ładowane są z dysku, co jest 10-100 razy szybsze niż generacja od zera.

Rekomendacje:

• Pre-generuj przynajmniej strefę spawnu + główne trasy graczy
• Dla serwerów survival: promień 5000-10000 bloków od spawnu
• Generację lepiej robić nocą lub przy minimalnym online, bo sam proces generacji obciąża serwer
• Ustaw granicę świata (world border), żeby ograniczyć mapę. Oszczędza to i dysk, i zapobiega obciążeniu od eksploracji odległych terenów

/worldborder set 20000

Optymalizacja dysku

NVMe vs HDD

Dla serwera Minecraft prędkość dysku gra ogromną rolę. Chunki ładowane są z dysku, zapisywane na dysk, dane graczy zapisywane na dysk. Podczas ataku, kiedy dziesiątki botów generują operacje I/O, wolny dysk staje się wąskim gardłem.

• NVMe SSD: 3000-7000 MB/s odczyt. Chunki ładują się natychmiast.
• SATA SSD: 500-550 MB/s. Akceptowalne dla małych serwerów.
• HDD: 100-150 MB/s. Niedopuszczalne dla serwerów z 20+ graczami lub serwerów poddawanych atakom.

tmpfs dla plików tymczasowych

# Montowanie tmpfs dla logów
mount -t tmpfs -o size=512M tmpfs /home/minecraft/server/logs

# Albo w fstab
tmpfs /home/minecraft/server/logs tmpfs size=512M,nodev,nosuid 0 0

Logi Minecrafta mogą generować znaczące I/O. Przeniesienie logów do tmpfs (RAM-dysk) uwalnia dyskowe I/O pod ważniejsze zadania: ładowanie chunków i zapis danych.

Scheduler I/O

Dla dysków NVMe:

echo "none" > /sys/block/nvme0n1/queue/scheduler

Dla SATA SSD:

echo "mq-deadline" > /sys/block/sda/queue/scheduler

Dyski NVMe nie potrzebują schedulera I/O, bo obsługują zapytania równolegle. Scheduler none usuwa overhead.

System plików

Dla serwerów Minecraft rekomendowany jest ext4 z parametrami noatime,nodiratime:

# /etc/fstab
/dev/nvme0n1p1 /home/minecraft ext4 defaults,noatime,nodiratime 0 2

Parametr noatime wyłącza aktualizację znacznika czasu ostatniego dostępu przy odczycie pliku. Przy ładowaniu tysięcy plików chunków (region files) zmniejsza to liczbę zapisów na dysk. Jest to szczególnie widoczne pod atakiem, kiedy boty triggerują masowe ładowanie chunków.

Jeśli serwer używa ZFS, skonfiguruj recordsize=128k dla datasetów ze światem. Pliki region Minecrafta dobrze leżą na tym rozmiarze bloku. Włącz też compression=lz4 dla oszczędności miejsca bez widocznego wpływu na wydajność.

Limity połączeń na poziomie serwera

server.properties

max-players=100

Ustaw realistyczny limit. Jeśli twój serwer stabilnie obsługuje 50 graczy, nie stawiaj max-players=1000 "na zapas". Przy ataku boty zapełnią wszystkie 1000 slotów.

Rate limiting

Velocity (rekomendowane proxy) ma wbudowany rate limiter:

# velocity.toml
[advanced]
login-ratelimit = 3000
connection-timeout = 5000
read-timeout = 30000

login-ratelimit = 3000 znaczy minimum 3 sekundy między próbami logowania z jednego IP. Nie zatrzyma to rozproszonego ataku z tysięcy IP, ale odsieje najprostsze bot flood z jednego źródła.

Dla serwera bez proxy używaj pluginów typu LoginSecurity lub AuthMe ze skonfigurowanymi limitami.

Jak stabilność TPS pomaga przy atakach

TPS (Ticks Per Second) = 20 znaczy, że serwer obrabia 20 tików gry na sekundę. Każdy tik zajmuje do 50 ms. Jeśli tik zajmuje więcej niż 50 ms, TPS spada poniżej 20.

MSPT (Milliseconds Per Tick) to dokładniejsza metryka. Serwer z MSPT 30 ms ma 20 ms zapasu. Serwer z MSPT 48 ms ma tylko 2 ms zapasu.

Przy ataku DDoS każde dodatkowe obciążenie zwiększa MSPT:

• Obróbka pakietów botów: +5-15 ms
• Ładowanie chunków dla nowych połączeń: +10-50 ms
• Zwiększenie GC pressure: +5-20 ms

Serwer z MSPT 30 ms wytrzyma dodatkowe 20 ms obciążenia i zostanie na 20 TPS. Serwer z MSPT 48 ms spadnie do 10-15 TPS, gracze zaczną lagować i się odłączać.

Monitoring MSPT

/spark tps
/spark tickmonitor

Cel: trzymać MSPT poniżej 35 ms w normalnym trybie, żeby zostawał zapas na skoki.

Zmniejszanie powierzchni ataku

Optymalizacja to nie tylko prędkość. To też zmniejszanie tego, co atakujący może wykorzystać.

Wyłącz Query

# server.properties
enable-query=false

Protokół Query (UDP port 25565) pozwala uzyskać informacje o serwerze. Atakujący używają go do rekonesansu i ataków amplification.

Wyłącz RCON, jeśli nie używasz

enable-rcon=false

RCON to zdalna konsola. Jeśli jest otwarta do internetu, to bezpośredni wektor do bruteforce i eksploitacji.

Ogranicz broadcast

# paper-global.yml
proxies:
  bungee-cord:
    online-mode: true
  velocity:
    enabled: true
    online-mode: true
    secret: 'twój-sekretny-klucz'

Jeśli używasz proxy, włącz je przez secret key. To zapobiega bezpośredniemu podłączaniu do serwera backend z pominięciem proxy.

Whitelist w sytuacjach awaryjnych

/whitelist on

Jeśli atak jest za silny i filtracja sobie nie radzi, tymczasowy whitelist pozwoli grać tylko zarejestrowanym graczom. Nie idealne rozwiązanie, ale lepsze niż pełny downtime.

Kompleksowy checklist optymalizacji

Oto krótki checklist, który można przejść w jeden wieczór:

JVM:

• Aikar's flags ustawione
• -Xms = -Xmx
• RAM nie więcej niż 12-16 GB na instancję
• GraalVM rozważony jako alternatywa

Paper/Purpur:

• Mob spawn limits zmniejszone
• Entity tick rates zwiększone
• Chunk loading rate ograniczona
• View distance = 8 lub mniej
• Simulation distance = 5
• optimize-explosions: true
• redstone-implementation: ALTERNATE_CURRENT

Linux kernel:

• somaxconn = 65535
• tcp_max_syn_backlog = 65535
• tcp_syncookies = 1
• rmem_max i wmem_max zwiększone
• nofile limit zwiększony
• tcp_fin_timeout zmniejszony

Pluginy:

• Spark profiling przeprowadzony
• Ciężkie pluginy wymienione lub zoptymalizowane
• Sync zapytania SQL wymienione na async
• Nieużywane pluginy usunięte

Dysk i sieć:

• NVMe/SSD używany
• Chunki pre-generowane (Chunky)
• World border ustawiony
• Query i RCON wyłączone

Monitoring:

• Spark zainstalowany
• MSPT monitorowany
• Alerty na TPS < 18 skonfigurowane

Optymalizacja + zewnętrzna ochrona = maksymalna odporność

Ważne, żeby zrozumieć: optymalizacja serwera nie zastępuje ochrony DDoS. Uzupełnia ją. Żadne ustawienia sysctl nie uratują od 10 Gbit/s UDP flood. Do tego potrzebna jest filtracja ruchu na poziomie sieci.

Ale połączenie "zoptymalizowany serwer + jakościowa filtracja" (na przykład przez MineGuard) daje maksymalną odporność. Filtr odsiewa 99% śmieciowego ruchu, a zoptymalizowany serwer spokojnie trawi pozostały 1%, który się przedostał.

Wybór hostingu też gra rolę. Więcej o tym, na co zwracać uwagę przy wyborze hostingu z ochroną DDoS, przeczytasz tutaj.

Podsumowanie

Optymalizacja serwera Minecraft to nie jednorazowa akcja, tylko ciągły proces. Każda aktualizacja jądra, każdy nowy plugin, każda zmiana obciążenia może przesunąć balans. Regularnie rób profilowanie przez Spark, śledź MSPT, sprawdzaj ustawienia sysctl po aktualizacji jądra Linuksa.

Zapas wydajności to twoje ubezpieczenie. Im większy headroom ma serwer w normalnym trybie, tym większe szanse, że przeżyje atak i twoi gracze nawet nie zauważą, że coś się stało.