ছোট VPN MTU কি দ্রুততর? প্রকৃত প্রমাণ তুলনা করুন
কম MTU পথের সীমা এড়াতে পারে, তবুও থ্রুপুট খরচ করতে পারে। পরিবর্তনটি রাখার আগে প্রকৃত সীমাবদ্ধতা, প্যাকেটের ওভারহেড ও কাজের ভার তুলনা করুন।
টানেল বড় স্থানান্তর ফেলে দেয় কিন্তু পিং পার করে, তাই পরামর্শ দ্রুত আসে: MTU কমান। সমাধানটি মাঝে মাঝে কাজ করে, তারপর প্রতিটি নেটওয়ার্কে প্রতিটি প্রোফাইলে প্রয়োগ করা হয়। এই বিন্দুতেই একটি লক্ষ্যভিত্তিক মেরামত স্থায়ী কর্মক্ষমতা কর হয়ে ওঠে। যে তুলনাটি করতে হবে তা হলো পথের প্রকৃত সীমা এবং এর নিচে প্রতিটি প্যাকেট ছোট করার খরচের মধ্যে।
MTU কমালে আসলে কী ছোট হয়
প্রতিটি প্যাকেট আপনার ডেটার আগে হেডার বহন করে। 1500 বাইটের ইথারনেট পথে IPv4 ও TCP 40 বাইট নেয়, পেলোডের জন্য 1460 রাখে; এনক্যাপসুলেশন উপরে বহিঃস্থ IP, UDP ও টানেল হেডার যোগ করে, তাই ভেতরের পেলোড বাজেট আবার কমে। ইন্টারফেসের MTU কমানো সেই বাজেট ইচ্ছাকৃতভাবে ছোট করে।
খরচ বাইটের সংখ্যার সাথে নয়, প্যাকেটের সংখ্যার সাথে সমানুপাতিক। একই ফাইল বেশি প্যাকেটে ভাগ হলে বেশি ইন্টারাপ্ট, বেশি রাউটিং সিদ্ধান্ত এবং পথের প্রতিটি ডিভাইসে বেশি প্যাকেট-প্রতি প্রক্রিয়াকরণ লাগে। যে রাউটার ইতিমধ্যে সেকেন্ডে-প্যাকেট সীমার কাছাকাছি, সেখানে এটি রাউন্ডিং ত্রুটি নয়, প্রকৃত মন্থরতা। স্থানান্তর নিজেই সফল হলেও খরচ দেখা যায়।
এই কারণেই ছোট MTU একটি সীমাবদ্ধতার জন্য বাইপাস, সাধারণ অপ্টিমাইজেশন নয়। এটি বড় ফ্রেম বহনে অক্ষম পথের বিরুদ্ধে নির্ভরযোগ্যতা কেনে, এবং যে প্যাকেটগুলোর হ্রাস দরকার ছিল না তাদের প্রতিটির জন্য ওভারহেড ধার্য করে।
কখন ছোট MTU সঠিক সমাধান
ক্লাসিক লক্ষণটি নির্দিষ্ট: TCP হ্যান্ডশেক সম্পন্ন হয়, ছোট সাড়া আসে, আর বড় ডাউনলোড থেমে যায় বা রিসেট হয়। 1472 বাইটে ডোন্ট-ফ্র্যাগমেন্ট বিটসহ পিং ব্যর্থ হয়, অথচ 1400 বাইটের পিং সফল হয়, যা এমন পথের দিকে ইঙ্গিত করে যা পূর্ণ মাপের প্যাকেট বহন করতে পারে না এবং প্রেরককে ছোট করতে বলবে এমন ICMP বার্তা পৌঁছায় না।
পথ MTU আবিষ্কার ওই ICMP ফ্র্যাগমেন্টেশন-প্রয়োজন বার্তাগুলোর উপর নির্ভর করে। ফায়ারওয়াল সেগুলো ফেলে দিলে প্রেরক বড় প্যাকেট পুনরায় চেষ্টা করতে থাকে এবং সংযোগ আটকে থাকা মনে হয়। টানেলের দিকে MTU কমানো পুনরায় চেষ্টা এড়ায়, যা ওই নেটওয়ার্কের জন্য বৈধ মেরামত।
অ্যাক্সেস প্রযুক্তিগুলোও নিজেদের সীমা আরোপ করে: PPPoE সাধারণত 1492-এ সীমাবদ্ধ, কিছু মোবাইল ও DSL পথ আরও কম, আর নেস্টেড টানেল ওভারহেড দুইবার বিয়োগ করে। গাইড থেকে সংখ্যা কপি না করে প্রকৃত পথ মাপুন, এবং মনে রাখুন IPv6 বহনকারী যেকোনো লিঙ্কে অন্তত 1280 বাইট MTU লাগে, যেমন RFC 8200 নির্দিষ্ট করে।
একটি বদলানোর আগে তিনটি নিয়ন্ত্রণ তুলনা করুন
MTU, MSS ও ফ্র্যাগমেন্টেশন ভিন্ন স্তরে ভিন্ন নব, আর ভুলটি বদলালে লক্ষণটি জায়গাতেই থাকে।
| Control | Layer | What it changes | Where it misleads |
|---|---|---|---|
| Interface MTU | IP link | Largest frame the interface will send | Penalizes every protocol, not just the one that failed |
| TCP MSS clamp | TCP | Segment size advertised in the handshake | Leaves UDP and QUIC untouched |
| DF and fragmentation | IP | Whether a router may split a packet | Can break path MTU discovery and security assumptions |
| Tunnel overhead | Encapsulation | Inner MTU after outer headers | Mismatch shows up only for large inner packets |
MSS ক্ল্যাম্প প্রায়ই সবচেয়ে কম আক্রমণাত্মক মেরামত, কারণ এটি কেবল TCP-তে প্রভাব ফেলে এবং ইন্টারফেস অন্য ট্র্যাফিকের জন্য মুক্ত রাখে। কম ইন্টারফেস MTU আরও বিস্তৃত ও যুক্তি করা সহজ, তাই এটি ভোক্তা রাউটারে প্রচলিত, কিন্তু এটি এক প্রোটোকলের সমস্যার জন্য প্রতিটি প্রোটোকল থেকে খরচ নেয়।
ডোন্ট-ফ্র্যাগমেন্ট আচরণ বন্ধ করা ফ্র্যাগমেন্টেশনের অনুমতি দিয়ে লক্ষণ লুকায়, এবং এটি সাধারণত বিলম্ব আরও খারাপ করে, একইসঙ্গে সেই প্রতিক্রিয়া ভেঙে দেয় যা সঠিক মাপ খুঁজে পেত। স্থায়ী সমাধান হিসেবে এটি এড়িয়ে চলুন।
একটি সংখ্যার বদলে বিনিময়টি মাপুন
ডোন্ট-ফ্র্যাগমেন্ট প্রোব দিয়ে পথের সীমা খুঁজুন, উঁচু থেকে শুরু করে উত্তর আসা পর্যন্ত নামতে থাকুন:
ping -M do -s 1472 203.0.113.10
ping -M do -s 1400 203.0.113.10
tracepath 203.0.113.10তারপর দুই সেটিংয়ে প্রকৃত কাজটি তুলনা করুন: একই ফাইল স্থানান্তর, একই এন্ডপয়েন্ট এবং একই নেটওয়ার্ক। সম্পূর্ণ হওয়ার সময় ও পুনঃপ্রেরণ লিখে রাখুন, উদাহরণস্বরূপ nstat -az TcpRetransSegs দিয়ে, আর টানেল ছোট রাউটারে শেষ হলে ডিভাইসের CPU লক্ষ্য করুন। সংক্ষিপ্ত কৃত্রিম থ্রুপুট পরীক্ষা সেই থেমে যাওয়া মিস করতে পারে যা কয়েক মেগাবাইট পরেই দেখা যায়।
হ্রাসের পরে প্যাকেট কাউন্টার বাড়বে, কারণ একই স্থানান্তর এখন বেশি প্যাকেট ব্যবহার করে। এটি প্রত্যাশিত এবং উচ্চতর থ্রুপুটের প্রমাণ নয়। সম্পূর্ণ অ্যাপ্লিকেশন ডেটা, পুনঃপ্রেরণের সংখ্যা ও সাড়াদায়িত্ব তুলনা করুন, কেবল প্যাকেট হার নয়।
পরিবর্তনটি ধাপে ধাপে করুন এবং সীমিত রাখুন
মূল মান লিখে রাখুন, একটি নিয়ন্ত্রণ বদলান, এবং স্থায়ী করার আগে পরিমাপটি পুনরাবৃত্তি করুন। প্রমাণ সুফল না দেখালে, যে ইন্টারফেস কমান্ডে এটি সেট করেছিলেন সেই একই কমান্ডে আগের মান ফিরিয়ে আনুন:
ip link set dev wg0 mtu 1420
ip link set dev wg0 mtu 1500ফলাফলটি যে নেটওয়ার্কের প্রয়োজন ছিল তার মধ্যে সীমাবদ্ধ রাখুন। যে প্রোফাইলকে হোটেল Wi-Fi, মোবাইল হটস্পট ও অফিস LAN-এ কাজ করতে হবে, সেটি তাদের যেকোনোটির প্রয়োজনীয় সর্বনিম্ন মান উত্তরাধিকারে নেবে না, যদি না ক্লায়েন্ট পথ শনাক্ত করতে না পারে।
সঠিক মান হলো পথে টিকে থাকা সবচেয়ে বড় MTU, লক্ষণ দূর করা সবচেয়ে ছোট মান নয়। পথ, প্রোবের ফলাফল ও রোলব্যাক নথিভুক্ত করুন, এবং অ্যাক্সেস নেটওয়ার্ক বদলালে সেটিংটি পুনর্বিবেচনা করুন।