অনুরোধ, সংযোগ ও সেশন জুড়ে প্রক্সি রোটেশন
প্রতিটি অ্যাপ্লিকেশন অনুরোধে Connection: close যোগ করার আগে ঘূর্ণায়মান প্রক্সি পরিষেবা আসলে কী ঘোরায় তা যাচাই করুন।
একই গেটওয়ে দিয়ে করা দ্বিতীয় অনুরোধ বৈধভাবে একই পাবলিক IP ব্যবহার করতে পারে। পরিষেবাটি তার রোটেশনের জন্য কোন জীবনকাল ব্যবহার করে তা যাচাই করুন:
| রোটেশনের একক | কী তুলনা করবেন |
|---|---|
| অনুরোধ | পরবর্তী অ্যাপ্লিকেশন কার্যক্রম এবং তার পর্যবেক্ষিত প্রস্থান |
| সংযোগ | ক্লায়েন্ট উপযুক্ত সংযোগ পুনরায় ব্যবহার করেছে না নতুন একটি খুলেছে |
| প্রদানকারীর সেশন | নথিভুক্ত স্টিকি-সেশন ইনপুট এবং তার জীবনকাল |
Connection: close কোনো সার্বজনীন গেটওয়ে নির্দেশ নয়। CONNECT-এর ভিতরে HTTPS-এর ক্ষেত্রে ওয়েবসাইটের অনুরোধ হেডার গন্তব্যের TLS-এর ভিতরে যায়। এটি বাইরের প্রক্সিকে বলে না কোন পাবলিক IP বরাদ্দ করতে হবে। HTTP/1.1-এর সংযোগ-নির্দিষ্ট অর্থও প্রতিটি HTTP সংস্করণ বা পরিবহনে অপরিবর্তিতভাবে বহন করা যায় না।
যদি নথিভুক্ত প্রতি-সংযোগ পরিষেবার নতুন সংযোগ প্রয়োজন হয়, ক্লায়েন্টের সমর্থিত জীবনচক্র নিয়ন্ত্রণ ব্যবহার করুন এবং বারবার TCP/TLS স্থাপনের ব্যয় হিসাব করুন। যদি রোটেশন প্রদানকারীর সেশন অনুসরণ করে, পুনরায় সংযোগ সেই সেশন ও তার প্রস্থান দুটোই ধরে রাখতে পারে।
অনুরোধের পরিচয়ক, এন্ডপয়েন্ট, প্রাসঙ্গিক সেশন কী এবং গন্তব্যে পর্যবেক্ষিত উৎস আলাদাভাবে লিপিবদ্ধ করুন। সংযোগ বন্ধ করা কেবল সেই জীবনচক্র ঘটনাটি প্রতিষ্ঠা করে; পরবর্তী কার্যক্রমের জন্য বাছাই করা প্রস্থানটি পরিষেবার প্রকৃত রোটেশন চুক্তির বিপরীতে যাচাই করুন।