ພຣັອກຊີດ້ານໜ້າບໍ່ຮັກສາຂອບເຂດຂອງສ່ວນ TCP

ແຍກການແບ່ງສ່ວນ TCP, ການອ່ານ socket ແລະ ການຈັດກອບ HTTP ເມື່ອກວດສອບການຈະລາຈອນທັງສອງຂ້າງຂອງພຣັອກຊີດ້ານໜ້າ.

ສົມມຸດວ່າການຕອບສະໜອງ HTTP ປະກົດໃນຫຼາຍສ່ວນ TCP ທີ່ບັນທຶກໄວ້ຫຼັງຈາກຜ່ານ Squid. ນັ້ນອາດເປັນພຶດຕິກຳ TCP ປົກກະຕິ ບໍ່ແມ່ນຫຼັກຖານວ່າການຕອບສະໜອງຖືກແບ່ງຜິດ.

ພຣັອກຊີດ້ານໜ້າປົກກະຕິມີສອງການເຊື່ອມຕໍ່:

client ⇄ TCP connection A ⇄ proxy ⇄ TCP connection B ⇄ origin

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

ສາມຂອບເຂດທີ່ຄວນແຍກໄວ້

ຂອບເຂດອັນໃດກຳນົດມັນ
ສ່ວນ TCPເສັ້ນທາງການຂົນສົ່ງ ແລະ ເຄືອຂ່າຍ
ຜົນຂອງການອ່ານ socketຈຳນວນໄບຕ໌ຂອງກະແສທີ່ມີ ແລະ ບັຟເຟີຂອງຜູ້ເອີ້ນ
ຂໍ້ຄວາມ ຫຼື ກອບ HTTPກົດການຈັດກອບຂອງໂປຣໂຕຄອນ HTTP

ການອ່ານໜຶ່ງຄັ້ງອາດມີສ່ວນໜຶ່ງຂອງຫົວ, ຫົວທັງໝົດພ້ອມໄບຕ໌ເນື້ອ, ຫຼື ຂໍ້ມູນທີ່ຂ້າມຂອບເຂດລະດັບແອັບພລິເຄຊັນຫຼາຍກວ່າໜຶ່ງ. TCP ບໍ່ໄດ້ຜູກ «ຈຸດສິ້ນສຸດຂອງການຕອບສະໜອງ HTTP» ໄວ້ກັບຈຸດສິ້ນສຸດຂອງການອ່ານທີ່ສຳເລັດ.

ດັ່ງນັ້ນຕົວແຍກ HTTP/1.1 ຈະລວບລວມຫົວ ແລະ ໃຊ້ກົດການຈັດກອບເນື້ອທີ່ໃຊ້ໄດ້ ລວມທັງຄວາມຍາວ, ການເຂົ້າລະຫັດການສົ່ງ ຫຼື ການປິດການເຊື່ອມຕໍ່ທີ່ອະນຸຍາດ. ກອບ HTTP/2 ເປັນໂຄງສ້າງໂປຣໂຕຄອນທີ່ຕົວມັນເອງສາມາດຂ້າມສ່ວນ TCP ໄດ້; ມັນບໍ່ແມ່ນຊື່ອື່ນຂອງແພັກເກັດເຄືອຂ່າຍ.

ອຸໂມງ CONNECT ທີ່ສຳເລັດຮັກສາກະແສໄບຕ໌ໃນອຸໂມງ ແຕ່ຍັງໃຊ້ຂາ TCP ສອງຂາ. ຂອບເຂດສ່ວນຂອງມັນອາດແຕກຕ່າງກັນ ເຖິງແມ່ນວ່າພຣັອກຊີບໍ່ໄດ້ປ່ຽນໄບຕ໌ໃນອຸໂມງ.

ເມື່ອສືບສວນຄວາມເສຍຫາຍ ໃຫ້ປຽບທຽບຂໍ້ມູນແອັບພລິເຄຊັນທີ່ປະກອບຄືນ. ການປຽບທຽບຈຳນວນແພັກເກັດ ຫຼື ການຄາດຫວັງຄວາມຍາວແພັກເກັດດຽວກັນທັງສອງຂ້າງ ແມ່ນການຂໍການຮັບປະກັນຂອບເຂດຈາກ TCP ທີ່ມັນບໍ່ໃຫ້.

ບົດຄວາມທີ່ກ່ຽວຂ້ອງ