ಗ್ರೇಟ್ ಚೈನೀಸ್ ಫೈರ್‌ವಾಲ್ ಅನ್ನು ನಾವು ಹೇಗೆ ಭೇದಿಸಿದ್ದೇವೆ (ಭಾಗ 2)

ಹಾಯ್!

ನಿಕಿತಾ ಮತ್ತೆ ನಿಮ್ಮೊಂದಿಗೆ ಇದ್ದಾರೆ, ಕಂಪನಿಯ ಸಿಸ್ಟಂ ಇಂಜಿನಿಯರ್ SEMrush. ಮತ್ತು ಈ ಲೇಖನದೊಂದಿಗೆ ನಾವು ಪರಿಹಾರದ ಪರಿಹಾರದೊಂದಿಗೆ ಹೇಗೆ ಬಂದಿದ್ದೇವೆ ಎಂಬುದರ ಕುರಿತು ನಾನು ಕಥೆಯನ್ನು ಮುಂದುವರಿಸುತ್ತೇನೆ ಚೈನೀಸ್ ಫೈರ್ವಾಲ್ ನಮ್ಮ ಸೇವೆಗಾಗಿ semrush.com.

В ಹಿಂದಿನ ಭಾಗ ನಾನು ಹೇಳಿದೆ:

• "ನಾವು ನಮ್ಮ ಸೇವೆಯನ್ನು ಚೀನಾದಲ್ಲಿ ಕೆಲಸ ಮಾಡಬೇಕಾಗಿದೆ" ಎಂಬ ನಿರ್ಧಾರವನ್ನು ತೆಗೆದುಕೊಂಡ ನಂತರ ಯಾವ ಸಮಸ್ಯೆಗಳು ಉದ್ಭವಿಸುತ್ತವೆ
• ಚೈನೀಸ್ ಇಂಟರ್ನೆಟ್ ಯಾವ ಸಮಸ್ಯೆಗಳನ್ನು ಹೊಂದಿದೆ?
• ನಿಮಗೆ ICP ಪರವಾನಗಿ ಏಕೆ ಬೇಕು?
• ಕ್ಯಾಚ್‌ಪಾಯಿಂಟ್‌ನೊಂದಿಗೆ ನಮ್ಮ ಪರೀಕ್ಷಾ ಹಾಸಿಗೆಗಳನ್ನು ಹೇಗೆ ಮತ್ತು ಏಕೆ ಪರೀಕ್ಷಿಸಲು ನಾವು ನಿರ್ಧರಿಸಿದ್ದೇವೆ
• ಕ್ಲೌಡ್‌ಫ್ಲೇರ್ ಚೀನಾ ನೆಟ್‌ವರ್ಕ್ ಆಧಾರಿತ ನಮ್ಮ ಮೊದಲ ಪರಿಹಾರದ ಫಲಿತಾಂಶ ಏನು
• ಕ್ಲೌಡ್‌ಫ್ಲೇರ್ ಡಿಎನ್‌ಎಸ್‌ನಲ್ಲಿ ನಾವು ಹೇಗೆ ದೋಷವನ್ನು ಕಂಡುಕೊಂಡಿದ್ದೇವೆ

ಈ ಭಾಗವು ಅತ್ಯಂತ ಆಸಕ್ತಿದಾಯಕವಾಗಿದೆ, ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ, ಇದು ವೇದಿಕೆಯ ನಿರ್ದಿಷ್ಟ ತಾಂತ್ರಿಕ ಅನುಷ್ಠಾನಗಳ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸುತ್ತದೆ. ಮತ್ತು ನಾವು ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ ಅಥವಾ ಮುಂದುವರಿಯುತ್ತೇವೆ ಅಲಿಬಾಬಾ ಕ್ಲೌಡ್.

ಅಲಿಬಾಬಾ ಕ್ಲೌಡ್

ಅಲಿಬಾಬಾ ಕ್ಲೌಡ್ ಸಾಕಷ್ಟು ದೊಡ್ಡ ಕ್ಲೌಡ್ ಪ್ರೊವೈಡರ್ ಆಗಿದ್ದು, ಇದು ಕ್ಲೌಡ್ ಪ್ರೊವೈಡರ್ ಎಂದು ಪ್ರಾಮಾಣಿಕವಾಗಿ ಕರೆಯಲು ಅನುಮತಿಸುವ ಎಲ್ಲಾ ಸೇವೆಗಳನ್ನು ಹೊಂದಿದೆ. ವಿದೇಶಿ ಬಳಕೆದಾರರಿಗೆ ನೋಂದಾಯಿಸಲು ಅವರು ಅವಕಾಶವನ್ನು ಹೊಂದಿರುವುದು ಒಳ್ಳೆಯದು, ಮತ್ತು ಹೆಚ್ಚಿನ ಸೈಟ್ ಅನ್ನು ಇಂಗ್ಲಿಷ್ಗೆ ಅನುವಾದಿಸಲಾಗಿದೆ (ಚೀನಾಕ್ಕೆ ಇದು ಐಷಾರಾಮಿಯಾಗಿದೆ). ಈ ಕ್ಲೌಡ್‌ನಲ್ಲಿ, ನೀವು ಪ್ರಪಂಚದ ಅನೇಕ ಪ್ರದೇಶಗಳು, ಚೀನಾದ ಮುಖ್ಯ ಭೂಭಾಗ, ಹಾಗೆಯೇ ಓಷಿಯಾನಿಕ್ ಏಷ್ಯಾ (ಹಾಂಗ್ ಕಾಂಗ್, ತೈವಾನ್, ಇತ್ಯಾದಿ) ಜೊತೆಗೆ ಕೆಲಸ ಮಾಡಬಹುದು.

IPSEC

ನಾವು ಭೌಗೋಳಿಕತೆಯಿಂದ ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ. ನಮ್ಮ ಪರೀಕ್ಷಾ ಸೈಟ್ Google ಮೇಘದಲ್ಲಿ ನೆಲೆಗೊಂಡಿರುವುದರಿಂದ, ನಾವು GCP ಯೊಂದಿಗೆ ಅಲಿಬಾಬಾ ಕ್ಲೌಡ್ ಅನ್ನು "ಲಿಂಕ್" ಮಾಡಬೇಕಾಗಿದೆ, ಆದ್ದರಿಂದ ನಾವು Google ಇರುವ ಸ್ಥಳಗಳ ಪಟ್ಟಿಯನ್ನು ತೆರೆದಿದ್ದೇವೆ. ಆ ಕ್ಷಣದಲ್ಲಿ ಅವರು ಇನ್ನೂ ಹಾಂಗ್ ಕಾಂಗ್‌ನಲ್ಲಿ ತಮ್ಮದೇ ಆದ ಡೇಟಾ ಕೇಂದ್ರವನ್ನು ಹೊಂದಿರಲಿಲ್ಲ.
ಹತ್ತಿರದ ಪ್ರದೇಶವು ಹೊರಹೊಮ್ಮಿತು ಏಷ್ಯಾ-ಪೂರ್ವ 1 (ತೈವಾನ್). ಅಲಿ ತೈವಾನ್‌ಗೆ ಚೀನಾದ ಮುಖ್ಯ ಭೂಭಾಗದ ಹತ್ತಿರದ ಪ್ರದೇಶವಾಗಿದೆ ಸಿಎನ್-ಶೆನ್ಜೆನ್ (ಶೆನ್ಜೆನ್).

ಸಹಾಯದಿಂದ ಟೆರಾಫಾರ್ಮ್ GCP ಮತ್ತು ಅಲಿಯಲ್ಲಿ ಸಂಪೂರ್ಣ ಮೂಲಸೌಕರ್ಯವನ್ನು ವಿವರಿಸಲಾಗಿದೆ ಮತ್ತು ಹೆಚ್ಚಿಸಿದೆ. ಮೋಡಗಳ ನಡುವೆ 100 Mbit/s ಸುರಂಗವು ತಕ್ಷಣವೇ ಮೇಲಕ್ಕೆ ಹೋಯಿತು. ಶೆನ್ಜೆನ್ ಮತ್ತು ತೈವಾನ್ ಬದಿಯಲ್ಲಿ, ಪ್ರಾಕ್ಸಿಯಿಂಗ್ ವರ್ಚುವಲ್ ಯಂತ್ರಗಳನ್ನು ಬೆಳೆಸಲಾಯಿತು. ಶೆನ್‌ಜೆನ್‌ನಲ್ಲಿ, ಬಳಕೆದಾರರ ದಟ್ಟಣೆಯನ್ನು ಕೊನೆಗೊಳಿಸಲಾಗಿದೆ, ತೈವಾನ್‌ಗೆ ಸುರಂಗದ ಮೂಲಕ ಪ್ರಾಕ್ಸಿ ಮಾಡಲಾಗಿದೆ ಮತ್ತು ಅಲ್ಲಿಂದ ನೇರವಾಗಿ ನಮ್ಮ ಸೇವೆಯ ಬಾಹ್ಯ IP ಗೆ ಹೋಗುತ್ತದೆ us-ಪೂರ್ವ (ಯುಎಸ್ಎ ಈಸ್ಟ್ ಕೋಸ್ಟ್). ಸುರಂಗದ ಮೂಲಕ ವರ್ಚುವಲ್ ಯಂತ್ರಗಳ ನಡುವೆ ಪಿಂಗ್ ಮಾಡಿ 24ms, ಇದು ತುಂಬಾ ಕೆಟ್ಟದ್ದಲ್ಲ.

ಅದೇ ಸಮಯದಲ್ಲಿ, ನಾವು ಪರೀಕ್ಷಾ ಪ್ರದೇಶವನ್ನು ಇರಿಸಿದ್ದೇವೆ ಅಲಿಬಾಬಾ ಮೇಘ DNS. NS ಅಲಿಗೆ ವಲಯವನ್ನು ನಿಯೋಜಿಸಿದ ನಂತರ, ರೆಸಲ್ಯೂಶನ್ ಸಮಯವು 470 ms ಗೆ ಕಡಿಮೆಯಾಗಿದೆ 50 ms. ಇದಕ್ಕೂ ಮೊದಲು, ವಲಯವು ಕ್ಲೌಡ್‌ಫೇರ್‌ನಲ್ಲಿಯೂ ಇತ್ತು.

ಗೆ ಸುರಂಗಕ್ಕೆ ಸಮಾನಾಂತರವಾಗಿ ಏಷ್ಯಾ-ಪೂರ್ವ 1 ಶೆನ್‌ಜೆನ್‌ನಿಂದ ನೇರವಾಗಿ ಮತ್ತೊಂದು ಸುರಂಗವನ್ನು ಎತ್ತಿದರು ಯುಎಸ್-ಪೂರ್ವ 4. ಅಲ್ಲಿ ಅವರು ಹೆಚ್ಚು ಪ್ರಾಕ್ಸಿ ವರ್ಚುವಲ್ ಯಂತ್ರಗಳನ್ನು ರಚಿಸಿದರು ಮತ್ತು ಎರಡೂ ಪರಿಹಾರಗಳನ್ನು ಪರೀಕ್ಷಿಸಲು ಪ್ರಾರಂಭಿಸಿದರು, ಕುಕೀಸ್ ಅಥವಾ DNS ಅನ್ನು ಬಳಸಿಕೊಂಡು ಪರೀಕ್ಷಾ ಸಂಚಾರವನ್ನು ರೂಟಿಂಗ್ ಮಾಡಿದರು. ಪರೀಕ್ಷಾ ಬೆಂಚ್ ಅನ್ನು ಈ ಕೆಳಗಿನ ಚಿತ್ರದಲ್ಲಿ ಕ್ರಮಬದ್ಧವಾಗಿ ವಿವರಿಸಲಾಗಿದೆ:

ಸುರಂಗಗಳ ಸುಪ್ತತೆ ಈ ಕೆಳಗಿನಂತಿದೆ:
ಅಲಿ cn-shenzhen <—> GCP ಏಷ್ಯಾ-ಪೂರ್ವ1 — 24ms
ಅಲಿ cn-shenzhen <—> GCP us-east4 — 200ms

ಕ್ಯಾಚ್‌ಪಾಯಿಂಟ್ ಬ್ರೌಸರ್ ಪರೀಕ್ಷೆಗಳು ಅತ್ಯುತ್ತಮ ಸುಧಾರಣೆಯನ್ನು ವರದಿ ಮಾಡಿದೆ.

ಎರಡು ಪರಿಹಾರಗಳಿಗಾಗಿ ಪರೀಕ್ಷಾ ಫಲಿತಾಂಶಗಳನ್ನು ಹೋಲಿಕೆ ಮಾಡಿ:

ನಿರ್ಧಾರವನ್ನು
ಸಮಯ
ಮಧ್ಯಮ
75 ಶೇಕಡಾ
95 ಶೇಕಡಾ

cloudflare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

ಇದು IPSEC ಸುರಂಗದ ಮೂಲಕ ಬಳಸುವ ಪರಿಹಾರದ ಡೇಟಾ ಏಷ್ಯಾ-ಪೂರ್ವ 1. us-east4 ಮೂಲಕ ಫಲಿತಾಂಶಗಳು ಕೆಟ್ಟದಾಗಿದೆ, ಮತ್ತು ಹೆಚ್ಚಿನ ದೋಷಗಳಿವೆ, ಆದ್ದರಿಂದ ನಾನು ಫಲಿತಾಂಶಗಳನ್ನು ನೀಡುವುದಿಲ್ಲ.

ಎರಡು ಸುರಂಗಗಳ ಈ ಪರೀಕ್ಷೆಯ ಫಲಿತಾಂಶಗಳ ಆಧಾರದ ಮೇಲೆ, ಅವುಗಳಲ್ಲಿ ಒಂದನ್ನು ಚೀನಾಕ್ಕೆ ಸಮೀಪವಿರುವ ಪ್ರದೇಶದಲ್ಲಿ ಕೊನೆಗೊಳಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಇನ್ನೊಂದು ಅಂತಿಮ ಗಮ್ಯಸ್ಥಾನದಲ್ಲಿ, ಚೀನೀ ಫೈರ್‌ವಾಲ್‌ನಿಂದ ಬೇಗನೆ "ಹೊರಹೊಮ್ಮುವುದು" ಮುಖ್ಯ ಎಂದು ಸ್ಪಷ್ಟವಾಯಿತು. ಸಾಧ್ಯ, ತದನಂತರ ವೇಗದ ನೆಟ್‌ವರ್ಕ್‌ಗಳನ್ನು ಬಳಸಿ (ಸಿಡಿಎನ್ ಪೂರೈಕೆದಾರರು , ಕ್ಲೌಡ್ ಪೂರೈಕೆದಾರರು, ಇತ್ಯಾದಿ). ಫೈರ್‌ವಾಲ್ ಮೂಲಕ ಹೋಗಲು ಮತ್ತು ನಿಮ್ಮ ಗಮ್ಯಸ್ಥಾನವನ್ನು ಒಂದೇ ಹೊಡೆತದಲ್ಲಿ ಪಡೆಯಲು ಪ್ರಯತ್ನಿಸುವ ಅಗತ್ಯವಿಲ್ಲ. ಇದು ವೇಗವಾದ ಮಾರ್ಗವಲ್ಲ.

ಸಾಮಾನ್ಯವಾಗಿ, ಫಲಿತಾಂಶಗಳು ಕೆಟ್ಟದ್ದಲ್ಲ, ಆದಾಗ್ಯೂ, semrush.com ಸರಾಸರಿ 8.8 ಸೆ, ಮತ್ತು 75 ಪರ್ಸೆಂಟೈಲ್ 9.4 ಸೆ (ಅದೇ ಪರೀಕ್ಷೆಯಲ್ಲಿ) ಹೊಂದಿದೆ.
ಮತ್ತು ಮುಂದುವರಿಯುವ ಮೊದಲು, ನಾನು ಸಣ್ಣ ಸಾಹಿತ್ಯಿಕ ವ್ಯತಿರಿಕ್ತತೆಯನ್ನು ಮಾಡಲು ಬಯಸುತ್ತೇನೆ.

ಭಾವಗೀತಾತ್ಮಕ ವಿಷಯಾಂತರ

ಬಳಕೆದಾರರು ಸೈಟ್ ಅನ್ನು ಪ್ರವೇಶಿಸಿದ ನಂತರ www.semrushchina.cn, ಇದು "ವೇಗದ" ಚೈನೀಸ್ DNS ಸರ್ವರ್‌ಗಳ ಮೂಲಕ ಪರಿಹರಿಸುತ್ತದೆ, HTTP ವಿನಂತಿಯು ನಮ್ಮ ವೇಗದ ಪರಿಹಾರದ ಮೂಲಕ ಹೋಗುತ್ತದೆ. ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಅದೇ ಹಾದಿಯಲ್ಲಿ ಹಿಂತಿರುಗಿಸಲಾಗುತ್ತದೆ, ಆದರೆ ಡೊಮೇನ್ ಅನ್ನು ಎಲ್ಲಾ JS ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು, HTML ಪುಟಗಳು ಮತ್ತು ವೆಬ್ ಪುಟದ ಇತರ ಅಂಶಗಳಲ್ಲಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಲಾಗಿದೆ semrush.com ಪುಟವನ್ನು ಸಲ್ಲಿಸಿದಾಗ ಲೋಡ್ ಮಾಡಬೇಕಾದ ಹೆಚ್ಚುವರಿ ಸಂಪನ್ಮೂಲಗಳಿಗಾಗಿ. ಅಂದರೆ, ಕ್ಲೈಂಟ್ "ಮುಖ್ಯ" ಎ-ರೆಕಾರ್ಡ್ ಅನ್ನು ಪರಿಹರಿಸುತ್ತದೆ www.semrushchina.cn ಮತ್ತು ವೇಗದ ಸುರಂಗಕ್ಕೆ ಹೋಗುತ್ತದೆ, ತ್ವರಿತವಾಗಿ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಪಡೆಯುತ್ತದೆ - HTML ಪುಟವು ಹೇಳುತ್ತದೆ:

• ಅಂತಹ ಮತ್ತು ಅಂತಹ js ಅನ್ನು sso.semrush.com ನಿಂದ ಡೌನ್‌ಲೋಡ್ ಮಾಡಿ,
• cdn.semrush.com ನಿಂದ CSS ಫೈಲ್‌ಗಳನ್ನು ಪಡೆಯಿರಿ,
• ಮತ್ತು dab.semrush.com ನಿಂದ ಕೆಲವು ಚಿತ್ರಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಿ
• ಹೀಗೆ.

ಬ್ರೌಸರ್ ಈ ಸಂಪನ್ಮೂಲಗಳಿಗಾಗಿ "ಬಾಹ್ಯ" ಇಂಟರ್ನೆಟ್ಗೆ ಹೋಗಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ, ಪ್ರತಿ ಬಾರಿಯೂ ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯವನ್ನು ತಿನ್ನುವ ಫೈರ್ವಾಲ್ ಮೂಲಕ ಹಾದುಹೋಗುತ್ತದೆ.

ಆದರೆ ಹಿಂದಿನ ಪರೀಕ್ಷೆಯು ಪುಟದಲ್ಲಿ ಯಾವುದೇ ಸಂಪನ್ಮೂಲಗಳಿಲ್ಲದಿದ್ದಾಗ ಫಲಿತಾಂಶಗಳನ್ನು ತೋರಿಸುತ್ತದೆ semrush.com, ಮಾತ್ರ semrushchina.cn, ಮತ್ತು *.semrushchina.cn ನಂತರ ಸುರಂಗವನ್ನು ಪ್ರವೇಶಿಸಲು ಶೆನ್‌ಜೆನ್‌ನಲ್ಲಿರುವ ವರ್ಚುವಲ್ ಯಂತ್ರದ ವಿಳಾಸಕ್ಕೆ ಪರಿಹರಿಸುತ್ತದೆ.

ಈ ರೀತಿಯಲ್ಲಿ ಮಾತ್ರ, ಚೀನೀ ಫೈರ್‌ವಾಲ್ ಅನ್ನು ತ್ವರಿತವಾಗಿ ರವಾನಿಸಲು ನಿಮ್ಮ ಪರಿಹಾರದ ಮೂಲಕ ಸಾಧ್ಯವಿರುವ ಎಲ್ಲಾ ದಟ್ಟಣೆಯನ್ನು ಗರಿಷ್ಠವಾಗಿ ತಳ್ಳುವ ಮೂಲಕ, ನೀವು ಸ್ವೀಕಾರಾರ್ಹ ವೇಗಗಳು ಮತ್ತು ವೆಬ್‌ಸೈಟ್ ಲಭ್ಯತೆ ಸೂಚಕಗಳನ್ನು ಮತ್ತು ಪರಿಹಾರ ಪರೀಕ್ಷೆಗಳ ಪ್ರಾಮಾಣಿಕ ಫಲಿತಾಂಶಗಳನ್ನು ಪಡೆಯಬಹುದು.
ತಂಡದ ಉತ್ಪನ್ನದ ಬದಿಯಲ್ಲಿ ಒಂದೇ ಕೋಡ್ ಸಂಪಾದನೆ ಇಲ್ಲದೆ ನಾವು ಇದನ್ನು ಮಾಡಿದ್ದೇವೆ.

ಉಪ ಫಿಲ್ಟರ್

ಈ ಸಮಸ್ಯೆ ಕಾಣಿಸಿಕೊಂಡ ತಕ್ಷಣ ಪರಿಹಾರವು ಹುಟ್ಟಿಕೊಂಡಿತು. ನಮಗೆ ಬೇಕಾಗಿತ್ತು ಪಿಒಸಿ (ಪರಿಕಲ್ಪನೆಯ ಪುರಾವೆ) ನಮ್ಮ ಫೈರ್‌ವಾಲ್ ನುಗ್ಗುವ ಪರಿಹಾರಗಳು ನಿಜವಾಗಿಯೂ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. ಇದನ್ನು ಮಾಡಲು, ನೀವು ಎಲ್ಲಾ ಸೈಟ್ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಈ ಪರಿಹಾರಕ್ಕೆ ಸಾಧ್ಯವಾದಷ್ಟು ಸುತ್ತುವ ಅಗತ್ಯವಿದೆ. ಮತ್ತು ನಾವು ಅರ್ಜಿ ಸಲ್ಲಿಸಿದ್ದೇವೆ ಉಪಶೋಧಕ nginx ನಲ್ಲಿ.

ಉಪ ಫಿಲ್ಟರ್ nginx ನಲ್ಲಿ ಸಾಕಷ್ಟು ಸರಳ ಮಾಡ್ಯೂಲ್ ಆಗಿದ್ದು ಅದು ಪ್ರತಿಕ್ರಿಯೆಯ ದೇಹದಲ್ಲಿ ಒಂದು ಸಾಲನ್ನು ಮತ್ತೊಂದು ಸಾಲಿಗೆ ಬದಲಾಯಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಆದ್ದರಿಂದ ನಾವು ಎಲ್ಲಾ ಘಟನೆಗಳನ್ನು ಬದಲಾಯಿಸಿದ್ದೇವೆ semrush.com ಮೇಲೆ semrushchina.cn ಎಲ್ಲಾ ಉತ್ತರಗಳಲ್ಲಿ.

ಮತ್ತು... ಇದು ಕೆಲಸ ಮಾಡಲಿಲ್ಲ ಏಕೆಂದರೆ ನಾವು ಬ್ಯಾಕೆಂಡ್‌ಗಳಿಂದ ಸಂಕುಚಿತ ವಿಷಯವನ್ನು ಸ್ವೀಕರಿಸಿದ್ದೇವೆ, ಆದ್ದರಿಂದ ಸಬ್‌ಫಿಲ್ಟರ್ ಅಗತ್ಯವಿರುವ ಸಾಲನ್ನು ಕಂಡುಹಿಡಿಯಲಿಲ್ಲ. ನಾನು nginx ಗೆ ಇನ್ನೊಂದು ಸ್ಥಳೀಯ ಸರ್ವರ್ ಅನ್ನು ಸೇರಿಸಬೇಕಾಗಿತ್ತು, ಅದು ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಡಿಕಂಪ್ರೆಸ್ ಮಾಡಿತು ಮತ್ತು ಮುಂದಿನ ಸ್ಥಳೀಯ ಸರ್ವರ್‌ಗೆ ರವಾನಿಸಿತು, ಅದು ಈಗಾಗಲೇ ಸ್ಟ್ರಿಂಗ್ ಅನ್ನು ಬದಲಿಸುವಲ್ಲಿ, ಕುಗ್ಗಿಸುವಾಗ ಮತ್ತು ಸರಪಳಿಯಲ್ಲಿ ಮುಂದಿನ ಪ್ರಾಕ್ಸಿ ಸರ್ವರ್‌ಗೆ ಕಳುಹಿಸುವಲ್ಲಿ ನಿರತವಾಗಿತ್ತು.

ಪರಿಣಾಮವಾಗಿ, ಗ್ರಾಹಕರು ಎಲ್ಲಿ ಸ್ವೀಕರಿಸುತ್ತಾರೆ .semrush.com, ಅವರು ಸ್ವೀಕರಿಸಿದರು .semrushchina.cn ಮತ್ತು ವಿಧೇಯತೆಯಿಂದ ನಮ್ಮ ನಿರ್ಧಾರದ ಮೂಲಕ ನಡೆದರು.

ಆದಾಗ್ಯೂ, ಡೊಮೇನ್ ಅನ್ನು ಒಂದು ರೀತಿಯಲ್ಲಿ ಸರಳವಾಗಿ ಬದಲಾಯಿಸಲು ಸಾಕಾಗುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಬ್ಯಾಕೆಂಡ್‌ಗಳು ಕ್ಲೈಂಟ್‌ನಿಂದ ನಂತರದ ವಿನಂತಿಗಳಲ್ಲಿ semrush.com ಅನ್ನು ಇನ್ನೂ ನಿರೀಕ್ಷಿಸುತ್ತವೆ. ಅಂತೆಯೇ, ಏಕಮುಖ ಬದಲಿಯನ್ನು ಮಾಡುವ ಅದೇ ಸರ್ವರ್‌ನಲ್ಲಿ, ಸರಳ ನಿಯಮಿತ ಅಭಿವ್ಯಕ್ತಿಯನ್ನು ಬಳಸಿಕೊಂಡು ನಾವು ವಿನಂತಿಯಿಂದ ಸಬ್‌ಡೊಮೈನ್ ಅನ್ನು ಪಡೆಯುತ್ತೇವೆ ಮತ್ತು ನಂತರ ನಾವು ಮಾಡುತ್ತೇವೆ ಪ್ರಾಕ್ಸಿ_ಪಾಸ್ ವೇರಿಯಬಲ್ ಜೊತೆ $ ಹೋಸ್ಟ್, ನಲ್ಲಿ ಪ್ರದರ್ಶಿಸಲಾಗಿದೆ $subdomain.semrush.com. ಇದು ಗೊಂದಲಮಯವಾಗಿ ಕಾಣಿಸಬಹುದು, ಆದರೆ ಅದು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಮತ್ತು ಇದು ಚೆನ್ನಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ವಿಭಿನ್ನ ತರ್ಕದ ಅಗತ್ಯವಿರುವ ಪ್ರತ್ಯೇಕ ಡೊಮೇನ್‌ಗಳಿಗಾಗಿ, ನಿಮ್ಮ ಸ್ವಂತ ಸರ್ವರ್ ಬ್ಲಾಕ್‌ಗಳನ್ನು ರಚಿಸಿ ಮತ್ತು ಪ್ರತ್ಯೇಕ ಕಾನ್ಫಿಗರೇಶನ್ ಮಾಡಿ. ಈ ಯೋಜನೆಯ ಸ್ಪಷ್ಟತೆ ಮತ್ತು ಪ್ರದರ್ಶನಕ್ಕಾಗಿ nginx ಸಂರಚನೆಗಳನ್ನು ಕೆಳಗೆ ಸಂಕ್ಷಿಪ್ತಗೊಳಿಸಲಾಗಿದೆ.

ಕೆಳಗಿನ ಸಂರಚನೆಯು ಚೀನಾದಿಂದ ಎಲ್ಲಾ ವಿನಂತಿಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ .semrushchina.cn:

    listen 80;

    server_name ~^(?<subdomain>[w-]+).semrushchina.cn$;

    sub_filter '.semrush.com' '.semrushchina.cn';
    sub_filter_last_modified on;
    sub_filter_once off;
    sub_filter_types *;

    gzip on;
    gzip_proxied any;
    gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript;

    location / {
        proxy_pass http://127.0.0.1:8083;
        proxy_set_header Accept-Encoding "";
        proxy_set_header Host $subdomain.semrush.com;
        proxy_set_header X-Accept-Encoding $http_accept_encoding;
    }
}

ಈ ಸಂರಚನೆಯು ಇದಕ್ಕೆ ಪ್ರಾಕ್ಸಿ ಮಾಡುತ್ತದೆ ಸ್ಥಳೀಯ ಹೋಸ್ಟ್ ಪೋರ್ಟ್ 83 ಗೆ, ಮತ್ತು ಕೆಳಗಿನ ಸಂರಚನೆಯು ಅಲ್ಲಿ ಕಾಯುತ್ತಿದೆ:

    listen 127.0.0.1:8083;

    server_name *.semrush.com;

    location / {
        resolver 8.8.8.8 ipv6=off;
        gunzip on;
        proxy_pass https://$host;
        proxy_set_header Accept-Encoding gzip;
    }
}

ನಾನು ಪುನರಾವರ್ತಿಸುತ್ತೇನೆ, ಇವುಗಳು ಕತ್ತರಿಸಿದ ಸಂರಚನೆಗಳಾಗಿವೆ.

ಹಾಗೆ. ಇದು ಸಂಕೀರ್ಣವಾಗಿ ಕಾಣಿಸಬಹುದು, ಆದರೆ ಅದು ಪದಗಳಲ್ಲಿದೆ. ವಾಸ್ತವವಾಗಿ, ಆವಿಯಿಂದ ಬೇಯಿಸಿದ ಟರ್ನಿಪ್‌ಗಳಿಗಿಂತ ಎಲ್ಲವೂ ಸರಳವಾಗಿದೆ :)

ವಿಷಯಾಂತರದ ಅಂತ್ಯ

IPSEC ಸುರಂಗಗಳು ಬೀಳುವ ಪುರಾಣವನ್ನು ದೃಢೀಕರಿಸದ ಕಾರಣ ನಾವು ಸ್ವಲ್ಪ ಸಮಯದವರೆಗೆ ಸಂತೋಷಪಟ್ಟಿದ್ದೇವೆ. ಆದರೆ ನಂತರ ಸುರಂಗಗಳು ಬೀಳಲು ಪ್ರಾರಂಭಿಸಿದವು. ಕೆಲವು ನಿಮಿಷಗಳವರೆಗೆ ದಿನಕ್ಕೆ ಹಲವಾರು ಬಾರಿ. ಸ್ವಲ್ಪ, ಆದರೆ ಅದು ನಮಗೆ ಸರಿಹೊಂದುವುದಿಲ್ಲ. ಎರಡೂ ಸುರಂಗಗಳನ್ನು ಒಂದೇ ರೂಟರ್‌ನಲ್ಲಿ ಅಲಿ ಬದಿಯಲ್ಲಿ ಕೊನೆಗೊಳಿಸಲಾಗಿರುವುದರಿಂದ, ಬಹುಶಃ ಇದು ಪ್ರಾದೇಶಿಕ ಸಮಸ್ಯೆ ಎಂದು ನಾವು ನಿರ್ಧರಿಸಿದ್ದೇವೆ ಮತ್ತು ನಾವು ಬ್ಯಾಕಪ್ ಪ್ರದೇಶವನ್ನು ಹೆಚ್ಚಿಸಬೇಕಾಗಿದೆ.

ಅವರು ಅದನ್ನು ಎತ್ತಿಕೊಂಡರು. ಸುರಂಗಗಳು ವಿವಿಧ ಸಮಯಗಳಲ್ಲಿ ವಿಫಲಗೊಳ್ಳಲು ಪ್ರಾರಂಭಿಸಿದವು, ಆದರೆ ವೈಫಲ್ಯವು nginx ನಲ್ಲಿ ಅಪ್‌ಸ್ಟ್ರೀಮ್ ಮಟ್ಟದಲ್ಲಿ ನಮಗೆ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಿತು. ಆದರೆ ನಂತರ ಅದೇ ಸಮಯದಲ್ಲಿ ಸುರಂಗಗಳು ಬೀಳಲು ಪ್ರಾರಂಭಿಸಿದವು 🙂 ಮತ್ತು 502 ಮತ್ತು 504 ಮತ್ತೆ ಪ್ರಾರಂಭವಾಯಿತು. ಅಪ್ಟೈಮ್ ಕ್ಷೀಣಿಸಲು ಪ್ರಾರಂಭಿಸಿತು, ಆದ್ದರಿಂದ ನಾವು ಆಯ್ಕೆಯ ಮೇಲೆ ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ ಅಲಿಬಾಬಾ CEN (ಕ್ಲೌಡ್ ಎಂಟರ್‌ಪ್ರೈಸ್ ನೆಟ್‌ವರ್ಕ್).

ಸಿಇಎನ್

ಸಿಇಎನ್ - ಇದು ಅಲಿಬಾಬಾ ಕ್ಲೌಡ್‌ನ ವಿವಿಧ ಪ್ರದೇಶಗಳಿಂದ ಎರಡು VPC ಗಳ ಸಂಪರ್ಕವಾಗಿದೆ, ಅಂದರೆ, ನೀವು ಕ್ಲೌಡ್‌ನೊಳಗಿನ ಯಾವುದೇ ಪ್ರದೇಶಗಳ ಖಾಸಗಿ ನೆಟ್‌ವರ್ಕ್‌ಗಳನ್ನು ಪರಸ್ಪರ ಸಂಪರ್ಕಿಸಬಹುದು. ಮತ್ತು ಮುಖ್ಯವಾಗಿ: ಈ ಚಾನಲ್ ಸಾಕಷ್ಟು ಕಟ್ಟುನಿಟ್ಟನ್ನು ಹೊಂದಿದೆ ಶ್ರೀಲಂಕಾ. ಇದು ವೇಗ ಮತ್ತು ಅಪ್ಟೈಮ್ ಎರಡರಲ್ಲೂ ಬಹಳ ಸ್ಥಿರವಾಗಿರುತ್ತದೆ. ಆದರೆ ಅದು ಎಂದಿಗೂ ಸರಳವಲ್ಲ:

• ನೀವು ಚೈನೀಸ್ ಪ್ರಜೆಗಳು ಅಥವಾ ಕಾನೂನು ಘಟಕವಾಗಿಲ್ಲದಿದ್ದರೆ ಅದನ್ನು ಪಡೆಯುವುದು ತುಂಬಾ ಕಷ್ಟ,
• ಚಾನಲ್ ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್‌ನ ಪ್ರತಿ ಮೆಗಾಬಿಟ್‌ಗೆ ನೀವು ಪಾವತಿಸಬೇಕಾಗುತ್ತದೆ.

ಸಂಪರ್ಕಿಸಲು ಅವಕಾಶವಿದೆ ಚೀನಾದ ಮುಖ್ಯಭೂಭಾಗ и ಸಾಗರೋತ್ತರ, ನಾವು ಎರಡು ಅಲಿ ಪ್ರದೇಶಗಳ ನಡುವೆ CEN ಅನ್ನು ರಚಿಸಿದ್ದೇವೆ: ಸಿಎನ್-ಶೆನ್ಜೆನ್ и us-east-1 (ನಮಗೆ ಹತ್ತಿರದ ಬಿಂದು-ಪೂರ್ವ 4). ಅಲಿಯಲ್ಲಿ us-east-1 ಇನ್ನೊಂದು ವರ್ಚುವಲ್ ಗಣಕವನ್ನು ಬೆಳೆಸಿದರು ಇದರಿಂದ ಇನ್ನೂ ಒಂದು ಇರುತ್ತದೆ ಹಾಪ್.

ಇದು ಈ ರೀತಿ ಬದಲಾಯಿತು:

ಬ್ರೌಸರ್ ಪರೀಕ್ಷೆಯ ಫಲಿತಾಂಶಗಳು ಕೆಳಗಿವೆ:

ನಿರ್ಧಾರವನ್ನು
ಸಮಯ
ಮಧ್ಯಮ
75 ಶೇಕಡಾ
95 ಶೇಕಡಾ

cloudflare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

ಸಿಇಎನ್
99.75
16s
21s
27s

ಕಾರ್ಯಕ್ಷಮತೆ IPSEC ಗಿಂತ ಸ್ವಲ್ಪ ಉತ್ತಮವಾಗಿದೆ. ಆದರೆ IPSEC ಮೂಲಕ ನೀವು ಸಮರ್ಥವಾಗಿ 100 Mbit/s ವೇಗದಲ್ಲಿ ಮತ್ತು CEN ಮೂಲಕ 5 Mbit/s ಮತ್ತು ಹೆಚ್ಚಿನ ವೇಗದಲ್ಲಿ ಡೌನ್‌ಲೋಡ್ ಮಾಡಬಹುದು.

ಹೈಬ್ರಿಡ್‌ನಂತೆ ಧ್ವನಿಸುತ್ತದೆ, ಸರಿ? IPSEC ವೇಗ ಮತ್ತು CEN ಸ್ಥಿರತೆಯನ್ನು ಸಂಯೋಜಿಸಿ.

IPSEC ಸುರಂಗದ ವೈಫಲ್ಯದ ಸಂದರ್ಭದಲ್ಲಿ IPSEC ಮತ್ತು CEN ಎರಡರ ಮೂಲಕ ಸಂಚಾರವನ್ನು ಅನುಮತಿಸುವ ಮೂಲಕ ನಾವು ಇದನ್ನು ಮಾಡಿದ್ದೇವೆ. ಅಪ್ಟೈಮ್ ಹೆಚ್ಚು ಹೆಚ್ಚಾಗಿದೆ, ಆದರೆ ಸೈಟ್ ಲೋಡಿಂಗ್ ವೇಗವು ಇನ್ನೂ ಅಪೇಕ್ಷಿತವಾಗಿರುವುದನ್ನು ಬಿಟ್ಟುಬಿಡುತ್ತದೆ. ನಂತರ ನಾವು ಈಗಾಗಲೇ ಬಳಸಿದ ಮತ್ತು ಪರೀಕ್ಷಿಸಿದ ಎಲ್ಲಾ ಸರ್ಕ್ಯೂಟ್‌ಗಳನ್ನು ನಾನು ಸೆಳೆಯುತ್ತೇನೆ ಮತ್ತು ಈ ಸರ್ಕ್ಯೂಟ್‌ಗೆ ಸ್ವಲ್ಪ ಹೆಚ್ಚು GCP ಅನ್ನು ಸೇರಿಸಲು ಪ್ರಯತ್ನಿಸಲು ನಿರ್ಧರಿಸಿದೆ, ಅವುಗಳೆಂದರೆ ಜಿಎಲ್‌ಬಿ.

ಜಿಎಲ್‌ಬಿ

ಜಿಎಲ್‌ಬಿ - ಇದು ಗ್ಲೋಬಲ್ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ (ಅಥವಾ Google ಕ್ಲೌಡ್ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್). ಇದು ನಮಗೆ ಒಂದು ಪ್ರಮುಖ ಪ್ರಯೋಜನವನ್ನು ಹೊಂದಿದೆ: CDN ನ ಸಂದರ್ಭದಲ್ಲಿ ಅದು ಹೊಂದಿದೆ anycast IP, ಕ್ಲೈಂಟ್‌ಗೆ ಸಮೀಪವಿರುವ ಡೇಟಾ ಸೆಂಟರ್‌ಗೆ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಮಾರ್ಗ ಮಾಡಲು ಇದು ನಿಮ್ಮನ್ನು ಅನುಮತಿಸುತ್ತದೆ, ಇದರಿಂದಾಗಿ ಟ್ರಾಫಿಕ್ ತ್ವರಿತವಾಗಿ Google ನ ವೇಗದ ನೆಟ್‌ವರ್ಕ್‌ಗೆ ಸೇರುತ್ತದೆ ಮತ್ತು ಕಡಿಮೆ "ನಿಯಮಿತ" ಇಂಟರ್ನೆಟ್ ಮೂಲಕ ಹೋಗುತ್ತದೆ.

ಎರಡು ಬಾರಿ ಯೋಚಿಸದೆ, ನಾವು ಬೆಳೆಸಿದೆವು HTTP/HTTPS LB ನಾವು ನಮ್ಮ ವರ್ಚುವಲ್ ಯಂತ್ರಗಳನ್ನು ಜಿಸಿಪಿಯಲ್ಲಿ ಸಬ್‌ಫಿಲ್ಟರ್‌ನೊಂದಿಗೆ ಮತ್ತು ಬ್ಯಾಕೆಂಡ್‌ನಂತೆ ಸ್ಥಾಪಿಸಿದ್ದೇವೆ.

ಹಲವಾರು ಯೋಜನೆಗಳು ಇದ್ದವು:

• ಬಳಸಲು ಕ್ಲೌಡ್‌ಫ್ಲೇರ್ ಚೀನಾ ನೆಟ್‌ವರ್ಕ್, ಆದರೆ ಈ ಬಾರಿ ಮೂಲವು ಜಾಗತಿಕವಾಗಿ ಸೂಚಿಸಬೇಕು IP GLB.
• ನಲ್ಲಿ ಗ್ರಾಹಕರನ್ನು ಕೊನೆಗೊಳಿಸಿ ಸಿಎನ್-ಶೆನ್ಜೆನ್, ಮತ್ತು ಅಲ್ಲಿಂದ ನೇರವಾಗಿ ಸಂಚಾರವನ್ನು ಪ್ರಾಕ್ಸಿ ಮಾಡಿ ಜಿಎಲ್‌ಬಿ.
• ಚೀನಾದಿಂದ ನೇರವಾಗಿ ಹೋಗಿ ಜಿಎಲ್‌ಬಿ.
• ನಲ್ಲಿ ಗ್ರಾಹಕರನ್ನು ಕೊನೆಗೊಳಿಸಿ ಸಿಎನ್-ಶೆನ್ಜೆನ್, ಅಲ್ಲಿಂದ ಪ್ರಾಕ್ಸಿ ಗೆ ಏಷ್ಯಾ-ಪೂರ್ವ 1 IPSEC ಮೂಲಕ (ಇನ್ ಯುಎಸ್-ಪೂರ್ವ 4 CEN ಮೂಲಕ), ಅಲ್ಲಿಂದ GLB ಗೆ ಹೋಗಿ (ಶಾಂತವಾಗಿ, ಕೆಳಗೆ ಚಿತ್ರ ಮತ್ತು ವಿವರಣೆ ಇರುತ್ತದೆ)

ನಾವು ಈ ಎಲ್ಲಾ ಆಯ್ಕೆಗಳನ್ನು ಮತ್ತು ಹಲವಾರು ಹೈಬ್ರಿಡ್ ಆಯ್ಕೆಗಳನ್ನು ಪರೀಕ್ಷಿಸಿದ್ದೇವೆ:

• ಕ್ಲೌಡ್‌ಫ್ಲೇರ್ + GLB

ಅಪ್‌ಟೈಮ್ ಮತ್ತು DNS ದೋಷಗಳಿಂದಾಗಿ ಈ ಯೋಜನೆಯು ನಮಗೆ ಸರಿಹೊಂದುವುದಿಲ್ಲ. ಆದರೆ CF ಬದಿಯಲ್ಲಿ ದೋಷವನ್ನು ಸರಿಪಡಿಸುವ ಮೊದಲು ಪರೀಕ್ಷೆಯನ್ನು ನಡೆಸಲಾಯಿತು, ಬಹುಶಃ ಅದು ಈಗ ಉತ್ತಮವಾಗಿದೆ (ಆದಾಗ್ಯೂ, ಇದು HTTP ಸಮಯ ಮೀರುವಿಕೆಯನ್ನು ಹೊರತುಪಡಿಸುವುದಿಲ್ಲ).

• ಅಲಿ + GLB

ಅಪ್‌ಟೈಮ್‌ಗೆ ಸಂಬಂಧಿಸಿದಂತೆ ಈ ಯೋಜನೆಯು ನಮಗೆ ಸರಿಹೊಂದುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಸ್ವೀಕಾರಾರ್ಹ ಸಮಯ ಅಥವಾ ಸಮಯ ಮೀರುವ ಸಮಯದಲ್ಲಿ ಸಂಪರ್ಕಿಸಲು ಅಸಾಧ್ಯವಾದ ಕಾರಣ GLB ಹೆಚ್ಚಾಗಿ ಅಪ್‌ಸ್ಟ್ರೀಮ್‌ನಿಂದ ಹೊರಗುಳಿಯುತ್ತದೆ, ಏಕೆಂದರೆ ಚೀನಾದೊಳಗಿನ ಸರ್ವರ್‌ಗಾಗಿ, GLB ವಿಳಾಸವು ಹೊರಗಿರುತ್ತದೆ ಮತ್ತು ಆದ್ದರಿಂದ ಹಿಂದೆ ಚೈನೀಸ್ ಫೈರ್ವಾಲ್. ಮ್ಯಾಜಿಕ್ ನಡೆಯಲಿಲ್ಲ.

• GLB ಮಾತ್ರ

ಹಿಂದಿನದಕ್ಕೆ ಹೋಲುವ ಒಂದು ಆಯ್ಕೆ, ಇದು ಚೀನಾದಲ್ಲಿಯೇ ಸರ್ವರ್‌ಗಳನ್ನು ಬಳಸಲಿಲ್ಲ: ಸಂಚಾರ ನೇರವಾಗಿ GLB ಗೆ ಹೋಯಿತು (DNS ದಾಖಲೆಗಳನ್ನು ಬದಲಾಯಿಸಲಾಗಿದೆ). ಅಂತೆಯೇ, ಫಲಿತಾಂಶಗಳು ತೃಪ್ತಿಕರವಾಗಿಲ್ಲ, ಏಕೆಂದರೆ ಸಾಮಾನ್ಯ ಇಂಟರ್ನೆಟ್ ಪೂರೈಕೆದಾರರ ಸೇವೆಗಳನ್ನು ಬಳಸುವ ಸಾಮಾನ್ಯ ಚೈನೀಸ್ ಕ್ಲೈಂಟ್‌ಗಳು ಅಲಿ ಕ್ಲೌಡ್‌ಗಿಂತ ಫೈರ್‌ವಾಲ್ ಅನ್ನು ಹಾದುಹೋಗುವಲ್ಲಿ ಕೆಟ್ಟ ಪರಿಸ್ಥಿತಿಯನ್ನು ಹೊಂದಿದ್ದಾರೆ.

• ಶೆನ್ಜೆನ್ -> (CEN/IPSEC) -> ಪ್ರಾಕ್ಸಿ -> GLB

ಇಲ್ಲಿ ನಾವು ಎಲ್ಲಾ ಅತ್ಯುತ್ತಮ ಪರಿಹಾರಗಳನ್ನು ಬಳಸಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ:

• CEN ನಿಂದ ಸ್ಥಿರತೆ ಮತ್ತು ಖಾತರಿ SLA
• IPSEC ಯಿಂದ ಹೆಚ್ಚಿನ ವೇಗ
• Google ನ "ವೇಗದ" ನೆಟ್‌ವರ್ಕ್ ಮತ್ತು ಅದರ ಯಾವುದೇ ಕಾಸ್ಟ್.

ಯೋಜನೆಯು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ: ವರ್ಚುವಲ್ ಗಣಕದಲ್ಲಿ ಬಳಕೆದಾರರ ದಟ್ಟಣೆಯನ್ನು ಕೊನೆಗೊಳಿಸಲಾಗುತ್ತದೆ ch-shenzhen. Nginx ಅಪ್‌ಸ್ಟ್ರೀಮ್‌ಗಳನ್ನು ಅಲ್ಲಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ, ಅವುಗಳಲ್ಲಿ ಕೆಲವು IPSEC ಸುರಂಗದ ಇನ್ನೊಂದು ತುದಿಯಲ್ಲಿರುವ ಖಾಸಗಿ IP ಸರ್ವರ್‌ಗಳಿಗೆ ಸೂಚಿಸುತ್ತವೆ ಮತ್ತು ಕೆಲವು ಅಪ್‌ಸ್ಟ್ರೀಮ್‌ಗಳು CEN ನ ಇನ್ನೊಂದು ಬದಿಯಲ್ಲಿರುವ ಸರ್ವರ್‌ಗಳ ಖಾಸಗಿ ವಿಳಾಸಗಳನ್ನು ಸೂಚಿಸುತ್ತವೆ. IPSEC ಪ್ರದೇಶಕ್ಕೆ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ ಏಷ್ಯಾ-ಪೂರ್ವ 1 GCP ಯಲ್ಲಿ (ಪರಿಹಾರವನ್ನು ರಚಿಸುವ ಸಮಯದಲ್ಲಿ ಚೀನಾಕ್ಕೆ ಹತ್ತಿರದ ಪ್ರದೇಶವಾಗಿತ್ತು. GCP ಈಗ ಹಾಂಗ್ ಕಾಂಗ್‌ನಲ್ಲಿ ಸಹ ಅಸ್ತಿತ್ವವನ್ನು ಹೊಂದಿದೆ). CEN - ಪ್ರದೇಶಕ್ಕೆ ಯುಎಸ್-ಪೂರ್ವ 1 ಅಲಿ ಕ್ಲೌಡ್‌ನಲ್ಲಿ.

ನಂತರ ಎರಡೂ ಕಡೆಯಿಂದ ಸಂಚಾರಕ್ಕೆ ನಿರ್ದೇಶನ ನೀಡಲಾಯಿತು anycast IP GLB, ಅಂದರೆ, Google ಉಪಸ್ಥಿತಿಯ ಹತ್ತಿರದ ಬಿಂದುವಿಗೆ, ಮತ್ತು ಅದರ ನೆಟ್‌ವರ್ಕ್‌ಗಳ ಮೂಲಕ ಪ್ರದೇಶಕ್ಕೆ ಹೋಯಿತು ಯುಎಸ್-ಪೂರ್ವ 4 GCP ಯಲ್ಲಿ, ಬದಲಿ ವರ್ಚುವಲ್ ಯಂತ್ರಗಳು ಇದ್ದವು (nginx ನಲ್ಲಿ ಉಪ ಫಿಲ್ಟರ್‌ನೊಂದಿಗೆ).

ಈ ಹೈಬ್ರಿಡ್ ಪರಿಹಾರ, ನಾವು ನಿರೀಕ್ಷಿಸಿದಂತೆ, ಪ್ರತಿ ತಂತ್ರಜ್ಞಾನದ ಪ್ರಯೋಜನಗಳ ಲಾಭವನ್ನು ಪಡೆದುಕೊಂಡಿದೆ. ಸಾಮಾನ್ಯವಾಗಿ, ಟ್ರಾಫಿಕ್ ವೇಗದ IPSEC ಮೂಲಕ ಹೋಗುತ್ತದೆ, ಆದರೆ ಸಮಸ್ಯೆಗಳು ಪ್ರಾರಂಭವಾದರೆ, ನಾವು ತ್ವರಿತವಾಗಿ ಮತ್ತು ಕೆಲವು ನಿಮಿಷಗಳ ಕಾಲ ಈ ಸರ್ವರ್‌ಗಳನ್ನು ಅಪ್‌ಸ್ಟ್ರೀಮ್‌ನಿಂದ ಹೊರಹಾಕುತ್ತೇವೆ ಮತ್ತು ಸುರಂಗವು ಸ್ಥಿರಗೊಳ್ಳುವವರೆಗೆ CEN ಮೂಲಕ ಮಾತ್ರ ಸಂಚಾರವನ್ನು ಕಳುಹಿಸುತ್ತೇವೆ.

ಮೇಲಿನ ಪಟ್ಟಿಯಿಂದ 4 ನೇ ಪರಿಹಾರವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಮೂಲಕ, ಆ ಸಮಯದಲ್ಲಿ ನಾವು ಬಯಸಿದ್ದನ್ನು ಮತ್ತು ವ್ಯಾಪಾರವು ನಮಗೆ ಬೇಕಾದುದನ್ನು ನಾವು ಸಾಧಿಸಿದ್ದೇವೆ.

ಹಿಂದಿನ ಪರಿಹಾರಗಳಿಗೆ ಹೋಲಿಸಿದರೆ ಹೊಸ ಪರಿಹಾರಕ್ಕಾಗಿ ಬ್ರೌಸರ್ ಪರೀಕ್ಷೆಯ ಫಲಿತಾಂಶಗಳು:

ನಿರ್ಧಾರವನ್ನು
ಸಮಯ
ಮಧ್ಯಮ
75 ಶೇಕಡಾ
95 ಶೇಕಡಾ

cloudflare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

ಸಿಇಎನ್
99.75
16s
21s
27s

CEN/IPsec + GLB
99.79
13s
16s
25s

ಸಿಡಿಎನ್

ನಾವು ಜಾರಿಗೊಳಿಸಿದ ಪರಿಹಾರದಲ್ಲಿ ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿದೆ, ಆದರೆ ಪ್ರಾದೇಶಿಕ ಮತ್ತು ನಗರ ಮಟ್ಟದಲ್ಲಿ ಸಂಚಾರವನ್ನು ವೇಗಗೊಳಿಸುವ ಯಾವುದೇ CDN ಇಲ್ಲ. ಸಿದ್ಧಾಂತದಲ್ಲಿ, ಇದು CDN ಪೂರೈಕೆದಾರರ ವೇಗದ ಸಂವಹನ ಚಾನಲ್‌ಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಅಂತಿಮ ಬಳಕೆದಾರರಿಗೆ ಸೈಟ್ ಅನ್ನು ವೇಗಗೊಳಿಸುತ್ತದೆ. ಮತ್ತು ನಾವು ಅದರ ಬಗ್ಗೆ ಸಾರ್ವಕಾಲಿಕ ಯೋಚಿಸಿದ್ದೇವೆ. ಮತ್ತು ಈಗ, ಯೋಜನೆಯ ಮುಂದಿನ ಪುನರಾವರ್ತನೆಯ ಸಮಯ ಬಂದಿದೆ: ಚೀನಾದಲ್ಲಿ CDN ಪೂರೈಕೆದಾರರನ್ನು ಹುಡುಕುವುದು ಮತ್ತು ಪರೀಕ್ಷಿಸುವುದು.

ಮತ್ತು ಮುಂದಿನ, ಅಂತಿಮ ಭಾಗದಲ್ಲಿ ನಾನು ಇದರ ಬಗ್ಗೆ ಹೇಳುತ್ತೇನೆ :)

ಮೂಲ: www.habr.com