VPN কি সরাসরি সংযোগের চেয়ে দ্রুত হতে পারে?

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

টানেল যে তিনটি জিনিস বদলাতে পারে

প্রথমটি ট্রানজিট। ইন্টারনেট রাউটিং মাপা বিলম্ব নয়, অপারেটরের নীতি আর ব্যবসায়িক সম্পর্ক অনুসরণ করে, তাই VPN সরবরাহকারীর মধ্য দিয়ে পথ সরাসরি পথের চেয়ে আলাদা নেটওয়ার্ক পার হতে পারে। এটি ভিড় করা এক্সচেঞ্জ এড়াতে পারে বা ভালো পিয়ারিংযুক্ত এক্সচেঞ্জে পৌঁছাতে পারে, আবার সমান সহজে খারাপও হতে পারে।

দ্বিতীয়টি গন্তব্য। প্রস্থানের ঠিকানা বদলালে প্রায়ই DNS উত্তর বদলে যায়, আর কোনো কনটেন্ট নেটওয়ার্ক আপনাকে ভিন্ন ক্যাশ বা অঞ্চল দিতে পারে। তখন উন্নতির একটি অংশ টানেলের নয়, নতুন সার্ভারের। একই হোস্টনাম ক্লায়েন্টে কিছু না বদলেও আরও কাছের বা কম বোঝাই সার্ভারে পৌঁছাতে পারে।

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

যা এটি বদলাতে পারে না

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

সার্ভার-পক্ষের সীমাও সমান উদাসীন। দূরের হোস্ট ধীরে সেবা দিলে ভালো পথ কেবল ধীর উত্তরকে বেশি দক্ষভাবে পৌঁছায়, আর ব্যবহারকারী তখনও অপেক্ষা করে। চাপে থাকা ভাগাভাগি উৎস একই মুহূর্তে দুই পথেই ধীর দেখায়।

পথগুলো ঠিকভাবে তুলনা করুন

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

mtr -rwc 50 -T -P 443 203.0.113.20
curl -o /dev/null -s -w '%{speed_download} %{time_connect}\n' https://example.com/file
dig +short cdn.example.com
traceroute -n -T -p 443 cdn.example.com

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

কখন পার্থক্যটি রাখার যোগ্য

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

মাপের রেকর্ডটি কনফিগারেশনের সঙ্গে রাখুন। এটি পরের প্রশ্নের উত্তর দেয়—উন্নতিটি এখনও আছে কি না, আর পথ বদলেছে কি কাজের চাপ বদলেছে তা জানার একমাত্র উপায় এটিই। তারিখ ছাড়া রেকর্ড সেই প্রশ্নের উত্তর দিতে পারে না।