Microsoft ໄດ້ເປີດການຈັດຕັ້ງປະຕິບັດໂປຣໂຕຄໍ QUIC ທີ່ໃຊ້ໃນ HTTP/3

ບໍລິສັດ Microsoft ປະ​ກາດ ກ່ຽວກັບການເປີດລະຫັດຫ້ອງສະຫມຸດ ນາງ MsQuic ກັບການປະຕິບັດຂອງໂປໂຕຄອນເຄືອຂ່າຍ QUIC. ລະຫັດແມ່ນຂຽນໃນ C ແລະ ແຈກຢາຍໂດຍ ພາຍໃຕ້ໃບອະນຸຍາດ MIT. ຫ້ອງສະຫມຸດແມ່ນຂ້າມເວທີແລະສາມາດນໍາໃຊ້ບໍ່ພຽງແຕ່ໃນ Windows, ແຕ່ຍັງໃຊ້ Linux ຊ່ອງ ຫຼື OpenSSL ສໍາລັບ TLS 1.3. ໃນອະນາຄົດ, ມັນໄດ້ຖືກວາງແຜນທີ່ຈະສະຫນັບສະຫນູນເວທີອື່ນໆ.

ຫ້ອງສະຫມຸດແມ່ນອີງໃສ່ລະຫັດໄດເວີ msquic.sys ທີ່ສະຫນອງໃຫ້ຢູ່ໃນ Windows 10 kernel (Insider Preview) ເພື່ອເປີດໃຊ້ HTTP ແລະ SMB ຢູ່ເທິງສຸດຂອງ QUIC. ລະຫັດຍັງຖືກນໍາໃຊ້ເພື່ອປະຕິບັດ HTTP/3 ໃນ stack Windows ພາຍໃນແລະໃນ .NET Core. ການພັດທະນາຫ້ອງສະຫມຸດ MsQuic ຈະດໍາເນີນການທັງຫມົດໃນ GitHub ໂດຍໃຊ້ການທົບທວນຄືນ peer ສາທາລະນະ, ດຶງຄໍາຮ້ອງຂໍ, ແລະບັນຫາ GitHub. ໂຄງສ້າງພື້ນຖານໄດ້ຖືກກະກຽມທີ່ກວດສອບທຸກໆຄໍາຫມັ້ນສັນຍາແລະດຶງຄໍາຮ້ອງຂໍໃນຊຸດຂອງຫຼາຍກວ່າ 4000 ການທົດສອບ. ຫຼັງຈາກສະຖຽນລະພາບຂອງສະພາບແວດລ້ອມການພັດທະນາ, ມັນໄດ້ຖືກວາງແຜນທີ່ຈະຍອມຮັບການປ່ຽນແປງຈາກຜູ້ພັດທະນາພາກສ່ວນທີສາມ.

MsQuic ສາມາດຖືກນໍາໃຊ້ເພື່ອສ້າງເຄື່ອງແມ່ຂ່າຍແລະລູກຄ້າ, ແຕ່ບໍ່ແມ່ນທຸກຫນ້າທີ່ກໍານົດໄວ້ໃນຂໍ້ກໍານົດ IETF ໃນປະຈຸບັນ. ຕົວຢ່າງ, ບໍ່ມີການສະຫນັບສະຫນູນ 0-RTT, ການເຄື່ອນຍ້າຍລູກຄ້າ, Path MTU Discovery, ຫຼືການຄວບຄຸມທີ່ຢູ່ທີ່ຕ້ອງການຂອງເຄື່ອງແມ່ຂ່າຍ. ໃນບັນດາລັກສະນະທີ່ຖືກປະຕິບັດ, ການເພີ່ມປະສິດທິພາບແມ່ນສັງເກດເຫັນວ່າບັນລຸການສົ່ງຜ່ານສູງສຸດແລະຄວາມລ່າຊ້າຕໍ່າສຸດ, ການສະຫນັບສະຫນູນການປ້ອນຂໍ້ມູນ / ຜົນຜະລິດແບບ asynchronous, RSS (Receive Scaling), ແລະຄວາມສາມາດໃນການສົມທົບການປ້ອນຂໍ້ມູນແລະຜົນຜະລິດ UDP streams. ການປະຕິບັດ MsQuic ໄດ້ຮັບການທົດສອບຄວາມເຂົ້າກັນໄດ້ກັບຕົວທ່ອງເວັບ Chrome ແລະ Edge ລຸ້ນທົດລອງ.

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

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

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

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

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