ওয়েব ডেভেলপমেন্টে 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: 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 হেডারের প্রয়োজন ছাড়াই বাস্তবায়িত হয়।
ব্যবহারিক সুপারিশ
মোবাইল ডেভেলপমেন্টে, বড় ফাইল (ছবি, ভিডিও) ডাউনলোড করতে এবং বড় ডেটা অ্যারে ফেরত দেয় এমন 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 অ্যাপ্লিকেশন তৈরি করে। আমরা আপনাকে পরামর্শ দেব এবং সেরা সমাধান প্রস্তাব করব।
আরও পড়ুন