23 सित॰ 2025·6 मिनट
ZSTD बनाम Brotli बनाम GZIP: API संकुचन का चयन
APIs के लिए ZSTD, Brotli और GZIP की तुलना: स्पीड, अनुपात, CPU लागत और JSON व बाइनरी पेलोड्स के लिए व्यावहारिक डिफ़ॉल्ट्स प्रोडक्शन में।
APIs के लिए ZSTD, Brotli और GZIP की तुलना: स्पीड, अनुपात, CPU लागत और JSON व बाइनरी पेलोड्स के लिए व्यावहारिक डिफ़ॉल्ट्स प्रोडक्शन में।
API प्रतिक्रिया संकुचन का मतलब है कि आपका सर्वर प्रतिक्रिया बॉडी (अकसर JSON) को नेटवर्क पर भेजने से पहले छोटे बाइट स्ट्रीम में एन्कोड करता है। क्लाइंट (ब्राउज़र, मोबाइल ऐप, SDK, या कोई सर्विस) उसे डी‑कम्प्रेस करता है। HTTP पर यह हेडर्स के माध्यम से नेगोशिएट होता है जैसे Accept-Encoding (क्लाइंट क्या संभाल सकता है) और Content-Encoding (सर्वर ने क्या चुना)।
संकुचन मुख्यतः आपको तीन चीज़ देता है:
ट्रेड‑ऑफ सीधा है: संकुचन बैंडविड्थ बचाता है लेकिन CPU (कम्प्रेस/डीकम्प्रेस) और कभी-कभी मेमोरी (बफर) की लागत लेता है। क्या यह फायदेमंद है यह आपके बॉटलनेcks पर निर्भर करता है।
संकुचन तब चमकता है जब प्रतिक्रियाएँ:
यदि आप बड़े JSON लिस्ट (कैटलॉग, सर्च रिज़ल्ट्स, एनालिटिक्स) लौटाते हैं, तो संकुचन अक्सर सबसे आसान जीतों में से एक है।
संकुचन अक्सर CPU के गलत उपयोग में पड़ता है जब प्रतिक्रियाएँ:
जब आप ZSTD बनाम Brotli बनाम GZIP चुनते हैं, तो व्यावहारिक निर्णय आम तौर पर तीन बातों पर निर्भर करता है:
बाकी लेख में सब कुछ इन्हीं तीनों को आपके API और ट्रैफ़िक पैटर्न के लिए संतुलित करने के बारे में है।
तीनों payload आकार घटाते हैं, पर वे अलग‑अलग प्रतिबंधों के लिए अनुकूलित होते हैं — स्पीड, संकुचन अनुपात और संगतता।
ZSTD स्पीड: जब आपका API टेल‑लेटेंसी के प्रति संवेदनशील हो या आपके सर्वर CPU‑बाउंड हों तो यह शानदार है। मध्यम‑से‑बड़े JSON उत्तरों के लिए यह काफी तेज़ कम्प्रेश कर सकता है—अकसर नेटवर्क समय की तुलना में ओवरहेड नगण्य होता है।
Brotli संकुचन अनुपात: जब बैंडविड्थ प्राथमिक बाधा हो (मोबाइल क्लाइंट, महंगा egress, CDN‑भारी डिलीवरी) और प्रतिक्रियाएँ ज्यादातर टेक्स्ट हों, तो यह जीतता है। छोटे पेलोड्स पर भी यह लाभदायक हो सकता है यदि आप अधिक CPU सह सकते हैं।
GZIP संगतता: जब आपको अधिकतम क्लाइंट समर्थन चाहिए और नेगोशिएशन जोखिम कम रखना हो (पुराने SDKs, एम्बेडेड क्लाइंट्स, लेगेसी प्रॉक्सी)। सुरक्षित बेसलाइन है भले ही यह टॉप‑परफॉर्मर न हो।
कम्प्रेशन “लेवल” CPU समय और आउटपुट साइज के बीच प्रीसेट होते हैं:
डीकम्प्रेशन आम तौर पर तीनों के लिए कम्प्रेशन से सस्ता होता है, पर बहुत उच्च स्तर मोबाइल जैसे कम‑शक्ति क्लाइंट्स पर क्लाइंट CPU/बैटरी बढ़ा सकते हैं।
संकुचन अक्सर “छोटे उत्तर = तेज़ APIs” के रूप में बेचा जाता है। धीमे या महंगे नेटवर्क पर यह अक्सर सही होता है—पर यह स्वतः सच्चा नहीं है। अगर संकुचन पर्याप्त सर्वर CPU समय जोड़ दे तो आप छोटे ट्रांसफर के बावजूद धीमें रह सकते हैं।
दो लागतों को अलग करना सहायक है:
एक उच्च अनुपात ट्रांसफर समय घटा सकता है, पर अगर कम्प्रेशन सर्वर टाइम में 15–30 ms जोड़ दे तो आप तेज़ कनेक्शन पर उससे अधिक समय खो सकते हैं।
लोड पर, संकुचन अक्सर p95/p99 लेटेंसी को p50 से अधिक नुकसान पहुंचा सकता है। जब CPU उपयोग उछलता है, अनुरोध कतार में लगते हैं। कतारबद्धता छोटे‑छोटे प्रति‑अनुरोध लागतों को बड़े विलंबों में बदल देती है—औसत लेटेंसी ठीक लग सकती है, पर सबसे धीमे उपयोगकर्ता प्रभावित होते हैं।
अंदाज़े पर भरोसा न करें। A/B टेस्ट या चरणबद्ध रोलआउट चलाएँ और तुलना करें:
वास्तविक ट्रैफ़िक पैटर्न और पेलोड्स के साथ टेस्ट करें। “सबसे अच्छा” कम्प्रेशन स्तर वह है जो कुल समय घटाए, न कि सिर्फ़ बाइट।
संकुचन मुफ्त नहीं होता—यह दोनों सिरों पर नेटवर्क से CPU और मेमोरी पर काम को शिफ्ट करता है। APIs में यह अनुरोध हैंडलिंग समय, मेमोरी फूटप्रिंट और कभी‑कभी क्लाइंट‑साइड धीमापन के रूप में दिखता है।
अधिकतर CPU प्रतिक्रियाओं को कम्प्रेस करने में खर्च होता है। कम्प्रेशन पैटर्न ढूँढता है, स्टेट/डिक्शनरी बनाता है, और एन्कोडेड आउटपुट लिखता है।
डीकम्प्रेशन आम तौर पर सस्ता होता है, पर अभी भी प्रासंगिक है:
यदि आपका API पहले से ही CPU‑बाउंड है, तो उच्च कम्प्रेशन स्तर टेल‑लेटेंसी बढ़ा सकता है भले ही पेलोड छोटा हो।
संकुचन मेमोरी उपयोग बढ़ा सकता है:
कंटेनराइज़्ड वातावरण में उच्च पीक मेमोरी OOM किल्स या कंज़ोर सीमाओं में तब्दील हो सकती है जो डेंसिटी घटाती हैं।
संकुचन प्रति‑प्रतिक्रिया CPU साइकिल जोड़ता है, जिससे प्रति इंस्टेंस थ्रूपुट घटता है। इससे ऑटो‑स्केलिंग जल्द शुरू हो सकती है और लागत बढ़ सकती है। आम पैटर्न: बैंडविड्थ घटता है, पर CPU खर्च बढ़ता है—तो सही विकल्प निर्भर करता है कि आपके लिए कौन सा संसाधन सुलभ है।
मोबाइल या कम‑शक्ति डिवाइसेज पर, डिकम्प्रेशन रेंडरिंग, JavaScript निष्पादन और बैटरी से प्रतिस्पर्धा करता है। एक फ़ॉर्मैट जो कुछ KB बचाता है पर डिकम्प्रेशन में अधिक समय लेता है, वह धीमा महसूस हो सकता है—खासकर जब "उपयोगयोग्य डेटा तक समय" मायने रखता है।
Zstandard (ZSTD) एक आधुनिक कम्प्रेशन फ़ॉर्मैट है जो मजबूत संकुचन अनुपात देने के लिए डिज़ाइन किया गया है बिना आपके API को धीमा किए। कई JSON‑प्रधान APIs के लिए यह एक मजबूत “डिफ़ॉल्ट” है: GZIP से स्पष्ट रूप से छोटे उत्तर समान या कम लेटेंसी पर, और क्लाइंट्स पर बेहद तेज़ डी‑कम्प्रेशन।
ZSTD तब सबसे उपयोगी है जब आप एंड‑टू‑एंड समय के बारे में परवाह करते हैं, सिर्फ़ सबसे छोटे बाइट्स के बारे में नहीं। यह सामान्यतः तेज़ कम्प्रेशन और बहुत तेज़ डी‑कम्प्रेशन देता है—API के लिए उपयोगी जहां हर मिलीसेकंड महत्वपूर्ण हो।
यह छोटे‑से‑मध्यम पेलोड्स में भी अच्छा प्रदर्शन करता है: छोटे‑मध्यम JSON अक्सर महत्वपूर्ण लाभ देखते हैं, जबकि बड़े उत्तर और भी अधिक लाभ दे सकते हैं।
अधिकांश APIs के लिए कम स्तर (सामान्यतः स्तर 1–3) से शुरू करें। ये अक्सर लेटेंसी/साइज ट्रेड‑ऑफ का सबसे अच्छा परिणाम देती हैं।
उच्च स्तर केवल तब उपयोग करें जब:
एक व्यावहारिक तरीका है: एक कम ग्लोबल डिफ़ॉल्ट रखें, और केवल कुछ "बड़े उत्तर" वाले एंडपॉइंट्स के लिए स्तर बढ़ाएँ।
ZSTD स्ट्रीमिंग का समर्थन करता है, जो बड़े उत्तरों के लिए पीक मेमोरी कम कर सकता है और जल्द भेजना शुरू कर सकता है।
डिक्शनरी मोड उन APIs के लिए बड़ा लाभ दे सकता है जो बहुत समान ऑब्जेक्ट्स लौटाते हैं (दोहराए गए कीज़, स्थिर स्कीमा)। यह तब सबसे प्रभावी है जब:
सर्वर‑साइड सपोर्ट कई स्टैक्स में सीधा है, पर क्लाइंट संगतता निर्णायक कारक हो सकती है। कुछ HTTP क्लाइंट, प्रॉक्सी, और गेटवे अभी भी डिफ़ॉल्ट रूप से Content-Encoding: zstd का विज्ञापन या स्वीकृति नहीं करते।
यदि आप थर्ड‑पार्टी उपभोक्ताओं को सर्व करते हैं, तो एक फॉलबैक रखें (आम तौर पर GZIP) और केवल तब ZSTD सक्षम करें जब Accept-Encoding स्पष्ट रूप से इसमें शामिल हो।
Brotli टेक्स्ट को बहुत अच्छी तरह से निचोड़ने के लिए डिज़ाइन किया गया है। JSON, HTML और अन्य "शब्दी" पेलोड्स पर यह अक्सर GZIP से बेहतर अनुपात देता है—खासतौर पर उच्च कम्प्रेशन स्तरों पर।
टेक्स्ट‑प्रधान प्रतिक्रियाएँ Brotli की मिठाई जगह हैं। यदि आपका API बड़े JSON दस्तावेज़ भेजता है (कैटलॉग, सर्च रिज़ल्ट, कॉन्फ़िग ब्लॉब्स), तो Brotli बाइट्स को काफी कम कर सकता है, जो धीने नेटवर्क पर मदद करता है और egress लागत घटा सकता है।
Brotli तब भी मजबूत है जब आप एक बार कम्प्रेस करके कई बार सर्व करते हैं (कैशेबिल रेसोर्सेज, वर्जनड रिसोर्सेज)। ऐसे मामलों में उच्च‑लेवल Brotli CPU लागत को कई रिक्वेस्ट्स पर अमॉर्टाइज़ कर सकता है।
डायनामिक API प्रतिक्रियाओं के लिए (प्रति‑अनुरोध जनरेटेड), Brotli का सर्वश्रेष्ठ अनुपात अक्सर उच्च स्तर मांगता है जो CPU‑महंगा हो सकता है और लेटेंसी बढ़ा सकता है। कम्प्रेशन समय जोड़ने पर ZSTD (या अच्छी तरह ट्यून किया GZIP) के ऊपर वास्तविक‑दुनिया लाभ उम्मीद से छोटा हो सकता है।
यह उन पेलोड्स के लिए भी कम आकर्षक है जो अच्छी तरह से संकुचित नहीं होते (पहले से संकुचित डेटा, कई बाइनरी फॉर्मैट्स)। उन मामलों में बस CPU जलता है।
ब्राउज़र्स HTTPS पर Brotli को सामान्यतः अच्छी तरह सपोर्ट करते हैं, यही कारण है कि यह वेब ट्रैफ़िक में लोकप्रिय है। गैर‑ब्राउज़र API क्लाइंट्स (मोबाइल SDKs, IoT डिवाइसेज़, पुराने HTTP स्टैक्स) के लिए सपोर्ट असंगत हो सकता है—इसलिए सही नेगोशिएशन (Accept-Encoding) और फॉलबैक (gzip) रखें।
GZIP अभी भी API संकुचन के लिए डिफ़ॉल्ट जवाब है क्योंकि यह सबसे सार्वभौमिक रूप से समर्थित विकल्प है। लगभग हर HTTP क्लाइंट, ब्राउज़र, प्रॉक्सी, और गेटवे Content-Encoding: gzip को समझता है, और यह भविष्यवाणी‑योग्य होना मायने रखता है जब आप अपने उपयोगकर्ताओं और बीच में मौजूद घटकों पर पूरा नियंत्रण न रखें।
फायदा यह नहीं कि GZIP "सर्वश्रेष्ठ" है—बल्कि यह कि यह शायद ही कभी गलत विकल्प होता है। कई संगठनों को इसके साथ वर्षों का परिचय है, उनके वेब सर्वर में समझदारी भरे डिफ़ॉल्ट हैं, और नए एन्कोडिंग्स के साथ इंटरमीडियरीज़ के साथ कम समस्याएँ आती हैं।
API पेलोड्स (अक्सर JSON) के लिए मध्यम‑से‑निम्न स्तर स्वीट‑स्पॉट होते हैं। स्तर जैसे 1–6 अक्सर अधिकांश साइज रिडक्शन देते हैं जबकि CPU को उचित रखते हैं।
बहुत उच्च स्तर (8–9) कुछ और बचत दे सकते हैं, पर डायनामिक ट्रैफ़िक जहाँ लेटेंसी मायने रखती है वहाँ अक्सर अतिरिक्त CPU का लाभ नहीं होता।
आधुनिक हार्डवेयर पर, GZIP सामान्यतः समान अनुपात पर ZSTD से धीमा होता है, और अक्सर टेक्स्ट पेलोड्स पर Brotli के सर्वोत्तम अनुपात से मेल नहीं खाता। वास्तविक API वर्कलोड में यह सामान्यतः मतलब रखता है:
यदि आपको पुराने क्लाइंट्स, एम्बेडेड डिवाइसेज़, सख्त कॉर्पोरेट प्रॉक्सीज़, या लेगेसी गेटवे सपोर्ट करना है, तो GZIP सबसे सुरक्षित विकल्प है। कुछ इंटरमीडियरी अज्ञात एन्कोडिंग्स को हटा देते हैं, पास‑थ्रू नहीं करते, या नेगोशिएशन तोड़ देते हैं—ऐसी समस्याएँ GZIP के साथ कम होती हैं।
यदि आपका वातावरण मिश्रित या अनिश्चि
उत्तर दें जब प्रतिक्रियाएँ टेक्स्ट-प्रधान (JSON/GraphQL/XML/HTML) हों, मध्यम से बड़ी हों, और आपके उपयोगकर्ता धीने/महंगे नेटवर्क पर हों या आप महत्वपूर्ण egress लागत चुकाते हों। उन मामलों में सक्षम करें। छोटों के लिए (कुछ सौ बाइट्स), पहले से संकुचित मीडिया (JPEG/MP4/ZIP/PDF), और उन सर्विसेस के लिए जो पहले से CPU-बाउंड हों, इसे बंद रखें या उच्च थ्रेशोल्ड रखें।
क्योंकि यह बैंडविड्थ के बदले CPU (और कभी-कभी मेमोरी) का व्यापार करता है। संकुचन समय सर्वर को बाइट्स भेजना शुरू करने में देरी कर सकता है (TTFB), और लोड के तहत यह कतारबद्धता को बढ़ाकर—खासकर टेल लेटेंसी—बढ़ा सकता है। “सबसे अच्छा” सेटिंग वह है जो सिर्फ बाइट्स नहीं बल्कि पूरे एंड‑टू‑एंड समय को घटाए।
अधिकांश API के लिए व्यावहारिक प्राथमिकता अक्सर होती है:
zstd पहले (तेज़, अच्छा अनुपात)br (टेक्स्ट के लिए अक्सर सबसे छोटा, कभी-कभी अधिक CPU)gzip (सबसे व्यापक अनुकूलता)अंतिम चयन हमेशा ग्राहक के द्वारा भेजे गए पर आधारित होना चाहिए, और एक सुरक्षित फॉलबैक रखें (आम तौर पर या )।
धीमी शुरुआत करें और मापें.
एक न्यूनतम रिस्पांस साइज थ्रेशोल्ड लागू करें ताकि आप छोटे पेलोड पर CPU बर्बाद न करें.
प्रति-एंडपॉइंट ट्यून करें: बचाए गए बाइट्स बनाम जोड़ा गया सर्वर समय और p50/p95/p99 पर प्रभाव तुलना करें।
वे कंटेंट प्रकार जिनमें संरचना और पुनरावृत्ति अधिक होती है:
HTTP नेगोशिएशन का पालन करें:
Accept-Encoding भेजता है (उदा., zstd, br, gzip)Content-Encoding के साथ उत्तर देता हैअगर क्लाइंट नहीं भेजता, तो सबसे सुरक्षित उत्तर आमतौर पर है। कभी भी ऐसा रिटर्न न करें जो क्लाइंट ने विज्ञापित न किया हो, वरना क्लाइंट विफल हो सकता है।
जोड़ें:
Vary: Accept-Encodingयह CDN/प्रॉक्सी को रोकता है कि वह किसी एक एन्कोडिंग (उदा., gzip) वाली प्रतिक्रिया कैश करके उसे ऐसे क्लाइंट को दे दे जो उस एन्कोडिंग को सपोर्ट नहीं करता। अगर आप कई एन्कोडिंग्स समर्थन करते हैं, तो यह हेडर सही कैशिंग के लिए अनिवार्य है।
सामान्य विफलताएँ:
इसे एक परफॉर्मेंस फीचर की तरह रोलआउट करें:
अगर लोड पर टेल‑लेटेंसी बढ़े, तो स्तर घटाएँ, थ्रेशोल्ड बढ़ाएँ, या तेज़ कोडेक (अक्सर ZSTD) पर स्विच करें।
Accept-Encodinggzipidentityउच्च स्तर अक्सर आकार में मामूली सुधार देते हैं पर CPU और p95/p99 पर दुष्प्रभाव बढ़ाते हैं।
आम तौर पर टेक्स्ट-प्रकार वाले Content-Type पर संकुचन सक्षम रखें और पहले से संकुचित फ़ॉर्मैट्स के लिए बंद कर दें।
Accept-EncodingContent-EncodingContent-Encoding कहा गया पर बॉडी संकुचित नहीं)Accept-Encoding की अवहेलना)Content-Lengthडिबग करते समय कच्चे रिस्पांस हेडर्स कैप्चर करें और एक विश्वसनीय क्लाइंट के साथ डी‑कम्प्रेशन सत्यापित करें।