HTTP over UDP - ເຮັດໃຫ້ການນໍາໃຊ້ທີ່ດີຂອງໂປໂຕຄອນ QUIC

QUIC (ການ​ເຊື່ອມ​ຕໍ່​ອິນ​ເຕີ​ເນັດ UDP ດ່ວນ​) ເປັນ​ໂປ​ຣ​ໂຕ​ຄອນ​ເທິງ​ຂອງ UDP ທີ່​ສະ​ຫນັບ​ສະ​ຫນູນ​ຄຸນ​ສົມ​ບັດ​ທັງ​ຫມົດ​ຂອງ TCP​, TLS ແລະ HTTP / 2 ແລະ​ແກ້​ໄຂ​ບັນ​ຫາ​ສ່ວນ​ໃຫຍ່​ຂອງ​ເຂົາ​ເຈົ້າ​. ມັນມັກຈະເອີ້ນວ່າພິທີການໃຫມ່ຫຼື "ການທົດລອງ", ແຕ່ມັນໄດ້ຜ່ານໄລຍະການທົດລອງມາດົນນານ: ການພັດທະນາໄດ້ດໍາເນີນມາເປັນເວລາຫຼາຍກວ່າ 7 ປີ. ໃນລະຫວ່າງເວລານີ້, ອະນຸສັນຍາບໍ່ໄດ້ຈັດການໃຫ້ກາຍເປັນມາດຕະຖານ, ແຕ່ຍັງແຜ່ຂະຫຍາຍຢ່າງກວ້າງຂວາງ. ຕົວຢ່າງ, QUIC ຖືກນໍາໃຊ້ໂດຍຍັກໃຫຍ່ເຊັ່ນ Google ແລະ Facebook ເພື່ອເລັ່ງການຈະລາຈອນແລະຫຼຸດຜ່ອນຄວາມລ່າຊ້າໃນເຄືອຂ່າຍມືຖື, ແລະ IETF ປະກາດ fork ຂອງໂປໂຕຄອນຂອງຕົນເປັນພື້ນຖານສໍາລັບມາດຕະຖານ HTTP / 3 (ເຖິງແມ່ນວ່າ HTTP / 2 ໃຊ້. ພຽງ​ແຕ່ 44.8​% ພື້ນ​ທີ່).

ແນວຄິດ

QUIC ໄດ້ຖືກພັດທະນາເປັນການທົດແທນ TCP ແບບເກົ່າ, ເຊິ່ງໄດ້ຖືກອອກແບບໃນເບື້ອງຕົ້ນສໍາລັບເຄືອຂ່າຍມີສາຍທີ່ມີການສູນເສຍຕ່ໍາ. TCP ຈັດສົ່ງແພັກເກັດຕາມລໍາດັບ, ດັ່ງນັ້ນຖ້າຊຸດຫນຶ່ງຫາຍໄປ, ແຖວທັງຫມົດຈະຖືກຢຸດ (ການຂັດຂວາງທາງຫົວ), ເຊິ່ງມີຜົນກະທົບທາງລົບຕໍ່ຄຸນນະພາບແລະຄວາມຫມັ້ນຄົງຂອງການເຊື່ອມຕໍ່. ເພື່ອຫຼີກເວັ້ນການສູນເສຍອັນໃຫຍ່ຫຼວງ, ເຄືອຂ່າຍໂທລະສັບມືຖືຈະໃຊ້ buffers ຂະຫນາດໃຫຍ່, ເຊິ່ງເຮັດໃຫ້ການຊ້ໍາຊ້ອນແລະການຕອບໂຕ້ທີ່ບໍ່ຖືກຕ້ອງຂອງໂປໂຕຄອນ (bufferbloat). ນອກຈາກນັ້ນ, TCP ໃຊ້ເວລາຫຼາຍໃນການສ້າງການເຊື່ອມຕໍ່: ການຮ້ອງຂໍ SYN / ACK ແລະ TLS ໄປແຍກຕ່າງຫາກ, ຮຽກຮ້ອງໃຫ້ມີສາມໄປກັບແທນທີ່ຈະເປັນຫນຶ່ງ, ດັ່ງທີ່ QUIC ເຮັດ.

ເນື່ອງຈາກ QUIC ປະສົມປະສານການທົດແທນ TCP ແລະການປະຕິບັດ TLS 1.3, ການເຊື່ອມຕໍ່ທັງຫມົດຈະຖືກເຂົ້າລະຫັດສະເຫມີ, ແລະການຖອດລະຫັດການຈາລະຈອນດັ່ງກ່າວບໍ່ງ່າຍກວ່າຖ້າມັນຜ່ານ HTTPS. ນອກຈາກນັ້ນ, QUIC ໄດ້ຖືກປະຕິບັດຢູ່ໃນລະດັບຄໍາຮ້ອງສະຫມັກ, ຍ້ອນວ່າການທົດແທນ TCP stack ຢ່າງສົມບູນຈະໃຊ້ເວລາ ຕະຫຼອດໄປ.

ເຖິງວ່າຈະມີການສະຫນັບສະຫນູນການ multiplexing ໃນ HTTP / 2, ບັນຫາຂອງການສະກັດກັ້ນຫົວຫນ້າເສັ້ນຍັງຄົງຢູ່ຍ້ອນຄວາມຕ້ອງການທີ່ຈະຈັດສົ່ງແພັກເກັດຕາມລໍາດັບ. QUIC ແມ່ນຖືກປະຕິບັດຢູ່ເທິງ UDP, ດັ່ງນັ້ນມັນບໍ່ມີການຂັດຂວາງໃນຫຼັກການ, ແລະເພື່ອປ້ອງກັນບໍ່ໃຫ້ແພັກເກັດຖືກສູນເສຍຕະຫຼອດໄປ, ພວກມັນຖືກເລກແລະສາມາດບັນຈຸບາງສ່ວນຂອງ "ເພື່ອນບ້ານ", ສະຫນອງການຊ້ໍາຊ້ອນ. ນອກຈາກນັ້ນ, QUIC ແຍກແຖວ monolithic ເຂົ້າໄປໃນຫຼາຍຫົວຂໍ້ສໍາລັບການຮ້ອງຂໍປະເພດຕ່າງໆພາຍໃນການເຊື່ອມຕໍ່ດຽວ. ດັ່ງນັ້ນ, ຖ້າແພັກເກັດສູນເສຍ, ບັນຫາອາດຈະເກີດຂື້ນພຽງແຕ່ຫນຶ່ງຄິວເທົ່ານັ້ນ (ຕົວຢ່າງ, ສໍາລັບການໂອນໄຟລ໌ສະເພາະ):

ການນໍາໃຊ້

ໃນເບື້ອງຕົ້ນ, QUIC ໄດ້ຖືກພັດທະນາພາຍໃນ Google ແລະຖືກປັບແຕ່ງສ່ວນໃຫຍ່ສໍາລັບການນໍາໃຊ້ພາຍໃນບໍລິສັດ. ໃນປີ 2013, ມັນຖືກໂອນໄປຫາ IETF ສໍາລັບມາດຕະຖານ (ທີ່ຍັງຄົງຢູ່), ແລະໃນປັດຈຸບັນທຸກຄົນສາມາດມີສ່ວນຮ່ວມໃນການພັດທະນາອະນຸສັນຍາໂດຍການສະເຫນີສິ່ງທີ່ພວກເຂົາຂາດຫາຍໄປ. ຄະນະປະຕິບັດງານ IETF ຈັດຕັ້ງກອງປະຊຸມປະຈໍາປີໃນໄລຍະທີ່ມາດຕະຖານໃຫມ່ໄດ້ຮັບການອະນຸມັດແລະການປະດິດສ້າງໄດ້ຖືກປຶກສາຫາລື. ການປະຕິບັດ QUIC ນີ້ແມ່ນພິຈາລະນາຕົ້ນຕໍແລະມັນອີງໃສ່ມາດຕະຖານ HTTP / 3 ໄດ້ຮັບການຢັ້ງຢືນ.

ມາຮອດປະຈຸ, ບໍ່ມີການເວົ້າກ່ຽວກັບການລວມ HTTP / 3 ເປັນໂປໂຕຄອນຕົ້ນຕໍ, ເພາະວ່າມັນຍັງບໍ່ແລ້ວແລະເກືອບບໍ່ໄດ້ຮັບການສະຫນັບສະຫນູນ:

ແຕ່ QUIC ສາມາດຖືກປະຕິບັດເປັນການຂົນສົ່ງລະຫວ່າງແອັບພລິເຄຊັນແລະເຊີບເວີ, ເຊິ່ງໄດ້ເຮັດຢ່າງສໍາເລັດຜົນຢູ່ Uber:

ຄໍາເຫັນຂອງ Uber ກ່ຽວກັບການນໍາ QUIC

ເພື່ອສຳເລັດການຝັງ QUIC ແລະປັບປຸງການປະຕິບັດຂອງແອັບພລິເຄຊັນໃນສະພາບແວດລ້ອມການເຊື່ອມຕໍ່ທີ່ບໍ່ດີ, ພວກເຮົາໄດ້ປ່ຽນແທນ stack ເກົ່າ (HTTP/2 over TLS/TCP) ດ້ວຍໂປຣໂຕຄໍ QUIC. ພວກເຮົາໄດ້ໃຊ້ຫ້ອງສະຫມຸດເຄືອຂ່າຍ Cronet ຈາກນັ້ນ ໂຄງການ Chromium, ເຊິ່ງປະກອບດ້ວຍຕົ້ນສະບັບ, ຮຸ່ນ Google ຂອງໂປໂຕຄອນ - gQUIC . ການປະຕິບັດນີ້ຍັງຖືກປັບປຸງຢ່າງຕໍ່ເນື່ອງເພື່ອປະຕິບັດຕາມຂໍ້ກໍານົດ IETF ຫຼ້າສຸດ.

ທໍາອິດພວກເຮົາປະສົມປະສານ Cronet ເຂົ້າໄປໃນແອັບຯ Android ຂອງພວກເຮົາເພື່ອເພີ່ມການສະຫນັບສະຫນູນສໍາລັບ QUIC. ການເຊື່ອມໂຍງໄດ້ຖືກປະຕິບັດໃນລັກສະນະດັ່ງກ່າວເພື່ອຫຼຸດຜ່ອນຄ່າໃຊ້ຈ່າຍໃນການເຄື່ອນຍ້າຍຫຼາຍເທົ່າທີ່ເປັນໄປໄດ້. ແທນທີ່ຈະປ່ຽນແທັບເຄືອຂ່າຍເກົ່າທີ່ໃຊ້ຫ້ອງສະຫມຸດຢ່າງສົມບູນ OkHttp, ພວກເຮົາໄດ້ປະສົມປະສານ Cronet ພາຍໃຕ້ກອບ OkHttp API. ໂດຍການເຮັດການເຊື່ອມໂຍງດ້ວຍວິທີນີ້, ພວກເຮົາຫຼີກເວັ້ນການປ່ຽນແປງການໂທເຄືອຂ່າຍຂອງພວກເຮົາ (ທີ່ຖືກນໍາໃຊ້ໂດຍ ຕິດຕັ້ງຄືນໃ່) ໃນລະດັບ API.

ຄ້າຍ​ຄື​ກັນ​ກັບ​ວິ​ທີ​ການ​ສໍາ​ລັບ​ອຸ​ປະ​ກອນ Android​, ພວກ​ເຮົາ​ໄດ້​ປະ​ຕິ​ບັດ Cronet ເຂົ້າ​ໄປ​ໃນ​ກິດ Uber ໃນ iOS​, ຂັດຂວາງ​ການ​ຈະ​ລາ​ຈອນ HTTP ຈາກ​ເຄືອ​ຂ່າຍ​. APIການນໍາໃຊ້ NSURLProtocol. ສິ່ງທີ່ບໍ່ມີຕົວຕົນນີ້, ສະໜອງໃຫ້ໂດຍມູນນິທິ iOS, ຈັດການກັບຂໍ້ມູນ URL ສະເພາະຂອງໂປຣໂຕຄໍ ແລະຮັບປະກັນວ່າພວກເຮົາສາມາດເຊື່ອມໂຍງ Cronet ເຂົ້າໃນແອັບພລິເຄຊັນ iOS ຂອງພວກເຮົາໄດ້ໂດຍບໍ່ມີຄ່າໃຊ້ຈ່າຍໃນການເຄື່ອນຍ້າຍທີ່ສໍາຄັນ.

ເອົາມາຈາກ ການແປນີ້ ບົດຄວາມ Uber

ໃນ backend ພວກເຂົາຈັບການເຊື່ອມຕໍ່ 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 ໃນຕົວທ່ອງເວັບປົກກະຕິ, ແຕ່ທ່ານສາມາດນໍາໃຊ້ໄດ້ Chromium Canary ແລະແລ່ນມັນດ້ວຍທຸງ --enable-quic, ໄປທີ່ເຊີບເວີຂອງທ່ານຫຼື, ສໍາລັບການຍົກຕົວຢ່າງ, ເວັບໄຊທ໌ quic.rocks ແລະເບິ່ງປະເພດການເຊື່ອມຕໍ່ໃນ Developer Tools:

ແທນທີ່ຈະ HTTP / 3 ມັນຖືກຂຽນ http2+quic/99, ແຕ່ມັນເປັນສິ່ງຈໍາເປັນສິ່ງດຽວກັນ.

ເຕັກໂນໂລຊີອື່ນໆ

• QUIC ຍັງສະຫນັບສະຫນູນ LiteSpeed (ທີ່ເຊື່ອມຕໍ່ກັບ Facebook ຜ່ານ HTTP/3 ທີ່ມີ fanfare ທີ່ຍິ່ງໃຫຍ່) ແລະກ້າວຫນ້າ Caddy. Apache ບໍ່ສາມາດເຮັດມັນໄດ້ເທື່ອ, ແຕ່ວຽກງານກໍາລັງດໍາເນີນຢູ່ swing ເຕັມ.
• 21 ມັງກອນປັບປຸງ ຮ່າງມາດຕະຖານສໍາລັບ WebRTC
• ພຽງແຕ່ມື້ອື່ນ Microsoft ເປີດ ລະຫັດການປະຕິບັດ msquic, ເຊິ່ງບໍ່ແມ່ນຫນ້າທີ່ທັງຫມົດຈາກມາດຕະຖານ IETF ແມ່ນມີຢູ່, ແຕ່ນີ້ແມ່ນຄວາມກ້າວຫນ້າອັນໃຫຍ່ຫຼວງແລ້ວ.

ສະຫລຸບ

ຄວາມສົນໃຈໃນ QUIC ແມ່ນບໍ່ຄົງທີ່, ແຕ່ການຂະຫຍາຍຕົວ, ແລະການເຮັດວຽກແມ່ນກໍາລັງດໍາເນີນເພື່ອໃຫ້ມັນມາດຕະຖານ. ການປະຕິບັດໃຫມ່ຂອງໂປໂຕຄອນຈະປາກົດຂຶ້ນເກືອບທຸກໆເດືອນ, ແລະທຸກໆປີມີຜູ້ພັດທະນາຫຼາຍຂຶ້ນຫມັ້ນໃຈວ່າ QUIC ແມ່ນອະນາຄົດ. ມັນເປັນໄປໄດ້ທີ່ຈະລວມເອົາໂປໂຕຄອນໃນ TCP stack ຮຸ່ນໃນອະນາຄົດ, ຊຶ່ງຫມາຍຄວາມວ່າບໍ່ຊ້າຫຼືຫຼັງຈາກນັ້ນອິນເຕີເນັດທັງຫມົດຈະຍ້າຍໄປທີ່ການເຊື່ອມຕໍ່ທີ່ຫມັ້ນຄົງແລະໄວກວ່າ.

ແລ້ວຕອນນີ້ທ່ານສາມາດຕັ້ງຄ່າການໂຕ້ຕອບ QUIC ສໍາລັບໂຄງສ້າງພື້ນຖານຂອງທ່ານຫຼືແມ້ກະທັ້ງໃຫ້ມັນກັບຕົວທ່ອງເວັບ - ພວກເຂົາທັງຫມົດກໍາລັງວາງແຜນທີ່ຈະເພີ່ມການສະຫນັບສະຫນູນສໍາລັບໂປໂຕຄອນ, ແລະສະຖິຕິທີ່ຫນ້າເສົ້າໃຈກັບ caniuse ຈະກາຍເປັນຄວາມສຸກຫຼາຍ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com