ການສະຕຣີມຜ່ານພຣັອກຊີດ້ານໜ້າ ທຽບກັບການບັຟເຟີຄຳຕອບເຕັມ

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

ຂັ້ນຕອນການສະຕຣີມປົກກະຕິສາມາດທັບຊ້ອນກັນໄດ້:

origin produces a chunk → proxy forwards bytes → client consumes them

ພຣັອກຊີສາມາດຂຽນເນື້ອຫາທີ່ເໝາະສົມລົງແຄດ ຂະນະທີ່ສົ່ງຕໍ່. ການແຄດບໍ່ຕ້ອງລໍຖ້າໄຟລ໌ທັງໝົດ. read_ahead_gap ຂອງ Squid ຄວບຄຸມການດຶງຂໍ້ມູນທີ່ໄວກວ່າການສົ່ງມອບ ເຊິ່ງເປັນການບັຟເຟີອີກຊະນິດໜຶ່ງ.

ແຮງດັນຍ້ອນກັບສາມາດຢຸດການອ່ານທາງເທິງຊົ່ວຄາວ ເມື່ອລູກຄ້າຊ້າເຕີມຄິວສົ່ງອອກ. Content-Length ຍັງໃຫ້ຄວາມຍາວໂດຍບໍ່ຕ້ອງບັຟເຟີເຕັມ. HTTP/1.1 chunked encoding ອະນຸຍາດການສົ່ງມອບເປັນລຳດັບ ແຕ່ບໍ່ສາມາດຮັບປະກັນຄວາມໜ່ວງໜ້ອຍ ຖ້າອົງປະກອບກ່ອນໜ້າຖືຂໍ້ມູນໄວ້.

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

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