উষ্ণ HTTPS বনাম উষ্ণ VPN: একই অনুরোধ পথ তুলনা করুন

আপনি সম্ভবত পড়েছেন যে HTTPS প্রতিটি API অনুরোধের জন্য নতুন TCP সংযোগ ও নতুন TLS হ্যান্ডশেক খোলে, তাই এক ঘণ্টা খোলা থাকা টানেল সস্তা দেখায়। এর প্রথম অর্ধেক সাধারণত ভুল। সমর্থিত ক্লায়েন্ট অনেক বিনিময়ের জন্য প্রতিষ্ঠিত সংযোগ পুনরায় ব্যবহার করে, আর প্রতিটি কলে নতুন ক্লায়েন্ট বানানো পরিমাপ জীবনচক্র মাপে, সুরক্ষা নয়। এই পাতার বাকি অংশে বলা হয়েছে এর বদলে কী মাপা উচিত।

পুনরায় ব্যবহার আসলে কী দাবি করে

স্থায়িত্ব HTTP মডেলের অংশ, কৌশল নয়: একটি সংযোগ একাধিক অনুরোধ-প্রতিক্রিয়া বিনিময় বহন করে। সংযোগ শেষ হয় যখন দুই পক্ষের একটি তা বন্ধ করে, যখন সার্ভার নিষ্ক্রিয় বা অতিরিক্ত বোঝাই সংযোগ সরিয়ে নেয়, অথবা যখন হেডার বা প্রোটোকল নিয়ম বলে সংযোগটি পুনরায় ব্যবহার করা যাবে না। HTTPS সেই আলাপচারিতা প্রতিটি বিনিময়ের জন্য নতুন হ্যান্ডশেক দাবি না করেই TLS-এর ভিতরে রাখে। তাই দ্বিতীয় অনুরোধ প্রথম অনুরোধের হ্যান্ডশেক পুনরাবৃত্তি করে না, যদি না মাঝপথে কিছু সংযোগটি শেষ করে দেয়।

পুনরায় ব্যবহারের একটি শর্তও আছে যা অ্যাপ্লিকেশন সহজেই ভাঙে। যে ক্লায়েন্ট সংযোগ পুনরায় ব্যবহারের পরিকল্পনা করে তাকে প্রতিক্রিয়ার সম্পূর্ণ বডি পড়তে হয়, আর অর্ধেক পথে পরিত্যক্ত প্রতিক্রিয়া হলো সংযোগ পুল নিঃশব্দে হারিয়ে যাওয়ার সাধারণ উপায়।

লাইব্রেরির সমর্থিত ক্লায়েন্ট ও সংযোগ পুলের জীবনচক্র পরীক্ষা করুন, পুল চালু বা বন্ধ ধরে নেবেন না। সমঝোতায় আসা HTTP সংস্করণও লিখে রাখুন, কারণ HTTP/2 ও HTTP/3 সংযোগ পুনরায় ব্যবহার HTTP/1.1 থেকে ভিন্নভাবে সামলায়। সমঝোতায় আসা সংস্করণকে পরিমাপের অংশ মনে করুন, পাদটীকা নয়।

কেন তুলনা জীবনচক্র মাপে

প্রতিটি কাজের জন্য নতুন ক্লায়েন্ট তৈরি করা এবং এক ঘণ্টা ধরে সংযুক্ত একটি টানেলের সঙ্গে তুলনা করা সংযোগ স্থাপনকে স্থির অবস্থার সঙ্গে তুলনা করে। এটি বৈধ পরিমাপ, আর এটি HTTPS বনাম VPN নয়। একই ক্লায়েন্ট কনফিগারেশনে দুটি রান একটির চেয়ে আচরণ ভালোভাবে বর্ণনা করে, বিশেষত যখন প্রথম রান কোনো রিজলভার বা সংযোগ ক্যাশ গরম করে।

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

ঠান্ডা স্থাপনাকে উষ্ণ অনুরোধ থেকে আলাদা করুন

প্রথম অনুরোধ পরেরগুলো থেকে আলাদাভাবে মাপুন। তারপর যোগ করুন যা সেবাটি সত্যিই দেখে: নিষ্ক্রিয় সময়, বিস্ফোরণ, সমকালীনতা, প্রতিক্রিয়ার আকার ও পুনঃসংযোগ।

উভয় পথে সার্টিফিকেট যাচাই ও HTTPS চালু রাখুন, কারণ সেগুলো সরানো ভিন্ন নিরাপত্তা নকশা মাপে, দ্রুততর নয়। টানেল যদি রুট বা গেটওয়ের অবস্থান বদলায়, তবে প্রতিটি সময় পরিবর্তনকে এনক্রিপশনের জন্য আরোপ করার বদলে সেই পার্থক্য আলাদাভাবে জানান, কারণ পথ, ক্ষতি ও সারি একটি ছোট অনুরোধে প্রাধান্য পেতে পারে। সিদ্ধান্তে পৌঁছানোর আগে প্রতিটি পথ একই রুটে দুবার চালান। সমঝোতায় আসা প্রোটোকল ও টাইমারের সীমা দুই রানের সঙ্গে লিখে রাখুন।

বন্ধ হওয়া সংযোগের জন্য পরিকল্পনা করুন

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

সকেট আবার খোলা একটি লুপের বদলে সেবার নথিভুক্ত পুনঃচেষ্টা বা আইডেম্পোটেন্সি ব্যবস্থা ব্যবহার করুন। পুনরুদ্ধার স্পষ্টভাবে পরীক্ষা করুন: একটি নিষ্ক্রিয় সংযোগ বন্ধ করে দেখুন ক্লায়েন্ট এরপর কী করে। সকেট আবার খোলা অবস্থা পরিবর্তনকারী কল পুনরাবৃত্তি নিরাপদ করে না।

আগে সীমা বেছে নিন, তারপর সমন্বয় করুন

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

RFC 9112-এর স্থায়িত্ব অংশ হলো পুনরায় ব্যবহার আসলে কী প্রতিশ্রুতি দেয় তার সূত্র, যার মধ্যে সংযোগ শেষ করার শর্তগুলোও আছে। এমন একটি পরিমাপে ভরসা করার আগে এটি একবার পড়ুন যা সেগুলো উপেক্ষা করে।