Cloudflare ໄດ້ປະຕິບັດໂມດູນເພື່ອສະຫນັບສະຫນູນ HTTP / 3 ໃນ NGINX

ບໍລິສັດ Cloudflare ກະກຽມ ໂມດູນ ເພື່ອສະຫນອງການສະຫນັບສະຫນູນສໍາລັບ HTTP / 3 protocol ໃນ NGINX. ໂມດູນໄດ້ຖືກອອກແບບເປັນສ່ວນເສີມຂອງຫ້ອງສະຫມຸດທີ່ພັດທະນາໂດຍ Cloudflare quiche ດ້ວຍການຈັດຕັ້ງປະຕິບັດໂປຣໂຕຄໍການຂົນສົ່ງ QUIC ແລະ HTTP/3. ລະຫັດ quiche ຖືກຂຽນໄວ້ໃນ Rust, ແຕ່ໂມດູນ NGINX ຕົວຂອງມັນເອງຖືກຂຽນໃນ C ແລະເຂົ້າເຖິງຫ້ອງສະຫມຸດໂດຍໃຊ້ການເຊື່ອມໂຍງແບບເຄື່ອນໄຫວ. ການພັດທະນາ ເປີດ ພາຍໃຕ້ໃບອະນຸຍາດ BSD.

ເພື່ອປະກອບ, ພຽງແຕ່ດາວໂຫລດ patch ເຖິງ nginx 1.16 ແລະ ລະຫັດ quiche libraries, ຫຼັງຈາກນັ້ນສ້າງ nginx ຄືນໃໝ່ດ້ວຍຕົວເລືອກ “—with-http_v3_module —with-quiche=../quiche”. ເມື່ອສ້າງ, ການສະຫນັບສະຫນູນ TLS ຄວນອີງໃສ່ຫ້ອງສະຫມຸດ BoringSSL (“--with-openssl=../quiche/deps/boringssl”), ການນໍາໃຊ້ OpenSSL ຍັງບໍ່ທັນໄດ້ຮັບການສະຫນັບສະຫນູນ. ເພື່ອຍອມຮັບການເຊື່ອມຕໍ່, ທ່ານຈໍາເປັນຕ້ອງເພີ່ມຄໍາສັ່ງຟັງດ້ວຍທຸງ "quic" ກັບການຕັ້ງຄ່າ (ຕົວຢ່າງ, "ຟັງ 443 quic reuseport").

ໃນຊອບແວລູກຄ້າ, ການສະຫນັບສະຫນູນ HTTP/3 ໄດ້ຖືກເພີ່ມເຂົ້າໃນການທົດລອງຂອງ Chrome Canary ແລະຜົນປະໂຫຍດຂອງ curl. ໃນດ້ານເຊີຟເວີ, ຈົນກ່ວາໃນປັດຈຸບັນມັນຈໍາເປັນຕ້ອງໃຊ້ແຍກຕ່າງຫາກ, ຈໍາກັດ ການ​ປະ​ຕິ​ບັດ​ການ​ທົດ​ສອບ​. ຄວາມສາມາດໃນການປະມວນຜົນ HTTP / 3 ໃນ nginx ຈະເຮັດໃຫ້ການໃຊ້ງານຂອງເຊີບເວີງ່າຍຂຶ້ນຫຼາຍດ້ວຍການຮອງຮັບ HTTP/3 ແລະຈະເຮັດໃຫ້ການປະຕິບັດການທົດສອບຂອງໂປໂຕຄອນໃຫມ່ສາມາດເຂົ້າເຖິງໄດ້ຫຼາຍຂຶ້ນ. ການປະກົດຕົວຂອງການສະຫນັບສະຫນູນມາດຕະຖານສໍາລັບ HTTP / 3 ໃນ nginx ຄາດວ່າ ໃນສາຂາ 1.17.x ສໍາລັບ 6-12 ເດືອນ.

ຈື່ໄວ້ວ່າ HTTP/3 ມາດຕະຖານການນໍາໃຊ້ໂປໂຕຄອນ QUIC ເປັນການຂົນສົ່ງສໍາລັບ HTTP/2. ພິທີການ QUIC (ການເຊື່ອມຕໍ່ອິນເຕີເນັດ UDP ດ່ວນ) ໄດ້ຖືກພັດທະນາໂດຍ Google ຕັ້ງແຕ່ປີ 2013 ເປັນທາງເລືອກໃນການລວມ TCP + TLS ສໍາລັບເວັບ, ແກ້ໄຂບັນຫາທີ່ມີການຕັ້ງຄ່າຍາວແລະເວລາການເຈລະຈາສໍາລັບການເຊື່ອມຕໍ່ໃນ TCP ແລະກໍາຈັດຄວາມລ່າຊ້າໃນເວລາທີ່ແພັກເກັດສູນເສຍໃນລະຫວ່າງການໂອນຂໍ້ມູນ. QUIC ແມ່ນສ່ວນຂະຫຍາຍຂອງໂປຣໂຕຄໍ UDP ທີ່ຮອງຮັບການ multiplex ຂອງການເຊື່ອມຕໍ່ຫຼາຍອັນ ແລະໃຫ້ວິທີການເຂົ້າລະຫັດທຽບເທົ່າກັບ TLS/SSL.

ຕົ້ນ​ຕໍ ຄຸນ​ລັກ​ສະ​ນະ QUIC:

• ຄວາມ​ປອດ​ໄພ​ສູງ​ຄ້າຍ​ຄື TLS (ໂດຍ​ສະ​ເພາະ​ແມ່ນ QUIC ໃຫ້​ຄວາມ​ສາ​ມາດ​ໃນ​ການ​ນໍາ​ໃຊ້ TLS ຜ່ານ UDP​)​;
• ການຄວບຄຸມຄວາມສົມບູນຂອງການໄຫຼ, ປ້ອງກັນການສູນເສຍແພັກເກັດ;
• ຄວາມສາມາດໃນການສ້າງຕັ້ງການເຊື່ອມຕໍ່ທັນທີທັນໃດ (0-RTT, ໃນປະມານ 75% ຂອງກໍລະນີຂໍ້ມູນສາມາດສົ່ງໄດ້ທັນທີຫຼັງຈາກການສົ່ງຊຸດການຕິດຕັ້ງການເຊື່ອມຕໍ່) ແລະສະຫນອງການຊັກຊ້າຫນ້ອຍທີ່ສຸດລະຫວ່າງການສົ່ງຄໍາຮ້ອງຂໍແລະການໄດ້ຮັບການຕອບສະຫນອງ (RTT, Round Trip Time);
• ບໍ່ໃຊ້ຕົວເລກລໍາດັບດຽວກັນເມື່ອສົ່ງແພັກເກັດຄືນໃຫມ່, ເຊິ່ງຫຼີກລ່ຽງຄວາມບໍ່ແນ່ນອນໃນການກໍານົດແພັກເກັດທີ່ໄດ້ຮັບແລະກໍາຈັດການຫມົດເວລາ;
• ການສູນເສຍແພັກເກັດສົ່ງຜົນກະທົບຕໍ່ພຽງແຕ່ການຈັດສົ່ງນ້ໍາທີ່ກ່ຽວຂ້ອງກັບມັນແລະບໍ່ຢຸດການຈັດສົ່ງຂໍ້ມູນໃນສາຍນ້ໍາຂະຫນານທີ່ສົ່ງຜ່ານການເຊື່ອມຕໍ່ໃນປະຈຸບັນ;
• ຄຸນສົມບັດການແກ້ໄຂຂໍ້ຜິດພາດທີ່ຫຼຸດຜ່ອນຄວາມລ່າຊ້າເນື່ອງຈາກການສົ່ງຄືນແພັກເກັດທີ່ເສຍໄປ. ການ​ນໍາ​ໃຊ້​ລະ​ຫັດ​ການ​ແກ້​ໄຂ​ຄວາມ​ຜິດ​ພາດ​ພິ​ເສດ​ໃນ​ລະ​ດັບ Packet ເພື່ອ​ຫຼຸດ​ຜ່ອນ​ສະ​ຖາ​ນະ​ການ​ທີ່​ຈໍາ​ເປັນ​ຕ້ອງ​ໄດ້​ຮັບ​ການ​ສົ່ງ​ຄືນ​ຂອງ​ຂໍ້​ມູນ Packet ທີ່​ສູນ​ເສຍ​ໄປ​.
• ຂອບເຂດບລັອກການເຂົ້າລະຫັດລັບແມ່ນສອດຄ່ອງກັບຂອບເຂດຂອງແພັກເກັດ QUIC, ເຊິ່ງຊ່ວຍຫຼຸດຜ່ອນຜົນກະທົບຂອງການສູນເສຍແພັກເກັດຕໍ່ການຖອດລະຫັດເນື້ອຫາຂອງແພັກເກັດຕໍ່ໄປ;
• ບໍ່ມີບັນຫາກັບການຂັດຂວາງແຖວ TCP;
• ສະຫນັບສະຫນູນຕົວລະບຸການເຊື່ອມຕໍ່, ເຊິ່ງຊ່ວຍຫຼຸດຜ່ອນເວລາທີ່ມັນໃຊ້ເວລາເພື່ອສ້າງການເຊື່ອມຕໍ່ຄືນໃຫມ່ສໍາລັບລູກຄ້າມືຖື;
• ຄວາມເປັນໄປໄດ້ຂອງການເຊື່ອມຕໍ່ກ້າວຫນ້າທາງດ້ານກົນໄກການຄວບຄຸມ congestion;
• ໃຊ້ເຕັກນິກການພະຍາກອນການສົ່ງຕໍ່ຕໍ່ທິດທາງເພື່ອຮັບປະກັນວ່າແພັກເກັດຖືກສົ່ງໃນອັດຕາທີ່ດີທີ່ສຸດ, ປ້ອງກັນບໍ່ໃຫ້ພວກມັນກາຍເປັນຄວາມແອອັດແລະເຮັດໃຫ້ເກີດການສູນເສຍແພັກເກັດ;
• ຮັບຮູ້ໄດ້ ການຂະຫຍາຍຕົວ ປະສິດທິພາບແລະອັດຕາການຜ່ານທຽບກັບ TCP. ສໍາລັບການບໍລິການວິດີໂອເຊັ່ນ YouTube, QUIC ໄດ້ຖືກສະແດງໃຫ້ເຫັນເພື່ອຫຼຸດຜ່ອນການປະຕິບັດການປະຕິເສດໃນເວລາທີ່ເບິ່ງວິດີໂອ 30%.

ແຫຼ່ງຂໍ້ມູນ: opennet.ru