TCP-তে OpenVPN আটকে যাওয়া: rto_min হেড-অফ-লাইন ঠিক করে না

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

লক্ষণটি মনোযোগ দিয়ে পড়া উচিত কারণ এটি একটি সেটিং নয়, একটি প্রক্রিয়ার দিকে ইঙ্গিত করে: বিরতি ভাগ করা, তাই কারণও ভাগ করা, আর ভাগ করা বস্তুটি হল বাইরের সংযোগ। এ ঘটনার সময় লগের বাকি সবকিছু স্বাভাবিক দেখায়।

লক্ষণ: সবকিছু একসাথে থেমে যায়

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

সেই কিছুটি হল টানেলের ট্রান্সপোর্ট। TCP মোডে OpenVPN এনক্যাপসুলেটেড প্যাকেটগুলো পিয়ারের সাথে একটি TCP সংযোগে লেখে, আর TCP-এর চুক্তি হল একক বাইট স্ট্রিমের ক্রমানুসারে ডেলিভারি। পরের বাইটগুলো কোন ভিতরের কথোপকথনের তা নিয়ে অনুপস্থিতগুলোর আগে অ্যাপ্লিকেশনকে দেওয়া হয় না।

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

একটি বাইরের বাইট স্ট্রিম, অনেক ভিতরের কথোপকথন

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

এটি একটি সংযোগের ভেতরে হেড-অফ-লাইন ব্লকিং, এবং এতে দুটি অ্যাপ্লিকেশনকে ভিতরের সংযোগ ভাগ করতে হয় না। তারা বাইরেরটি ভাগ করে, যা যথেষ্ট।

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

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

কেন একটি দীর্ঘতর ভিতরের টাইমার সাহায্য করতে পারে না

একটি রুটে ন্যূনতম পুনঃপ্রেরণ টাইমআউট বাড়ানো, rto_min দিয়ে, সেই রুট ব্যবহারকারী স্থানীয়ভাবে উৎপন্ন TCP ট্রাফিকের জন্য টাইমার-ভিত্তিক পুনঃপ্রেরণ বিলম্বিত করে। এটি সত্যিকারের প্রভাবসহ সত্যিকারের একটি নিয়ন্ত্রণ, এবং এটি প্রথম নয়, দ্বিতীয় ক্রমের সমস্যার সমাধান করে।

ip route show
ip route show cache 2>/dev/null | head
ss -tin dst 10.70.0.1

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

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

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

tcp-nodelay কী করে এবং কী করে না

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

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

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

ট্রান্সপোর্টগুলো ন্যায্যভাবে কীভাবে তুলনা করবেন

যদি অপারেটর অনুমতি দেয় এবং দুটি সেবাই থাকে, তবে একই সার্ভারে একই অ্যাক্সেস পথে একই কাজের চাপ বহনকারী একটি UDP সেবা ও একটি TCP সেবা তুলনা করুন। দুই পরীক্ষার মধ্যে দেশ, প্রদানকারী বা সার্ভার প্রজন্ম বদলালে এমন একটি চলক ঢোকে যা ফলাফলকে প্রাধান্য দেবে।

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

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

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