ອະນຸສັນຍາ QUIC ໄດ້ຮັບສະຖານະຂອງມາດຕະຖານທີ່ສະເໜີໃຫ້.

ໜ່ວຍງານວິສະວະກຳອິນເຕີເນັດ (IETF), ເຊິ່ງຮັບຜິດຊອບການພັດທະນາໂປຣໂຕຄໍ ແລະສະຖາປັດຕະຍະກຳອິນເຕີເນັດ, ໄດ້ສະຫຼຸບ RFC ສຳລັບໂປຣໂຕຄໍ QUIC ແລະ ເຜີຍແຜ່ຂໍ້ມູນສະເພາະທີ່ກ່ຽວຂ້ອງພາຍໃຕ້ຕົວລະບຸ RFC 8999 (ຄຸນສົມບັດໂປຣໂຕຄໍລຸ້ນເອກະລາດ), RFC 9000 (ການຂົນສົ່ງ. ຫຼາຍກວ່າ UDP), RFC 9001 (ການເຂົ້າລະຫັດ TLS ຂອງຊ່ອງທາງການສື່ສານ QUIC) ແລະ RFC 9002 (ການຄວບຄຸມຄວາມແອອັດ ແລະການກວດສອບການສູນເສຍແພັກເກັດໃນລະຫວ່າງການສົ່ງຂໍ້ມູນ).

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

ຄາດວ່າການກໍານົດມາດຕະຖານຂອງ QUIC ຈະຊຸກຍູ້ໃຫ້ມີການຮັບຮອງເອົາອະນຸສັນຍານີ້ຢ່າງກວ້າງຂວາງ, ເຊັ່ນດຽວກັນກັບການພັດທະນາການຂະຫຍາຍໂດຍອີງໃສ່ມັນ, ເຊັ່ນ: WebTransport (ເຕັກໂນໂລຢີສໍາລັບການສົ່ງແລະຮັບຂໍ້ມູນລະຫວ່າງຕົວທ່ອງເວັບແລະເຄື່ອງແມ່ຂ່າຍ) ແລະ MASQUE. (ເຕັກ​ໂນ​ໂລ​ຊີ​ຕົວ​ແທນ​ການ​ເຊື່ອມ​ຕໍ່​ທີ່​ຂະ​ຫຍາຍ​ຄວາມ​ສາ​ມາດ​ຂອງ SOCKS ແລະ HTTP CONNECT, ແລະ​ການ​ນໍາ​ໃຊ້ HTTPS ຜ່ານ QUIC ເປັນ​ການ​ຂົນ​ສົ່ງ).

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

ຄຸນ​ນະ​ສົມ​ບັດ​ທີ່​ສໍາ​ຄັນ​ຂອງ 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