Quelle est la différence entre latency, bandwidth et throughput ?

Question

IT Interview Practice · Accepted Answer

Ces trois notions décrivent des choses différentes et sont constamment confondues. La **latency** est le *délai* — combien de temps une unité de données met pour aller de A à B (mesurée en temps, par ex. ms). La **bandwidth** est la *capacité* — le débit de données maximal qu'un lien peut porter (par ex. Gbps). Le **throughput** est le débit *réel* que vous atteignez en pratique, généralement en dessous de la bandwidth. Une analogie de tuyau la rend évidente :

```text
   ├────────────── length of pipe = LATENCY (how long to traverse) ─────────────┤
   ╔══════════════════════════════════════════════════════════════════════════╗
   ║  width of pipe = BANDWIDTH (max capacity)                                  ║
   ║  water actually flowing = THROUGHPUT (real achieved rate ≤ bandwidth)      ║
   ╚══════════════════════════════════════════════════════════════════════════╝
```

Point crucial : **un tuyau plus large ne le rend pas plus court** : ajouter de la bandwidth ne réduit pas la latency. Un gros lien transatlantique a toujours ~80 ms de latency aller-retour dictée par la distance et la vitesse de la lumière — vous ne pouvez pas payer pour passer en dessous. C'est pourquoi la latency, et non la bandwidth, domine le ressenti des applications interactives : chaque aller-retour (DNS, handshake TCP, TLS, puis la requête) paie le péage de la latency, et ils s'additionnent.

La latency et le throughput interagissent via le **Bandwidth-Delay Product** (BDP = bandwidth × round-trip time), la quantité de données « en vol » nécessaire pour garder un tuyau plein. Sur un « long fat network » à haute bandwidth et haute latency, un protocole comme TCP qui attend des ACK ne peut pas remplir le tuyau à moins que sa fenêtre soit au moins égale au BDP — donc le throughput finit par être *limité par la latency*, pas par la bandwidth. C'est pourquoi un seul stream TCP sur une longue distance sous-performe souvent même sur un lien rapide, et pourquoi le parallélisme, des fenêtres plus grandes et les CDN (qui réduisent la distance, donc la latency) aident.

## Pourquoi c'est important

Confondre ces trois notions est l'une des erreurs de performance les plus courantes — et les plus lourdes de conséquences : des équipes achètent plus de bandwidth pour corriger ce qui est en réalité un problème de latency, et ne voient aucune amélioration. L'intuition senior est que **la latency est un plancher fixé par la physique** (la distance) que l'on attaque de façon architecturale — rapprocher serveurs/CDN des utilisateurs, réduire les allers-retours (réutilisation de connexion, HTTP/3, caching) et grouper les requêtes — tandis que la bandwidth est souvent quelque chose que l'on peut simplement provisionner. Comprendre le BDP explique des résultats contre-intuitifs comme un lien « rapide » livrant des transferts en flux unique lents, exactement le genre de raisonnement attendu quand vous concevez ou déboguez des systèmes hautement performants et répartis géographiquement.

Pourquoi c'est important

Questions connexes