वेब डेवलपमेंट में Chunked Transfer — यह क्या है, प्रारूप और चंक ट्रांसफर का सिद्धांत
Chunked Transfer HTTP प्रोटोकॉल का एक तंत्र है जिसमें सर्वर प्रतिक्रिया के मुख्य भाग को अलग-अलग टुकड़ों (चंक्स) में भेजता है बिना पहले से डेटा का कुल आकार बताए। प्रत्येक चंक में हेक्साडेसिमल प्रारूप में अपना आकार और निर्दिष्ट लंबाई का डेटा होता है, और एक शून्य आकार के अंतिम चंक के साथ समाप्त होता है। MDN Web Docs, 2025 के अनुसार, Transfer-Encoding: chunked सर्वर द्वारा स्वचालित रूप से सक्षम किया जाता है जब प्रतिक्रिया का आकार पहले से अज्ञात हो — उदाहरण के लिए, तुरंत सामग्री निर्माण या डेटा स्ट्रीमिंग के दौरान।
मुख्य बिंदु
- Chunked Transfer — Content-Length पूर्व निर्दिष्ट किए बिना HTTP प्रतिक्रिया का भागों में प्रेषण।
- Transfer-Encoding: chunked — हेडर जो चंक डेटा स्थानांतरण मोड को सक्षम करता है।
- प्रत्येक चंक में हेक्स में आकार, डेटा और अंत में CRLF होता है, और अंत शून्य आकार के चंक द्वारा इंगित किया जाता है।
- Streaming — ऑडियो, वीडियो और SSE इवेंट्स के प्रेषण के लिए chunked transfer का मुख्य उपयोग।
- Chunked Transfer Content-Length हेडर के साथ असंगत है — इनका एक साथ उपयोग नहीं किया जाता।
Chunked Transfer क्या है?
Chunked Transfer HTTP/1.1 विनिर्देश (RFC 7230, खंड 4.1) में परिभाषित एक HTTP तंत्र है जो सर्वर को कुल Content-Length निर्दिष्ट किए बिना प्रतिक्रिया के मुख्य भाग को भागों में भेजने की अनुमति देता है। भेजने से पहले प्रतिक्रिया के आकार की गणना करने के बजाय, सर्वर तुरंत संचरण शुरू करता है, डेटा के टुकड़े तैयार होते ही भेजता है। प्रत्येक टुकड़ा अपने स्वयं के आकार हेडर के साथ आता है, जो क्लाइंट को टुकड़ों से प्रतिक्रिया को जोड़ने की अनुमति देता है।
तंत्र Transfer-Encoding: chunked हेडर द्वारा सक्षम किया जाता है। जब क्लाइंट प्रतिक्रिया में यह हेडर देखता है, तो उसे पता चलता है कि मुख्य भाग चंक्स में प्रेषित होगा और उसे एक लूप में प्रतिक्रिया पढ़नी होगी: चंक का आकार पढ़ें, फिर निर्दिष्ट आकार का डेटा पढ़ें, फिर दोहराएँ। प्रक्रिया तब समाप्त होती है जब शून्य आकार का चंक मिलता है। Chunked Transfer HTTP/1.1 का एक अनिवार्य हिस्सा है, जो सभी आधुनिक वेब सर्वरों और HTTP क्लाइंट्स द्वारा समर्थित है।
चंक ट्रांसफर का उपयोग करने का मुख्य कारण गतिशील सामग्री निर्माण है। जब सर्वर डेटाबेस क्वेरी, बाहरी API या लंबी गणना के आधार पर प्रतिक्रिया उत्पन्न करता है, तो वह पहले से परिणाम का आकार नहीं जान सकता। पूरी प्रतिक्रिया को मेमोरी में बफर करने के बजाय (जो बड़ी मात्रा के लिए जोखिम भरा है), सर्वर Transfer-Encoding: chunked सक्षम करता है और डेटा उपलब्ध होते ही भेजता है। यह सीमित मेमोरी वाले सर्वरों और उन प्रतिक्रियाओं के लिए विशेष रूप से महत्वपूर्ण है जिनका आकार बहुत बड़ा हो सकता है — 100 MB और उससे अधिक।
HTTP/1.1 चंक्ड और HTTP/2 के बीच अंतर
HTTP/2 में, चंक ट्रांसफर तंत्र स्वयं मौजूद नहीं है क्योंकि प्रोटोकॉल फ्रेम स्तर पर स्ट्रीम मल्टीप्लेक्सिंग का उपयोग करता है। HTTP/2 में, किसी भी आकार का डेटा DATA फ्रेम्स में प्रेषित होता है, और प्रतिक्रिया के मुख्य भाग के आकार को पहले से घोषित करने की आवश्यकता नहीं है — एक स्ट्रीम किसी भी क्षण बंद की जा सकती है। आधुनिक सर्वर HTTP/2 अपस्ट्रीम पर प्रॉक्सी करते समय स्वचालित रूप से HTTP/1.1 चंक्ड प्रतिक्रियाओं को समतुल्य स्ट्रीमिंग प्रेषण में परिवर्तित करते हैं। Chunked Transfer HTTP/1.1 कनेक्शन के लिए प्रासंगिक बना हुआ है।
चंक ट्रांसफर कैसे काम करता है
जब सर्वर Chunked Transfer का उपयोग करने का निर्णय लेता है, तो वह Content-Length की गणना नहीं करता बल्कि Transfer-Encoding: chunked हेडर भेजता है। फिर प्रतिक्रिया का मुख्य भाग चंक्स के अनुक्रम के रूप में बनता है। प्रत्येक चंक एक पंक्ति से शुरू होता है जिसमें हेक्साडेसिमल प्रारूप में चंक का आकार होता है (बिना 0x उपसर्ग के), उसके बाद CRLF ( ) होता है। फिर निर्दिष्ट आकार का चंक डेटा आता है, जो CRLF पर समाप्त होता है। अंतिम चंक का आकार 0 होता है, जिसके बाद trailer हेडर आ सकते हैं।
हेक्साडेसिमल आकार 1 बाइट से लेकर सैद्धांतिक रूप से असीमित मात्रा तक किसी भी आकार के चंक्स को प्रेषित करने की अनुमति देता है। व्यवहार में, चंक का आकार सर्वर द्वारा चुना जाता है: विशिष्ट मान 4 KB, 8 KB या 16 KB हैं। इष्टतम चंक आकार परिवहन स्तर पर विखंडन को कम करने के लिए TCP खंड आकार (सामान्यतः ईथरनेट के लिए 1460 बाइट्स) का गुणज होना चाहिए। Nginx डिफ़ॉल्ट रूप से 4 KB चंक का उपयोग करता है, Apache 8 KB चंक का।
Transfer-Encoding: chunked प्राप्त करने वाला क्लाइंट समाप्ति शून्य चंक तक प्रतिक्रिया को चंक दर चंक पढ़ने के लिए बाध्य है। यदि क्लाइंट चंक ट्रांसफर का समर्थन नहीं करता है, तो सर्वर इस मोड का उपयोग नहीं कर सकता। व्यवहार में, सभी आधुनिक HTTP क्लाइंट — ब्राउज़र, OkHttp, URLSession, curl — चंक्ड प्रतिक्रियाओं का पूरी तरह समर्थन करते हैं। स्ट्रीमिंग रीड क्लाइंट को पूरी प्रतिक्रिया प्राप्त करने से पहले डेटा प्रसंस्करण शुरू करने की अनुमति देता है, जो प्रदर्शन के लिए महत्वपूर्ण है।
| चंक तत्व | प्रारूप | उदाहरण |
|---|---|---|
| चंक आकार | HEX + CRLF | 1000 |
| चंक डेटा | [आकार बाइट्स] + CRLF | [4096 बाइट्स डेटा] |
| समाप्ति चंक | 0 | 0 |
| Trailer (वैकल्पिक) | हेडर + CRLF | Expires: Wed, 21 Oct 2025 |
Chunked Transfer में Trailer हेडर
Chunked Transfer trailer हेडर का समर्थन करता है — अतिरिक्त HTTP हेडर जो अंतिम चंक के बाद प्रेषित होते हैं। यह मेटाडेटा के लिए उपयोगी है जो प्रतिक्रिया निर्माण पूरा होने के बाद ही ज्ञात होता है: उदाहरण के लिए, Content-MD5 या X-Compression-Ratio. Trailer हेडर को Trailer हेडर में घोषित किया जाना चाहिए: Trailer: Content-MD5, X-Compression-Ratio. व्यवहार में, trailers का उपयोग शायद ही कभी किया जाता है — अधिकांश सर्वर उन्हें प्रतिक्रियाओं में शामिल नहीं करते।
Chunked प्रतिक्रिया का प्रारूप
चंक्ड प्रतिक्रिया की एक सख्ती से परिभाषित संरचना होती है जिसे क्लाइंट को सही ढंग से पार्स करना चाहिए। आइए Transfer-Encoding: chunked के साथ HTTP प्रतिक्रिया का एक पूर्ण उदाहरण देखें। हेडर और एक खाली पंक्ति के बाद, प्रतिक्रिया का मुख्य भाग शुरू होता है। मुख्य भाग की संरचना एक अनुक्रम है: चंक_आकार डेटा चंक_आकार डेटा ... 0 तक। प्रत्येक आकार ASCII वर्णों का उपयोग करके हेक्साडेसिमल संकेतन में प्रेषित होता है।
Chunked Transfer के साथ सर्वर प्रतिक्रिया का उदाहरण:
HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked
7
Hello
6
World!
0
इस उदाहरण में, सर्वर स्ट्रिंग “Hello World!” को दो चंक्स में प्रेषित करता है। पहला चंक 7 बाइट्स का है जिसमें “Hello ” है, दूसरा 6 बाइट्स का है जिसमें “World!” है। क्लाइंट दोनों चंक्स से डेटा एकत्र करता है और पूर्ण स्ट्रिंग प्राप्त करता है। महत्वपूर्ण: चंक आकार में केवल डेटा शामिल है, स्वयं चंक्स के CRLF विभाजक नहीं। समाप्ति खाली चंक (0 ) क्लाइंट को सूचित करता है कि प्रेषण पूरा हो गया है।
kotlin
import java.net.HttpURLConnection
import java.io.BufferedReader
import java.io.InputStreamReader
fun readChunkedResponse() {
val url = java.net.URL("https://stream.example.com/data")
val connection = url.openConnection() as HttpURLConnection
val reader = BufferedReader(
InputStreamReader(connection.inputStream)
)
var line: String?
while (reader.readLine().also { line = it } != null) {
println("चंक: $line")
}
reader.close()
}OkHttp में चंक्ड प्रतिक्रिया को पार्स करना
OkHttp डेवलपर को Chunked Transfer के विवरण से पूरी तरह अलग कर देता है। Transfer-Encoding: chunked के साथ प्रतिक्रिया प्राप्त करने पर, OkHttp स्वचालित रूप से चंक्स एकत्र करता है और डेवलपर को response.body?.string() के माध्यम से पूर्ण प्रतिक्रिया मुख्य भाग प्रदान करता है। स्ट्रीमिंग प्रसंस्करण के लिए, response.body?.source() का उपयोग किया जाता है, जो BufferedSource लौटाता है और डेटा आने पर पढ़ने की अनुमति देता है। डेवलपर को मैन्युअल रूप से हेक्स आकार और CRLF पार्स करने की आवश्यकता नहीं है — लाइब्रेरी यह स्वचालित रूप से करती है।
Chunked Transfer बनाम Content-Length
Content-Length और Transfer-Encoding: chunked HTTP संदेश के मुख्य भाग का आकार निर्दिष्ट करने के दो परस्पर अनन्य तरीके हैं। Content-Length एक हेडर है जिसमें बाइट्स में मुख्य भाग का सटीक आकार होता है। यह उन प्रतिक्रियाओं के लिए अनिवार्य है जिनका आकार पहले से ज्ञात है और मुख्य भाग (POST, PUT) वाले अनुरोधों के लिए। Content-Length क्लाइंट को आवश्यक आकार का बफर पहले से आवंटित करने और सत्यापित करने की अनुमति देता है कि सभी डेटा प्राप्त हो गया है।
Chunked Transfer का उपयोग तब किया जाता है जब मुख्य भाग का आकार पहले से ज्ञात न हो। यह तीन मुख्य परिदृश्यों में होता है: गतिशील सामग्री निर्माण (उदाहरण के लिए, डेटाबेस क्वेरी जिसका परिणाम अभी उपलब्ध नहीं है), बड़ी फाइलों का स्ट्रीमिंग प्रेषण (पूरी फाइल को मेमोरी में बफर करने से बचने के लिए) और रीयल-टाइम इवेंट प्रेषण के लिए Server-Sent Events (SSE)। चुनाव Content-Length और चंक्ड के बीच सर्वर की जिम्मेदारी है। यदि सर्वर प्रेषण शुरू करने से पहले आकार जानता है, तो उसे एक सरल और अधिक अनुमानित तंत्र के रूप में Content-Length का उपयोग करना चाहिए।
HTTP/1.1 विनिर्देश Content-Length और Transfer-Encoding: chunked के एक साथ उपयोग को प्रतिबंधित करता है। यदि सर्वर दोनों हेडर भेजता है, तो क्लाइंट को Content-Length को अनदेखा करना चाहिए और प्रतिक्रिया को चंक्ड के रूप में संसाधित करना चाहिए। प्राथमिकता Transfer-Encoding की Content-Length पर RFC 7230 में उन मामलों के लिए स्थापित की गई है जहां प्रॉक्सी सर्वर प्रतिक्रिया के मुख्य भाग को संशोधित करता है और मूल Content-Length को संरक्षित नहीं कर सकता। कुछ पुराने HTTP क्लाइंट इस स्थिति को गलत तरीके से संभालते हैं, लेकिन आधुनिक कार्यान्वयन विनिर्देश का पालन करते हैं।
जब Content-Length असंभव है
ऐसे परिदृश्य हैं जहां Content-Length मूल रूप से पहले से गणना नहीं की जा सकती। गतिशील रिपोर्ट फ़िल्टरिंग और एकत्रीकरण के साथ मांग पर उत्पन्न — सर्वर डेटाबेस क्वेरी पूरी होने तक डेटा की मात्रा नहीं जानता। रीयल-टाइम में कैमरे से प्रेषित स्ट्रीमिंग वीडियो — आकार अनंत है। सूचनाओं के लिए SSE और long polling — प्रतिक्रिया अनिश्चित काल तक रह सकती है। इन सभी मामलों में, Chunked Transfer ही एकमात्र सही तंत्र है।
Chunked transfer पर आधारित स्ट्रीमिंग
Chunked Transfer वेब पर कई स्ट्रीमिंग तकनीकों का आधार है। सबसे प्रसिद्ध है Server-Sent Events (SSE), जहां सर्वर Transfer-Encoding: chunked के साथ एक HTTP कनेक्शन पर क्लाइंट को इवेंट भेजता है। SSE एक विशेष टेक्स्ट प्रारूप (data: संदेश ) का उपयोग करता है, लेकिन परिवहन स्तर सामान्य चंक ट्रांसफर है। ब्राउज़र सर्वर द्वारा भेजे जाने पर इवेंट प्राप्त करता है, प्रतिक्रिया पूरी होने की प्रतीक्षा किए बिना।
ऑडियो और वीडियो स्ट्रीमिंग भी Chunked Transfer पर निर्भर करती है। मीडिया सर्वर जैसे Nginx RTMP और Wowza Streaming Engine HTTP पर चंक्स में मीडिया डेटा भेजते हैं। क्लाइंट-साइड प्लेयर पहला चंक प्राप्त होते ही प्लेबैक शुरू करता है, फाइल के पूरी तरह लोड होने की प्रतीक्षा किए बिना। यह पहले फ्रेम तक के समय को दसियों सेकंड से घटाकर 1-2 सेकंड कर देता है। YouTube और Netflix अपने HTTP स्ट्रीम के लिए बिल्कुल इसी दृष्टिकोण का उपयोग करते हैं।
मोबाइल डेवलपमेंट में, Chunked Transfer का उपयोग पूरी प्रतिक्रिया को मेमोरी में लोड किए बिना बड़ी मात्रा में डेटा स्थानांतरित करने के लिए किया जाता है। Android पर Coil या Glide के माध्यम से छवियाँ लोड करते समय, लाइब्रेरीज़ चंक दर चंक स्ट्रीमिंग डेटा पढ़ती हैं और धीरे-धीरे छवि को डिकोड करती हैं। यह बिना OutOfMemoryError के बड़ी छवियाँ (10+ MB) प्रदर्शित करने की अनुमति देता है। OkHttp response.body?.byteStream() के माध्यम से स्ट्रीमिंग रीड का समर्थन करता है, जो एक InputStream लौटाता है जो चंक दर चंक डेटा पढ़ता है।
gRPC और GraphQL में Chunked transfer
gRPC HTTP/2 का उपयोग करता है, जहां स्ट्रीमिंग प्रोटोकॉल स्तर पर निर्मित है और एक अलग चंक तंत्र की आवश्यकता नहीं है। HTTP/1.1 पर चलने वाले GraphQL सर्वर सब्सक्रिप्शन परिणामों को स्ट्रीम करने के लिए Chunked Transfer का उपयोग कर सकते हैं। Apollo Server और Hasura GraphQL सब्सक्रिप्शन के लिए चंक्ड प्रतिक्रियाएँ भेजते हैं, घटित होने पर इवेंट प्रेषित करते हैं। क्लाइंट को पोलिंग की आवश्यकता के बिना रीयल-टाइम अपडेट प्राप्त होते हैं।
लाभ और सीमाएँ
Chunked Transfer वेब अनुप्रयोगों के लिए महत्वपूर्ण लाभ प्रदान करता है। तत्काल डेटा भेजना — सर्वर भेजने से पहले प्रतिक्रिया को बफर नहीं करता, पहले बाइट तक विलंबता कम करता है। स्ट्रीमिंग प्रसंस्करण — क्लाइंट पूर्ण डाउनलोड की प्रतीक्षा किए बिना डेटा आते ही संसाधित करना शुरू कर सकता है। कोई मेमोरी सीमाएँ नहीं — सर्वर पूरी प्रतिक्रिया को मेमोरी में संग्रहीत नहीं करता, जो बड़े डेटा वॉल्यूम के लिए महत्वपूर्ण है। अनंत स्ट्रीम प्रेषित करने की क्षमता — SSE, लाइव वीडियो, निगरानी।
हालाँकि, Chunked Transfer की सीमाएँ हैं। ओवरहेड प्रत्येक चंक के लिए आकार + CRLF के 6-12 बाइट्स है, जो कई छोटे चंक्स (उदाहरण के लिए, 100 बाइट्स प्रत्येक) के लिए प्रतिक्रिया आकार को 10-15% बढ़ा सकता है। सटीक आकार निर्दिष्ट करने में असमर्थता — क्लाइंट पहले से बफर आवंटित नहीं कर सकता या प्रगति पट्टी नहीं दिखा सकता। प्रॉक्सी सर्वर के साथ समस्याएँ — कुछ पुराने प्रॉक्सी चंक ट्रांसफर का समर्थन नहीं करते और ऐसी प्रतिक्रियाओं को कैश नहीं कर सकते। डाउनलोड फिर से शुरू करने का समर्थन नहीं — आंशिक रूप से प्राप्त चंक्ड प्रतिक्रियाओं के लिए Range अनुरोध नहीं किए जा सकते।
HTTP Archive, 2025 के अनुसार, लगभग 35% सभी HTTP प्रतिक्रियाएँ Transfer-Encoding: chunked का उपयोग करती हैं। इनमें गतिशील पृष्ठ (60%), API प्रतिक्रियाएँ (25%) और मीडिया स्ट्रीम (15%) प्रमुख हैं। स्थिर फाइलें लगभग हमेशा Content-Length का उपयोग करती हैं क्योंकि उनका आकार पहले से ज्ञात होता है। चंक्ड प्रतिक्रियाओं का हिस्सा HTTP/2 को अपनाने के साथ धीरे-धीरे कम हो रहा है, जहां स्ट्रीमिंग फ्रेम स्तर पर अतिरिक्त Transfer-Encoding हेडर की आवश्यकता के बिना कार्यान्वित की जाती है।
व्यावहारिक सुझाव
मोबाइल डेवलपमेंट में, बड़ी फाइलें (चित्र, वीडियो) डाउनलोड करने और बड़े डेटा सरणियाँ लौटाने वाले API अनुरोधों के लिए Chunked Transfer का उपयोग करें। OkHttp बिना अतिरिक्त कॉन्फ़िगरेशन के चंक ट्रांसफर का पूरी तरह समर्थन करता है। सर्वर पर अपलोड के लिए, Chunked Transfer का उपयोग नहीं किया जाता — HTTP/1.1 में अपलोड के लिए Transfer-Encoding नहीं है। iOS पर, URLSession बिना विशेष कॉन्फ़िगरेशन के चंक्ड डेटा भेजने और प्राप्त करने दोनों का समर्थन करता है। स्ट्रीमिंग JSON पार्सिंग (उदाहरण के लिए, Jackson Streaming API या Moshi के माध्यम से) चंक्ड स्ट्रीम में आने पर बड़े JSON सरणियों को संसाधित करने की अनुमति देता है।
अक्सर पूछे जाने वाले प्रश्न
सर्वर Chunked Transfer कैसे सक्षम करता है?
सर्वर स्वचालित रूप से Chunked Transfer सक्षम करता है जब प्रतिक्रिया का आकार अज्ञात होता है। Nginx Transfer-Encoding: chunked जोड़ता है यदि Content-Length सेट नहीं है। Spring Boot में, StreamingResponseBody और SseEmitter स्वचालित रूप से चंक ट्रांसफर का उपयोग करते हैं। Node.js Express में, प्रतिक्रिया चंक्ड हो जाती है यदि Content-Length के बिना res.write() और res.end() कॉल किया जाए।
क्या Content-Length और chunked एक साथ उपयोग किए जा सकते हैं?
नहीं, HTTP/1.1 विनिर्देश Content-Length और Transfer-Encoding: chunked के एक साथ उपयोग को प्रतिबंधित करता है। यदि सर्वर दोनों हेडर भेजता है, तो क्लाइंट को Content-Length को अनदेखा करना चाहिए और प्रतिक्रिया को चंक्ड के रूप में संसाधित करना चाहिए। यह नियम RFC 7230 में प्रॉक्सी सर्वरों के साथ संगतता के लिए स्थापित किया गया है जो प्रतिक्रिया के मुख्य भाग को संशोधित कर सकते हैं।
इष्टतम चंक आकार क्या है?
इष्टतम चंक आकार परिदृश्य पर निर्भर करता है। सामान्य वेब पृष्ठों के लिए — 4-8 KB। वीडियो स्ट्रीमिंग के लिए — 16-64 KB। SSE के लिए — विलंबता कम करने के लिए 1-2 KB के न्यूनतम चंक। चंक आकार परिवहन स्तर पर विखंडन को कम करने के लिए TCP खंड आकार (ईथरनेट के लिए 1460 बाइट्स) का गुणज होना चाहिए।
क्या Chunked Transfer प्रॉक्सी के माध्यम से काम करता है?
आधुनिक प्रॉक्सी सर्वर (Nginx, HAProxy, Envoy) Chunked Transfer का समर्थन करते हैं। प्रॉक्सी बिना बफरिंग (स्ट्रीमिंग) के चंक्स को आगे भेज सकता है या पूरी प्रतिक्रिया को बफर करके Content-Length के साथ पुनः भेज सकता है। पुराने प्रॉक्सी चंक्ड प्रतिक्रिया को पूरा होने तक बफर कर सकते हैं, जिससे विलंबता बढ़ जाती है। HTTP/2 इस समस्या को प्रोटोकॉल स्तर पर हल करता है।
Chunked Transfer HTTP chunked encoding से कैसे अलग है?
ये एक ही हैं। Chunked Transfer HTTP/1.1 विनिर्देश से तंत्र का पूरा नाम है। HTTP chunked encoding भी वही है, कभी-कभी लाइब्रेरी दस्तावेज़ीकरण में उपयोग किया जाता है। Transfer-Encoding: chunked वह हेडर है जो इस मोड को सक्षम करता है। तीनों शब्द डेटा को भागों में प्रेषित करने के एक ही तंत्र का वर्णन करते हैं।
सारांश
- Chunked Transfer — HTTP/1.1 तंत्र जो Content-Length पूर्व निर्दिष्ट किए बिना प्रतिक्रिया के मुख्य भाग को चंक्स में प्रेषित करता है।
- Transfer-Encoding: chunked — हेडर जो चंक प्रेषण सक्षम करता है; प्रत्येक चंक में हेक्स आकार, डेटा और CRLF होता है।
- शून्य आकार का समाप्ति चंक प्रेषण के अंत का संकेत देता है, जिसके बाद trailer हेडर आ सकते हैं।
- गतिशील सामग्री स्ट्रीमिंग — मुख्य उपयोग मामला: गतिशील पृष्ठ, SSE, स्ट्रीमिंग ऑडियो/वीडियो, लंबी रिपोर्ट।
- Content-Length और chunked परस्पर अनन्य हैं — विनिर्देश इन हेडर के एक साथ उपयोग को प्रतिबंधित करता है।
- लाभ — कम विलंबता, मेमोरी बचत, अनंत स्ट्रीम प्रेषित करने की क्षमता और क्लाइंट पक्ष पर स्ट्रीमिंग प्रसंस्करण।
- सीमाएँ — चंक हेडर से ओवरहेड, प्रगति दिखाने में असमर्थता, पुराने प्रॉक्सी सर्वरों के साथ समस्याएँ।
हम एक मोबाइल एप्लिकेशन टर्नकी विकसित करेंगे
IT Sectr 2017 से स्टार्टअप और व्यवसायों के लिए iOS और Android एप्लिकेशन बनाता है। हम आपको सलाह देंगे और सर्वोत्तम समाधान प्रस्तावित करेंगे।
यह भी पढ़ें