ফরওয়ার্ড প্রক্সি স্ট্রিমিং বনাম সম্পূর্ণ-রেসপন্স বাফারিং

ডাউনলোড অপেক্ষা করছে মনে হলে তিনটি ঘটনা আলাদা করুন: রেসপন্স হেডার আসা, বডি বাইট আসা, এবং অ্যাপ্লিকেশন ফলাফল ব্যবহার বা রেন্ডার করতে পারা। শুধু স্পিনার কোনটি বিলম্বিত তা চিহ্নিত করতে পারে না।

স্বাভাবিক স্ট্রিমিং ধাপগুলো ওভারল্যাপ করতে পারে:

origin produces a chunk → proxy forwards bytes → client consumes them

প্রক্সি রিলে করার সময় উপযুক্ত কনটেন্ট ক্যাশে লিখতে পারে। ক্যাশিং পুরো ফাইলের জন্য অপেক্ষা করে না। Squid-এর read_ahead_gap ডেলিভারির আগে চলা রিট্রিভ্যাল নিয়ন্ত্রণ করে, যা আরেক ধরনের বাফারিং।

ধীর ক্লায়েন্ট আউটপুট কিউ ভরিয়ে ফেললে ব্যাকপ্রেশার আপস্ট্রিম পড়া সাময়িকভাবে থামাতে পারে। Content-Length-ও পূর্ণ বাফারিং ছাড়াই দৈর্ঘ্য দেয়। HTTP/1.1 chunked এনকোডিং ক্রমবর্ধমান ডেলিভারি দেয়, কিন্তু আগের কোনো কম্পোনেন্ট ডেটা ধরে রাখলে কম লেটেন্সির প্রতিশ্রুতি দিতে পারে না।

এরপর প্রক্রিয়াকরণ ধাপ দেখুন। পুনর্লিখন বা পরিদর্শনের জন্য বডির অংশ বা সম্পূর্ণ অংশ লাগতে পারে। কম্প্রেশন ও অ্যাপ্লিকেশন ফ্রেমিং উপযোগী আউটপুট বিলম্বিত করতে পারে। ক্লায়েন্টে সম্পূর্ণ বাইট অ্যারে চাওয়া মেথড ফেরার আগে অপেক্ষা করে, আর ব্রাউজার রেন্ডার করার আগেই বাইট পেতে পারে।

সফল CONNECT-এর পর সাধারণ প্রক্সি টানেল করা ফাইলের চূড়ান্ত দৈর্ঘ্য না জেনেই সার্ভিস স্ট্রিম রিলে করে। বাফার বা টাইমআউট সেটিং বদলানোর আগে উপরের প্রথম অনুপস্থিত ঘটনাটি অনুসরণ করুন। curl পর্যবেক্ষক হলে এর no-buffer অপশন স্থানীয় আউটপুট ধাপ বদলায়।