HTTP លើ UDP - ប្រើពិធីការ QUIC ដើម្បីប្រើប្រាស់បានល្អ

QUIC (Quick UDP Internet Connections) គឺជាពិធីការនៅលើ UDP ដែលគាំទ្រមុខងារទាំងអស់របស់ TCP, TLS និង HTTP/2 ហើយដោះស្រាយបញ្ហាភាគច្រើនរបស់ពួកគេ។ ជារឿយៗវាត្រូវបានគេហៅថាពិធីការថ្មី ឬ "ការពិសោធន៍" ប៉ុន្តែវាមានរយៈពេលវែងនៃដំណាក់កាលពិសោធន៍៖ ការអភិវឌ្ឍន៍បានបន្តអស់រយៈពេលជាង 7 ឆ្នាំ។ ក្នុងអំឡុងពេលនេះ ពិធីការមិនបានគ្រប់គ្រងដើម្បីក្លាយជាស្តង់ដារទេ ប៉ុន្តែនៅតែរីករាលដាល។ ជាឧទាហរណ៍ QUIC ត្រូវបានប្រើប្រាស់ដោយក្រុមហ៊ុនយក្សដូចជា Google និង Facebook ដើម្បីបង្កើនល្បឿនចរាចរណ៍ និងកាត់បន្ថយការពន្យារពេលក្នុងបណ្តាញទូរស័ព្ទចល័ត ហើយ IETF បានប្រកាសអំពីសមនៃពិធីការរបស់ខ្លួនជាមូលដ្ឋានសម្រាប់ស្តង់ដារ HTTP/3 (ទោះបីជា HTTP/2 ប្រើ ត្រឹមតែ 44.8% គេហទំព័រ)។

គំនិត

QUIC ត្រូវ​បាន​បង្កើត​ឡើង​ជា​ការ​ជំនួស​ TCP ចាស់​ដែល​ត្រូវ​បាន​រចនា​ឡើង​ដំបូង​សម្រាប់​បណ្តាញ​ខ្សែ​ដែល​បាត់បង់​ទាប។ TCP ផ្តល់កញ្ចប់ព័ត៌មានតាមលំដាប់លំដោយ ដូច្នេះប្រសិនបើកញ្ចប់មួយត្រូវបានបាត់បង់ ជួរទាំងមូលត្រូវបានបញ្ឈប់ (ការទប់ស្កាត់ក្បាលបន្ទាត់) ដែលជះឥទ្ធិពលអវិជ្ជមានដល់គុណភាព និងស្ថេរភាពនៃការតភ្ជាប់។ ដើម្បីជៀសវាងការខាតបង់ដ៏ធំ បណ្តាញកោសិកាងាកទៅរកការប្រើប្រាស់សតិបណ្ដោះអាសន្នធំ ដែលនាំទៅរកភាពដដែលៗ និងការឆ្លើយតបអវិជ្ជមានមិនពិតនៃពិធីការ (bufferbloat) លើសពីនេះ TCP ចំណាយពេលវេលាច្រើនក្នុងការបង្កើតការតភ្ជាប់៖ សំណើ SYN/ACK និង TLS ត្រូវបានដំណើរការដោយឡែកពីគ្នា ដែលទាមទារការធ្វើដំណើរទៅមកចំនួនបីជំនួសឱ្យមួយ ដូច QUIC ធ្វើ។

ដោយសារ QUIC រួមបញ្ចូលការជំនួស TCP និងការអនុវត្ត TLS 1.3 ការតភ្ជាប់ទាំងអស់តែងតែត្រូវបានអ៊ិនគ្រីប ហើយការឌិគ្រីបចរាចរណ៍បែបនេះមិនងាយស្រួលជាងប្រសិនបើវាឆ្លងកាត់ HTTPS នោះទេ។ លើសពីនេះទៀត QUIC ត្រូវបានអនុវត្តនៅកម្រិតកម្មវិធី ដោយសារការជំនួសពេញលេញនៃជង់ TCP នឹងប្រព្រឹត្តទៅ ភាពអស់កល្ប.

ទោះបីជាមានការគាំទ្រសម្រាប់ multiplexing នៅក្នុង HTTP/2 ក៏ដោយ ក៏បញ្ហានៃការទប់ស្កាត់ជាចម្បងនៅតែមាននៅទីនោះ ដោយសារតែតម្រូវការក្នុងការចែកចាយកញ្ចប់ព័ត៌មានតាមលំដាប់លំដោយ។ QUIC ត្រូវបានអនុវត្តនៅលើកំពូល UDP ដូច្នេះវាមិនមានការទប់ស្កាត់ជាគោលការណ៍ទេ ហើយដើម្បីការពារកញ្ចប់ព័ត៌មានពីការបាត់ជារៀងរហូត ពួកវាត្រូវបានដាក់លេខ ហើយអាចមានផ្នែកខ្លះនៃ "អ្នកជិតខាង" ដែលផ្តល់ភាពច្របូកច្របល់។ លើសពីនេះ QUIC បំបែកជួរ monolithic ទៅជាខ្សែស្រឡាយច្រើនសម្រាប់ប្រភេទផ្សេងគ្នានៃសំណើក្នុងការតភ្ជាប់តែមួយ។ ដូច្នេះប្រសិនបើកញ្ចប់ព័ត៌មានត្រូវបានបាត់បង់ បញ្ហាអាចកើតឡើងសម្រាប់តែជួរមួយប៉ុណ្ណោះ (ឧទាហរណ៍ សម្រាប់ការផ្ទេរឯកសារជាក់លាក់មួយ)៖

ប្រើ

ដំបូង QUIC ត្រូវ​បាន​បង្កើត​ឡើង​នៅ​ក្នុង Google ហើយ​ត្រូវ​បាន​សម្រួល​យ៉ាង​ច្រើន​សម្រាប់​ប្រើ​ក្នុង​ក្រុមហ៊ុន។ នៅឆ្នាំ 2013 វាត្រូវបានផ្ទេរទៅ IETF សម្រាប់ការធ្វើស្តង់ដារ (ដែលនៅតែកំពុងដំណើរការ) ហើយឥឡូវនេះអ្នកគ្រប់គ្នាអាចចូលរួមក្នុងការអភិវឌ្ឍន៍ពិធីការដោយស្នើនូវអ្វីដែលពួកគេកំពុងបាត់។ ក្រុមការងារ IETF រៀបចំកិច្ចប្រជុំប្រចាំឆ្នាំ ក្នុងអំឡុងពេលដែលស្តង់ដារថ្មីត្រូវបានអនុម័ត ហើយការច្នៃប្រឌិតត្រូវបានពិភាក្សា។ ការអនុវត្ត QUIC នេះត្រូវបានចាត់ទុកថាជាចំណុចសំខាន់ ហើយវាគឺផ្អែកលើស្តង់ដារ HTTP/3 ត្រូវបានបញ្ជាក់។

រហូតមកដល់ពេលនេះ មិនទាន់មានការនិយាយអំពីការរួមបញ្ចូល HTTP/3 ជាពិធីការចម្បងនោះទេ ព្រោះវាមិនទាន់បានបញ្ចប់ ហើយស្ទើរតែមិនត្រូវបានគាំទ្រ៖

ប៉ុន្តែ QUIC អាចត្រូវបានអនុវត្តជាការដឹកជញ្ជូនរវាងកម្មវិធី និងម៉ាស៊ីនមេ ដែលត្រូវបានធ្វើដោយជោគជ័យនៅ Uber៖

ការអត្ថាធិប្បាយរបស់ Uber លើការណែនាំរបស់ 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 របស់យើងដោយមិនមានការចំណាយលើការផ្ទេរទិន្នន័យដ៏សំខាន់។

យកពី ការបកប្រែនេះ។ អត្ថបទ Uber

នៅលើផ្នែកខាងក្រោយ ពួកគេចាប់បានការតភ្ជាប់ QUIC តាមរយៈ Google Cloud lb ដែល គាំទ្រពិធីការ ចាប់តាំងពីពាក់កណ្តាលឆ្នាំ 2018 ។

វាមិនមែនជារឿងចម្លែកទេដែល Google Cloud ដំណើរការល្អជាមួយពិធីការដែលបង្កើតឡើងដោយ Google ប៉ុន្តែតើមានជម្រើសអ្វីខ្លះ?

Nginx

មិនយូរប៉ុន្មាន CloudFlare ខ្ញុំបានព្យាយាមឆ្លងកាត់ nginx (ដែលមិនគាំទ្រ HTTP/3 តាមលំនាំដើម) ជាមួយនឹងឧបករណ៍ Quiche របស់វា។ ការអនុវត្តមានជាឯកសារ .patch តែមួយ ដែលភ្ជាប់មកជាមួយការបង្រៀនការដំឡើង៖

curl -O https://nginx.org/download/nginx-1.16.1.tar.gz
tar xvzf nginx-1.16.1.tar.gz
git clone --recursive https://github.com/cloudflare/quiche
cd nginx-1.16.1
patch -p01 < ../quiche/extras/nginx/nginx-1.16.patch

នៅទីនេះអ្នកអាចភ្ជាប់ម៉ូឌុលរបស់អ្នកប្រសិនបើចាំបាច់

./configure                          	
   	--prefix=$PWD                       	
   	--with-http_ssl_module              	
   	--with-http_v2_module               	
   	--with-http_v3_module               	
   	--with-openssl=../quiche/deps/boringssl 
   	--with-quiche=../quiche
 make

អ្វីដែលនៅសល់គឺត្រូវបើកការគាំទ្រ HTTP/3

events {
    worker_connections  1024;
}

http {
    server {
        # Enable QUIC and HTTP/3.
        listen 443 quic reuseport;

        # Enable HTTP/2 (optional).
        listen 443 ssl http2;

        ssl_certificate      cert.crt;
        ssl_certificate_key  cert.key;

        # Enable all TLS versions (TLSv1.3 is required for QUIC).
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;

        # Request buffering in not currently supported for HTTP/3.
        proxy_request_buffering off;

        # Add Alt-Svc header to negotiate HTTP/3.
        add_header alt-svc 'h3-27=":443"; ma=86400';
    }
}

វាមិនទាន់អាចភ្ជាប់តាមរយៈ HTTP/3 នៅក្នុងកម្មវិធីរុករកធម្មតាបានទេ ប៉ុន្តែអ្នកអាចប្រើបាន។ Chrome Canary ។ ហើយរត់វាជាមួយទង់ --enable-quicទៅកាន់ម៉ាស៊ីនមេរបស់អ្នក ឬឧទាហរណ៍ គេហទំព័រ quic.rocks ហើយមើលប្រភេទការតភ្ជាប់នៅក្នុងឧបករណ៍អ្នកអភិវឌ្ឍន៍៖

ជំនួសឱ្យ HTTP/3 វាត្រូវបានសរសេរ http2+quic/99ប៉ុន្តែវាជារឿងសំខាន់ដូចគ្នា។

បច្ចេកវិទ្យាផ្សេងៗ

• QUIC ក៏គាំទ្រផងដែរ។ ល្បឿនលឿន (ដែលភ្ជាប់ទៅ Facebook តាមរយៈ HTTP/3 ជាមួយនឹងអ្នកគាំទ្រដ៏អស្ចារ្យ) និងរីកចម្រើន caddy. Apache មិនអាចធ្វើវាបាននៅឡើយទេ ប៉ុន្តែការងារកំពុងដំណើរការ តំលៃ​ពេញ.
• ថ្ងៃទី 21 ខែមករាបានធ្វើបច្ចុប្បន្នភាព សេចក្តីព្រាងស្តង់ដារសម្រាប់ WebRTC
• គ្រាន់តែថ្ងៃមុនក្រុមហ៊ុន Microsoft បានបើក កូដការអនុវត្ត msquicដែលមិនមានមុខងារទាំងអស់ពីស្តង់ដារ IETF នៅឡើយទេ ប៉ុន្តែនេះគឺជារបកគំហើញដ៏ធំមួយរួចទៅហើយ។

សេចក្តីសន្និដ្ឋាន

ចំណាប់អារម្មណ៍លើ QUIC មិនស្ថិតស្ថេរទេ ប៉ុន្តែកំពុងកើនឡើង ហើយការងារកំពុងដំណើរការដើម្បីបង្កើតស្តង់ដារ។ ការអនុវត្តថ្មីនៃពិធីការលេចឡើងស្ទើរតែរៀងរាល់ខែ ហើយជារៀងរាល់ឆ្នាំអ្នកអភិវឌ្ឍន៍កាន់តែច្រើនឡើងត្រូវបានគេជឿជាក់ថា QUIC គឺជាអនាគត។ វាថែមទាំងអាចបញ្ចូលពិធីការនៅក្នុងកំណែអនាគតនៃ TCP stack ដែលមានន័យថាមិនយូរមិនឆាប់ អ៊ីនធឺណិតទាំងមូលនឹងផ្លាស់ទីទៅការតភ្ជាប់ដែលមានស្ថេរភាព និងលឿនជាងមុន។

ឥឡូវនេះ អ្នកអាចកំណត់រចនាសម្ព័ន្ធអន្តរកម្ម QUIC សម្រាប់ហេដ្ឋារចនាសម្ព័ន្ធរបស់អ្នក ឬសូម្បីតែផ្តល់ឱ្យវាទៅកម្មវិធីរុករក - ពួកគេទាំងអស់គ្រោងនឹងបន្ថែមការគាំទ្រសម្រាប់ពិធីការ ហើយស្ថិតិសោកសៅជាមួយ caniuse នឹងកាន់តែរីករាយ។

ប្រភព: www.habr.com