[ຢ່າ] ໃຊ້ CDN

ເກືອບທຸກບົດຄວາມຫຼືເຄື່ອງມືສໍາລັບການເພີ່ມປະສິດທິພາບຄວາມໄວຂອງເວັບໄຊທ໌ມີປະໂຫຍກເລັກນ້ອຍ "ໃຊ້ CDN." ໂດຍທົ່ວໄປ, CDN ແມ່ນເຄືອຂ່າຍການຈັດສົ່ງເນື້ອຫາຫຼືເຄືອຂ່າຍການຈັດສົ່ງເນື້ອຫາ. ພວກເຮົາຢູ່ Method Lab ມັກຈະພົບກັບຄໍາຖາມຈາກລູກຄ້າໃນຫົວຂໍ້ນີ້; ຈຸດປະສົງຂອງບົດຄວາມນີ້ແມ່ນເພື່ອເຂົ້າໃຈສິ່ງທີ່ CDN ສາມາດສະຫນອງໄດ້ໃນແງ່ຂອງຄວາມໄວການໂຫຼດຂອງເວັບໄຊທ໌, ບັນຫາໃດທີ່ອາດຈະເກີດຂື້ນ, ແລະໃນກໍລະນີໃດທີ່ການໃຊ້ CDN ແມ່ນຖືກຕ້ອງ.

ຄວາມລ່າຊ້າທີ່ວົງຢູ່ໃນຮູບແມ່ນເກີດມາຈາກການໃຊ້ CDN.

ບາງປະຫວັດສາດ

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

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

ບັນຫາການຈໍາກັດຊ່ອງທາງຂອງເຄື່ອງແມ່ຂ່າຍສ່ວນບຸກຄົນແມ່ນໄດ້ຮັບການແກ້ໄຂຢ່າງສົມບູນໂດຍ CDN. ລູກຄ້າບໍ່ໄດ້ເຊື່ອມຕໍ່ກັບເຄື່ອງແມ່ຂ່າຍໂດຍກົງ, ແຕ່ກັບ nodes ໃນເຄືອຂ່າຍ CDN. ໃນສະຖານະການທີ່ເຫມາະສົມ, ເຄື່ອງແມ່ຂ່າຍຈະສົ່ງກະແສຫນຶ່ງໄປຫາ CDN node, ແລະຫຼັງຈາກນັ້ນເຄືອຂ່າຍໃຊ້ຊັບພະຍາກອນຂອງຕົນເອງເພື່ອສົ່ງກະແສນີ້ໃຫ້ກັບຜູ້ໃຊ້ຫຼາຍຄົນ. ຈາກທັດສະນະທາງດ້ານເສດຖະກິດ, ພວກເຮົາຈ່າຍພຽງແຕ່ສໍາລັບຊັບພະຍາກອນທີ່ບໍລິໂພກຕົວຈິງ (ນີ້ອາດຈະເປັນແບນວິດຫຼືການຈະລາຈອນ) ແລະໄດ້ຮັບການຂະຫຍາຍການບໍລິການທີ່ດີເລີດຂອງພວກເຮົາ. ການນໍາໃຊ້ CDN ເພື່ອສົ່ງເນື້ອຫາຫນັກແມ່ນສົມເຫດສົມຜົນແລະມີເຫດຜົນ. ເຖິງແມ່ນວ່າມັນເປັນມູນຄ່າທີ່ສັງເກດວ່າຜູ້ຫຼິ້ນທີ່ໃຫຍ່ທີ່ສຸດໃນຊ່ອງນີ້ (ເຊັ່ນ: Netflix) ກໍາລັງສ້າງ CDNs ຂອງຕົນເອງແທນທີ່ຈະໃຊ້ CDNs ການຄ້າຂະຫນາດໃຫຍ່ (Akamai, Cloudflare, Fastly, ແລະອື່ນໆ).

ເມື່ອເວັບໄຊຕ໌ໄດ້ພັດທະນາ, ຄໍາຮ້ອງສະຫມັກເວັບໄຊຕ໌ຕົວເອງໄດ້ກາຍເປັນຄວາມສັບສົນແລະສັບສົນຫຼາຍ. ບັນຫາຄວາມໄວໃນການໂຫຼດໄດ້ເກີດຂຶ້ນກ່ອນ. ຜູ້ມັກຄວາມໄວຂອງເວັບໄຊທ໌ໄດ້ກໍານົດບັນຫາໃຫຍ່ຈໍານວນຫນຶ່ງທີ່ເຮັດໃຫ້ເວັບໄຊທ໌ໂຫລດຊ້າ. ນຶ່ງໃນນັ້ນແມ່ນການຊັກຊ້າຂອງເຄືອຂ່າຍ (RTT - ເວລາເດີນທາງຮອບ ຫຼືເວລາ ping). ຄວາມລ່າຊ້າສົ່ງຜົນກະທົບຕໍ່ຂະບວນການຫຼາຍຢ່າງໃນການໂຫຼດເວັບໄຊທ໌: ການສ້າງການເຊື່ອມຕໍ່ TCP, ເລີ່ມຕົ້ນກອງປະຊຸມ TLS, ການໂຫຼດແຕ່ລະຊັບພະຍາກອນ (ຮູບພາບ, ໄຟລ໌ JS, ເອກະສານ HTML, ແລະອື່ນໆ).

ບັນຫາແມ່ນຮ້າຍແຮງຂຶ້ນໂດຍຄວາມຈິງທີ່ວ່າເມື່ອນໍາໃຊ້ໂປໂຕຄອນ HTTP / 1.1 (ກ່ອນການມາເຖິງຂອງ SPDY, QUIC ແລະ HTTP / 2 ນີ້ແມ່ນທາງເລືອກດຽວ), ຕົວທ່ອງເວັບເປີດບໍ່ເກີນ 6 ການເຊື່ອມຕໍ່ TCP ກັບໂຮດດຽວ. ທັງຫມົດນີ້ນໍາໄປສູ່ການຢຸດການເຊື່ອມຕໍ່ແລະການນໍາໃຊ້ແບນວິດຊ່ອງທີ່ບໍ່ມີປະສິດທິພາບ. ບັນຫາໄດ້ຖືກແກ້ໄຂບາງສ່ວນໂດຍການແບ່ງປັນໂດເມນ - ການສ້າງໂຮດເພີ່ມເຕີມເພື່ອເອົາຊະນະການຈໍາກັດຈໍານວນການເຊື່ອມຕໍ່.

ນີ້ແມ່ນບ່ອນທີ່ຄວາມສາມາດທີສອງຂອງ CDN ປາກົດ - ການຫຼຸດຜ່ອນ latency (RTT) ເນື່ອງຈາກຈໍານວນຈຸດຫຼາຍແລະຄວາມໃກ້ຊິດຂອງ nodes ກັບຜູ້ໃຊ້. ໄລຍະຫ່າງມີບົດບາດສໍາຄັນຢູ່ທີ່ນີ້: ຄວາມໄວຂອງແສງແມ່ນຈໍາກັດ (ປະມານ 200 ກິໂລແມັດຕໍ່ວິນາທີໃນເສັ້ນໄຍແສງ). ນີ້ຫມາຍຄວາມວ່າທຸກໆ 000 ກິໂລແມັດຂອງການເດີນທາງຈະເພີ່ມ 1000 ms ຂອງຄວາມລ່າຊ້າຫຼື 5 ms ກັບ RTT. ນີ້ແມ່ນເວລາຂັ້ນຕ່ໍາທີ່ຕ້ອງການສໍາລັບການສົ່ງຕໍ່, ເນື່ອງຈາກວ່າມັນຍັງມີຄວາມລ່າຊ້າໃນອຸປະກອນລະດັບກາງ. ເນື່ອງຈາກ CDN ປົກກະຕິແລ້ວຮູ້ວິທີການ cache ວັດຖຸຢູ່ໃນເຄື່ອງແມ່ຂ່າຍຂອງມັນ, ພວກເຮົາສາມາດໄດ້ຮັບຜົນປະໂຫຍດຈາກການໂຫຼດວັດຖຸດັ່ງກ່າວຜ່ານ CDN. ເງື່ອນໄຂທີ່ຈໍາເປັນສໍາລັບການນີ້: ການປະກົດຕົວຂອງວັດຖຸໃນແຄດ, ຄວາມໃກ້ຊິດຂອງ CDN ຊີ້ໃຫ້ເຫັນເຖິງຜູ້ໃຊ້ໃນການປຽບທຽບກັບເຄື່ອງແມ່ຂ່າຍຂອງແອັບພລິເຄຊັນເວັບ (ເຄື່ອງແມ່ຂ່າຍຕົ້ນກໍາເນີດ). ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະເຂົ້າໃຈວ່າຄວາມໃກ້ຊິດທາງພູມສາດຂອງ node CDN ບໍ່ໄດ້ຮັບປະກັນການ latency ຕ່ໍາ. ເສັ້ນທາງລະຫວ່າງລູກຄ້າແລະ CDN ສາມາດຖືກສ້າງຂຶ້ນໃນແບບທີ່ລູກຄ້າຈະເຊື່ອມຕໍ່ກັບເຈົ້າພາບໃນປະເທດອື່ນ, ແລະອາດຈະຢູ່ໃນທະວີບອື່ນ. ນີ້ແມ່ນບ່ອນທີ່ການພົວພັນລະຫວ່າງຜູ້ປະຕິບັດການໂທລະຄົມນາຄົມແລະການບໍລິການ CDN (ມິດສະຫາຍ, ການເຊື່ອມຕໍ່, ການມີສ່ວນຮ່ວມໃນ IX, ແລະອື່ນໆ) ແລະນະໂຍບາຍເສັ້ນທາງການຈະລາຈອນຂອງ CDN ຕົວມັນເອງເຂົ້າມາ. ຕົວຢ່າງ, Cloudflare, ເມື່ອນໍາໃຊ້ສອງແຜນການເບື້ອງຕົ້ນ (ຟຣີແລະລາຄາຖືກ), ບໍ່ຮັບປະກັນການຈັດສົ່ງເນື້ອຫາຈາກເຈົ້າພາບທີ່ໃກ້ທີ່ສຸດ - ເຈົ້າພາບຈະຖືກເລືອກເພື່ອບັນລຸຄ່າໃຊ້ຈ່າຍຂັ້ນຕ່ໍາ.

ບໍລິສັດອິນເຕີເນັດຊັ້ນນໍາຫຼາຍແຫ່ງດຶງດູດຄວາມສົນໃຈສາທາລະນະ (ຜູ້ພັດທະນາເວັບແລະເຈົ້າຂອງບໍລິການ) ກັບຫົວຂໍ້ຂອງຄວາມໄວການໂຫຼດແລະການປະຕິບັດເວັບໄຊທ໌. ໃນບັນດາບໍລິສັດເຫຼົ່ານີ້ແມ່ນ Yahoo (Yslow tool), AOL (WebPageTest) ແລະ Google (Page Speed ​​​​Insights ບໍລິການ), ເຊິ່ງກໍາລັງພັດທະນາຄໍາແນະນໍາຂອງຕົນເອງສໍາລັບການເລັ່ງເວັບໄຊທ໌ (ຕົ້ນຕໍແມ່ນພວກເຂົາກ່ຽວຂ້ອງກັບການເພີ່ມປະສິດທິພາບຂອງລູກຄ້າ). ຕໍ່ມາ, ເຄື່ອງມືການທົດສອບຄວາມໄວເວັບໄຊທ໌ໃຫມ່ປາກົດ, ເຊິ່ງຍັງໃຫ້ຄໍາແນະນໍາກ່ຽວກັບການເພີ່ມຄວາມໄວຂອງເວັບໄຊທ໌. ແຕ່ລະບໍລິການຫຼື plugins ເຫຼົ່ານີ້ມີຄໍາແນະນໍາທີ່ສອດຄ່ອງ: "ໃຊ້ CDN." ການຫຼຸດຜ່ອນຄວາມລ່າຊ້າຂອງເຄືອຂ່າຍແມ່ນມັກຈະອ້າງວ່າເປັນຄໍາອະທິບາຍສໍາລັບຜົນກະທົບຂອງ CDN. ແຕ່ຫນ້າເສຍດາຍ, ບໍ່ແມ່ນທຸກຄົນພ້ອມທີ່ຈະເຂົ້າໃຈຢ່າງແນ່ນອນວ່າຜົນກະທົບຂອງການເລັ່ງຂອງ CDN ແມ່ນບັນລຸໄດ້ແລະວິທີການທີ່ມັນສາມາດວັດແທກໄດ້, ດັ່ງນັ້ນຄໍາແນະນໍາໄດ້ຖືກປະຕິບັດໂດຍຄວາມເຊື່ອແລະນໍາໃຊ້ເປັນ postulate. ໃນຄວາມເປັນຈິງ, ບໍ່ແມ່ນ CDNs ທັງຫມົດຖືກສ້າງຂື້ນເທົ່າທຽມກັນ.

ການນໍາໃຊ້ CDN ໃນມື້ນີ້

ເພື່ອປະເມີນຜົນປະໂຫຍດຂອງການນໍາໃຊ້ CDNs, ພວກເຂົາຕ້ອງໄດ້ຮັບການຈັດປະເພດ. ສິ່ງທີ່ສາມາດພົບເຫັນໄດ້ໃນປັດຈຸບັນໃນການປະຕິບັດ (ຕົວຢ່າງໃນວົງເລັບແມ່ນ, ແນ່ນອນ, ບໍ່ຄົບຖ້ວນ):

1. CDN ຟຣີສໍາລັບການແຈກຢາຍຫ້ອງສະຫມຸດ JS (MaxCDN, Google. Yandex).
2. CDN ຂອງການບໍລິການສໍາລັບການເພີ່ມປະສິດທິພາບຂອງລູກຄ້າ (ຕົວຢ່າງ, Google Fonts ສໍາລັບຕົວອັກສອນ, Cloudinary, Cloudimage ສໍາລັບຮູບພາບ).
3. CDN ສໍາລັບການເພີ່ມປະສິດທິພາບຄົງທີ່ແລະຊັບພະຍາກອນໃນ CMS (ມີຢູ່ໃນ Bitrix, WordPress ແລະອື່ນໆ).
4. ຈຸດປະສົງທົ່ວໄປ CDN (StackPath, CDNVideo, NGENIX, Megafon).
5. CDN ສໍາລັບການເລັ່ງເວັບໄຊທ໌ (Cloudflare, Imperva, Airi).

ຄວາມແຕກຕ່າງທີ່ ສຳ ຄັນລະຫວ່າງປະເພດເຫຼົ່ານີ້ແມ່ນຫຼາຍປານໃດຂອງການຈະລາຈອນຜ່ານ CDN. ປະເພດ 1-3 ແມ່ນການຈັດສົ່ງພຽງແຕ່ສ່ວນຫນຶ່ງຂອງເນື້ອຫາ: ຈາກຄໍາຮ້ອງຂໍຫນຶ່ງໄປຫາຫຼາຍສິບ (ປົກກະຕິແລ້ວຮູບພາບ). ປະເພດ 4 ແລະ 5 ແມ່ນຕົວແທນເຕັມຂອງການຈະລາຈອນຜ່ານ CDN.

ໃນການປະຕິບັດ, ນີ້ຫມາຍເຖິງຈໍານວນຂອງການເຊື່ອມຕໍ່ທີ່ຖືກນໍາໃຊ້ເພື່ອໂຫລດເວັບໄຊທ໌. ເມື່ອໃຊ້ HTTP/2, ພວກເຮົາໃຊ້ການເຊື່ອມຕໍ່ TCP ດຽວກັບເຈົ້າພາບເພື່ອປະມວນຜົນການຮ້ອງຂໍໃດໆ. ຖ້າພວກເຮົາແບ່ງຊັບພະຍາກອນເຂົ້າໄປໃນໂຮດຕົ້ນຕໍ (ຕົ້ນກໍາເນີດ) ແລະ CDN, ຫຼັງຈາກນັ້ນ, ມັນຈໍາເປັນຕ້ອງແຈກຢາຍຄໍາຮ້ອງຂໍໃນທົ່ວຫລາຍໂດເມນແລະສ້າງການເຊື່ອມຕໍ່ TCP ຫຼາຍ. ກໍລະນີທີ່ຮ້າຍແຮງທີ່ສຸດແມ່ນ: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. ສູດນີ້ບໍ່ຄຳນຶງເຖິງຄວາມລ່າຊ້າໃນເຄືອຂ່າຍມືຖືສຳລັບການເປີດໃຊ້ຊ່ອງວິທະຍຸຂອງອຸປະກອນ (ຖ້າມັນບໍ່ເຄື່ອນໄຫວ) ແລະຄວາມລ່າຊ້າໃນຫໍເຊວ.

ນີ້ແມ່ນສິ່ງທີ່ເບິ່ງຄືວ່າຢູ່ໃນນ້ໍາຕົກທີ່ໂຫລດຂອງເວັບໄຊທ໌ (latencies ສໍາລັບການເຊື່ອມຕໍ່ CDN ແມ່ນເນັ້ນໃສ່ຢູ່ທີ່ RTT 150 ms):

ຖ້າ CDN ກວມເອົາການເຂົ້າຊົມເວັບໄຊທ໌ທັງຫມົດ (ຍົກເວັ້ນການບໍລິການຂອງພາກສ່ວນທີສາມ), ຫຼັງຈາກນັ້ນພວກເຮົາສາມາດນໍາໃຊ້ການເຊື່ອມຕໍ່ TCP ດຽວ, ຊ່ວຍປະຢັດການຊັກຊ້າໃນການເຊື່ອມຕໍ່ກັບໂຮດເພີ່ມເຕີມ. ແນ່ນອນ, ນີ້ໃຊ້ກັບການເຊື່ອມຕໍ່ HTTP/2.

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

ຄວາມສາມາດ CDN ສໍາລັບການເລັ່ງເວັບໄຊທ໌

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

1. ການບີບອັດຂອງຊັບພະຍາກອນຂໍ້ຄວາມ

ລັກສະນະພື້ນຖານທີ່ສຸດແລະເຂົ້າໃຈໄດ້, ແຕ່ມັກຈະປະຕິບັດບໍ່ດີ. CDNs ທັງໝົດປະກາດປະກົດການບີບອັດເປັນຄຸນສົມບັດການເລັ່ງຂອງພວກມັນ. ແຕ່ຖ້າທ່ານເບິ່ງລາຍລະອຽດເພີ່ມເຕີມ, ຂໍ້ບົກຜ່ອງຈະກາຍເປັນທີ່ຊັດເຈນ:

• ອົງສາຕ່ໍາສໍາລັບການບີບອັດແບບເຄື່ອນໄຫວສາມາດນໍາໃຊ້ໄດ້ - 5-6 (ຕົວຢ່າງ, ສໍາລັບ gzip ສູງສຸດແມ່ນ 9);
• ການບີບອັດແບບຄົງທີ່ (ໄຟລ໌ໃນແຄດ) ບໍ່ໃຊ້ຄຸນສົມບັດເພີ່ມເຕີມ (ຕົວຢ່າງ: zopfi ຫຼື brotli ທີ່ມີລະດັບ 11)
• ບໍ່ມີການສະຫນັບສະຫນູນການບີບອັດ brotli ທີ່ມີປະສິດທິພາບ (ປະຫຍັດປະມານ 20% ເມື່ອທຽບກັບ gzip).

ຖ້າທ່ານໃຊ້ CDN, ມັນຄຸ້ມຄ່າທີ່ຈະກວດເບິ່ງຈຸດເຫຼົ່ານີ້: ເອົາໄຟລ໌ທີ່ມາຈາກ CDN, ບັນທຶກຂະຫນາດທີ່ຖືກບີບອັດຂອງມັນແລະບີບອັດມັນດ້ວຍຕົນເອງສໍາລັບການປຽບທຽບ (ທ່ານສາມາດໃຊ້ບໍລິການອອນໄລນ໌ບາງຢ່າງທີ່ມີການສະຫນັບສະຫນູນ brotli, ສໍາລັບການຍົກຕົວຢ່າງ. vsszhat.rf).

2. ການຕັ້ງຄ່າສ່ວນຫົວຂອງຖານຄວາມຈໍາຂອງລູກຄ້າ

ນອກຈາກນີ້ຍັງມີຄຸນສົມບັດການເລັ່ງຄວາມໄວທີ່ງ່າຍດາຍ: ເພີ່ມສ່ວນຫົວສໍາລັບການເກັບຮັກສາເນື້ອຫາໂດຍລູກຄ້າ (ຕົວທ່ອງເວັບ). ສ່ວນຫົວປັດຈຸບັນຫຼາຍທີ່ສຸດແມ່ນ cache-control, ອັນທີ່ລ້າສະໄຫມແມ່ນຫມົດອາຍຸ. ນອກຈາກນັ້ນ, Etag ສາມາດນໍາໃຊ້ໄດ້. ສິ່ງທີ່ສໍາຄັນແມ່ນວ່າ max-age ຂອງ cache-control ແມ່ນຂະຫນາດໃຫຍ່ພຽງພໍ (ຈາກຫນຶ່ງເດືອນຫຼືຫຼາຍກວ່ານັ້ນ).

CDNs ສາມາດຫຼຸດຄ່າອາຍຸສູງສຸດ, ບັງຄັບໃຫ້ຜູ້ໃຊ້ໂຫຼດເນື້ອຫາຄົງທີ່ເລື້ອຍໆ. ມັນບໍ່ຊັດເຈນວ່າອັນນີ້ເຊື່ອມຕໍ່ກັບຫຍັງ: ຄວາມປາຖະຫນາທີ່ຈະເພີ່ມການຈະລາຈອນໃນເຄືອຂ່າຍຫຼືເພີ່ມຄວາມເຂົ້າກັນໄດ້ກັບເວັບໄຊທ໌ທີ່ບໍ່ຮູ້ວິທີການປັບຄ່າ cache. ຕົວຢ່າງ, ເວລາ cache header Cloudflare ເລີ່ມຕົ້ນແມ່ນ 1 ຊົ່ວໂມງ, ເຊິ່ງຕໍ່າຫຼາຍສໍາລັບຂໍ້ມູນຄົງທີ່ບໍ່ສາມາດປ່ຽນແປງໄດ້.

3. ການເພີ່ມປະສິດທິພາບຮູບພາບ

ນັບຕັ້ງແຕ່ CDN ປະຕິບັດຫນ້າທີ່ຂອງຖານຄວາມຈໍາແລະການບໍລິການຮູບພາບ, ມັນຈະເປັນການສົມເຫດສົມຜົນທີ່ຈະເພີ່ມປະສິດທິພາບໃຫ້ເຂົາເຈົ້າໃນດ້ານ CDN ແລະໃຫ້ບໍລິການໃຫ້ເຂົາເຈົ້າກັບຜູ້ໃຊ້ໃນຮູບແບບນີ້. ໃຫ້ຈອງທັນທີວ່າຄຸນສົມບັດນີ້ສາມາດໃຊ້ໄດ້ກັບ CDN ປະເພດ 2, 3 ແລະ 5 ເທົ່ານັ້ນ.

ທ່ານສາມາດເພີ່ມປະສິດທິພາບຮູບພາບໃນຫຼາຍວິທີ: ການນໍາໃຊ້ຮູບແບບການບີບອັດຂັ້ນສູງ (ເຊັ່ນ: WebP), ຕົວເຂົ້າລະຫັດທີ່ມີປະສິດທິພາບຫຼາຍຂຶ້ນ (MozJPEG), ຫຼືພຽງແຕ່ເຮັດຄວາມສະອາດ metadata ທີ່ບໍ່ຈໍາເປັນ.

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

4. ການເພີ່ມປະສິດທິພາບການເຊື່ອມຕໍ່ TLS

ການຈະລາຈອນສ່ວນໃຫຍ່ໃນມື້ນີ້ຈະເດີນທາງຜ່ານການເຊື່ອມຕໍ່ TLS, ຊຶ່ງຫມາຍຄວາມວ່າພວກເຮົາໃຊ້ເວລາພິເສດໃນການເຈລະຈາ TLS. ບໍ່ດົນມານີ້, ເຕັກໂນໂລຢີໃຫມ່ໄດ້ຖືກພັດທະນາເພື່ອເລັ່ງຂະບວນການນີ້. ຕົວຢ່າງ, ນີ້ແມ່ນ EC cryptography, TLS 1.3, session cache ແລະ tickets, hardware encryption acceleration (AES-NI), etc. ການຕັ້ງຄ່າ TLS ຢ່າງຖືກຕ້ອງສາມາດຫຼຸດຜ່ອນເວລາເຊື່ອມຕໍ່ເປັນ 0-1 RTT (ບໍ່ນັບ DNS ແລະ TCP).

ດ້ວຍຊອບແວທີ່ທັນສະໄຫມ, ມັນບໍ່ຍາກທີ່ຈະປະຕິບັດການປະຕິບັດດັ່ງກ່າວດ້ວຍຕົວທ່ານເອງ.

ບໍ່ແມ່ນ CDNs ທັງຫມົດປະຕິບັດ TLS ທີ່ດີທີ່ສຸດທີ່ທ່ານສາມາດກວດສອບການນີ້ໂດຍການວັດແທກເວລາເຊື່ອມຕໍ່ TLS (ຕົວຢ່າງ, ໃນ Webpagetest). ເຫມາະສໍາລັບການເຊື່ອມຕໍ່ໃຫມ່ - 1RTT, 2RTT - ລະດັບສະເລ່ຍ, 3RTT ແລະອື່ນໆ - ບໍ່ດີ.

ມັນຄວນຈະສັງເກດເຫັນວ່າເຖິງແມ່ນວ່າໃນເວລາທີ່ໃຊ້ TLS ໃນລະດັບ CDN, ເຄື່ອງແມ່ຂ່າຍທີ່ມີຄໍາຮ້ອງສະຫມັກເວັບໄຊຕ໌ຂອງພວກເຮົາຍັງຕ້ອງດໍາເນີນການ TLS, ແຕ່ຈາກດ້ານ CDN, ເນື່ອງຈາກວ່າການຈະລາຈອນລະຫວ່າງເຄື່ອງແມ່ຂ່າຍແລະ CDN ຜ່ານເຄືອຂ່າຍສາທາລະນະ. ໃນກໍລະນີທີ່ຮ້າຍແຮງທີ່ສຸດ, ພວກເຮົາຈະໄດ້ຮັບການຊັກຊ້າການເຊື່ອມຕໍ່ TLS ສອງເທົ່າ (ຄັ້ງທໍາອິດກັບເຈົ້າພາບ CDN, ທີສອງລະຫວ່າງມັນກັບເຄື່ອງແມ່ຂ່າຍຂອງພວກເຮົາ).

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

5. ຫຼຸດຜ່ອນຄວາມລ່າຊ້າການເຊື່ອມຕໍ່

ຜົນປະໂຫຍດຕົ້ນຕໍຂອງ CDN ທີ່ທຸກຄົນເວົ້າກ່ຽວກັບ: latency ຕ່ໍາ (ໄລຍະຫ່າງຫນ້ອຍ) ລະຫວ່າງເຈົ້າພາບ CDN ແລະຜູ້ໃຊ້. ບັນລຸໄດ້ໂດຍການສ້າງສະຖາປັດຕະຍະກໍາເຄືອຂ່າຍທີ່ແຈກຢາຍຕາມພູມສັນຖານ, ເຊິ່ງເຈົ້າພາບຕັ້ງຢູ່ໃນຈຸດທີ່ມີຄວາມເຂັ້ມຂົ້ນຂອງຜູ້ໃຊ້ (ເມືອງ, ຈຸດແລກປ່ຽນການຈະລາຈອນ, ແລະອື່ນໆ).

ໃນທາງປະຕິບັດ, ບູລິມະສິດສໍາລັບເຄືອຂ່າຍທີ່ແຕກຕ່າງກັນອາດຈະຢູ່ໃນພາກພື້ນສະເພາະ. ຕົວຢ່າງ, CDNs ລັດເຊຍຈະມີຈຸດຫຼາຍຢູ່ໃນລັດເຊຍ. ຄົນອາເມລິກາທໍາອິດຈະພັດທະນາເຄືອຂ່າຍໃນສະຫະລັດ. ຕົວຢ່າງ, ຫນຶ່ງໃນ CDN Cloudflare ທີ່ໃຫຍ່ທີ່ສຸດມີພຽງແຕ່ 2 ຈຸດໃນລັດເຊຍ - Moscow ແລະ St. ນັ້ນແມ່ນ, ພວກເຮົາສາມາດປະຫຍັດເວລາ latency ສູງສຸດປະມານ 10 ms ເມື່ອທຽບກັບການຈັດວາງໂດຍກົງໃນ Moscow.

CDN ຕາເວັນຕົກສ່ວນໃຫຍ່ບໍ່ມີຈຸດຢູ່ໃນລັດເຊຍເລີຍ. ໂດຍການເຊື່ອມຕໍ່ກັບພວກເຂົາ, ທ່ານພຽງແຕ່ສາມາດເພີ່ມຄວາມລ່າຊ້າສໍາລັບຜູ້ຊົມພາສາລັດເຊຍຂອງທ່ານ.

6. ການເພີ່ມປະສິດທິພາບເນື້ອຫາ (ການຫຍໍ້, ການປ່ຽນແປງໂຄງສ້າງ)

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

ດັ່ງນັ້ນ, ພຽງແຕ່ບາງ CDNs ປະເພດ 5 ເຮັດສິ່ງນີ້. ແນ່ນອນ, ມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະອັດຕະໂນມັດການປ່ຽນແປງທັງຫມົດທີ່ຈໍາເປັນເພື່ອເລັ່ງສິ່ງຕ່າງໆ - ຕ້ອງມີການວິເຄາະຄູ່ມືແລະການເພີ່ມປະສິດທິພາບ. ຕົວຢ່າງ, ການຖອນລະຫັດທີ່ບໍ່ໄດ້ໃຊ້ຫຼືຊ້ໍາກັນແມ່ນວຽກງານຄູ່ມື.

ຕາມກົດລະບຽບ, ການເພີ່ມປະສິດທິພາບດັ່ງກ່າວທັງຫມົດຖືກຄວບຄຸມໂດຍການຕັ້ງຄ່າແລະອັນຕະລາຍທີ່ສຸດແມ່ນຖືກປິດໃຊ້ງານໂດຍຄ່າເລີ່ມຕົ້ນ.

ສະຫນັບສະຫນູນຄວາມສາມາດໃນການເລັ່ງໂດຍປະເພດ CDN

ດັ່ງນັ້ນ, ໃຫ້ພວກເຮົາພິຈາລະນາເບິ່ງວ່າໂອກາດການເລັ່ງທີ່ມີທ່າແຮງທີ່ປະເພດຕ່າງໆຂອງ CDNs ໃຫ້.

ເພື່ອຄວາມສະດວກ, ພວກເຮົາເຮັດຊ້ໍາການຈັດປະເພດ.

1. CDN ຟຣີສໍາລັບການແຈກຢາຍຫ້ອງສະຫມຸດ JS (MaxCDN, Google. Yandex).
2. CDN ຂອງການບໍລິການສໍາລັບການເພີ່ມປະສິດທິພາບຂອງລູກຄ້າ (ຕົວຢ່າງ, Google Fonts ສໍາລັບຕົວອັກສອນ, Cloudinary, Cloudimage ສໍາລັບຮູບພາບ).
3. CDN ສໍາລັບການເພີ່ມປະສິດທິພາບຄົງທີ່ແລະຊັບພະຍາກອນໃນ CMS (ມີຢູ່ໃນ Bitrix, WordPress ແລະອື່ນໆ).
4. ຈຸດປະສົງທົ່ວໄປ CDN (StackPath, CDNVideo, NGENIX, Megafon).
5. CDN ສໍາລັບການເລັ່ງເວັບໄຊທ໌ (Cloudflare, Imperva, Airi).

ຕອນນີ້ໃຫ້ເຮົາປຽບທຽບຄຸນສົມບັດ ແລະປະເພດຂອງ CDN.

ໂອກາດ
ປະເພດ 1
ປະເພດ 2
ປະເພດ 3
ປະເພດ 4
ປະເພດ 5

ການບີບອັດຂໍ້ຄວາມ
+–
-
+–
+–
+

ສ່ວນຫົວແຄດ
+
+
+
+
+

ຮູບພາບ
-
+–
+–
-
+

TLS
-
-
-
+–
+

ການຊັກຊ້າ
-
-
-
+
+

ເນື້ອໃນ
-
-
-
-
+

ໃນຕາຕະລາງນີ້, "+" ຖືກນໍາໃຊ້ເພື່ອຊີ້ໃຫ້ເຫັນການສະຫນັບສະຫນູນຢ່າງເຕັມທີ່, "–" ແມ່ນບໍ່ສະຫນັບສະຫນູນ, ແລະ "+-" ແມ່ນການສະຫນັບສະຫນູນບາງສ່ວນ. ແນ່ນອນ, ມັນອາດຈະມີການບິດເບືອນຈາກຕາຕະລາງນີ້ໃນຄວາມເປັນຈິງ (ຕົວຢ່າງ, ບາງ CDN ຈຸດປະສົງທົ່ວໄປຈະປະຕິບັດຄຸນສົມບັດສໍາລັບການເພີ່ມປະສິດທິພາບຮູບພາບ), ແຕ່ສໍາລັບຄວາມຄິດທົ່ວໄປມັນເປັນປະໂຫຍດ.

ຜົນໄດ້ຮັບ

ຫວັງເປັນຢ່າງຍິ່ງ, ຫຼັງຈາກອ່ານບົດຄວາມນີ້, ທ່ານຈະມີຮູບພາບທີ່ຈະແຈ້ງກ່ຽວກັບຄໍາແນະນໍາ "ໃຊ້ CDN" ເພື່ອເພີ່ມຄວາມໄວໃນເວັບໄຊຂອງທ່ານ.

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

ມັນເປັນໄປໄດ້ວ່າການນໍາໃຊ້ CDN ໃນປັດຈຸບັນແມ່ນຊ້າລົງເວລາໂຫຼດຂອງເວັບໄຊທ໌ຂອງທ່ານ.

ຕາມຄໍາແນະນໍາທົ່ວໄປ, ພວກເຮົາສາມາດສຸມໃສ່ສິ່ງຕໍ່ໄປນີ້: ສຶກສາຜູ້ຊົມຂອງທ່ານ, ກໍານົດຂອບເຂດພູມສາດຂອງມັນ. ຖ້າຜູ້ຊົມຕົ້ນຕໍຂອງທ່ານມີຄວາມເຂັ້ມຂຸ້ນພາຍໃນລັດສະ ໝີ 1-2 ພັນກິໂລແມັດ, ທ່ານບໍ່ຕ້ອງການ CDN ສໍາລັບຈຸດປະສົງຕົ້ນຕໍ - ການຫຼຸດຜ່ອນ latency. ແທນທີ່ຈະ, ທ່ານສາມາດວາງເຄື່ອງແມ່ຂ່າຍຂອງທ່ານໃກ້ຊິດກັບຜູ້ໃຊ້ຂອງທ່ານແລະກໍານົດມັນຢ່າງຖືກຕ້ອງ, ໄດ້ຮັບການເພີ່ມປະສິດທິພາບສ່ວນໃຫຍ່ທີ່ໄດ້ອະທິບາຍໄວ້ໃນບົດຄວາມ (ຟຣີແລະຖາວອນ).

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

ແຫຼ່ງຂໍ້ມູນ: www.habr.com