Facebook សាកល្បងក្បួនដោះស្រាយការកកស្ទះថ្មី COPA ប្រឆាំងនឹង BBR និង CUBIC

Facebook បោះពុម្ភ លទ្ធផលនៃការពិសោធន៍ជាមួយក្បួនដោះស្រាយការគ្រប់គ្រងការកកស្ទះថ្មី - ស៊ីអរធ្វើឱ្យប្រសើរឡើងសម្រាប់ការបញ្ជូនមាតិកាវីដេអូ។ ក្បួនដោះស្រាយនេះត្រូវបានស្នើឡើងដោយអ្នកស្រាវជ្រាវមកពីវិទ្យាស្ថានបច្ចេកវិទ្យា Massachusetts ។ គំរូ COPA ដែលត្រូវបានស្នើឡើងសម្រាប់ការធ្វើតេស្តត្រូវបានសរសេរនៅក្នុង C ++, បើក មានអាជ្ញាប័ណ្ណក្រោម MIT និងរួមបញ្ចូលក្នុង mvfst — ការអនុវត្តពិធីការ QUIC កំពុងត្រូវបានបង្កើតឡើងនៅ Facebook។

ក្បួនដោះស្រាយ COPA គឺផ្តោតលើការដោះស្រាយបញ្ហាដែលកើតឡើងនៅពេលបញ្ជូនវីដេអូតាមបណ្តាញ។ អាស្រ័យលើប្រភេទវីដេអូ តម្រូវការស្ទើរតែផ្ទុយគ្នាត្រូវបានដាក់លើក្បួនដោះស្រាយការគ្រប់គ្រងការកកស្ទះ - សម្រាប់វីដេអូអន្តរកម្ម ចាំបាច់ត្រូវធានាឱ្យមានការពន្យារពេលតិចតួច ទោះបីជាការចំណាយលើគុណភាពក៏ដោយ ហើយនៅពេលចាក់ផ្សាយវីដេអូដែលមានគុណភាពខ្ពស់ដែលបានរៀបចំជាមុន អាទិភាពត្រូវបានផ្តល់អាទិភាព។ ដើម្បីរក្សាគុណភាព។ ពីមុន អ្នកអភិវឌ្ឍន៍កម្មវិធីត្រូវបានកំណត់ចំពោះសមត្ថភាពក្នុងការអនុវត្តក្បួនដោះស្រាយផ្សេងៗគ្នា អាស្រ័យលើគុណភាព ឬតម្រូវការភាពយឺតយ៉ាវ។ អ្នកស្រាវជ្រាវដែលបានបង្កើត COPA បានព្យាយាមបង្កើតក្បួនដោះស្រាយជាសកលសម្រាប់គ្រប់គ្រងការកកស្ទះវីដេអូ TCP ដែលអាចប្ដូរតាមបំណងដោយផ្អែកលើតម្រូវការវីដេអូ។

ការងាររបស់ក្បួនដោះស្រាយការគ្រប់គ្រងការកកស្ទះគឺដើម្បីកំណត់សមតុល្យដ៏ល្អប្រសើរនៅពេលផ្ញើកញ្ចប់ព័ត៌មាន - ការផ្ញើកញ្ចប់ព័ត៌មានច្រើនពេកអាចនាំឱ្យបាត់បង់កញ្ចប់ព័ត៌មាន និងការថយចុះនៃដំណើរការដោយសារតម្រូវការក្នុងការបញ្ជូនពួកវាឡើងវិញ ហើយការផ្ញើយឺតពេកនាំឱ្យមានការពន្យារពេល ដែលជះឥទ្ធិពលអវិជ្ជមានដល់ការអនុវត្តផងដែរ។ . ពិធីការ QUIC ត្រូវបានជ្រើសរើសសម្រាប់ការពិសោធន៍ ដោយសារវាអនុញ្ញាតឱ្យអនុវត្តក្បួនដោះស្រាយការគ្រប់គ្រងការកកស្ទះក្នុងចន្លោះអ្នកប្រើប្រាស់ដោយមិនរំខានដល់ខឺណែល។

ដើម្បីទប់ស្កាត់ការកកស្ទះនៃបណ្តាញទំនាក់ទំនង COPA ប្រើប្រាស់គំរូនៃលក្ខណៈឆានែលដោយផ្អែកលើការវិភាគនៃការផ្លាស់ប្តូរការពន្យារពេលក្នុងអំឡុងពេលចែកចាយកញ្ចប់ព័ត៌មាន (COPA កាត់បន្ថយទំហំនៃបង្អួចការកកស្ទះនៅពេលការពន្យារពេលកើនឡើង រៀបចំការពន្យារពេលចាប់ផ្តើមកើនឡើងសូម្បីតែនៅដំណាក់កាលមុនពេលការបាត់បង់កញ្ចប់ព័ត៌មានកើតឡើង) . តុល្យភាពរវាងការពន្យាពេល និងលំហូរត្រូវបានកែតម្រូវដោយប្រើប៉ារ៉ាម៉ែត្រ delta ពិសេស។ ការបង្កើន delta បង្កើនភាពប្រែប្រួលទៅនឹងការពន្យាពេល ប៉ុន្តែកាត់បន្ថយការបញ្ជូន ខណៈពេលដែលការថយចុះ delta អនុញ្ញាតឱ្យមានលំហូរកាន់តែខ្ពស់ជាមួយនឹងតម្លៃនៃការបង្កើនភាពយឺតយ៉ាវ។ Delta=0.04 ត្រូវ​បាន​កំណត់​ជា​សមតុល្យ​ដ៏​ល្អ​បំផុត​រវាង​គុណភាព​និង​ភាព​យឺតយ៉ាវ។

COPA ត្រូវបានសាកល្បងប្រឆាំងនឹងក្បួនដោះស្រាយ CUBIC និង BBR ដ៏ពេញនិយមដោយប្រើប្រាស់សេវាកម្មផ្សាយផ្ទាល់តាមហ្វេសប៊ុក។ ក្បួនដោះស្រាយ CUBIC ត្រូវបានប្រើតាមលំនាំដើមនៅក្នុង Linux ហើយ​សង្ខេប​ទៅ​ជា​ការ​កើនឡើង​បន្តិចម្តងៗ​នៃ​ទំហំ​បង្អួច​កកស្ទះ​រហូតដល់​ការបាត់បង់​កញ្ចប់​កើតឡើង បន្ទាប់ពី​នោះ​ទំហំ​បង្អួច​ត្រូវ​បាន​រំកិល​ត្រឡប់​ទៅ​តម្លៃ​មុនពេល​ការបាត់បង់​ចាប់ផ្តើម។

CUBIC ទុកអ្វីៗជាច្រើនដែលចង់បាននៅ packet buffering លើឧបករណ៍បណ្តាញទំនើប ដែលបន្ថយល្បឿននៃ packet drops ។ ក្បួនដោះស្រាយការគ្រប់គ្រងការកកស្ទះគឺមិនដឹងពីការបណ្ដោះអាសន្ន ហើយបន្តបង្កើនល្បឿន បើទោះបីជាឆានែលនេះមានការកកស្ទះរាងកាយរួចហើយក៏ដោយ។ កញ្ចប់ព័ត៌មានដែលមិនបានផ្ញើត្រូវបានផ្អាកជាជាងបោះចោល ហើយក្បួនដោះស្រាយការគ្រប់គ្រងការកកស្ទះរបស់ TCP ចាប់ផ្តើមនៅពេលសតិបណ្ដោះអាសន្នពេញ ហើយមិនអាចមានតុល្យភាពអត្រាលំហូរជាមួយនឹងល្បឿននៃតំណភ្ជាប់រូបវ័ន្តនោះទេ។ ដើម្បីដោះស្រាយបញ្ហានេះ Google បានស្នើនូវក្បួនដោះស្រាយ BBR ដែលត្រូវបានកែលម្អ ដែលព្យាករណ៍ពីកម្រិតបញ្ជូនដែលមានតាមរយៈការត្រួតពិនិត្យតាមលំដាប់លំដោយ និងការប៉ាន់ប្រមាណពេលវេលាទៅមក (RTT) ។

ជាមួយនឹង delta = 0.04 សូចនាករ COPA ប្រែទៅជាជិត CUBIC និង BBR ។ នៅក្នុងការធ្វើតេស្តដែលធ្វើឡើងលើការតភ្ជាប់បណ្តាញល្បឿនលឿនជាមួយនឹងការពន្យាពេលនៃការបញ្ជូនកញ្ចប់ព័ត៌មានទាប COPA ទទួលបានភាពយឺតយ៉ាវទាប (479 ms) បើប្រៀបធៀបទៅនឹង CUBIC (499 ms) ប៉ុន្តែបានធ្លាក់ចុះបន្តិចពីក្រោយ BBR (462 ms) ។ នៅពេលដែលគុណភាពនៃការតភ្ជាប់មានការថយចុះ COPA បានបង្ហាញលទ្ធផលល្អបំផុត - ការពន្យារពេលគឺទាបជាងពេលប្រើ CUBIC និង BBR 27% ។

ក្នុងពេលជាមួយគ្នានេះ នៅលើបណ្តាញទំនាក់ទំនងមិនល្អ COPA និង BBR បានធ្វើឱ្យវាអាចសម្រេចបាននូវលំហូរខ្ពស់ជាងគួរឱ្យកត់សម្គាល់បើប្រៀបធៀបទៅនឹង CUBIC ។ ការកើនឡើងនៃ BBR បើប្រៀបធៀបទៅនឹង CUBIC គឺ 4.8% និង 5.5% និង COPA - 6.2% និង 16.3% ។

ប្រភព: opennet.ru