चंक्ड ट्रांसफर एनकोडिंग क्या है? एक HTTP/1.1 गाइड

चंक्ड ट्रांसफर एनकोडिंग क्या है?

स्क्रेपलेस यूनिवर्सल स्क्रैपिंग एपीआई एक प्रबंधित अनुरोध सतह के माध्यम से सार्वजनिक वेब सामग्री प्राप्त करता है जो प्रतिक्रिया निकायों को बिना मूल-सर्वर संदेश फ्रेमिंग को नियंत्रित किए लौटाता है।

TL;DR

  • चंक्ड ट्रांसफर एनकोडिंग एक HTTP/1.1 संदेश-फ्रेमिंग विधि है जो एक शरीर को स्वतंत्र रूप से आकार के चंक्स के अनुक्रम के रूप में भेजता है जब विक्रेता प्रसारण शुरू करने से पहले पूर्ण शरीर की लंबाई प्रदान नहीं करता है। चंकिंग के लिए व्यावहारिक कारण समय है।
  • ट्रांसफर कोडिंग पढ़ें। प्रापक ट्रांसफर-एनकोडिंग की जांच करता है और अंतिम कोडिंग को फ्रेमिंग नियम के रूप में मानता है। जब चंक्ड मौजूद है, तो कंटेंट-लेंथ को उसी संदेश शरीर को परिभाषित नहीं करना चाहिए। विरोधाभासी फ्रेमिंग मेटाडेटा खतरनाक होता है क्योंकि विभिन्न मध्यवर्ती यह असहमत हो सकते हैं कि अनुरोध या प्रतिक्रिया कहाँ समाप्त होती है।
  • डेटा और सीमांकक को सही ढंग से लें। आकार की पंक्ति के बाद, पार्सर घोषित संख्या में ऑक्टेट्स का उपभोग करता है और फिर आवश्यक पंक्ति समाप्ति। आकार की असंगति, अनुपस्थित सीमांकक, या शून्य चंक से पहले कनेक्शन बंद होने से संदेश अधूरा हो जाता है। अच्छी तरह से परीक्षण किए गए HTTP पुस्तकालय इस सीमा तार्किक को संभालते हैं इससे पहले कि वे शरीर को अनुप्रयोग कोड में उजागर करें।
  • हर प्रासंगिक कूद पर वार्तालापित HTTP संस्करण की पुष्टि करें, इसके बजाय इसे ब्राउज़र URL से अनुमानित करें। जब एक चंक्ड प्रतिक्रिया कट जाती है, तो पहले इस बात की पहचान करें कि किस कूद ने विफलता का उत्पादन किया।
  • चंक्ड ट्रांसफर एनकोडिंग एक सटीक HTTP/1.1 समस्या को हल करता है: कैसे एक शरीर को सीमांकित करें जिसका अंतिम बाइट लंबाई भेजने से पहले ज्ञात नहीं है।

परिभाषा और संक्षिप्त उत्तर

चंक्ड ट्रांसफर एनकोडिंग एक HTTP/1.1 संदेश-फ्रेमिंग विधि है जो एक शरीर को स्वतंत्र रूप से आकार के चंक्स के अनुक्रम के रूप में भेजता है जब विक्रेता प्रसारण शुरू करने से पहले पूर्ण शरीर की लंबाई प्रदान नहीं करता है। प्रत्येक चंक hexadecimal में अपने आकार के साथ शुरू होता है, उस आकार के डेटा के कई ऑक्टेट्स के साथ जारी रहता है, और एक कैरिज-रिटर्न और लाइन-फीड जोड़ी के साथ समाप्त होता है। एक शून्य आकार का चंक शरीर के अंत को चिह्नित करता है। इस तंत्र का संदेश एक नेटवर्क कूद पर फ्रेम होता है; यह मीडिया प्रकार को परिभाषित नहीं करता है, स्वयं प्रतिनिधित्व को संकुचित नहीं करता है, या एक संसाधन को स्वतंत्र रूप से पता लगाने योग्य फ़ाइलों में विभाजित नहीं करता है।

चंकिंग के लिए व्यावहारिक कारण समय है। एक अनुप्रयोग पंक्ति दर पंक्ति रिपोर्ट उत्पन्न कर सकता है, किसी अन्य सेवा से आउटपुट स्ट्रीम कर सकता है, या हर बाइट ज्ञात होने से पहले एक गतिशील रूप से रेंडर की गई प्रतिक्रिया भेजना शुरू कर सकता है। HTTP/1.1 अन्यथा एक विश्वसनीय सीमा की आवश्यकता होती है, आमतौर पर एक कंटेंट-लेंथ फ़ील्ड या कनेक्शन बंद होना। चंक्ड फ्रेमिंग उस सीमा को प्रदान करता है जबकि कनेक्शन को स्थायी बनाए रखने की अनुमति देता है। प्रापक प्रत्येक आकार की पंक्ति को पार्स कर सकता है, ठीक घोषित संख्या में ऑक्टेट्स का उपभोग कर सकता है, और बिना सर्वर के सॉकेट को बंद किए पूरा होने को पहचान सकता है।

चंक्ड ट्रांसफर एनकोडिंग कूद दर कूद है। एक रिवर्स प्रॉक्सी चंक्ड प्रतिक्रिया प्राप्त कर सकता है, इसे डीकोड कर सकता है, सामग्री को बफर या परिवर्तित कर सकता है, और इसे कंटेंट-लेंथ या एक अलग चंक लेआउट के साथ आगे बढ़ा सकता है। इस कारण से, अनुप्रयोग कोड को डीकोड किए गए शरीर और प्रतिक्रिया पूर्णता के बारे में चिंता करनी चाहिए न कि यह मान लेना चाहिए कि एक बिंदु पर देखे गए चंक्स अंत से अंत तक जीवित रहते हैं। कंटेंट-एनकोडिंग विभिन्न है: gzip या अन्य सामग्री कोडिंग यह बताती है कि प्रतिनिधित्व अनुरोध पथ में कैसे एनकोड किया जाता है, जबकि ट्रांसफर-एनकोडिंग निकटतम HTTP प्रतिभागियों के बीच फ्रेमिंग का वर्णन करता है।

HTTP/2 और HTTP/3 HTTP/1.1 ट्रांसफर-एनकोडिंग हेडर का उपयोग शरीर फ्रेमिंग के लिए नहीं करते हैं। वे अपनी स्वयं की बाइनरी फ्रेम परतों में डेटा ले जाते हैं। एक डेवलपर अभी भी स्ट्रीम किए गए डेटा को देख सकता है, लेकिन परिवहन प्रतिनिधित्व HTTP/1.1 चंकड कोडिंग नहीं है। यह भेद लॉग और डिबगिंग उपकरणों में महत्वपूर्ण है क्योंकि एक गेटवे ब्राउज़र से HTTP/2 स्वीकार कर सकता है और एक मूल के साथ HTTP/1.1 बोल सकता है, केवल मार्ग के एक पैरों पर चंकड ट्रैफ़िक बनाता है।

HTTP/1.1 चंकड़ शरीर को कैसे फ्रेम किया जाता है

  1. ट्रांसफर कोडिंग पढ़ें। प्रापक ट्रांसफर-एनकोडिंग की जांच करता है और अंतिम कोडिंग को फ्रेमिंग नियम के रूप में मानता है। जब चंक्ड मौजूद है, तो कंटेंट-लेंथ को उसी संदेश शरीर को परिभाषित नहीं करना चाहिए। विरोधाभासी फ्रेमिंग मेटाडेटा खतरनाक होता है क्योंकि विभिन्न मध्यवर्ती यह असहमत हो सकते हैं कि अनुरोध या प्रतिक्रिया कहाँ समाप्त होती है।
  2. हेक्साडेसिमल आकार को पार्स करें। प्रत्येक चंक एक या एक से अधिक हेक्साडेसिमल अंकों के साथ शुरू होता है। मान डेटा ऑक्टेट्स की संख्या को गिनता है, दृश्यमान वर्ण नहीं। इसलिए मल्टीबाइट फ़ॉन्ट को JavaScript स्ट्रिंग की लंबाई या वर्ण की गिनती से मापना संभव नहीं है; फ्रेमिंग को उस तरह से बाइट्स पर कार्य करता है जैसा कि प्रसारित किया गया था।
  3. डेटा और सीमांकक को सही ढंग से लें। आकार की पंक्ति के बाद, पार्सर घोषित संख्या में ऑक्टेट्स का उपभोग करता है और फिर आवश्यक पंक्ति समाप्ति। आकार की असंगति, अनुपस्थित सीमांकक, या शून्य चंक से पहले कनेक्शन बंद होने से संदेश अधूरा हो जाता है। अच्छी तरह से परीक्षण किए गए HTTP पुस्तकालय इस सीमा तार्किक को संभालते हैं इससे पहले कि वे शरीर को अनुप्रयोग कोड में उजागर करें।
  4. आखिरी चंक के साथ समाप्त करें। एक शून्य आकार का चंक चंक अनुक्रम को समाप्त करता है। एक वैकल्पिक ट्रेलर अनुभाग अंतिम खाली रेखा से पहले आ सकता है, लेकिन ट्रेलर्स केवल उन क्षेत्रों के लिए उपयुक्त होते हैं जिन्हें स्ट्रीमिंग के बाद गणना की जा सकती है। वे उन हेडर्स को ठीक नहीं करते जिन्हें प्रापक शरीर पढ़ने से पहले की जरूरत है।

वास्तविक प्रणालियों में चंक्ड ट्रांसफर एनकोडिंग

उत्पन्न प्रतिक्रियाएँ

एक सर्वर एक बड़ा निर्यात भेजना शुरू कर सकता है जबकि डेटाबेस क्वेरी अभी भी पंक्तियों का उत्पादन कर रही है, जिससे ग्राहक को उपयोगी बाइट्स प्राप्त करने से पहले का समय कम होता है।

रिवर्स-प्रॉक्सी पाइपलाइन्स

एक गेटवे क्लाइंट की ओर अपस्ट्रीम डेटा को स्ट्रीम कर सकता है बिना पूरी प्रतिनिधित्व को बफर किए, इसके अपने रूपांतरण और बफरिंग सेटिंग्स के अधीन।

सर्वर-भेजा आउटपुट

प्रगतिशील पाठ या इवेंट-जैसी आउटपुट HTTP/1.1 कनेक्शन पर टुकड़ों में आ सकती है, भले ही एप्लिकेशन एक तार्किक प्रतिक्रिया शरीर का उपभोग करती हो।

अज्ञात अंतिम आकार

टेम्प्लेट, संपीड़न धाराएं और समग्र सेवाएं उत्पन्न होने पर एन्कोडेड बाइट की गिनती नहीं जान सकती हैं, जिससे प्री-कंप्यूटेड कंटेंट-लेंग्थ अप्रभावी हो जाता है।

चंक्ड एन्कोडिंग की तुलना निकटवर्ती अवधारणाओं से

एक साथ-साथ का दृश्य निकटवर्ती अवधारणाओं को इंटरचेंजेबल के रूप में व्यवहार करने से रोकता है। संदर्भ का उपयोग करें यह पहचानने के लिए कि कौन सा अनुबंध सक्रिय है, 클ाइंट या सर्वर व्यवहार बदलने से पहले।

अवधारणा या संकेतअर्थसंचालन नोट
सामग्री-लंबाईस्थानांतरण से पहले पूरी शारीरिक आकार को घोषित करता हैजब एन्कोडेड लंबाई ज्ञात और स्थिर हो, तब उपयोग करें
चंक्ड ट्रांसफर कोडिंगएक HTTP/1.1 शरीर को आकार के चंक के रूप में फ्रेम करता हैजब अंतिम आकार भेजने से पहले ज्ञात नहीं हो, तब उपयोग करें
कनेक्शन बंदशरीर सीमा के रूप में सॉकेट बंदन का उपयोग करता हैऐसा धरोहर गिरावट जो कनेक्शन पुन: उपयोग को रोकता है
सामग्री-एन्कोडिंगप्रतिनिधित्व बाइट को परिवर्तित करता है, जैसे कि संपीड़नसंदेश फ्रेमिंग से स्वतंत्र
HTTP/2 डेटा फ्रेमप्रोटोकॉल फ्रेम में शरीर बाइट ले जाता हैHTTP/2 लिंक पर HTTP/1.1 चंक्ड फ्रेमिंग को प्रतिस्थापित करता है

चंक्ड ट्रांसफर एन्कोडिंग डायग्नोसिस और संचालन डिजाइन

जब एक चंक्ड प्रतिक्रिया भीलती हुई लगती है, तो पहले पहचानें कि कौन सा हॉप विफलता का उत्पादन करता है। ब्राउज़र विकास उपकरण आमतौर पर अवसादित शरीर को दिखाते हैं, जबकि एक पैकेट कैप्चर या विस्तृत कमांड-लाइन क्लाइंट वायर-स्तरीय आकार की रेखाएँ प्रकट कर सकता है। स्रोत, गेटवे, सामग्री-डिलीवरी नेटवर्क, और क्लाइंट लॉग की तुलना अनुरोध पहचानकर्ता द्वारा कीजिए। एक पूरा एप्लिकेशन पेलोड अभी भी एक प्रॉक्सी टाइमआउट द्वारा काटा जा सकता है, और एक सही शून्य चंक अभी भी एक अनुप्रयोग दस्तावेज़ को संलग्न कर सकता है जो तार्किक रूप से अधूरा है।

एक सामान्य HTTP क्लाइंट द्वारा लौटाई गई प्रतिक्रिया को मैन्युअल रूप से डीकंच न करें। परिपक्व क्लाइंट परिवहन फ्रेमिंग को हटा देते हैं और एक बाइट स्ट्रीम या अवसादित शरीर को उजागर करते हैं। चंक मार्कर को फिर से पार्स करना वैध सामग्री को भ्रष्ट कर सकता है जिसमें हेक्साडेसिमल रेखाएँ होती हैं। मैन्युअल पार्सिंग प्रोटोकॉल परीक्षणों, नेटवर्क निदान, सर्वर, प्रॉक्सी और विशेषीकृत क्लाइंट में होती है जहां कच्चे बाइट जानबूझकर उपलब्ध होते हैं।

सुरक्षा समीक्षा को अस्पष्ट फ्रेमिंग को प्रोटोकॉल समस्या के रूप में मानना चाहिए, न कि सजावटी हेडर समस्या के रूप में। एक संदेश जो विपरीत लंबाई संकेत ले जाता है, उसे निकटवर्ती प्रणालियों के द्वारा अलग-अलग तरीके से व्याख्या किया जा सकता है। विश्वसनीय सीमाओं पर आने वाले अनुरोधों को सामान्य बनाएं, विकृत फ्रेमिंग को अस्वीकार करें, प्रॉक्सी और स्रोत व्यवहार को समन्वित रखें, और अस्पष्ट संदेशों को एप्लिकेशन स्टैक में गहराई से पास करने से बचें।

चंक्ड ट्रांसफर एन्कोडिंग कार्यान्वयन चेकलिस्ट

नीचे की चेकलिस्ट अवधारणा को सत्यापित इंजीनियरिंग कार्य में बदल देती है। केवल उन आइटम को लागू करें जो सक्रिय प्रोटोकॉल और उत्पाद अनुबंध से मेल खाते हैं, लेकिन साक्ष्य को एक साथ रखें ताकि अन्य इंजीनियर निर्णय को पुनः निर्मित कर सकें।

  • प्रत्येक प्रासंगिक हॉप पर बातचीत की गई HTTP संस्करण की पुष्टि करें, न कि इसे ब्राउज़र URL से निकाला जाए।
  • ट्रांसफर-एन्कोडिंग और सामग्री-लंबाई का साथ में निरीक्षण करें; वैध फ्रेमिंग को प्राप्तकर्ताओं को विपरीत सीमाओं के बीच चयन करने के लिए नहीं कहना चाहिए।
  • अगर कच्ची पार्सिंग प्रणाली के परीक्षण का हिस्सा है, तो चंक आकारों को ऑक्टेट में मापें और आवश्यक पंक्ति समाप्तियों को मान्य करें।
  • यह रिकॉर्ड करें कि गेटवे क्या बफर करते हैं, अपरिपक्व करते हैं, या शरीर को पुनर्गठित करते हैं क्योंकि ये चरण नीचे की ओर के उपकरणों द्वारा देखे जाने वाले पर्यवेक्षण को बदल देते हैं।
  • अधूरा संदेशों के लिए क्लाइंट, प्रॉक्सी, और स्रोत साक्ष्य को जोड़ने के लिए अनुरोध पहचानकर्ताओं का उपयोग करें।
  • किसी नियंत्रित वातावरण में जल्दी कनेक्शन बंद और विकृत अंतिम चंक का परीक्षण करें ताकि विफलताएँ स्पष्ट रहें।
  • मानक HTTP पुस्तकालयों को अनुप्रयोग कोड के लिए अवसादित शरीर प्रकट करने दें जब तक प्रोटोकॉल कार्यान्वयन वास्तविक कार्य न हो।

कार्यान्वयन के बाद, सामान्य व्यवहार, सीमाओं, विकृत इनपुट, अनुपस्थित राज्य, समानांतर गतिविधि, और जानबूझकर पहुँच अस्वीकृति का परीक्षण करें। प्रत्येक मामले के लिए अपेक्षित स्थिति, शरीर का आकार, अंत की स्थिति, और राज्य परिवर्तन को रिकॉर्ड करें। उत्पादन मॉनिटरिंग को परीक्षण के दौरान उपयोग किए गए समान मापदंडों की रिपोर्ट करनी चाहिए ताकि एक घटना की तुलना ज्ञात बुनियादी रेखा से की जा सके।

प्रलेखन को इंटरफ़ेस के प्रत्येक पक्ष पर जिम्मेदारी का नाम देना चाहिए। क्लाइंट को आवश्यक फील्ड, स्थिर पहचानकर्ता, क्रमबद्धता के नियम, सीमाएँ, अंतिम संकेत, और त्रुटि अर्थों की आवश्यकता होती है। ऑपरेटरों को आंतरिक नीति, भंडारण या रूटिंग निर्णय, अवलोकन फील्ड, और सुरक्षित सार्वजनिक प्रतिक्रिया की आवश्यकता होती है। अस्पष्ट अनुबंध टीमें को गलत स्तर पर दृश्य लक्षण को ठीक करने का कारण बनती हैं।

चंक्ड ट्रांसफर एन्कोडिंग के सामान्य गलतियाँ

किसी भी क्षेत्र से सफलता, अनुपस्थिति, अनुमति, क्रमबद्धता, या पूर्णता की व्याख्या न करें बिना चारों ओर अनुबंध। स्थिति कोड, टोकन, पृष्ठ आकार, और परिवहन हेडर संदर्भ प्रश्न का उत्तर देते हैं। प्रतिक्रिया शरीर, विधि, पहचान, फ़िल्टर, प्रोटोकॉल संस्करण, और सर्वर प्रलेखन शेष अर्थ प्रदान करते हैं।

सरलता के नाम पर निदान संदर्भ को न हटाएं। एक छोटा लॉग लाइन जो अनुरोध पहचानकर्ता, लक्ष्य, संस्करण, दायरा, या सीमा को छोड़ देता है, उसे एक छोटे दोष को घंटों की अनुमान के काम में बदल सकता है। साथ ही, अवलोकनीयता को क्रेडेंशियल्स, सत्र रहस्यों, हस्ताक्षरित यूआरएल, और संवेदनशील पेलोड फ़ील्ड को हटाना चाहिए।

एक अस्थायी संचालन समाधान को स्थायी अनुबंध में न बदलें। अंतर्निहित अनुक्रम, अनुमति, राउटिंग, गति, फ्रेमिंग, या त्रुटि-मैपिंग समस्या को सही करें और एक प्रतिगमन जांच जोड़ें। एक प्रणाली तब विश्वसनीय हो जाती है जब विफलता स्पष्ट और सीमित होती है, न कि जब एक मैन्युअल दौड़ पूरा होती है।

निष्कर्ष

चंक्ड ट्रांसफर एन्कोडिंग एक सटीक HTTP/1.1 समस्या को हल करती है: एक शरीर को सीमांकित करने के लिए जिसकी अंतिम बाइट लंबाई भेजने से पहले ज्ञात नहीं होती। इसके हेक्साडेसिमल आकार, डेटा खंड, शून्य चंक, और वैकल्पिक ट्रेलर्स एक ही हॉप पर परिवहन फ्रेमिंग से संबंधित होते हैं। अनुप्रयोग आमतौर पर अवसादित शरीर का उपभोग करते हैं, जबकि ऑपरेटर कच्चे चंक का निरीक्षण केवल तब करते हैं जब अधूरे प्रतिक्रियाओं, प्रॉक्सी परिवर्तनों, या फ्रेमिंग संघर्षों का पता लगाने में।

क्या एक अधिक विश्वसनीय डेटा वर्कफ़्लो बनाने के लिए तैयार हैं?

इस मार्गदर्शिका में प्रोटोकॉल के सिद्धांतों को एक दस्तावेजित Scrapeless उत्पाद सतह से जोड़ें और प्रत्येक अनुरोध को प्रस्तुतिकरण से परिणाम तक मापने योग्य रखें।

आज साइन अप करें और पाएं $5 का मुफ्त क्रेडिट — कोई क्रेडिट कार्ड आवश्यक नहीं.

अपना $5 क्रेडिट प्राप्त करें →

अक्सर पूछे जाने वाले प्रश्न

क्या चंक्ड ट्रांसफर एन्कोडिंग स्ट्रीमिंग के समान है?

नहीं। चंक्ड ट्रांसफर एन्कोडिंग एक HTTP/1.1 फ्रेमिंग तंत्र है जो प्रगतिशील वितरण का समर्थन कर सकता है, लेकिन स्ट्रीमिंग एक विस्तृत अनुप्रयोग व्यवहार है। HTTP/2 और HTTP/3 अपने स्वयं के फ्रेम सिस्टम के माध्यम से प्रतिक्रिया डेटा स्ट्रीम कर सकते हैं बिना Transfer-Encoding: chunked हेडर के।

क्या चंक्ड प्रतिक्रिया में Content-Length भी शामिल हो सकता है?

एक वैध HTTP/1.1 संदेश को तब फ्रेम में Content-Length का उपयोग नहीं करना चाहिए जब Transfer-Encoding फ्रेमिंग को परिभाषित करता है। विरोधाभासी संकेत अस्पष्टता उत्पन्न करते हैं और इन्हें विश्वसनीय सीमा पर अस्वीकार या सामान्यीकृत किया जाना चाहिए।

क्या प्रत्येक चंक JavaScript में दिखाई देता है?

आम तौर पर नहीं। ब्राउज़र और HTTP क्लाइंट पुस्तकालय चंक फ्रेमिंग को प्रतिक्रिया डेटा को उजागर करने से पहले डिकोड करते हैं। अनुप्रयोग कोड स्ट्रीम सेगमेंट प्राप्त कर सकता है, लेकिन ये सेगमेंट उस तार चंकों से मेल नहीं खा सकते जो प्रेषक या किसी मध्यस्थ द्वारा चुने गए हैं।

शून्य आकार का चंक का क्या मतलब है?

शून्य आकार का चंक चंक अनुक्रम के अंत को चिह्नित करता है। वैकल्पिक ट्रेलर फ़ील्ड इसके बाद आ सकते हैं, और एक अंतिम खाली पंक्ति संदेश को पूर्ण करती है। यदि कनेक्शन जल्दी समाप्त होता है, तो प्राप्तकर्ता को शरीर को अधूरा मान लेना चाहिए।

प्रॉक्सी के माध्यम से चंक सीमाएँ क्यों बदलती हैं?

ट्रांसफर कोडिंग चरण दर चरण होती है, इसलिए एक प्रॉक्सी शरीर को डिकोड, बफर, ट्रांसफॉर्म और पुनःफ्रेम कर सकता है। डाउनस्ट्रीम चंक आकार अपस्ट्रीम आकारों से भिन्न हो सकते हैं, भले ही अनुप्रयोग को वितरित प्रतिनिधित्व समान हो।

संदर्भ