ຄຳຮ້ອງ Squid ຊ້າ ເມື່ອ URL rewriter ຂັດຂ້ອງ

ຖ້າ Squid ຮັບການເຊື່ອມຕໍ່ໄດ້ ແຕ່ໃຊ້ເວລາດົນໃນການສົ່ງຄຳຮ້ອງຕໍ່ໄປ, ໃຫ້ກວດເບິ່ງ URL rewriter ໃດໆ ຢູ່ເສັ້ນທາງນັ້ນ. ໃນ Squid 5–7, url_rewrite_program ຄືຊື່ຂອງໂປຣແກຣມພາຍນອກທີ່ຖືກເອີ້ນຫຼັງການກວດສິດເຂົ້າເຖິງເບື້ອງຕົ້ນ. ມັນສາມາດເຮັດໃຫ້ຄຳຮ້ອງຊ້າລົງກ່ອນປາຍທາງຈະໄດ້ຮັບ.

1. ອ່ານຄຳສັ່ງ rewriter ທີ່ໃຊ້ຕົວຈິງ ລວມທັງ wrapper ແລະ argument.
2. ຈັບຄູ່ transaction ທີ່ໄດ້ຮັບຜົນກະທົບກັບ ການວິນິດໄສຂອງ helper. ການອອກຂອງ process ລູກຊ້ຳໆ, ການຕອບກັບທີ່ຜິດຮູບແບບ ແລະ ຄິວທີ່ເພີ່ມຂຶ້ນ ແມ່ນຂໍ້ບົ່ງຊີ້ແຕກຕ່າງກັນ.
3. ກວດເບິ່ງວ່າ URL pattern ດຽວເປັນຕົວກະຕຸ້ນຄວາມຜິດພາດຫຼືບໍ່. ເກັບຕົວຢ່າງຂອງ input ນັ້ນທີ່ປົກປິດຂໍ້ມູນແລ້ວ ແທນທີ່ຈະປ່ຽນການຕັ້ງຄ່າ resolver ທີ່ບໍ່ກ່ຽວຂ້ອງ.

Helper ມີສັນຍາຄຳຮ້ອງ/ຕອບກັບແບບແຍກຕາມແຖວ. ຂໍ້ຄວາມຄວາມຄືບໜ້າຂອງ wrapper ທີ່ອອກທາງ standard output ສາມາດເຮັດໃຫ້ມັນແຕກ. ການລັນ script ສຳເລັດໃນຖານະຜູ້ດູແລລະບົບກໍບໍ່ສາມາດສ້າງ input stream, ສະພາບແວດລ້ອມ ຫຼື ສິດຂອງ Squid ຄືນໄດ້. ເສັ້ນທາງນີ້ແຍກຈາກການກວດສອບລະຫັດຜ່ານ.

ຫຼັງຈາກການແລກປ່ຽນເຮັດວຽກໄດ້ແລ້ວ ຈຶ່ງຄວນຖືວ່າເປັນບັນຫາຄວາມສາມາດ. url_rewrite_children ຄວບຄຸມ process ແລະ ພຶດຕິກຳຄິວທີ່ກ່ຽວຂ້ອງ, ແຕ່ process ລູກຫຼາຍຂຶ້ນກໍບໍ່ສາມາດແກ້ການຂັດຂ້ອງທີ່ເກີດຈາກ input. ຕົວເລືອກ concurrency ຂອງມັນເພີ່ມ channel identifier ແລະ ຕ້ອງການ helper ທີ່ປະຕິບັດການສົນທະນາແບບນັ້ນ.

ການປຽບທຽບທີ່ໄດ້ຮັບອະນຸຍາດໂດຍບໍ່ມີ rewriter ສາມາດແຍກສ່ວນປະກອບຂອງມັນອອກ. ການປ່ອຍໃຫ້ມັນຖືກຂ້າມໄປໃນເວລາໂຫຼດເກີນ ອາດປ່ຽນ routing ຫຼື ການກັ່ນຕອງທີ່ມັນບັງຄັບໃຊ້, ດັ່ງນັ້ນນັ້ນແມ່ນການເລືອກນະໂຍບາຍ. ປຽບທຽບເວລາລໍຖ້າຂອງ helper ທີ່ສັງເກດເຫັນ ກັບຫຼັກຖານ DNS ແລະ ການເຊື່ອມຕໍ່ຕໍ່ໄປ ກ່ອນຈະໂທດຄວາມຊ້າທັງໝົດໃຫ້ latency ເຄືອຂ່າຍ.