Le contrôle de congestion TCP détermine comment les connexions sont gérées en cas de variation charge du réseau ajuster le débit de données et comment les algorithmes se comportent dans des configurations d'hébergement réelles. Dans cette comparaison, je montre les effets concrets sur le débit, le retard et l'équité pour Hébergement web, le streaming et les charges de travail dans le cloud.
Points centraux
Pour que tu puisses lire cet article de manière ciblée, je vais résumer brièvement les aspects essentiels, puis les replacer dans leur contexte. Je fais une distinction claire entre les procédures basées sur les pertes et celles basées sur les modèles, car ces deux familles réagissent de manière très différente. J'explique pourquoi cwnd, RTT et Pacing ont une incidence sur les performances et Équité décider. Je classe les résultats des mesures afin que tu ne prennes pas de décisions instinctives. Je conclus par des recommandations pragmatiques pour l'hébergement, les conteneurs et les Utilisateur.
- AIMD contrôle cwnd et réagit aux pertes
- CUBIC offre des performances constantes avec des RTT élevés
- BBR utilise un modèle, réduit les files d'attente et la latence
- BIC marque des points dans les filets avec des drops
- Hybla accélère les longues lignes (satellite)
Ce que contrôle le Congestion Control : cwnd, RTT, signaux de perte
Je commence par les bases, car elles influencent tous les choix ultérieurs. La fenêtre de congestion (cwnd) limite le nombre d'octets en transit sans confirmation, et AIMD augmente progressivement cwnd jusqu'à ce que des pertes surviennent. RTT détermine la vitesse à laquelle les confirmations reviennent et l'agressivité avec laquelle un algorithme peut croître. Auparavant, les signaux de perte provenaient des délais d'attente et des ACK triples dupliqués. Aujourd'hui, la profondeur de la file d'attente, le RTT minimal et la bande passante mesurée en cas d'engorgement sont également pris en compte. Comprendre cwnd, RTT et l'interprétation des pertes permet d'évaluer leur influence sur le débit, le retard et Jitter Tout de suite mieux.
Rétrospective : Reno, NewReno et Vegas au quotidien
Reno utilise Slow Start au début, puis passe à des augmentations linéaires, mais réduit considérablement la taille de la fenêtre après des pertes. NewReno répare plus efficacement plusieurs pertes par fenêtre, ce qui est particulièrement utile lorsque les taux d'erreur sont modérés. Vegas mesure le débit attendu par rapport au débit réel via le RTT et ralentit tôt pour éviter les pertes. Cette prudence permet de réduire les files d'attente, mais coûte en débit lorsque les flux basés sur les pertes envoient de manière plus agressive en parallèle. Si vous constatez des délais d'attente inexpliqués ou des ACK en double, vous devez d'abord Analyser les pertes de paquets puis l'algorithme pour Topologie Choisissez celui qui convient.
High-BW-RTT : comparaison entre BIC et CUBIC
BIC s'approche de manière binaire du cwnd sans perte le plus élevé et maintient le débit étonnamment constant, même en cas d'erreurs légères. Dans les laboratoires à faible latence et avec des taux de perte d'environ 10^-4, BIC a fourni des débits supérieurs à 8 Gbit/s, tandis que les algorithmes classiques ont fluctué. CUBIC a remplacé BIC comme norme, car il contrôle son cwnd via une fonction temporelle cubique et exploite ainsi mieux les RTT longs. Après un événement de perte, la courbe augmente d'abord modérément, puis s'accélère sensiblement et redevient prudente à proximité du dernier débit maximal. Dans les réseaux à longue distance, j'obtiens souvent une utilisation plus élevée avec CUBIC tout en conservant une bonne Planification des latences.
Basé sur un modèle : BBR, pacing et bufferbloat
BBR utilise un modèle basé sur un RTT minimal et une bande passante de goulot d'étranglement mesurée, définit cwnd à environ le double du produit bande passante-retard et échelonne les paquets de manière uniforme. Cette stratégie évite les files d'attente trop longues et réduit les retards, même en cas de pertes légères. Dans les configurations où la qualité radio est variable ou les chemins mixtes, le goodput reste élevé car BBR ne réagit pas de manière réflexive à chaque perte. La version 1 est considérée comme très rapide, mais peut rivaliser avec CUBIC dans les petits tampons, tout en affichant une répartition quelque peu inéquitable. Je combine BBR dans Hébergement BBR CUBIC Je préfère les paysages pour les flux primaires et j'utilise CUBIC comme solution de secours compatible.
Satellite et radio : Hybla, Westwood et PCC
Hybla compense les inconvénients des RTT élevés en ajustant cwnd comme s'il s'agissait d'un RTT de référence court. Ainsi, les longues distances, comme les satellites, atteignent beaucoup plus rapidement des débits utilisables et restent stables. Westwood estime la bande passante disponible à partir des débits ACK et réduit moins fortement cwnd après des pertes, ce qui est utile dans les réseaux radio avec des erreurs aléatoires. PCC va encore plus loin et optimise une valeur d'utilité à travers de courtes expériences, ce qui lui permet d'atteindre des combinaisons élevées de goodput et de latence. Dans les réseaux hétérogènes avec Mobilité Je préfère tester Hybla et Westwood avant de me lancer dans des règles QoS complexes.
Comparaison des performances : valeurs mesurées et équité
Les comparaisons montrent des profils très différents lorsque la latence et les taux d'erreur varient. Avec un RTT faible, BIC domine souvent la course au débit pur, tandis que CUBIC offre un mélange fiable de débit et de comportement dans le temps. Avec des RTT très longs, CUBIC marque clairement des points par rapport à Reno et NewReno, car il traduit mieux les temps d'attente en croissance. BBR maintient les files d'attente vides et fournit des retards constamment faibles, mais génère davantage de retransmissions en fonction de la taille du tampon. Pour les flux parallèles, CUBIC affiche généralement une répartition équitable, tandis que BIC maintient volontiers la ligne proche de la Capacité.
| Algorithme | Principe | Force | faiblesse | Recommandé pour |
|---|---|---|---|---|
| Reno / NewReno | Basé sur les pertes, AIMD | Comportement simple | Lent avec un RTT élevé | Piles héritées, Dépannage |
| Las Vegas | Basé sur RTT | Prévention précoce des embouteillages | Débit réduit | Latence constante |
| BIC | Recherche binaire | Goodput élevé lors des drops | Agressif envers les autres | Faible RTT, taux d'erreur |
| CUBIC | Fonction temporelle cubique | Bonne équité | Dispersion des gouttes | Longs chemins, centres de données |
| BBR | Basé sur un modèle, pacing | Faible latence | Injuste dans les petits tampons | Hébergement, utilisateurs mondiaux |
| Hybla | Compensation RTT | Accélération rapide | Caractère particulier | Satellite, Maritime |
Guide pratique : sélection en fonction de la latence, de la perte et de la cible
Je commence chaque décision avec des objectifs clairs : faible latence, débit utile maximal ou équilibre pour de nombreux flux. Lorsque les tailles de tampon sont très limitées et que les exigences en matière de latence sont sensibles, je commence par utiliser BBR. Lorsque les chemins longs dominent et que plusieurs hôtes coexistent, CUBIC est incontournable. Dans les réseaux présentant des modèles de perte facilement observables, BIC continue d'offrir des débits impressionnants, à condition que l'équité soit secondaire. Pour les satellites et les coûts de chemin RTT très élevés, Hybla élimine les inconvénients typiques de la montée en puissance et garantit une rapidité charge utile.
Linux, Windows et conteneurs : activation et optimisation
Sous Linux, je vérifie l'algorithme actif avec sysctl net.ipv4.tcp_congestion_control et je le mets en œuvre de manière ciblée avec sysctl net.ipv4.tcp_congestion_control=bbr. Pour CUBIC, je respecte les paramètres par défaut du noyau, mais j'ajuste net.core.default_qdisc et les paramètres de cadencement lorsque je désamorce les files d'attente hôtes. Dans les conteneurs, je transfère les paramètres vers l'hôte, car les espaces de noms n'isolent pas toutes les files d'attente. Sous Windows, à partir des versions actuelles, BBR peut être activé dans les éditions appropriées, tandis que les systèmes plus anciens continuent d'utiliser CUBIC ou Compound. Sans un système solide et QueueSans ces paramètres, chaque algorithme perd considérablement de son efficacité.
Perspective de l'hébergement web : équité multi-flux et goodput
Dans les clusters d'hébergement, c'est la somme de nombreux flux simultanés qui compte, et non la valeur optimale d'un seul transfert. CUBIC maintient la prévisibilité des connexions et répartit généralement la capacité de manière équitable, ce qui favorise les scénarios multi-locataires denses. BBR réduit les files d'attente et maintient des temps de réponse courts pour les API et les sites Web dynamiques. Si vous tenez compte de la surcharge du protocole, vous devriez tester le transport avec les versions HTTP ; mon point de départ est HTTP/3 vs. HTTP/2 en combinaison avec le procédé CC choisi. Pour les utilisateurs internationaux, je préfère les pics de latence faibles, car le temps de réponse influe directement sur la perception Rapidité marqué.
QUIC et BBR : influence au-delà du TCP
QUIC intègre son propre contrôle des encombrements basé sur UDP et utilise des principes similaires à ceux de BBR, tels que le pacing et l'observation RTT. Dans les piles modernes, les performances se déplacent ainsi progressivement du TCP vers la couche application. Cela augmente la liberté, mais nécessite des mesures précises au niveau du chemin, de l'hôte et de l'application. Pour la planification, je recommande d'utiliser le Protocole QUIC sous des profils de charge réels par rapport à CUBIC/BBR‑TCP. Cela me permet de détecter rapidement où se forment les files d'attente et comment je peux éliminer les goulots d'étranglement grâce au pacing ou modelage lisse.
AQM, ECN et discipline de tampon : interaction avec les algorithmes
Le contrôle des embouteillages ne déploie pleinement ses effets qu'en combinaison avec la gestion des files d'attente des périphériques réseau. Le Tail Drop classique remplit les tampons à ras bord, puis rejette brusquement les paquets, ce qui entraîne des pics de latence et des effets de synchronisation. La gestion active des files d'attente (AQM) telle que CoDel ou FQ-CoDel marque ou rejette les paquets à un stade précoce et répartit la capacité de manière plus équitable entre les flux. Cela profite à tous les processus : CUBIC perd moins de cwnd à cause des burst drops, et BBR conserve son rythme cardiaqueStratégie plus stable, car les files d'attente ne „ débordent “ pas.
L'ECN (Explicit Congestion Notification) complète ce tableau. Au lieu de rejeter les paquets, les routeurs marquent les encombrements avec un bit CE ; les terminaux réduisent le débit sans qu'il soit nécessaire de procéder à des retransmissions. Les algorithmes basés sur les pertes réagissent ainsi plus tôt et plus doucement, tandis que les méthodes basées sur des modèles, telles que BBR, interprètent les signaux dans le contexte du RTT minimal. Dans les centres de données, le DCTCP avec ECN cohérent permet des délais de mise en file d'attente très faibles en cas de charge élevée. Dans le WAN, j'utilise l'ECN de manière sélective : uniquement lorsque les chemins transmettent les marquages de manière cohérente et que les boîtiers intermédiaires n'interviennent pas. Dans les réseaux publics mixtes, il convient toujours de configurer correctement l'AQM plutôt que de simplement augmenter la taille des tampons.
Bursts, déchargements et cadence côté hôte
De nombreuses baisses de performances sont dues à des rafales d'envoi sur l'hôte. Les déchargements importants (TSO/GSO) regroupent les segments dans des trames très volumineuses ; sans rythme cardiaque ces paquets se déchargent en pics courts et remplissent les files d'attente du commutateur. Sous Linux, je définis donc sch_fq ou FQ-CoDel comme default_qdisc et j'utilise les taux de régulation spécifiés par l'algorithme CC. BBR en profite particulièrement, mais CUBIC devient également plus stable. Des tampons NIC Ring trop grands et un txqueuelen trop élevé allongent les files d'attente dans l'hôte. Je choisis des valeurs modérées et observe avec tc -s qdisc si des drops ou des marques ECN y apparaissent.
Du côté réception, GRO/LRO influencent la latence des petits flux. Pour les charges de travail API, il est utile de tester ou de limiter ces déchargements en fonction de la carte réseau et du noyau afin que les ACK soient traités plus rapidement. Dans les configurations de conteneurs, je vérifie les paires veth et les Qdiscs hôtes : la file d'attente se trouve sur l'interface hôte, et non dans l'espace de noms. Si vous utilisez des cgroups pour la gestion de la bande passante, vous devez définir des limites cohérentes avec CC et AQM, sinon des interférences imprévisibles entre les flux peuvent se produire.
Profils de charge de travail : flux courts, éléphants et streaming
Toutes les applications ne nécessitent pas le même contrôle des embouteillages. Les flux „ Mice “ (petits transferts) dominent les API Web et les pages dynamiques. Ce qui compte ici, c'est la rapidité avec laquelle la connexion entre en phase d'utilisation et le faible niveau des latences de queue. BBR maintient les files d'attente à un niveau bas et favorise les flux de courte durée, tandis que CUBIC fournit des valeurs moyennes solides avec une répartition équitable des capacités. La taille initiale de la fenêtre (initcwnd) et les paramètres Delayed-ACK influencent les premiers RTT : les valeurs par défaut conservatrices protègent contre les pics, mais ne doivent pas trop ralentir les premiers kilo-octets.
„Les flux “ Elephant » (sauvegardes, réplication, téléchargements volumineux) exigent une charge stable sur de longues périodes. CUBIC s'adapte de manière robuste à différents RTT et partage équitablement les flux parallèles. BIC fournit des débits maximaux dans des réseaux contrôlés avec des modèles de perte connus, mais présente des inconvénients en cas de coexistence. Pour le streaming en direct et les interactions en temps réel (VoIP, jeux), j'évite systématiquement les files d'attente fixes : BBR reste le premier choix si les tampons sont petits et si AQM est efficace. Les interactions Nagle (TCP_NODELAY) et le traitement par lots des applications jouent un rôle : ceux qui génèrent de nombreuses petites écritures devraient désactiver Nagle de manière ciblée et laisser le pacing se charger du réglage fin.
Méthodologie de mesure : tests réalistes et indicateurs pertinents
Pour prendre les bonnes décisions, il faut des mesures reproductibles. Je combine une charge synthétique avec des conditions de chemin réelles : émulation contrôlée du RTT, de la gigue et des pertes (par exemple sur des liaisons de test) plus des emplacements cibles réels. Je mesure la bande passante en tant que goodput et je la corrèle avec les courbes RTT, les retransmissions et les proportions hors séquence. Les latences P50/P95/P99 en disent plus long que les valeurs moyennes, en particulier pour les temps de réponse API et l'interactivité. Pour TCP, j'examine les courbes cwnd et pacing_rate et je vérifie les statistiques Qdisc côté hôte ainsi que la saturation du CPU afin d'attribuer correctement les goulots d'étranglement.
Les tests individuels peuvent être trompeurs : les flux parallèles par hôte et le trafic croisé créent des situations de concurrence réalistes. L'heure de la journée, les chemins de peering et les conditions radio varient ; je répète les mesures dans des séries chronologiques et vérifie la sensibilité aux petits taux de perte. Pour QUIC, je compare des charges de travail identiques à TCP afin que les niveaux d'application et de transport soient évalués séparément. Ce n'est que lorsque les mesures restent stables en cas de perturbation que je m'engage dans un choix en production.
Erreurs fréquentes et solutions rapides
Une augmentation constante du RTT sous charge accompagnée d'une chute du débit utile indique Bufferbloat Activer AQM, affiner le Host Pacing, utiliser BBR si nécessaire. De nombreuses retransmissions sans modèle de perte clair indiquent un réordonnancement ou une compression ACK – les Qdiscs basés sur FQ et un pacing propre peuvent aider. Des blocages soudains avec des ACK manquants indiquent souvent des problèmes de Path MTU ; j'active le MTU probing et j'applique le MSS clamping aux transitions pertinentes.
Une répartition inéquitable entre les flux apparaît lorsque certaines connexions sont durablement avantagées : CUBIC améliore l'équité RTT par rapport aux anciens algorithmes Loss, BBR nécessite une discipline de tampon rigoureuse ; avec des tampons de petite taille, un ajustement plus fin du rythme ou un retour à CUBIC peut assurer la coexistence. Dans les environnements conteneurisés, des files d'attente „ cachées “ apparaissent aux extrémités veth. Sans limites Qdisc et cgroup coordonnées, les congestions se déplacent vers l'hôte, loin de l'application.
Lignes directrices opérationnelles : décisions relatives à l'équipe et à la plateforme
J'intègre le contrôle des embouteillages dans les normes de la plateforme : paramètres par défaut Qdisc uniformes, profils CC définis par cluster et playbooks pour les écarts. Pour les Utilisateur Je sépare les charges de travail en fonction de leur sensibilité à la latence : priorité aux API frontales avec BBR et AQM strict, transfert en masse avec CUBIC. La télémétrie est obligatoire : distribution RTT, goodput, retransmissions et quotas ECN sous forme de séries chronologiques. L'équipe déploie les modifications à l'aide d'expériences en pourcentage et compare les valeurs P95/P99, et pas seulement les valeurs moyennes. Les décisions CC deviennent ainsi reproductibles et compréhensibles, et ne restent pas une simple intuition.
Liste de contrôle pour la décision
Je commence par vérifier les intervalles RTT et les taux d'erreur, car ils dominent le comportement. Ensuite, je décide si la latence ou le débit est prioritaire et je teste spécifiquement cette métrique. À l'étape suivante, je mesure l'équité avec des flux parallèles afin d'éviter les surprises pendant le fonctionnement. Je vérifie ensuite la taille des tampons, les procédures AQM et les paramètres de cadencement sur l'hôte et les passerelles. Enfin, je valide sous charge si le choix avec des utilisateurs réels et des Itinéraires porte.
Bilan succinct
Reno et NewReno offrent un comportement de référence clair, mais semblent ralentis sur les chemins longs. CUBIC est la norme dans presque tous les hébergements Linux, car il utilise bien les RTT longs et se comporte de manière équitable. BIC est convaincant dans les réseaux présentant des baisses notables, lorsque la charge maximale est plus importante que le voisinage. BBR permet des latences faibles et des temps de réponse constants, mais nécessite une attention particulière pour les tampons et la coexistence. Si vous comparez soigneusement les cibles, les caractéristiques des chemins et les files d'attente des hôtes, vous pouvez utiliser le contrôle de congestion comme un véritable Levier pour l'expérience utilisateur et les coûts.
