Réduire la bande passante grâce à la compression des messages
Réduisez la bande passante WebSocket avec l’extension permessage-deflate et une conception judicieuse des données utiles, et comprenez ses compromis en matière de CPU et de mémoire.
Réduire la bande passante grâce à la compression des messages est une leçon WebSockets & Real-Time Systems with Spring gratuite sur CoddyKit. Ceci est la leçon 4 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage WebSockets & Real-Time Systems with Spring, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours WebSockets & Real-Time Systems with Spring comprend 4 leçons au total.
Certaines parties de cette leçon n'ont pas encore été traduites et s'affichent en anglais.
Bandwidth Is a Bottleneck
Real-time apps can push thousands of frames per second. On mobile and high-fan-out systems, raw bytes on the wire become a real cost in latency, data charges, and egress bills.
The permessage-deflate Extension
WebSocket defines an extension, permessage-deflate, that compresses each message with DEFLATE (the same algorithm as gzip) before it is sent and decompresses it on arrival.
Negotiated in the Handshake
Compression is negotiated via the Sec-WebSocket-Extensions header during the upgrade. If both peers agree, frames are compressed transparently afterward.
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bitsWhere Compression Wins
Compression helps most with text and JSON, which are highly repetitive. A 4 KB JSON payload can shrink to under 1 KB.
Already-compressed data (images, video, gzip) barely shrinks and just wastes CPU.
The CPU Trade-off
Compression is not free. Every message costs CPU on both sides. Under very high message rates the CPU spent compressing can outweigh the bandwidth saved.
The Context-Takeover Memory Cost
DEFLATE keeps a sliding-window dictionary per connection (context takeover). With many connections this is significant memory. Disabling takeover saves RAM but lowers the compression ratio.
Enabling in Spring (Tomcat)
Spring delegates to the servlet container. On Tomcat you tune the WebSocket compression via container properties or a customizer.
server.tomcat.use-relative-redirects=false
# Tomcat enables permessage-deflate when the client offers it;
# tune limits via WsServerContainer / @Bean customizerPer-Message Skip for Small Frames
Compressing tiny frames adds overhead with little gain. Many stacks skip compression below a threshold (e.g. messages under 256 bytes). Keep this in mind when designing payload sizes.
Application-Level Alternatives
Before reaching for transport compression, shrink the payload itself:
- Send deltas, not full snapshots
- Use short field names or a binary format (Protobuf, MessagePack)
- Batch many small updates into one frame
Measuring the Benefit
Always measure. Compare bytes-on-wire and CPU before and after enabling compression for your real traffic mix; do not assume it is always a win.
# Compare with monitoring metrics
websocket.bytes.sent (deflate on vs off)
process.cpu.usageChoosing a Strategy
Rules of thumb:
- High-volume JSON, bandwidth-bound → enable permessage-deflate
- Many idle connections, memory-bound → disable context takeover
- CPU-bound, small frames → prefer application-level payload shrinking
Quick Check
Test your compression knowledge.
Recap
You optimized bandwidth:
- permessage-deflate compresses each message, negotiated in the handshake
- Best for repetitive text/JSON; useless for already-compressed data
- It trades CPU and per-connection memory (context takeover) for fewer bytes
- Application-level deltas, binary formats, and batching are complementary
- Always measure before and after for your real traffic
Questions Fréquemment Posées
La leçon « Réduire la bande passante grâce à la compression des messages » est-elle gratuite ?
Oui — le texte complet de « Réduire la bande passante grâce à la compression des messages » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours WebSockets & Real-Time Systems with Spring, passe à CoddyKit PRO. Le cours WebSockets & Real-Time Systems with Spring comprend 4 leçons au total.
Qu'est-ce que j'apprendrai dans « Réduire la bande passante grâce à la compression des messages » ?
Réduisez la bande passante WebSocket avec l’extension permessage-deflate et une conception judicieuse des données utiles, et comprenez ses compromis en matière de CPU et de mémoire. Tu pratiques WebSockets & Real-Time Systems with Spring avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.
Dois-je avoir de l'expérience pour commencer WebSockets & Real-Time Systems with Spring ?
Aucune expérience préalable n'est requise. WebSockets & Real-Time Systems with Spring sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 4 sur 4.
Combien de temps prend la leçon « Réduire la bande passante grâce à la compression des messages » ?
La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.
Peux-tu écrire et exécuter du code dans cette leçon WebSockets & Real-Time Systems with Spring ?
Oui. Chaque leçon WebSockets & Real-Time Systems with Spring inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.
Toutes les leçons de ce cours
- Évaluation des performances de WebSocket
- Surveillance des connexions WebSocket
- Optimisation des paramètres Spring WebSocket
- Réduire la bande passante grâce à la compression des messages