কার্যকরী QUIC প্রোটোকল: কিভাবে Uber কার্যক্ষমতা অপ্টিমাইজ করতে এটি প্রয়োগ করেছে

QUIC প্রোটোকলটি দেখার জন্য অত্যন্ত আকর্ষণীয়, তাই আমরা এটি সম্পর্কে লিখতে পছন্দ করি। কিন্তু যদি QUIC সম্পর্কে পূর্ববর্তী প্রকাশনাগুলি একটি ঐতিহাসিক (স্থানীয় ইতিহাস, যদি আপনি চান) প্রকৃতি এবং হার্ডওয়্যার ছিল, আজ আমরা একটি ভিন্ন ধরনের অনুবাদ প্রকাশ করতে পেরে খুশি - আমরা 2019 সালে প্রোটোকলের বাস্তব প্রয়োগ সম্পর্কে কথা বলব। তদুপরি, আমরা তথাকথিত গ্যারেজে ভিত্তিক ছোট অবকাঠামোর কথা বলছি না, তবে উবার সম্পর্কে, যা প্রায় সারা বিশ্বে কাজ করে। কীভাবে কোম্পানির প্রকৌশলীরা উৎপাদনে QUIC ব্যবহার করার সিদ্ধান্তে এসেছেন, তারা কীভাবে পরীক্ষা চালিয়েছে এবং উৎপাদনে এটি রোল করার পরে তারা কী দেখেছে - কাটার নীচে।

ছবি ক্লিকযোগ্য. পড়া ভোগ!

Uber-এর একটি বিশ্বব্যাপী স্কেল রয়েছে, যথা 600টি শহরের উপস্থিতি, যার প্রতিটিতে অ্যাপ্লিকেশনটি সম্পূর্ণরূপে 4500 টিরও বেশি সেলুলার অপারেটরের ওয়্যারলেস ইন্টারনেটের উপর নির্ভর করে। ব্যবহারকারীরা আশা করেন যে অ্যাপটি কেবল দ্রুত নয়, বাস্তব সময়ে হবে - এটি অর্জন করতে, উবার অ্যাপটির কম লেটেন্সি এবং একটি খুব নির্ভরযোগ্য সংযোগ প্রয়োজন। হায়, কিন্তু স্ট্যাক HTTP- র / 2 গতিশীল এবং ক্ষতি-প্রবণ ওয়্যারলেস নেটওয়ার্কগুলিতে ভাল কাজ করে না। আমরা বুঝতে পেরেছি যে এই ক্ষেত্রে, কম কর্মক্ষমতা সরাসরি অপারেটিং সিস্টেম কার্নেলে TCP বাস্তবায়নের সাথে সম্পর্কিত।

সমস্যা সমাধানের জন্য, আমরা আবেদন করেছি QUIC, একটি আধুনিক চ্যানেল মাল্টিপ্লেক্সিং প্রোটোকল যা ট্রান্সপোর্ট প্রোটোকলের কার্যক্ষমতার উপর আমাদের আরও নিয়ন্ত্রণ দেয়। বর্তমানে ওয়ার্কিং গ্রুপ IETF QUIC হিসাবে প্রমিত করে HTTP- র / 3.

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

এই নিবন্ধে, আমরা QUIC সমর্থন করে এমন একটি স্ট্যাক ব্যবহার করে Uber অ্যাপ্লিকেশনের জন্য TCP অপ্টিমাইজ করার আমাদের অভিজ্ঞতা শেয়ার করি।

সর্বশেষ প্রযুক্তি: TCP

বর্তমানে, ইন্টারনেটে HTTPS ট্রাফিক সরবরাহের জন্য TCP হল সবচেয়ে বেশি ব্যবহৃত ট্রান্সপোর্ট প্রোটোকল। TCP বাইটের একটি নির্ভরযোগ্য স্ট্রীম প্রদান করে, যার ফলে নেটওয়ার্ক কনজেশন এবং লিঙ্ক লেয়ার লস মোকাবেলা করে। HTTPS ট্র্যাফিকের জন্য TCP-এর ব্যাপক ব্যবহার পূর্বের সর্বজনীনতার কারণে (প্রায় প্রতিটি OS-এ TCP থাকে), বেশিরভাগ অবকাঠামোতে (যেমন লোড ব্যালেন্সার, HTTPS প্রক্সি এবং CDN) উপলব্ধতা এবং উপলভ্য কার্যকারিতা প্রায় বেশিরভাগ প্ল্যাটফর্ম এবং নেটওয়ার্কে।

বেশিরভাগ ব্যবহারকারীরা যেতে যেতে আমাদের অ্যাপ ব্যবহার করেন এবং TCP টেল লেটেন্সিগুলি আমাদের রিয়েল-টাইম HTTPS ট্র্যাফিকের চাহিদার কাছাকাছি ছিল না। সহজ কথায়, সারা বিশ্বের ব্যবহারকারীরা এটির অভিজ্ঞতা পেয়েছেন - চিত্র 1 প্রধান শহরগুলিতে বিলম্ব দেখায়:

চিত্র 1: টেল লেটেন্সি Uber এর প্রধান শহর জুড়ে পরিবর্তিত হয়।

যদিও ভারতীয় এবং ব্রাজিলিয়ান নেটওয়ার্কে লেটেন্সি মার্কিন যুক্তরাষ্ট্র এবং যুক্তরাজ্যের তুলনায় বেশি ছিল, টেল লেটেন্সি গড় বিলম্বের তুলনায় উল্লেখযোগ্যভাবে বেশি। এবং এটি মার্কিন যুক্তরাষ্ট্র এবং যুক্তরাজ্যের জন্যও সত্য।

বায়ু কর্মক্ষমতা উপর TCP

TCP এর জন্য তৈরি করা হয়েছিল তারযুক্ত নেটওয়ার্ক, যে, অত্যন্ত অনুমানযোগ্য লিঙ্কগুলির উপর জোর দিয়ে। যাহোক, বেতার নেটওয়ার্কগুলির নিজস্ব বৈশিষ্ট্য এবং অসুবিধা রয়েছে। প্রথমত, ওয়্যারলেস নেটওয়ার্ক হস্তক্ষেপ এবং সংকেত ক্ষয়জনিত কারণে ক্ষতির জন্য সংবেদনশীল। উদাহরণস্বরূপ, Wi-Fi নেটওয়ার্কগুলি মাইক্রোওয়েভ, ব্লুটুথ এবং অন্যান্য রেডিও তরঙ্গের প্রতি সংবেদনশীল। সেলুলার নেটওয়ার্ক সংকেত ক্ষতির শিকার হয় (হারিয়ে যাওয়া পথ) বস্তু এবং ভবন দ্বারা সংকেতের প্রতিফলন/শোষণের কারণে, সেইসাথে থেকে হস্তক্ষেপ প্রতিবেশী থেকে সেল টাওয়ার. এটি আরও উল্লেখযোগ্য (4-10 বার) এবং আরও বৈচিত্র্যের দিকে পরিচালিত করে রাউন্ড ট্রিপ টাইম (RTT) এবং একটি তারযুক্ত সংযোগের তুলনায় প্যাকেটের ক্ষতি।

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

অবশেষে, সেলুলার নেটওয়ার্ক কর্মক্ষমতা ক্যারিয়ার, অঞ্চল এবং সময় অনুসারে পরিবর্তিত হয়। চিত্র 2-এ, আমরা 2-কিলোমিটার পরিসরের মধ্যে ঘর জুড়ে HTTPS ট্র্যাফিকের গড় বিলম্ব সংগ্রহ করেছি। ভারতের দিল্লিতে দুটি বড় সেলুলার অপারেটরের জন্য ডেটা সংগ্রহ করা হয়েছে। আপনি দেখতে পাচ্ছেন, কার্যক্ষমতা কোষ থেকে কোষে পরিবর্তিত হয়। এছাড়াও, একটি অপারেটরের উত্পাদনশীলতা দ্বিতীয়টির উত্পাদনশীলতার থেকে পৃথক। এটি নেটওয়ার্ক এন্ট্রি প্যাটার্ন যেমন অ্যাকাউন্টের সময় এবং অবস্থান, ব্যবহারকারীর গতিশীলতা, সেইসাথে নেটওয়ার্ক অবকাঠামো টাওয়ারের ঘনত্ব এবং নেটওয়ার্ক প্রকারের অনুপাত (LTE, 3G, ইত্যাদি) বিবেচনায় নেওয়ার মতো কারণগুলির দ্বারা প্রভাবিত হয়।

চিত্র 2. একটি উদাহরণ হিসাবে 2 কিমি ব্যাসার্ধ ব্যবহার করে বিলম্ব। দিল্লি, ভারত।

এছাড়াও, সেলুলার নেটওয়ার্কের কর্মক্ষমতা সময়ের সাথে পরিবর্তিত হয়। চিত্র 3 সপ্তাহের দিনের মধ্যবর্তী বিলম্ব দেখায়। আমরা একক দিন এবং ঘন্টার মধ্যে একটি ছোট স্কেলে পার্থক্যও পর্যবেক্ষণ করেছি।

চিত্র 3. লেজ বিলম্ব দিনের মধ্যে উল্লেখযোগ্যভাবে পরিবর্তিত হতে পারে, কিন্তু একই অপারেটরের জন্য।

উপরোক্ত সবগুলি TCP কার্যকারিতা ওয়্যারলেস নেটওয়ার্কে অকার্যকর হওয়ার কারণ। যাইহোক, TCP-এর বিকল্প খোঁজার আগে, আমরা নিম্নলিখিত বিষয়গুলির উপর একটি সুনির্দিষ্ট বোঝার বিকাশ করতে চেয়েছিলাম:

• টিসিপি কি আমাদের অ্যাপ্লিকেশনে লেলেন্সিগুলির পিছনে প্রধান অপরাধী?
• আধুনিক নেটওয়ার্কগুলিতে কি উল্লেখযোগ্য এবং বিভিন্ন রাউন্ড-ট্রিপ বিলম্ব (RTT) আছে?
• আরটিটি এবং টিসিপি কার্যক্ষমতার ক্ষতির প্রভাব কী?

TCP কর্মক্ষমতা বিশ্লেষণ

আমরা কীভাবে TCP কার্যক্ষমতা বিশ্লেষণ করেছি তা বোঝার জন্য, আসুন TCP কীভাবে একজন প্রেরক থেকে একজন প্রাপকের কাছে ডেটা স্থানান্তর করে তা দ্রুত দেখে নেওয়া যাক। প্রথমে, প্রেরক একটি TCP সংযোগ স্থাপন করে, একটি ত্রিমুখী সম্পাদন করে হ্যান্ডশেক: প্রেরক একটি SYN প্যাকেট পাঠায়, রিসিভার থেকে একটি SYN-ACK প্যাকেটের জন্য অপেক্ষা করে, তারপর একটি ACK প্যাকেট পাঠায়৷ একটি অতিরিক্ত দ্বিতীয় এবং তৃতীয় পাস TCP সংযোগ স্থাপনের জন্য ব্যয় করা হয়। নির্ভরযোগ্য ডেলিভারি নিশ্চিত করতে প্রাপক প্রতিটি প্যাকেটের (ACK) প্রাপ্তি স্বীকার করে।

যদি একটি প্যাকেট বা ACK হারিয়ে যায়, প্রেরক একটি সময় শেষ হওয়ার পরে পুনরায় প্রেরণ করে (RTO, পুনঃপ্রচারের সময়সীমা) RTO বিভিন্ন কারণের উপর ভিত্তি করে গতিশীলভাবে গণনা করা হয়, যেমন প্রেরক এবং প্রাপকের মধ্যে প্রত্যাশিত RTT বিলম্ব।

চিত্র 4. টিসিপি/টিএলএস-এর মাধ্যমে প্যাকেট বিনিময় একটি পুনঃপ্রচার প্রক্রিয়া অন্তর্ভুক্ত করে।

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

উভয় পরীক্ষার ফলাফল একে অপরের সাথে সামঞ্জস্যপূর্ণ ছিল। আমরা উচ্চ RTT বিলম্ব দেখেছি; লেজের মান মধ্যম মানের তুলনায় প্রায় 6 গুণ বেশি ছিল; বিলম্বের গাণিতিক গড় 1 সেকেন্ডের বেশি। অনেক সংযোগ ক্ষতিগ্রস্থ ছিল, যার ফলে TCP সমস্ত প্যাকেটের 3,5% পুনরায় প্রেরণ করেছে। বিমানবন্দর এবং ট্রেন স্টেশনের মতো যানজটপূর্ণ এলাকায়, আমরা 7% লোকসান দেখেছি। এই ফলাফলগুলি সেলুলার নেটওয়ার্কগুলিতে ব্যবহৃত প্রচলিত জ্ঞানের উপর সন্দেহ প্রকাশ করে উন্নত রিট্রান্সমিশন সার্কিট উল্লেখযোগ্যভাবে পরিবহন স্তরে ক্ষতি হ্রাস. নীচে "সিমুলেটর" অ্যাপ্লিকেশন থেকে পরীক্ষার ফলাফল রয়েছে:

নেটওয়ার্ক মেট্রিক্স
অর্থ

RTT, মিলিসেকেন্ড [50%,75%, 95%,99%]
[১, ৩, ৫, ১]

RTT ডাইভারজেন্স, সেকেন্ড
গড়ে ~1,2 সেকেন্ড

অস্থির সংযোগে প্যাকেটের ক্ষতি
গড় ~3.5% (ওভারলোডেড এলাকায় 7%)

এই সংযোগগুলির প্রায় অর্ধেকই কমপক্ষে একটি প্যাকেট হারিয়েছে, যার বেশিরভাগেরই SYN এবং SYN-ACK প্যাকেট৷ বেশিরভাগ TCP বাস্তবায়ন SYN প্যাকেটের জন্য 1 সেকেন্ডের RTO মান ব্যবহার করে, যা পরবর্তী ক্ষতির জন্য দ্রুতগতিতে বৃদ্ধি পায়। টিসিপি সংযোগ স্থাপন করতে বেশি সময় নেয় বলে অ্যাপ্লিকেশন লোড হওয়ার সময় বাড়তে পারে।

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

পরিমাপকৃত RTT-এর 75 তম পার্সেন্টাইল প্রায় 425 ms, TCP-এর 75 তম পার্সেন্টাইল ছিল প্রায় 3 সেকেন্ড। এটি ইঙ্গিত দেয় যে ক্ষতির কারণে TCP সফলভাবে ডেটা প্রেরণ করতে 7-10 পাস নিতে হয়েছে। এটি অদক্ষ RTO গণনার একটি পরিণতি হতে পারে, TCP-এর ক্ষতির দ্রুত প্রতিক্রিয়া জানাতে অক্ষমতা সর্বশেষ প্যাকেজ উইন্ডোতে এবং কনজেশন কন্ট্রোল অ্যালগরিদমের অদক্ষতা, যা নেটওয়ার্ক কনজেশনের কারণে ওয়্যারলেস ক্ষতি এবং ক্ষতির মধ্যে পার্থক্য করে না। নীচে TCP ক্ষতি পরীক্ষার ফলাফল আছে:

TCP প্যাকেট ক্ষতি পরিসংখ্যান
মান

কমপক্ষে 1 প্যাকেট ক্ষতির সাথে সংযোগের শতাংশ
45%

সংযোগ সেটআপের সময় ক্ষতির সাথে সংযোগের শতাংশ
30%

ডেটা বিনিময়ের সময় ক্ষতির সাথে সংযোগের শতাংশ
76%

পুনঃপ্রচারে বিলম্বের বিতরণ, সেকেন্ড [50%, 75%, 95%,99%] [1, 2.8, 15, 28]

একটি প্যাকেট বা TCP সেগমেন্টের জন্য রিট্রান্সমিশনের সংখ্যার বিতরণ
[1,3,6,7]

QUIC এর আবেদন

মূলত Google দ্বারা বিকশিত, QUIC হল একটি বহু-থ্রেডেড আধুনিক পরিবহন প্রোটোকল যা UDP-এর উপরে চলে। বর্তমানে QUIC আছে প্রমিতকরণ প্রক্রিয়া (আমরা ইতিমধ্যেই লিখেছি যে QUIC এর দুটি সংস্করণ রয়েছে, কৌতূহলী লিঙ্ক অনুসরণ করতে পারেন - প্রায়. অনুবাদক)। চিত্র 5-এ যেমন দেখানো হয়েছে, QUIC কে HTTP/3 এর অধীনে রাখা হয়েছে (আসলে, QUIC-এর উপরে HTTP/2 হল HTTP/3, যা এখন নিবিড়ভাবে প্রমিত করা হচ্ছে)। এটি প্যাকেট তৈরি করতে UDP ব্যবহার করে HTTPS এবং TCP স্তরগুলিকে আংশিকভাবে প্রতিস্থাপন করে। QUIC শুধুমাত্র নিরাপদ ডেটা স্থানান্তর সমর্থন করে কারণ TLS সম্পূর্ণরূপে QUIC-এ বিল্ট করা হয়েছে।

চিত্র 5: QUIC HTTP/3 এর অধীনে চলে, TLS প্রতিস্থাপন করে, যা আগে HTTP/2 এর অধীনে চলত।

নীচের কারণগুলি যা আমাদের TCP পরিবর্ধনের জন্য QUIC ব্যবহার করতে রাজি করেছে:

• 0-RTT সংযোগ স্থাপন। QUIC পূর্ববর্তী সংযোগগুলি থেকে অনুমোদনের পুনঃব্যবহারের অনুমতি দেয়, নিরাপত্তা হ্যান্ডশেকের সংখ্যা হ্রাস করে। ভবিষ্যতে TLS1.3 0-RTT সমর্থন করবে, কিন্তু একটি ত্রিমুখী TCP হ্যান্ডশেক এখনও প্রয়োজন হবে।
• HoL ব্লকিং কাটিয়ে ওঠা। HTTP/2 পারফরম্যান্স উন্নত করতে ক্লায়েন্ট প্রতি একটি TCP সংযোগ ব্যবহার করে, কিন্তু এটি HoL (হেড-অফ-লাইন) ব্লকিং হতে পারে। QUIC মাল্টিপ্লেক্সিংকে সহজ করে এবং স্বাধীনভাবে অ্যাপ্লিকেশনে অনুরোধগুলি সরবরাহ করে।
• যানজট নিয়ন্ত্রণ. QUIC অ্যাপ্লিকেশন স্তরে অবস্থান করে, এটি প্রধান পরিবহন অ্যালগরিদম আপডেট করা সহজ করে যা নেটওয়ার্ক প্যারামিটারের (ক্ষতির সংখ্যা বা RTT) উপর ভিত্তি করে প্রেরণ নিয়ন্ত্রণ করে। বেশিরভাগ TCP বাস্তবায়ন অ্যালগরিদম ব্যবহার করে ঘনক, যা লেটেন্সি-সংবেদনশীল ট্র্যাফিকের জন্য সর্বোত্তম নয়৷ সম্প্রতি উন্নত অ্যালগরিদম মত BBR, আরও নিখুঁতভাবে নেটওয়ার্ক মডেল করুন এবং লেটেন্সি অপ্টিমাইজ করুন৷ QUIC আপনাকে BBR ব্যবহার করতে এবং এই অ্যালগরিদমটি ব্যবহার করার সাথে সাথে আপডেট করার অনুমতি দেয়। উন্নতি.
• ক্ষতিপূরণ। QUIC দুটি TLP কল করে (লেজ ক্ষতি তদন্ত) RTO ট্রিগার হওয়ার আগে - এমনকি যখন লোকসান খুব লক্ষণীয় হয়। এটি TCP বাস্তবায়ন থেকে ভিন্ন। TLP দ্রুত পুনঃপূরণ ট্রিগার করার জন্য প্রধানত শেষ প্যাকেট (বা নতুন একটি, যদি একটি থাকে) পুনরায় প্রেরণ করে। উবার যেভাবে তার নেটওয়ার্ক পরিচালনা করে, যেমন সংক্ষিপ্ত, বিক্ষিপ্ত এবং লেটেন্সি-সংবেদনশীল ডেটা স্থানান্তরের জন্য টেল বিলম্বগুলি পরিচালনা করা বিশেষভাবে কার্যকর।
• অপ্টিমাইজ করা ACK. যেহেতু প্রতিটি প্যাকেটের একটি ইউনিক সিকোয়েন্স নম্বর আছে, তাই কোন সমস্যা নেই পার্থক্য প্যাকেটগুলি যখন পুনরায় প্রেরণ করা হয়। ACK প্যাকেটগুলিতে প্যাকেট প্রক্রিয়া করার সময়ও থাকে এবং ক্লায়েন্ট সাইডে একটি ACK তৈরি করে। এই বৈশিষ্ট্যগুলি নিশ্চিত করে যে QUIC আরও সঠিকভাবে RTT গণনা করে। QUIC-এ ACK 256 ব্যান্ড পর্যন্ত সমর্থন করে NACK, প্রেরককে প্যাকেট এলোমেলো করতে আরও স্থিতিস্থাপক হতে সাহায্য করে এবং প্রক্রিয়ায় কম বাইট ব্যবহার করে। নির্বাচনী ACK (স্যাক) TCP-তে সব ক্ষেত্রে এই সমস্যার সমাধান করে না।
• সংযোগ স্থানান্তর। QUIC সংযোগ একটি 64-বিট আইডি দ্বারা চিহ্নিত করা হয়, তাই যদি একটি ক্লায়েন্ট IP ঠিকানা পরিবর্তন করে, পুরানো সংযোগ আইডি কোনো বাধা ছাড়াই নতুন IP ঠিকানায় ব্যবহার করা চালিয়ে যেতে পারে। এটি মোবাইল অ্যাপ্লিকেশনগুলির জন্য একটি খুব সাধারণ অভ্যাস যেখানে ব্যবহারকারী Wi-Fi এবং সেলুলার সংযোগগুলির মধ্যে স্যুইচ করে৷

QUIC এর বিকল্প

আমরা QUIC বেছে নেওয়ার আগে সমস্যা সমাধানের বিকল্প পন্থা বিবেচনা করেছি।

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

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

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

আমাদের গবেষণায় দেখানো হয়েছে যে QUIC সম্ভবত একমাত্র প্রোটোকল যা নিরাপত্তা এবং কর্মক্ষমতা উভয়ই বিবেচনায় রেখে ইন্টারনেট ট্রাফিকের সমস্যায় সাহায্য করতে পারে।

প্ল্যাটফর্মে QUIC এর একীকরণ

সফলভাবে QUIC এম্বেড করতে এবং দুর্বল সংযোগ পরিবেশে অ্যাপ্লিকেশন কর্মক্ষমতা উন্নত করতে, আমরা QUIC প্রোটোকলের সাথে পুরানো স্ট্যাক (HTTP/2 ওভার TLS/TCP) প্রতিস্থাপন করেছি। আমরা নেটওয়ার্ক লাইব্রেরি ব্যবহার করেছি ক্রোনেট থেকে ক্রোমিয়াম প্রকল্প, যা প্রোটোকলের মূল, Google সংস্করণ ধারণ করে - gQUIC। সর্বশেষ IETF স্পেসিফিকেশন অনুসরণ করার জন্য এই বাস্তবায়ন ক্রমাগত উন্নত করা হচ্ছে।

QUIC-এর জন্য সমর্থন যোগ করতে আমরা প্রথমে আমাদের Android অ্যাপে Cronet সংহত করেছি। ইন্টিগ্রেশন এমনভাবে করা হয়েছিল যাতে যতটা সম্ভব মাইগ্রেশন খরচ কমানো যায়। লাইব্রেরি ব্যবহার করা পুরানো নেটওয়ার্কিং স্ট্যাকটিকে সম্পূর্ণরূপে প্রতিস্থাপন করার পরিবর্তে OkHttp, আমরা OkHttp API ফ্রেমওয়ার্কের অধীনে Cronet সংহত করেছি। এইভাবে ইন্টিগ্রেশন করার মাধ্যমে, আমরা আমাদের নেটওয়ার্ক কলগুলিতে পরিবর্তনগুলি এড়াতে পারি (যা দ্বারা ব্যবহৃত হয় রেট্রোফিট) API স্তরে।

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

Google ক্লাউড ব্যালেন্সারে QUIC সম্পূর্ণ করা হচ্ছে

ব্যাকএন্ডের দিকে, QUIC সমাপ্তি Google ক্লাউড লোড ব্যালেন্সিং পরিকাঠামো দ্বারা সরবরাহ করা হয়, যা ব্যবহার করে alt-svc QUIC সমর্থন করার জন্য হেডার সাধারণভাবে, ব্যালেন্সার প্রতিটি HTTP অনুরোধে একটি alt-svc শিরোনাম যোগ করে এবং এটি ইতিমধ্যেই ডোমেনের জন্য QUIC সমর্থনকে বৈধ করে। যখন একটি Cronet ক্লায়েন্ট এই শিরোনামের সাথে একটি HTTP প্রতিক্রিয়া পায়, তখন এটি সেই ডোমেনের পরবর্তী HTTP অনুরোধগুলির জন্য QUIC ব্যবহার করে। একবার ব্যালেন্সার QUIC সম্পূর্ণ করলে, আমাদের পরিকাঠামো স্পষ্টভাবে এই ক্রিয়াটিকে HTTP2/TCP-এর মাধ্যমে আমাদের ডেটা সেন্টারে পাঠায়।

কর্মক্ষমতা ফলাফল

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

পরীক্ষা-নিরীক্ষা ঘ

পরীক্ষার জন্য সরঞ্জাম:

• আমরা যথাক্রমে TCP এবং QUIC এর উপর HTTPS ট্র্যাফিকের অনুমতি দিই তা নিশ্চিত করতে OkHttp এবং Cronet স্ট্যাক দিয়ে Android ডিভাইসগুলি পরীক্ষা করুন;
• একটি জাভা-ভিত্তিক ইমুলেশন সার্ভার যেটি একই ধরনের HTTPS শিরোনাম পাঠায় এবং ক্লায়েন্ট ডিভাইস লোড করে তাদের কাছ থেকে অনুরোধ পাওয়ার জন্য;
• ক্লাউড প্রক্সিগুলি যা শারীরিকভাবে TCP এবং QUIC সংযোগ বন্ধ করতে ভারতের কাছাকাছি অবস্থিত। TCP বন্ধ করার সময় আমরা একটি বিপরীত প্রক্সি ব্যবহার করেছি nginx, QUIC-এর জন্য একটি ওপেন সোর্স রিভার্স প্রক্সি খুঁজে পাওয়া কঠিন ছিল। আমরা ক্রোমিয়াম থেকে মৌলিক QUIC স্ট্যাক ব্যবহার করে নিজেরাই QUIC এর জন্য একটি বিপরীত প্রক্সি তৈরি করেছি এবং প্রকাশিত ওপেন সোর্স হিসাবে এটি ক্রোমিয়ামে।

চিত্র 6. TCP বনাম QUIC রোড টেস্ট স্যুটটিতে OkHttp এবং Cronet সহ Android ডিভাইস, সংযোগ বন্ধ করার জন্য ক্লাউড প্রক্সি এবং একটি এমুলেশন সার্ভার রয়েছে।

পরীক্ষা-নিরীক্ষা ঘ

যখন Google QUIC এর সাথে উপলব্ধ করেছে গুগল ক্লাউড লোড ব্যালেন্সিং, আমরা একই ইনভেন্টরি ব্যবহার করেছি, কিন্তু একটি পরিবর্তনের সাথে: NGINX এর পরিবর্তে, আমরা ডিভাইস থেকে TCP এবং QUIC সংযোগ বন্ধ করতে, সেইসাথে এমুলেশন সার্ভারে HTTPS ট্র্যাফিক রুট করতে Google লোড ব্যালেন্সার নিয়েছি। ব্যালেন্সারগুলি সারা বিশ্বে বিতরণ করা হয়, তবে ডিভাইসের সবচেয়ে কাছের PoP সার্ভার ব্যবহার করুন (ভৌগলিক অবস্থানের জন্য ধন্যবাদ)।

চিত্র 7. দ্বিতীয় পরীক্ষায়, আমরা TCP এবং QUIC-এর সমাপ্তির লেটেন্সি তুলনা করতে চেয়েছিলাম: Google ক্লাউড ব্যবহার করে এবং আমাদের ক্লাউড প্রক্সি ব্যবহার করে।

ফলস্বরূপ, বেশ কয়েকটি প্রকাশ আমাদের জন্য অপেক্ষা করছে:

• PoP এর মাধ্যমে সমাপ্তি TCP কর্মক্ষমতা উন্নত করেছে। যেহেতু ব্যালেন্সাররা ব্যবহারকারীদের কাছাকাছি TCP সংযোগ বন্ধ করে দেয় এবং অত্যন্ত অপ্টিমাইজ করা হয়, এর ফলে RTT কম হয়, যা TCP কর্মক্ষমতা উন্নত করে। এবং যদিও QUIC কম প্রভাবিত হয়েছিল, এটি এখনও টেইল লেটেন্সি কমানোর ক্ষেত্রে (10-30 শতাংশ) TCP-কে ছাড়িয়ে গেছে।
• লেজ প্রভাবিত হয় নেটওয়ার্ক হপস. যদিও আমাদের QUIC প্রক্সিটি Google-এর লোড ব্যালেন্সারগুলির তুলনায় ডিভাইসগুলি থেকে (প্রায় 50 ms উচ্চতর লেটেন্সি) ছিল, এটি একই রকম কর্মক্ষমতা প্রদান করেছে - TCP-এর জন্য 15 তম শতাংশে 20% হ্রাসের বিপরীতে 99% লেটেন্সি হ্রাস৷ এটি পরামর্শ দেয় যে শেষ মাইল রূপান্তরটি নেটওয়ার্কে একটি বাধা।

চিত্র 8: দুটি পরীক্ষার ফলাফল দেখায় যে QUIC উল্লেখযোগ্যভাবে TCP-কে ছাড়িয়ে গেছে।

যুদ্ধ ট্রাফিক

পরীক্ষা দ্বারা অনুপ্রাণিত হয়ে, আমরা আমাদের Android এবং iOS অ্যাপ্লিকেশনগুলিতে QUIC সমর্থন প্রয়োগ করেছি৷ Uber যে শহরে কাজ করে সেখানে QUIC-এর প্রভাব নির্ণয় করতে আমরা A/B পরীক্ষা পরিচালনা করেছি। সাধারণভাবে, আমরা উভয় অঞ্চল, টেলিকম অপারেটর এবং নেটওয়ার্কের ধরন জুড়ে পুচ্ছ বিলম্বে উল্লেখযোগ্য হ্রাস দেখেছি।

নীচের গ্রাফগুলি ম্যাক্রো-অঞ্চল এবং বিভিন্ন নেটওয়ার্ক প্রকার - LTE, 95G, 99G দ্বারা লেজের (3 এবং 2 শতাংশ) শতকরা উন্নতি দেখায়।

চিত্র 9. যুদ্ধের পরীক্ষায়, QUIC বিলম্বের ক্ষেত্রে TCP-কে ছাড়িয়ে গেছে।

শুধুমাত্র ফরওয়ার্ড

সম্ভবত এটি শুধুমাত্র শুরু - উত্পাদনে QUIC এর প্রকাশ স্থিতিশীল এবং অস্থির উভয় নেটওয়ার্কে অ্যাপ্লিকেশন কর্মক্ষমতা উন্নত করার জন্য আশ্চর্যজনক সুযোগ প্রদান করেছে, যথা:

বর্ধিত কভারেজ

প্রকৃত ট্র্যাফিকের প্রোটোকলের কার্যকারিতা বিশ্লেষণ করে, আমরা দেখেছি যে প্রায় 80% সেশন সফলভাবে এর জন্য QUIC ব্যবহার করেছে всех অনুরোধ, যখন 15% সেশন QUIC এবং TCP এর সংমিশ্রণ ব্যবহার করে। আমরা অনুমান করি যে ক্রোনেট লাইব্রেরি টিসিপিতে ফিরে যাওয়ার কারণে এই সংমিশ্রণটি হয়েছে, কারণ এটি প্রকৃত UDP ব্যর্থতা এবং দুর্বল নেটওয়ার্ক অবস্থার মধ্যে পার্থক্য করতে পারে না। আমরা বর্তমানে এই সমস্যার সমাধান খুঁজছি কারণ আমরা QUIC এর পরবর্তী বাস্তবায়নের দিকে কাজ করছি।

QUIC অপ্টিমাইজেশান

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

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

উত্স: www.habr.com