Chrome ເພີ່ມການສະຫນັບສະຫນູນການທົດລອງສໍາລັບ HTTP/3 protocol

ເພື່ອ​ທົດ​ລອງ​ການ​ກໍ່​ສ້າງ​ Chromium Canary ເພີ່ມ ຮອງຮັບ HTTP/3 protocol, ເຊິ່ງປະຕິບັດ add-on ເພື່ອເຮັດໃຫ້ HTTP ເຮັດວຽກຜ່ານ QUIC protocol. ໂປຣໂຕຄໍ QUIC ຕົວຂອງມັນເອງໄດ້ຖືກເພີ່ມເຂົ້າໃນບຣາວເຊີເມື່ອຫ້າປີກ່ອນ ແລະຕັ້ງແຕ່ນັ້ນມາໄດ້ຖືກນໍາໃຊ້ເພື່ອເພີ່ມປະສິດທິພາບການເຮັດວຽກກັບການບໍລິການຂອງ Google. ໃນຂະນະດຽວກັນ, ລຸ້ນ QUIC ຈາກ Google ທີ່ໃຊ້ໃນ Chrome ມີຄວາມແຕກຕ່າງກັນໃນບາງລາຍລະອຽດຈາກເວີຊັນຈາກ ຂໍ້ມູນສະເພາະ IETF, ແຕ່ໃນປັດຈຸບັນການປະຕິບັດໄດ້ຖືກ synchronized.

HTTP/3 ມາດຕະຖານການນໍາໃຊ້ QUIC ເປັນການຂົນສົ່ງສໍາລັບ HTTP/2. ເພື່ອເປີດໃຊ້ HTTP/3 ແລະທາງເລືອກ QUIC ຈາກ 23 ຮ່າງ ຂໍ້ມູນຈໍາເພາະຂອງ IETF ຮຽກຮ້ອງໃຫ້ Chrome ເປີດຕົວດ້ວຍຕົວເລືອກ "-enable-quic -quic-version=h3-23" ແລະຫຼັງຈາກນັ້ນເມື່ອເປີດເວັບໄຊທ໌ທົດສອບ quick.rocks: 4433 ໃນໂຫມດການກວດສອບເຄືອຂ່າຍໃນເຄື່ອງມືນັກພັດທະນາ, ກິດຈະກໍາ HTTP/3 ຈະຖືກສະແດງເປັນ “http/2+quic/99”.

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

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

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

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