ویب ڈویلپمنٹ میں 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 کے مطابق، تمام HTTP جوابات کا تقریباً 35% Transfer-Encoding: chunked استعمال کرتا ہے۔ ان میں متحرک صفحات (60%)، API جوابات (25%) اور میڈیا سٹریمز (15%) غالب ہیں۔ جامد فائلیں تقریباً ہمیشہ Content-Length استعمال کرتی ہیں کیونکہ ان کا حجم پہلے سے معلوم ہوتا ہے۔ چانکڈ جوابات کا حصہ HTTP/2 کو اپنانے کے ساتھ آہستہ آہستہ کم ہو رہا ہے، جہاں سٹریمنگ اضافی Transfer-Encoding ہیڈر کی ضرورت کے بغیر فریم سطح پر نافذ کی جاتی ہے۔
عملی سفارشات
موبائل ڈویلپمنٹ میں، بڑی فائلیں (تصاویر، ویڈیو) ڈاؤن لوڈ کرنے اور بڑے ڈیٹا arrays واپس کرنے والی API درخواستوں کے لیے Chunked Transfer استعمال کریں۔ OkHttp اضافی ترتیب کے بغیر چانک ٹرانسفر کو مکمل طور پر سپورٹ کرتا ہے۔ سرور پر اپ لوڈ کے لیے Chunked Transfer استعمال نہیں ہوتا — HTTP/1.1 میں اپ لوڈ کے لیے Transfer-Encoding نہیں ہے۔ iOS پر، URLSession خصوصی ترتیب کے بغیر چانکڈ ڈیٹا بھیجنے اور وصول کرنے دونوں کو سپورٹ کرتا ہے۔ سٹریمنگ JSON پارسنگ (Jackson Streaming API یا Moshi کے ذریعے) چانکڈ سٹریم میں آنے پر بڑے JSON arrays کی پروسیسنگ کی اجازت دیتا ہے۔
اکثر پوچھے گئے سوالات
سرور 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 اور چانکڈ باہمی مخصوص ہیں — تصریح ان ہیڈرز کے بیک وقت استعمال کو منع کرتی ہے۔
- فوائد — کم تاخیر، میموری کی بچت، لامحدود سٹریمز منتقل کرنے کی صلاحیت اور کلائنٹ کی جانب سٹریمنگ پروسیسنگ۔
- حدود — حصہ ہیڈرز کا اوور ہیڈ، پیش رفت دکھانے میں ناکامی، پرانے پراکسی سرورز کے ساتھ مسائل۔
ہم ایک موبائل ایپلیکیشن ٹرنکی تیار کریں گے
IT Sectr 2017 سے اسٹارٹ اپس اور کاروبار کے لیے iOS اور Android ایپلیکیشنز بناتا ہے۔ ہم آپ کو مشورہ دیں گے اور بہترین حل تجویز کریں گے۔
مزید پڑھیں