VPN-এ ফাইল শেয়ার ধীর লাগে কেন: রাউন্ড ট্রিপ, Mbps নয়

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

দূরের ওয়ার্কিং কপির আকারটাই ভুল

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

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

মেগাবাইটের আগে রাউন্ড ট্রিপ গুনুন

ক্যাপাসিটি কেনার আগে বিলম্ব মাপুন। একটি ping বলে দেয় প্রতিটি বিনিময়ে কত দিতে হয়।

ping -c 10 fileserver.example.net

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

বাইট নয়, কাজ সরান

বেশি পাইপের জন্য টাকা দেওয়ার বদলে কাজটা কোথায় ঘটে তা বদলান। রিপোজিটরি মাউন্ট করার বদলে সার্ভ করুন, আর শুধু পার্থক্য পাঠায় এমন টুল দিয়ে একসাথে কপি করুন।

rsync -av --info=progress2 ./project/ [email protected]:/srv/share/project/

রিপোজিটরি সার্ভ করা, যেমন hgweb বা দূরের Git করে, ক্লায়েন্টকে স্থানীয় ক্লোনে কাজ করতে দেয় যাতে তার ফাইলসিস্টেম কল কখনো টানেল পার না হয়। rsync দুই দিক হাঁটে আর বদলানো ব্লক পাঠায়, ফলে সহজ কপি যে বিনিময়গুলোর দাম দেয় তার বেশিরভাগ বাদ পড়ে। ডেস্কটপ ডেটাবেসের জায়গা সার্ভার-সাইড ইঞ্জিনে, ক্লায়েন্ট শুধু সামনের ইন্টারফেস, নয়তো পুরো ক্লায়েন্ট ভেতরের হোস্টে চলে। প্রতিটি বিকল্প বদলে দেয় প্রোটোকল কতটা বিলম্বের মুখোমুখি, আর সেটাই মূল কথা।

একই আকারের কাছে আটকে যাওয়া MTU-র লক্ষণ

বড় ট্রান্সফার প্রায় একই পরিমাণ ডেটার পরে আটকে যায়, অথচ ping আর ছোট পৃষ্ঠা কাজ করে — এটা ব্যান্ডউইথ নয়, প্যাকেটের আকারের দিকে ইশারা করে।

ping -M do -s 1400 -c 3 fileserver.example.net

সফল প্রোব মানে 1428 বাইটের একটি IP প্যাকেট খণ্ডন ছাড়াই পথ পেরোয়, কারণ ICMP আর IP হেডার 28 বাইট যোগ করে। খণ্ডন-নিষিদ্ধ ফ্ল্যাগ দিয়ে ব্যর্থতা বলে টানেলের ব্যবহারযোগ্য MTU সার্ভার যা ধরে নেয় তার চেয়ে ছোট। যে সার্ভার 9000 বাইটের বাফার 1500 বাইটের পথে পাঠায় সে খণ্ডন বা ড্রপ চাপিয়ে দেয়, আর ICMP ফিল্টার হলে পথের MTU আবিষ্কার নীরবে ব্যর্থ হতে পারে। টানেলের MTU কমান, সক্রিয় করুন mssfix OpenVPN-এ, নয়তো সার্ভারের বাফার ছোট করুন, তারপর নিশ্চিত হতে একই ট্রান্সফার আবার চালান।

যে ব্যবধানটি গুরুত্বপূর্ণ তা মাপুন

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

শুধু শুরুর মেগাবাইটগুলো টানলে প্রমাণীকরণ আর মেটাডেটার দিকে তাকান; সবকিছু হামাগুড়ি দিলে ক্যাপাসিটি আর ক্ষতির দিকে তাকান। মিলে যাওয়া কারণটা ঠিক করুন, আর WAN লিংক LAN কেবলের মতো আচরণ করবে এমন আশা ছাড়ুন।