ពិធីការ QUIC បានទទួលស្ថានភាពនៃស្តង់ដារដែលបានស្នើឡើង។

ក្រុមការងារវិស្វកម្មអ៊ីនធឺណិត (IETF) ដែលទទួលខុសត្រូវចំពោះការអភិវឌ្ឍន៍ពិធីការ និងស្ថាបត្យកម្មអ៊ីនធឺណិតបានបញ្ចប់ RFC សម្រាប់ពិធីការ QUIC និងបានបោះពុម្ពផ្សាយលក្ខណៈជាក់លាក់ដែលពាក់ព័ន្ធក្រោមការកំណត់អត្តសញ្ញាណ RFC 8999 (លក្ខណសម្បត្តិពិធីការកំណែឯករាជ្យ) RFC 9000 (ដឹកជញ្ជូន លើ UDP), RFC 9001 (ការអ៊ិនគ្រីប TLS នៃបណ្តាញទំនាក់ទំនង QUIC) និង RFC 9002 (ការគ្រប់គ្រងការកកស្ទះ និងការរកឃើញការបាត់បង់កញ្ចប់ព័ត៌មានកំឡុងពេលបញ្ជូនទិន្នន័យ)។

RFCs បានទទួលស្ថានភាពនៃ "ស្តង់ដារដែលបានស្នើឡើង" បន្ទាប់មកការងារនឹងចាប់ផ្តើមផ្តល់ឱ្យ RFC នូវស្ថានភាពនៃស្តង់ដារសេចក្តីព្រាង (Draft Standard) ដែលពិតជាមានន័យថាស្ថេរភាពពេញលេញនៃពិធីការ និងពិចារណាលើមតិយោបល់ទាំងអស់ដែលបានធ្វើ។ ពិធីការ HTTP/3 ដែលកំណត់ការប្រើប្រាស់ពិធីការ QUIC ជាការដឹកជញ្ជូនសម្រាប់ HTTP/2 នៅតែស្ថិតក្នុងដំណាក់កាលកំណត់សេចក្តីព្រាង ប៉ុន្តែទីបំផុតវានឹងត្រូវបានកំណត់ស្តង់ដារដោយ IETF ឆាប់ៗនេះ។

វាត្រូវបានគេរំពឹងថាការធ្វើស្តង់ដារនៃ QUIC នឹងផ្តល់កម្លាំងរុញច្រានដល់ការទទួលយកកាន់តែទូលំទូលាយនៃពិធីការនេះ ក៏ដូចជាការអភិវឌ្ឍន៍ផ្នែកបន្ថែមដោយផ្អែកលើវា ដូចជា WebTransport (បច្ចេកវិទ្យាសម្រាប់ការផ្ញើ និងទទួលទិន្នន័យរវាងកម្មវិធីរុករកតាមអ៊ីនធឺណិត និងម៉ាស៊ីនមេ) និង MASQUE (បច្ចេកវិទ្យាទំនាក់ទំនងប្រូកស៊ីដែលពង្រីកសមត្ថភាពរបស់ SOCKS និង HTTP CONNECT និងប្រើប្រាស់ HTTPS លើ QUIC ជាការដឹកជញ្ជូន)។

ចូរយើងចាំថាពិធីការ QUIC (Quick UDP Internet Connections) ត្រូវបានបង្កើតឡើងដោយ Google តាំងពីឆ្នាំ 2013 ជាជម្រើសមួយសម្រាប់ការរួមបញ្ចូលគ្នានៃ TCP+TLS សម្រាប់គេហទំព័រ ដោយដោះស្រាយបញ្ហាជាមួយនឹងការដំឡើងរយៈពេលយូរ និងការចរចានៃការតភ្ជាប់នៅក្នុង TCP និងលុបបំបាត់ការពន្យារពេលនៅពេល កញ្ចប់ត្រូវបានបាត់បង់កំឡុងពេលផ្ទេរទិន្នន័យ។ QUIC គឺជាផ្នែកបន្ថែមនៃពិធីការ UDP ដែលគាំទ្រការពង្រីកការតភ្ជាប់ច្រើន និងផ្តល់នូវវិធីសាស្ត្រអ៊ិនគ្រីបដែលស្មើនឹង TLS/SSL។ ក្នុងអំឡុងពេលនៃការអភិវឌ្ឍន៍ស្តង់ដារ IETF ការផ្លាស់ប្តូរត្រូវបានធ្វើឡើងចំពោះពិធីការ ដែលនាំទៅដល់ការលេចចេញនូវសាខាប៉ារ៉ាឡែលពីរ ដែលមួយសម្រាប់ HTTP/3 និងទីពីរដែលគាំទ្រដោយ Google (Chrome គាំទ្រជម្រើសទាំងពីរ ហើយ Firefox គាំទ្រកំណែ IETF) .

លក្ខណៈសំខាន់ៗរបស់ QUIC៖

• សុវត្ថិភាពខ្ពស់ស្រដៀងនឹង TLS (ជាសំខាន់ QUIC ផ្តល់លទ្ធភាពប្រើប្រាស់ TLS លើ UDP);
• ការត្រួតពិនិត្យភាពសុចរិតនៃលំហូរ ការការពារការបាត់បង់កញ្ចប់ព័ត៌មាន;
• សមត្ថភាពក្នុងការបង្កើតការតភ្ជាប់ភ្លាមៗ (0-RTT ក្នុងប្រហែល 75% នៃករណីទិន្នន័យអាចត្រូវបានបញ្ជូនភ្លាមៗបន្ទាប់ពីផ្ញើកញ្ចប់ដំឡើងការតភ្ជាប់) និងផ្តល់ការពន្យារពេលតិចតួចបំផុតរវាងការផ្ញើសំណើ និងទទួលការឆ្លើយតប (RTT ពេលវេលាធ្វើដំណើរទៅមក)។
• ការប្រើប្រាស់លេខលំដាប់ផ្សេងគ្នានៅពេលបញ្ជូនកញ្ចប់ព័ត៌មានឡើងវិញ ដែលជៀសវាងភាពមិនច្បាស់លាស់ក្នុងការកំណត់អត្តសញ្ញាណកញ្ចប់ព័ត៌មានដែលបានទទួល និងកម្ចាត់ការអស់ពេល។
• ការបាត់បង់កញ្ចប់ព័ត៌មានប៉ះពាល់តែការចែកចាយស្ទ្រីមដែលភ្ជាប់ជាមួយវា និងមិនបញ្ឈប់ការចែកចាយទិន្នន័យនៅក្នុងស្ទ្រីមប៉ារ៉ាឡែលដែលបានបញ្ជូនតាមរយៈការតភ្ជាប់បច្ចុប្បន្ន។
• មុខងារកែកំហុសដែលកាត់បន្ថយការពន្យារពេលដោយសារការបញ្ជូនសារឡើងវិញនៃកញ្ចប់ព័ត៌មានដែលបាត់។ ការប្រើប្រាស់លេខកូដកែកំហុសពិសេសនៅកម្រិតកញ្ចប់ព័ត៌មាន ដើម្បីកាត់បន្ថយស្ថានភាពដែលតម្រូវឱ្យបញ្ជូនទិន្នន័យកញ្ចប់ព័ត៌មានដែលបាត់មកវិញ។
• ព្រំដែនប្លុកគ្រីបត្រូវបានតម្រឹមជាមួយព្រំដែនកញ្ចប់ព័ត៌មាន QUIC ដែលកាត់បន្ថយផលប៉ះពាល់នៃការបាត់បង់កញ្ចប់ព័ត៌មានលើការឌិកូដមាតិកានៃកញ្ចប់ព័ត៌មានជាបន្តបន្ទាប់។
• មិនមានបញ្ហាជាមួយនឹងការទប់ស្កាត់ជួរ TCP;
• ការគាំទ្រសម្រាប់ការកំណត់អត្តសញ្ញាណការតភ្ជាប់ ដែលកាត់បន្ថយពេលវេលាដែលវាត្រូវការដើម្បីបង្កើតការតភ្ជាប់ឡើងវិញសម្រាប់អតិថិជនទូរសព្ទចល័ត។
• លទ្ធភាពនៃការតភ្ជាប់កម្រិតខ្ពស់ យន្តការត្រួតពិនិត្យការកកស្ទះនៃការតភ្ជាប់;
• ប្រើបច្ចេកទេសព្យាករណ៍តាមរយៈទិសដៅនីមួយៗ ដើម្បីធានាថាកញ្ចប់ព័ត៌មានត្រូវបានផ្ញើក្នុងអត្រាដ៏ល្អប្រសើរ ការពារពួកវាពីការកកស្ទះ និងបណ្តាលឱ្យបាត់បង់កញ្ចប់ព័ត៌មាន។
• ការកើនឡើងគួរឱ្យកត់សម្គាល់នៅក្នុងដំណើរការនិងលំហូរធៀបនឹង TCP ។ សម្រាប់សេវាកម្មវីដេអូដូចជា YouTube , QUIC ត្រូវបានបង្ហាញដើម្បីកាត់បន្ថយប្រតិបត្តិការបដិសេធនៅពេលមើលវីដេអូ 30% ។

ប្រភព: opennet.ru