ການໂຈມຕີໃນລະບົບທາງຫນ້າ - ທ້າຍ - ກັບຫລັງທີ່ອະນຸຍາດໃຫ້ພວກເຮົາເຂົ້າໄປໃນການຮ້ອງຂໍຂອງພາກສ່ວນທີສາມ

ເປີດເຜີຍ ລາຍ​ລະ​ອຽດ​ຂອງ​ການ​ໂຈມ​ຕີ​ໃຫມ່​ໃນ​ເວັບ​ໄຊ​ທີ່​ນໍາ​ໃຊ້​ຮູບ​ແບບ front-end-back-end ເຊັ່ນ​ວ່າ​ການ​ແລ່ນ​ຜ່ານ​ເຄືອ​ຂ່າຍ​ການ​ຈັດ​ສົ່ງ​ເນື້ອ​ຫາ​, load balancers ຫຼື proxies​. ການໂຈມຕີອະນຸຍາດໃຫ້, ໂດຍການສົ່ງຄໍາຮ້ອງຂໍບາງຢ່າງ, ເຂົ້າໄປໃນເນື້ອໃນຂອງຄໍາຮ້ອງຂໍອື່ນໆທີ່ດໍາເນີນການໃນຫົວຂໍ້ດຽວກັນລະຫວ່າງ frontend ແລະ backend. ວິທີການທີ່ສະເຫນີໄດ້ຖືກໃຊ້ຢ່າງສໍາເລັດຜົນເພື່ອຈັດຕັ້ງການໂຈມຕີທີ່ເຮັດໃຫ້ມັນເປັນໄປໄດ້ທີ່ຈະຂັດຂວາງຕົວກໍານົດການພິສູດຢືນຢັນຂອງຜູ້ໃຊ້ບໍລິການ PayPal, ເຊິ່ງໄດ້ຈ່າຍເງິນໃຫ້ນັກຄົ້ນຄວ້າປະມານ 40 ພັນໂດລາເປັນສ່ວນຫນຶ່ງຂອງໂຄງການເພື່ອແຈ້ງໃຫ້ຊາບກ່ຽວກັບການປະກົດຕົວຂອງຊ່ອງຫວ່າງທີ່ບໍ່ໄດ້ຮັບການແກ້ໄຂ. ການໂຈມຕີຍັງໃຊ້ໄດ້ກັບສະຖານທີ່ທີ່ໃຊ້ເຄືອຂ່າຍການຈັດສົ່ງເນື້ອຫາ Akamai.

ຈຸດສໍາຄັນຂອງບັນຫາແມ່ນວ່າ frontends ແລະ backends ມັກຈະສະຫນອງລະດັບທີ່ແຕກຕ່າງກັນຂອງການສະຫນັບສະຫນູນ HTTP protocol, ແຕ່ໃນເວລາດຽວກັນ encapsulate ການຮ້ອງຂໍຈາກຜູ້ໃຊ້ທີ່ແຕກຕ່າງກັນເຂົ້າໄປໃນຊ່ອງທາງທົ່ວໄປ. ເພື່ອເຊື່ອມຕໍ່ການຮ້ອງຂໍການຮັບ frontend ແລະການຮ້ອງຂໍການປະມວນຜົນ backend, ການເຊື່ອມຕໍ່ TCP ທີ່ມີຊີວິດຍາວໄດ້ຖືກສ້າງຕັ້ງຂຶ້ນ, ໂດຍຜ່ານຄໍາຮ້ອງຂໍຂອງຜູ້ໃຊ້ໄດ້ຖືກສົ່ງ, ຖ່າຍທອດຕາມລະບົບຕ່ອງໂສ້ຫນຶ່ງຫຼັງຈາກທີ່ອື່ນ, ແຍກໂດຍວິທີການ HTTP protocol. ເພື່ອແຍກຄໍາຮ້ອງຂໍ, ຫົວຂໍ້ "ຄວາມຍາວເນື້ອຫາ" (ກໍານົດຂະຫນາດທັງຫມົດຂອງຂໍ້ມູນໃນຄໍາຮ້ອງຂໍ) ແລະ ".ການໂອນເຂົ້າລະຫັດ: chunked"(ອະນຸຍາດໃຫ້ທ່ານໂອນຂໍ້ມູນໃນສ່ວນຕ່າງໆ, ລະບຸບລັອກຂອງຂະຫນາດຕ່າງໆໃນຮູບແບບ "{size}\r\n{block}\r\n{size}\r\n{block}\r\n0").

ບັນຫາເກີດຂື້ນຖ້າ frontend ສະຫນັບສະຫນູນພຽງແຕ່ "ຄວາມຍາວຂອງເນື້ອຫາ" ແຕ່ບໍ່ສົນໃຈ "ການເຂົ້າລະຫັດການໂອນ: chunked" (ຕົວຢ່າງ, Akamai CDN ເຮັດແບບນີ້) ຫຼືໃນທາງກັບກັນ. ຖ້າ Transfer-Encoding: chunked ສະຫນັບສະຫນູນທັງສອງດ້ານ, ລັກສະນະການປະຕິບັດຂອງ HTTP header parsers ສາມາດໃຊ້ສໍາລັບການໂຈມຕີ (ຕົວຢ່າງເຊັ່ນ, ໃນເວລາທີ່ທາງຫນ້າບໍ່ສົນໃຈແຖວເຊັ່ນ "Transfer-Encoding: xchunked", "Transfer-Encoding: chunked ”, “Transfer-Encoding” :[tab]chunked”, “X: X[\n]Transfer-Encoding: chunked”, “Transfer-Encoding[\n]: chunked” ຫຼື “Transfer-Encoding : chunked”, ແລະ backend ສົບຜົນສໍາເລັດຂະບວນການໃຫ້ເຂົາເຈົ້າ).

ໃນກໍລະນີນີ້, ຜູ້ໂຈມຕີສາມາດສົ່ງຄໍາຮ້ອງຂໍທີ່ມີທັງ "ຄວາມຍາວເນື້ອຫາ" ແລະ "ການເຂົ້າລະຫັດການໂອນຍ້າຍ: chunked", ແຕ່ຂະຫນາດໃນ "ຄວາມຍາວເນື້ອຫາ" ບໍ່ກົງກັບຂະຫນາດຂອງລະບົບຕ່ອງໂສ້ chunked, ເຊິ່ງ. ແມ່ນນ້ອຍກວ່າມູນຄ່າຕົວຈິງ. ຖ້າ frontend ດໍາເນີນການແລະສົ່ງຕໍ່ຄໍາຮ້ອງຂໍຕາມ "ຄວາມຍາວຂອງເນື້ອຫາ" ແລະ backend ລໍຖ້າ block ສໍາເລັດໂດຍອີງໃສ່ "Transfer-Encoding: chunked", ຫຼັງຈາກນັ້ນ, ສິ້ນສຸດຂອງຂໍ້ມູນໂດຍອີງໃສ່ "Transfer-Encoding: chunked" ຈະ. ຖືກກໍານົດໄວ້ກ່ອນຫນ້ານີ້ແລະຫາງທີ່ຍັງເຫຼືອຂອງຄໍາຮ້ອງຂໍທີ່ຜູ້ໂຈມຕີຈະຢູ່ໃນຕອນຕົ້ນຂອງຄໍາຮ້ອງຂໍຕໍ່ໄປ, i.e. ຜູ້ໂຈມຕີຈະສາມາດແນບຂໍ້ມູນໂດຍຕົນເອງເພື່ອເລີ່ມຕົ້ນການຮ້ອງຂໍຂອງຜູ້ອື່ນທີ່ສົ່ງຕໍ່ໄປ.

ເພື່ອກໍານົດບັນຫາໃນການປະສົມປະສານ frontend-backend ທີ່ໃຊ້ແລ້ວ, ທ່ານສາມາດສົ່ງຄໍາຮ້ອງຂໍແບບນີ້ຜ່ານທາງຫນ້າ:

ໂພສ /ກ່ຽວກັບ HTTP/1.1
ເຈົ້າພາບ: example.com
ການໂອນເຂົ້າລະຫັດ: chunked
ເນື້ອໃນຂອງຄວາມຍາວ: 4

1
Z
Q

ບັນຫາແມ່ນມີຢູ່ຖ້າຫາກວ່າ backend ບໍ່ໄດ້ດໍາເນີນການຮ້ອງຂໍທັນທີທັນໃດແລະລໍຖ້າການມາຮອດຂອງສູນສຸດທ້າຍຂອງຂໍ້ມູນ chunked block. ສໍາລັບການກວດສອບທີ່ສົມບູນກວ່າ ກະກຽມ ຜົນປະໂຫຍດພິເສດທີ່ຍັງທົດສອບວິທີການທີ່ເປັນໄປໄດ້ສໍາລັບການເຊື່ອງ "ການເຂົ້າລະຫັດການໂອນຍ້າຍ: chunked" header ຈາກ frontend.

ການປະຕິບັດການໂຈມຕີທີ່ແທ້ຈິງແມ່ນຂຶ້ນກັບຄວາມສາມາດຂອງເວັບໄຊທີ່ຖືກໂຈມຕີ, ຕົວຢ່າງເຊັ່ນ, ເມື່ອໂຈມຕີຄໍາຮ້ອງສະຫມັກເວັບໄຊຕ໌ Trello, ທ່ານສາມາດທົດແທນການເລີ່ມຕົ້ນຂອງຄໍາຮ້ອງຂໍ (ຂໍ້ມູນທົດແທນເຊັ່ນ "PUT /1/members/1234... x=x&csrf =1234&username=testzzz&bio=cake”) ແລະສົ່ງຂໍ້ຄວາມລວມທັງການຮ້ອງຂໍຕົ້ນສະບັບຂອງຜູ້ໃຊ້ພາກສ່ວນທີສາມແລະ Cookie ການຮັບຮອງທີ່ລະບຸໄວ້ໃນນັ້ນ. ສໍາລັບການໂຈມຕີໃນ saas-app.com, ມັນໄດ້ກາຍມາເປັນຄວາມເປັນໄປໄດ້ທີ່ຈະທົດແທນລະຫັດ JavaScript ໃນການຕອບສະຫນອງໂດຍການປ່ຽນມັນຢູ່ໃນຫນຶ່ງໃນຕົວກໍານົດການຮ້ອງຂໍ. ສໍາລັບການໂຈມຕີໃນ redhat.com, ຕົວຈັດການພາຍໃນໄດ້ຖືກນໍາໃຊ້ເພື່ອປ່ຽນເສັ້ນທາງໄປຫາເວັບໄຊທ໌ຂອງຜູ້ໂຈມຕີ (ຄໍາຮ້ອງຂໍຂອງແບບຟອມ "POST /search?dest=../assets/idx?redir=//[email protected]/ HTTP/1.1").

ການນໍາໃຊ້ວິທີການສໍາລັບເຄືອຂ່າຍການຈັດສົ່ງເນື້ອຫາເຮັດໃຫ້ມັນເປັນໄປໄດ້ພຽງແຕ່ປ່ຽນເວັບໄຊທ໌ທີ່ຮ້ອງຂໍໂດຍການປ່ຽນສ່ວນຫົວຂອງ "ເຈົ້າພາບ:". ການໂຈມຕີຍັງສາມາດຖືກນໍາໃຊ້ເພື່ອສານພິດຂອງລະບົບ caching ເນື້ອໃນແລະສະກັດຂໍ້ມູນຄວາມລັບຂອງຖານຄວາມຈໍາ. ຈຸດສູງສຸດຂອງວິທີການແມ່ນການຈັດຕັ້ງການໂຈມຕີໃນ PayPal, ເຊິ່ງເຮັດໃຫ້ມັນເປັນໄປໄດ້ທີ່ຈະຂັດຂວາງລະຫັດຜ່ານທີ່ສົ່ງໂດຍຜູ້ໃຊ້ໃນລະຫວ່າງການກວດສອບຄວາມຖືກຕ້ອງ (ຄໍາຮ້ອງຂໍ iframe ໄດ້ຖືກດັດແກ້ເພື່ອປະຕິບັດ JavaScript ໃນບໍລິບົດຂອງຫນ້າ paypal.com/us/gifts, ສໍາລັບ ເຊິ່ງ CSP (ນະໂຍບາຍຄວາມປອດໄພເນື້ອຫາ) ບໍ່ໄດ້ຖືກນໍາໃຊ້).

ຫນ້າສົນໃຈ, ໃນປີ 2005 ມີ ສະ ເໜີ ເຕັກນິກການປອມແປງຄໍາຮ້ອງຂໍທີ່ຄ້າຍຄືກັນທີ່ສໍາຄັນທີ່ຊ່ວຍໃຫ້ທ່ານສາມາດປອມແປງຂໍ້ມູນໃນຖານຄວາມຈໍາຂອງຕົວແທນ (Tomcat, squid, mod_proxy) ຫຼືຂ້າມການສະກັດໄຟວໍໂດຍການລະບຸຄໍາຮ້ອງຂໍ "GET" ຫຼື "POST" ພາຍໃນຫນຶ່ງຄັ້ງ HTTP.

ແຫຼ່ງຂໍ້ມູນ: opennet.ru