Firefox ຄາດວ່າຈະເປີດຕົວສະຫນັບສະຫນູນ HTTP / 3 ໃນທ້າຍເດືອນພຶດສະພາ.

Mozilla ໄດ້ປະກາດຄວາມຕັ້ງໃຈທີ່ຈະເລີ່ມຕົ້ນໃນ HTTP / 3 ແລະ QUIC ດ້ວຍການປ່ອຍ Firefox 88, ກໍານົດສໍາລັບວັນທີ 19 ເດືອນເມສາ (ເບື້ອງຕົ້ນຄາດວ່າຈະປ່ອຍໃນວັນທີ 20 ເດືອນເມສາ, ແຕ່ການຕັດສິນຕາມຕາຕະລາງ, ມັນຈະຖືກຍູ້ຄືນໃນມື້ຫນຶ່ງ). ການສະຫນັບສະຫນູນ HTTP/3 ຈະຖືກເປີດໃຊ້ສໍາລັບຜູ້ໃຊ້ຈໍານວນຫນ້ອຍໆໃນເບື້ອງຕົ້ນແລະ, ການຂັດຂວາງບັນຫາທີ່ບໍ່ຄາດຄິດ, ຈະຖືກເປີດຕົວໃຫ້ກັບທຸກຄົນໃນທ້າຍເດືອນພຶດສະພາ. ໃນການກໍ່ສ້າງໃນຕອນກາງຄືນແລະສະບັບເບຕ້າ, HTTP/3 ຖືກເປີດໃຊ້ໂດຍຄ່າເລີ່ມຕົ້ນໃນທ້າຍເດືອນມີນາ.

ໃຫ້ພວກເຮົາຈື່ວ່າການປະຕິບັດ HTTP / 3 ໃນ Firefox ແມ່ນອີງໃສ່ໂຄງການ neqo ທີ່ພັດທະນາໂດຍ Mozilla, ເຊິ່ງສະຫນອງການປະຕິບັດລູກຄ້າແລະເຄື່ອງແມ່ຂ່າຍສໍາລັບໂປໂຕຄອນ QUIC. ລະຫັດອົງປະກອບສໍາລັບ HTTP/3 ແລະການສະຫນັບສະຫນູນ QUIC ແມ່ນຂຽນໃນ Rust. ເພື່ອຄວບຄຸມວ່າຈະເປີດໃຊ້ HTTP/3, about:config ໃຫ້ທາງເລືອກ “network.http.http3.enabled”. ຈາກຊອບແວລູກຄ້າ, ການສະຫນັບສະຫນູນການທົດລອງ HTTP / 3 ໄດ້ຖືກເພີ່ມເຂົ້າໃນ Chrome ແລະ curl, ແລະສໍາລັບເຄື່ອງແມ່ຂ່າຍມັນມີຢູ່ໃນ nginx, ເຊັ່ນດຽວກັນກັບໃນຮູບແບບຂອງໂມດູນ nginx ແລະເຄື່ອງແມ່ຂ່າຍການທົດສອບຈາກ Cloudflare. ໃນດ້ານເວັບໄຊທ໌, ການສະຫນັບສະຫນູນ HTTP/3 ໄດ້ຖືກສະຫນອງໃຫ້ຢູ່ໃນເຄື່ອງແມ່ຂ່າຍຂອງ Google ແລະ Facebook.

ໂປໂຕຄອນ HTTP/3 ຍັງຢູ່ໃນຂັ້ນຕອນການກໍານົດສະບັບຮ່າງ ແລະຍັງບໍ່ທັນໄດ້ມາດຕະຖານຢ່າງເຕັມສ່ວນໂດຍ IETF. HTTP/3 ຕ້ອງການການຊ່ວຍເຫຼືອລູກຄ້າ ແລະເຊີບເວີສຳລັບສະບັບດຽວກັນຂອງມາດຕະຖານຮ່າງ QUIC ແລະ HTTP/3, ເຊິ່ງລະບຸໄວ້ໃນສ່ວນຫົວ Alt-Svc (Firefox ຮອງຮັບ spec ສະບັບຮ່າງ 27 ຫາ 32).

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

ຄຸນ​ນະ​ສົມ​ບັດ​ທີ່​ສໍາ​ຄັນ​ຂອງ QUIC​:

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

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