{"id":19121,"date":"2026-04-17T11:50:36","date_gmt":"2026-04-17T09:50:36","guid":{"rendered":"https:\/\/webhosting.de\/server-bandwidth-shaping-traffic-control-linux-optimierung-netzwerk\/"},"modified":"2026-04-17T11:50:36","modified_gmt":"2026-04-17T09:50:36","slug":"server-bandwidth-shaping-traffic-control-linux-optimization-network","status":"publish","type":"post","link":"https:\/\/webhosting.de\/fr\/server-bandwidth-shaping-traffic-control-linux-optimierung-netzwerk\/","title":{"rendered":"Server Bandwidth Shaping et Traffic Control Linux : optimisation expliqu\u00e9e"},"content":{"rendered":"<p>Ich zeige, wie <strong>Bandwidth Shaping<\/strong> auf Servern und Traffic Control in Linux die Paketfl\u00fcsse so steuert, dass Latenz, Jitter und Ausf\u00e4lle sp\u00fcrbar sinken. Dabei setze ich priorisierte Queues, Limits und QoS-Regeln gezielt ein, um gesch\u00e4ftskritische Str\u00f6me wie VoIP, APIs oder Shop-Requests vor Hintergrundlasten und Backups zu sch\u00fctzen.<\/p>\n\n<h2>Zentrale Punkte<\/h2>\n\n<p>Die folgenden Kernaussagen helfen mir, Bandbreiten und Verkehr auf Linux-Servern zielgerichtet zu kontrollieren und dauerhaft planbar zu machen.<\/p>\n<ul>\n  <li><strong>Priorisierung<\/strong> zeitkritischer Flows senkt Latenz und Jitter.<\/li>\n  <li><strong>Rate-Limits<\/strong> und Throttling vermeiden Bursts und Pufferstaus.<\/li>\n  <li><strong>HTB\/SFQ<\/strong> verteilen Bandbreite fair und halten Klassen konstant.<\/li>\n  <li><strong>QoS-Filter<\/strong> steuern nach IP, Port, Protokoll oder Markierungen.<\/li>\n  <li><strong>Monitoring<\/strong> via P95 und Alerts deckt Engp\u00e4sse fr\u00fch auf.<\/li>\n<\/ul>\n<p>Diese Punkte baue ich schrittweise auf, messe Effekte kontinuierlich und passe Klassen sowie Raten an reale Nutzung an.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/04\/server-optimierung-linux-8724.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Was Bandwidth Shaping konkret bedeutet<\/h2>\n\n<p>Beim Shaping reguliere ich den <strong>Paketfluss<\/strong> aktiv, statt nur reaktiv zu drosseln. Ich halte Raten konstant, priorisiere Echtzeit- und Interaktiv-Verkehr und gl\u00e4tte unregelm\u00e4\u00dfige Datenbursts. Dazu setze ich auf Rate Limiting f\u00fcr ausgehenden Traffic und Throttling f\u00fcr eingehenden Datenstrom. Diese Trennung schafft klare Zust\u00e4ndigkeiten pro Richtung und verhindert vollgelaufene Puffer. F\u00fcr Hosting-Umgebungen stelle ich pro Kunde oder Anwendung definierte Obergrenzen ein, damit eine Lastspitze nicht das gesamte System ausbremst.<\/p>\n\n<h2>Traffic Control in Linux: Werkzeuge und Konzepte<\/h2>\n\n<p>Unter Linux steuere ich Verkehr mit dem Tool <strong>tc<\/strong> und den Kernel-Queuing-Disziplinen (qdisc). Typische Bausteine sind Wurzel-qdisc, Klassen und Filter, die die Zuordnung von Paketen zu Priorit\u00e4ten und Limits festlegen. Ich starte oft mit HTB als hierarchischem Regler f\u00fcr garantierte und maximale Raten. Erg\u00e4nzend setze ich SFQ f\u00fcr gerechte Verteilung innerhalb einer Klasse ein. So beschr\u00e4nke ich Bandbreite auf 90\u201395 Prozent der physisch m\u00f6glichen Rate, um Burst-Headroom zu behalten und Latenzspitzen zu vermeiden.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/04\/linux_optimierung_4789.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Eingangs\u2011Shaping (Ingress): IFB statt Policer<\/h2>\n\n<p>F\u00fcr eingehenden Verkehr forme ich nicht direkt auf dem physikalischen Interface, sondern nutze ein <strong>IFB<\/strong>-Device (Intermediate Functional Block). Ich spiegele Ingress-Pakete auf das IFB und behandle sie dort wie ausgehenden Traffic \u2013 inklusive HTB-Hierarchie, Fairness und Limits. Das ist <em>feiner<\/em> als ein reiner Policer, der nur hart verwirft und oft Jitter erh\u00f6ht.<\/p>\n<pre><code>modprobe ifb numifbs=1\nip link add ifb0 type ifb\nip link set dev ifb0 up\n\n# Ingress am PHY aktivieren und auf IFB umlenken\ntc qdisc add dev eth0 handle ffff: ingress\ntc filter add dev eth0 parent ffff: protocol ip u32 match u32 0 0 \\\n  action mirred egress redirect dev ifb0\n\n# Shaping auf dem IFB wie bei Egress\ntc qdisc add dev ifb0 root handle 2: htb default 20\ntc class add dev ifb0 parent 2: classid 2:10 htb rate 40mbit ceil 60mbit\ntc class add dev ifb0 parent 2: classid 2:20 htb rate 20mbit ceil 40mbit\ntc qdisc add dev ifb0 parent 2:10 handle 210: fq_codel\ntc qdisc add dev ifb0 parent 2:20 handle 220: sfq\n<\/code><\/pre>\n<p>Mit IFB gewinne ich Kontrolle \u00fcber Download-Peaks, etwa wenn Backup- oder Mirror-Jobs eingehend Bandbreite binden. In der Praxis richte ich IFB auf Schnittstellen mit stark asymmetrischen Raten (z.\u202fB. 1G\/200M) oder wo eingehende Bursts Interaktivit\u00e4t gef\u00e4hrden.<\/p>\n\n<h2>HTB, TBF und SFQ im Vergleich<\/h2>\n\n<p>F\u00fcr die richtige Wahl der <strong>qdisc<\/strong> schaue ich auf Anwendungsziele: Garantien, Burst-Verhalten und Fairness. HTB bietet hierarchische Klassen mit festen und maximalen Raten, TBF begrenzt streng per Token-Bucket, SFQ verteilt Chancen \u00fcber Flows. In Kombination bilden sie in der Praxis ein belastbares Ger\u00fcst: HTB deckelt und garantiert, SFQ verhindert Dominanz einzelner Verbindungen, TBF b\u00e4ndigt hartn\u00e4ckige Bursts. Die folgende Tabelle fasst Kernmerkmale f\u00fcr typische Server-Szenarien zusammen. So entscheide ich schneller, welche Disziplin an welcher Stelle Sinn ergibt.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>qdisc\/Feature<\/th>\n      <th>Zweck<\/th>\n      <th>St\u00e4rken<\/th>\n      <th>Typischer Einsatz<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>HTB<\/td>\n      <td><strong>Hierarchie<\/strong> und Rate-Kontrolle<\/td>\n      <td>Garantierte Rate, Obergrenze, Vererbung<\/td>\n      <td>Mandanten, Service-Klassen, QoS-Profile<\/td>\n    <\/tr>\n    <tr>\n      <td>TBF<\/td>\n      <td><strong>Striktes<\/strong> Deckeln<\/td>\n      <td>Einfach, sehr deterministisch<\/td>\n      <td>Uplink-Cap, harte App-Limits<\/td>\n    <\/tr>\n    <tr>\n      <td>SFQ<\/td>\n      <td><strong>Fairness<\/strong> je Flow<\/td>\n      <td>Geringe Overhead, gute Verteilung<\/td>\n      <td>Downloads, P2P, viele Sessions<\/td>\n    <\/tr>\n    <tr>\n      <td>FQ_CoDel<\/td>\n      <td><strong>AQM<\/strong> gegen Bufferbloat<\/td>\n      <td>Niedrige Latenz, Queue-Entsch\u00e4rfung<\/td>\n      <td>Edge-Router, Latenz-kritische Links<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>F\u00fcr Zug\u00e4nge mit deutlich schwankenden RTTs nutze ich FQ_CoDel oder \u2013 je nach Kernel \u2013 auch CAKE als Allrounder. In der Serverpraxis bleibe ich jedoch bei HTB+SFQ\/FQ_CoDel, weil ich damit Garantien, Borrowing und faire Verteilung sauber in einer Hierarchie kombiniere.<\/p>\n\n<h2>Praxis: tc-Regeln f\u00fcr typische Server<\/h2>\n\n<p>Ich beginne mit einer einfachen <strong>HTB<\/strong>-Struktur und ordne danach per Filter zu. Eine Wurzel-qdisc mit Default-Klasse f\u00e4ngt unklassifizierte Pakete, priorisierte Klassen erhalten garantierte Raten. Danach verfeinere ich die Filter: HTTP\/S auf Klasse A, Datenbank-Replikation auf Klasse B, Backups auf Klasse C. So bleiben Shop-Requests schnell, w\u00e4hrend Backups die Reste nutzen. F\u00fcr Grundlagen und Wortschatz verweise ich auf diesen Einstieg zu <a href=\"https:\/\/webhosting.de\/bandbreiten-management-webhosting-grundlagen-trafficboost\/\">Bandbreiten-Management<\/a>, der das Vorgehen greifbar macht.<\/p>\n<pre><code>tc qdisc add dev eth0 root handle 1: htb default 20\ntc class add dev eth0 parent 1: classid 1:10 htb rate 50mbit ceil 70mbit\ntc class add dev eth0 parent 1: classid 1:20 htb rate 20mbit ceil 50mbit\ntc class add dev eth0 parent 1: classid 1:30 htb rate 10mbit ceil 30mbit\ntc qdisc add dev eth0 parent 1:10 handle 110: sfq\ntc qdisc add dev eth0 parent 1:20 handle 120: sfq\ntc qdisc add dev eth0 parent 1:30 handle 130: sfq\ntc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dport 443 0xffff flowid 1:10\ntc filter add dev eth0 protocol ip parent 1:0 prio 2 u32 match ip dport 3306 0xffff flowid 1:20\ntc filter add dev eth0 protocol ip parent 1:0 prio 3 u32 match ip sport 22 0xffff flowid 1:30\n<\/code><\/pre>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/04\/bandwidth-traffic-control-linux-8421.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Klassifizierung mit DSCP und Marks (IPv4\/IPv6\u2011tauglich)<\/h2>\n\n<p>Damit Filter unabh\u00e4ngig von IP-Version und NAT greifen, markiere ich Pakete fr\u00fch und mappe dann per <strong>fwmark<\/strong> in Klassen. So spare ich komplexe u32-Matches und halte Regeln schlank. DSCP nutze ich zus\u00e4tzlich f\u00fcr End-to-End-Semantik, z.\u202fB. f\u00fcr VoIP oder Interaktivit\u00e4t.<\/p>\n<pre><code># Beispiel mit nftables: TLS priorisieren, Backups drosseln\nnft add table inet mangle\nnft add chain inet mangle prerouting { type filter hook prerouting priority -150; }\nnft add rule inet mangle prerouting tcp dport 443  meta mark set 10\nnft add rule inet mangle prerouting tcp dport 22   meta mark set 30\nnft add rule inet mangle prerouting tcp dport 873  meta mark set 40  # rsync\/Backups\n\n# Mapping in HTB-Klassen (wirken f\u00fcr IPv4\/IPv6 gleicherma\u00dfen)\ntc filter add dev eth0 parent 1:0 prio 1 handle 10 fw flowid 1:10\ntc filter add dev eth0 parent 1:0 prio 2 handle 30 fw flowid 1:30\ntc filter add dev eth0 parent 1:0 prio 3 handle 40 fw flowid 1:20\n<\/code><\/pre>\n<p>Wichtig: DSCP\/Markierungen setze ich m\u00f6glichst <em>am Rand<\/em> (Eingang der Maschine oder davor), damit sp\u00e4tere Entscheidungen schnell fallen und tc unter Last weniger Arbeit hat.<\/p>\n\n<h2>QoS-Strategien f\u00fcr Hosting: Fairness und Limits<\/h2>\n\n<p>In Multi-Tenant-Setups sichere ich <strong>Fairness<\/strong> \u00fcber feste Garantien pro Kunde und Caps pro Anwendung. Ich markiere Pakete per DSCP oder nach Ports und weise sie passenden Klassen zu. Downloads und Backups d\u00fcrfen Kapazit\u00e4t f\u00fcllen, w\u00e4hrend interaktive Sessions bevorzugt laufen. Auf diese Weise bleiben SLA-relevante Dienste priorisiert, ohne andere Mieter auszuschlie\u00dfen. Praktische Szenarien und Priorisierungslogik fasse ich in diesem \u00dcberblick zu <a href=\"https:\/\/webhosting.de\/https-webhosting-de-traffic-priorisierung-bandwidth-management-netzwerk-optimierung\/\">Traffic-Priorisierung<\/a> zusammen, der gut zu tc-Regeln passt.<\/p>\n\n<h2>Persistenz und Automatisierung<\/h2>\n\n<p>Meine QoS-Policies \u00fcberleben Reboots und Interface-Neustarts. Ich hinterlege tc-Befehle als idempotentes Skript und binde es in systemd oder netplan\/networkd ein. F\u00fcr Ger\u00e4te mit dynamischen Namen (z.\u202fB. veth\/tap) nutze ich udev-Regeln oder systemd-Templates.<\/p>\n<pre><code># \/usr\/local\/sbin\/tc-setup.sh (idempotent bauen)\n#!\/bin\/sh\ntc qdisc replace dev eth0 root handle 1: htb default 20\n# ... weitere Klassen\/Filter hier\n\n# systemd unit: \/etc\/systemd\/system\/tc-setup.service\n[Unit]\nDescription=Traffic Control Setup\nAfter=network-online.target\nWants=network-online.target\n\n[Service]\nType=oneshot\nExecStart=\/usr\/local\/sbin\/tc-setup.sh\nRemainAfterExit=yes\n\n[Install]\nWantedBy=multi-user.target\n<\/code><\/pre>\n<p>\u00c4nderungen rolle ich kontrolliert aus: erst auf Staging, dann zeitlich begrenzt im Produktivsystem (<code>tc replace<\/code> statt <code>add<\/code>), begleitet von Metriken und einem Rollback-Knopf.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/04\/linux_trafficcontrol_3841.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Monitoring, P95 und Fehlersuche ohne Frust<\/h2>\n\n<p>Ich messe Effekte fortlaufend, statt mich auf <strong>Bauchgef\u00fchl<\/strong> zu verlassen. P95-Latenzen, Queue-L\u00e4ngen und Paketverluste zeigen, ob Regeln greifen oder zu streng wirken. Tools wie iftop, vnStat und Netdata machen Lastspitzen sichtbar, Logs von tc und iptables zeigen die Zuordnung. Tritt Jitter auf, reduziere ich Ceil-Werte leicht und pr\u00fcfe CoDel\/FQ_CoDel als AQM-Ma\u00dfnahme. Bei Engp\u00e4ssen passe ich Klassengewichte schrittweise an und halte nach jeder \u00c4nderung Messfenster ein.<\/p>\n\n<h2>Testmethodik: Lastsimulation und Verifikation<\/h2>\n\n<p>Ich simuliere realistische Szenarien: ein Dauerstrom (iperf3), parallel dazu kurze Interaktionen (kleine HTTP-Requests) und periodische Bursts (Backup\/rsync). Danach pr\u00fcfe ich, ob interaktive Flows konstant niedrige Latenz halten und Bursts sauber gegl\u00e4ttet werden.<\/p>\n<pre><code># Gegenrichtung testen (Download\/Ingress)\niperf3 -c &lt;server&gt; -R -t 60\n\n# Shaping-Statistiken lesen\ntc -s qdisc show dev eth0\ntc -s class show dev eth0\n\n# Jitter\/RTT-Verteilung pr\u00fcfen\nping -i 0.2 -c 100 &lt;ziel&gt; | awk '\/time=\/{print $7}'<\/code><\/pre>\n<p>Wenn Klassen dauerhaft Borrows ben\u00f6tigen, erh\u00f6he ich garantierte Raten leicht. H\u00e4ufen sich Drops in AQM-Queues, pr\u00fcfe ich Puffergr\u00f6\u00dfen und ob Limits zu aggressiv gesetzt sind.<\/p>\n\n<h2>Performance-Tuning: 90\u201395 % Deckel, Burst-Gl\u00e4ttung, MTU<\/h2>\n\n<p>Ich limitiere die Ausgaberate auf <strong>90\u201395%<\/strong> des Link-Speeds, um Pufferbloat zu vermeiden und AQM wirken zu lassen. Bursts gl\u00e4tte ich mit Token-Bucket-Parametern (rate, burst\/latency), damit kurzzeitige Spitzen nicht ganze Queues f\u00fcllen. Die MTU \u00fcberpr\u00fcfe ich, um Fragmentierung zu reduzieren und Path-MTU-Probleme zu vermeiden. Bei stark schwankenden Workloads lege ich gro\u00dfz\u00fcgige Ceil-Werte fest, aber konservative garantierte Raten. Dieses Setup h\u00e4lt Prior-Verkehr schnell, w\u00e4hrend Hintergrundprozesse neutral weiterlaufen.<\/p>\n\n<h2>Hardware\u2011Offloads, Multiqueue und IRQ\u2011Tuning<\/h2>\n\n<p>F\u00fcr pr\u00e4zises Shaping auf schnellen Links kenne ich das Zusammenspiel mit NIC\u2011Offloads. TSO\/GSO\/GRO beschleunigen zwar, k\u00f6nnen aber bei sehr niedrigen Zielraten die Feink\u00f6rnigkeit verschlechtern. F\u00fcr sensible Links schalte ich testweise TSO\/GSO ab und messe Latenz\/CPU-Gewinn gegen. Auf Multiqueue\u2011NICs setze ich eine <strong>mq<\/strong>-Wurzel-qdisc und konfiguriere darunter pro Queue HTB oder FQ_CoDel. CPU\u2011Last verteile ich mit RPS\/XPS und IRQ\u2011Pinning, damit QoS-Arbeit nicht auf einer CPU verhungert.<\/p>\n<pre><code># Offloads selektiv testen (vorsichtig in Produktion)\nethtool -K eth0 tso off gso off gro off\n\n# Multiqueue-Layout\ntc qdisc add dev eth0 root handle 1: mq\ntc qdisc add dev eth0 parent 1:1 handle 10: htb default 20\ntc qdisc add dev eth0 parent 1:2 handle 20: htb default 20\n# ... pro Queue weiterf\u00fchren und Klassen\/Filter wie gewohnt setzen\n<\/code><\/pre>\n<p>Mit <code>txqueuelen<\/code>, Ringpuffergr\u00f6\u00dfen und IRQ\u2011Affinity trimme ich die Latenz weiter. Ziel ist ein stabiler, kurzer Queue\u2011Pfad, der unter Last nicht kippt.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/04\/server_traffic_control_8234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Sicherheit und Segmentierung: Shaping mit Firewall und VLAN<\/h2>\n\n<p>Ich kombiniere QoS mit <strong>Segmentierung<\/strong>, damit kritische Netze eigene Kapazit\u00e4ten behalten. Pro VLAN oder Interface setze ich eigene Queues, Firewalls markieren bereits beim Eintritt in den Server. So muss tc weniger Entscheidungen unter Last treffen, weil Pakete fr\u00fch klassifiziert sind. Backups aus dem Storage-VLAN bleiben auf ihrer Bahn, w\u00e4hrend Frontend-HTTP nicht verhungert. Die Trennung verk\u00fcrzt zudem Fehleranalysen, weil Flows eindeutiger zuordenbar sind.<\/p>\n\n<h2>Virtualisierung und Container: Wo ich forme<\/h2>\n\n<p>In KVM\/virtio\u2011Setups forme ich am bevorzugten <em>Edge<\/em>: am Bridge\u2011Interface (br0), am physischen Uplink (eth0) oder gezielt pro Gast auf dessen vnet\u2011Interface. Pro\u2011Tenant\u2011Garantien setze ich gern auf vnetX um, globale Caps auf dem Uplink. In Kubernetes ist tc an veth\u2011Peers oder Node\u2011Uplinks praktikabel; Markierungen vergebe ich fr\u00fch per CNI\/iptables\/nftables, damit die Zuteilung deterministic bleibt. F\u00fcr SR\u2011IOV oder DPDK achte ich darauf, dass die Datenpfade tc \u00fcberhaupt noch durchlaufen \u2013 sonst forme ich davor oder nutze NIC\u2011eigene Rate\u2011Limiter.<\/p>\n\n<h2>Kosten und Nutzen: Effizienz statt Hardware-Upgrade<\/h2>\n\n<p>Mit sauberem <strong>Shaping<\/strong> sch\u00f6pfe ich vorhandene Leitungen besser aus und spare h\u00e4ufig teure Upgrades. Weniger Paketverluste und geringere Latenz steigern die Nutzererfahrung direkt. In Hosting-Umgebungen zahlt sich das doppelt aus, weil faire Limits Eskalationen zwischen Mandanten verhindern. Ich sehe in der Praxis, dass stabile Raten den Durchsatz erh\u00f6hen, da Retransmits sinken. Diese Effekte schlagen sich am Ende in klareren SLAs und weniger Supportf\u00e4llen nieder.<\/p>\n\n<h2>H\u00e4ufige Stolperfallen und schnelle Checks<\/h2>\n\n<ul>\n  <li>Unpassende Einheiten: Ich pr\u00fcfe, ob <code>mbit<\/code> und <code>kbit<\/code> korrekt geschrieben sind und Burst\/Latency zur MTU passen.<\/li>\n  <li>Priorit\u00e4tsumkehr: Zu viele High\u2011Priority\u2011Klassen ohne echte Begrenzung f\u00fchren zu Starvation der Defaults. Ich halte Obergrenzen strikt ein.<\/li>\n  <li>NAT\/IPv6 \u00fcbersehen: Port\u2011Filter greifen nach NAT\/IPv6 nicht wie gedacht. Ich markiere fr\u00fch (fwmark) und mappe dann in Klassen.<\/li>\n  <li>Ceil kleiner als Rate: Ein h\u00e4ufiger Tippfehler, der Borrowing blockiert. Ich validiere jede Klasse mit <code>tc -s class<\/code>.<\/li>\n  <li>Ingress nur gepolicet: Hartes Droppen erzeugt Jitter. Mit IFB forme ich feiner und gerechter.<\/li>\n  <li>Offloads verf\u00e4lschen Messung: Ich dokumentiere den Offload\u2011Zustand bei jedem Test und vergleiche \u00c4pfel mit \u00c4pfeln.<\/li>\n<\/ul>\n\n<h2>Zukunftsausblick: KI-gest\u00fctzte Reservierung und adaptive Policies<\/h2>\n\n<p>Ich nutze Trends wie <strong>Vorhersagen<\/strong> auf Basis historischer Last, um Klassen kurz vor Peak-Zeiten dynamisch anzupassen. Lernende Modelle reservieren Bandbreite f\u00fcr VoIP- oder Checkout-Phasen, bevor Warteschlangen wachsen. In hybriden Netzen zwischen Cloud und On-Prem greife ich auf tempor\u00e4re Caps und Burst-Budgets zur\u00fcck, die Policies per Zeitplan wechseln. Das reduziert operative Eingriffe und h\u00e4lt Services auch bei Sonderevents berechenbar. Tieferes Hintergrundwissen zu Skalierung und Limits b\u00fcndele ich hier: <a href=\"https:\/\/webhosting.de\/traffic-management-hosting-limits-bursts-priorisierung-scaleup\/\">Traffic-Management und Hosting-Limits<\/a>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/04\/serverraum-optimierung-8293.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Kurzfassung &#038; Checkliste<\/h2>\n\n<p>Ich setze zuerst eine klare <strong>Hierarchie<\/strong> mit HTB auf, vergebe Garantien und halte Ceil leicht unter Link-Speed. Danach klassifiziere ich nach Diensten, Protokollen oder DSCP und pr\u00fcfe Latenz, Jitter sowie P95-Werte. SFQ oder FQ_CoDel sorge ich f\u00fcr faire Verteilung und kurze Queues. Monitoring begleitet jede \u00c4nderung, damit ich \u00fcber Effekte entscheide statt zu raten. So bleibt Bandwidth Shaping kein einmaliger Akt, sondern ein schlanker Regelkreis, der Serververkehr sicher und kalkulierbar h\u00e4lt.<\/p>","protected":false},"excerpt":{"rendered":"<p>Les serveurs Bandwidth Shaping et Traffic Control Linux optimisent les r\u00e9seaux : priorisez le trafic, fixez des limites d'h\u00e9bergement et am\u00e9liorez la qualit\u00e9 de service.<\/p>","protected":false},"author":1,"featured_media":19114,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-19121","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-server_vm"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"94","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"Bandwidth Shaping","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"19114","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/19121","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/comments?post=19121"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/19121\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media\/19114"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media?parent=19121"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/categories?post=19121"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/tags?post=19121"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}