TURN সার্ভার: এটি কী, কীভাবে কাজ করে এবং কোথায় ব্যবহৃত হয়

TURN সার্ভার কী

TURN সার্ভার (Traversal Using Relays around NAT) হলো RFC 5766-এ সংজ্ঞায়িত এবং RFC 8656-এ আপডেট করা একটি নেটওয়ার্ক পরিষেবা যা দুটি ক্লায়েন্টের মধ্যে UDP এবং TCP ট্রাফিক রিলে করে যখন NAT বা ফায়ারওয়াল সীমাবদ্ধতার কারণে সরাসরি P2P সংযোগ অসম্ভব। WebRTC আর্কিটেকচারে, TURN সার্ভার চূড়ান্ত ফলব্যাক মেকানিজম হিসেবে কাজ করে, যেকোনো নেটওয়ার্ক অবস্থায় কানেক্টিভিটি নিশ্চিত করে।

STUN-এর বিপরীতে, যা শুধু ক্লায়েন্টকে তার বাহ্যিক ঠিকানা জানায়, TURN সার্ভার ডেটা ট্রান্সমিশনে সক্রিয়ভাবে অংশগ্রহণ করে। প্রতিটি পিয়ার TURN সার্ভারের সাথে সংযোগ স্থাপন করে এবং তাতে তার মিডিয়া ডেটা পাঠায়। TURN সার্ভার, পালাক্রমে, এই ডেটা অন্য পিয়ারে ফরোয়ার্ড করে। ফলস্বরূপ, পিয়ারদের মধ্যে কোনো সরাসরি সংযোগ থাকে না — সমস্ত ট্রাফিক রিলে সার্ভারের মাধ্যমে যায়, যা সবচেয়ে কঠোর NAT সীমাবদ্ধতার অধীনেও ডেলিভারি নিশ্চিত করে।

TURN প্রোটোকল

TURN হলো STUN প্রোটোকলের একটি এক্সটেনশন। TURN বার্তাগুলি একই 20-বাইট হেডার এবং অ্যাট্রিবিউট মেকানিজম ব্যবহার করে। মূল পার্থক্য হলো TURN নতুন বার্তা প্রকার (Allocate, Refresh, Send, Data, CreatePermission, ChannelBind) এবং রিলে বরাদ্দ পরিচালনার জন্য প্রয়োজনীয় অ্যাট্রিবিউট সংজ্ঞায়িত করে। ক্লায়েন্ট Allocate বার্তার মাধ্যমে TURN সার্ভারে একটি বরাদ্দ তৈরি করে, একটি রিলেড ট্রান্সপোর্ট ঠিকানা (relayed transport address) পায় এবং সার্ভারের মাধ্যমে ডেটা পাঠানো ও গ্রহণের জন্য এটি ব্যবহার করে।

TURN সার্ভার কীভাবে কাজ করে

TURN সার্ভার নিম্নলিখিত ধাপের ক্রম অনুযায়ী কাজ করে। ক্লায়েন্ট প্রমাণীকরণ (username, credential) সহ Allocate Request পাঠায়। সার্ভার ক্রেডেনশিয়াল যাচাই করে এবং একটি বরাদ্দ তৈরি করে — ক্লায়েন্টের জন্য একটি রিলেড ঠিকানার (TURN সার্ভারে IP:পোর্ট) অস্থায়ী বন্ধন। সার্ভার একটি রিলেড ট্রান্সপোর্ট ঠিকানা সহ Allocate Response ফেরত দেয় — যে ঠিকানাটি অন্য পিয়াররা TURN সার্ভারের মাধ্যমে এই ক্লায়েন্টকে ডেটা পাঠাতে ব্যবহার করবে।

বরাদ্দ তৈরি হওয়ার পরে, ক্লায়েন্ট Send Indication বার্তা বা চ্যানেলের (ChannelBind) মাধ্যমে TURN সার্ভারের মাধ্যমে ডেটা পাঠাতে পারে। ক্লায়েন্টের কাছ থেকে ডেটা পাওয়ার পর, TURN সার্ভার অনুমতি (নির্দিষ্ট পিয়ারদের কাছে ডেটা পাঠানোর অনুমোদন) পরীক্ষা করে এবং ডেটা লক্ষ্য পিয়ারে রিলে করে। ইনকামিং ডেটা পাওয়ার জন্য, ক্লায়েন্টকে প্রথমে পিয়ারের জন্য একটি অনুমতি তৈরি করতে হবে যার কাছ থেকে এটি ডেটা আশা করে; অন্যথায় TURN সার্ভার ইনকামিং প্যাকেটটি বাতিল করবে। অনুমতি পিয়ারের IP ঠিকানা নির্দিষ্ট করে CreatePermission বার্তার মাধ্যমে তৈরি করা হয়।

বরাদ্দ এবং জীবনকাল

TURN সার্ভারে বরাদ্দের সীমিত জীবনকাল থাকে — ডিফল্টভাবে 10 মিনিট। ক্লায়েন্টকে বরাদ্দ বাড়ানোর জন্য পর্যায়ক্রমে Refresh Request পাঠাতে হবে। জীবনকাল LIFETIME অ্যাট্রিবিউটে সেকেন্ডে নির্দিষ্ট করা হয়। কোনো Refresh না পেলে, সার্ভার বরাদ্দ মুছে ফেলে এবং রিলেড ঠিকানা মুক্ত করে। প্রস্তাবিত রিফ্রেশ ব্যবধান — 5 মিনিট (300 সেকেন্ড) Refresh প্যাকেট ক্ষতি থেকে রক্ষার জন্য।

WebRTC-এ TURN সার্ভার কনফিগার করা

WebRTC-এ, TURN সার্ভার iceServers অ্যারেতে RTCPeerConnection কনফিগারেশনের মাধ্যমে কনফিগার করা হয়। TURN সার্ভারগুলি UDP, TCP বা TLS ট্রান্সপোর্ট ব্যবহার করতে পারে। প্রমাণীকরণ সাধারণত অ্যাপ্লিকেশন সার্ভারে সীমিত বৈধতা সময়সীমার সাথে তৈরি সময়-সীমিত ক্রেডেনশিয়াল (TURN ক্রেডেনশিয়াল) ব্যবহার করে।

JavaScript-এ HMAC-SHA1 টোকেন প্রমাণীকরণ সহ TURN সার্ভার কনফিগারেশনের একটি উদাহরণ বিবেচনা করুন।

async function createPeerConnection(turnServerUrl) {
    const credentials = await fetchTurnCredentials();

    const config = {
        iceServers: [
            {
                urls: "stun:stun.l.google.com:19302"
            },
            {
                urls: turnServerUrl,
                username: credentials.username,
                credential: credentials.credential
            }
        ],
        iceTransportPolicy: "all"
    };

    return new RTCPeerConnection(config);
}

async function fetchTurnCredentials() {
    const response = await fetch("/api/turn-credentials");
    return response.json();
}

const turnUrl = "turn:turn.example.com:3478";
const pc = await createPeerConnection(turnUrl);

এই উদাহরণে, TURN সার্ভারটি STUN সার্ভারের সাথে একটি একক ICE কনফিগারেশনে নির্দিষ্ট করা হয়েছে। ICE প্রক্রিয়া প্রথমে host প্রার্থী এবং STUN থেকে প্রাপ্ত srflx প্রার্থী ব্যবহার করার চেষ্টা করে। যদি সরাসরি সংযোগ ব্যর্থ হয়, ICE স্বয়ংক্রিয়ভাবে TURN সার্ভার থেকে প্রাপ্ত relay প্রার্থীতে স্যুইচ করে। প্যারামিটার iceTransportPolicy: "all" relay প্রার্থীদের সক্ষম করে — বিকল্প মান "relay" TURN ছাড়া সব প্রার্থী নিষ্ক্রিয় করে, যা পরীক্ষার জন্য উপযোগী।

TURN সার্ভার প্রমাণীকরণ

অননুমোদিত ব্যবহার রোধ করতে, TURN সার্ভার-এর প্রমাণীকরণ প্রয়োজন। মানক পদ্ধতি হলো HMAC-SHA1 ব্যবহার করে অ্যাপ্লিকেশন সার্ভারে সময়-সীমিত ক্রেডেনশিয়াল তৈরি করা। অ্যাপ্লিকেশন সার্ভার TURN সার্ভারের গোপন কী দিয়ে ব্যবহারকারীর নাম এনক্রিপ্ট করে এবং ক্লায়েন্টকে username ও credential ফেরত দেয়। ক্লায়েন্ট সেগুলি RTCPeerConnection কনফিগারেশনে পাঠায় এবং ব্রাউজার TURN সার্ভারে বরাদ্দ তৈরি করার সময় সেগুলি ব্যবহার করে। ক্রেডেনশিয়ালের মেয়াদ শেষ হলে, ক্লায়েন্ট অ্যাপ্লিকেশন সার্ভার থেকে নতুনগুলি পায়।

TURN বনাম STUN: তুলনা

TURN এবং STUN সম্পর্কিত NAT ট্রাভার্সাল কাজগুলি সমাধান করে কিন্তু প্রক্রিয়া এবং খরচে মৌলিকভাবে ভিন্ন। TURN ট্রাফিক রিলে করে, মধ্যস্থতাকারী হিসেবে কাজ করে, যেখানে STUN শুধুমাত্র সরাসরি P2P সংযোগের জন্য বাহ্যিক ঠিকানা নির্ধারণে সাহায্য করে। তাদের মধ্যে পছন্দ পিয়ার NAT ধরন এবং পারফরম্যান্স প্রয়োজনীয়তার উপর নির্ভর করে।

ব্যবহারিকভাবে, TURN সার্ভার শুধুমাত্র সেই সংযোগগুলির জন্য ব্যবহৃত হয় যেখানে P2P অসম্ভব। Google-এর মতে (WebRTC পরিসংখ্যান, 2023), প্রায় 15–20% সমস্ত WebRTC সংযোগের TURN রিলে প্রয়োজন। বাকি 80–85% STUN বা স্থানীয় host প্রার্থীদের মাধ্যমে কানেক্টিভিটি স্থাপন করে। একটি অ্যাপ্লিকেশন ডিজাইন করার সময়, আপনার মোট মিডিয়া ভলিউমের 15–20% হারে TURN ট্রাফিকের জন্য বাজেট করা উচিত যদি আপনার দর্শকদের মধ্যে কর্পোরেট নেটওয়ার্ক এবং কঠোর NAT সীমাবদ্ধতাযুক্ত অঞ্চলের ব্যবহারকারী অন্তর্ভুক্ত থাকে।

TURN সার্ভারের খরচ এবং পারফরম্যান্স

TURN সার্ভার উল্লেখযোগ্য সম্পদ খরচ করে কারণ সমস্ত মিডিয়া ট্রাফিক এর মাধ্যমে যায়। TURN রিলে সহ প্রতিটি সক্রিয় কল মোট মিডিয়া ট্রাফিক থ্রুপুট (ইনকামিং + আউটগোয়িং স্ট্রিম) সমান সার্ভার ব্যান্ডউইথ ব্যবহার করে। HD ভিডিও কলের (720p) জন্য, এটি প্রতি সংযোগে প্রতিদিকে 1.5–2.5 Mbps হতে পারে, যা TURN সার্ভারের মাধ্যমে মোট 3–5 Mbps ট্রাফিক।

TURN ইনফ্রাস্ট্রাকচার স্থাপনার জন্য বেশ কয়েকটি বিকল্প রয়েছে। গুণমান এবং নিরাপত্তা গ্যারান্টির অভাবে বিনামূল্যের পাবলিক TURN সার্ভার প্রোডাকশনের জন্য সুপারিশ করা হয় না। বাণিজ্যিক প্রদানকারী (Twilio Network Traversal Service, Xirsys, Metered) প্রতি গিগাবাইট মূল্যে TURN একটি পরিষেবা হিসেবে অফার করে — সাধারণ খরচ হলো $0.005–0.02 প্রতি গিগাবাইট। coturn (ওপেন-সোর্স TURN সার্ভার) সহ সেল্ফ-হোস্টিংয়ের জন্য পর্যাপ্ত ব্যান্ডউইথ ক্ষমতা এবং মনিটরিং সেটআপ সহ একটি সার্ভার প্রয়োজন।

• coturn — সবচেয়ে জনপ্রিয় ওপেন-সোর্স TURN সার্ভার, অধিকাংশ প্রোডাকশন সিস্টেমে ব্যবহৃত, UDP, TCP, TLS এবং DTLS ট্রান্সপোর্ট সমর্থন করে।
• Twilio — একটি বাণিজ্যিক পরিষেবা যা ট্রাফিক-ভিত্তিক মূল্য এবং সময়-সীমিত টোকেনের মাধ্যমে প্রমাণীকরণ সহ TURN + STUN প্রদান করে।
• Xirsys — একটি বৈশ্বিক সার্ভার নেটওয়ার্ক এবং বিস্তারিত ব্যবহার বিশ্লেষণ সহ একটি বিশেষায়িত TURN প্রদানকারী।
• Metered.ca — একটি TURN পরিষেবা যা প্রতি মাসে 50 GB পর্যন্ত বিনামূল্যের সীমা এবং তার বেশি পে-এজ-ইউ-গো সহ।
• সেল্ফ-হোস্টেড coturn — কনফিগারেশনের উপর সম্পূর্ণ নিয়ন্ত্রণ, তবে সার্ভার প্রশাসন এবং মনিটরিং সেটআপ প্রয়োজন।

TURN সার্ভার সমাধান নির্বাচন করার সময়, ব্যবহারকারীর ভৌগোলিক অবস্থান, ট্রাফিক খরচ এবং নিরাপত্তা প্রয়োজনীয়তা বিবেচনা করুন। হাজার হাজার সমবর্তী কলের অ্যাপ্লিকেশনের জন্য, প্রশস্ত চ্যানেল (1+ Gbps) সহ সার্ভারে সেল্ফ-হোস্টেড coturn বাণিজ্যিক প্রদানকারীদের তুলনায় বেশি খরচ-কার্যকর হতে পারে। ডজন খানেক ব্যবহারকারীর ছোট প্রকল্পের জন্য, প্রশাসন এবং মনিটরিং ওভারহেডের অভাবে বাণিজ্যিক TURN পরিষেবাগুলি পছন্দনীয়।