SSTP-এর ভিতরে TCP: পুনঃপ্রেরণ কেন দুবার হয়
SSTP তার টানেলটি TLS-এর উপর TCP স্ট্রিমে বহন করে। পথ প্যাকেট হারালে, বাইরের ও ভিতরের পুনরুদ্ধার একসাথে পিছিয়ে যায়।
মুখের কথাই আগে আসে, প্রোটোকল পরে। আশপাশে জিজ্ঞাসা করুন, SSTP-ই ধীরগতির, যে বিকল্পটি কিছু বাধ্য না করলে এড়িয়ে যান। সেই সুনাম এক ধরনের পথে একটিমাত্র ব্যর্থতার ধারা বর্ণনা করে।
প্রক্রিয়াটি বাস্তব। এটি শর্তসাপেক্ষও, যা সুনাম কখনও উল্লেখ করে না।
একই পথে দুটি নির্ভরযোগ্য স্ট্রিম
SSTP তার টানেলটিকে একটি HTTPS সেশনের ভিতরে মুড়ে দেয়। HTTPS চলে TCP-এর উপরে, এবং সেই বাইরের স্ট্রিমটি ক্রমবদ্ধ ডেলিভারি নিশ্চিত করে। তাই একটি মাত্র হারানো সেগমেন্ট তার পেছনে সারিবদ্ধ সবকিছু আটকে রাখে। অন্য ভিতরের কথোপকথনের পরবর্তী বাইটগুলি যেকোনো ভাবেই অপেক্ষা করে।
ভিতরের TCP ফ্লো নিজেদের ক্রম ও কনজেশন নিয়ন্ত্রণ রাখে। তারা বাইরের পুনরুদ্ধার দেখতে পায় না, তাই তারা কেবল একটি থেমে যাওয়া লক্ষ্য করে। থেমে যাওয়াই সেই সংকেত যা তাদের বলে পথটি কনজেস্টেড।
এখন দুই স্তরই একই সময়ে পিছিয়ে যায়। এইটুকুই পুরো মিথস্ক্রিয়া, এবং এটি শুরু করতে একটি হারানো সেগমেন্টই যথেষ্ট।
প্রভাব কোথায় দেখা যায় আর কোথায় যায় না
পরিষ্কার পথে বাইরের স্ট্রিম খুব কমই কিছু পুনরুদ্ধার করে। মিথস্ক্রিয়াটি কখনও শুরু হয় না, এবং SSTP ইন্টারঅ্যাকটিভ ট্রাফিক সম্পূর্ণ ভালোভাবেই বহন করে। সার্বিক দাবিটি ঠিক এই জায়গাতেই ব্যর্থ হয়।
প্রভাব দেখা যায় যখন ক্ষতি বা পুনর্বিন্যাস অন্তর্নিহিত পথে পৌঁছায়। একটি কনজেস্টেড Wi-Fi লিঙ্ক বা পরিবর্তনশীল লেটেন্সিযুক্ত মোবাইল সংযোগ পরিস্থিতি তৈরি করে। তারপর একটি আটকে যাওয়া বাইরের সারি টানেলের ভিতরে দৃশ্যমান বিলম্বে পরিণত হয়।
এটি কাজের চাপের সাথে সাথে বাড়ে। অনেক সমান্তরাল ফ্লো সারিটি ভরাট করে এবং হেড-অব-লাইন ব্লকিং আরও খারাপ করে। একই পথে একটি ইন্টারঅ্যাকটিভ সেশন গ্রহণযোগ্য মনে হতে পারে।
উপসর্গটি সাধারণত যা নয়
প্রতিটি ধীর সেশন এই সমস্যা নয়। প্রথম প্যাকেট থেকেই অবিচল কম হার ক্যাপাসিটি, শেপিং বা সার্ভার সীমার দিকে ইঙ্গিত করে। স্থানীয় কনজেশন সঙ্গে যে বিরতিগুলি মিলে যায় সেগুলি অ্যাক্সেস লিঙ্কে সারিবদ্ধতার দিকে ইঙ্গিত করে।
প্রতিকারগুলি ভিন্ন, তাই রোগনির্ণয় আগে আসে। বাফার টিউনিং একটি শেপড লিঙ্কের জন্য কিছুই করে না। প্রোটোকল বদলানো ক্যাপাসিটি শেষ হয়ে যাওয়া সার্ভারের জন্য কিছুই করে না। বারবার রিসেট সম্পূর্ণ ভিন্ন জায়গায় ইঙ্গিত করে।
# outer path quality to the SSTP endpoint
ping -c 50 203.0.113.44 | tail -3
mtr -rwc 50 203.0.113.44
# is the local link saturated while the session stalls?
sar -n DEV 2 5
# retransmissions on the outer connection
ss -tin dst 203.0.113.44
সমস্যাটি ঘটার সময়েই পরিমাপ চালান। সুস্থ এক মিনিটে নেওয়া একটি ক্যাপচার খারাপ মিনিটে চলা লুপ সম্পর্কে কিছুই প্রমাণ করে না।
বিশ্বাসযোগ্য একটি তুলনা
যদি সত্যিই অন্য কোনো ট্রান্সপোর্ট পাওয়া যায়, তবে নিয়ন্ত্রিত অবস্থায় তার সাথে তুলনা করুন। একই হোস্ট, একই নেটওয়ার্ক, একই গন্তব্য এবং একই কাজ। উভয় রান একই দশ মিনিটের মধ্যে হওয়া উচিত যাতে পথের পরিস্থিতি মেলে।
পোর্ট বদলালে প্রোটোকল বদলায় না। SSTP ক্লায়েন্টে একটি অসম্পর্কিত প্রোফাইল আমদানি করলে বিকল্প ট্রান্সপোর্ট তৈরি হয় না। তুলনাটি অর্থবহ হয় কেবল তখনই যখন সার্ভার দ্বিতীয় বিকল্পটি দেয়।
সর্বদা TLS যাচাই চালু রাখুন। পারফরম্যান্সের কাজটি যাচাই না করা সার্টিফিকেট গ্রহণ করার কারণ নয়। যদি স্টল প্রধানত আপলিঙ্ক পরিপূর্ণ থাকার সময় দেখা দেয়, তাহলে স্তরগুলিকে দোষারোপ করার আগে সারিবদ্ধতা দেখুন।