ਅਸੀਂ ਮਹਾਨ ਚੀਨੀ ਫਾਇਰਵਾਲ ਨੂੰ ਕਿਵੇਂ ਤੋੜਿਆ (ਭਾਗ 2)

ਹੈਲੋ!

ਨਿਕਿਤਾ ਫਿਰ ਤੁਹਾਡੇ ਨਾਲ ਹੈ, ਕੰਪਨੀ ਦੀ ਇੱਕ ਸਿਸਟਮ ਇੰਜੀਨੀਅਰ SEMrush. ਅਤੇ ਇਸ ਲੇਖ ਦੇ ਨਾਲ ਮੈਂ ਇਸ ਬਾਰੇ ਕਹਾਣੀ ਨੂੰ ਜਾਰੀ ਰੱਖਦਾ ਹਾਂ ਕਿ ਅਸੀਂ ਇੱਕ ਹੱਲ ਦੇ ਨਾਲ ਕਿਵੇਂ ਆਏ ਹਾਂ ਚੀਨੀ ਫਾਇਰਵਾਲ ਸਾਡੀ ਸੇਵਾ semrush.com ਲਈ।

В ਪਿਛਲੇ ਭਾਗ ਮੈਂ ਕਿਹਾ:

• ਫੈਸਲਾ ਲੈਣ ਤੋਂ ਬਾਅਦ ਕਿਹੜੀਆਂ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਹੁੰਦੀਆਂ ਹਨ "ਸਾਨੂੰ ਚੀਨ ਵਿੱਚ ਸਾਡੀ ਸੇਵਾ ਨੂੰ ਕੰਮ ਕਰਨ ਦੀ ਲੋੜ ਹੈ"
• ਚੀਨੀ ਇੰਟਰਨੈਟ ਵਿੱਚ ਕਿਹੜੀਆਂ ਸਮੱਸਿਆਵਾਂ ਹਨ?
• ਤੁਹਾਨੂੰ ICP ਲਾਇਸੈਂਸ ਦੀ ਲੋੜ ਕਿਉਂ ਹੈ?
• ਅਸੀਂ ਕੈਚਪੁਆਇੰਟ ਨਾਲ ਆਪਣੇ ਟੈਸਟਬੈੱਡਾਂ ਦੀ ਜਾਂਚ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕਿਵੇਂ ਅਤੇ ਕਿਉਂ ਕੀਤਾ
• Cloudflare ਚਾਈਨਾ ਨੈੱਟਵਰਕ 'ਤੇ ਆਧਾਰਿਤ ਸਾਡੇ ਪਹਿਲੇ ਹੱਲ ਦਾ ਨਤੀਜਾ ਕੀ ਸੀ
• ਸਾਨੂੰ Cloudflare DNS ਵਿੱਚ ਇੱਕ ਬੱਗ ਕਿਵੇਂ ਮਿਲਿਆ

ਇਹ ਹਿੱਸਾ ਸਭ ਤੋਂ ਦਿਲਚਸਪ ਹੈ, ਮੇਰੀ ਰਾਏ ਵਿੱਚ, ਕਿਉਂਕਿ ਇਹ ਸਟੇਜਿੰਗ ਦੇ ਖਾਸ ਤਕਨੀਕੀ ਲਾਗੂਕਰਨ 'ਤੇ ਕੇਂਦ੍ਰਤ ਕਰਦਾ ਹੈ. ਅਤੇ ਅਸੀਂ ਇਸ ਨਾਲ ਸ਼ੁਰੂ ਕਰਾਂਗੇ, ਜਾਂ ਜਾਰੀ ਰੱਖਾਂਗੇ ਅਲੀਬਬਾ ਕ੍ਲਾਉਡ.

ਅਲੀਬਬਾ ਕ੍ਲਾਉਡ

ਅਲੀਬਬਾ ਕ੍ਲਾਉਡ ਇੱਕ ਕਾਫ਼ੀ ਵੱਡਾ ਕਲਾਉਡ ਪ੍ਰਦਾਤਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਸਾਰੀਆਂ ਸੇਵਾਵਾਂ ਹਨ ਜੋ ਇਸਨੂੰ ਇਮਾਨਦਾਰੀ ਨਾਲ ਆਪਣੇ ਆਪ ਨੂੰ ਇੱਕ ਕਲਾਉਡ ਪ੍ਰਦਾਤਾ ਕਹਿਣ ਦੀ ਆਗਿਆ ਦਿੰਦੀਆਂ ਹਨ। ਇਹ ਚੰਗਾ ਹੈ ਕਿ ਉਹਨਾਂ ਕੋਲ ਵਿਦੇਸ਼ੀ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਰਜਿਸਟਰ ਕਰਨ ਦਾ ਮੌਕਾ ਹੈ, ਅਤੇ ਇਹ ਕਿ ਜ਼ਿਆਦਾਤਰ ਸਾਈਟ ਦਾ ਅੰਗਰੇਜ਼ੀ ਵਿੱਚ ਅਨੁਵਾਦ ਕੀਤਾ ਗਿਆ ਹੈ (ਚੀਨ ਲਈ ਇਹ ਇੱਕ ਲਗਜ਼ਰੀ ਹੈ)। ਇਸ ਕਲਾਉਡ ਵਿੱਚ, ਤੁਸੀਂ ਦੁਨੀਆ ਦੇ ਬਹੁਤ ਸਾਰੇ ਖੇਤਰਾਂ, ਮੁੱਖ ਭੂਮੀ ਚੀਨ, ਅਤੇ ਨਾਲ ਹੀ ਸਮੁੰਦਰੀ ਏਸ਼ੀਆ (ਹਾਂਗਕਾਂਗ, ਤਾਈਵਾਨ, ਆਦਿ) ਨਾਲ ਕੰਮ ਕਰ ਸਕਦੇ ਹੋ।

ਆਈ.ਪੀ.ਐੱਸ.ਈ.ਸੀ

ਅਸੀਂ ਭੂਗੋਲ ਨਾਲ ਸ਼ੁਰੂਆਤ ਕੀਤੀ। ਕਿਉਂਕਿ ਸਾਡੀ ਟੈਸਟ ਸਾਈਟ ਗੂਗਲ ਕਲਾਉਡ 'ਤੇ ਸਥਿਤ ਸੀ, ਸਾਨੂੰ ਅਲੀਬਾਬਾ ਕਲਾਉਡ ਨੂੰ GCP ਨਾਲ "ਲਿੰਕ" ਕਰਨ ਦੀ ਲੋੜ ਸੀ, ਇਸਲਈ ਅਸੀਂ ਉਹਨਾਂ ਸਥਾਨਾਂ ਦੀ ਇੱਕ ਸੂਚੀ ਖੋਲ੍ਹੀ ਜਿੱਥੇ Google ਮੌਜੂਦ ਹੈ। ਉਸ ਸਮੇਂ ਉਨ੍ਹਾਂ ਕੋਲ ਹਾਂਗਕਾਂਗ ਵਿੱਚ ਆਪਣਾ ਡਾਟਾ ਸੈਂਟਰ ਨਹੀਂ ਸੀ।
ਸਭ ਤੋਂ ਨੇੜਲਾ ਖੇਤਰ ਨਿਕਲਿਆ asia-east1 (ਤਾਈਵਾਨ)। ਅਲੀ ਮੁੱਖ ਭੂਮੀ ਚੀਨ ਦਾ ਤਾਇਵਾਨ ਦਾ ਸਭ ਤੋਂ ਨਜ਼ਦੀਕੀ ਖੇਤਰ ਨਿਕਲਿਆ cn-ਸ਼ੇਨਜ਼ੇਨ (ਸ਼ੇਨਜ਼ੇਨ)।

ਦੀ ਸਹਾਇਤਾ ਨਾਲ ਟਰਾਫਾਰਮ ਨੇ ਜੀਸੀਪੀ ਅਤੇ ਅਲੀ ਵਿੱਚ ਪੂਰੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦਾ ਵਰਣਨ ਕੀਤਾ ਅਤੇ ਉਭਾਰਿਆ। ਬੱਦਲਾਂ ਦੇ ਵਿਚਕਾਰ ਇੱਕ 100 Mbit/s ਸੁਰੰਗ ਲਗਭਗ ਤੁਰੰਤ ਉੱਪਰ ਚਲੀ ਗਈ। ਸ਼ੇਨਜ਼ੇਨ ਅਤੇ ਤਾਈਵਾਨ ਦੇ ਪਾਸੇ, ਪ੍ਰੌਕਸੀਿੰਗ ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਨੂੰ ਉਭਾਰਿਆ ਗਿਆ ਸੀ. ਸ਼ੇਨਜ਼ੇਨ ਵਿੱਚ, ਉਪਭੋਗਤਾ ਟ੍ਰੈਫਿਕ ਨੂੰ ਬੰਦ ਕਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, ਇੱਕ ਸੁਰੰਗ ਰਾਹੀਂ ਤਾਈਵਾਨ ਨੂੰ ਪ੍ਰੌਕਸੀ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਉੱਥੋਂ ਇਹ ਸਿੱਧਾ ਸਾਡੀ ਸੇਵਾ ਦੇ ਬਾਹਰੀ IP ਵਿੱਚ ਜਾਂਦਾ ਹੈ। us-ਪੂਰਬ (ਅਮਰੀਕਾ ਈਸਟ ਕੋਸਟ)। ਸੁਰੰਗ ਰਾਹੀਂ ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਵਿਚਕਾਰ ਪਿੰਗ 24ms, ਜੋ ਕਿ ਇੰਨਾ ਬੁਰਾ ਨਹੀਂ ਹੈ।

ਉਸੇ ਸਮੇਂ, ਅਸੀਂ ਇੱਕ ਟੈਸਟ ਖੇਤਰ ਵਿੱਚ ਰੱਖਿਆ ਅਲੀਬਾਬਾ ਕਲਾਊਡ DNS. ਐਨਐਸ ਅਲੀ ਨੂੰ ਜ਼ੋਨ ਸੌਂਪਣ ਤੋਂ ਬਾਅਦ, ਰੈਜ਼ੋਲਿਊਸ਼ਨ ਦਾ ਸਮਾਂ 470 ਐਮਐਸ ਤੋਂ ਘਟ ਗਿਆ 50 ਮੀ. ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਜ਼ੋਨ ਕਲਾਊਡਫੇਅਰ 'ਤੇ ਵੀ ਸੀ।

ਨੂੰ ਸੁਰੰਗ ਦੇ ਸਮਾਨਾਂਤਰ asia-east1 ਸ਼ੇਨਜ਼ੇਨ ਤੋਂ ਸਿੱਧੀ ਇਕ ਹੋਰ ਸੁਰੰਗ ਨੂੰ ਉਭਾਰਿਆ us-east4. ਉੱਥੇ ਉਹਨਾਂ ਨੇ ਹੋਰ ਪ੍ਰੌਕਸੀ ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਬਣਾਈਆਂ ਅਤੇ ਕੂਕੀਜ਼ ਜਾਂ DNS ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਟੈਸਟ ਟਰੈਫਿਕ ਨੂੰ ਰੂਟਿੰਗ, ਦੋਨਾਂ ਹੱਲਾਂ ਦੀ ਜਾਂਚ ਕਰਨੀ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤੀ। ਟੈਸਟ ਬੈਂਚ ਨੂੰ ਹੇਠਾਂ ਦਿੱਤੇ ਚਿੱਤਰ ਵਿੱਚ ਯੋਜਨਾਬੱਧ ਢੰਗ ਨਾਲ ਦਰਸਾਇਆ ਗਿਆ ਹੈ:

ਸੁਰੰਗਾਂ ਲਈ ਲੇਟੈਂਸੀ ਹੇਠ ਲਿਖੇ ਅਨੁਸਾਰ ਨਿਕਲੀ:
ਅਲੀ cn-ਸ਼ੇਨਜ਼ੇਨ <—> GCP asia-east1 — 24ms
ਅਲੀ cn-ਸ਼ੇਨਜ਼ੇਨ <—> GCP us-east4 — 200ms

ਕੈਚਪੁਆਇੰਟ ਬ੍ਰਾਊਜ਼ਰ ਟੈਸਟਾਂ ਨੇ ਸ਼ਾਨਦਾਰ ਸੁਧਾਰ ਦੀ ਰਿਪੋਰਟ ਕੀਤੀ.

ਦੋ ਹੱਲਾਂ ਲਈ ਟੈਸਟ ਦੇ ਨਤੀਜਿਆਂ ਦੀ ਤੁਲਨਾ ਕਰੋ:

ਫੈਸਲੇ ਦਾ
ਅਪਿਟਾਈਮ
ਮੱਧਮਾਨ
75 ਪ੍ਰਤੀਸ਼ਤ
95 ਪ੍ਰਤੀਸ਼ਤ

Cloudflare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

ਇਹ ਇੱਕ ਹੱਲ ਤੋਂ ਡੇਟਾ ਹੈ ਜੋ ਇੱਕ IPSEC ਸੁਰੰਗ ਦੁਆਰਾ ਵਰਤਦਾ ਹੈ asia-east1. us-east4 ਦੁਆਰਾ ਨਤੀਜੇ ਬਦਤਰ ਸਨ, ਅਤੇ ਹੋਰ ਤਰੁੱਟੀਆਂ ਸਨ, ਇਸਲਈ ਮੈਂ ਨਤੀਜੇ ਨਹੀਂ ਦੇਵਾਂਗਾ।

ਦੋ ਸੁਰੰਗਾਂ ਦੇ ਇਸ ਪਰੀਖਣ ਦੇ ਨਤੀਜਿਆਂ ਦੇ ਆਧਾਰ 'ਤੇ, ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਇੱਕ ਚੀਨ ਦੇ ਸਭ ਤੋਂ ਨਜ਼ਦੀਕੀ ਖੇਤਰ ਵਿੱਚ ਖਤਮ ਹੋ ਗਈ ਹੈ, ਅਤੇ ਦੂਜੀ ਨੂੰ ਅੰਤਮ ਮੰਜ਼ਿਲ 'ਤੇ, ਇਹ ਸਪੱਸ਼ਟ ਹੋ ਗਿਆ ਹੈ ਕਿ ਚੀਨੀ ਫਾਇਰਵਾਲ ਦੇ ਹੇਠਾਂ ਤੋਂ ਜਿੰਨੀ ਜਲਦੀ "ਉਭਰਨਾ" ਜ਼ਰੂਰੀ ਹੈ। ਸੰਭਵ ਹੈ, ਅਤੇ ਫਿਰ ਤੇਜ਼ ਨੈੱਟਵਰਕ (CDN ਪ੍ਰਦਾਤਾ, ਕਲਾਉਡ ਪ੍ਰਦਾਤਾ, ਆਦਿ) ਦੀ ਵਰਤੋਂ ਕਰੋ। ਫਾਇਰਵਾਲ ਵਿੱਚੋਂ ਲੰਘਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਦੀ ਕੋਈ ਲੋੜ ਨਹੀਂ ਹੈ ਅਤੇ ਇੱਕ ਝਟਕੇ ਵਿੱਚ ਆਪਣੀ ਮੰਜ਼ਿਲ 'ਤੇ ਪਹੁੰਚਣ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਇਹ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਨਹੀਂ ਹੈ।

ਆਮ ਤੌਰ 'ਤੇ, ਨਤੀਜੇ ਮਾੜੇ ਨਹੀਂ ਹੁੰਦੇ, ਹਾਲਾਂਕਿ, semrush.com ਦਾ ਮੱਧਮਾਨ 8.8s, ਅਤੇ 75 ਪ੍ਰਤੀਸ਼ਤ 9.4s (ਉਸੇ ਟੈਸਟ 'ਤੇ) ਹੈ।
ਅਤੇ ਅੱਗੇ ਵਧਣ ਤੋਂ ਪਹਿਲਾਂ, ਮੈਂ ਇੱਕ ਛੋਟਾ ਜਿਹਾ ਗੀਤਕਾਰੀ ਵਿਖਿਆਨ ਕਰਨਾ ਚਾਹਾਂਗਾ।

ਕਥਾਵਚਨ

ਉਪਭੋਗਤਾ ਦੁਆਰਾ ਸਾਈਟ ਵਿੱਚ ਦਾਖਲ ਹੋਣ ਤੋਂ ਬਾਅਦ www.semrushchina.cn, ਜੋ "ਤੇਜ਼" ਚੀਨੀ DNS ਸਰਵਰਾਂ ਦੁਆਰਾ ਹੱਲ ਕਰਦਾ ਹੈ, HTTP ਬੇਨਤੀ ਸਾਡੇ ਤੇਜ਼ ਹੱਲ ਦੁਆਰਾ ਜਾਂਦੀ ਹੈ। ਜਵਾਬ ਉਸੇ ਮਾਰਗ ਦੇ ਨਾਲ ਵਾਪਸ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਪਰ ਡੋਮੇਨ ਸਾਰੀਆਂ JS ਸਕ੍ਰਿਪਟਾਂ, HTML ਪੰਨਿਆਂ ਅਤੇ ਵੈਬ ਪੇਜ ਦੇ ਹੋਰ ਤੱਤਾਂ ਵਿੱਚ ਨਿਰਧਾਰਤ ਕੀਤਾ ਗਿਆ ਹੈ semrush.com ਵਾਧੂ ਸਰੋਤਾਂ ਲਈ ਜੋ ਪੰਨੇ ਦੇ ਰੈਂਡਰ ਹੋਣ 'ਤੇ ਲੋਡ ਕੀਤੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ। ਭਾਵ, ਕਲਾਇੰਟ "ਮੁੱਖ" ਏ-ਰਿਕਾਰਡ ਨੂੰ ਹੱਲ ਕਰਦਾ ਹੈ www.semrushchina.cn ਅਤੇ ਤੇਜ਼ ਸੁਰੰਗ ਵਿੱਚ ਜਾਂਦਾ ਹੈ, ਤੁਰੰਤ ਇੱਕ ਜਵਾਬ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ - ਇੱਕ HTML ਪੰਨਾ ਜੋ ਕਹਿੰਦਾ ਹੈ:

• sso.semrush.com ਤੋਂ ਅਜਿਹੇ ਅਤੇ ਅਜਿਹੇ ਜੇਐਸ ਨੂੰ ਡਾਊਨਲੋਡ ਕਰੋ,
• cdn.semrush.com ਤੋਂ CSS ਫਾਈਲਾਂ ਪ੍ਰਾਪਤ ਕਰੋ,
• ਅਤੇ dab.semrush.com ਤੋਂ ਕੁਝ ਤਸਵੀਰਾਂ ਵੀ ਲਓ
• ਅਤੇ ਇਸ 'ਤੇ.

ਬ੍ਰਾਉਜ਼ਰ ਇਹਨਾਂ ਸਰੋਤਾਂ ਲਈ "ਬਾਹਰੀ" ਇੰਟਰਨੈਟ ਤੇ ਜਾਣਾ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ, ਹਰ ਵਾਰ ਇੱਕ ਫਾਇਰਵਾਲ ਵਿੱਚੋਂ ਲੰਘਦਾ ਹੈ ਜੋ ਜਵਾਬ ਦੇ ਸਮੇਂ ਨੂੰ ਖਾ ਜਾਂਦਾ ਹੈ।

ਪਰ ਪਿਛਲਾ ਟੈਸਟ ਨਤੀਜੇ ਦਿਖਾਉਂਦਾ ਹੈ ਜਦੋਂ ਪੰਨੇ 'ਤੇ ਕੋਈ ਸਰੋਤ ਨਹੀਂ ਹੁੰਦੇ ਹਨ semrush.comਸਿਰਫ semrushchina.cn, ਅਤੇ *.semrushchina.cn ਸੁਰੰਗ ਵਿੱਚ ਜਾਣ ਲਈ ਸ਼ੇਨਜ਼ੇਨ ਵਿੱਚ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਦੇ ਪਤੇ ਨੂੰ ਹੱਲ ਕਰਦਾ ਹੈ।

ਸਿਰਫ਼ ਇਸ ਤਰੀਕੇ ਨਾਲ, ਚੀਨੀ ਫਾਇਰਵਾਲ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਪਾਸ ਕਰਨ ਲਈ ਤੁਹਾਡੇ ਹੱਲ ਦੁਆਰਾ ਹਰ ਸੰਭਵ ਟ੍ਰੈਫਿਕ ਨੂੰ ਵੱਧ ਤੋਂ ਵੱਧ ਧੱਕ ਕੇ, ਤੁਸੀਂ ਸਵੀਕਾਰਯੋਗ ਗਤੀ ਅਤੇ ਵੈਬਸਾਈਟ ਉਪਲਬਧਤਾ ਸੂਚਕਾਂ ਦੇ ਨਾਲ-ਨਾਲ ਹੱਲ ਟੈਸਟਾਂ ਦੇ ਇਮਾਨਦਾਰ ਨਤੀਜੇ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ।
ਅਸੀਂ ਟੀਮ ਦੇ ਉਤਪਾਦ ਵਾਲੇ ਪਾਸੇ ਇੱਕ ਕੋਡ ਸੰਪਾਦਨ ਕੀਤੇ ਬਿਨਾਂ ਅਜਿਹਾ ਕੀਤਾ।

ਸਬਫਿਲਟਰ

ਇਸ ਸਮੱਸਿਆ ਦੇ ਸਾਹਮਣੇ ਆਉਣ ਤੋਂ ਤੁਰੰਤ ਬਾਅਦ ਹੱਲ ਪੈਦਾ ਹੋਇਆ ਸੀ। ਸਾਨੂੰ ਲੋੜ ਸੀ PoC (ਸੰਕਲਪ ਦਾ ਸਬੂਤ) ਕਿ ਸਾਡੇ ਫਾਇਰਵਾਲ ਪ੍ਰਵੇਸ਼ ਹੱਲ ਅਸਲ ਵਿੱਚ ਵਧੀਆ ਕੰਮ ਕਰਦੇ ਹਨ। ਅਜਿਹਾ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਇਸ ਹੱਲ ਵਿੱਚ ਸਾਰੇ ਸਾਈਟ ਟ੍ਰੈਫਿਕ ਨੂੰ ਸਮੇਟਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ. ਅਤੇ ਅਸੀਂ ਅਰਜ਼ੀ ਦਿੱਤੀ ਸਬਫਿਲਟਰ nginx ਵਿੱਚ.

ਸਬਫਿਲਟਰ nginx ਵਿੱਚ ਇੱਕ ਕਾਫ਼ੀ ਸਧਾਰਨ ਮੋਡੀਊਲ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਜਵਾਬ ਦੇ ਭਾਗ ਵਿੱਚ ਇੱਕ ਲਾਈਨ ਨੂੰ ਦੂਜੀ ਲਾਈਨ ਵਿੱਚ ਬਦਲਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਇਸ ਲਈ ਅਸੀਂ ਸਾਰੀਆਂ ਘਟਨਾਵਾਂ ਨੂੰ ਬਦਲ ਦਿੱਤਾ ਹੈ semrush.com 'ਤੇ semrushchina.cn ਸਾਰੇ ਜਵਾਬਾਂ ਵਿੱਚ।

ਅਤੇ... ਇਹ ਕੰਮ ਨਹੀਂ ਕੀਤਾ ਕਿਉਂਕਿ ਸਾਨੂੰ ਬੈਕਐਂਡ ਤੋਂ ਸੰਕੁਚਿਤ ਸਮੱਗਰੀ ਪ੍ਰਾਪਤ ਹੋਈ, ਇਸਲਈ ਸਬਫਿਲਟਰ ਨੂੰ ਲੋੜੀਂਦੀ ਲਾਈਨ ਨਹੀਂ ਮਿਲੀ। ਮੈਨੂੰ nginx ਵਿੱਚ ਇੱਕ ਹੋਰ ਸਥਾਨਕ ਸਰਵਰ ਜੋੜਨਾ ਪਿਆ, ਜਿਸ ਨੇ ਜਵਾਬ ਨੂੰ ਡੀਕੰਪ੍ਰੈਸ ਕੀਤਾ ਅਤੇ ਇਸਨੂੰ ਅਗਲੇ ਸਥਾਨਕ ਸਰਵਰ ਤੇ ਪਾਸ ਕਰ ਦਿੱਤਾ, ਜੋ ਪਹਿਲਾਂ ਹੀ ਸਤਰ ਨੂੰ ਬਦਲਣ, ਇਸ ਨੂੰ ਸੰਕੁਚਿਤ ਕਰਨ, ਅਤੇ ਇਸਨੂੰ ਚੇਨ ਵਿੱਚ ਅਗਲੇ ਪ੍ਰੌਕਸੀ ਸਰਵਰ ਨੂੰ ਭੇਜਣ ਵਿੱਚ ਰੁੱਝਿਆ ਹੋਇਆ ਸੀ।

ਨਤੀਜੇ ਵਜੋਂ, ਗਾਹਕ ਕਿੱਥੇ ਪ੍ਰਾਪਤ ਕਰੇਗਾ .semrush.com, ਉਸ ਨੇ ਪ੍ਰਾਪਤ ਕੀਤਾ .semrushchina.cn ਅਤੇ ਆਗਿਆਕਾਰੀ ਨਾਲ ਸਾਡੇ ਫੈਸਲੇ ਦੁਆਰਾ ਚੱਲਿਆ.

ਹਾਲਾਂਕਿ, ਡੋਮੇਨ ਨੂੰ ਇੱਕ ਤਰੀਕੇ ਨਾਲ ਬਦਲਣ ਲਈ ਇਹ ਕਾਫ਼ੀ ਨਹੀਂ ਹੈ, ਕਿਉਂਕਿ ਬੈਕਐਂਡ ਅਜੇ ਵੀ ਗਾਹਕ ਤੋਂ ਬਾਅਦ ਦੀਆਂ ਬੇਨਤੀਆਂ ਵਿੱਚ semrush.com ਦੀ ਉਮੀਦ ਕਰਦੇ ਹਨ. ਇਸ ਅਨੁਸਾਰ, ਉਸੇ ਸਰਵਰ 'ਤੇ ਜਿੱਥੇ ਇਕ-ਪਾਸੜ ਤਬਦੀਲੀ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਇੱਕ ਸਧਾਰਨ ਨਿਯਮਤ ਸਮੀਕਰਨ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਅਸੀਂ ਬੇਨਤੀ ਤੋਂ ਸਬਡੋਮੇਨ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਾਂ, ਅਤੇ ਫਿਰ ਅਸੀਂ ਕਰਦੇ ਹਾਂ proxy_pass ਵੇਰੀਏਬਲ ਦੇ ਨਾਲ $ਹੋਸਟ, ਵਿੱਚ ਪ੍ਰਦਰਸ਼ਿਤ $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;
    }
}

ਮੈਂ ਦੁਹਰਾਉਂਦਾ ਹਾਂ, ਇਹ ਕ੍ਰੌਪ ਕੀਤੀਆਂ ਸੰਰਚਨਾਵਾਂ ਹਨ।

ਓਸ ਵਾਂਗ. ਇਹ ਗੁੰਝਲਦਾਰ ਲੱਗ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਸ਼ਬਦਾਂ ਵਿੱਚ ਹੈ. ਵਾਸਤਵ ਵਿੱਚ, ਹਰ ਚੀਜ਼ ਭੁੰਲਨਆ ਟਰਨਿਪਸ ਨਾਲੋਂ ਸਰਲ ਹੈ :)

ਵਿਕਾਰ ਦਾ ਅੰਤ

ਕੁਝ ਸਮੇਂ ਲਈ ਅਸੀਂ ਖੁਸ਼ ਸੀ ਕਿਉਂਕਿ ਆਈਪੀਐਸਈਸੀ ਸੁਰੰਗਾਂ ਦੇ ਡਿੱਗਣ ਬਾਰੇ ਮਿੱਥ ਦੀ ਪੁਸ਼ਟੀ ਨਹੀਂ ਹੋਈ ਸੀ। ਪਰ ਫਿਰ ਸੁਰੰਗਾਂ ਡਿੱਗਣੀਆਂ ਸ਼ੁਰੂ ਹੋ ਗਈਆਂ। ਕੁਝ ਮਿੰਟਾਂ ਲਈ ਦਿਨ ਵਿੱਚ ਕਈ ਵਾਰ. ਥੋੜਾ ਜਿਹਾ, ਪਰ ਇਹ ਸਾਡੇ ਲਈ ਅਨੁਕੂਲ ਨਹੀਂ ਸੀ। ਕਿਉਂਕਿ ਦੋਵੇਂ ਸੁਰੰਗਾਂ ਨੂੰ ਇੱਕੋ ਰਾਊਟਰ 'ਤੇ ਅਲੀ ਸਾਈਡ 'ਤੇ ਖਤਮ ਕੀਤਾ ਗਿਆ ਸੀ, ਅਸੀਂ ਫੈਸਲਾ ਕੀਤਾ ਕਿ ਸ਼ਾਇਦ ਇਹ ਇੱਕ ਖੇਤਰੀ ਸਮੱਸਿਆ ਸੀ ਅਤੇ ਸਾਨੂੰ ਬੈਕਅੱਪ ਖੇਤਰ ਨੂੰ ਵਧਾਉਣ ਦੀ ਲੋੜ ਸੀ।

ਉਨ੍ਹਾਂ ਨੇ ਇਸ ਨੂੰ ਚੁੱਕਿਆ। ਸੁਰੰਗਾਂ ਵੱਖ-ਵੱਖ ਸਮਿਆਂ 'ਤੇ ਫੇਲ੍ਹ ਹੋਣੀਆਂ ਸ਼ੁਰੂ ਹੋ ਗਈਆਂ, ਪਰ ਫੇਲਓਵਰ ਨੇ ਐਨਜੀਨੈਕਸ ਵਿੱਚ ਅੱਪਸਟਰੀਮ ਪੱਧਰ 'ਤੇ ਸਾਡੇ ਲਈ ਵਧੀਆ ਕੰਮ ਕੀਤਾ। ਪਰ ਫਿਰ ਲਗਭਗ ਉਸੇ ਸਮੇਂ ਸੁਰੰਗਾਂ ਡਿੱਗਣੀਆਂ ਸ਼ੁਰੂ ਹੋ ਗਈਆਂ 🙂 ਅਤੇ 502 ਅਤੇ 504 ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਹੋ ਗਏ। ਅਪਟਾਈਮ ਵਿਗੜਨਾ ਸ਼ੁਰੂ ਹੋ ਗਿਆ, ਇਸ ਲਈ ਅਸੀਂ ਇਸ ਵਿਕਲਪ 'ਤੇ ਕੰਮ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ। ਅਲੀਬਾਬਾ ਸੀ.ਈ.ਐਨ (ਕਲਾਊਡ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਨੈੱਟਵਰਕ)।

cen

cen - ਇਹ ਅਲੀਬਾਬਾ ਕਲਾਉਡ ਦੇ ਅੰਦਰ ਵੱਖ-ਵੱਖ ਖੇਤਰਾਂ ਤੋਂ ਦੋ VPCs ਦੀ ਕਨੈਕਟੀਵਿਟੀ ਹੈ, ਯਾਨੀ ਤੁਸੀਂ ਕਲਾਉਡ ਦੇ ਅੰਦਰ ਕਿਸੇ ਵੀ ਖੇਤਰ ਦੇ ਪ੍ਰਾਈਵੇਟ ਨੈਟਵਰਕ ਨੂੰ ਇੱਕ ਦੂਜੇ ਨਾਲ ਜੋੜ ਸਕਦੇ ਹੋ। ਅਤੇ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ: ਇਸ ਚੈਨਲ ਵਿੱਚ ਕਾਫ਼ੀ ਸਖਤ ਹੈ ALS. ਇਹ ਸਪੀਡ ਅਤੇ ਅਪਟਾਈਮ ਦੋਵਾਂ ਵਿੱਚ ਬਹੁਤ ਸਥਿਰ ਹੈ। ਪਰ ਇਹ ਕਦੇ ਵੀ ਇੰਨਾ ਸੌਖਾ ਨਹੀਂ ਹੁੰਦਾ:

• ਇਹ ਪ੍ਰਾਪਤ ਕਰਨਾ ਬਹੁਤ ਮੁਸ਼ਕਲ ਹੈ ਜੇਕਰ ਤੁਸੀਂ ਚੀਨੀ ਨਾਗਰਿਕ ਜਾਂ ਕਾਨੂੰਨੀ ਸੰਸਥਾ ਨਹੀਂ ਹੋ,
• ਤੁਹਾਨੂੰ ਚੈਨਲ ਬੈਂਡਵਿਡਥ ਦੇ ਹਰੇਕ ਮੈਗਾਬਿਟ ਲਈ ਭੁਗਤਾਨ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

ਨਾਲ ਜੁੜਨ ਦਾ ਮੌਕਾ ਮਿਲਿਆ ਮੇਨਲੈਂਡ ਚੀਨ и ਓਵਰਸੀਜ਼, ਅਸੀਂ ਦੋ ਅਲੀ ਖੇਤਰਾਂ ਦੇ ਵਿਚਕਾਰ ਇੱਕ CEN ਬਣਾਇਆ ਹੈ: cn-ਸ਼ੇਨਜ਼ੇਨ и us-east-1 (ਸਾਡੇ ਲਈ ਸਭ ਤੋਂ ਨਜ਼ਦੀਕੀ ਬਿੰਦੂ-ਪੂਰਬ 4)। ਅਲੀ ਵਿੱਚ us-east-1 ਇੱਕ ਹੋਰ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਨੂੰ ਉਭਾਰਿਆ ਤਾਂ ਜੋ ਇੱਕ ਹੋਰ ਹੋਵੇ ਟੱਪਣ.

ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਨਿਕਲਿਆ:

ਬ੍ਰਾਊਜ਼ਰ ਟੈਸਟ ਦੇ ਨਤੀਜੇ ਹੇਠਾਂ ਦਿੱਤੇ ਗਏ ਹਨ:

ਫੈਸਲੇ ਦਾ
ਅਪਿਟਾਈਮ
ਮੱਧਮਾਨ
75 ਪ੍ਰਤੀਸ਼ਤ
95 ਪ੍ਰਤੀਸ਼ਤ

Cloudflare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

cen
99.75
16s
21s
27s

ਪ੍ਰਦਰਸ਼ਨ IPSEC ਨਾਲੋਂ ਥੋੜ੍ਹਾ ਬਿਹਤਰ ਹੈ। ਪਰ IPSEC ਦੁਆਰਾ ਤੁਸੀਂ ਸੰਭਾਵੀ ਤੌਰ 'ਤੇ 100 Mbit/s ਦੀ ਸਪੀਡ ਨਾਲ, ਅਤੇ CEN ਰਾਹੀਂ ਸਿਰਫ 5 Mbit/s ਅਤੇ ਹੋਰ ਦੀ ਗਤੀ ਨਾਲ ਡਾਊਨਲੋਡ ਕਰ ਸਕਦੇ ਹੋ।

ਇੱਕ ਹਾਈਬ੍ਰਿਡ ਵਰਗਾ ਆਵਾਜ਼, ਠੀਕ? IPSEC ਸਪੀਡ ਅਤੇ CEN ਸਥਿਰਤਾ ਨੂੰ ਜੋੜੋ।

ਇਹ ਉਹ ਹੈ ਜੋ ਅਸੀਂ ਕੀਤਾ, IPSEC ਸੁਰੰਗ ਦੀ ਅਸਫਲਤਾ ਦੀ ਸਥਿਤੀ ਵਿੱਚ IPSEC ਅਤੇ CEN ਦੋਵਾਂ ਦੁਆਰਾ ਆਵਾਜਾਈ ਦੀ ਆਗਿਆ ਦਿੱਤੀ। ਅਪਟਾਈਮ ਬਹੁਤ ਜ਼ਿਆਦਾ ਹੋ ਗਿਆ ਹੈ, ਪਰ ਸਾਈਟ ਲੋਡ ਕਰਨ ਦੀ ਗਤੀ ਅਜੇ ਵੀ ਲੋੜੀਂਦੇ ਹੋਣ ਲਈ ਬਹੁਤ ਕੁਝ ਛੱਡਦੀ ਹੈ. ਫਿਰ ਮੈਂ ਉਹਨਾਂ ਸਾਰੇ ਸਰਕਟਾਂ ਨੂੰ ਖਿੱਚਿਆ ਜੋ ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਵਰਤੇ ਅਤੇ ਟੈਸਟ ਕੀਤੇ ਸਨ, ਅਤੇ ਇਸ ਸਰਕਟ ਵਿੱਚ ਥੋੜਾ ਹੋਰ GCP ਜੋੜਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ, ਅਰਥਾਤ ਜੀ.ਐਲ.ਬੀ..

ਜੀ.ਐਲ.ਬੀ.

ਜੀ.ਐਲ.ਬੀ. ਹੈ ਗਲੋਬਲ ਲੋਡ ਬੈਲੈਂਸਰ (ਜਾਂ ਗੂਗਲ ਕਲਾਉਡ ਲੋਡ ਬੈਲੈਂਸਰ)। ਇਸਦਾ ਸਾਡੇ ਲਈ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਫਾਇਦਾ ਹੈ: ਇੱਕ CDN ਦੇ ਸੰਦਰਭ ਵਿੱਚ ਇਸ ਕੋਲ ਹੈ anycast IP, ਜੋ ਤੁਹਾਨੂੰ ਟ੍ਰੈਫਿਕ ਨੂੰ ਕਲਾਇੰਟ ਦੇ ਸਭ ਤੋਂ ਨੇੜੇ ਦੇ ਡੇਟਾ ਸੈਂਟਰ ਤੱਕ ਰੂਟ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਜੋ ਟ੍ਰੈਫਿਕ ਤੇਜ਼ੀ ਨਾਲ Google ਦੇ ਤੇਜ਼ ਨੈਟਵਰਕ ਵਿੱਚ ਆ ਜਾਵੇ ਅਤੇ ਘੱਟ "ਨਿਯਮਿਤ" ਇੰਟਰਨੈਟ ਰਾਹੀਂ ਜਾਂਦਾ ਹੈ।

ਦੋ ਵਾਰ ਸੋਚੇ ਬਿਨਾਂ, ਅਸੀਂ ਉਠਾਇਆ HTTP/HTTPS LB ਅਸੀਂ ਆਪਣੀਆਂ ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਨੂੰ GCP ਵਿੱਚ ਸਬ-ਫਿਲਟਰ ਅਤੇ ਬੈਕਐਂਡ ਵਜੋਂ ਸਥਾਪਤ ਕੀਤਾ ਹੈ।

ਕਈ ਸਕੀਮਾਂ ਸਨ:

• ਵਰਤਣ ਲਈ Cloudflare ਚੀਨ ਨੈੱਟਵਰਕ, ਪਰ ਇਸ ਵਾਰ Origin ਨੂੰ ਗਲੋਬਲ ਨਿਰਧਾਰਤ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ IP GLB.
• 'ਤੇ ਗਾਹਕਾਂ ਨੂੰ ਖਤਮ ਕਰੋ cn-ਸ਼ੇਨਜ਼ੇਨ, ਅਤੇ ਉੱਥੋਂ ਸਿੱਧੇ ਟ੍ਰੈਫਿਕ ਨੂੰ ਪ੍ਰੌਕਸੀ ਕਰੋ ਜੀ.ਐਲ.ਬੀ..
• ਚੀਨ ਤੋਂ ਸਿੱਧੇ ਜਾਓ ਜੀ.ਐਲ.ਬੀ..
• 'ਤੇ ਗਾਹਕਾਂ ਨੂੰ ਖਤਮ ਕਰੋ cn-ਸ਼ੇਨਜ਼ੇਨ, ਉੱਥੇ ਤੋਂ ਪ੍ਰੌਕਸੀ ਤੱਕ asia-east1 IPSEC ਦੁਆਰਾ (ਵਿੱਚ us-east4 CEN ਰਾਹੀਂ), ਉੱਥੋਂ GLB 'ਤੇ ਜਾਓ (ਸ਼ਾਂਤੀ ਨਾਲ, ਹੇਠਾਂ ਇੱਕ ਤਸਵੀਰ ਅਤੇ ਵਿਆਖਿਆ ਹੋਵੇਗੀ)

ਅਸੀਂ ਇਹਨਾਂ ਸਾਰੇ ਵਿਕਲਪਾਂ ਅਤੇ ਕਈ ਹੋਰ ਹਾਈਬ੍ਰਿਡ ਵਿਕਲਪਾਂ ਦੀ ਜਾਂਚ ਕੀਤੀ:

• Cloudflare + GLB

ਇਹ ਸਕੀਮ ਅਪਟਾਈਮ ਅਤੇ DNS ਗਲਤੀਆਂ ਦੇ ਕਾਰਨ ਸਾਡੇ ਅਨੁਕੂਲ ਨਹੀਂ ਸੀ। ਪਰ CF ਸਾਈਡ 'ਤੇ ਬੱਗ ਫਿਕਸ ਕੀਤੇ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ ਟੈਸਟ ਕੀਤਾ ਗਿਆ ਸੀ, ਸ਼ਾਇਦ ਇਹ ਹੁਣ ਬਿਹਤਰ ਹੈ (ਹਾਲਾਂਕਿ, ਇਹ HTTP ਸਮਾਂ ਸਮਾਪਤੀ ਨੂੰ ਬਾਹਰ ਨਹੀਂ ਰੱਖਦਾ ਹੈ)।

• ਅਲੀ + ਜੀ.ਐਲ.ਬੀ

ਇਹ ਸਕੀਮ ਅਪਟਾਈਮ ਦੇ ਰੂਪ ਵਿੱਚ ਵੀ ਸਾਡੇ ਲਈ ਅਨੁਕੂਲ ਨਹੀਂ ਸੀ, ਕਿਉਂਕਿ GLB ਅਕਸਰ ਇੱਕ ਸਵੀਕਾਰਯੋਗ ਸਮੇਂ ਜਾਂ ਸਮਾਂ ਸਮਾਪਤੀ ਵਿੱਚ ਜੁੜਨ ਦੀ ਅਸੰਭਵਤਾ ਦੇ ਕਾਰਨ ਅੱਪਸਟ੍ਰੀਮ ਤੋਂ ਬਾਹਰ ਹੋ ਜਾਂਦਾ ਹੈ, ਕਿਉਂਕਿ ਚੀਨ ਦੇ ਅੰਦਰ ਇੱਕ ਸਰਵਰ ਲਈ, GLB ਪਤਾ ਬਾਹਰ ਰਹਿੰਦਾ ਹੈ, ਅਤੇ ਇਸਲਈ ਪਿੱਛੇ ਚੀਨੀ ਫਾਇਰਵਾਲ. ਜਾਦੂ ਨਹੀਂ ਹੋਇਆ।

• ਸਿਰਫ਼ GLB

ਪਿਛਲੇ ਇੱਕ ਵਰਗਾ ਇੱਕ ਵਿਕਲਪ, ਸਿਰਫ ਇਸ ਨੇ ਆਪਣੇ ਆਪ ਵਿੱਚ ਚੀਨ ਵਿੱਚ ਸਰਵਰਾਂ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕੀਤੀ: ਟ੍ਰੈਫਿਕ ਸਿੱਧਾ GLB ਵਿੱਚ ਗਿਆ (DNS ਰਿਕਾਰਡ ਬਦਲੇ ਗਏ ਸਨ)। ਇਸ ਅਨੁਸਾਰ, ਨਤੀਜੇ ਤਸੱਲੀਬਖਸ਼ ਨਹੀਂ ਸਨ, ਕਿਉਂਕਿ ਸਾਧਾਰਨ ਇੰਟਰਨੈਟ ਪ੍ਰਦਾਤਾਵਾਂ ਦੀਆਂ ਸੇਵਾਵਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਵਾਲੇ ਆਮ ਚੀਨੀ ਗਾਹਕਾਂ ਦੀ ਫਾਇਰਵਾਲ ਨੂੰ ਅਲੀ ਕਲਾਉਡ ਨਾਲੋਂ ਪਾਸ ਕਰਨ ਨਾਲ ਬਹੁਤ ਮਾੜੀ ਸਥਿਤੀ ਹੈ।

• ਸ਼ੇਨਜ਼ੇਨ -> (CEN/IPSEC) -> ਪ੍ਰੌਕਸੀ -> GLB

ਇੱਥੇ ਅਸੀਂ ਸਭ ਤੋਂ ਵਧੀਆ ਹੱਲਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ:

• CEN ਤੋਂ ਸਥਿਰਤਾ ਅਤੇ ਗਾਰੰਟੀਸ਼ੁਦਾ SLA
• IPSEC ਤੋਂ ਉੱਚ ਗਤੀ
• ਗੂਗਲ ਦਾ "ਤੇਜ਼" ਨੈਟਵਰਕ ਅਤੇ ਇਸਦਾ ਕੋਈ ਵੀ ਕਾਸਟ।

ਸਕੀਮ ਕੁਝ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ: ਉਪਭੋਗਤਾ ਟ੍ਰੈਫਿਕ ਨੂੰ ਇੱਕ ਵਰਚੁਅਲ ਮਸ਼ੀਨ 'ਤੇ ਖਤਮ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ch-ਸ਼ੇਨਜ਼ੇਨ. Nginx ਅੱਪਸਟ੍ਰੀਮ ਉੱਥੇ ਕੌਂਫਿਗਰ ਕੀਤੇ ਗਏ ਹਨ, ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੁਝ IPSEC ਸੁਰੰਗ ਦੇ ਦੂਜੇ ਸਿਰੇ 'ਤੇ ਸਥਿਤ ਪ੍ਰਾਈਵੇਟ IP ਸਰਵਰਾਂ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੇ ਹਨ, ਅਤੇ ਕੁਝ ਅੱਪਸਟ੍ਰੀਮ CEN ਦੇ ਦੂਜੇ ਪਾਸੇ ਸਰਵਰਾਂ ਦੇ ਨਿੱਜੀ ਪਤਿਆਂ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੇ ਹਨ। IPSEC ਖੇਤਰ ਲਈ ਕੌਂਫਿਗਰ ਕੀਤਾ ਗਿਆ asia-east1 GCP ਵਿੱਚ (ਉਸ ਸਮੇਂ ਚੀਨ ਦਾ ਸਭ ਤੋਂ ਨਜ਼ਦੀਕੀ ਖੇਤਰ ਸੀ ਜਦੋਂ ਹੱਲ ਬਣਾਇਆ ਗਿਆ ਸੀ। GCP ਹੁਣ ਹਾਂਗਕਾਂਗ ਵਿੱਚ ਵੀ ਮੌਜੂਦ ਹੈ)। CEN - ਖੇਤਰ ਨੂੰ us-east1 ਅਲੀ ਕਲਾਉਡ ਵਿੱਚ.

ਫਿਰ ਦੋਵਾਂ ਪਾਸਿਆਂ ਤੋਂ ਆਵਾਜਾਈ ਨੂੰ ਨਿਰਦੇਸ਼ਿਤ ਕੀਤਾ ਗਿਆ ਸੀ anycast IP GLB, ਭਾਵ, ਗੂਗਲ ਦੀ ਮੌਜੂਦਗੀ ਦੇ ਸਭ ਤੋਂ ਨਜ਼ਦੀਕੀ ਬਿੰਦੂ ਤੱਕ, ਅਤੇ ਇਸਦੇ ਨੈਟਵਰਕਾਂ ਦੁਆਰਾ ਖੇਤਰ ਵਿੱਚ ਗਿਆ us-east4 GCP ਵਿੱਚ, ਜਿਸ ਵਿੱਚ ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਨੂੰ ਬਦਲਿਆ ਗਿਆ ਸੀ (nginx ਵਿੱਚ ਸਬਫਿਲਟਰ ਦੇ ਨਾਲ)।

ਇਹ ਹਾਈਬ੍ਰਿਡ ਹੱਲ, ਜਿਵੇਂ ਕਿ ਅਸੀਂ ਉਮੀਦ ਕੀਤੀ ਸੀ, ਨੇ ਹਰੇਕ ਤਕਨਾਲੋਜੀ ਦੇ ਲਾਭਾਂ ਦਾ ਫਾਇਦਾ ਉਠਾਇਆ। ਆਮ ਤੌਰ 'ਤੇ, ਟ੍ਰੈਫਿਕ ਤੇਜ਼ੀ ਨਾਲ IPSEC ਤੋਂ ਲੰਘਦਾ ਹੈ, ਪਰ ਜੇਕਰ ਸਮੱਸਿਆਵਾਂ ਸ਼ੁਰੂ ਹੁੰਦੀਆਂ ਹਨ, ਤਾਂ ਅਸੀਂ ਜਲਦੀ ਅਤੇ ਕੁਝ ਮਿੰਟਾਂ ਲਈ ਇਹਨਾਂ ਸਰਵਰਾਂ ਨੂੰ ਅੱਪਸਟ੍ਰੀਮ ਤੋਂ ਬਾਹਰ ਕੱਢ ਦਿੰਦੇ ਹਾਂ ਅਤੇ ਸੁਰੰਗ ਦੇ ਸਥਿਰ ਹੋਣ ਤੱਕ ਸਿਰਫ CEN ਰਾਹੀਂ ਆਵਾਜਾਈ ਭੇਜਦੇ ਹਾਂ।

ਉਪਰੋਕਤ ਸੂਚੀ ਵਿੱਚੋਂ 4ਵੇਂ ਹੱਲ ਨੂੰ ਲਾਗੂ ਕਰਕੇ, ਅਸੀਂ ਉਹ ਪ੍ਰਾਪਤ ਕੀਤਾ ਜੋ ਅਸੀਂ ਚਾਹੁੰਦੇ ਸੀ ਅਤੇ ਉਸ ਸਮੇਂ ਕਾਰੋਬਾਰ ਲਈ ਸਾਡੇ ਲਈ ਕੀ ਲੋੜੀਂਦਾ ਸੀ।

ਪਿਛਲੇ ਦੇ ਮੁਕਾਬਲੇ ਨਵੇਂ ਹੱਲ ਲਈ ਬ੍ਰਾਊਜ਼ਰ ਟੈਸਟ ਦੇ ਨਤੀਜੇ:

ਫੈਸਲੇ ਦਾ
ਅਪਿਟਾਈਮ
ਮੱਧਮਾਨ
75 ਪ੍ਰਤੀਸ਼ਤ
95 ਪ੍ਰਤੀਸ਼ਤ

Cloudflare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

cen
99.75
16s
21s
27s

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

CDN

ਸਾਡੇ ਦੁਆਰਾ ਲਾਗੂ ਕੀਤੇ ਗਏ ਹੱਲ ਵਿੱਚ ਸਭ ਕੁਝ ਵਧੀਆ ਹੈ, ਪਰ ਅਜਿਹਾ ਕੋਈ CDN ਨਹੀਂ ਹੈ ਜੋ ਖੇਤਰੀ ਅਤੇ ਇੱਥੋਂ ਤੱਕ ਕਿ ਸ਼ਹਿਰ ਪੱਧਰ 'ਤੇ ਆਵਾਜਾਈ ਨੂੰ ਤੇਜ਼ ਕਰ ਸਕਦਾ ਹੈ। ਸਿਧਾਂਤ ਵਿੱਚ, ਇਸ ਨੂੰ CDN ਪ੍ਰਦਾਤਾ ਦੇ ਤੇਜ਼ ਸੰਚਾਰ ਚੈਨਲਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਅੰਤਮ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਸਾਈਟ ਨੂੰ ਤੇਜ਼ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ. ਅਤੇ ਅਸੀਂ ਹਰ ਸਮੇਂ ਇਸ ਬਾਰੇ ਸੋਚਿਆ. ਅਤੇ ਹੁਣ, ਪ੍ਰੋਜੈਕਟ ਦੇ ਅਗਲੇ ਦੁਹਰਾਓ ਦਾ ਸਮਾਂ ਆ ਗਿਆ ਹੈ: ਚੀਨ ਵਿੱਚ CDN ਪ੍ਰਦਾਤਾਵਾਂ ਦੀ ਖੋਜ ਅਤੇ ਜਾਂਚ.

ਅਤੇ ਮੈਂ ਤੁਹਾਨੂੰ ਇਸ ਬਾਰੇ ਅਗਲੇ, ਅੰਤਮ ਭਾਗ ਵਿੱਚ ਦੱਸਾਂਗਾ :)

ਸਰੋਤ: www.habr.com