ໂປຣໂຕຄໍ QUIC ໃນການປະຕິບັດ: ວິທີການ Uber ປະຕິບັດມັນເພື່ອເພີ່ມປະສິດທິພາບການປະຕິບັດ

ໂປຣໂຕຄໍ QUIC ເປັນທີ່ໜ້າສົນໃຈທີ່ສຸດທີ່ຈະເບິ່ງ, ເຊິ່ງເປັນເຫດຜົນທີ່ພວກເຮົາມັກຂຽນກ່ຽວກັບມັນ. ແຕ່ຖ້າສິ່ງພິມທີ່ຜ່ານມາກ່ຽວກັບ QUIC ເປັນປະຫວັດສາດຫຼາຍກວ່າ (ປະຫວັດສາດທ້ອງຖິ່ນ, ຖ້າທ່ານຕ້ອງການ) ທໍາມະຊາດແລະຮາດແວ, ມື້ນີ້ພວກເຮົາມີຄວາມຍິນດີທີ່ຈະເຜີຍແຜ່ການແປປະເພດທີ່ແຕກຕ່າງກັນ - ພວກເຮົາຈະເວົ້າກ່ຽວກັບການນໍາໃຊ້ທີ່ແທ້ຈິງຂອງໂປໂຕຄອນໃນປີ 2019. ຍິ່ງໄປກວ່ານັ້ນ, ພວກເຮົາບໍ່ໄດ້ເວົ້າກ່ຽວກັບໂຄງສ້າງພື້ນຖານຂະຫນາດນ້ອຍຢູ່ໃນບ່ອນຈອດລົດທີ່ເອີ້ນວ່າ Uber, ເຊິ່ງດໍາເນີນການເກືອບທົ່ວໂລກ. ວິ​ສະ​ວະ​ກອນ​ຂອງ​ບໍ​ລິ​ສັດ​ມາ​ເຖິງ​ການ​ຕັດ​ສິນ​ໃຈ​ທີ່​ຈະ​ນໍາ​ໃຊ້ QUIC ໃນ​ການ​ຜະ​ລິດ​, ວິ​ທີ​ການ​ທີ່​ເຂົາ​ເຈົ້າ​ດໍາ​ເນີນ​ການ​ທົດ​ສອບ​ແລະ​ສິ່ງ​ທີ່​ເຂົາ​ເຈົ້າ​ໄດ້​ເຫັນ​ຫຼັງ​ຈາກ​ການ​ມ້ວນ​ມັນ​ອອກ​ໃນ​ການ​ຜະ​ລິດ - ຂ້າງ​ລຸ່ມ​ນີ້​ການ​ຕັດ​.

ຮູບ​ພາບ​ແມ່ນ​ສາ​ມາດ​ຄລິກ​ໃສ່​. ມ່ວນກັບການອ່ານ!

Uber ມີຂະຫນາດທົ່ວໂລກ, ຄື 600 ເມືອງທີ່ມີ, ໃນແຕ່ລະຄໍາຮ້ອງສະຫມັກແມ່ນອີງໃສ່ອິນເຕີເນັດໄຮ້ສາຍທັງຫມົດຈາກຫຼາຍກ່ວາ 4500 ຜູ້ໃຫ້ບໍລິການໂທລະສັບມືຖື. ຜູ້ໃຊ້ຄາດຫວັງວ່າ app ບໍ່ພຽງແຕ່ໄວ, ແຕ່ໃນເວລາທີ່ແທ້ຈິງ - ເພື່ອບັນລຸເປົ້າຫມາຍນີ້, ແອັບຯ Uber ຕ້ອງການຄວາມລ່າຊ້າຕ່ໍາແລະການເຊື່ອມຕໍ່ທີ່ເຊື່ອຖືໄດ້ຫຼາຍ. ອະນິຈາ, ແຕ່ stack ໄດ້ HTTP / 2 ບໍ່ເຮັດໄດ້ດີໃນເຄືອຂ່າຍໄຮ້ສາຍແບບເຄື່ອນໄຫວ ແລະການສູນເສຍງ່າຍ. ພວກເຮົາຮັບຮູ້ວ່າໃນກໍລະນີນີ້, ການປະຕິບັດທີ່ບໍ່ດີແມ່ນກ່ຽວຂ້ອງໂດຍກົງກັບການປະຕິບັດ TCP ໃນແກ່ນຂອງລະບົບປະຕິບັດການ.

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

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

ໃນບົດຄວາມນີ້, ພວກເຮົາແບ່ງປັນປະສົບການຂອງພວກເຮົາໃນການເພີ່ມປະສິດທິພາບ TCP ສໍາລັບຄໍາຮ້ອງສະຫມັກ Uber ໂດຍໃຊ້ stack ທີ່ສະຫນັບສະຫນູນ QUIC.

ເຕັກໂນໂລຊີຫລ້າສຸດ: TCP

ມື້ນີ້, TCP ແມ່ນໂປໂຕຄອນການຂົນສົ່ງທີ່ໃຊ້ຫຼາຍທີ່ສຸດສໍາລັບການສົ່ງການຈະລາຈອນ HTTPS ໃນອິນເຕີເນັດ. TCP ສະຫນອງການນ້ໍາທີ່ເຊື່ອຖືໄດ້ຂອງ bytes, ດັ່ງນັ້ນການຮັບມືກັບຄວາມແອອັດຂອງເຄືອຂ່າຍແລະການສູນເສຍຊັ້ນເຊື່ອມຕໍ່. ການນໍາໃຊ້ຢ່າງກວ້າງຂວາງຂອງ TCP ສໍາລັບການຈະລາຈອນ HTTPS ແມ່ນເນື່ອງມາຈາກສະຖານທີ່ຂອງອະດີດ (ເກືອບທຸກ OS ປະກອບດ້ວຍ TCP), ມີຢູ່ໃນພື້ນຖານໂຄງລ່າງສ່ວນໃຫຍ່ (ເຊັ່ນ: load balancers, HTTPS proxies ແລະ CDNs), ແລະການທໍາງານນອກກ່ອງທີ່ມີຢູ່. ໃນເກືອບທຸກເວທີ ແລະເຄືອຂ່າຍ.

ຜູ້ໃຊ້ສ່ວນໃຫຍ່ໃຊ້ app ຂອງພວກເຮົາໃນເວລາເດີນທາງ, ແລະ TCP ຫາງ latencies ບໍ່ມີບ່ອນໃດຢູ່ໃກ້ກັບຄວາມຕ້ອງການຂອງການຈະລາຈອນ HTTPS ຂອງພວກເຮົາໃນເວລາຈິງ. ເວົ້າງ່າຍໆ, ຜູ້ໃຊ້ທົ່ວໂລກໄດ້ປະສົບກັບສິ່ງນີ້ - ຮູບທີ 1 ສະແດງໃຫ້ເຫັນຄວາມລ່າຊ້າໃນຕົວເມືອງໃຫຍ່:

ຮູບທີ 1: ຄວາມຢືດຢຸ່ນຂອງຫາງແຕກຕ່າງກັນໄປທົ່ວເມືອງຫຼັກຂອງ Uber.

ເຖິງແມ່ນວ່າເວລາ latency ໃນເຄືອຂ່າຍອິນເດຍແລະ Brazilian ແມ່ນສູງກວ່າໃນສະຫະລັດແລະອັງກິດ, ການ latency ຫາງແມ່ນສູງກ່ວາ latency ສະເລ່ຍຢ່າງຫຼວງຫຼາຍ. ແລະນີ້ແມ່ນຄວາມຈິງເຖິງແມ່ນວ່າສໍາລັບສະຫະລັດແລະອັງກິດ.

TCP ໃນໄລຍະການປະຕິບັດທາງອາກາດ

TCP ຖືກສ້າງຂຶ້ນສໍາລັບ ມີສາຍ ເຄືອຂ່າຍ, ນັ້ນແມ່ນ, ໂດຍເນັ້ນໃສ່ການເຊື່ອມຕໍ່ທີ່ຄາດເດົາໄດ້ສູງ. ແນວໃດກໍ່ຕາມ, ໄຮ້ສາຍ ເຄືອຂ່າຍມີລັກສະນະຂອງຕົນເອງແລະຄວາມຫຍຸ້ງຍາກ. ຫນ້າທໍາອິດ, ເຄືອຂ່າຍໄຮ້ສາຍແມ່ນມີຄວາມອ່ອນໄຫວຕໍ່ກັບການສູນເສຍເນື່ອງຈາກການແຊກແຊງແລະການຫຼຸດຜ່ອນສັນຍານ. ສໍາລັບຕົວຢ່າງ, ເຄືອຂ່າຍ Wi-Fi ມີຄວາມອ່ອນໄຫວຕໍ່ກັບໄມໂຄເວຟ, bluetooth ແລະຄື້ນວິທະຍຸອື່ນໆ. ເຄືອຂ່າຍໂທລະສັບມືຖືທົນທຸກຈາກການສູນເສຍສັນຍານ (ເສັ້ນທາງສູນເສຍ) ເນື່ອງຈາກການສະທ້ອນ / ການດູດຊຶມຂອງສັນຍານໂດຍວັດຖຸແລະອາຄານ, ເຊັ່ນດຽວກັນກັບຈາກ ແຊກແຊງ ຈາກ​ເພື່ອນ​ບ້ານ towers ຫ້ອງ. ນີ້ນໍາໄປສູ່ຄວາມສໍາຄັນຫຼາຍ (4-10 ເທື່ອ) ແລະມີຄວາມຫຼາກຫຼາຍຫຼາຍ ເວລາໄປກັບ (RTT) ແລະການສູນເສຍແພັກເກັດທຽບກັບການເຊື່ອມຕໍ່ແບບມີສາຍ.

ເພື່ອຕໍ່ສູ້ກັບການເໜັງຕີງ ແລະການສູນເສຍແບນວິດ, ເຄືອຂ່າຍໂທລະສັບມືຖືໂດຍປົກກະຕິຈະໃຊ້ buffers ຂະໜາດໃຫຍ່ສຳລັບການເກີດການຈາລະຈອນ. ນີ້ສາມາດນໍາໄປສູ່ການຈັດແຖວຫຼາຍເກີນໄປ, ຊຶ່ງຫມາຍຄວາມວ່າການຊັກຊ້າຕໍ່ໄປອີກແລ້ວ. ເລື້ອຍໆ TCP ປະຕິບັດຕໍ່ການຈັດແຖວນີ້ເປັນສິ່ງເສດເຫຼືອອັນເນື່ອງມາຈາກການໝົດເວລາທີ່ຂະຫຍາຍອອກໄປ, ດັ່ງນັ້ນ TCP ມັກຈະສົ່ງຕໍ່ ແລະເຮັດແນວນັ້ນຈຶ່ງຕື່ມຂໍ້ມູນໃສ່ buffer. ບັນຫານີ້ແມ່ນເອີ້ນວ່າ bufferbloat (buffering ເຄືອຂ່າຍຫຼາຍເກີນໄປ, buffer bloat), ແລະນີ້ແມ່ນຫຼາຍ ບັນຫາຮ້າຍແຮງ ອິນ​ເຕີ​ເນັດ​ທີ່​ທັນ​ສະ​ໄຫມ​.

ສຸດທ້າຍ, ປະສິດທິພາບເຄືອຂ່າຍມືຖືແຕກຕ່າງກັນໄປຕາມຜູ້ໃຫ້ບໍລິການ, ພາກພື້ນ ແລະເວລາ. ໃນຮູບທີ 2, ພວກເຮົາໄດ້ເກັບກໍາຄວາມລ່າຊ້າສະເລ່ຍຂອງການຈະລາຈອນ HTTPS ໃນທົ່ວເຊລພາຍໃນຂອບເຂດ 2 ກິໂລແມັດ. ຂໍ້​ມູນ​ເກັບ​ກໍາ​ຂໍ້​ມູນ​ສໍາ​ລັບ​ສອງ​ປະ​ຕິ​ບັດ​ການ​ໂທລະ​ສັບ​ມື​ຖື​ທີ່​ສໍາ​ຄັນ​ໃນ Delhi​, ປະ​ເທດ​ອິນ​ເດຍ​. ດັ່ງທີ່ເຈົ້າສາມາດເຫັນໄດ້, ປະສິດທິພາບແຕກຕ່າງກັນໄປຈາກແຕ່ລະຫ້ອງ. ນອກຈາກນີ້, ຜົນຜະລິດຂອງຜູ້ປະກອບການຫນຶ່ງແຕກຕ່າງຈາກຜົນຜະລິດຂອງສອງ. ນີ້ແມ່ນອິດທິພົນຈາກປັດໃຈເຊັ່ນ: ຮູບແບບການເຂົ້າເຄືອຂ່າຍທີ່ຄໍານຶງເຖິງເວລາແລະສະຖານທີ່, ການເຄື່ອນຍ້າຍຂອງຜູ້ໃຊ້, ເຊັ່ນດຽວກັນກັບໂຄງສ້າງເຄືອຂ່າຍທີ່ຄໍານຶງເຖິງຄວາມຫນາແຫນ້ນຂອງ tower ແລະອັດຕາສ່ວນຂອງປະເພດເຄືອຂ່າຍ (LTE, 3G, ແລະອື່ນໆ).

ຮູບທີ 2. ການຊັກຊ້າໂດຍໃຊ້ລັດສະໝີ 2 ກິໂລແມັດເປັນຕົວຢ່າງ. ເດລີ, ອິນເດຍ.

ນອກຈາກນີ້, ການປະຕິບັດຂອງເຄືອຂ່າຍໂທລະສັບມືຖືແຕກຕ່າງກັນໄປຕາມເວລາ. ຮູບທີ 3 ສະແດງໃຫ້ເຫັນການຕອບສະໜອງປານກາງໂດຍມື້ຂອງອາທິດ. ພວກເຮົາຍັງໄດ້ສັງເກດເຫັນຄວາມແຕກຕ່າງໃນລະດັບຂະຫນາດນ້ອຍກວ່າ, ພາຍໃນມື້ດຽວແລະຊົ່ວໂມງ.

ຮູບ 3. ການຊັກຊ້າຫາງສາມາດແຕກຕ່າງກັນຢ່າງຫຼວງຫຼາຍລະຫວ່າງມື້, ແຕ່ສໍາລັບຜູ້ປະກອບການດຽວກັນ.

ທັງຫມົດຂ້າງເທິງນີ້ເຮັດໃຫ້ການປະຕິບັດ TCP ບໍ່ມີປະສິດທິພາບໃນເຄືອຂ່າຍໄຮ້ສາຍ. ຢ່າງໃດກໍຕາມ, ກ່ອນທີ່ຈະຊອກຫາທາງເລືອກສໍາລັບ TCP, ພວກເຮົາຕ້ອງການທີ່ຈະພັດທະນາຄວາມເຂົ້າໃຈທີ່ຊັດເຈນກ່ຽວກັບຈຸດຕໍ່ໄປນີ້:

• TCP ແມ່ນຜູ້ກະທໍາຜິດຕົ້ນຕໍທີ່ຢູ່ເບື້ອງຫລັງ latencies ຫາງໃນຄໍາຮ້ອງສະຫມັກຂອງພວກເຮົາບໍ?
• ເຄືອຂ່າຍທີ່ທັນສະໄຫມມີຄວາມລ່າຊ້າໄປກັບ (RTT) ທີ່ສໍາຄັນແລະແຕກຕ່າງກັນບໍ?
• ຜົນກະທົບຂອງ RTT ແລະການສູນເສຍຕໍ່ການປະຕິບັດ TCP ແມ່ນຫຍັງ?

ການວິເຄາະປະສິດທິພາບ TCP

ເພື່ອເຂົ້າໃຈວິທີທີ່ພວກເຮົາວິເຄາະການປະຕິບັດ TCP, ໃຫ້ພວກເຮົາເບິ່ງໄວໆກ່ຽວກັບວິທີການ TCP ໂອນຂໍ້ມູນຈາກຜູ້ສົ່ງໄປຫາຜູ້ຮັບ. ຫນ້າທໍາອິດ, ຜູ້ສົ່ງສ້າງຕັ້ງການເຊື່ອມຕໍ່ TCP, ປະຕິບັດສາມທາງ ຈັບມື: ຜູ້ສົ່ງຈະສົ່ງແພັກເກັດ SYN, ລໍຖ້າແພັກເກັດ SYN-ACK ຈາກຜູ້ຮັບ, ຫຼັງຈາກນັ້ນສົ່ງແພັກເກັດ ACK. ການເພີ່ມເຕີມທີສອງແລະທີສາມແມ່ນໃຊ້ເວລາໃນການສ້າງການເຊື່ອມຕໍ່ TCP. ຜູ້ຮັບຮັບຮູ້ການຮັບແຕ່ລະຊອງ (ACK) ເພື່ອຮັບປະກັນການຈັດສົ່ງທີ່ເຊື່ອຖືໄດ້.

ຖ້າແພັກເກັດຫຼື ACK ຫາຍໄປ, ຜູ້ສົ່ງຈະສົ່ງຄືນຫຼັງຈາກຫມົດເວລາ (RTO, ໝົດເວລາການສົ່ງຕໍ່). RTO ຖືກຄິດໄລ່ແບບເຄື່ອນໄຫວໂດຍອີງໃສ່ປັດໃຈຕ່າງໆ, ເຊັ່ນຄວາມລ່າຊ້າ RTT ທີ່ຄາດວ່າຈະລະຫວ່າງຜູ້ສົ່ງແລະຜູ້ຮັບ.

ຮູບທີ 4. ການແລກປ່ຽນແພັກເກັດໃນໄລຍະ TCP/TLS ປະກອບມີກົນໄກການສົ່ງຄືນ.

ເພື່ອກໍານົດວິທີການປະຕິບັດ TCP ໃນຄໍາຮ້ອງສະຫມັກຂອງພວກເຮົາ, ພວກເຮົາໄດ້ຕິດຕາມຊຸດ TCP ໂດຍໃຊ້ tcpdump ສໍາລັບຫນຶ່ງອາທິດກ່ຽວກັບການຈະລາຈອນການຕໍ່ສູ້ທີ່ມາຈາກເຄື່ອງແມ່ຂ່າຍຂອບຂອງອິນເດຍ. ຫຼັງຈາກນັ້ນ, ພວກເຮົາວິເຄາະການເຊື່ອມຕໍ່ TCP ໂດຍໃຊ້ tcptrac. ນອກຈາກນັ້ນ, ພວກເຮົາໄດ້ສ້າງແອັບພລິເຄຊັນ Android ທີ່ສົ່ງການຈາລະຈອນແບບຈຳລອງໄປຫາເຊີບເວີທົດສອບ, ລຽນແບບການຈາລະຈອນຕົວຈິງໃຫ້ຫຼາຍເທົ່າທີ່ເປັນໄປໄດ້. ໂທລະສັບສະມາດໂຟນທີ່ມີແອັບພລິເຄຊັນນີ້ໄດ້ຖືກແຈກຢາຍໃຫ້ພະນັກງານຫຼາຍຄົນ, ຜູ້ທີ່ເກັບກໍາຂໍ້ມູນບັນທຶກໃນໄລຍະເວລາຫຼາຍມື້.

ຜົນໄດ້ຮັບຂອງການທົດລອງທັງສອງແມ່ນສອດຄ່ອງກັນ. ພວກເຮົາໄດ້ເຫັນ latencies RTT ສູງ; ຄ່າຫາງແມ່ນເກືອບ 6 ເທົ່າຂອງຄ່າສະເລ່ຍ; ຕົວເລກສະເລ່ຍຂອງການຊັກຊ້າແມ່ນຫຼາຍກວ່າ 1 ວິນາທີ. ການເຊື່ອມຕໍ່ຈໍານວນຫຼາຍໄດ້ສູນເສຍ, ເຮັດໃຫ້ TCP ສົ່ງຄືນໃຫມ່ 3,5% ຂອງແພັກເກັດທັງຫມົດ. ໃນເຂດທີ່ແອອັດເຊັ່ນ: ສະຫນາມບິນແລະສະຖານີລົດໄຟ, ພວກເຮົາໄດ້ສູນເສຍ 7%. ຜົນໄດ້ຮັບເຫຼົ່ານີ້ເຮັດໃຫ້ຄວາມສົງໃສໃນປັນຍາທໍາມະດາທີ່ຖືກນໍາໃຊ້ໃນເຄືອຂ່າຍໂທລະສັບມືຖື ວົງຈອນ retransmission ຂັ້ນສູງ ຫຼຸດຜ່ອນການສູນເສຍຢ່າງຫຼວງຫຼາຍໃນລະດັບການຂົນສົ່ງ. ຂ້າງລຸ່ມນີ້ແມ່ນຜົນການທົດສອບຈາກຄໍາຮ້ອງສະຫມັກ "simulator":

ການວັດແທກເຄືອຂ່າຍ
ຄຸນຄ່າ

RTT, ມິນລິວິນາທີ [50%, 75%, 95%, 99%]
[350, 425, 725, 2300]

ຄວາມແຕກຕ່າງຂອງ RTT, ວິນາທີ
ໂດຍສະເລ່ຍ ~1,2 ວິນາທີ

ການສູນເສຍແພັກເກັດໃນການເຊື່ອມຕໍ່ທີ່ບໍ່ຫມັ້ນຄົງ
ສະເລ່ຍ ~3.5% (7% ໃນເຂດທີ່ມີການໂຫຼດເກີນ)

ເກືອບເຄິ່ງຫນຶ່ງຂອງການເຊື່ອມຕໍ່ເຫຼົ່ານີ້ມີການສູນເສຍຢ່າງຫນ້ອຍຫນຶ່ງແພັກເກັດ, ສ່ວນຫຼາຍແມ່ນແພັກເກັດ SYN ແລະ SYN-ACK. ການປະຕິບັດ TCP ສ່ວນໃຫຍ່ໃຊ້ຄ່າ RTO 1 ວິນາທີສໍາລັບແພັກເກັດ SYN, ເຊິ່ງເພີ່ມຂຶ້ນເປັນຕົວເລກສໍາລັບການສູນເສຍຕໍ່ມາ. ເວລາໂຫຼດແອັບພລິເຄຊັນອາດຈະເພີ່ມຂຶ້ນເນື່ອງຈາກ TCP ໃຊ້ເວລາດົນກວ່າໃນການສ້າງການເຊື່ອມຕໍ່.

ໃນກໍລະນີຂອງຊຸດຂໍ້ມູນ, ມູນຄ່າ RTO ສູງຫຼຸດລົງຢ່າງຫຼວງຫຼາຍໃນການນໍາໃຊ້ທີ່ເປັນປະໂຫຍດຂອງເຄືອຂ່າຍໃນເວລາທີ່ມີການສູນເສຍຊົ່ວຄາວໃນເຄືອຂ່າຍໄຮ້ສາຍ. ພວກ​ເຮົາ​ໄດ້​ພົບ​ເຫັນ​ວ່າ​ເວ​ລາ retransmission ໂດຍ​ສະ​ເລ່ຍ​ແມ່ນ​ປະ​ມານ 1 ວິ​ນາ​ທີ​ທີ່​ມີ​ຄວາມ​ຊັກ​ຊ້າ​ຫາງ​ເກືອບ 30 ວິ​ນາ​ທີ​. latencies ສູງເຫຼົ່ານີ້ຢູ່ໃນລະດັບ TCP ເຮັດໃຫ້ເກີດການຫມົດເວລາ HTTPS ແລະການຮ້ອງຂໍຄືນໃຫມ່, ເພີ່ມຄວາມລ່າຊ້າຂອງເຄືອຂ່າຍແລະຄວາມບໍ່ມີປະສິດທິພາບ.

ໃນຂະນະທີ່ເປີເຊັນທີ 75 ຂອງການວັດແທກ RTT ແມ່ນປະມານ 425 ms, ເປີເຊັນທີ 75 ສໍາລັບ TCP ແມ່ນເກືອບ 3 ວິນາທີ. ນີ້ຊີ້ໃຫ້ເຫັນວ່າການສູນເສຍເຮັດໃຫ້ TCP ໃຊ້ເວລາ 7-10 passes ເພື່ອສົ່ງຂໍ້ມູນສົບຜົນສໍາເລັດ. ນີ້ອາດຈະເປັນຜົນມາຈາກການຄິດໄລ່ RTO ທີ່ບໍ່ມີປະສິດທິພາບ, ຄວາມບໍ່ສາມາດຂອງ TCP ເພື່ອຕອບສະຫນອງການສູນເສຍຢ່າງໄວວາ. ແພັກເກດຫຼ້າສຸດ ຢູ່ໃນປ່ອງຢ້ຽມແລະຄວາມບໍ່ມີປະສິດທິພາບຂອງລະບົບການຄວບຄຸມ congestion algorithm, ເຊິ່ງບໍ່ໄດ້ຈໍາແນກລະຫວ່າງການສູນເສຍໄຮ້ສາຍແລະການສູນເສຍເນື່ອງຈາກຄວາມແອອັດຂອງເຄືອຂ່າຍ. ຂ້າງລຸ່ມນີ້ແມ່ນຜົນຂອງການທົດສອບການສູນເສຍ TCP:

ສະຖິຕິການສູນເສຍແພັກເກັດ TCP
ມູນຄ່າ

ເປີເຊັນຂອງການເຊື່ອມຕໍ່ທີ່ມີການສູນເສຍແພັກເກັດຢ່າງຫນ້ອຍ 1
45%

ເປີເຊັນຂອງການເຊື່ອມຕໍ່ກັບການສູນເສຍໃນລະຫວ່າງການຕິດຕັ້ງການເຊື່ອມຕໍ່
30%

ເປີເຊັນຂອງການເຊື່ອມຕໍ່ກັບການສູນເສຍໃນລະຫວ່າງການແລກປ່ຽນຂໍ້ມູນ
76%

ການແຜ່ກະຈາຍຄວາມລ່າຊ້າໃນ retransmission, ວິນາທີ [50%, 75%, 95%, 99%] [1, 2.8, 15, 28]

ການແຈກຢາຍຈໍານວນຂອງ retransmissions ສໍາລັບຫນຶ່ງ packet ຫຼື TCP segment
[1,3,6,7]

ຄໍາຮ້ອງສະຫມັກຂອງ QUIC

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

ຮູບທີ 5: QUIC ແລ່ນພາຍໃຕ້ HTTP/3, ແທນທີ່ TLS, ເຊິ່ງຜ່ານມາແລ່ນພາຍໃຕ້ HTTP/2.

ຂ້າງລຸ່ມນີ້ແມ່ນເຫດຜົນທີ່ເຮັດໃຫ້ພວກເຮົາໃຊ້ QUIC ສໍາລັບການຂະຫຍາຍ TCP:

• ການສ້າງຕັ້ງການເຊື່ອມຕໍ່ 0-RTT. QUIC ອະນຸຍາດໃຫ້ນໍາໃຊ້ຄືນໃຫມ່ຂອງການອະນຸຍາດຈາກການເຊື່ອມຕໍ່ທີ່ຜ່ານມາ, ຫຼຸດຜ່ອນຈໍານວນຂອງການຈັບມືຄວາມປອດໄພ. ໃນອະນາຄົດ ອຈ S TLS1.3 ຈະຮອງຮັບ 0-RTT, ແຕ່ການຈັບມື TCP ສາມທາງຈະຍັງຕ້ອງການ.
• ເອົາຊະນະການຂັດຂວາງ HoL. HTTP/2 ໃຊ້ການເຊື່ອມຕໍ່ TCP ຫນຶ່ງຕໍ່ລູກຄ້າເພື່ອປັບປຸງການປະຕິບັດ, ແຕ່ນີ້ສາມາດນໍາໄປສູ່ການຂັດຂວາງ HoL (ຫົວຫນ້າສາຍ). QUIC ເຮັດໃຫ້ການຄູນແບບງ່າຍ ແລະສົ່ງຄໍາຮ້ອງຂໍໄປຍັງແອັບພລິເຄຊັນຢ່າງເປັນອິດສະຫຼະ.
• ການຄວບຄຸມຄວາມແອອັດ. QUIC ຢູ່ໃນຊັ້ນຂອງແອັບພລິເຄຊັນ, ເຮັດໃຫ້ມັນງ່າຍຂຶ້ນໃນການປັບປຸງລະບົບການຂົນສົ່ງຕົ້ນຕໍທີ່ຄວບຄຸມການສົ່ງໂດຍອີງໃສ່ຕົວກໍານົດການເຄືອຂ່າຍ (ຈໍານວນການສູນເສຍຫຼື RTT). ການປະຕິບັດ TCP ສ່ວນໃຫຍ່ໃຊ້ algorithm CUBIC, ເຊິ່ງບໍ່ເໝາະສົມສຳລັບການຈະລາຈອນທີ່ລະອຽດອ່ອນເວລາ latency. ບໍ່ດົນມານີ້ໄດ້ພັດທະນາສູດການຄິດໄລ່ເຊັ່ນ: ບີບີ,ສ້າງແບບຈໍາລອງເຄືອຂ່າຍໃຫ້ຖືກຕ້ອງຫຼາຍຂຶ້ນ ແລະເພີ່ມປະສິດທິພາບການແຝງ. QUIC ອະນຸຍາດໃຫ້ທ່ານໃຊ້ BBR ແລະປັບປຸງສູດການຄິດໄລ່ນີ້ຍ້ອນວ່າມັນຖືກນໍາໃຊ້. ການປັບປຸງ.
• ການ​ເພີ່ມ​ເຕີມ​ຂອງ​ການ​ສູນ​ເສຍ​. QUIC ໂທຫາສອງ TLP (ການສືບສວນການສູນເສຍຫາງ) ກ່ອນທີ່ RTO ຈະຖືກກະຕຸ້ນ - ເຖິງແມ່ນວ່າການສູນເສຍຈະສັງເກດເຫັນຫຼາຍ. ນີ້ແມ່ນແຕກຕ່າງຈາກການປະຕິບັດ TCP. TLP retransmits ສ່ວນໃຫຍ່ແມ່ນຊຸດສຸດທ້າຍ (ຫຼືອັນໃຫມ່, ຖ້າມີຫນຶ່ງ) ເພື່ອກະຕຸ້ນການຕື່ມຂໍ້ມູນໄວ. ການຈັດການຄວາມລ່າຊ້າຂອງຫາງແມ່ນເປັນປະໂຫຍດໂດຍສະເພາະສໍາລັບວິທີທີ່ Uber ດໍາເນີນການເຄືອຂ່າຍຂອງຕົນ, ຄືສໍາລັບການໂອນຂໍ້ມູນໄລຍະສັ້ນ, ເປັນໄລຍະໆ, ແລະ latency-sensitive.
• ປັບປຸງ ACK. ເນື່ອງຈາກແຕ່ລະແພັກເກັດມີຕົວເລກລໍາດັບທີ່ເປັນເອກະລັກ, ບໍ່ມີບັນຫາ ຄວາມແຕກຕ່າງ packets ເມື່ອພວກມັນຖືກສົ່ງຄືນ. ແພັກເກັດ ACK ຍັງມີເວລາໃນການປະມວນຜົນແພັກເກັດ ແລະສ້າງ ACK ຢູ່ຝ່າຍລູກຄ້າ. ຄຸນສົມບັດເຫຼົ່ານີ້ຮັບປະກັນວ່າ QUIC ຄິດໄລ່ RTT ໄດ້ຢ່າງຖືກຕ້ອງກວ່າ. ACK ໃນ QUIC ຮອງຮັບສູງສຸດ 256 ແຖບ NACK, ຊ່ວຍໃຫ້ຜູ້ສົ່ງມີຄວາມຢືດຢຸ່ນຫຼາຍຕໍ່ການສະຫຼັບແພັກເກັດແລະໃຊ້ bytes ຫນ້ອຍລົງໃນຂະບວນການ. ACK ເລືອກ (SACK) ໃນ TCP ບໍ່ໄດ້ແກ້ໄຂບັນຫານີ້ໃນທຸກກໍລະນີ.
• ການ​ເຄື່ອນ​ຍ້າຍ​ການ​ເຊື່ອມ​ຕໍ່​. ການເຊື່ອມຕໍ່ QUIC ຖືກລະບຸໂດຍ ID 64-bit, ດັ່ງນັ້ນຖ້າລູກຄ້າປ່ຽນທີ່ຢູ່ IP, ID ການເຊື່ອມຕໍ່ເກົ່າສາມາດສືບຕໍ່ຖືກນໍາໃຊ້ໃນທີ່ຢູ່ IP ໃຫມ່ໂດຍບໍ່ມີການຂັດຂວາງ. ນີ້ແມ່ນການປະຕິບັດທົ່ວໄປຫຼາຍສໍາລັບແອັບພລິເຄຊັນມືຖືທີ່ຜູ້ໃຊ້ປ່ຽນລະຫວ່າງ Wi-Fi ແລະການເຊື່ອມຕໍ່ໂທລະສັບມືຖື.

ທາງເລືອກເພື່ອ QUIC

ພວກເຮົາໄດ້ພິຈາລະນາວິທີການທາງເລືອກໃນການແກ້ໄຂບັນຫາກ່ອນທີ່ຈະເລືອກ QUIC.

ສິ່ງທໍາອິດທີ່ພວກເຮົາໄດ້ພະຍາຍາມແມ່ນການນໍາໃຊ້ TPC PoPs (ຈຸດທີ່ປາກົດ) ເພື່ອຢຸດການເຊື່ອມຕໍ່ TCP ທີ່ໃກ້ຊິດກັບຜູ້ໃຊ້. ໂດຍພື້ນຖານແລ້ວ, PoPs ຢຸດການເຊື່ອມຕໍ່ TCP ກັບອຸປະກອນມືຖືທີ່ໃກ້ຊິດກັບເຄືອຂ່າຍໂທລະສັບມືຖືແລະເປັນຕົວແທນການຈະລາຈອນກັບຄືນໄປບ່ອນພື້ນຖານໂຄງລ່າງເດີມ. ໂດຍການຢຸດ TCP ໃກ້ຊິດ, ພວກເຮົາສາມາດຫຼຸດລົງ RTT ແລະຮັບປະກັນວ່າ TCP ຕອບສະຫນອງຕໍ່ສະພາບແວດລ້ອມໄຮ້ສາຍແບບເຄື່ອນໄຫວຫຼາຍຂຶ້ນ. ຢ່າງໃດກໍ່ຕາມ, ການທົດລອງຂອງພວກເຮົາໄດ້ສະແດງໃຫ້ເຫັນວ່າສ່ວນໃຫຍ່ຂອງ RTT ແລະການສູນເສຍແມ່ນມາຈາກເຄືອຂ່າຍໂທລະສັບມືຖືແລະການນໍາໃຊ້ PoPs ບໍ່ໄດ້ສະຫນອງການປັບປຸງປະສິດທິພາບທີ່ສໍາຄັນ.

ພວກເຮົາຍັງໄດ້ເບິ່ງການປັບຕົວກໍານົດ TCP. ການຕັ້ງຄ່າ TCP stack ໃນເຊີບເວີຂອບທີ່ແຕກຕ່າງກັນຂອງພວກເຮົາແມ່ນມີຄວາມຫຍຸ້ງຍາກເພາະວ່າ TCP ມີການປະຕິບັດທີ່ແຕກຕ່າງກັນໃນທົ່ວຮຸ່ນ OS. ມັນຍາກທີ່ຈະປະຕິບັດສິ່ງນີ້ແລະທົດສອບການຕັ້ງຄ່າເຄືອຂ່າຍທີ່ແຕກຕ່າງກັນ. ການຕັ້ງຄ່າ TCP ໂດຍກົງໃນອຸປະກອນມືຖືເປັນໄປບໍ່ໄດ້ເນື່ອງຈາກຂາດການອະນຸຍາດ. ສິ່ງທີ່ສໍາຄັນກວ່ານັ້ນ, ລັກສະນະເຊັ່ນ: ການເຊື່ອມຕໍ່ 0-RTT ແລະການປັບປຸງການຄາດຄະເນ RTT ແມ່ນສໍາຄັນຕໍ່ສະຖາປັດຕະຍະກໍາຂອງໂປໂຕຄອນ, ແລະດັ່ງນັ້ນມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະບັນລຸຜົນປະໂຫຍດທີ່ສໍາຄັນໂດຍການປັບ TCP ຢ່າງດຽວ.

ສຸດທ້າຍ, ພວກເຮົາໄດ້ປະເມີນໂປໂຕຄອນທີ່ອີງໃສ່ UDP ຫຼາຍອັນທີ່ແກ້ໄຂບັນຫາການຖ່າຍທອດວິດີໂອ - ພວກເຮົາຕ້ອງການເບິ່ງວ່າໂປໂຕຄອນເຫຼົ່ານີ້ຈະຊ່ວຍໄດ້ໃນກໍລະນີຂອງພວກເຮົາ. ແຕ່ຫນ້າເສຍດາຍ, ພວກເຂົາເຈົ້າຂາດຢ່າງຮ້າຍແຮງໃນການຕັ້ງຄ່າຄວາມປອດໄພຫຼາຍ, ແລະຍັງຕ້ອງການການເຊື່ອມຕໍ່ TCP ເພີ່ມເຕີມສໍາລັບ metadata ແລະຂໍ້ມູນການຄວບຄຸມ.

ການຄົ້ນຄວ້າຂອງພວກເຮົາໄດ້ສະແດງໃຫ້ເຫັນວ່າ QUIC ບາງທີອາດເປັນໂປໂຕຄອນດຽວທີ່ສາມາດຊ່ວຍແກ້ໄຂບັນຫາການຈະລາຈອນທາງອິນເຕີເນັດ, ໃນຂະນະທີ່ຄໍານຶງເຖິງຄວາມປອດໄພແລະການປະຕິບັດ.

ການເຊື່ອມໂຍງຂອງ QUIC ເຂົ້າໄປໃນເວທີ

ເພື່ອສຳເລັດການຝັງ QUIC ແລະປັບປຸງການປະຕິບັດຂອງແອັບພລິເຄຊັນໃນສະພາບແວດລ້ອມການເຊື່ອມຕໍ່ທີ່ບໍ່ດີ, ພວກເຮົາໄດ້ປ່ຽນແທນ stack ເກົ່າ (HTTP/2 over TLS/TCP) ດ້ວຍໂປຣໂຕຄໍ QUIC. ພວກເຮົາໄດ້ໃຊ້ຫ້ອງສະຫມຸດເຄືອຂ່າຍ Cronet ຈາກນັ້ນ ໂຄງການ Chromium, ເຊິ່ງປະກອບດ້ວຍຕົ້ນສະບັບ, ຮຸ່ນ Google ຂອງໂປໂຕຄອນ - gQUIC . ການປະຕິບັດນີ້ຍັງຖືກປັບປຸງຢ່າງຕໍ່ເນື່ອງເພື່ອປະຕິບັດຕາມຂໍ້ກໍານົດ IETF ຫຼ້າສຸດ.

ທໍາອິດພວກເຮົາປະສົມປະສານ Cronet ເຂົ້າໄປໃນແອັບຯ Android ຂອງພວກເຮົາເພື່ອເພີ່ມການສະຫນັບສະຫນູນສໍາລັບ QUIC. ການເຊື່ອມໂຍງໄດ້ຖືກປະຕິບັດໃນລັກສະນະດັ່ງກ່າວເພື່ອຫຼຸດຜ່ອນຄ່າໃຊ້ຈ່າຍໃນການເຄື່ອນຍ້າຍຫຼາຍເທົ່າທີ່ເປັນໄປໄດ້. ແທນທີ່ຈະປ່ຽນແທັບເຄືອຂ່າຍເກົ່າທີ່ໃຊ້ຫ້ອງສະຫມຸດຢ່າງສົມບູນ OkHttp, ພວກເຮົາໄດ້ປະສົມປະສານ Cronet ພາຍໃຕ້ກອບ OkHttp API. ໂດຍການເຮັດການເຊື່ອມໂຍງດ້ວຍວິທີນີ້, ພວກເຮົາຫຼີກເວັ້ນການປ່ຽນແປງການໂທເຄືອຂ່າຍຂອງພວກເຮົາ (ທີ່ຖືກນໍາໃຊ້ໂດຍ ຕິດຕັ້ງຄືນໃ່) ໃນລະດັບ API.

ຄ້າຍ​ຄື​ກັນ​ກັບ​ວິ​ທີ​ການ​ສໍາ​ລັບ​ອຸ​ປະ​ກອນ Android​, ພວກ​ເຮົາ​ໄດ້​ປະ​ຕິ​ບັດ Cronet ເຂົ້າ​ໄປ​ໃນ​ກິດ Uber ໃນ iOS​, ຂັດຂວາງ​ການ​ຈະ​ລາ​ຈອນ HTTP ຈາກ​ເຄືອ​ຂ່າຍ​. APIການນໍາໃຊ້ NSURLProtocol. ສິ່ງທີ່ບໍ່ມີຕົວຕົນນີ້, ສະໜອງໃຫ້ໂດຍມູນນິທິ iOS, ຈັດການກັບຂໍ້ມູນ URL ສະເພາະຂອງໂປຣໂຕຄໍ ແລະຮັບປະກັນວ່າພວກເຮົາສາມາດເຊື່ອມໂຍງ Cronet ເຂົ້າໃນແອັບພລິເຄຊັນ iOS ຂອງພວກເຮົາໄດ້ໂດຍບໍ່ມີຄ່າໃຊ້ຈ່າຍໃນການເຄື່ອນຍ້າຍທີ່ສໍາຄັນ.

ກຳລັງເຮັດສຳເລັດ QUIC ໃນ Google Cloud Balancers

ຢູ່ດ້ານຫຼັງ, ການສຳເລັດ QUIC ແມ່ນສະໜອງໃຫ້ໂດຍໂຄງສ້າງພື້ນຖານການດຸ່ນດ່ຽງ Google Cloud Load, ເຊິ່ງໃຊ້ alt-svc headers ໃນຄໍາຕອບເພື່ອສະຫນັບສະຫນູນ QUIC. ໂດຍທົ່ວໄປ, balancer ເພີ່ມ header alt-svc ໃຫ້ກັບແຕ່ລະຄໍາຮ້ອງຂໍ HTTP, ແລະອັນນີ້ຢືນຢັນການສະຫນັບສະຫນູນ QUIC ສໍາລັບໂດເມນແລ້ວ. ເມື່ອລູກຄ້າ Cronet ໄດ້ຮັບການຕອບຮັບ HTTP ກັບສ່ວນຫົວນີ້, ມັນໃຊ້ QUIC ສໍາລັບການຮ້ອງຂໍ HTTP ຕໍ່ມາຕໍ່ໂດເມນນັ້ນ. ເມື່ອຜູ້ດຸ່ນດ່ຽງສໍາເລັດ QUIC, ໂຄງສ້າງພື້ນຖານຂອງພວກເຮົາຈະສົ່ງການກະທໍານີ້ຢ່າງຈະແຈ້ງຜ່ານ HTTP2/TCP ໄປຫາສູນຂໍ້ມູນຂອງພວກເຮົາ.

ປະສິດທິພາບ: ຜົນໄດ້ຮັບ

ປະສິດທິພາບຜົນຜະລິດແມ່ນເຫດຜົນຕົ້ນຕໍສໍາລັບການຄົ້ນຫາຂອງພວກເຮົາສໍາລັບໂປໂຕຄອນທີ່ດີກວ່າ. ເພື່ອເລີ່ມຕົ້ນດ້ວຍ, ພວກເຮົາໄດ້ສ້າງຈຸດຢືນດ້ວຍ emulation ເຄືອຂ່າຍເພື່ອຊອກຫາວ່າ QUIC ຈະປະຕິບັດແນວໃດພາຍໃຕ້ໂປຣໄຟລ໌ເຄືອຂ່າຍທີ່ແຕກຕ່າງກັນ. ເພື່ອທົດສອບປະສິດທິພາບຂອງ QUIC ໃນເຄືອຂ່າຍໂລກຈິງ, ພວກເຮົາໄດ້ດໍາເນີນການທົດລອງໃນຂະນະທີ່ຂັບລົດໄປທົ່ວນະຄອນນິວເດລີໂດຍໃຊ້ການຈໍາລອງການຈາລະຈອນເຄືອຂ່າຍທີ່ຄ້າຍຄືກັນກັບການໂທ HTTP ໃນແອັບຯຜູ້ໂດຍສານ.

ການທົດລອງ 1

ອຸ​ປະ​ກອນ​ສໍາ​ລັບ​ການ​ທົດ​ລອງ​:

• ທົດສອບອຸປະກອນ Android ດ້ວຍ OkHttp ແລະ Cronet stacks ເພື່ອຮັບປະກັນວ່າພວກເຮົາອະນຸຍາດໃຫ້ການຈະລາຈອນ HTTPS ຜ່ານ TCP ແລະ QUIC ຕາມລໍາດັບ;
• ເຊີບເວີ emulation ທີ່ໃຊ້ Java ທີ່ສົ່ງສ່ວນຫົວ HTTPS ປະເພດດຽວກັນໃນການຕອບສະໜອງ ແລະໂຫຼດອຸປະກອນລູກຄ້າເພື່ອຮັບການຮ້ອງຂໍຈາກພວກເຂົາ;
• cloud proxies ທີ່ຕັ້ງຢູ່ໃກ້ກັບອິນເດຍເພື່ອຢຸດການເຊື່ອມຕໍ່ TCP ແລະ QUIC. ໃນຂະນະທີ່ສໍາລັບການຢຸດ TCP ພວກເຮົາໃຊ້ proxy reverse on NGINX, ມັນເປັນການຍາກທີ່ຈະຊອກຫາ open source proxy reverse ສໍາລັບ QUIC. ພວກເຮົາສ້າງ proxy reverse ສໍາລັບ QUIC ຕົວເຮົາເອງໂດຍໃຊ້ stack QUIC ພື້ນຖານຈາກ Chromium ແລະ ເຜີຍແຜ່ ມັນເຂົ້າໄປໃນ chromium ເປັນແຫຼ່ງເປີດ.

ຮູບທີ 6. ຊຸດທົດສອບເສັ້ນທາງ TCP vs QUIC ປະກອບດ້ວຍອຸປະກອນ Android ທີ່ມີ OkHttp ແລະ Cronet, cloud proxies ສຳລັບການຢຸດການເຊື່ອມຕໍ່ ແລະເຊີບເວີ emulation.

ການທົດລອງ 2

ເມື່ອ Google ເຮັດໃຫ້ QUIC ສາມາດໃຊ້ໄດ້ກັບ Google Cloud Load Balancing, ພວກເຮົາໄດ້ນໍາໃຊ້ສິນຄ້າຄົງຄັງດຽວກັນ, ແຕ່ມີການດັດແກ້ຫນຶ່ງ: ແທນທີ່ຈະເປັນ NGINX, ພວກເຮົາໄດ້ເອົາຕົວດຸ່ນດ່ຽງການໂຫຼດຂອງ Google ເພື່ອຢຸດການເຊື່ອມຕໍ່ TCP ແລະ QUIC ຈາກອຸປະກອນ, ເຊັ່ນດຽວກັນກັບເສັ້ນທາງ HTTPS ໄປຫາເຄື່ອງແມ່ຂ່າຍ emulation. Balancers ໄດ້ຖືກແຈກຢາຍທົ່ວໂລກ, ແຕ່ໃຊ້ເຄື່ອງແມ່ຂ່າຍ PoP ທີ່ຢູ່ໃກ້ກັບອຸປະກອນທີ່ສຸດ (ຂອບໃຈທີ່ຕັ້ງພູມສາດ).

ຮູບທີ 7. ໃນການທົດລອງທີສອງ, ພວກເຮົາຕ້ອງການປຽບທຽບການເລັ່ງເວລາສໍາເລັດຂອງ TCP ແລະ QUIC: ການນໍາໃຊ້ Google Cloud ແລະການນໍາໃຊ້ cloud proxy ຂອງພວກເຮົາ.

ດັ່ງນັ້ນ, ການເປີດເຜີຍຫຼາຍຢ່າງລໍຖ້າພວກເຮົາຢູ່:

• ການຢຸດເຊົາໂດຍຜ່ານ PoP ປັບປຸງການປະຕິບັດ TCP. ເນື່ອງຈາກຜູ້ດຸ່ນດ່ຽງຢຸດການເຊື່ອມຕໍ່ TCP ໃກ້ຊິດກັບຜູ້ໃຊ້ແລະໄດ້ຮັບການເພີ່ມປະສິດທິພາບສູງ, ນີ້ເຮັດໃຫ້ RTTs ຕ່ໍາ, ເຊິ່ງປັບປຸງການປະຕິບັດ TCP. ແລະເຖິງແມ່ນວ່າ QUIC ໄດ້ຮັບຜົນກະທົບຫນ້ອຍ, ມັນຍັງປະຕິບັດໄດ້ດີກວ່າ TCP ໃນການຫຼຸດຜ່ອນຄວາມລ່າຊ້າຫາງ (ໂດຍ 10-30 ເປີເຊັນ).
• ຫາງໄດ້ຮັບຜົນກະທົບ hops ເຄືອຂ່າຍ. ເຖິງແມ່ນວ່າ QUIC proxy ຂອງພວກເຮົາຢູ່ໄກຈາກອຸປະກອນ (ປະມານ 50 ms ສູງກວ່າ) ກ່ວາຕົວດຸ່ນດ່ຽງການໂຫຼດຂອງ Google, ມັນໄດ້ສະຫນອງການປະຕິບັດທີ່ຄ້າຍຄືກັນ - 15% latency ຫຼຸດລົງທຽບກັບ TCP ຫຼຸດລົງ 20% ໃນສ່ວນຮ້ອຍທີ 99. ນີ້ຊີ້ໃຫ້ເຫັນວ່າການຫັນປ່ຽນໄມລ໌ສຸດທ້າຍແມ່ນເປັນຄໍຂວດໃນເຄືອຂ່າຍ.

ຮູບທີ 8: ຜົນໄດ້ຮັບຈາກສອງການທົດລອງສະແດງໃຫ້ເຫັນວ່າ QUIC ດີກວ່າ TCP ຢ່າງຫຼວງຫຼາຍ.

ການຈະລາຈອນຕໍ່ສູ້

ໄດ້ຮັບແຮງບັນດານໃຈຈາກການທົດລອງ, ພວກເຮົາໄດ້ປະຕິບັດການຮອງຮັບ QUIC ໃນແອັບພລິເຄຊັນ Android ແລະ iOS ຂອງພວກເຮົາ. ພວກເຮົາໄດ້ດໍາເນີນການທົດສອບ A/B ເພື່ອກໍານົດຜົນກະທົບຂອງ QUIC ຢູ່ໃນຕົວເມືອງທີ່ Uber ດໍາເນີນການ. ໂດຍທົ່ວໄປແລ້ວ, ພວກເຮົາເຫັນວ່າມີການຫຼຸດຜ່ອນຄວາມລ່າຊ້າຫາງຫຼາຍໃນທົ່ວພາກພື້ນ, ຜູ້ໃຫ້ບໍລິການໂທລະຄົມ ແລະ ປະເພດເຄືອຂ່າຍ.

ກຣາຟຂ້າງລຸ່ມນີ້ສະແດງໃຫ້ເຫັນການປັບປຸງອັດຕາສ່ວນຂອງຫາງ (95 ແລະ 99 ເປີເຊັນ) ໂດຍພາກພື້ນມະຫາພາກ ແລະເຄືອຂ່າຍປະເພດຕ່າງໆ - LTE, 3G, 2G.

ຮູບທີ 9. ໃນການທົດສອບການສູ້ຮົບ, QUIC ປະຕິບັດໄດ້ດີກວ່າ TCP ໃນແງ່ຂອງການແຝງ.

ສົ່ງຕໍ່ເທົ່ານັ້ນ

ບາງທີນີ້ແມ່ນພຽງແຕ່ການເລີ່ມຕົ້ນ - ການປ່ອຍ QUIC ເຂົ້າໄປໃນການຜະລິດໄດ້ສະຫນອງໂອກາດທີ່ຫນ້າປະຫລາດໃຈເພື່ອປັບປຸງການປະຕິບັດຄໍາຮ້ອງສະຫມັກໃນເຄືອຂ່າຍທີ່ຫມັ້ນຄົງແລະບໍ່ຫມັ້ນຄົງ, ຄື:

ການຄຸ້ມຄອງເພີ່ມຂຶ້ນ

ມີການວິເຄາະການປະຕິບັດຂອງໂປໂຕຄອນກ່ຽວກັບການຈະລາຈອນທີ່ແທ້ຈິງ, ພວກເຮົາເຫັນວ່າປະມານ 80% ຂອງກອງປະຊຸມສົບຜົນສໍາເລັດໄດ້ນໍາໃຊ້ QUIC ສໍາລັບ всех ການຮ້ອງຂໍ, ໃນຂະນະທີ່ 15% ຂອງເຊດຊັນໃຊ້ການປະສົມປະສານຂອງ QUIC ແລະ TCP. ພວກເຮົາສົມມຸດວ່າການປະສົມປະສານແມ່ນເນື່ອງມາຈາກການຫມົດເວລາຫ້ອງສະຫມຸດ Cronet ກັບຄືນໄປບ່ອນ TCP, ເນື່ອງຈາກວ່າມັນບໍ່ສາມາດຈໍາແນກລະຫວ່າງ UDP ທີ່ແທ້ຈິງແລະສະພາບເຄືອຂ່າຍທີ່ບໍ່ດີ. ປະຈຸບັນພວກເຮົາກຳລັງຊອກຫາວິທີແກ້ໄຂບັນຫານີ້ ໃນຂະນະທີ່ພວກເຮົາເຮັດວຽກຕໍ່ກັບການຈັດຕັ້ງປະຕິບັດ QUIC ຕໍ່ໄປ.

ການເພີ່ມປະສິດທິພາບ QUIC

ການຈາລະຈອນຈາກແອັບຯມືຖືແມ່ນມີຄວາມອ່ອນໄຫວໃນການຕອບສະໜອງ, ແຕ່ບໍ່ແມ່ນຄວາມອ່ອນໄຫວຂອງແບນວິດ. ນອກຈາກນີ້, ຄໍາຮ້ອງສະຫມັກຂອງພວກເຮົາແມ່ນຖືກນໍາໃຊ້ຕົ້ນຕໍໃນເຄືອຂ່າຍໂທລະສັບມືຖື. ອີງຕາມການທົດລອງ, ຫາງ latencies ຍັງສູງເຖິງແມ່ນວ່າການນໍາໃຊ້ຕົວແທນເພື່ອຢຸດ TCP ແລະ QUIC ໃກ້ຊິດກັບຜູ້ໃຊ້. ພວກເຮົາກຳລັງຊອກຫາວິທີການປັບປຸງການຈັດການຄວາມແອອັດ ແລະ ປັບປຸງປະສິດທິພາບຂອງລະບົບການຟື້ນຕົວການສູນເສຍ QUIC.

ດ້ວຍການປັບປຸງເຫຼົ່ານີ້ ແລະອີກຫຼາຍໆອັນ, ພວກເຮົາວາງແຜນທີ່ຈະປັບປຸງປະສົບການຂອງຜູ້ໃຊ້ໂດຍບໍ່ຄໍານຶງເຖິງເຄືອຂ່າຍ ແລະພາກພື້ນ, ເຮັດໃຫ້ການຂົນສົ່ງແພັກເກັດສະດວກ ແລະ ສະດວກສະບາຍຍິ່ງຂຶ້ນໃນທົ່ວໂລກ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com