HTTP/3៖ បំបែកដី និងពិភពលោកថ្មីដ៏ក្លាហាន

អស់រយៈពេលជាង 20 ឆ្នាំមកហើយដែលយើងបានមើលគេហទំព័រដោយប្រើពិធីការ HTTP ។ អ្នក​ប្រើ​ភាគ​ច្រើន​មិន​បាន​គិត​អំពី​អ្វី​ដែល​វា​ជា​និង​របៀប​ដែល​វា​ធ្វើ​ការ។ អ្នកផ្សេងទៀតដឹងថាកន្លែងណាមួយនៅក្រោម HTTP មាន TLS ហើយនៅក្រោមនោះគឺ TCP ក្រោមនោះជា IP ជាដើម។ ហើយនៅតែមានអ្នកផ្សេងទៀត - អ្នកខុសឆ្គង - ជឿថា TCP គឺជារឿងអតីតកាលដែលពួកគេចង់បានអ្វីដែលលឿនជាងមុន គួរឱ្យទុកចិត្ត និងមានសុវត្ថិភាព។ ប៉ុន្តែនៅក្នុងការប៉ុនប៉ងរបស់ពួកគេក្នុងការបង្កើតពិធីការដ៏ល្អថ្មីមួយ ពួកគេបានត្រលប់ទៅបច្ចេកវិទ្យានៃទសវត្សរ៍ទី 80 ហើយកំពុងព្យាយាមបង្កើតពិភពលោកថ្មីដ៏ក្លាហានរបស់ពួកគេនៅលើវា។

ប្រវត្តិតិចតួច៖ HTTP/1.1

នៅឆ្នាំ 1997 ពិធីសារផ្លាស់ប្តូរព័ត៌មានអត្ថបទ HTTP កំណែ 1.1 បានទទួល RFC របស់ខ្លួន។ នៅពេលនោះ ពិធីការត្រូវបានប្រើប្រាស់ដោយកម្មវិធីរុករកជាច្រើនឆ្នាំ ហើយស្តង់ដារថ្មីមានរយៈពេលដប់ប្រាំមួយផ្សេងទៀត។ ពិធីការនេះដំណើរការតែលើគោលការណ៍ឆ្លើយតបសំណើ និងត្រូវបានបម្រុងទុកជាចម្បងសម្រាប់ការបញ្ជូនព័ត៌មានអត្ថបទ។

HTTP ត្រូវ​បាន​រចនា​ឡើង​ដើម្បី​ដំណើរការ​នៅ​លើ​កំពូល​នៃ​ពិធីការ TCP ដោយ​ធានា​ថា​កញ្ចប់​ព័ត៌មាន​ត្រូវ​បាន​បញ្ជូន​ទៅ​កាន់​គោលដៅ​របស់​ពួកគេ​ដោយ​ភាព​ជឿជាក់។ TCP ដំណើរការដោយបង្កើត និងរក្សាការតភ្ជាប់ដែលអាចទុកចិត្តបានរវាងចំណុចបញ្ចប់ និងបំបែកចរាចរណ៍ទៅជាផ្នែក។ ផ្នែកមានលេខស៊េរី និងមូលប្បទានប័ត្រផ្ទាល់ខ្លួន។ ប្រសិនបើភ្លាមៗនោះផ្នែកណាមួយមិនមកដល់ ឬមកដល់ជាមួយនឹងការត្រួតពិនិត្យមិនត្រឹមត្រូវ នោះការបញ្ជូននឹងឈប់រហូតដល់ផ្នែកដែលបាត់បង់ត្រូវបានស្ដារឡើងវិញ។

នៅក្នុង HTTP/1.0 ការតភ្ជាប់ TCP ត្រូវបានបិទបន្ទាប់ពីការស្នើសុំនីមួយៗ។ នេះគឺជាការខ្ជះខ្ជាយខ្លាំងណាស់ព្រោះ ... ការបង្កើតការតភ្ជាប់ TCP (3-Way-Handshake) គឺជាដំណើរការយឺត។ HTTP/1.1 បានណែនាំយន្តការរក្សាជីវិត ដែលអនុញ្ញាតឱ្យអ្នកប្រើការតភ្ជាប់មួយឡើងវិញសម្រាប់សំណើច្រើន។ ទោះយ៉ាងណាក៏ដោយ ដោយសារវាអាចក្លាយជាឧបសគ្គយ៉ាងងាយស្រួល ការអនុវត្តផ្សេងៗនៃ HTTP/1.1 អនុញ្ញាតឱ្យមានការភ្ជាប់ TCP ជាច្រើនត្រូវបានបើកទៅកាន់ម៉ាស៊ីនតែមួយ។ ឧទាហរណ៍ Chrome និង Firefox កំណែថ្មីៗអនុញ្ញាតឱ្យមានការតភ្ជាប់រហូតដល់ប្រាំមួយ។

ការអ៊ិនគ្រីបក៏ត្រូវបានគេសន្មត់ថាទុកចោលទៅពិធីការផ្សេងទៀត ហើយសម្រាប់រឿងនេះ ពិធីការ TLS ត្រូវបានប្រើលើ TCP ដែលការពារទិន្នន័យដោយភាពជឿជាក់ ប៉ុន្តែបានបង្កើនពេលវេលាដែលត្រូវការដើម្បីបង្កើតការតភ្ជាប់បន្ថែមទៀត។ ជាលទ្ធផល ដំណើរការចាប់ដៃចាប់ផ្តើមមើលទៅដូចនេះ៖

រូបភាព Cloudflare

ដូច្នេះ HTTP/1.1 មានបញ្ហាមួយចំនួន៖

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

ប្រសិនបើ server-push យ៉ាងហោចណាស់ត្រូវបានអនុវត្តដោយប្រើពិធីការ WebSocket នោះបញ្ហាដែលនៅសេសសល់ត្រូវដោះស្រាយកាន់តែធ្ងន់ធ្ងរ។

ភាពទំនើបបន្តិច៖ HTTP/2

ក្នុងឆ្នាំ 2012 Google បានចាប់ផ្តើមធ្វើការលើពិធីសារ SPDY (ប្រកាសថា "លឿន")។ ពិធីការត្រូវបានរចនាឡើងដើម្បីដោះស្រាយបញ្ហាចម្បងរបស់ HTTP/1.1 ហើយនៅពេលជាមួយគ្នានេះត្រូវបានគេសន្មត់ថារក្សាភាពឆបគ្នាថយក្រោយ។ នៅឆ្នាំ 2015 ក្រុមការងារ IETF បានណែនាំការបញ្ជាក់ HTTP/2 ដោយផ្អែកលើពិធីការ SPDY ។ នេះគឺជាភាពខុសគ្នានៅក្នុង HTTP/2៖

• សៀរៀលគោលពីរ។
• ការបញ្ចូលសំណើ HTTP ច្រើនទៅក្នុងការតភ្ជាប់ TCP តែមួយ។
• ម៉ាស៊ីនមេ - រុញចេញពីប្រអប់ (ដោយគ្មាន WebSocket) ។

ពិធីការគឺជាជំហានដ៏ធំមួយឆ្ពោះទៅមុខ។ គាត់ខ្លាំង យកឈ្នះកំណែដំបូងក្នុងល្បឿន ហើយ​មិន​តម្រូវ​ឱ្យ​មាន​ការ​បង្កើត​ការ​តភ្ជាប់ TCP ច្រើន​: សំណើ​ទាំង​អស់​ទៅ​ម៉ាស៊ីន​មួយ​ត្រូវ​បាន​ពហុគុណ​ទៅ​ជា​មួយ​។ នោះគឺនៅក្នុងការតភ្ជាប់មួយមានស្ទ្រីមជាច្រើនដែលគេហៅថា ដែលនីមួយៗមានលេខសម្គាល់ផ្ទាល់ខ្លួន។ ប្រាក់រង្វាន់គឺជាការជំរុញម៉ាស៊ីនមេដែលមានប្រអប់។

ទោះយ៉ាងណាក៏ដោយ ការពហុគុណនាំទៅរកបញ្ហាសំខាន់មួយទៀត។ ស្រមៃថាយើងកំពុងដំណើរការសំណើ 5 យ៉ាងអសមកាលទៅកាន់ម៉ាស៊ីនមេមួយ។ នៅពេលប្រើ HTTP/2 សំណើទាំងអស់នេះនឹងត្រូវបានអនុវត្តនៅក្នុងការតភ្ជាប់ TCP ដូចគ្នា ដែលមានន័យថាប្រសិនបើផ្នែកមួយនៃសំណើណាមួយត្រូវបានបាត់បង់ ឬទទួលបានមិនត្រឹមត្រូវ ការបញ្ជូនសំណើ និងការឆ្លើយតបទាំងអស់នឹងបញ្ឈប់រហូតដល់ផ្នែកដែលបាត់បង់។ បានស្ដារឡើងវិញ។ ជាក់ស្តែង គុណភាពនៃការតភ្ជាប់កាន់តែអាក្រក់ ដំណើរការ HTTP/2 កាន់តែយឺត។ នេះ​បើ​តាម​លោក Daniel Stenbergនៅក្នុងលក្ខខណ្ឌដែលបាត់កញ្ចប់ព័ត៌មានមានចំនួន 2% នៃកញ្ចប់ព័ត៌មានទាំងអស់ HTTP/1.1 នៅក្នុងកម្មវិធីរុករកតាមអ៊ីនធឺណិតដំណើរការបានល្អជាង HTTP/2 ដោយសារតែវាបើក 6 ការតភ្ជាប់ជាជាងមួយ។

បញ្ហានេះត្រូវបានគេហៅថា "ការទប់ស្កាត់ក្បាលបន្ទាត់" ហើយជាអកុសលវាមិនអាចដោះស្រាយបានទេនៅពេលប្រើ TCP ។

គំនូរដោយ Daniel Steinberg

ជាលទ្ធផល អ្នកអភិវឌ្ឍន៍ស្តង់ដារ HTTP/2 ធ្វើការងារបានល្អណាស់ ហើយធ្វើអ្វីៗស្ទើរតែទាំងអស់ដែលអាចធ្វើបាននៅស្រទាប់កម្មវិធីនៃគំរូ OSI ។ វាដល់ពេលដែលត្រូវចុះទៅស្រទាប់ដឹកជញ្ជូន ហើយបង្កើតពិធីការដឹកជញ្ជូនថ្មីមួយ។

យើងត្រូវការពិធីការថ្មី៖ UDP ទល់នឹង TCP

វាច្បាស់ណាស់ថាការអនុវត្តពិធីការស្រទាប់ដឹកជញ្ជូនថ្មីទាំងស្រុងគឺជាកិច្ចការដែលមិនអាចទៅរួចក្នុងការពិតនាពេលបច្ចុប្បន្ននេះ។ ការពិតគឺថា Hardware ឬ Middle-boxes (router, firewalls, NAT servers...) ដឹងអំពីស្រទាប់ដឹកជញ្ជូន ហើយការបង្រៀនពួកគេនូវអ្វីដែលថ្មីគឺជាកិច្ចការដ៏លំបាកបំផុត។ លើសពីនេះ ការគាំទ្រសម្រាប់ពិធីការដឹកជញ្ជូនត្រូវបានភ្ជាប់ដោយរឹងទៅក្នុងខឺណែលនៃប្រព័ន្ធប្រតិបត្តិការ ហើយខឺណែលក៏មិនមានឆន្ទៈក្នុងការផ្លាស់ប្តូរដែរ។

ហើយនៅទីនេះ មនុស្សម្នាក់អាចលើកដៃម្ខាង ហើយនិយាយថា "ជាការពិតណាស់ យើងនឹងបង្កើត HTTP/3 ថ្មីជាមួយនឹងចំណូលចិត្ត និងការគួរសម ប៉ុន្តែវានឹងចំណាយពេល 10-15 ឆ្នាំដើម្បីអនុវត្ត (បន្ទាប់ពីប្រហែលពេលនេះ ភាគច្រើននៃផ្នែករឹងនឹងត្រូវបាន ជំនួស)” ប៉ុន្តែមានមួយទៀតមិនដូច្នេះទេ ជម្រើសជាក់ស្តែងគឺត្រូវប្រើពិធីការ UDP ។ បាទ/ចាស៎ ពិធីការដូចគ្នាដែលយើងធ្លាប់បោះឯកសារនៅលើ LAN នៅចុងទសវត្សរ៍ទី XNUMX និងដើមទសវត្សរ៍ឆ្នាំ XNUMX។ Hardware ស្ទើរតែទាំងអស់សព្វថ្ងៃនេះអាចដំណើរការជាមួយវាបាន។

តើអ្វីទៅជាអត្ថប្រយោជន៍នៃ UDP ជាង TCP? ជាដំបូង យើងមិនមានវគ្គដឹកជញ្ជូនដែលផ្នែករឹងដឹងអំពីនោះទេ។ នេះអនុញ្ញាតឱ្យយើងកំណត់វគ្គនៅលើចំណុចបញ្ចប់ដោយខ្លួនឯង និងដោះស្រាយជម្លោះនៅទីនោះ។ នោះគឺយើងមិនត្រូវបានកំណត់ចំពោះវគ្គមួយ ឬច្រើនទេ (ដូចនៅក្នុង TCP) ប៉ុន្តែអាចបង្កើតបានច្រើនតាមដែលយើងត្រូវការ។ ទីពីរ ការបញ្ជូនទិន្នន័យតាមរយៈ UDP គឺលឿនជាងតាមរយៈ TCP ។ ដូច្នេះតាមទ្រឹស្ដី យើងអាចទម្លុះល្បឿនបច្ចុប្បន្នដែលសម្រេចបាននៅក្នុង HTTP/2។

ទោះយ៉ាងណាក៏ដោយ UDP មិនធានាការបញ្ជូនទិន្នន័យដែលអាចជឿទុកចិត្តបានទេ។ តាមការពិត យើងគ្រាន់តែផ្ញើកញ្ចប់ព័ត៌មានដោយសង្ឃឹមថា ចុងម្ខាងទៀតនឹងទទួលបានពួកគេ។ មិនបានទទួលទេ? មែនហើយ សំណាងទេ... នេះគឺគ្រប់គ្រាន់ដើម្បីបញ្ជូនវីដេអូសម្រាប់មនុស្សពេញវ័យ ប៉ុន្តែសម្រាប់រឿងធ្ងន់ធ្ងរជាងនេះ អ្នកត្រូវការភាពជឿជាក់ ដែលមានន័យថាអ្នកត្រូវរុំអ្វីផ្សេងទៀតនៅលើ UDP ។

ដូចនឹង HTTP/2 ការងារលើការបង្កើតពិធីការថ្មីបានចាប់ផ្តើមនៅ Google ក្នុងឆ្នាំ 2012 ពោលគឺនៅជុំវិញពេលដូចគ្នាជាមួយនឹងការងារនៅលើ SPDY បានចាប់ផ្តើម។ ក្នុងឆ្នាំ 2013 លោក Jim Roskind បានបង្ហាញដល់សាធារណជនទូទៅ ពិធីការ QUIC (ការភ្ជាប់អ៊ីនធឺណិតរហ័ស UDP)ហើយរួចហើយនៅក្នុងឆ្នាំ 2015 សេចក្តីព្រាងអ៊ីនធឺណិតត្រូវបានណែនាំសម្រាប់ការធ្វើស្តង់ដារនៅក្នុង IETF ។ រួចហើយនៅពេលនោះ ពិធីការដែលបង្កើតឡើងដោយ Roskind នៅ Google គឺខុសគ្នាខ្លាំងពីស្តង់ដារ ដូច្នេះកំណែ Google បានចាប់ផ្តើមត្រូវបានគេហៅថា gQUIC ។

តើ QUIC គឺជាអ្វី

ទីមួយ ដូចដែលបានបញ្ជាក់រួចមកហើយ នេះគឺជាការរុំលើ UDP ។ ការតភ្ជាប់ QUIC ឡើងលើ UDP ដែលក្នុងនោះ ដោយការប្រៀបធៀបជាមួយ HTTP/2 ស្ទ្រីមជាច្រើនអាចមាន។ ស្ទ្រីមទាំងនេះមានតែនៅលើចំណុចបញ្ចប់ប៉ុណ្ណោះ ហើយត្រូវបានបម្រើដោយឯករាជ្យ។ ប្រសិនបើការបាត់បង់កញ្ចប់ព័ត៌មានកើតឡើងនៅក្នុងស្ទ្រីមមួយ វានឹងមិនប៉ះពាល់ដល់អ្នកដទៃទេ។

គំនូរដោយ Daniel Steinberg

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

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

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

ហើយទីបំផុតចំណងជើង។ ការបង្ហាប់បឋមកថាគឺជារឿងមួយដែលខុសគ្នារវាង QUIC និង gQUIC ។ ខ្ញុំ​មិន​ឃើញ​ចំណុច​សំខាន់​ក្នុង​ការ​ចំណាយ​ពេល​ច្រើន​សម្រាប់​រឿង​នេះ​ទេ ខ្ញុំ​គ្រាន់​តែ​និយាយ​ថា​នៅ​ក្នុង​កំណែ​ដែល​បាន​ដាក់​ស្នើ​សម្រាប់​ស្តង់ដារ ការ​បង្ហាប់​បឋមកថា​ត្រូវ​បាន​ធ្វើ​ឱ្យ​ស្រដៀង​គ្នា​នឹង​ការ​បង្ហាប់​បឋមកថា​ក្នុង HTTP/2។ អ្នកអាចអានបន្ថែម នៅទីនេះ.

តើវាលឿនប៉ុណ្ណា?

វាជាសំណួរពិបាក។ ការពិតគឺថាទាល់តែយើងមានស្ដង់ដារ គ្មានអ្វីពិសេសសម្រាប់វាស់វែងនោះទេ។ ប្រហែលជាស្ថិតិតែមួយគត់ដែលយើងមានគឺស្ថិតិពី Google ដែលបានប្រើប្រាស់ gQUIC តាំងពីឆ្នាំ 2013 និងឆ្នាំ 2016 រាយការណ៍ទៅ IETFថាប្រហែល 90% នៃចរាចរទៅកាន់ម៉ាស៊ីនមេរបស់ពួកគេពីកម្មវិធីរុករក Chrome ឥឡូវនេះប្រើ QUIC ។ នៅក្នុងបទបង្ហាញដូចគ្នា ពួកគេរាយការណ៍ថាទំព័រផ្ទុកលឿនជាង 5% តាមរយៈ gQUIC ហើយមាន 30% តិចក្នុងការចាក់វីដេអូបើធៀបនឹង TCP ។

នៅឆ្នាំ 2017 ក្រុមអ្នកស្រាវជ្រាវដែលដឹកនាំដោយ Arash Molavi Kakhki បានបោះពុម្ពផ្សាយ ធ្វើ​បាន​ល្អ ដើម្បីសិក្សាការអនុវត្តរបស់ gQUIC បើប្រៀបធៀបទៅនឹង TCP ។
ការសិក្សាបានបង្ហាញពីភាពទន់ខ្សោយជាច្រើនរបស់ gQUIC ដូចជាអស្ថិរភាពចំពោះការលាយបញ្ចូលគ្នានៃកញ្ចប់បណ្តាញ ការលោភលន់ (អយុត្តិធម៌) ទៅនឹងកម្រិតបញ្ជូនរបស់ឆានែល និងការផ្ទេរយឺតនៃវត្ថុតូចៗ (រហូតដល់ 10 kb) ។ ទោះយ៉ាងណាក៏ដោយ ក្រោយមកទៀតអាចត្រូវបានផ្តល់សំណងដោយការប្រើ 0-RTT ។ ក្នុងករណីផ្សេងទៀតទាំងអស់ដែលបានសិក្សា gQUIC បានបង្ហាញពីការកើនឡើងនៃល្បឿនធៀបនឹង TCP ។ វាពិបាកក្នុងការនិយាយអំពីលេខជាក់លាក់នៅទីនេះ។ អានកាន់តែប្រសើរ ការស្រាវជ្រាវខ្លួនឯង ឬ ប្រកាសខ្លី.

នៅទីនេះវាត្រូវតែនិយាយថាទិន្នន័យនេះគឺជាក់លាក់អំពី gQUIC ហើយវាមិនពាក់ព័ន្ធសម្រាប់ស្តង់ដារដែលកំពុងត្រូវបានបង្កើតឡើងនោះទេ។ អ្វីដែលនឹងកើតឡើងសម្រាប់ QUIC៖ វានៅតែជាការសម្ងាត់ ប៉ុន្តែមានក្តីសង្ឃឹមថា ចំណុចខ្សោយដែលបានកំណត់នៅក្នុង gQUIC នឹងត្រូវបានយកមកពិចារណា និងកែតម្រូវ។

អនាគតបន្តិច៖ ចុះ HTTP/3?

ប៉ុន្តែនៅទីនេះអ្វីគ្រប់យ៉ាងគឺច្បាស់លាស់: API នឹងមិនផ្លាស់ប្តូរតាមវិធីណាមួយឡើយ។ អ្វីៗនឹងនៅដដែលដូចនៅក្នុង HTTP/2។ ជាការប្រសើរណាស់ ប្រសិនបើ API នៅតែដដែល ការផ្លាស់ប្តូរទៅ HTTP/3 នឹងត្រូវដោះស្រាយដោយប្រើកំណែថ្មីនៃបណ្ណាល័យនៅលើផ្នែកខាងក្រោយដែលគាំទ្រការដឹកជញ្ជូន QUIC ។ ពិត អ្នកនឹងត្រូវរក្សាការថយក្រោយនៅលើកំណែចាស់របស់ HTTP សម្រាប់ពេលខ្លះ ដោយសារតែ បច្ចុប្បន្ន អ៊ីនធឺណិតមិនទាន់រួចរាល់សម្រាប់ការផ្លាស់ប្តូរពេញលេញទៅ UDP ទេ។

អ្នកណាគាំទ្ររួចហើយ

នៅទីនេះ បញ្ជី ការអនុវត្ត QUIC ដែលមានស្រាប់។ ទោះ​បី​ជា​ខ្វះ​ស្ដង់ដារ​ក៏​ដោយ ក៏​បញ្ជី​នេះ​មិន​អន់​ដែរ។

បច្ចុប្បន្នមិនមានកម្មវិធីរុករកណាមួយគាំទ្រ QUIC ក្នុងការចេញផ្សាយផលិតកម្មទេ។ ថ្មីៗនេះមានព័ត៌មានដែលគាំទ្រ HTTP/3 ត្រូវបានរួមបញ្ចូលនៅក្នុង Chrome ប៉ុន្តែរហូតមកដល់ពេលនេះមានតែនៅក្នុង Canary ប៉ុណ្ណោះ។

ក្នុងចំណោមផ្នែកខាងក្រោយ HTTP/3 គាំទ្រតែប៉ុណ្ណោះ caddy и Cloudflareប៉ុន្តែនៅតែពិសោធន៍។ NGINX នៅចុងនិទាឃរដូវឆ្នាំ 2019 បានប្រកាសដែលបានចាប់ផ្តើមធ្វើការលើការគាំទ្រ HTTP/3 ប៉ុន្តែមិនទាន់បានបញ្ចប់វានៅឡើយទេ។

តើមានបញ្ហាអ្វីខ្លះ?

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

អ្វី​ដែល​សំខាន់​បំផុត​នោះ​គឺ​ថា​អ្នក​ត្រូវ​ពន្យល់​យ៉ាង​ដូចម្ដេច​ទៅ​កាន់​កម្មវិធី​រុករក​ថា "https://" មិន​មែន​ជា​ការ​ពិត​ដែល​វា​នាំ​ទៅ​ច្រក TCP 443 ទៀត​ទេ។ ប្រហែលជាមិនមាន TCP ទាល់តែសោះ។ បឋមកថា Alt-Svc ត្រូវបានប្រើសម្រាប់ការនេះ។ វាអនុញ្ញាតឱ្យអ្នកប្រាប់កម្មវិធីរុករកថាគេហទំព័រនេះក៏មាននៅលើពិធីការបែបនេះ និងអាសយដ្ឋានបែបនេះផងដែរ។ តាមទ្រឹស្ដី នេះគួរតែដំណើរការដូចការទាក់ទាញ ប៉ុន្តែនៅក្នុងការអនុវត្តជាក់ស្តែង យើងនឹងជួបប្រទះនូវការពិតដែលថា UDP អាចត្រូវបានហាមឃាត់នៅលើជញ្ជាំងភ្លើង ដើម្បីជៀសវាងការវាយប្រហារដោយ DDoS ។

ប៉ុន្តែទោះបីជា UDP មិនត្រូវបានហាមឃាត់ក៏ដោយ ក៏ម៉ាស៊ីនភ្ញៀវអាចនៅពីក្រោយរ៉ោតទ័រ NAT ដែលត្រូវបានកំណត់រចនាសម្ព័ន្ធដើម្បីកាន់វគ្គ TCP ដោយអាសយដ្ឋាន IP ហើយដោយសារតែ យើងប្រើ UDP ដែលមិនមានវគ្គផ្នែករឹង NAT នឹងមិនរក្សាការតភ្ជាប់ និងវគ្គ QUIC នឹងបំបែកឥតឈប់ឈរ.

បញ្ហាទាំងអស់នេះគឺដោយសារតែ UDP ពីមុនមិនត្រូវបានប្រើដើម្បីបញ្ជូនមាតិកាអ៊ីនធឺណិត ហើយអ្នកផលិតផ្នែករឹងមិនអាចទាយទុកជាមុនថាវានឹងកើតឡើងនោះទេ។ ដូចគ្នាដែរ អ្នកគ្រប់គ្រងមិនទាន់យល់ពីរបៀបកំណត់បណ្តាញរបស់ពួកគេឱ្យបានត្រឹមត្រូវសម្រាប់ QUIC ដើម្បីដំណើរការ។ ស្ថានភាពនេះនឹងផ្លាស់ប្តូរបន្តិចម្តងៗ ហើយក្នុងករណីណាក៏ដោយ ការផ្លាស់ប្តូរបែបនេះនឹងចំណាយពេលតិចជាងការអនុវត្តពិធីការស្រទាប់ដឹកជញ្ជូនថ្មី។

លើសពីនេះទៀត ដូចដែលបានរៀបរាប់រួចហើយ QUIC បង្កើនការប្រើប្រាស់ស៊ីភីយូយ៉ាងខ្លាំង។ Daniel Stenberg កោតសរសើរ ដំណើរការកើនឡើងដល់ទៅបីដង។

តើ HTTP/3 នឹងមកដល់នៅពេលណា?

ស្តង់ដារ ចង់ទទួលយក ត្រឹមខែឧសភា ឆ្នាំ 2020 ប៉ុន្តែដោយសារឯកសារដែលបានគ្រោងទុកសម្រាប់ខែកក្កដា ឆ្នាំ 2019 នៅតែមិនទាន់បញ្ចប់នៅពេលនេះ យើងអាចនិយាយបានថាកាលបរិច្ឆេទនឹងទំនងជាត្រូវបានរុញត្រឡប់មកវិញ។

Google បាននិងកំពុងប្រើប្រាស់ការអនុវត្ត gQUIC របស់ខ្លួនតាំងពីឆ្នាំ 2013។ ប្រសិនបើអ្នកក្រឡេកមើលសំណើ HTTP ដែលត្រូវបានផ្ញើទៅកាន់ម៉ាស៊ីនស្វែងរក Google អ្នកនឹងឃើញវា៖

ការរកឃើញ

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

ទោះយ៉ាងណាក៏ដោយ នៅតែមានបញ្ហាមិនទាន់ដោះស្រាយ ដែលនឹងត្រូវដោះស្រាយក្នុងរយៈពេលប៉ុន្មានឆ្នាំខាងមុខ។ ដំណើរការអាចនឹងត្រូវពន្យារពេល ដោយសារតែមាន Hardware ពាក់ព័ន្ធ ដែលគ្មាននរណាម្នាក់ចូលចិត្តធ្វើបច្ចុប្បន្នភាព ប៉ុន្តែយ៉ាងណាក៏ដោយ បញ្ហាទាំងអស់មើលទៅអាចដោះស្រាយបាន ហើយមិនយូរមិនឆាប់ យើងទាំងអស់គ្នានឹងមាន HTTP/3។

អនាគតជិតមកដល់ហើយ!

ប្រភព: www.habr.com