ពិធីការ QUIC នៅក្នុងសកម្មភាព៖ របៀបដែល Uber អនុវត្តវា ដើម្បីបង្កើនប្រសិទ្ធភាពប្រតិបត្តិការ

ពិធីការ QUIC គឺគួរឱ្យចាប់អារម្មណ៍ខ្លាំងណាស់ក្នុងការមើល ដែលជាមូលហេតុដែលយើងចូលចិត្តសរសេរអំពីវា។ ប៉ុន្តែប្រសិនបើការបោះពុម្ពផ្សាយពីមុនអំពី QUIC មានលក្ខណៈជាប្រវត្តិសាស្ត្រ (ប្រវត្តិសាស្រ្តក្នុងតំបន់ ប្រសិនបើអ្នកចូលចិត្ត) ធម្មជាតិ និងផ្នែករឹង ថ្ងៃនេះយើងរីករាយក្នុងការបោះពុម្ពផ្សាយការបកប្រែប្រភេទផ្សេង យើងនឹងនិយាយអំពីការអនុវត្តជាក់ស្តែងនៃពិធីការនៅឆ្នាំ 2019។ ជាងនេះទៅទៀត យើងមិននិយាយអំពីហេដ្ឋារចនាសម្ព័ន្ធតូចដែលមានមូលដ្ឋាននៅក្នុងយានដ្ឋានមួយនោះទេ ប៉ុន្តែអំពី Uber ដែលប្រតិបត្តិការស្ទើរតែទូទាំងពិភពលោក។ របៀបដែលវិស្វកររបស់ក្រុមហ៊ុនបានមកដល់ការសម្រេចចិត្តប្រើប្រាស់ QUIC ក្នុងការផលិត របៀបដែលពួកគេបានធ្វើតេស្ត និងអ្វីដែលពួកគេបានឃើញបន្ទាប់ពីការដាក់ឱ្យដំណើរការនៅក្នុងការផលិត - ខាងក្រោមការកាត់។

រូបភាពអាចចុចបាន។ សូមរីករាយអាន!

Uber មានមាត្រដ្ឋានជាសកល ពោលគឺទីក្រុងចំនួន 600 នៃវត្តមាន ដែលក្នុងនោះកម្មវិធីនីមួយៗពឹងផ្អែកទាំងស្រុងលើអ៊ីនធឺណិតឥតខ្សែពីប្រតិបត្តិករទូរស័ព្ទជាង 4500 ។ អ្នកប្រើប្រាស់រំពឹងថាកម្មវិធីនេះមិនត្រឹមតែមានល្បឿនលឿនប៉ុណ្ណោះទេ ប៉ុន្តែនៅក្នុងពេលវេលាជាក់ស្តែង - ដើម្បីសម្រេចបាននូវចំណុចនេះ កម្មវិធី Uber ត្រូវការភាពយឺតយ៉ាវទាប និងការតភ្ជាប់ដែលអាចទុកចិត្តបាន។ Alas ប៉ុន្តែជង់ HTTP / 2 មិនដំណើរការល្អនៅក្នុងបណ្តាញឥតខ្សែថាមវន្ត និងងាយបាត់បង់។ យើងបានដឹងថាក្នុងករណីនេះ ដំណើរការទាបគឺទាក់ទងដោយផ្ទាល់ទៅនឹងការអនុវត្ត TCP នៅក្នុងខឺណែលប្រព័ន្ធប្រតិបត្តិការ។

ដើម្បីដោះស្រាយបញ្ហាយើងបានអនុវត្ត QUICដែលជាពិធីការពហុគុណឆានែលទំនើបដែលផ្តល់ឱ្យយើងនូវការគ្រប់គ្រងបន្ថែមទៀតលើដំណើរការនៃពិធីការដឹកជញ្ជូន។ បច្ចុប្បន្នក្រុមការងារ IETF ធ្វើស្តង់ដារ QUIC ជា HTTP / 3.

បន្ទាប់ពីការធ្វើតេស្តយ៉ាងទូលំទូលាយ យើងបានសន្និដ្ឋានថាការអនុវត្ត QUIC នៅក្នុងកម្មវិធីរបស់យើងនឹងនាំឱ្យមានភាពយឺតយ៉ាវនៅកន្ទុយទាបបើប្រៀបធៀបទៅនឹង TCP ។ យើងបានសង្កេតឃើញថាមានការថយចុះពី 10 ទៅ 30% សម្រាប់ចរាចរណ៍ HTTPS នៅក្នុងកម្មវិធីអ្នកបើកបរ និងអ្នកដំណើរ។ QUIC ក៏បានផ្តល់ឱ្យយើងនូវការគ្រប់គ្រងពីចុងដល់ចុងលើកញ្ចប់អ្នកប្រើប្រាស់ផងដែរ។

នៅក្នុងអត្ថបទនេះ យើងចែករំលែកបទពិសោធន៍របស់យើងក្នុងការបង្កើនប្រសិទ្ធភាព TCP សម្រាប់កម្មវិធី Uber ដោយប្រើជង់ដែលគាំទ្រ QUIC ។

បច្ចេកវិទ្យាចុងក្រោយ៖ TCP

សព្វថ្ងៃនេះ TCP គឺជាពិធីការដឹកជញ្ជូនដែលប្រើច្រើនបំផុតសម្រាប់ការបញ្ជូនចរាចរ HTTPS នៅលើអ៊ីនធឺណិត។ TCP ផ្តល់នូវការស្ទ្រីមបៃតៃដែលអាចទុកចិត្តបាន ដោយអាចទប់ទល់នឹងការកកស្ទះបណ្តាញ និងការបាត់បង់ស្រទាប់តំណ។ ការប្រើប្រាស់ TCP យ៉ាងទូលំទូលាយសម្រាប់ចរាចរណ៍ HTTPS គឺដោយសារតែភាពទូលំទូលាយរបស់អតីត (ស្ទើរតែគ្រប់ OS មាន TCP) ភាពអាចរកបាននៅលើហេដ្ឋារចនាសម្ព័ន្ធភាគច្រើន (ដូចជា load balancers, HTTPS proxies និង CDNs) និងមុខងារក្រៅប្រអប់ដែលអាចប្រើបាន។ នៅលើវេទិកា និងបណ្តាញស្ទើរតែទាំងអស់។

អ្នកប្រើប្រាស់ភាគច្រើនប្រើកម្មវិធីរបស់យើងនៅពេលធ្វើដំណើរ ហើយភាពយឺតយ៉ាវរបស់កន្ទុយ TCP គឺមិននៅជិតតម្រូវការនៃចរាចរណ៍ HTTPS ពេលវេលាពិតប្រាកដរបស់យើងទេ។ និយាយឱ្យសាមញ្ញ អ្នកប្រើប្រាស់ទូទាំងពិភពលោកបានជួបប្រទះបញ្ហានេះ - រូបភាពទី 1 បង្ហាញពីការពន្យារពេលនៅក្នុងទីក្រុងធំៗ៖

រូបភាពទី 1៖ ភាពយឺតយ៉ាវនៃកន្ទុយប្រែប្រួលនៅទូទាំងទីក្រុងសំខាន់ៗរបស់ Uber ។

ទោះបីជាភាពយឺតយ៉ាវនៅក្នុងបណ្តាញឥណ្ឌា និងប្រេស៊ីលគឺខ្ពស់ជាងនៅសហរដ្ឋអាមេរិក និងចក្រភពអង់គ្លេសក៏ដោយ ភាពយឺតយ៉ាវនៃកន្ទុយគឺខ្ពស់ជាងភាពយឺតយ៉ាវជាមធ្យម។ ហើយនេះជាការពិតសូម្បីតែសម្រាប់សហរដ្ឋអាមេរិក និងចក្រភពអង់គ្លេសក៏ដោយ។

TCP លើការអនុវត្តខ្យល់

TCP ត្រូវបានបង្កើតឡើងសម្រាប់ មានខ្សែ បណ្តាញ នោះគឺដោយសង្កត់ធ្ងន់លើតំណភ្ជាប់ដែលអាចព្យាករណ៍បានខ្ពស់។ ទោះយ៉ាងណាក៏ដោយ ឥតខ្សែ បណ្តាញមានលក្ខណៈ និងការលំបាកផ្ទាល់ខ្លួន។ ទីមួយ បណ្តាញឥតខ្សែគឺងាយនឹងបាត់បង់ដោយសារតែការជ្រៀតជ្រែក និងការបន្ថយសញ្ញា។ ឧទាហរណ៍ បណ្តាញ Wi-Fi មានភាពរសើបចំពោះមីក្រូវ៉េវ ប៊្លូធូស និងរលកវិទ្យុផ្សេងទៀត។ បណ្តាញកោសិកាទទួលរងពីការបាត់បង់សញ្ញា (ផ្លូវបាត់) ដោយសារតែការឆ្លុះបញ្ចាំង / ការស្រូបយកសញ្ញាដោយវត្ថុនិងអគារក៏ដូចជាពី ការជ្រៀតជ្រែក ពីអ្នកជិតខាង ប៉មកោសិកា. នេះនាំឱ្យមានសារៈសំខាន់កាន់តែច្រើន (4-10 ដង) និងមានភាពចម្រុះ ពេលវេលាធ្វើដំណើរទៅមក (RTT) និងការបាត់បង់កញ្ចប់ព័ត៌មានធៀបនឹងការភ្ជាប់ខ្សែ។

ដើម្បីទប់ទល់នឹងការប្រែប្រួល និងការបាត់បង់កម្រិតបញ្ជូន បណ្តាញកោសិកាជាធម្មតាប្រើបណ្តោះអាសន្នធំសម្រាប់ការផ្ទុះចរាចរណ៍។ នេះអាចនាំឱ្យមានការតម្រង់ជួរច្រើនពេក ដែលមានន័យថាការពន្យារពេលយូរជាងនេះ។ ជាញឹកញាប់ TCP ចាត់ទុកការតម្រង់ជួរនេះថាជាការខ្ជះខ្ជាយដោយសារការពន្យារពេលយូរ ដូច្នេះ TCP មានទំនោរក្នុងការបញ្ជូនបន្ត ហើយដោយហេតុនេះបំពេញសតិបណ្ដោះអាសន្ន។ បញ្ហានេះត្រូវបានគេស្គាល់ថាជា bufferbloat (បណ្តែតបណ្តាញហួសហេតុ, បណ្តែតបណ្តោយ) ហើយនេះគឺខ្លាំងណាស់ បញ្ហាធ្ងន់ធ្ងរ អ៊ីនធឺណិតទំនើប។

ជាចុងក្រោយ ដំណើរការបណ្តាញកោសិកាប្រែប្រួលតាមក្រុមហ៊ុនដឹកជញ្ជូន តំបន់ និងពេលវេលា។ នៅក្នុងរូបភាពទី 2 យើងបានប្រមូលការពន្យារពេលជាមធ្យមនៃចរាចរ HTTPS ឆ្លងកាត់ក្រឡាក្នុងចន្លោះ 2 គីឡូម៉ែត្រ។ ទិន្នន័យ​ដែល​ប្រមូល​បាន​សម្រាប់​ប្រតិបត្តិករ​ទូរស័ព្ទ​ធំ​ពីរ​នៅ​ក្រុង​ដេលី ប្រទេស​ឥណ្ឌា។ ដូចដែលអ្នកអាចមើលឃើញ ដំណើរការប្រែប្រួលពីក្រឡាមួយទៅក្រឡាមួយ។ ដូចគ្នានេះផងដែរផលិតភាពរបស់ប្រតិបត្តិករមួយខុសពីផលិតភាពទីពីរ។ នេះត្រូវបានជះឥទ្ធិពលដោយកត្តាមួយចំនួនដូចជា លំនាំនៃការបញ្ចូលបណ្តាញ ដោយគិតទៅលើពេលវេលា និងទីតាំង ការចល័តរបស់អ្នកប្រើប្រាស់ ក៏ដូចជាហេដ្ឋារចនាសម្ព័ន្ធបណ្តាញ ដោយគិតគូរពីដង់ស៊ីតេប៉ម និងសមាមាត្រនៃប្រភេទបណ្តាញ (LTE, 3G ។ល។)។

រូបភាពទី 2. ការពន្យារពេលដោយប្រើកាំ 2 គីឡូម៉ែត្រជាឧទាហរណ៍។ ដេលី ប្រទេសឥណ្ឌា។

ដូចគ្នានេះផងដែរ, ដំណើរការនៃបណ្តាញកោសិកាប្រែប្រួលតាមពេលវេលា។ រូបភាពទី 3 បង្ហាញពីភាពយឺតយ៉ាវជាមធ្យមតាមថ្ងៃនៃសប្តាហ៍។ យើងក៏បានសង្កេតឃើញភាពខុសប្លែកគ្នានៅលើមាត្រដ្ឋានតូចជាង ក្នុងរយៈពេលមួយថ្ងៃ និងមួយម៉ោង។

រូបភាពទី 3. ការពន្យាពេលកន្ទុយអាចប្រែប្រួលយ៉ាងខ្លាំងរវាងថ្ងៃ ប៉ុន្តែសម្រាប់ប្រតិបត្តិករដូចគ្នា។

ទាំងអស់ខាងលើបណ្តាលឱ្យដំណើរការ TCP មិនមានប្រសិទ្ធភាពនៅក្នុងបណ្តាញឥតខ្សែ។ ទោះយ៉ាងណាក៏ដោយ មុននឹងស្វែងរកជម្រើសជំនួស TCP យើងចង់បង្កើតការយល់ដឹងច្បាស់លាស់មួយលើចំណុចខាងក្រោម៖

• តើ TCP គឺជាពិរុទ្ធជនចម្បងនៅពីក្រោយភាពយឺតយ៉ាវនៅក្នុងកម្មវិធីរបស់យើងមែនទេ?
• តើបណ្តាញទំនើបមានការពន្យាពេលធ្វើដំណើរទៅមក (RTT) សំខាន់ៗ និងខុសគ្នាដែរឬទេ?
• តើអ្វីទៅជាផលប៉ះពាល់នៃ RTT និងការបាត់បង់លើការអនុវត្ត TCP?

ការវិភាគការអនុវត្ត TCP

ដើម្បីយល់ពីរបៀបដែលយើងបានវិភាគការអនុវត្ត TCP សូមមើលពីរបៀបដែល TCP ផ្ទេរទិន្នន័យពីអ្នកផ្ញើទៅអ្នកទទួល។ ដំបូងអ្នកផ្ញើបង្កើតការតភ្ជាប់ TCP ដោយអនុវត្តបីផ្លូវ ការចាប់ដៃ៖ អ្នកផ្ញើផ្ញើកញ្ចប់ SYN រង់ចាំកញ្ចប់ SYN-ACK ពីអ្នកទទួល បន្ទាប់មកផ្ញើកញ្ចប់ ACK ។ ការឆ្លងទីពីរ និងទីបីបន្ថែមត្រូវបានចំណាយដើម្បីបង្កើតការតភ្ជាប់ TCP ។ អ្នកទទួលទទួលស្គាល់ការទទួលកញ្ចប់នីមួយៗ (ACK) ដើម្បីធានាបាននូវការចែកចាយដែលអាចទុកចិត្តបាន។

ប្រសិនបើកញ្ចប់ព័ត៌មាន ឬ ACK ត្រូវបានបាត់បង់ អ្នកផ្ញើបញ្ជូនសារឡើងវិញបន្ទាប់ពីអស់ពេល (RTO, អស់ពេលនៃការបញ្ជូនឡើងវិញ) RTO ត្រូវបានគណនាថាមវន្តដោយផ្អែកលើកត្តាផ្សេងៗ ដូចជាការពន្យារពេល RTT ដែលរំពឹងទុករវាងអ្នកផ្ញើ និងអ្នកទទួល។

រូបភាពទី 4. ការផ្លាស់ប្តូរកញ្ចប់ព័ត៌មានលើ TCP/TLS រួមមានយន្តការបញ្ជូនបន្ត។

ដើម្បីកំណត់ពីរបៀបដែល TCP ដំណើរការនៅក្នុងកម្មវិធីរបស់យើង យើងបានត្រួតពិនិត្យកញ្ចប់ TCP ដោយប្រើ tcpdump សម្រាប់មួយសប្តាហ៍នៅលើចរាចរណ៍ប្រយុទ្ធដែលមកពីម៉ាស៊ីនមេគែមឥណ្ឌា។ បន្ទាប់មកយើងវិភាគការតភ្ជាប់ TCP ដោយប្រើ tcptrace. លើសពីនេះ យើងបានបង្កើតកម្មវិធី Android ដែលផ្ញើចរាចរណ៍ត្រាប់តាមទៅកាន់ម៉ាស៊ីនមេសាកល្បង ដោយត្រាប់តាមចរាចរណ៍ពិតប្រាកដតាមដែលអាចធ្វើទៅបាន។ ស្មាតហ្វូនដែលមានកម្មវិធីនេះត្រូវបានចែកចាយដល់បុគ្គលិកជាច្រើននាក់ ដែលបានប្រមូលកំណត់ហេតុក្នុងរយៈពេលជាច្រើនថ្ងៃ។

លទ្ធផលនៃការពិសោធន៍ទាំងពីរគឺស្របគ្នាទៅវិញទៅមក។ យើងបានឃើញ latencies RTT ខ្ពស់; តម្លៃកន្ទុយគឺស្ទើរតែ 6 ដងខ្ពស់ជាងតម្លៃមធ្យម; មធ្យមនព្វន្ធនៃការពន្យារពេលគឺច្រើនជាង 1 វិនាទី។ ការតភ្ជាប់ជាច្រើនបានបាត់បង់ ដែលបណ្តាលឱ្យ TCP បញ្ជូនឡើងវិញ 3,5% នៃកញ្ចប់ព័ត៌មានទាំងអស់។ នៅតំបន់ដែលមានការកកស្ទះដូចជាព្រលានយន្តហោះ និងស្ថានីយ៍រថភ្លើង យើងឃើញថាមានការខាតបង់ 7% ។ លទ្ធផលទាំងនេះធ្វើឱ្យមានការងឿងឆ្ងល់ចំពោះប្រាជ្ញាសាមញ្ញដែលប្រើក្នុងបណ្តាញកោសិកា សៀគ្វីបញ្ជូនបន្តកម្រិតខ្ពស់ កាត់បន្ថយការខាតបង់យ៉ាងខ្លាំងនៅកម្រិតដឹកជញ្ជូន។ ខាងក្រោមនេះជាលទ្ធផលតេស្តពីកម្មវិធី “ក្លែងធ្វើ”៖

រង្វាស់បណ្តាញ
តម្លៃ

RTT, មីលីវិនាទី [50%, 75%, 95%, 99%]
[១, ២, ៤, ៥]

ភាពខុសគ្នា RTT, វិនាទី
ជាមធ្យម ~ 1,2 វិ

ការបាត់បង់កញ្ចប់ព័ត៌មាននៅលើការតភ្ជាប់មិនស្ថិតស្ថេរ
ជាមធ្យម ~ 3.5% (7% នៅក្នុងតំបន់ផ្ទុកលើសទម្ងន់)

ស្ទើរតែពាក់កណ្តាលនៃការតភ្ជាប់ទាំងនេះមានការខាតបង់យ៉ាងហោចមួយកញ្ចប់ ដែលភាគច្រើនជាកញ្ចប់ SYN និង SYN-ACK ។ ការអនុវត្ត TCP ភាគច្រើនប្រើតម្លៃ RTO 1 វិនាទីសម្រាប់កញ្ចប់ SYN ដែលកើនឡើងជានិទស្សន្តសម្រាប់ការខាតបង់ជាបន្តបន្ទាប់។ រយៈពេលនៃការផ្ទុកកម្មវិធីអាចកើនឡើងដោយសារតែ TCP ចំណាយពេលយូរដើម្បីបង្កើតការតភ្ជាប់។

នៅក្នុងករណីនៃកញ្ចប់ទិន្នន័យ តម្លៃ RTO ខ្ពស់កាត់បន្ថយការប្រើប្រាស់បណ្តាញដ៏មានសារៈប្រយោជន៍នៅក្នុងវត្តមាននៃការខាតបង់បណ្តោះអាសន្ននៅក្នុងបណ្តាញឥតខ្សែ។ យើងបានរកឃើញថាពេលវេលាបញ្ជូនឡើងវិញជាមធ្យមគឺប្រហែល 1 វិនាទីជាមួយនឹងការពន្យាពេលកន្ទុយជិត 30 វិនាទី។ ភាពយឺតយ៉ាវខ្ពស់ទាំងនេះនៅកម្រិត TCP បណ្តាលឱ្យអស់ពេល HTTPS និងការស្នើសុំឡើងវិញ ដែលបង្កើនភាពយឺតយ៉ាវបណ្តាញ និងអប្រសិទ្ធភាព។

ខណៈពេលដែលភាគរយទី 75 នៃការវាស់វែង RTT គឺនៅជុំវិញ 425 ms, ភាគរយទី 75 សម្រាប់ TCP គឺជិត 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 (តាមពិត HTTP/2 នៅលើកំពូលនៃ QUIC គឺ HTTP/3 ដែលឥឡូវនេះកំពុងត្រូវបានធ្វើស្តង់ដារយ៉ាងខ្លាំង)។ វាជំនួសស្រទាប់ HTTPS និង TCP ដោយផ្នែកដោយប្រើ UDP ដើម្បីបង្កើតកញ្ចប់ព័ត៌មាន។ QUIC គាំទ្រតែការផ្ទេរទិន្នន័យដែលមានសុវត្ថិភាព ព្រោះ TLS ត្រូវបានបង្កើតឡើងយ៉ាងពេញលេញនៅក្នុង QUIC ។

រូបភាពទី 5៖ QUIC ដំណើរការនៅក្រោម HTTP/3 ដោយជំនួស TLS ដែលពីមុនដំណើរការនៅក្រោម HTTP/2។

ខាងក្រោមនេះគឺជាហេតុផលដែលបញ្ចុះបញ្ចូលយើងឱ្យប្រើ QUIC សម្រាប់ការពង្រីក TCP៖

• ការបង្កើតការតភ្ជាប់ 0-RTT ។ QUIC អនុញ្ញាតឱ្យប្រើឡើងវិញនូវការអនុញ្ញាតពីការតភ្ជាប់ពីមុន ដោយកាត់បន្ថយចំនួននៃការចាប់ដៃសុវត្ថិភាព។ នៅ​ពេល​អនាគត TLS1.3 ។ នឹងគាំទ្រ 0-RTT ប៉ុន្តែការចាប់ដៃ TCP បីផ្លូវនឹងនៅតែត្រូវបានទាមទារ។
• ការយកឈ្នះលើការទប់ស្កាត់ HoL ។ HTTP/2 ប្រើការភ្ជាប់ TCP មួយក្នុងម៉ាស៊ីនភ្ញៀវ ដើម្បីកែលម្អដំណើរការ ប៉ុន្តែវាអាចនាំឱ្យមានការទប់ស្កាត់ HoL (head-of-line) ។ QUIC សម្រួលការពហុគុណ និងបញ្ជូនសំណើទៅកម្មវិធីដោយឯករាជ្យ។
• ការគ្រប់គ្រងការកកស្ទះ។ QUIC រស់នៅក្នុងស្រទាប់កម្មវិធី ដែលធ្វើឱ្យវាកាន់តែងាយស្រួលក្នុងការធ្វើបច្ចុប្បន្នភាពក្បួនដោះស្រាយដឹកជញ្ជូនចម្បងដែលគ្រប់គ្រងការបញ្ជូនដោយផ្អែកលើប៉ារ៉ាម៉ែត្របណ្តាញ (ចំនួននៃការខាតបង់ ឬ RTT) ។ ការអនុវត្ត TCP ភាគច្រើនប្រើក្បួនដោះស្រាយ គុយបាដែល​មិន​ល្អ​សម្រាប់​ចរាចរណ៍​ដែល​មាន​ភាព​យឺតយ៉ាវ។ ក្បួនដោះស្រាយដែលបានបង្កើតថ្មីៗនេះដូចជា BBRធ្វើឱ្យគំរូបណ្តាញកាន់តែត្រឹមត្រូវ និងបង្កើនប្រសិទ្ធភាពភាពយឺតយ៉ាវ។ QUIC អនុញ្ញាតឱ្យអ្នកប្រើ BBR និងធ្វើបច្ចុប្បន្នភាព algorithm នេះ ដូចដែលវាត្រូវបានប្រើ។ ការកែលម្អ.
• ការបំពេញបន្ថែមនៃការបាត់បង់។ QUIC ហៅ TLPs ពីរ (ការស៊ើបអង្កេតការបាត់បង់កន្ទុយ) មុនពេល RTO ត្រូវបានកេះ - ទោះបីជាការខាតបង់គួរឱ្យកត់សម្គាល់ក៏ដោយ។ នេះខុសពីការអនុវត្ត TCP ។ TLP បញ្ជូនឡើងវិញជាចម្បងនូវកញ្ចប់ព័ត៌មានចុងក្រោយ (ឬកញ្ចប់ថ្មី ប្រសិនបើមានមួយ) ដើម្បីជំរុញការបំពេញបន្ថែមយ៉ាងឆាប់រហ័ស។ ការដោះស្រាយការពន្យារពេលកន្ទុយគឺមានប្រយោជន៍ជាពិសេសសម្រាប់វិធីដែល Uber ដំណើរការបណ្តាញរបស់ខ្លួន ពោលគឺសម្រាប់ការផ្ទេរទិន្នន័យខ្លីៗ ចន្លោះពេល និងយឺតៗ។
• ធ្វើឱ្យប្រសើរឡើង ACK ។ ដោយសារ​កញ្ចប់​នីមួយៗ​មាន​លេខ​លំដាប់​តែ​មួយ មិន​មាន​បញ្ហា​ទេ។ ភាពខុសគ្នា កញ្ចប់នៅពេលដែលពួកគេត្រូវបានបញ្ជូនឡើងវិញ។ កញ្ចប់ ACK ក៏មានពេលវេលាដើម្បីដំណើរការកញ្ចប់ព័ត៌មាន និងបង្កើត ACK នៅខាងអតិថិជនផងដែរ។ លក្ខណៈពិសេសទាំងនេះធានាថា QUIC គណនា RTT កាន់តែត្រឹមត្រូវ។ ACK ក្នុង QUIC គាំទ្រដល់ទៅ 256 ក្រុមតន្រ្តី NACKជួយអ្នកផ្ញើឱ្យមានភាពធន់នឹងការសាប់កញ្ចប់ព័ត៌មាន និងប្រើប្រាស់បៃតិចជាងមុនក្នុងដំណើរការ។ ACK ជ្រើសរើស (បាវ) នៅក្នុង TCP មិនដោះស្រាយបញ្ហានេះក្នុងគ្រប់ករណីទាំងអស់។
• ការផ្លាស់ប្តូរការតភ្ជាប់។ ការតភ្ជាប់ QUIC ត្រូវបានកំណត់អត្តសញ្ញាណដោយលេខសម្គាល់ 64 ប៊ីត ដូច្នេះប្រសិនបើអតិថិជនផ្លាស់ប្តូរអាសយដ្ឋាន IP លេខសម្គាល់ការតភ្ជាប់ចាស់អាចបន្តប្រើនៅលើអាសយដ្ឋាន IP ថ្មីដោយមិនមានការរំខាន។ នេះ​ជា​ទម្លាប់​ធម្មតា​សម្រាប់​កម្មវិធី​ទូរសព្ទ​ដែល​អ្នក​ប្រើ​ប្ដូរ​រវាង Wi-Fi និង​ការ​តភ្ជាប់​ទូរសព្ទ។

ជម្មើសជំនួសទៅ QUIC

យើងបានពិចារណាវិធីសាស្រ្តជំនួសក្នុងការដោះស្រាយបញ្ហាមុននឹងជ្រើសរើស QUIC ។

រឿងដំបូងដែលយើងព្យាយាមគឺត្រូវដាក់ពង្រាយ TPC PoPs (Points of Presence) ដើម្បីបញ្ចប់ការតភ្ជាប់ TCP កាន់តែជិតអ្នកប្រើប្រាស់។ ជាសំខាន់ PoPs បញ្ចប់ការភ្ជាប់ TCP ជាមួយឧបករណ៍ចល័តដែលខិតទៅជិតបណ្តាញកោសិកា ហើយប្រូកស៊ីចរាចរត្រឡប់ទៅហេដ្ឋារចនាសម្ព័ន្ធដើមវិញ។ តាមរយៈការបញ្ចប់ TCP កាន់តែខិតជិត យើងអាចកាត់បន្ថយ RTT និងធានាថា TCP កាន់តែឆ្លើយតបទៅនឹងបរិស្ថានឥតខ្សែដែលមានថាមពល។ ទោះជាយ៉ាងណាក៏ដោយ ការពិសោធន៍របស់យើងបានបង្ហាញថាភាគច្រើននៃ RTT និងការបាត់បង់គឺមកពីបណ្តាញកោសិកា ហើយការប្រើប្រាស់ PoPs មិនផ្តល់នូវការកែលម្អដំណើរការគួរឱ្យកត់សម្គាល់នោះទេ។

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

ជាចុងក្រោយ យើងបានវាយតម្លៃពិធីការដែលមានមូលដ្ឋានលើ UDP ជាច្រើនដែលដោះស្រាយបញ្ហាការផ្សាយវីដេអូ - យើងចង់មើលថាតើពិធីការទាំងនេះនឹងជួយក្នុងករណីរបស់យើងដែរឬទេ។ ជាអកុសល ពួកគេខ្វះខាតយ៉ាងខ្លាំងក្នុងការកំណត់សុវត្ថិភាពជាច្រើន ហើយក៏ទាមទារការតភ្ជាប់ TCP បន្ថែមសម្រាប់ទិន្នន័យមេតា និងព័ត៌មានគ្រប់គ្រងផងដែរ។

ការស្រាវជ្រាវរបស់យើងបានបង្ហាញថា QUIC ប្រហែលជាពិធីការតែមួយគត់ដែលអាចជួយដោះស្រាយបញ្ហានៃចរាចរណ៍អ៊ីនធឺណិត ខណៈពេលដែលគិតគូរទាំងសុវត្ថិភាព និងដំណើរការ។

ការរួមបញ្ចូល QUIC ទៅក្នុងវេទិកា

ដើម្បីបង្កប់ QUIC ដោយជោគជ័យ និងកែលម្អការអនុវត្តកម្មវិធីនៅក្នុងបរិយាកាសតភ្ជាប់ខ្សោយ យើងបានជំនួសជង់ចាស់ (HTTP/2 លើ TLS/TCP) ជាមួយនឹងពិធីការ QUIC ។ យើងបានប្រើបណ្ណាល័យបណ្តាញ ក្រូណេត ពី គម្រោង Chromiumដែលផ្ទុកនូវកំណែដើមរបស់ Google នៃពិធីការ - gQUIC ។ ការអនុវត្តនេះក៏កំពុងត្រូវបានកែលម្អឥតឈប់ឈរ ដើម្បីអនុវត្តតាមការបញ្ជាក់ចុងក្រោយរបស់ IETF ។

យើងបានដាក់បញ្ចូល Cronet ទៅក្នុងកម្មវិធី Android របស់យើងជាលើកដំបូង ដើម្បីបន្ថែមការគាំទ្រសម្រាប់ QUIC ។ ការធ្វើសមាហរណកម្មត្រូវបានអនុវត្តតាមវិធីមួយដើម្បីកាត់បន្ថយការចំណាយលើការធ្វើចំណាកស្រុកឱ្យបានច្រើនតាមដែលអាចធ្វើទៅបាន។ ជំនួសឱ្យការជំនួសទាំងស្រុងនូវបណ្តាញបណ្តាញចាស់ដែលបានប្រើបណ្ណាល័យ OkHttpយើងបានរួមបញ្ចូល Cronet ក្រោមក្របខ័ណ្ឌ OkHttp API ។ តាមរយៈការធ្វើសមាហរណកម្មតាមវិធីនេះ យើងជៀសវាងការផ្លាស់ប្តូរចំពោះការហៅតាមបណ្តាញរបស់យើង (ដែលត្រូវបានប្រើដោយ ដំឡើងឡើងវិញ) នៅកម្រិត API ។

ស្រដៀងគ្នាទៅនឹងវិធីសាស្រ្តសម្រាប់ឧបករណ៍ Android យើងបានអនុវត្ត Cronet ទៅក្នុងកម្មវិធី Uber នៅលើ iOS ដោយស្ទាក់ចាប់ចរាចរ HTTP ពីបណ្តាញ ការ APIដោយប្រើ ពិធីការ NSURL. អរូបីនេះ ផ្តល់ដោយ iOS Foundation គ្រប់គ្រងទិន្នន័យ URL ជាក់លាក់នៃពិធីការ និងធានាថាយើងអាចបញ្ចូល Cronet ទៅក្នុងកម្មវិធី iOS របស់យើងដោយមិនមានការចំណាយលើការផ្ទេរទិន្នន័យដ៏សំខាន់។

កំពុងបំពេញ QUIC នៅលើ Google Cloud Balancers

នៅផ្នែកខាងក្រោយ ការបញ្ចប់ QUIC ត្រូវបានផ្តល់ដោយហេដ្ឋារចនាសម្ព័ន្ធសមតុល្យ Google Cloud Load ដែលប្រើ alt-svc បឋមកថានៅក្នុងការឆ្លើយតបដើម្បីគាំទ្រ QUIC ។ ជាទូទៅ តុល្យការបន្ថែមបឋមកថា alt-svc ទៅនឹងសំណើ HTTP នីមួយៗ ហើយនេះផ្តល់សុពលភាពដល់ការគាំទ្រ QUIC សម្រាប់ដែនរួចហើយ។ នៅពេលដែលអតិថិជន Cronet ទទួលបានការឆ្លើយតប HTTP ជាមួយបឋមកថានេះ វាប្រើ QUIC សម្រាប់សំណើ HTTP ជាបន្តបន្ទាប់ទៅកាន់ដែននោះ។ នៅពេលដែលសមតុល្យបំពេញ QUIC ហេដ្ឋារចនាសម្ព័ន្ធរបស់យើងបញ្ជូនសកម្មភាពនេះយ៉ាងច្បាស់លាស់តាម HTTP2/TCP ទៅកាន់មជ្ឈមណ្ឌលទិន្នន័យរបស់យើង។

ការអនុវត្ត៖ លទ្ធផល

ការអនុវត្តលទ្ធផលគឺជាហេតុផលចម្បងសម្រាប់ការស្វែងរករបស់យើងសម្រាប់ពិធីការប្រសើរជាងមុន។ ដើម្បីចាប់ផ្តើមជាមួយយើងបានបង្កើតជំហរជាមួយ ការត្រាប់តាមបណ្តាញដើម្បីស្វែងយល់ពីរបៀបដែល QUIC នឹងមានឥរិយាបទនៅក្រោមទម្រង់បណ្តាញផ្សេងៗគ្នា។ ដើម្បីសាកល្បងដំណើរការរបស់ QUIC នៅលើបណ្តាញពិភពពិត យើងបានដំណើរការការពិសោធន៍ខណៈពេលកំពុងបើកបរជុំវិញទីក្រុង New Delhi ដោយប្រើចរាចរណ៍បណ្តាញដែលបានធ្វើត្រាប់តាមស្រដៀងទៅនឹងការហៅ HTTP នៅក្នុងកម្មវិធីអ្នកដំណើរ។

ពិសោធន៍ ១

ឧបករណ៍សម្រាប់ការពិសោធន៍៖

• សាកល្បងឧបករណ៍ Android ជាមួយ OkHttp និង Cronet stacks ដើម្បីធានាថាយើងអនុញ្ញាតឱ្យចរាចរ HTTPS លើ TCP និង QUIC រៀងៗខ្លួន។
• ម៉ាស៊ីនមេត្រាប់តាមដែលមានមូលដ្ឋានលើ Java ដែលផ្ញើប្រភេទដូចគ្នានៃបឋមកថា HTTPS ក្នុងការឆ្លើយតប និងផ្ទុកឧបករណ៍អតិថិជន ដើម្បីទទួលបានសំណើពីពួកគេ។
• ប្រូកស៊ីពពកដែលមានទីតាំងនៅជិតប្រទេសឥណ្ឌាដើម្បីបញ្ចប់ការតភ្ជាប់ TCP និង QUIC ។ ខណៈពេលដែលសម្រាប់ការបញ្ចប់ TCP យើងបានប្រើប្រូកស៊ីបញ្ច្រាស NGINXវាពិបាកក្នុងការស្វែងរកប្រូកស៊ីបញ្ច្រាសប្រភពបើកចំហសម្រាប់ QUIC ។ យើងបានបង្កើតប្រូកស៊ីបញ្ច្រាសសម្រាប់ QUIC ខ្លួនយើងដោយប្រើជង់ QUIC មូលដ្ឋានពី Chromium និង បោះពុម្ភ វាចូលទៅក្នុង chromium ជាប្រភពបើកចំហ។

រូបភាពទី 6. ឈុតសាកល្បងផ្លូវ TCP vs QUIC មានឧបករណ៍ Android ដែលមាន OkHttp និង Cronet ប្រូកស៊ីពពកសម្រាប់ការបញ្ចប់ការតភ្ជាប់ និងម៉ាស៊ីនមេត្រាប់តាម។

ពិសោធន៍ ១

នៅពេលដែល Google ធ្វើឱ្យ QUIC មានជាមួយ Google Cloud Load Balancingយើងបានប្រើសារពើភ័ណ្ឌដូចគ្នា ប៉ុន្តែជាមួយនឹងការកែប្រែមួយ៖ ជំនួសឱ្យ NGINX យើងបានយក Google load balancers ដើម្បីបញ្ចប់ការតភ្ជាប់ TCP និង QUIC ពីឧបករណ៍ ក៏ដូចជាដើម្បីបញ្ជូនចរាចរ HTTPS ទៅកាន់ម៉ាស៊ីនមេត្រាប់តាម។ តុល្យភាពត្រូវបានចែកចាយទូទាំងពិភពលោក ប៉ុន្តែប្រើម៉ាស៊ីនមេ PoP ដែលនៅជិតឧបករណ៍បំផុត (អរគុណចំពោះទីតាំងភូមិសាស្ត្រ)។

រូបភាពទី 7. នៅក្នុងការពិសោធន៍ទីពីរ យើងចង់ប្រៀបធៀបភាពយឺតយ៉ាវនៃការបញ្ចប់នៃ TCP និង QUIC៖ ដោយប្រើ Google Cloud និងការប្រើប្រាស់ cloud proxy របស់យើង។

ជាលទ្ធផល វិវរណៈជាច្រើនបានរង់ចាំយើង៖

• ការបញ្ចប់តាមរយៈ PoP ធ្វើអោយប្រសើរឡើងនូវដំណើរការ TCP ។ ចាប់តាំងពីសមតុល្យបញ្ចប់ការភ្ជាប់ TCP កាន់តែខិតទៅជិតអ្នកប្រើប្រាស់ និងត្រូវបានធ្វើឱ្យប្រសើរខ្ពស់ លទ្ធផលនេះនៅក្នុង RTTs ទាប ដែលធ្វើអោយដំណើរការ TCP ប្រសើរឡើង។ ហើយទោះបីជា QUIC មិនសូវរងផលប៉ះពាល់ក៏ដោយ ក៏វានៅតែដំណើរការបានល្អជាង TCP ទាក់ទងនឹងការកាត់បន្ថយភាពយឺតនៃកន្ទុយ (10-30 ភាគរយ)។
• កន្ទុយត្រូវបានប៉ះពាល់ បណ្តាញ hops. ទោះបីជាប្រូកស៊ី QUIC របស់យើងនៅឆ្ងាយពីឧបករណ៍ (ប្រហែល 50 ms ភាពយឺតយ៉ាវខ្ពស់ជាង) ជាងឧបករណ៍ផ្ទុករបស់ Google ប៉ុន្តែវាផ្តល់នូវដំណើរការស្រដៀងគ្នា - ការកាត់បន្ថយ 15% នៃភាពយឺតយ៉ាវធៀបនឹងការកាត់បន្ថយ 20% នៅក្នុងភាគរយទី 99 សម្រាប់ TCP ។ នេះបង្ហាញថាការផ្លាស់ប្តូរម៉ាយល៍ចុងក្រោយគឺជាការស្ទះនៅក្នុងបណ្តាញ។

រូបភាពទី 8៖ លទ្ធផលពីការពិសោធន៍ពីរបង្ហាញថា QUIC មានប្រសិទ្ធភាពជាង TCP យ៉ាងខ្លាំង។

ចរាចរណ៍ប្រយុទ្ធ

ដោយមានការបំផុសគំនិតដោយការពិសោធន៍ យើងបានអនុវត្តការគាំទ្រ QUIC នៅក្នុងកម្មវិធី Android និង iOS របស់យើង។ យើងបានធ្វើការធ្វើតេស្ត A/B ដើម្បីកំណត់ពីផលប៉ះពាល់នៃ QUIC នៅក្នុងទីក្រុងដែល Uber ប្រតិបត្តិការ។ ជាទូទៅ យើងបានឃើញការថយចុះគួរឱ្យកត់សម្គាល់នៃការពន្យាពេលនៅទូទាំងតំបន់ ប្រតិបត្តិករទូរគមនាគមន៍ និងប្រភេទបណ្តាញ។

ក្រាហ្វខាងក្រោមបង្ហាញពីការកែលម្អភាគរយនៅក្នុងកន្ទុយ (95 និង 99 ភាគរយ) តាមតំបន់ម៉ាក្រូ និងប្រភេទបណ្តាញផ្សេងៗគ្នា - LTE, 3G, 2G ។

រូបភាពទី 9. នៅក្នុងការធ្វើតេស្តប្រយុទ្ធ QUIC បានដំណើរការជាង TCP ទាក់ទងនឹងភាពយឺតយ៉ាវ។

ទៅមុខតែប៉ុណ្ណោះ

ប្រហែលជានេះគ្រាន់តែជាការចាប់ផ្តើមប៉ុណ្ណោះ - ការចេញផ្សាយ QUIC ទៅក្នុងផលិតកម្មបានផ្តល់នូវឱកាសដ៏អស្ចារ្យក្នុងការធ្វើឱ្យប្រសើរឡើងនូវការអនុវត្តកម្មវិធីនៅក្នុងបណ្តាញដែលមានស្ថេរភាព និងមិនមានស្ថេរភាព ពោលគឺ៖

បង្កើនការគ្របដណ្តប់

ដោយបានវិភាគដំណើរការនៃពិធីការលើចរាចរណ៍ពិតប្រាកដ យើងឃើញថាប្រហែល 80% នៃវគ្គប្រើប្រាស់ដោយជោគជ័យ QUIC សម្រាប់ всех សំណើ ខណៈពេលដែល 15% នៃវគ្គបានប្រើការរួមបញ្ចូលគ្នានៃ QUIC និង TCP ។ យើងសន្មត់ថាការរួមបញ្ចូលគ្នានេះគឺដោយសារតែបណ្ណាល័យ Cronet អស់ពេលត្រឡប់ទៅ TCP ព្រោះវាមិនអាចបែងចែករវាងការបរាជ័យ UDP ពិតប្រាកដ និងលក្ខខណ្ឌបណ្តាញខ្សោយ។ បច្ចុប្បន្នយើងកំពុងស្វែងរកដំណោះស្រាយចំពោះបញ្ហានេះ នៅពេលដែលយើងធ្វើការឆ្ពោះទៅរកការអនុវត្តជាបន្តបន្ទាប់នៃ QUIC ។

ការបង្កើនប្រសិទ្ធភាព QUIC

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

ជាមួយនឹងការកែលម្អទាំងនេះ និងការកែលម្អមួយចំនួនទៀត យើងមានគម្រោងកែលម្អបទពិសោធន៍អ្នកប្រើប្រាស់ដោយមិនគិតពីបណ្តាញ និងតំបន់ ដែលធ្វើឱ្យការដឹកជញ្ជូនកញ្ចប់ព័ត៌មានកាន់តែងាយស្រួល និងគ្មានថ្នេរអាចចូលដំណើរការបាននៅជុំវិញពិភពលោក។

ប្រភព: www.habr.com