SingLink 2.0 প্রোটোকল

SingLink 2.0 হলো SingLinkVPN-এর নিজস্বভাবে তৈরি অফিসিয়াল নেটওয়ার্ক ট্রান্সপোর্ট প্রোটোকল। “2.0” দিয়ে প্রোটোকলের নাম ও প্রজন্ম বোঝায়; এটি SingLinkVPN ক্লায়েন্ট সফটওয়্যারের কোনো সংস্করণ নয়।

SingLink প্রোটোকল শুধু VPN নোড পর্যন্ত ট্রাফিক বয়ে নেয় না। এর আওতায় আছে অ্যাকাউন্ট ও নোডের অনুমোদন, DNS সামলানো, স্মার্ট রাউটিং, এনক্রিপ্টেড সেশন, TCP ও UDP এনক্যাপসুলেশন, সংযোগের স্বাস্থ্য-পরীক্ষা, নেটওয়ার্ক পরিবর্তন এবং ব্যতিক্রম থেকে পুনরুদ্ধার।

SingLink-এর বর্তমানে আছে প্রোডাকশনের SingLink 2.0 প্রোটোকল এবং গতিকে অগ্রাধিকার দেওয়া SingLink Beta প্রিভিউ প্রোটোকল। অভ্যন্তরীণ A/B পরীক্ষায় SingLink 2.0 পৌঁছেছে 99.5% স্থিতিশীলতায়, আর Beta সর্বোচ্চ প্রায় 97%-এ; উপযুক্ত নেটওয়ার্ক ও ডিভাইসের পরিস্থিতিতে Beta-র সর্বোচ্চ গতি 1 Gbps ছাড়িয়েছে।

মূল ডেটার তুলনা: নির্দিষ্ট পরীক্ষা-পরিবেশে প্রোডাকশন SingLink 2.0 রেকর্ড করেছে 99.5% স্থিতিশীলতা। Beta পৌঁছেছে সর্বোচ্চ প্রায় 97%-এ, তবে উপযুক্ত নেটওয়ার্ক ও ডিভাইসের পরিস্থিতিতে 1 Gbps সর্বোচ্চ গতি ছাড়িয়েছে। এই ফলাফল স্থিতিশীলতা ও গতির ভিন্ন অগ্রাধিকার প্রকাশ করে; প্রতিটি ডিভাইস বা নেটওয়ার্কের জন্য নিশ্চয়তা নয়।

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

SingLink প্রোটোকল কীভাবে কাজ করে: পূর্ণ প্রক্রিয়া

পুরো ব্যবস্থাকে দুটি পথে ভাগ করা যায়:

কন্ট্রোল প্লেন

দায়িত্ব:

• অ্যাকাউন্টে সাইন ইন;
• সদস্যপদ যাচাই;
• নোড সংগ্রহ;
• নোড ব্যবহারের অধিকার নির্ধারণ;
• প্রোটোকল কনফিগারেশন পাঠানো;
• নিয়ম হালনাগাদ;
• Beta বা 2.0 বাছাই।

ডেটা প্লেন

দায়িত্ব:

• অ্যাপের ট্রাফিক গ্রহণ;
• DNS রিজলভ করা;
• নিরাপদ সংযোগ স্থাপন;
• TCP ও UDP এনক্যাপসুলেট করে বহন;
• সংযোগ সচল রাখা;
• সংযোগ বিচ্ছিন্ন হলে তা সামলানো;
• ডেটা অ্যাপে ফিরিয়ে দেওয়া।

সরলীকৃত প্রবাহটি হলো:

ব্যবহারকারী SingLinkVPN-এ সাইন ইন করেন
        ↓
অনুমোদিত নোড ও প্রোটোকল কনফিগারেশন সংগ্রহ
        ↓
ক্লায়েন্ট একটি TUN / সিস্টেম প্রক্সি তৈরি করে
        ↓
অ্যাপের ট্রাফিক গ্রহণ
        ↓
DNS ও রাউটিং নিয়ম মূল্যায়ন
        ↓
SingLink 2.0 বা Beta নোড বাছাই
        ↓
প্রোটোকলের সক্ষমতা নিয়ে আলোচনা
        ↓
অ্যাকাউন্ট ও ডিভাইসের অধিকার যাচাই
        ↓
এনক্রিপ্টেড সেশন ও সেশন কী তৈরি
        ↓
প্রতিটি অ্যাপ-সংযোগের জন্য আলাদা লজিক্যাল স্ট্রিম তৈরি
        ↓
TCP / UDP ডেটা এনক্যাপসুলেট
        ↓
SingLink নোডে ডেটা পাঠানো
        ↓
নোড ডিক্যাপসুলেট করে গন্তব্য ওয়েবসাইটে যায়
        ↓
ডেটা ফেরত এনে মূল অ্যাপে পৌঁছে দেওয়া
        ↓
ল্যাটেন্সি, প্যাকেট লস ও সংযোগের অবস্থা ক্রমাগত মাপা
        ↓
ব্যতিক্রমের পর পুনঃসংযোগ, পুনরুদ্ধার বা নোড বদল

---

ধাপ 1: সাইন ইন, নোড সংগ্রহ ও প্রোটোকল কনফিগারেশন

ব্যবহারকারী SingLinkVPN খুলে সাইন ইন করার পর ক্লায়েন্টের উচিত নয় সঙ্গে সঙ্গে প্রতিটি প্রোডাকশন নোডের ঠিকানা, ক্রেডেনশিয়াল ও প্রোটোকল প্যারামিটার ডিভাইসে স্থায়ীভাবে সংরক্ষণ করা।

আরও উপযুক্ত প্রবাহ হলো:

1. ক্লায়েন্ট অ্যাকাউন্টের ক্রেডেনশিয়াল জমা দেয়।
2. অ্যাকাউন্ট ব্যবস্থা ব্যবহারকারীকে যাচাই করে।
3. সিস্টেম প্ল্যান ও নোডের অধিকার নিশ্চিত করে।
4. সেই ব্যবহারকারীর জন্য উপলব্ধ নোডগুলো ফেরত দেয়।
5. স্বল্পমেয়াদি সংযোগ-ক্রেডেনশিয়াল ফেরত দেয়।
6. বর্তমান প্রোটোকল সংস্করণ ও প্রয়োজনীয় কনফিগারেশন ফেরত দেয়।
7. ক্লায়েন্ট কনফিগারেশনের অখণ্ডতা যাচাই করে।
8. সংবেদনশীল কনফিগারেশন সিস্টেমের সুরক্ষিত স্টোরেজে রাখা হয়।

এই স্তর প্রধানত নির্ধারণ করে:

• ব্যবহারকারীর বৈধ সদস্যপদ আছে কি না;
• Beta বা 2.0 উপলব্ধ কি না;
• অ্যাকাউন্টে Pro, Max বা Rich অধিকার আছে কি না;
• কোন দেশ ও নোড উপলব্ধ;
• কনফিগারেশনের মেয়াদ শেষ হয়েছে কি না;
• ক্লায়েন্ট আপডেট করা আবশ্যক কি না।

সহজ ভাষায়

এটি দ্রুতগতির ট্রেনে ওঠার আগে যাচাইয়ের মতো:

• আপনি কে;
• কোন শ্রেণির টিকিট কিনেছেন;
• কোন ট্রেনে উঠতে পারবেন;
• টিকিট এখনো বৈধ কি না।

প্রস্তাবিত নিরাপত্তা-নিয়ম

SingLink-এর উচিত নয় অনির্দিষ্টকাল একটিমাত্র স্থায়ী স্থির পাসওয়ার্ডের ওপর নির্ভর করা।

আরও উপযুক্ত নকশায় ব্যবহার হয়:

• স্বল্পমেয়াদি সংযোগ-টোকেন;
• একবার ব্যবহারযোগ্য চ্যালেঞ্জ;
• ডিভাইস nonce;
• মেয়াদের সীমা;
• সার্ভার-স্বাক্ষরিত নোড কনফিগারেশন;
• বাতিল করার ব্যবস্থা।

তাহলে একটি সংযোগ-কনফিগারেশন হাতে পেলেই স্থায়ী প্রবেশাধিকার মিলবে না।

---

ধাপ 2: সিস্টেমে নেটওয়ার্কের প্রবেশপথ তৈরি

ব্যবহারকারী Connect বেছে নিলে SingLinkVPN-কে প্রথমে অপারেটিং সিস্টেমে একটি নেটওয়ার্ক প্রবেশপথ তৈরি করতে হয়।

পদ্ধতি প্ল্যাটফর্মভেদে আলাদা:

প্ল্যাটফর্ম	প্রচলিত নেটওয়ার্ক প্রবেশপথ
iOS / iPadOS	Network Extension / Packet Tunnel
Android	VPN Service
macOS	Network Extension বা TUN
Windows	TUN ভার্চুয়াল অ্যাডাপ্টার ও সিস্টেম রাউটিং
Linux	TUN, রাউটিং টেবিল ও DNS ব্যবস্থাপনা

এটি তৈরি হওয়ার পর অ্যাপগুলো সাধারণত যে ডেটা সরাসরি নেটওয়ার্কে পাঠাত, তা আগে SingLinkVPN ক্লায়েন্টে ঢোকে।

যেমন:

ChatGPT অ্যাপ
    ↓
অপারেটিং সিস্টেমের নেটওয়ার্ক স্ট্যাক
    ↓
SingLink TUN ইন্টারফেস
    ↓
SingLinkVPN ক্লায়েন্ট

এই ধাপে ক্লায়েন্টকে যা করতে হয়:

• একটি ভার্চুয়াল IP তৈরি;
• রাউটিং টেবিল কনফিগার;
• DNS কনফিগার;
• লোকাল এরিয়া নেটওয়ার্ক বাদ রাখা;
• প্রক্সি সংযোগ যেন আবার TUN-এ ফিরে না আসে তা ঠেকানো;
• Kill Switch নিয়ম তৈরি।

শেষ বিষয়টি গুরুত্বপূর্ণ।

রুট বাদ না রাখলে SingLinkVPN যে ট্রাফিক দিয়ে নোডে পৌঁছায়, সেটিই আবার VPN-এ ঢুকে একটি লুপ তৈরি করতে পারে:

VPN ট্রাফিক
↓
আবার VPN-এ ঢোকে
↓
আবার এনক্যাপসুলেট হয়
↓
অসীম লুপ

তাই ক্লায়েন্টকে স্পষ্টভাবে বাদ রাখতে হবে:

• নোডের নিজস্ব IP;
• প্রয়োজনীয় কন্ট্রোল ইন্টারফেস;
• স্থানীয় গেটওয়ে;
• যেসব সেবায় সিস্টেমকে সরাসরি পৌঁছাতে হয়।

---

ধাপ 3: DNS রিজলভ ও ডোমেইন মূল্যায়ন

ব্যবহারকারী chatgpt.com খুললে ডিভাইসকে সাধারণত প্রথমে ডোমেইনটিকে একটি IP ঠিকানায় রূপান্তর করতে হয়।

DNS ভুলভাবে সামলালে যা হতে পারে:

• DNS অনুরোধ সরাসরি স্থানীয় নেটওয়ার্ক দিয়ে চলে যায়;
• স্থানীয় DNS রিজলভার ভুল ঠিকানা ফেরত দেয়;
• নিয়মগুলো মূল ডোমেইনের প্রেক্ষাপট হারিয়ে ফেলে;
• IPv6 ট্রাফিক VPN এড়িয়ে যায়;
• VPN সংযুক্ত দেখালেও DNS লিক হয়।

SingLink ক্লায়েন্ট এই প্রবাহ ব্যবহার করতে পারে:

অ্যাপ DNS অনুরোধ পাঠায়
        ↓
ক্লায়েন্ট DNS ধরে নেয়
        ↓
ডোমেইন নিয়ম মূল্যায়ন
        ↓
স্থানীয় DNS বা সুরক্ষিত রিমোট DNS বাছাই
        ↓
IPv4 / IPv6 ফল সংগ্রহ
        ↓
ডোমেইনকে IP-এর সঙ্গে যুক্ত করা
        ↓
সরাসরি, প্রক্সি নাকি ব্লক—সিদ্ধান্ত

স্থানীয় ডোমেইন

স্থানীয় ব্যাংক, LAN ডিভাইস বা অঞ্চল-নির্দিষ্ট সেবা স্থানীয় DNS ব্যবহার করে সরাসরি সংযোগ করতে পারে।

প্রক্সি করা ডোমেইন

যেসব ডোমেইনে VPN-এর মাধ্যমে যেতে হয়, সেগুলো প্রক্সি নোড বা সুরক্ষিত DNS রিজলভারের মাধ্যমে রিজলভ করা যায়।

সহজ ভাষায়

DNS হলো ঠিকানা খোঁজার মতো।

এই খোঁজ যদি তবুও স্থানীয় রাস্তা দিয়ে হয়, তাহলে পরের ডেটা VPN দিয়ে গেলেও কোন ওয়েবসাইট চাওয়া হচ্ছে তা প্রকাশ পেয়ে যেতে পারে।

তাই SingLink প্রোটোকল ব্যবস্থায় নির্ধারিত থাকা উচিত:

• ক্লায়েন্ট DNS ধরে নেয় কি না;
• কোন DNS অনুরোধ সরাসরি যায়;
• কোন DNS অনুরোধ VPN ব্যবহার করে;
• IPv4 ও IPv6 কীভাবে সামলানো হয়;
• DNS ফল কতক্ষণ ক্যাশে থাকে;
• নেটওয়ার্ক বদলের পর পুরোনো DNS ফল মুছে ফেলা হয় কি না।

---

ধাপ 4: স্মার্ট রাউটিং ও পথের সিদ্ধান্ত

DNS ও অ্যাপের ট্রাফিক ক্লায়েন্টে ঢোকার পর সিস্টেমকে ঠিক করতে হয় সেগুলো কীভাবে সামলাবে।

সাধারণত তিনটি ফল হয়:

সরাসরি
প্রক্সি
ব্লক

সরাসরি

ট্রাফিক স্থানীয় নেটওয়ার্ক ব্যবহার করে, SingLink টানেলে ঢোকে না।

উপযোগী:

• LAN ডিভাইসের জন্য;
• স্থানীয় ওয়েবসাইটের জন্য;
• যেসব অ্যাপের প্রক্সি দরকার নেই;
• ব্যবহারকারীর নিজের তৈরি অনুমোদিত তালিকার জন্য।

প্রক্সি

ট্রাফিক SingLink প্রোটোকলে ঢোকে এবং একটি নোড তা ফরওয়ার্ড করে।

উপযোগী:

• বিদেশি ওয়েবসাইটের জন্য;
• AI টুলের জন্য;
• আন্তর্জাতিক সোশ্যাল প্ল্যাটফর্মের জন্য;
• ব্যবহারকারীর বেছে নেওয়া অ্যাপের জন্য।

ব্লক

সংযোগ প্রত্যাখ্যান করা হয়।

উপযোগী:

• বিজ্ঞাপনের ডোমেইনের জন্য;
• ট্র্যাকিং ডোমেইনের জন্য;
• ক্ষতিকর ঠিকানার জন্য;
• ব্যবহারকারীর নিজের তৈরি ব্লক তালিকার জন্য।

সিদ্ধান্তে বিবেচনা করা যায়:

• ডোমেইন;
• IP ঠিকানা;
• পোর্ট;
• অ্যাপ;
• ভৌগোলিক অবস্থান;
• প্রোটোকলের ধরন;
• ব্যবহারকারীর নিয়ম;
• গ্লোবাল বা রুল মোড।

সহজ ভাষায়

এই ধাপটি যানবাহন নিয়ন্ত্রণের মতো:

• স্থানীয় গাড়ি সাধারণ রাস্তায় চলে;
• বিদেশগামী গাড়ি এনক্রিপ্টেড এক্সপ্রেসওয়েতে ওঠে;
• বিপজ্জনক গাড়িকে ঢুকতে দেওয়া হয় না।

---

ধাপ 5: নোড ও প্রোটোকল বাছাই

ট্রাফিক প্রক্সির জন্য চিহ্নিত হলে ক্লায়েন্টকে একটি নোড বেছে নিতে হয়।

বাছাই শুধু দেশের নামের ওপর নির্ভর করতে পারে না। আরও বিবেচনা করতে হয়:

• ব্যবহারকারীর প্ল্যান;
• নোডটি 2.0 নাকি Beta ব্যবহার করে;
• নোডটি অনলাইনে আছে কি না;
• ল্যাটেন্সি;
• প্যাকেট লস;
• লোড;
• নোডের দূরত্ব;
• স্থানীয় ক্যারিয়ার;
• গন্তব্যের অবস্থান;
• UDP সমর্থন;
• ক্লায়েন্টের সামঞ্জস্য।

ম্যানুয়াল বাছাই

ব্যবহারকারী জাপান, যুক্তরাষ্ট্র, সিঙ্গাপুর বা অন্য কোনো অবস্থানের নোড বেছে নেন।

স্মার্ট বাছাই

ক্লায়েন্ট পরীক্ষার ফল দেখে উপযুক্ত নোড বেছে নেয়।

স্মার্ট বাছাইয়ে শুধু সবচেয়ে কম ল্যাটেন্সির নোড বেছে নেওয়া উচিত নয়।

যেমন:

নোড	ল্যাটেন্সি	লস	লোড
A	50 ms	8%	90%
B	70 ms	0%	30%

A-এর ল্যাটেন্সি কম হলেও এর লস ও লোড বেশি; বাস্তব ব্যবহারে B বেশি স্থিতিশীল হতে পারে।

তাই স্মার্ট বাছাইয়ে মেলাতে হবে:

ল্যাটেন্সি + লস + সংযোগ সফলতার হার + লোড + আগের পারফরম্যান্স

---

ধাপ 6: প্রোটোকলের সক্ষমতা নিয়ে আলোচনা

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

আগে সক্ষমতা নিয়ে আলোচনা করে নিতে হয়।

আলোচনার বিষয়ের মধ্যে থাকতে পারে:

• SingLink সংস্করণ;
• Beta নাকি 2.0;
• TCP সমর্থন;
• UDP সমর্থন;
• IPv4 / IPv6;
• সেশন পুনরারম্ভের সমর্থন;
• মাল্টিপ্লেক্সিং সমর্থন;
• ডেটা-ফ্রেমের সর্বোচ্চ আকার;
• Padding কৌশল;
• হার্টবিটের ব্যবধান;
• কম্প্রেশন চালু কি না;
• MTU আকার;
• পুনরায় আলোচনার সমর্থন।

যেমন:

ক্লায়েন্ট:
আমি SingLink 2.0 সমর্থন করি
আমি TCP, UDP ও IPv6 সমর্থন করি
আমি Session Resume সমর্থন করি
সর্বোচ্চ ফ্রেম: 64 KB

সার্ভার:
SingLink 2.0 ব্যবহার নিশ্চিত
TCP ও UDP উপলব্ধ
Session Resume উপলব্ধ
কার্যকর সর্বোচ্চ ফ্রেম: 32 KB

শেষ পর্যন্ত দুই পক্ষ শুধু পারস্পরিকভাবে সমর্থিত সক্ষমতাগুলোই ব্যবহার করে।

আলোচনা কেন দরকার?

ক্লায়েন্ট ও নোড একই দিনে আপডেট না-ও হতে পারে।

নতুন ক্লায়েন্ট যদি এমন ফরম্যাট পাঠায় যা পুরোনো নোড চিনতে পারে না, তাহলে সংযোগ ব্যর্থ হয়।

প্রোডাকশন 2.0-এর উচিত Beta-র চেয়ে বেশি জোর দেওয়া:

• পুরোনো সংস্করণের সঙ্গে সামঞ্জস্যে;
• সংস্করণ ফলব্যাকে;
• কোনো ফিচার না থাকলে নিরাপদভাবে মান কমিয়ে চালানোয়;
• অসামঞ্জস্যপূর্ণ সংস্করণ স্পষ্টভাবে প্রত্যাখ্যানে।

---

ধাপ 7: পরিচয় যাচাই

মৌলিক সংযোগ স্থাপনের পর নোডকে নিশ্চিত হতে হয় যে ব্যবহারকারী অনুমোদিত।

প্রস্তাবিত যাচাই-ডেটার মধ্যে আছে:

• স্বল্পমেয়াদি টোকেন;
• অ্যাকাউন্ট বা অনুমোদনের ID;
• ক্লায়েন্ট nonce;
• প্রোটোকল সংস্করণ;
• নোড ID;
• অনুরোধ করা সক্ষমতা;
• অখণ্ডতা যাচাইয়ের ডেটা।

একটি সরলীকৃত প্রমাণীকরণ প্যাকেট বলে:

আমি কে
আমি কোন নোড চাই
আমি কোন প্রোটোকল চাই
এই সংযোগের র‍্যান্ডম শনাক্তকারী
আমার অনুমোদনের মেয়াদ কখন শেষ
ডেটা পরিবর্তিত হয়েছে কি না

সার্ভারকে যাচাই করতে হয়:

1. টোকেনটি অফিসিয়ালি ইস্যু করা কি না;
2. টোকেনের মেয়াদ শেষ কি না;
3. টোকেন বাতিল করা হয়েছে কি না;
4. নোডে প্রবেশাধিকার ব্যবহারকারীর আছে কি না;
5. nonce আগে ব্যবহার হয়েছে কি না;
6. অনুরোধটি রিপ্লে কি না;
7. এই ক্লায়েন্ট সংস্করণ সংযোগ করতে পারবে কি না।

রিপ্লে সুরক্ষা

আক্রমণকারী বৈধ প্রমাণীকরণ-ডেটা রেকর্ড করে হুবহু আবার পাঠাতে পারে।

তাই প্রমাণীকরণ-ডেটায় দরকার:

• একবার ব্যবহারযোগ্য nonce;
• সার্ভারের চ্যালেঞ্জ;
• সংক্ষিপ্ত বৈধতার মেয়াদ;
• ব্যবহৃত ক্রেডেনশিয়ালের রেকর্ড;
• সেশনের সঙ্গে বন্ধন।

সহজ ভাষায়:

একবার যাচাই হয়ে যাওয়া টিকিট কপি করে সীমাহীনভাবে আবার ব্যবহার করা যায় না।

---

ধাপ 8: কী বিনিময় ও এনক্রিপ্টেড সেশন

পরিচয় যাচাই সফল হলে ক্লায়েন্ট ও নোডের এই সংযোগের জন্য নির্দিষ্ট সেশন কী দরকার।

প্রস্তাবিত যুক্তি হলো:

ক্লায়েন্ট একটি ক্ষণস্থায়ী কী তৈরি করে
        ↓
সার্ভার একটি ক্ষণস্থায়ী কী তৈরি করে
        ↓
দুই পক্ষ প্রকাশ্য ডেটা বিনিময় করে
        ↓
প্রত্যেকে আলাদাভাবে একই শেয়ার্ড সিক্রেট হিসাব করে
        ↓
সেই শেয়ার্ড সিক্রেট থেকে একাধিক সেশন কী তৈরি হয়

আলাদা কী তৈরি করা উচিত:

• ক্লায়েন্ট থেকে সার্ভারের এনক্রিপশনের জন্য;
• সার্ভার থেকে ক্লায়েন্টের এনক্রিপশনের জন্য;
• ডেটার অখণ্ডতার জন্য;
• সেশন পুনরুদ্ধারের জন্য;
• হেডার সুরক্ষার জন্য।

সব দিক ও উদ্দেশ্যে একটিমাত্র কী ভাগাভাগি করা উচিত নয়।

ফরওয়ার্ড সিক্রেসি

আরও উপযুক্ত নকশায় প্রতিটি সেশনের জন্য ক্ষণস্থায়ী কী ব্যবহার হয়।

পরে কোনো দীর্ঘমেয়াদি সার্ভার-কী ফাঁস হলেও তা দিয়ে আগে রেকর্ড করা প্রতিটি সংযোগ সরাসরি ডিক্রিপ্ট করা যাওয়া উচিত নয়।

কী রোটেশন

দীর্ঘক্ষণ চলা সংযোগে চিরকাল একই সেট সেশন কী ব্যবহার করা উচিত নয়।

কী আবার তৈরি করা যায় যেসবের ভিত্তিতে:

• স্থানান্তরিত ডেটার পরিমাণ;
• সংযোগের সময়কাল;
• ফ্রেমের সংখ্যা;
• সার্ভারের নির্দেশ।

এগুলোর যেকোনোটি অনুযায়ী কী নতুন করে তৈরি করা হয়।

যেমন:

নির্দিষ্ট পরিমাণ GB পার হলে
অথবা
নির্দিষ্ট সময় পার হলে
দিকভিত্তিক নতুন কী তৈরি

সঠিক মান নির্ধারণ করা উচিত প্রকৌশলগত পারফরম্যান্স ও নিরাপত্তা পরীক্ষার মাধ্যমে, কোনো প্রচারমূলক লেখায় বানিয়ে নয়।

---

ধাপ 9: সেশন তৈরি

পরিচয় ও কী প্রতিষ্ঠার পর দুই পক্ষ একটি SingLink Session তৈরি করে।

একটি Session-এ থাকতে পারে:

• Session ID;
• প্রোটোকল সংস্করণ;
• এনক্রিপশন প্যারামিটার;
• সর্বোচ্চ ফ্রেম আকার;
• হার্টবিটের ব্যবধান;
• UDP মোড;
• Stream-এর সীমা;
• নিষ্ক্রিয়তার টাইমআউট;
• সেশন পুনরুদ্ধারের সক্ষমতা;
• Beta বা 2.0 নীতি।

সার্ভার নিশ্চিতকরণ ফেরত পাঠায়:

পরিচয় যাচাই সম্পন্ন
Session প্রতিষ্ঠিত
SingLink 2.0 ব্যবহার হচ্ছে
TCP উপলব্ধ
UDP উপলব্ধ
মাল্টিপ্লেক্সিং উপলব্ধ
হার্টবিট চালু

সার্ভারের নিশ্চিতকরণ পাওয়ার পরই ক্লায়েন্টের অ্যাপ-ডেটা পাঠানো উচিত।

---

ধাপ 10: Stream বা স্বতন্ত্র প্রক্সি সংযোগ তৈরি

SingLink আসলে কোন আর্কিটেকচার ব্যবহার করে, তা প্রকৌশল দলের নিশ্চিতকরণ সাপেক্ষ।

বিকল্প 1: একটি Session একাধিক Stream বহন করে

এটি AnyTLS-এর পদ্ধতির মতো:

SingLink Session
├─ Stream 1: ChatGPT
├─ Stream 2: YouTube
├─ Stream 3: Telegram
└─ Stream 4: ব্রাউজার

প্রতিটি Stream-এর দরকার:

• Stream ID;
• গন্তব্যের ঠিকানা;
• গন্তব্যের পোর্ট;
• TCP বা UDP;
• বর্তমান অবস্থা;
• পাঠানোর উইন্ডো;
• গ্রহণের উইন্ডো।

সুবিধা:

• বারবার হ্যান্ডশেক কম;
• সংযোগের ল্যাটেন্সি কম;
• নিচের সংযোগের সংখ্যা কম;
• অনেক ছোট সংযোগ দক্ষভাবে সামলানো।

ঝুঁকি:

• একটি Session ব্যর্থ হলে একাধিক Stream প্রভাবিত হতে পারে;
• নিচের একটি TCP সংযোগ হেড-অফ-লাইন ব্লকিং ঘটাতে পারে;
• পূর্ণাঙ্গ ফ্লো কন্ট্রোল দরকার।

বিকল্প 2: প্রতিটি অ্যাপ-অনুরোধে আলাদা সংযোগ

ChatGPT → আলাদা সংযোগ
YouTube → আলাদা সংযোগ
Telegram → আলাদা সংযোগ

সুবিধা:

• ভিন্ন ভিন্ন ট্রাফিক বিচ্ছিন্ন থাকে;
• একটি সংযোগ ব্যর্থ হলে অন্যগুলোর ক্ষতি হয় না;
• যুক্তি সরল।

অসুবিধা:

• হ্যান্ডশেক বেশি;
• সংযোগের বাড়তি খরচ বেশি;
• অনেক ছোট সংযোগে দক্ষতা কম।

পরামর্শ

SingLink একটি মিশ্র মোড ব্যবহার করতে পারে:

• ছোট সংযোগ ও সাধারণ ওয়েব ট্রাফিক একটি Session-এ মাল্টিপ্লেক্স করা;
• বড় ডাউনলোড ও ভিডিওর জন্য আলাদা চ্যানেল তৈরি;
• কম ল্যাটেন্সির UDP আলাদাভাবে সামলানো;
• একটি দ্রুতগতির ডাউনলোড যেন সব Stream দখল না করে তা ঠেকানো।

---

ধাপ 11: ডেটা-ফ্রেম এনক্যাপসুলেশন

অ্যাপের ডেটা অপরিবর্তিত অবস্থায় ট্রান্সপোর্ট চ্যানেলে ফেলে দেওয়া যায় না। একে প্রোটোকল ফ্রেম হিসেবে এনক্যাপসুলেট করতে হয়।

ধারণাগত একটি SingLink ফ্রেমে থাকতে পারে:

সংস্করণ
ফ্রেমের ধরন
Session ID
Stream ID
ক্রমিক নম্বর
ফ্ল্যাগ
ডেটার দৈর্ঘ্য
এনক্রিপ্টেড ডেটা
অখণ্ডতা ট্যাগ

সম্ভাব্য ফ্রেমের ধরন:

ফ্রেমের ধরন	উদ্দেশ্য
OPEN	নতুন Stream তৈরি
DATA	ডেটা বহন
ACK	অবস্থা নিশ্চিতকরণ
FIN	স্বাভাবিকভাবে বন্ধ
RESET	অস্বাভাবিকভাবে সমাপ্তি
PING	স্বাস্থ্য-পরীক্ষা
PONG	স্বাস্থ্য-পরীক্ষার উত্তর
UDP	UDP ডেটাগ্রাম বহন
SETTINGS	সেশনের প্যারামিটার হালনাগাদ
KEY_UPDATE	সেশন কী রোটেশন
RESUME	সেশন পুনরুদ্ধার

এটি প্রোটোকল নকশার একটি পরামর্শ। SingLink বর্তমানে এই নাম বা বিট-ফরম্যাট ব্যবহার করে—এমন কথা এখানে বলা হচ্ছে না।

---

ধাপ 12: TCP ট্রাফিক প্রক্রিয়াকরণ

ওয়েবসাইট, API ও ফাইল ডাউনলোডের মতো TCP সংযোগের ক্ষেত্রে SingLink-কে বজায় রাখতে হয়:

• ডেটার ক্রম;
• দ্বিমুখী স্থানান্তর;
• বন্ধ হওয়ার অবস্থা;
• ফ্লো কন্ট্রোল;
• ত্রুটির অবস্থা।

একটি পূর্ণ প্রবাহ হতে পারে:

অ্যাপ একটি TCP সংযোগ তৈরি করে
        ↓
ক্লায়েন্ট একটি SingLink Stream তৈরি করে
        ↓
গন্তব্যের ডোমেইন ও পোর্ট পাঠানো
        ↓
নোড গন্তব্য ওয়েবসাইটে সংযোগ করে
        ↓
নোড সফলতা বা ব্যর্থতা জানায়
        ↓
দ্বিমুখী ফরওয়ার্ডিং শুরু

স্বাভাবিকভাবে বন্ধ

অ্যাপ সংযোগ শেষ করলে:

1. ক্লায়েন্ট FIN পাঠায়।
2. নোড সেই দিকে ডেটা নেওয়া বন্ধ করে।
3. অন্য দিক শেষ হওয়া পর্যন্ত অপেক্ষা করে।
4. Stream পুরোপুরি বন্ধ হয়।
5. মেমরি ও সংযোগের অবস্থা মুক্ত করা হয়।

অস্বাভাবিকভাবে বন্ধ

গন্তব্য সংযোগ প্রত্যাখ্যান করলে:

1. নোড একটি ত্রুটি ফেরত দেয়।
2. ক্লায়েন্ট অ্যাপকে সংযোগ ব্যর্থতার কথা জানায়।
3. Stream সঙ্গে সঙ্গে পরিষ্কার করা হয়।
4. অন্য Stream প্রভাবিত হয় না।

---

ধাপ 13: UDP ট্রাফিক প্রক্রিয়াকরণ

UDP-তে প্রচলিত TCP সংযোগ নেই। প্রতিটি ডেটাগ্রামে ধরে রাখতে হয়:

• উৎসের সংশ্লিষ্টতা;
• গন্তব্যের ঠিকানা;
• গন্তব্যের পোর্ট;
• ডেটার দৈর্ঘ্য;
• ডেটাগ্রামের সীমানা;
• সংশ্লিষ্টতার টাইমআউট।

যেমন:

UDP Association ID
গন্তব্যের ঠিকানা
গন্তব্যের পোর্ট
ডেটার দৈর্ঘ্য
UDP Payload

SingLink-কে এই পদ্ধতিগুলোর মধ্যে স্পষ্টভাবে বেছে নিতে হয়:

UDP over TCP

UDP ডেটাগ্রাম TCP বা একটি নির্ভরযোগ্য Session-এর ভেতরে বহন করা হয়।

সুবিধা:

• শুধু TCP অনুমোদিত নেটওয়ার্ক সহজে পার হওয়া যায়;
• ডেটা হারানোর সম্ভাবনা কম;
• ডিপ্লয়মেন্ট সহজ।

অসুবিধা:

• TCP-তে প্যাকেট হারালে পরের UDP ডেটা আটকে যায়;
• কিছু গেম, ভয়েস ও রিয়েল-টাইম ব্যবহারের জন্য অনুপযুক্ত।

নেটিভ UDP

UDP সরাসরি ডেটা বহন করে।

সুবিধা:

• কম ল্যাটেন্সি;
• গেম, ভয়েস ও QUIC-এর জন্য উপযোগী;
• TCP হেড-অফ-লাইন ব্লকিংয়ে প্রভাবিত হয় না।

অসুবিধা:

• কিছু নেটওয়ার্ক UDP সীমিত করে;
• NAT ও ফায়ারওয়াল সামলানো আরও জটিল।

QUIC-ধাঁচের ট্রান্সপোর্ট

এটি UDP-ভিত্তিক, তবে প্রোটোকল স্তরে দেয়:

• এনক্রিপশন;
• পুনঃপ্রেরণ;
• একাধিক Stream;
• কনজেশন নিয়ন্ত্রণ;
• নেটওয়ার্ক মাইগ্রেশন।

এর প্রযুক্তিগত সক্ষমতা বেশি পূর্ণাঙ্গ, তবে বাস্তবায়ন কঠিন।

SingLink-এর জন্য একটি যুক্তিসংগত দিশা হলো:

নেটওয়ার্ক ও ট্রাফিকের ধরন অনুযায়ী নিজে থেকেই নেটিভ UDP, নির্ভরযোগ্য এনক্যাপসুলেশন বা অন্য কোনো সামঞ্জস্যপূর্ণ মোড বেছে নেওয়া।

এটি বাস্তবায়িত হয়েছে কি না, তা নিশ্চিত করা দরকার।

---

ধাপ 14: ফ্লো কন্ট্রোল ও ব্যাকপ্রেশার

ধরা যাক YouTube দ্রুত ডাউনলোড করছে, আর ChatGPT সামান্য পরিমাণ লেখা আদান-প্রদান করছে।

ফ্লো কন্ট্রোল না থাকলে ভিডিওর Stream চ্যানেল ভরিয়ে ফেলতে পারে, ফলে:

• ChatGPT-এর উত্তর ধীর হয়;
• DNS-এ দেরি হয়;
• অ্যাপ আটকে যায়;
• মেমরির ব্যবহার ক্রমাগত বাড়ে।

তাই দুই স্তরের ফ্লো কন্ট্রোল দরকার:

Session স্তর

পুরো Session কতটা অনিশ্চিত (ACK না পাওয়া) ডেটা বহন করতে পারবে, তা সীমিত করে।

Stream স্তর

প্রতিটি Stream ট্রান্সপোর্ট উইন্ডোর কতটা দখল করতে পারবে, তা সীমিত করে।

সহজ ভাষায়:

একটি বড় ট্রাক এক্সপ্রেসওয়ের সব লেন দখল করতে পারে না। প্রতিটি Stream-এর ট্রান্সপোর্ট রিসোর্সের ন্যায্য ভাগ দরকার।

প্রোডাকশন 2.0 প্রোটোকল Beta-র চেয়ে বেশি রক্ষণশীল শিডিউলিং ব্যবহার করতে পারে, যাতে সর্বোচ্চ গতির পেছনে ছুটতে গিয়ে অন্য সংযোগ বিঘ্নিত না হয়।

---

ধাপ 15: খণ্ডকরণ, Padding ও ট্রাফিকের চেহারা

ডেটা এনক্রিপ্ট হওয়ার পরও একজন পর্যবেক্ষক দেখতে পারেন:

• প্যাকেটের দৈর্ঘ্য;
• পাঠানোর ব্যবধান;
• সংযোগের সময়কাল;
• আপলোড/ডাউনলোডের অনুপাত;
• পুনঃসংযোগের আচরণ।

তাই প্রোটোকল ট্রাফিকের চেহারা বদলাতে পারে, যেমন:

• বড় ডেটাকে একাধিক ফ্রেমে ভাগ করা;
• ছোট ডেটা একত্র করা;
• পরিবর্তনশীল Padding যোগ করা;
• পাঠানোর ব্যাচ সমন্বয় করা;
• একটি নির্দিষ্ট হ্যান্ডশেক-দৈর্ঘ্য এড়ানো;
• সময়ে সময়ে Padding কৌশল হালনাগাদ করা।

তবে এটি স্পষ্ট থাকা দরকার:

Padding এনক্রিপশনের বিকল্প নয়, এবং ট্রাফিক সবসময় অশনাক্ত থাকবে—এমন নিশ্চয়তা দিতে পারে না।

অতিরিক্ত Padding-এর ফলেও হয়:

• বেশি ট্রাফিক;
• বেশি ল্যাটেন্সি;
• বেশি CPU ব্যবহার;
• বিনামূল্যে প্ল্যানের বরাদ্দের অপচয়।

তাই 2.0 প্রোফাইল পরিস্থিতি অনুযায়ী মানিয়ে নিতে পারে:

• সাধারণ নেটওয়ার্কে কম বাড়তি খরচ;
• বিশেষ নেটওয়ার্ক পরিবেশে চেহারা-প্রক্রিয়াকরণ বাড়ানো;
• দ্রুতগতির ডাউনলোডে অপ্রয়োজনীয় Padding কমানো;
• ছোট কন্ট্রোল ডেটায় উপযুক্ত প্যাডিং দেওয়া।

Beta বরং সর্বোচ্চ গতি বাড়াতে বাড়তি খরচ কমাতে পারে।

---

ধাপ 16: MTU ও প্যাকেটের আকার সামলানো

TUN ট্রাফিকে প্রোটোকল হেডার ও এনক্রিপ্টেড ডেটা যোগ হলে প্যাকেটের আকার বাড়ে।

নেটওয়ার্কের MTU ছাড়িয়ে গেলে হতে পারে:

• IP ফ্র্যাগমেন্টেশন;
• প্যাকেট হারানো;
• ওয়েবসাইট না খোলা;
• অস্থির গতি;
• VPN সংযুক্ত হয় কিন্তু কোনো ডেটা চলে না।

SingLink-কে যা করতে হয়:

1. TUN MTU নির্ধারণ;
2. প্রোটোকল হেডার বাদ দিয়ে হিসাব;
3. এনক্রিপশনের বাড়তি অংশ বাদ দিয়ে হিসাব;
4. IPv4 ও IPv6 অনুযায়ী সমন্বয়;
5. দরকার হলে ডেটা ভাগ করা;
6. অপ্রয়োজনীয় IP ফ্র্যাগমেন্টেশন এড়ানো।

এ কারণেই একটি নির্দিষ্ট প্যাকেট-আকার প্রতিটি নেটওয়ার্কে খাপ খায় না।

প্রোডাকশন 2.0-এর ক্রস-প্ল্যাটফর্ম MTU সামঞ্জস্য আরও পূর্ণাঙ্গ হওয়া উচিত। Beta যদি আরও আগ্রাসী বড় ফ্রেম ব্যবহার করে, তাহলে কিছু নেটওয়ার্কে দ্রুত হতে পারে, কিন্তু অস্বাভাবিক নেটওয়ার্কে কম স্থিতিশীল হতে পারে।

---

ধাপ 17: ল্যাটেন্সি, প্যাকেট লস ও কনজেশন সামলানো

ক্লায়েন্টকে ক্রমাগত পর্যবেক্ষণ করতে হয়:

• RTT ল্যাটেন্সি;
• জিটার;
• প্যাকেট লস;
• পাঠানোর গতি;
• গ্রহণের গতি;
• ACK না পাওয়া ডেটা;
• নোডের সাড়া।

একটিমাত্র Ping-এর ওপর নির্ভর করা যায় না।

যেমন:

স্বাভাবিক: 60 ms
সাময়িক বৃদ্ধি: 120 ms
টানা বৃদ্ধি: 500 ms
কোনো সাড়া নেই: টাইমআউট

ভিন্ন পরিস্থিতিতে ভিন্নভাবে সামলাতে হয়:

পরিস্থিতি	করণীয়
সাময়িক ল্যাটেন্সি	অপেক্ষা চালিয়ে যাওয়া; সঙ্গে সঙ্গে পুনঃসংযোগ নয়
সামান্য প্যাকেট লস	উইন্ডো বা পাঠানোর গতি সমন্বয়
টানা উচ্চ ল্যাটেন্সি	সমান্তরালতা কমানো বা অন্য নোড বিবেচনা
ডেটা নেই, তবে হার্টবিট সফল	Session বজায় রাখা
হার্টবিট ও ডেটা দুটোই ব্যর্থ	সংযোগ বিচ্ছিন্ন বলে ধরা
নোড সম্পূর্ণ ব্যর্থ	পুনঃসংযোগ বা নোড বদল

একটি প্যাকেট হারালেই পুনঃসংযোগ করলে প্রোটোকল কম স্থিতিশীল হয়ে পড়ত।

---

ধাপ 18: হার্টবিট ও স্বাস্থ্য-পরীক্ষা

দীর্ঘক্ষণ কোনো অ্যাপ-ডেটা না থাকলেও সিস্টেমকে জানতে হয় চ্যানেলটি সচল আছে কি না।

এর জন্য ব্যবহার করা যায়:

PING
↓
PONG

হার্টবিট খুব ঘন ঘন হওয়া চলবে না।

অতিরিক্ত ঘন হলে:

• ব্যাটারি নষ্ট হয়;
• ডেটা খরচ হয়;
• সার্ভারের লোড বাড়ে;
• একটি নির্দিষ্ট সময়-বৈশিষ্ট্য তৈরি হয়।

খুব কম হলে:

• ব্যর্থ নোড শনাক্ত করতে দেরি হয়;
• অ্যাপকে বেশিক্ষণ অপেক্ষা করতে হয়;
• নেটওয়ার্ক বদলের পর পুনরুদ্ধার ধীর হয়।

তাই হার্টবিটের হার অবস্থা অনুযায়ী মানিয়ে নিতে পারে:

• স্বাভাবিক ট্রাফিক থাকলে হার্টবিট যোগ না করা;
• কিছুক্ষণ নিষ্ক্রিয় থাকলে কম হারের হার্টবিট শুরু;
• নেটওয়ার্ক বদলের পর সাময়িকভাবে পরীক্ষা বাড়ানো;
• বারবার ব্যর্থ হলে সংযোগকে বিচ্ছিন্ন হিসেবে চিহ্নিত করা।

---

ধাপ 19: নেটওয়ার্ক পরিবর্তন ও সেশন পুনরুদ্ধার

ফোন Wi-Fi থেকে 5G-তে গেলে আগের সংযোগ সাধারণত অকার্যকর হয়ে যায়।

পূর্ণাঙ্গভাবে সামলানো উচিত এভাবে:

নেটওয়ার্ক পরিবর্তন শনাক্ত
        ↓
ব্যর্থ চ্যানেলে নতুন ডেটা পাঠানো বন্ধ
        ↓
নতুন স্থানীয় IP ও রুট সংগ্রহ
        ↓
আগের নোডে পুনঃসংযোগ
        ↓
সেশন-পুনরুদ্ধারের ক্রেডেনশিয়াল জমা
        ↓
সার্ভার পুরোনো Session যাচাই করে
        ↓
পুনরুদ্ধারযোগ্য লজিক্যাল Stream ফিরিয়ে আনা
        ↓
যেসব TCP সংযোগ ফেরানো যায় না, সেগুলো নতুন করে গড়তে অ্যাপকে জানানো

একটি গুরুত্বপূর্ণ সীমাবদ্ধতা:

অ্যাপের প্রতিটি TCP সংযোগ নির্বিঘ্নে পুনরুদ্ধার করা যায় না।

প্রোটোকল যা পুনরুদ্ধার করতে পারে:

• Session-এর অবস্থা;
• নোডের অনুমোদন;
• প্রোটোকল প্যারামিটার;
• যেসব Stream-এর অবস্থা এখনো বৈধ, তার কিছু।

তবে গন্তব্য ওয়েবসাইটের নিজস্ব TCP সংযোগ শেষ হয়ে গেলে অ্যাপকে তবুও নতুন করে সংযোগ করতে হতে পারে।

তাই এভাবে প্রচার করা উচিত নয়:

নেটওয়ার্ক বদলালেও প্রতিটি অ্যাপ সবসময় কোনো বিঘ্ন ছাড়াই চলবে।

আরও সঠিক বক্তব্য হলো:

SingLink 2.0 পুনঃসংযোগের সময় কমায়, প্রোটোকল ও রাউটিংয়ের অবস্থা ফিরিয়ে আনে এবং অ্যাপের ওপর প্রভাব যতটা সম্ভব কমানোর চেষ্টা করে।

---

ধাপ 20: নোড ব্যর্থতা ও স্বয়ংক্রিয় বদল

নোডের ব্যতিক্রমকে ভাগ করা যায়:

সফট ফেইলিওর

• ল্যাটেন্সি বাড়ছে;
• মাঝেমধ্যে প্যাকেট লস;
• সাময়িকভাবে সাড়া নেই;
• কিছু গন্তব্যে পৌঁছানো যাচ্ছে না।

করণীয়:

• কিছুক্ষণ অপেক্ষা;
• ট্রান্সপোর্টের চাপ কমানো;
• আবার মাপা;
• একই নোডে পুনঃসংযোগ।

হার্ড ফেইলিওর

• নোডে পৌঁছানো যাচ্ছে না;
• প্রমাণীকরণ ইন্টারফেস অনুপলব্ধ;
• টানা টাইমআউট;
• নোডটি সেবা থেকে সরিয়ে নেওয়া হয়েছে।

করণীয়:

1. আগের নোড ব্যবহার বন্ধ করা।
2. Kill Switch চালু করা।
3. উপলব্ধ তালিকা থেকে বিকল্প বেছে নেওয়া।
4. নতুন নিরাপদ Session স্থাপন।
5. DNS ও রুট ফিরিয়ে আনা।
6. প্রয়োজনীয় সংযোগ নতুন করে গড়তে অ্যাপকে জানানো।

প্রোডাকশন 2.0 আরও রক্ষণশীলভাবে নোড বদলাতে পারে, যাতে ক্ষণিকের জিটারে বারবার নোড লাফালাফি না হয়।

Beta আরও আগ্রাসীভাবে পুনঃসংযোগ বা দ্রুতগতির নোড বাছাই করতে পারে, তবে তাতে ওঠানামা বেশি হতে পারে।

---

ধাপ 21: ডেটা ফেরত আনা ও ডিক্যাপসুলেশন

গন্তব্য ওয়েবসাইটের উত্তর এই পথে আসে:

গন্তব্য ওয়েবসাইট ডেটা ফেরত দেয়
        ↓
SingLink নোড তা গ্রহণ করে
        ↓
মিল থাকা Session ও Stream খুঁজে বের করা
        ↓
SingLink ডেটা ফ্রেম হিসেবে এনক্যাপসুলেট
        ↓
এনক্রিপ্ট করে ক্লায়েন্টে পাঠানো
        ↓
ক্লায়েন্ট অখণ্ডতা যাচাই করে
        ↓
ডিক্রিপ্ট
        ↓
Stream ID অনুযায়ী ডিমাল্টিপ্লেক্স
        ↓
TUN বা সিস্টেম প্রক্সিতে লেখা
        ↓
মূল অ্যাপে ফেরত দেওয়া

ক্লায়েন্টকে যাচাই করতে হয়:

• ডেটা পরিবর্তিত হয়েছে কি না;
• ক্রমিক নম্বর সঠিক কি না;
• ফ্রেমটি ডুপ্লিকেট কি না;
• Stream এখনো আছে কি না;
• দৈর্ঘ্য সীমার মধ্যে কি না;
• গ্রহণের উইন্ডো ছাড়িয়ে গেছে কি না।

অবৈধ ডেটা সরাসরি অ্যাপে পৌঁছে দেওয়া চলবে না।

---

ধাপ 22: স্বাভাবিক সংযোগ বিচ্ছিন্ন ও নিরাপদ পরিচ্ছন্নতা

ব্যবহারকারী Disconnect বেছে নিলে ক্লায়েন্টের উচিত:

1. নতুন প্রক্সি ট্রাফিক নেওয়া বন্ধ করা;
2. সক্রিয় Stream স্বাভাবিকভাবে বন্ধ করা;
3. নোডে Session সমাপ্তির বার্তা পাঠানো;
4. সেশন কী মুছে ফেলা;
5. স্বল্পমেয়াদি টোকেন বাতিল বা পরিত্যাগ করা;
6. TUN বন্ধ করা;
7. সিস্টেমের রুট ফিরিয়ে আনা;
8. DNS ফিরিয়ে আনা;
9. Kill Switch নিয়ম সরানো;
10. অপ্রয়োজনীয় অস্থায়ী কনফিগারেশন সরানো।

ক্লায়েন্ট ক্র্যাশ করলে অপারেটিং সিস্টেম বা পরের বার চালুর সময়ও মেরামতের একটি পথ থাকা দরকার, যাতে থেকে না যায়:

• অকার্যকর সিস্টেম প্রক্সি;
• ভুল DNS;
• অবশিষ্ট রুট;
• ইন্টারনেট সংযোগহীনতা;
• স্থায়ীভাবে আটকে থাকা Kill Switch।

---

SingLink Beta ও 2.0-এর কৌশলগত বিস্তারিত পার্থক্য

নিচে পণ্যের প্রযুক্তিগত অবস্থান তুলে ধরা হয়েছে; সঠিক প্যারামিটার এখনো প্রকৌশল দলের নিশ্চিতকরণ সাপেক্ষ।

প্রক্রিয়াকরণের ক্ষেত্র	SingLink Beta	SingLink 2.0
প্রধান লক্ষ্য	সর্বোচ্চ গতি	গতি, স্থিতিশীলতা, সামঞ্জস্য
সংযোগের প্যারামিটার	বেশি আগ্রাসী	অভিযোজনশীল ও বেশি রক্ষণশীল
সমান্তরালতা	বেশি সমান্তরালতা ব্যবহার করতে পারে	একটি প্রবাহ যেন চ্যানেল ভরিয়ে না ফেলে
ট্রান্সপোর্ট উইন্ডো	থ্রুপুটের দিকে ঝোঁক	ল্যাটেন্সি ও লস অনুযায়ী গতিশীলভাবে সমন্বিত
নোড বদল	দ্রুতগতির নোড আগে চেষ্টা	ব্যর্থতা নিশ্চিত করে তারপর বদল
মাল্টিপ্লেক্সিং	পুনর্ব্যবহারের দক্ষতার দিকে ঝোঁক	পুনর্ব্যবহার ও ব্যর্থতা-বিচ্ছিন্নতার ভারসাম্য
Padding	কম বাড়তি খরচকে অগ্রাধিকার	পরিবেশ অনুযায়ী মানিয়ে নেয়
নেটওয়ার্ক পরিবর্তন	মৌলিক পুনরুদ্ধার	আরও পূর্ণাঙ্গ পুনরুদ্ধার ও সামঞ্জস্য
প্ল্যাটফর্ম রিগ্রেশন পরীক্ষা	প্রিভিউ পরিসর	পূর্ণ প্রোডাকশন পরীক্ষা
অভ্যন্তরীণ স্থিতিশীলতা	প্রায় 97%	99.5%
গতি	উপযুক্ত পরিস্থিতিতে 1 Gbps-এর বেশি	শুধু সর্বোচ্চ গতির পেছনে না ছুটেও দ্রুত

---

এক অনুচ্ছেদে পূর্ণ প্রক্রিয়া-নীতি

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

Beta ও 2.0-এর মৌলিক পার্থক্য হলো:

SingLink Beta আরও আগ্রাসীভাবে সর্বোচ্চ গতির পেছনে ছোটে। SingLink 2.0 দ্রুতগতির স্থানান্তর বজায় রেখে আরও পূর্ণাঙ্গ সামঞ্জস্য, স্বাস্থ্য-পরীক্ষা, ব্যতিক্রমের শ্রেণিবিন্যাস, সেশন পুনরুদ্ধার ও ক্রস-প্ল্যাটফর্ম ব্যবস্থাপনা যোগ করে, তাই এর স্থিতিশীলতা বেশি।

---

সচরাচর জিজ্ঞাসিত প্রশ্ন (FAQ)

SingLink 2.0 কী?

SingLink 2.0 হলো SingLinkVPN-এর তৈরি অফিসিয়াল নেটওয়ার্ক ট্রান্সপোর্ট প্রোটোকল। এটি পরিচয় যাচাই, এনক্রিপ্টেড সেশন, ট্রাফিক এনক্যাপসুলেশন, TCP ও UDP ট্রান্সপোর্ট, স্বাস্থ্য-পরীক্ষা ও ব্যতিক্রম থেকে পুনরুদ্ধার সামলায়।

SingLink 2.0 কি কোনো সফটওয়্যার সংস্করণ?

না। SingLink 2.0 হলো প্রোটোকলের অফিসিয়াল নাম। Windows, macOS, Android ও iOS ক্লায়েন্টের সংস্করণ আলাদা সংস্করণ-ব্যবস্থা মেনে চলে।

SingLink Beta ও 2.0-এর মধ্যে পার্থক্য কী?

Beta হলো গতিকে অগ্রাধিকার দেওয়া একটি প্রিভিউ প্রোটোকল, যার সর্বোচ্চ গতি উপযুক্ত পরিস্থিতিতে 1 Gbps ছাড়াতে পারে। 2.0 হলো প্রোডাকশন প্রোটোকল, যা গতি, স্থিতিশীলতা, ক্রস-প্ল্যাটফর্ম সামঞ্জস্য ও সংযোগ বিচ্ছিন্নতা থেকে পুনরুদ্ধারে জোর দেয়।

SingLink 2.0-এর স্থিতিশীলতার হার কত?

নির্দিষ্ট পরিস্থিতিতে SingLinkVPN-এর অভ্যন্তরীণ A/B পরীক্ষায় SingLink 2.0 পৌঁছেছে 99.5% স্থিতিশীলতায়, আর Beta সর্বোচ্চ প্রায় 97%-এ।

SingLink কীভাবে নেটওয়ার্ক ট্রাফিক প্রক্রিয়া করে?

SingLink-এর ক্লায়েন্ট প্রথমে সিস্টেমের ট্রাফিকের নিয়ন্ত্রণ নিয়ে DNS সামলানো ও স্মার্ট রাউটিং করে। এরপর অ্যাকাউন্ট ও নোডের অধিকার যাচাই করে, একটি এনক্রিপ্টেড Session প্রতিষ্ঠা করে, TCP বা UDP ডেটা এনক্যাপসুলেট করে নোডে পাঠায়।

SingLink কীভাবে সংযোগ বিচ্ছিন্নতা সামলায়?

SingLink ক্রমাগত ল্যাটেন্সি, প্যাকেট লস, হার্টবিট ও নোডের অবস্থা পরীক্ষা করে। কোনো ব্যতিক্রম হলে এটি Session আবার প্রতিষ্ঠা করতে, রুট ফিরিয়ে আনতে বা একটি উপলব্ধ নোডে চলে যেতে পারে।

SingLink আর VLESS-এর পার্থক্য কী?

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

SingLink আর AnyTLS-এর পার্থক্য কী?

AnyTLS মূলত একটি TLS সংযোগের ওপর একটি Session ও একাধিক Stream বহন করে। SingLink-এর পণ্যগত ভূমিকা আরও বিস্তৃত, যাতে স্মার্ট রাউটিং, সদস্যপদের অধিকার, নোড শিডিউলিং ও সংযোগ পুনরুদ্ধারও আছে। আসল Session ও Stream বাস্তবায়ন অফিসিয়াল প্রযুক্তিগত ডকুমেন্টেশন সাপেক্ষ।

SingLink 2.0 কারা ব্যবহার করতে পারেন?

প্রোডাকশন SingLink 2.0 প্রোটোকলের নোড বর্তমানে মূলত Pro, Max ও Rich ব্যবহারকারীদের জন্য উপলব্ধ। Beta প্রোটোকল সব সদস্যের জন্য উন্মুক্ত। আসলে কী ব্যবহার করা যাবে, তার জন্য সর্বশেষ ক্লায়েন্টে যা দেখায় সেটাই চূড়ান্ত।

SingLink 2.0 কি পুরোপুরি ওপেন সোর্স?

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

---

উৎস ও আরও পড়ুন

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

সংশ্লিষ্ট পাঠ: SingLinkVPN বিনামূল্যে প্ল্যানের পূর্ণ গাইড, SingLinkVPN ওপেন-সোর্স পরিকল্পনা এবং 2026 সালের SingLinkVPN নিরাপত্তা অডিট রিপোর্ট।

প্রযুক্তিগত টীকা: 99.5%, প্রায় 97% ও 1 Gbps-এর বেশি—এই সংখ্যাগুলো যথাক্রমে নির্দিষ্ট পরিস্থিতিতে অভ্যন্তরীণ A/B স্থিতিশীলতা ও সর্বোচ্চ থ্রুপুটের ফল। এর মানে এই নয় যে প্রতিটি অঞ্চল, ডিভাইস, ক্যারিয়ার, নেটওয়ার্ক বা সময়ে একই ফল পাওয়া যাবে। নির্দিষ্ট এনক্রিপশন অ্যালগরিদম, প্যাকেট ফরম্যাট, Session ও Stream-এর কার্যপদ্ধতি ভবিষ্যতের অফিসিয়াল SingLink প্রযুক্তিগত ডকুমেন্ট ও প্রকাশিত সোর্স কোড সাপেক্ষ।