প্রক্সির মাধ্যমে TCP শূন্য উইন্ডো: গ্রাহক চিহ্নিত করুন
স্থবির ডাউনলোডকে উইন্ডো স্কেলিং বা বাফার আকারের জন্য দায়ী করার আগে প্রক্সির ক্লায়েন্ট বা সার্ভার দিকে TCP প্রবাহ নিয়ন্ত্রণ চিহ্নিত করুন।
প্যাকেট ট্রেস দেখায় TCP ZeroWindow। কার্নেল সেটিং বদলানোর আগে শূন্যটি ঘোষণা করা প্রান্তটি চিহ্নিত করুন।
সেই প্রান্তটি এই TCP সংযোগে তার গ্রহণ ক্ষমতা বর্ণনা করছে। এটি পুরো প্রক্সির কত ব্যান্ডউইথ আছে তা ঘোষণা করছে না। শূন্য-উইন্ডো প্রোব প্রেরককে জানতে দেয় ঘোষিত ক্ষমতা বদলেছে কি না; প্রোব একা প্যাকেট হারানো বা ভাঙা প্রক্সি প্রমাণ করে না।
browser <-- TCP A --> proxy <-- TCP B --> websiteএগুলি আলাদা TCP কথোপকথন। ধরা যাক ব্রাউজার একটি বড় প্রতিক্রিয়া পড়া বন্ধ করে A-তে শূন্য ঘোষণা করল। প্রক্সি নিজের বাফার ভরে গেলে শেষে B নিঃশেষ করা বন্ধ করতে পারে। B-তে পরের শূন্য উইন্ডো মূল সমস্যার বদলে ধীর ক্লায়েন্টের ফলাফল হতে পারে।
আপলোডের সময় বিপরীত অবস্থাও সম্ভব। গন্তব্য অ্যাপ্লিকেশন তথ্য গ্রহণ বন্ধ করলে B-তে তার উইন্ডো বন্ধ হতে পারে। তখন চাপ প্রক্সির বাফার দিয়ে ক্লায়েন্টের দিকে ফিরে যেতে পারে।
পর্যবেক্ষণগুলি ক্রমে রাখুন
- সংযোগের প্রান্ত দুটি ও প্রভাবিত তথ্য স্থানান্তরের দিক লিখে রাখুন।
- কোন প্রান্ত প্রথমে সংকুচিত বা শূন্য গ্রহণ উইন্ডো ঘোষণা করেছে চিহ্নিত করুন।
- এর অ্যাপ্লিকেশন পড়ছিল কি না, অন্য কাজে থেমে ছিল কি না, বা সম্পদে সীমিত ছিল কি না দেখুন।
- মূল কারণ নির্ধারণের আগে প্রক্সির অন্য সংযোগের সময়ের সাথে তুলনা করুন।
Wireshark-এর উইন্ডো বিশ্লেষণ লেবেল ক্যাপচারের সহায়ক ব্যাখ্যা, প্রতিটি গ্রহণ বাফার বাড়ানোর নির্দেশ নয়। উইন্ডো স্কেলিংও সংযোগের আলোচনার প্রেক্ষিতে ব্যাখ্যা করতে হবে।
প্রক্সি তালিকা থেকে অন্য প্রান্ত চেষ্টা করে স্থানান্তর ফিরে আসা দেখা পথ বদলানোর সহায়ক প্রমাণ। তবে এটি নিজে থেকে প্রমাণ করে না যে কোনো অপারেটিং সিস্টেমের TCP বাস্তবায়ন ত্রুটিপূর্ণ ছিল। ব্যাখ্যাটি গ্রহণ প্রক্রিয়া ও যে সংযোগে অপেক্ষা শুরু হয়েছিল তার সাথে যুক্ত রাখুন।