HTTPS ট্র্যাফিক সনাক্তকরণে Wehe এর ত্রুটিগুলি বোঝা

লিঙ্কের টেবিল

বিমূর্ত এবং ভূমিকা

সম্পর্কিত কাজ এবং পটভূমি

টিডি সনাক্তকরণ পরিমাপ সেটআপ উন্নয়নে চ্যালেঞ্জ

কেস স্টাডি : Wehe - মোবাইল এনভায়রনমেন্টের জন্য TD সনাক্তকরণ টুল

HTTPS ট্র্যাফিক-এ Wehe-এর ঘাটতি

HTTPS ট্র্যাফিকের টিডি সনাক্তকরণ

উপসংহার ও তথ্যসূত্র

V. HTTPS ট্রাফিক-এ WEHE-এর শর্টকামিং

আমাদের অধ্যয়ন রিপ্লে করা ট্রাফিক স্ট্রীম, TD সনাক্তকরণ, এবং বিভিন্ন নেটওয়ার্ক কনফিগারেশনে অপারেশনাল সম্ভাব্যতার জন্য নেটওয়ার্ক প্রতিক্রিয়া যাচাই করার উপর দৃষ্টি নিবদ্ধ করে। Google Playstore-এ সর্বজনীনভাবে উপলব্ধ "Wehe" অ্যান্ড্রয়েড অ্যাপ ব্যবহার করে কার্যক্ষম সম্ভাব্যতা যাচাই করা হলেও, TD সনাক্তকরণের পরিস্থিতি তাত্ত্বিক যুক্তি ব্যবহার করে যাচাই করা হয়। নেটওয়ার্ক প্রতিক্রিয়াগুলির বৈধতার জন্য প্রাপ্ত ট্র্যাফিক স্ট্রিমের ব্যান্ডউইথ বিশ্লেষণ প্রয়োজন। এই বিশ্লেষণের জন্য বৈধকরণের পরিস্থিতি অনুযায়ী সম্পাদিত নির্দিষ্ট রিপ্লের জন্য নেটওয়ার্ক লগের প্রয়োজন। ডিভাইসে রিপ্লে করা হয়েছে এবং অন্যান্য একাধিক স্ট্রিমিং

চিত্র 6. রিপ্লে করা YouTube ট্রাফিকের ট্রাফিক শ্রেণীবিভাগ

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

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

এই বিভাগের অনুস্মারক যাচাইকরণের ফলাফল বর্ণনা করে।

A. মূল পরিষেবার ট্রাফিক অনুকরণ

নেটওয়ার্ক প্রতিক্রিয়াগুলি Sec.III-A-এ উল্লিখিত নেটওয়ার্ক মিডল-বক্স দ্বারা সঠিক অনুসন্ধান ট্রাফিক শ্রেণীবিভাগের উপর ভিত্তি করে নেটওয়ার্ক নীতির প্রয়োগের উপর নির্ভরশীল। আমরা একটি বাণিজ্যিক ট্রাফিক শেপার ব্যবহার করে Wehe-এর অনুকরণ করা ট্রাফিকের শ্রেণীবিভাগ যাচাই করেছি। বাণিজ্যিক ট্রাফিক শেপারের ইউজার ইন্টারফেস ব্যবহার করে অনুকরণ করা ট্রাফিকের শ্রেণীবিভাগ পরিলক্ষিত হয়।

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

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

চিত্র 6(ক) দেখায় যে ইন্টারনেট ব্রাউজার ব্যবহার করে ট্রাফিক অ্যাক্সেস করা সঠিকভাবে YouTube হিসাবে শ্রেণীবদ্ধ করা হয়েছে। এটি বাণিজ্যিক ট্রাফিক শেপারের উদ্দেশ্যমূলক আচরণের সাথে ইনলাইন।

চিত্র 6(b) ব্যবহারকারী-ক্লায়েন্ট ব্যবহার করে অ্যাক্সেস করা ট্রাফিকের জন্য ট্রাফিক শ্রেণীবিভাগের ফলাফল দেখায়। এটি যোগাযোগ লিঙ্কের মাধ্যমে কোনও YouTube ট্র্যাফিক স্থানান্তরিত না হওয়ার প্রমাণ দেখায়। অধিকন্তু, এটি HTTPS ট্র্যাফিক হিসাবে একই ট্র্যাফিককে শ্রেণীবদ্ধ করে। এই পরীক্ষার ফলাফল দেখায় যে সমস্ত নেটওয়ার্ক মিডলবক্স সঠিকভাবে Wehe এর রিপ্লে করা ট্র্যাফিককে শ্রেণীবদ্ধ করতে পারে না।

B. রিপ্লে স্ক্রিপ্টে ডেটা হারের প্রভাব

প্রোবিং ট্র্যাফিক জেনারেশন টিডি সনাক্তকরণ অ্যালগরিদম দ্বারা প্রত্যাশিত নেটওয়ার্ক প্রতিক্রিয়াকে প্রভাবিত করে Wehe রিপ্লে স্ক্রিপ্ট তৈরি করার জন্য আসল পরিষেবা থেকে ট্র্যাফিক ট্রেস ব্যবহার করে যা অ্যাপ্লিকেশন ডেটা এবং এর সময় সম্পর্ক সংরক্ষণ করে। এই রিপ্লে স্ক্রিপ্টটি মূল নেটওয়ার্কে এবং ভিন্নভাবে জিও-অবস্থিত নেটওয়ার্কগুলিতেও ব্যবহৃত হয়। যেহেতু ট্র্যাফিক শেপিং রেট একই পরিষেবার জন্য নেটওয়ার্ক জুড়ে পরিবর্তিত হয় (যেমন [৩২] উল্লেখ করা হয়েছে), রিপ্লে স্ক্রিপ্টে সংরক্ষিত ট্র্যাফিক রেট বর্তমানে বিবেচিত নেটওয়ার্কের ট্র্যাফিক আকারের হার থেকে আলাদা হতে পারে। রিপ্লে ট্র্যাফিক রেট ট্র্যাফিক শেপিং রেট থেকে কম হতে পারে।

রিপ্লে স্ক্রিপ্টের ট্র্যাফিক রেট নেটওয়ার্কের শেপিং রেট থেকে কম হলে Wehe পদ্ধতিটি ট্র্যাফিকের পার্থক্য সনাক্ত করে না কারণ এটি ট্র্যাফিক স্ট্রিমকে প্রভাবিত করে না। এই ধরনের রিপ্লে স্ক্রিপ্টগুলি কখনই এই জাতীয় নেটওয়ার্কগুলিতে ট্র্যাফিকের আকার সনাক্ত করতে পারে না। এইভাবে Wehe টুলের TD সনাক্তকরণ ক্ষমতা রিপ্লে স্ক্রিপ্টের প্রোবিং ট্র্যাফিক রেট দ্বারা সীমিত।

C. পোর্ট নম্বর 80 এর ব্যবহার

নেটওয়ার্ক প্রতিক্রিয়াগুলি প্রোবিং ট্র্যাফিক সম্পর্কে নেটওয়ার্ক মিডল-বক্স উপলব্ধি দ্বারা চালিত হয় (সেক. III-A পড়ুন)। রিপ্লে স্ক্রিপ্ট অ্যাপ্লিকেশনের মূল নেটওয়ার্ক ট্রেসে ডেটা সংরক্ষণ করে। আসল অ্যাপ্লিকেশন সার্ভারগুলি প্লেইন-টেক্সট ডেটার জন্য পোর্ট 80 এবং এনক্রিপ্ট করা ডেটা স্থানান্তরের জন্য পোর্ট 443 ব্যবহার করে। Wehe রিপ্লে স্ক্রিপ্ট সরাসরি অ্যাপ্লিকেশনের নেটওয়ার্ক ট্রেস থেকে এনক্রিপ্ট করা ডেটা ব্যবহার করে এবং পোর্ট 80 এ প্রেরণ করে। এই ধরনের ক্ষেত্রে, Wehe আশা করে যে এনক্রিপ্ট করা অ্যাপ্লিকেশন ডেটা ব্যবহার করে নেটওয়ার্ক ডিভাইসগুলির দ্বারা সঠিকভাবে শ্রেণীবদ্ধ করা হবে। পোর্ট 80 এ এই ধরনের ডেটা অসম্ভব কারণ এনক্রিপ্ট করা ট্র্যাফিক ডেটা নেটওয়ার্ক ডিভাইসে তার সনাক্তকরণ প্রকাশ করতে পারে না। সুতরাং রিপ্লে চালানোর জন্য পোর্ট 80 এর ডিফল্ট ব্যবহারের কারণে 443 নম্বর পোর্টে চলমান পরিষেবাগুলির জন্য Wehe টুল প্রয়োজনীয় ট্র্যাফিক স্ট্রিম তৈরি করতে পারে না।

D. ট্রাফিক লোড নিয়ন্ত্রিত নেটওয়ার্ক আচরণ

মনে রাখবেন যে সম্পদের অভাব নেটওয়ার্কগুলিকে নির্দিষ্ট নেটওয়ার্ক ট্রাফিক ব্যবস্থাপনা প্রয়োগ করতে অনুরোধ করে, বিশেষ করে ভারী নেটওয়ার্ক লোড পরিস্থিতিতে, যা তার নেটওয়ার্কের সমস্ত সক্রিয় পরিষেবাগুলির জন্য উপকারী, যেমন, QoS-ভিত্তিক ট্র্যাফিক ব্যবস্থাপনা (সেক. III-A পড়ুন)। আমরা এই ধরনের ট্রাফিক ব্যবস্থাপনার প্রভাব যাচাই করেছি

চিত্র 7. Wehe এর ট্র্যাফিক স্ট্রিম পারফরম্যান্সে নেটওয়ার্ক লোডের প্রভাব৷

নিয়ন্ত্রণ এবং মূল রিপ্লে উভয়ের পারফরম্যান্সের উপর। বৈধতা যাচাইকরণের জন্য নিম্নলিখিত তিনটি পরিস্থিতি ব্যবহার করে,

• নেটওয়ার্কে কোনো লোড ছাড়াই শুধুমাত্র Wehe-এর দুটি ট্রাফিক স্ট্রিম রিপ্লে করা হচ্ছে (চিত্র 7(a))

• সমান্তরালভাবে চলমান একটি অতিরিক্ত স্ট্রিমিং পরিষেবা সহ Wehe-এর তিনটি ট্র্যাফিক স্ট্রিম রিপ্লে করা (চিত্র 7(b))

• 2টি অতিরিক্ত স্ট্রিমিং পরিষেবার সাথে Wehe-এর তিনটি ট্র্যাফিক স্ট্রীম রিপ্লে করা হচ্ছে (চিত্র 7(c))

চিত্র 7(a) এর পারফরম্যান্স দেখায় যে Wehe টুল দ্বারা উত্পন্ন ট্র্যাফিক স্ট্রিমগুলির পারফরম্যান্সগুলি কোনও অতিরিক্ত নেটওয়ার্ক লোড অবস্থার অধীনে একই। নেটওয়ার্ক লোড বাড়ার সাথে সাথে, কন্ট্রোল রিপ্লে এর কার্যকারিতা মূল রিপ্লে থেকে এবং উচ্চ স্তরে (চিত্র 7(বি)) থেকে বিচ্যুত হয়। যদিও কন্ট্রোল রিপ্লে এর কার্যক্ষমতা নীচের দিকের মূল রিপ্লে থেকে আরও বিচ্যুত হয়, দুটি আসল রিপ্লে এখনও চিত্র 7(c) এ দেখানো অনুরূপ পারফরম্যান্স দেখায়। এটি Wehe টুলের কন্ট্রোল রিপ্লে ভিন্নতা না পাওয়ার প্রত্যাশাকে বাতিল করে। এটি মোট ব্যান্ডউইথের কারণে TD শনাক্ত করার টুলের দাবিকেও বাতিল করে।

E. একই সাব-নেটের মধ্যে একাধিক ডিভাইস থেকে Wehe পরীক্ষা করে

এক সাথে একাধিক ব্যবহারকারী ক্লায়েন্টকে সমর্থন করার জন্য Wehe ডিজাইনে সাইড-চ্যানেলগুলি চালু করা হয়েছে। সাইড চ্যানেলগুলি ব্যবহারকারী-ক্লায়েন্ট এবং আইপি ঠিকানা এবং পোর্টগুলির সংমিশ্রণের মধ্যে ম্যাপিং সনাক্ত করতেও সহায়তা করে। এটি NATs ব্যবহার করে নেটওয়ার্কের ক্ষেত্রে দরকারী [33]। আমরা দুটি ভিন্ন পরীক্ষা ব্যবহার করে একাধিক ক্লায়েন্ট এবং NAT-সক্ষম নেটওয়ার্কের জন্য Wehe-এর সমর্থন যাচাই করেছি। প্রথমত, আমরা একই সাবনেটের মধ্যে থেকে দুটি ব্যবহারকারী-ক্লায়েন্টকে সংযুক্ত করেছি, অর্থাৎ, একই পাবলিক আইপি ঠিকানা ভাগ করে নেওয়া ক্লায়েন্টদের। একটি পরীক্ষায়, Wehe টুল উভয় ডিভাইসে একই পরিষেবা পরীক্ষা করে, যেমন, ইউটিউবের জন্য উভয় ডিভাইসের পরীক্ষায় Wehe অ্যাপ। ফলাফল দেখায় যে Wehe পরীক্ষা শুধুমাত্র একটি ডিভাইসে সমাপ্ত হয়েছে যখন Wehe অ্যাপটি অন্য ডিভাইসে হঠাৎ বন্ধ হয়ে গেছে। আমরা একই দৃশ্যের পুনরাবৃত্তি করেছি, কিন্তু এবার Wehe বিভিন্ন পরিষেবা পরীক্ষা করে, যেমন, এক ডিভাইসে Wehe ইউটিউবকে অন্য পরীক্ষার সময় Netflix পরীক্ষা করে। আমরা দেখেছি যে একটি ডিভাইসে Wehe পরীক্ষা সঠিকভাবে সম্পন্ন হয় যখন অন্য ডিভাইসে Wehe পরীক্ষাটি স্ক্রীনে একটি ত্রুটি ছুড়ে দেয়, ব্যবহারকারীকে জানায় যে অন্য ক্লায়েন্ট ইতিমধ্যেই পরীক্ষাটি সম্পাদন করছে, যেমন চিত্র 9-এ দেখানো হয়েছে। এই পরীক্ষাগুলি দেখায় যে Wehe করে একাধিক ডিভাইস সমর্থন করে না যদি তারা একই IP ঠিকানা ভাগ করে। যদিও একটি পার্শ্ব-চ্যানেল একটি ব্যবহারকারী-ক্লায়েন্ট থেকে সরাসরি Wehe রিপ্লে সার্ভারের সাথে সংযুক্ত থেকে প্রতিটি রিপ্লে সনাক্ত করতে উপযোগী, এটি NAT ডিভাইস ব্যবহার করে নেটওয়ার্কে উপযোগী নয়। একাধিক ব্যবহারকারী NAT এর ক্ষেত্রে একই আইপি ঠিকানা ভাগ করে। এই ধরনের ক্ষেত্রে, পাশের চ্যানেলটি ক্লায়েন্টের কাছে চালানো প্রতিটি রিপ্লেকে অনন্যভাবে ম্যাপ করতে পারে না। এটি প্রতি রিপ্লে সার্ভার এবং আইএসপি এবং অ্যাপ্লিকেশন প্রতি শুধুমাত্র একটি সক্রিয় ক্লায়েন্টে Wehe-এর ব্যবহার সীমাবদ্ধ করে। এই সীমাবদ্ধতা Wehe বিকাশকারীদের দ্বারাও নথিভুক্ত করা হয়েছে।

F. টিডি সনাক্তকরণে ডিভাইস নেটওয়ার্ক লোডের প্রভাব

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

তবুও, এই প্রত্যাশা সর্বদা সন্তুষ্ট হয় না কারণ ট্র্যাফিক ডেটা রেট ব্যবহারকারীর ডিভাইসে নেটওয়ার্ক লোড দ্বারা পরিমিত হয় যখন Wehe পরীক্ষাগুলি সম্পাদন করে৷ এই ধরনের বিশৃঙ্খলাগুলি অসঙ্গতি তৈরি করে কারণ অনুসন্ধানী ট্র্যাফিকের উপর সময়-পরিবর্তিত বর্তমান নেটওয়ার্ক লোডের প্রভাবও সময়-পরিবর্তনশীল এবং সবসময় একই নাও হতে পারে। Wehe-এর ব্যাক-টু-ব্যাক রিপ্লে কৌশল নিশ্চিত করে যে উভয় (মূল এবং নিয়ন্ত্রণ রিপ্লে) ট্র্যাফিক স্ট্রীম অনুসন্ধান করা বর্তমান নেটওয়ার্ক লোড দ্বারা ভিন্নভাবে প্রভাবিত হয়। ডিভাইসের দিকে এই ধরনের নেটওয়ার্ক লোডের অধীনে, উপলব্ধ ব্যান্ডউইথের পরিশ্রান্ত না হওয়া পরিষেবার ধারণাটি টিডি সনাক্তকরণের সুবিধাগুলির সাথে বিদ্যমান বন্ধ হয়ে যায়। টিডি সনাক্তকরণের আগে এই ধরনের বিভ্রান্তিকর কারণগুলিকে স্বাভাবিক করা প্রয়োজন (সেক. III-B পড়ুন)।