HTTP/3.0 បានទទួលស្ថានភាពស្តង់ដារដែលបានស្នើឡើង

IETF (Internet Engineering Task Force) ដែលទទួលខុសត្រូវក្នុងការអភិវឌ្ឍន៍ពិធីការ និងស្ថាបត្យកម្មអ៊ីនធឺណិត បានបញ្ចប់ការបង្កើត RFC សម្រាប់ពិធីការ HTTP/3.0 និងបានបោះពុម្ពផ្សាយលក្ខណៈជាក់លាក់ដែលពាក់ព័ន្ធក្រោមការកំណត់អត្តសញ្ញាណ RFC 9114 (ពិធីការ) និង RFC 9204 ( បច្ចេកវិទ្យាបង្ហាប់ក្បាល QPACK សម្រាប់ HTTP/3) ។ ការបញ្ជាក់ HTTP/3.0 បានទទួលស្ថានភាពនៃ "ស្តង់ដារដែលបានស្នើឡើង" បន្ទាប់មកការងារនឹងចាប់ផ្តើមផ្តល់ឱ្យ RFC នូវស្ថានភាពនៃស្តង់ដារសេចក្តីព្រាង (ស្តង់ដារសេចក្តីព្រាង) ដែលពិតជាមានន័យថាស្ថេរភាពពេញលេញនៃពិធីការ និងគិតគូរដល់ការទាំងអស់ មតិដែលបានធ្វើ។ ក្នុងពេលជាមួយគ្នានោះ កំណែដែលបានអាប់ដេតនៃលក្ខណៈជាក់លាក់សម្រាប់ពិធីការ HTTP/1.1 (RFC 9112) និង HTTP/2.0 (RFC 9113) ត្រូវបានបោះពុម្ព ក៏ដូចជាឯកសារដែលកំណត់អត្ថន័យនៃសំណើ HTTP (RFC 9110) និង HTTP caching control headers (RFC 9111) ។

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

បច្ចុប្បន្ននេះ ការគាំទ្រ QUIC និង HTTP/3.0 ត្រូវបានអនុវត្តរួចហើយនៅក្នុងកម្មវិធីរុករកតាមអ៊ីនធឺណិតដ៏ពេញនិយមទាំងអស់ (នៅក្នុង Chrome, Firefox និង Edge ការគាំទ្រ HTTP/3 ត្រូវបានបើកតាមលំនាំដើម ហើយនៅក្នុង Safari វាទាមទារការកំណត់ "កម្រិតខ្ពស់ > លក្ខណៈពិសេសពិសោធន៍ > HTTP/3" ត្រូវបានបើក) ។ នៅផ្នែកខាងម៉ាស៊ីនមេ ការអនុវត្ត HTTP/3 មានសម្រាប់ nginx (នៅក្នុងសាខាដាច់ដោយឡែក និងក្នុងទម្រង់ជាម៉ូឌុលដាច់ដោយឡែក) Caddy, IIS និង LiteSpeed ​​។ ការគាំទ្រ HTTP/3 ក៏ត្រូវបានផ្តល់ដោយបណ្តាញចែកចាយមាតិកា Cloudflare ផងដែរ។

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

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

ក្នុងចំណោមការផ្លាស់ប្តូរនៅក្នុងការបញ្ជាក់ HTTP/1.1 មនុស្សម្នាក់អាចកត់សម្គាល់ការហាមឃាត់លើការប្រើប្រាស់ដាច់ដោយឡែកនៃតួអក្សរត្រឡប់មកវិញ (CR) នៅខាងក្រៅតួជាមួយនឹងមាតិកា ឧ។ នៅក្នុងធាតុពិធីការ តួអក្សរ CR អាចប្រើបានតែជាមួយតួអក្សរចំណីបន្ទាត់ (CRLF) ប៉ុណ្ណោះ។ ក្បួនដោះស្រាយ​ប្លង់​សំណើ​ដែល​បាន​បំបែក​ត្រូវ​បាន​ធ្វើ​ឱ្យ​ប្រសើរ​ឡើង​ដើម្បី​សម្រួល​ដល់​ការ​បំបែក​ផ្នែក​ដែល​បាន​ភ្ជាប់​ជាមួយ​នឹង​បឋមកថា។ បានបន្ថែមការណែនាំសម្រាប់ការដោះស្រាយខ្លឹមសារមិនច្បាស់លាស់ដើម្បីទប់ស្កាត់ការវាយប្រហារ “HTTP Request Smuggling” ដែលអនុញ្ញាតឱ្យយើងភ្ជាប់ខ្លួនយើងទៅក្នុងខ្លឹមសារនៃសំណើរបស់អ្នកប្រើប្រាស់ផ្សេងទៀតនៅក្នុងលំហូររវាងផ្នែកខាងមុខ និងផ្នែកខាងក្រោយ។

ការអាប់ដេតលក្ខណៈជាក់លាក់ HTTP/2.0 កំណត់យ៉ាងច្បាស់នូវការគាំទ្រសម្រាប់ TLS 1.3 ។ បានបដិសេធគ្រោងការណ៍កំណត់អាទិភាព និងវាលបឋមកថាដែលពាក់ព័ន្ធ។ យន្តការដែលមិនប្រើសម្រាប់ធ្វើបច្ចុប្បន្នភាពការតភ្ជាប់ជាមួយ HTTP/1.1 ត្រូវបានប្រកាសថាលែងប្រើហើយ។ តម្រូវការសម្រាប់ពិនិត្យមើលឈ្មោះវាល និងតម្លៃត្រូវបានកាត់បន្ថយ។ ប្រភេទស៊ុម និងប៉ារ៉ាម៉ែត្រដែលបានបម្រុងទុកពីមុនមួយចំនួនត្រូវបានស្នើឡើងសម្រាប់ការប្រើប្រាស់។ វាលបឋមកថាហាមឃាត់ដែលទាក់ទងនឹងការតភ្ជាប់ត្រូវបានកំណត់យ៉ាងច្បាស់លាស់ជាង។

ប្រភព: opennet.ru