ພຣັອກຊີສອງອັນສາມາດດາວໂຫຼດໄຟລ໌ໜຶ່ງໄດ້ໄວຂຶ້ນບໍ?

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

ເຄື່ອງລູກຄ້າເປີດການເຊື່ອມຕໍ່ຜ່ານພຣັອກຊີໜຶ່ງທີ່ເລືອກ. ພຣັອກຊີນັ້ນເປີດການເຊື່ອມຕໍ່ຕໍ່ໄປ. ການເພີ່ມທີ່ຢູ່ອີກອັນຈາກລາຍຊື່ພຣັອກຊີເຂົ້າໃນສະລິງຈະໃຫ້ການເຊື່ອມຕໍ່ໃນອະນາຄົດມີທາງເລືອກອີກອັນ; ມັນບໍ່ໄດ້ຕໍ່ພຣັອກຊີທີສອງເຂົ້າໃນກະແສໄບຕ໌ທີ່ກຳລັງເຮັດວຽກຢູ່.

ການດຸ່ນດ່ຽງຫຼາຍ WAN ແບບອີງໃສ່ການເຊື່ອມຕໍ່ທົ່ວໄປກໍມີຂໍ້ຈຳກັດຄ້າຍຄືກັນ. ມັນສາມາດແຈກການເຊື່ອມຕໍ່ຕ່າງໆໄປຕາມລິ້ງ ເຊິ່ງຊ່ວຍເພີ່ມຄວາມສາມາດລວມ ຫຼື ຫຼຸດການແຂ່ງຂັນ. ການເຊື່ອມຕໍ່ໜຶ່ງກໍຍັງເປັນການເຊື່ອມຕໍ່ໜຶ່ງ ເວັ້ນແຕ່ມີກົນໄກອື່ນທີ່ໃຫ້ຫຼາຍເສັ້ນທາງຢ່າງຊັດເຈນ.

ເມື່ອການດາວໂຫຼດແບບຂະໜານກັນເປັນເລື່ອງອື່ນ

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

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

ເສັ້ນທາງສຸດທ້າຍໄປຫາເຄື່ອງລູກຄ້າຍັງສຳຄັນຢູ່. ທາງອອກໄວຫຼາຍອັນບໍ່ສາມາດສົ່ງຂໍ້ມູນຜ່ານລິ້ງເຂົ້າໜຶ່ງທີ່ອີ່ມຕົວໄດ້ຫຼາຍກວ່າທີ່ລິ້ງນັ້ນຮັບໄດ້.

ຫຼາຍເສັ້ນທາງຕ້ອງການການຮອງຮັບທີ່ແທ້ຈິງ

Multipath TCP ແມ່ນກົນໄກຂົນສົ່ງທີ່ຊັດເຈນ ທີ່ສາມາດຂົນການເຊື່ອມຕໍ່ດ້ວຍກະແສຍ່ອຍຫຼາຍອັນ ເມື່ອຈຸດປາຍທັງສອງ ແລະ ການຈັດລຽງເຄືອຂ່າຍຮອງຮັບ. ມັນບໍ່ໄດ້ເປີດໃຊ້ພຽງແຕ່ລາຍຊື່ພຣັອກຊີ HTTP ຫຼື SOCKS ສອງອັນທີ່ບໍ່ກ່ຽວຂ້ອງກັນ.

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