ພວກ​ເຮົາ​ຜ່ານ​ຜ່າ​ກຳ​ແພງ​ໄຟ​ໃຫຍ່​ຂອງ​ຈີນ​ໄດ້​ແນວ​ໃດ (ຕອນ​ທີ 3)

Hello!
ທຸກໆເລື່ອງທີ່ດີມາຮອດຈຸດຈົບ. ແລະເລື່ອງຂອງພວກເຮົາກ່ຽວກັບວິທີທີ່ພວກເຮົາມາເຖິງການແກ້ໄຂເພື່ອຜ່ານ Firewall ຂອງຈີນຢ່າງໄວວາແມ່ນບໍ່ມີຂໍ້ຍົກເວັ້ນ. ເພາະສະນັ້ນ, ຂ້າພະເຈົ້າຮີບດ່ວນທີ່ຈະແບ່ງປັນກັບທ່ານສຸດທ້າຍ, ສ່ວນສຸດທ້າຍ ກ່ຽວກັບຫົວຂໍ້ນີ້.

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

ຂ້ອຍຈະບອກເຈົ້າວ່າພວກເຮົາໄດ້ທົດສອບ Alibaba Cloud CDN, Tencent Cloud CDN ແລະ Akamai ແນວໃດ, ແລະສິ່ງທີ່ພວກເຮົາຈົບລົງ. ແລະແນ່ນອນ, ໃຫ້ສະຫຼຸບ.

Alibaba Cloud CDN

ພວກເຮົາເປັນເຈົ້າພາບໃນ Alibaba Cloud ແລະໃຊ້ IPSEC ແລະ CEN ຈາກພວກມັນ. ມັນຈະເປັນການສົມເຫດສົມຜົນທີ່ຈະພະຍາຍາມແກ້ໄຂບັນຫາຂອງພວກເຂົາກ່ອນ.

Alibaba Cloud ມີສອງປະເພດຜະລິດຕະພັນທີ່ອາດຈະເຫມາະສົມກັບພວກເຮົາ: CDN и DCDN. ທາງເລືອກທໍາອິດແມ່ນ CDN ຄລາສສິກສໍາລັບໂດເມນສະເພາະ (ໂດເມນຍ່ອຍ). ທາງເລືອກທີສອງແມ່ນຢືນຢູ່ ເສັ້ນທາງໄດນາມິກສໍາລັບ CDN (ຂ້າພະເຈົ້າເອີ້ນວ່າ CDN ແບບເຄື່ອນໄຫວ), ມັນສາມາດຖືກເປີດໃຊ້ໃນໂຫມດ Full-site (ສໍາລັບໂດເມນ wildcard), ມັນຍັງ cache ເນື້ອຫາຄົງທີ່ແລະເລັ່ງເນື້ອຫາແບບເຄື່ອນໄຫວໃນຕົວມັນເອງ, ນັ້ນແມ່ນ, ນະໂຍບາຍດ້ານຂອງຫນ້າຈະຖືກໂຫລດຜ່ານຜູ້ໃຫ້ບໍລິການ. ເຄືອ​ຂ່າຍ​ໄວ​. ນີ້ແມ່ນສິ່ງສໍາຄັນສໍາລັບພວກເຮົາ, ເພາະວ່າໂດຍພື້ນຖານແລ້ວເວັບໄຊທ໌ຂອງພວກເຮົາແມ່ນແບບເຄື່ອນໄຫວ, ມັນໃຊ້ໂດເມນຍ່ອຍຫຼາຍ, ແລະມັນສະດວກກວ່າທີ່ຈະຕັ້ງຄ່າ CDN ຄັ້ງດຽວສໍາລັບ "ດາວ" - *.semrushchina.cn .

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

ໃນ DCDN ທ່ານສາມາດ:

• ຕັ້ງຄ່າການສິ້ນສຸດ SSL ດ້ວຍໃບຢັ້ງຢືນຂອງທ່ານ,
• ເຮັດ​ໃຫ້​ການ​ເລັ່ງ​ຂອງ​ເນື້ອ​ໃນ​ເຄື່ອນ​ໄຫວ​,
• ປັບ​ຕັ້ງ​ຄ່າ​ຖານ​ຄວາມ​ຈໍາ​ຂອງ​ໄຟລ​໌​ສະ​ຖິ​ຕິ​,
• ລ້າງ​ຖານ​ຄວາມ​ຈໍາ​,
• ສົ່ງຕໍ່ຊັອກເກັດເວັບ,
• ເປີດໃຊ້ການບີບອັດແລະແມ້ກະທັ້ງ HTML Beautifier.

ໂດຍທົ່ວໄປ, ທຸກສິ່ງທຸກຢ່າງແມ່ນຄືກັນກັບຜູ້ໃຫຍ່ແລະຜູ້ໃຫ້ບໍລິການ CDN ຂະຫນາດໃຫຍ່.

ຫຼັງຈາກຕົ້ນກໍາເນີດ (ສະຖານທີ່ທີ່ເຄື່ອງແມ່ຂ່າຍຂອບ CDN ຈະໄປ), ທັງຫມົດທີ່ຍັງເຫຼືອແມ່ນການສ້າງ CNAME ສໍາລັບດາວ, ການອ້າງອີງ all.semrushchina.cn.w.kunluncan.com (CNAME ນີ້ໄດ້ຮັບໃນ Alibaba Cloud console) ແລະ CDN ຈະເຮັດວຽກ.

ອີງຕາມຜົນການທົດສອບ, CDN ນີ້ຊ່ວຍພວກເຮົາຫຼາຍ. ສະຖິຕິແມ່ນສະແດງໃຫ້ເຫັນຂ້າງລຸ່ມນີ້.

ການຕັດສິນໃຈ
Uptime
Median
75 ເປີເຊັນ
95 ເປີເຊັນ

CloudFlare
86.6
18
30
60

IPsec
99.79
18
21
30

CEN
99.75
16
21
27

CEN/IPsec + GLB
99.79
13
16
25

Ali CDN + CEN/IPsec + GLB
99.75
10
12.8
17.3

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

ດັ່ງນັ້ນ, ພວກເຮົາກ້າວໄປສູ່ຍັກໃຫຍ່ອີກອັນຫນຶ່ງໃນຕະຫຼາດຈີນ - Tencent.

Tencent Cloud

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

• ພວກເຂົາເຈົ້າມີບາງສິ່ງບາງຢ່າງທີ່ຄ້າຍຄືກັນກັບ CEN ບໍ?
• IPSEC ເຮັດວຽກແນວໃດສໍາລັບພວກເຂົາ? ມັນໄວ, ເວລາຫວ່າງແມ່ນຫຍັງ?
• ພວກເຂົາເຈົ້າມີ Anycast ບໍ?

ໃຫ້ເບິ່ງຄໍາຖາມເຫຼົ່ານີ້ແຍກຕ່າງຫາກ.

ອະນາລັອກ CEN

Tencent ມີຜະລິດຕະພັນ Cloud Connect Network (CCN), ຊ່ວຍໃຫ້ທ່ານສາມາດເຊື່ອມຕໍ່ VPCs ຈາກພາກພື້ນຕ່າງໆ, ລວມທັງພາກພື້ນພາຍໃນແລະນອກປະເທດຈີນ. ຕອນນີ້ຜະລິດຕະພັນຢູ່ໃນເບຕ້າພາຍໃນ, ແລະທ່ານຕ້ອງການສ້າງປີ້ທີ່ຂໍໃຫ້ເຊື່ອມຕໍ່ກັບມັນ. ພວກເຮົາໄດ້ຮຽນຮູ້ຈາກການສະຫນັບສະຫນູນວ່າບັນຊີທົ່ວໂລກ (ພວກເຮົາບໍ່ໄດ້ເວົ້າກ່ຽວກັບພົນລະເມືອງຈີນຫຼືນິຕິບຸກຄົນ) ບໍ່ສາມາດເຂົ້າຮ່ວມໃນໂຄງການທົດສອບ beta ແລະໂດຍທົ່ວໄປແລ້ວ, ເຊື່ອມຕໍ່ພາກພື້ນພາຍໃນປະເທດຈີນກັບພາກພື້ນພາຍນອກ. 1-0 ໃນເງື່ອນໄຂຂອງ Ali Cloud

IPSEC

ເຂດພາກໃຕ້ສຸດຂອງ Tencent ແມ່ນ ກວາງໂຈ. ພວກເຮົາໄດ້ປະກອບອຸໂມງແລະເຊື່ອມຕໍ່ມັນກັບພາກພື້ນຮົງກົງໃນ GCP (ຫຼັງຈາກນັ້ນ, ພາກພື້ນນີ້ໄດ້ກາຍເປັນແລ້ວ). ອຸ​ໂມງ​ແຫ່ງ​ທີ​ສອງ​ຢູ່​ເມືອງ Ali Cloud ຈາກ​ເມືອງ Shenzhen ຫາ​ຮົງ​ກົງ ກໍ່​ໄດ້​ຍົກ​ຂຶ້ນ​ໃນ​ເວ​ລາ​ດຽວ​ກັນ. ມັນ​ໄດ້​ຫັນ​ອອກ​ວ່າ​ໂດຍ​ຜ່ານ​ເຄືອ​ຂ່າຍ Tencent latency ກັບ​ຮົງ​ກົງ​ໂດຍ​ທົ່ວ​ໄປ​ແມ່ນ​ດີກ​ວ່າ (10ms​) ກ​່​ວາ​ຈາກ Shenzhen ກັບ​ຮົງ​ກົງ​ໄປ Ali (120ms - ຫຍັງ​?). ແຕ່ນີ້ບໍ່ໄດ້ເລັ່ງການເຮັດວຽກຂອງສະຖານທີ່ທີ່ມີຈຸດປະສົງໃນການເຮັດວຽກຜ່ານ Tencent ແລະອຸໂມງນີ້, ເຊິ່ງໃນຕົວຂອງມັນເອງແມ່ນຄວາມເປັນຈິງທີ່ຫນ້າປະຫລາດໃຈແລະອີກເທື່ອຫນຶ່ງໄດ້ພິສູດດັ່ງຕໍ່ໄປນີ້: latency - ສໍາລັບປະເທດຈີນ, ນີ້ບໍ່ແມ່ນຕົວຊີ້ວັດທີ່ມີມູນຄ່າແທ້ໆ. ເອົາ​ໃຈ​ໃສ່​ໃນ​ເວ​ລາ​ທີ່​ການ​ພັດ​ທະ​ນາ​ການ​ແກ້​ໄຂ​ສໍາ​ລັບ​ການ​ຜ່ານ firewall ຂອງ​ຈີນ​.

ການເລັ່ງອິນເຕີເນັດ Anycast

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

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

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

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

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

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

Akamai

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

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

ສິ່ງທີ່ຂ້ອຍມັກ:

• guys ຈາກ Akamai ມີປະໂຫຍດຫຼາຍໃນທຸກຄໍາຖາມແລະມາພ້ອມກັບພວກເຮົາໃນທຸກຂັ້ນຕອນຂອງການທົດສອບ. ພວກເຮົາພະຍາຍາມຢ່າງຕໍ່ເນື່ອງເພື່ອປັບປຸງບາງສິ່ງບາງຢ່າງຢູ່ໃນຂ້າງຂອງພວກເຮົາ. ພວກເຂົາເຈົ້າໃຫ້ຄໍາແນະນໍາດ້ານວິຊາການທີ່ດີ.
• Akamai ແມ່ນປະມານ 10-15% ຊ້າກວ່າການແກ້ໄຂຂອງພວກເຮົາຜ່ານ Ali Cloud CDN. ສິ່ງທີ່ຫນ້າປະທັບໃຈແມ່ນວ່າໃນ Origin for Akamai ພວກເຮົາໄດ້ລະບຸທີ່ຢູ່ IP ຂອງ GLB, ຊຶ່ງຫມາຍຄວາມວ່າການຈະລາຈອນບໍ່ໄດ້ຜ່ານການແກ້ໄຂຂອງພວກເຮົາ (ເປັນໄປໄດ້ທີ່ພວກເຮົາສາມາດປະຖິ້ມບາງສ່ວນຂອງໂຄງສ້າງພື້ນຖານ). ຢ່າງໃດກໍຕາມ, ຜົນໄດ້ຮັບການທົດສອບໄດ້ສະແດງໃຫ້ເຫັນວ່າການແກ້ໄຂນີ້ແມ່ນຮ້າຍແຮງກວ່າສະບັບປະຈຸບັນຂອງພວກເຮົາ (ຜົນໄດ້ຮັບປຽບທຽບຂ້າງລຸ່ມນີ້).
• ທົດສອບທັງຕົ້ນກຳເນີດ GLB ແລະຕົ້ນກຳເນີດໃນປະເທດຈີນ. ທັງສອງທາງເລືອກແມ່ນປະມານຄືກັນ.
• ມີ ແນ່ນອນເສັ້ນທາງ (ການເພີ່ມປະສິດທິພາບເສັ້ນທາງອັດຕະໂນມັດ). ທ່ານສາມາດໂຮດວັດຖຸທົດສອບຢູ່ໃນ Origin, ແລະເຄື່ອງແມ່ຂ່າຍຂອງ Akamai Edge ຈະພະຍາຍາມເອົາມັນຂຶ້ນ (GET ປົກກະຕິ). ສໍາລັບການຮ້ອງຂໍເຫຼົ່ານີ້, ຄວາມໄວແລະການວັດແທກອື່ນໆແມ່ນການວັດແທກ, ໂດຍອີງໃສ່ທີ່ເຄືອຂ່າຍ Akamai ປັບປຸງເສັ້ນທາງເພື່ອໃຫ້ການຈະລາຈອນໄວຂຶ້ນສໍາລັບເວັບໄຊທ໌ຂອງພວກເຮົາແລະມັນເປັນທີ່ຊັດເຈນວ່າການເປີດໃຊ້ຄຸນສົມບັດນີ້ມີຜົນກະທົບທີ່ເຂັ້ມແຂງຕໍ່ຄວາມໄວຂອງເວັບໄຊທ໌.
• ການສ້າງເວີຊັນໃນການໂຕ້ຕອບຂອງເວັບແມ່ນເຢັນ. ທ່ານສາມາດເຮັດການປຽບທຽບສໍາລັບສະບັບ, ເບິ່ງຄວາມແຕກຕ່າງ. ເບິ່ງສະບັບທີ່ຜ່ານມາ.
• ທ່ານສາມາດເປີດຕົວຮຸ່ນໃຫມ່ຄັ້ງທໍາອິດໃນເຄືອຂ່າຍ Akamai Staging - ເຄືອຂ່າຍດຽວກັນກັບການຜະລິດ, ພຽງແຕ່ວິທີນີ້ຈະບໍ່ມີຜົນກະທົບຕໍ່ຜູ້ໃຊ້ທີ່ແທ້ຈິງ. ສໍາລັບການທົດສອບນີ້, ທ່ານຈໍາເປັນຕ້ອງ spoof ບັນທຶກ DNS ໃນເຄື່ອງທ້ອງຖິ່ນຂອງທ່ານ.
• ຄວາມໄວການດາວໂຫຼດໄວຫຼາຍໂດຍຜ່ານເຄືອຂ່າຍຂອງເຂົາເຈົ້າສໍາລັບໄຟລ໌ຄົງທີ່ຂະຫນາດໃຫຍ່, ແລະ, ປາກົດຂື້ນ, ໄຟລ໌ອື່ນໆ. ໄຟລ໌ຈາກແຄດ "ເຢັນ" ຖືກດຶງຂໍ້ມູນໄວກວ່າໄຟລ໌ດຽວກັນຫຼາຍຄັ້ງຈາກແຄດ "ເຢັນ" ຂອງ Ali CDN. ຈາກແຄດ "ຮ້ອນ", ຄວາມໄວແມ່ນຄືກັນ, ບວກຫຼືລົບ.

ການທົດສອບ Ali CDN:

root@shenzhen1:~# curl -o /dev/null -w@curl_time https://en.semrushchina.cn/my_reports/build/scripts/simpleInit.js?v=1551879212
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 5757k    0 5757k    0     0   513k      0 --:--:--  0:00:11 --:--:--  526k
time_namelookup:  0.004286
time_connect:  0.030107
time_appconnect:  0.117525
time_pretransfer:  0.117606
time_redirect:  0.000000
time_starttransfer:  0.840348
----------
time_total:  11.208119
----------
size_download:  5895467 Bytes
speed_download:  525999.000B/s

ການ​ທົດ​ສອບ Akamai​:

root@shenzhen1:~# curl -o /dev/null -w@curl_time https://www.semrushchina.cn/my_reports/build/scripts/simpleInit.js?v=1551879212
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 5757k    0 5757k    0     0  1824k      0 --:--:--  0:00:03 --:--:-- 1825k
time_namelookup:  0.509005
time_connect:  0.528261
time_appconnect:  0.577235
time_pretransfer:  0.577324
time_redirect:  0.000000
time_starttransfer:  1.327013
----------
time_total:  3.154850
----------
size_download:  5895467 Bytes
speed_download:  1868699.000B/s

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

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

ສິ່ງທີ່ຂ້ອຍບໍ່ມັກ:

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

Metrics (~3626 ແລ່ນ; metrics ທັງຫມົດຍົກເວັ້ນ Uptime, ໃນ ms; ສະຖິຕິສໍາລັບໄລຍະເວລາດຽວ):

ຜູ້ໃຫ້ບໍລິການ CDN
Median
75%
95%
ການຕອບສະຫນອງ
ຄໍາຕອບຂອງຫນ້າເວັບ
Uptime
DNS
ເຊື່ອມຕໍ່
ລໍຖ້າ
Load
SSL

AliCDN
9195
10749
17489
1,715
10,745
99.531
57
17
927
479
200

Akamai
9783
11887
19888
2,352
11,550
98.980
424
91
1408
381
50

ການແຜ່ກະຈາຍໂດຍເປີເຊັນ (ໃນ ms):

ເປີເຊັນ
Akamai
AliCDN

10
7,092
6,942

20
7,775
7,583

30
8,446
8,092

40
9,146
8,596

50
9,783
9,195

60
10,497
9,770

70
11,371
10,383

80
12,670
11,255

90
15,882
13,165

100
91,592
91,596

ສະຫຼຸບແມ່ນນີ້: ທາງເລືອກ Akamai ແມ່ນເປັນໄປໄດ້, ແຕ່ບໍ່ໄດ້ສະຫນອງຄວາມຫມັ້ນຄົງແລະຄວາມໄວດຽວກັນກັບການແກ້ໄຂຂອງພວກເຮົາກັບ Ali CDN.

ບັນທຶກນ້ອຍໆ

ບາງຊ່ວງເວລາບໍ່ໄດ້ລວມຢູ່ໃນເລື່ອງ, ແຕ່ຂ້ອຍຢາກຂຽນກ່ຽວກັບພວກມັນຄືກັນ.

ປັກກິ່ງ + ໂຕກຽວ ແລະຮົງກົງ

ດັ່ງທີ່ຂ້າພະເຈົ້າໄດ້ກ່າວຂ້າງເທິງ, ພວກເຮົາໄດ້ທົດສອບອຸໂມງ IPSEC ໄປຮົງກົງ (HK). ແຕ່ພວກເຮົາຍັງໄດ້ທົດສອບ CEN ກັບ HK. ມັນມີຄ່າໃຊ້ຈ່າຍຫນ້ອຍລົງ, ແລະຂ້ອຍສົງໄສວ່າມັນຈະເຮັດວຽກແນວໃດລະຫວ່າງເມືອງທີ່ມີໄລຍະທາງ ~ 100 ກິໂລແມັດ. ມັນ​ໄດ້​ກາຍ​ເປັນ​ທີ່​ຫນ້າ​ສົນ​ໃຈ​ທີ່ latency ລະ​ຫວ່າງ​ຕົວ​ເມືອງ​ເຫຼົ່າ​ນີ້​ແມ່ນ 100ms ສູງ​ກ​່​ວາ​ໃນ​ສະ​ບັບ​ຕົ້ນ​ສະ​ບັບ​ຂອງ​ພວກ​ເຮົາ (ກັບ​ໄຕ້​ຫວັນ​)​. ຄວາມ​ໄວ​, ຄວາມ​ສະ​ຖຽນ​ລະ​ພາບ​ແມ່ນ​ດີກ​ວ່າ​ສໍາ​ລັບ​ໄຕ້​ຫວັນ​. ດັ່ງນັ້ນ, ພວກເຮົາອອກຈາກ HK ເປັນພາກພື້ນ IPSEC ສຳຮອງ.

ນອກຈາກນັ້ນ, ພວກເຮົາໄດ້ພະຍາຍາມຕິດຕັ້ງການຕິດຕັ້ງຕໍ່ໄປນີ້:

• ການ​ຍົກ​ເລີກ​ລູກ​ຄ້າ​ຢູ່​ປັກ​ກິ່ງ
• IPSEC ແລະ CEN ໄປໂຕກຽວ,
• ໃນ Ali CDN ເຄື່ອງແມ່ຂ່າຍຂອງປັກກິ່ງໄດ້ຖືກລະບຸວ່າເປັນຕົ້ນກໍາເນີດ.

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

ຂ້າງລຸ່ມນີ້ແມ່ນສະຖິຕິກ່ຽວກັບການຕອບສະໜອງລະຫວ່າງພາກພື້ນຕ່າງໆສຳລັບຊ່ອງຕ່າງໆ. ບາງທີຄົນຈະສົນໃຈມັນ.

IPsec
Ali cn-beijing <—> GCP asia-ortheast1 — 193ms
Ali cn-shenzhen <—> GCP asia-east2 — 91ms
Ali cn-shenzhen <—> GCP us-east4 — 200ms

CEN
Ali cn-beijing <—> Ali ap-northeast-1 — 54ms (!)
Ali cn-shenzhen <—> Ali cn-hongkong — 6ms (!)
Ali cn-shenzhen <—> Ali us-east1 — 216ms

ຂໍ້ມູນທົ່ວໄປກ່ຽວກັບອິນເຕີເນັດໃນປະເທດຈີນ

ໃນຖານະເປັນການເພີ່ມເຕີມຕໍ່ກັບບັນຫາກັບອິນເຕີເນັດໄດ້ອະທິບາຍໃນຕອນຕົ້ນ, ໃນສ່ວນທໍາອິດຂອງບົດຄວາມ.

• ອິນ​ເຕີ​ເນັດ​ໃນ​ປະ​ເທດ​ຈີນ​ແມ່ນ​ຂ້ອນ​ຂ້າງ​ໄວ​ພາຍ​ໃນ​.
  • ການສະຫລຸບແມ່ນໄດ້ອີງໃສ່ການທົດສອບເຄືອຂ່າຍ Wi-Fi ສາທາລະນະໃນສະຖານທີ່ຕ່າງໆບ່ອນທີ່ເຄືອຂ່າຍເຫຼົ່ານີ້ຖືກນໍາໃຊ້ໂດຍປະຊາຊົນຈໍານວນຫລາຍ.
  • ຄວາມ​ໄວ​ການ​ດາວ​ໂຫຼດ​ແລະ​ອັບ​ໂຫຼດ​ກັບ​ເຊີບ​ເວີ​ພາຍ​ໃນ​ປະ​ເທດ​ຈີນ​ແມ່ນ​ປະ​ມານ 20 Mbit/s ແລະ 5-10 Mbit/s ຕາມ​ລຳ​ດັບ.
  • ຄວາມໄວຂອງເຄື່ອງແມ່ຂ່າຍທີ່ຢູ່ນອກປະເທດຈີນແມ່ນພຽງແຕ່ຫນ້ອຍ, ຫນ້ອຍກວ່າ 1 Mbit / s.
• ອິນ​ເຕີ​ເນັດ​ຢູ່​ຈີນ​ບໍ່​ໝັ້ນ​ທ່ຽງ​ຫຼາຍ.
  • ບາງຄັ້ງສະຖານທີ່ສາມາດເປີດໄດ້ໄວ, ບາງຄັ້ງຊ້າ (ໃນເວລາດຽວກັນຂອງມື້ໃນມື້ທີ່ແຕກຕ່າງກັນ), ສະຫນອງໃຫ້ວ່າການຕັ້ງຄ່າບໍ່ປ່ຽນແປງ. ພວກເຮົາສັງເກດເຫັນນີ້ດ້ວຍຕົວຢ່າງຂອງ semrushchina.cn. ນີ້ສາມາດເປັນຂອງ Ali CDN, ເຊິ່ງຍັງເຮັດວຽກແບບນີ້ແລະຂຶ້ນກັບເວລາຂອງມື້, ຕໍາແຫນ່ງຂອງດວງດາວ, ແລະອື່ນໆ.
• ອິນເຕີເນັດມືຖືແມ່ນເກືອບທຸກບ່ອນ 4G ຫຼື 4G+. ຈັບມັນຢູ່ໃນລົດໄຟໃຕ້ດິນ, ຟ - ໃນສັ້ນ, ຢູ່ທົ່ວທຸກແຫ່ງ.
• ມັນເປັນ myth ທີ່ຜູ້ໃຊ້ຈີນພຽງແຕ່ໄວ້ວາງໃຈໂດເມນໃນເຂດ .cn. ພວກເຮົາໄດ້ຮຽນຮູ້ເລື່ອງນີ້ໂດຍກົງຈາກຜູ້ໃຊ້.
  • ທ່ານສາມາດເບິ່ງວິທີການ http://baidu.cn ປ່ຽນເສັ້ນທາງໄປຫາ www.baidu.com (ໃນຈີນແຜ່ນດິນໃຫຍ່ເຊັ່ນກັນ).
• ຊັບພະຍາກອນຈໍານວນຫຼາຍຖືກສະກັດຢ່າງແທ້ຈິງ. ເບື້ອງຕົ້ນ: google.com, Facebook, Twitter. ແຕ່ຊັບພະຍາກອນຂອງ Google ຈໍານວນຫຼາຍເຮັດວຽກ (ແນ່ນອນ, ບໍ່ແມ່ນຢູ່ໃນ Wi-Fi ແລະ VPN ທັງຫມົດບໍ່ໄດ້ຖືກນໍາໃຊ້ (ໃນດ້ານ router ຄືກັນ, ແນ່ນອນ).
• ໂດເມນ "ດ້ານວິຊາການ" ຫຼາຍໆບໍລິສັດທີ່ຖືກບລັອກແມ່ນຍັງເຮັດວຽກ. ນີ້ຫມາຍຄວາມວ່າທ່ານບໍ່ຄວນຕັດ Google ທັງຫມົດແລະຊັບພະຍາກອນອື່ນໆທີ່ເບິ່ງຄືວ່າຖືກບລັອກຢ່າງລະມັດລະວັງ. ທ່ານຈໍາເປັນຕ້ອງຊອກຫາບາງບັນຊີລາຍຊື່ຂອງໂດເມນທີ່ຫ້າມ.
• ພວກເຂົາເຈົ້າມີພຽງແຕ່ສາມຜູ້ປະກອບການອິນເຕີເນັດຕົ້ນຕໍ: China Unicom, China Telecom, China Mobile. ມີຂະຫນາດນ້ອຍກວ່າ, ແຕ່ສ່ວນແບ່ງຕະຫຼາດຂອງພວກເຂົາແມ່ນບໍ່ສໍາຄັນ

ໂບນັດ: ແຜນວາດການແກ້ໄຂສຸດທ້າຍ

ຜົນໄດ້ຮັບ

ຫນຶ່ງປີໄດ້ຜ່ານໄປນັບຕັ້ງແຕ່ການເລີ່ມຕົ້ນຂອງໂຄງການ. ພວກເຮົາເລີ່ມຕົ້ນດ້ວຍຄວາມຈິງທີ່ວ່າເວັບໄຊທ໌ຂອງພວກເຮົາໂດຍທົ່ວໄປປະຕິເສດການເຮັດວຽກປົກກະຕິຈາກປະເທດຈີນ, ແລະພຽງແຕ່ GET curl ໃຊ້ເວລາ 5.5 ວິນາທີ.

ຫຼັງຈາກນັ້ນ, ດ້ວຍຕົວຊີ້ວັດເຫຼົ່ານີ້ໃນການແກ້ໄຂທໍາອິດ (Cloudflare):

ການຕັດສິນໃຈ
Uptime
Median
75 ເປີເຊັນ
95 ເປີເຊັນ

CloudFlare
86.6
18
30
60

ໃນທີ່ສຸດພວກເຮົາໄດ້ບັນລຸຜົນໄດ້ຮັບຕໍ່ໄປນີ້ (ສະຖິຕິສໍາລັບເດືອນທີ່ຜ່ານມາ):

ການຕັດສິນໃຈ
Uptime
Median
75 ເປີເຊັນ
95 ເປີເຊັນ

Ali CDN + CEN/IPsec + GLB
99.86
8.8
9.5
13.7

ດັ່ງທີ່ເຈົ້າສາມາດເຫັນໄດ້, ມັນຍັງບໍ່ທັນສາມາດບັນລຸ 100% uptime, ແຕ່ພວກເຮົາຈະມາກັບບາງສິ່ງບາງຢ່າງ, ແລະຫຼັງຈາກນັ້ນພວກເຮົາຈະບອກທ່ານກ່ຽວກັບຜົນໄດ້ຮັບໃນບົດຄວາມໃຫມ່ :)

ນັບຖືຜູ້ທີ່ອ່ານທັງສາມພາກຈົນຈົບ. ຂ້າ​ພະ​ເຈົ້າ​ຫວັງ​ວ່າ​ທ່ານ​ຈະ​ພົບ​ເຫັນ​ທັງ​ຫມົດ​ນີ້​ເປັນ​ທີ່​ຫນ້າ​ສົນ​ໃຈ​ທີ່​ຂ້າ​ພະ​ເຈົ້າ​ໄດ້​ເຮັດ​ໃນ​ເວ​ລາ​ທີ່​ຂ້າ​ພະ​ເຈົ້າ​ເຮັດ​ມັນ​.

PS ພາກສ່ວນທີ່ຜ່ານມາ

ສ່ວນ 1
ສ່ວນ 2

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