CDN ਦੀ ਵਰਤੋਂ ਨਾ ਕਰੋ

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

ਤਸਵੀਰ ਵਿੱਚ ਚੱਕਰ ਵਿੱਚ ਦੇਰੀ ਇੱਕ CDN ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਹੁੰਦੀ ਹੈ।

ਇਤਿਹਾਸ ਦਾ ਇੱਕ ਬਿੱਟ

ਬਹੁਤ ਸਾਰੀਆਂ ਤਕਨਾਲੋਜੀਆਂ ਵਾਂਗ, ਸੀਡੀਐਨਜ਼ ਲੋੜ ਤੋਂ ਬਾਹਰ ਨਿਕਲੇ ਹਨ। ਇੰਟਰਨੈਟ ਉਪਭੋਗਤਾਵਾਂ ਵਿੱਚ ਇੰਟਰਨੈਟ ਚੈਨਲਾਂ ਦੇ ਵਿਕਾਸ ਦੇ ਨਾਲ, ਔਨਲਾਈਨ ਵੀਡੀਓ ਸੇਵਾਵਾਂ ਪ੍ਰਗਟ ਹੋਈਆਂ. ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ, ਵੀਡੀਓ ਸਮੱਗਰੀ ਨੂੰ ਨਿਯਮਤ ਵੈੱਬਸਾਈਟ ਸਮੱਗਰੀ (ਤਸਵੀਰਾਂ, ਟੈਕਸਟ, ਅਤੇ CSS ਜਾਂ JS ਕੋਡ) ਦੇ ਮੁਕਾਬਲੇ ਜ਼ਿਆਦਾ ਬੈਂਡਵਿਡਥ ਦੇ ਆਰਡਰ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

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

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

ਜਿਵੇਂ ਕਿ ਵੈਬ ਦਾ ਵਿਕਾਸ ਹੋਇਆ ਹੈ, ਵੈਬ ਐਪਲੀਕੇਸ਼ਨ ਆਪਣੇ ਆਪ ਵਿੱਚ ਵਧੇਰੇ ਗੁੰਝਲਦਾਰ ਅਤੇ ਗੁੰਝਲਦਾਰ ਬਣ ਗਏ ਹਨ। ਲੋਡਿੰਗ ਸਪੀਡ ਦੀ ਸਮੱਸਿਆ ਸਾਹਮਣੇ ਆਈ ਹੈ। ਵੈੱਬਸਾਈਟ ਦੀ ਗਤੀ ਦੇ ਉਤਸ਼ਾਹੀਆਂ ਨੇ ਤੇਜ਼ੀ ਨਾਲ ਕਈ ਵੱਡੀਆਂ ਸਮੱਸਿਆਵਾਂ ਦੀ ਪਛਾਣ ਕੀਤੀ ਜਿਸ ਕਾਰਨ ਵੈੱਬਸਾਈਟਾਂ ਨੂੰ ਹੌਲੀ-ਹੌਲੀ ਲੋਡ ਕੀਤਾ ਗਿਆ। ਉਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨੈੱਟਵਰਕ ਦੇਰੀ ਸੀ (RTT - ਰਾਊਂਡ ਟ੍ਰਿਪ ਟਾਈਮ ਜਾਂ ਪਿੰਗ ਟਾਈਮ)। ਵੈੱਬਸਾਈਟ ਲੋਡ ਕਰਨ ਵਿੱਚ ਦੇਰੀ ਬਹੁਤ ਸਾਰੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀ ਹੈ: ਇੱਕ TCP ਕਨੈਕਸ਼ਨ ਸਥਾਪਤ ਕਰਨਾ, ਇੱਕ TLS ਸੈਸ਼ਨ ਸ਼ੁਰੂ ਕਰਨਾ, ਹਰੇਕ ਵਿਅਕਤੀਗਤ ਸਰੋਤ ਨੂੰ ਲੋਡ ਕਰਨਾ (ਚਿੱਤਰ, JS ਫਾਈਲ, HTML ਦਸਤਾਵੇਜ਼, ਆਦਿ)।

ਸਮੱਸਿਆ ਇਸ ਤੱਥ ਦੁਆਰਾ ਵਧ ਗਈ ਸੀ ਕਿ HTTP/1.1 ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ (SPDY, QUIC ਅਤੇ HTTP/2 ਦੇ ਆਉਣ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਇੱਕੋ ਇੱਕ ਵਿਕਲਪ ਸੀ), ਬ੍ਰਾਊਜ਼ਰ ਇੱਕ ਹੋਸਟ ਲਈ 6 ਤੋਂ ਵੱਧ TCP ਕਨੈਕਸ਼ਨ ਨਹੀਂ ਖੋਲ੍ਹਦੇ। ਇਹ ਸਭ ਕੁਨੈਕਸ਼ਨ ਡਾਊਨਟਾਈਮ ਅਤੇ ਚੈਨਲ ਬੈਂਡਵਿਡਥ ਦੀ ਅਕੁਸ਼ਲ ਵਰਤੋਂ ਵੱਲ ਅਗਵਾਈ ਕਰਦਾ ਹੈ। ਸਮੱਸਿਆ ਨੂੰ ਅੰਸ਼ਕ ਤੌਰ 'ਤੇ ਡੋਮੇਨ ਸ਼ਾਰਡਿੰਗ ਦੁਆਰਾ ਹੱਲ ਕੀਤਾ ਗਿਆ ਸੀ - ਕਨੈਕਸ਼ਨਾਂ ਦੀ ਗਿਣਤੀ 'ਤੇ ਸੀਮਾ ਨੂੰ ਦੂਰ ਕਰਨ ਲਈ ਵਾਧੂ ਮੇਜ਼ਬਾਨਾਂ ਦੀ ਸਿਰਜਣਾ।

ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ CDN ਦੀ ਦੂਜੀ ਯੋਗਤਾ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ - ਪੁਆਇੰਟਾਂ ਦੀ ਵੱਡੀ ਗਿਣਤੀ ਅਤੇ ਉਪਭੋਗਤਾ ਦੇ ਨਾਲ ਨੋਡਾਂ ਦੀ ਨੇੜਤਾ ਦੇ ਕਾਰਨ ਲੇਟੈਂਸੀ (RTT) ਨੂੰ ਘਟਾਉਣਾ। ਦੂਰੀ ਇੱਥੇ ਇੱਕ ਨਿਰਣਾਇਕ ਭੂਮਿਕਾ ਨਿਭਾਉਂਦੀ ਹੈ: ਪ੍ਰਕਾਸ਼ ਦੀ ਗਤੀ ਸੀਮਤ ਹੈ (ਆਪਟੀਕਲ ਫਾਈਬਰ ਵਿੱਚ ਲਗਭਗ 200 km/sec)। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਹਰ 000 ਕਿਲੋਮੀਟਰ ਦੀ ਯਾਤਰਾ ਵਿੱਚ RTT ਵਿੱਚ 1000 ms ਦੇਰੀ ਜਾਂ 5 ms ਸ਼ਾਮਲ ਹੁੰਦੀ ਹੈ। ਇਹ ਸੰਚਾਰ ਲਈ ਲੋੜੀਂਦਾ ਘੱਟੋ-ਘੱਟ ਸਮਾਂ ਹੈ, ਕਿਉਂਕਿ ਵਿਚਕਾਰਲੇ ਉਪਕਰਣਾਂ 'ਤੇ ਵੀ ਦੇਰੀ ਹੁੰਦੀ ਹੈ। ਕਿਉਂਕਿ ਇੱਕ CDN ਆਮ ਤੌਰ 'ਤੇ ਜਾਣਦਾ ਹੈ ਕਿ ਇਸ ਦੇ ਸਰਵਰਾਂ 'ਤੇ ਵਸਤੂਆਂ ਨੂੰ ਕਿਵੇਂ ਕੈਸ਼ ਕਰਨਾ ਹੈ, ਅਸੀਂ ਇੱਕ CDN ਦੁਆਰਾ ਅਜਿਹੀਆਂ ਵਸਤੂਆਂ ਨੂੰ ਲੋਡ ਕਰਨ ਤੋਂ ਲਾਭ ਲੈ ਸਕਦੇ ਹਾਂ। ਇਸਦੇ ਲਈ ਜ਼ਰੂਰੀ ਸ਼ਰਤਾਂ: ਕੈਸ਼ ਵਿੱਚ ਵਸਤੂ ਦੀ ਮੌਜੂਦਗੀ, ਵੈਬ ਐਪਲੀਕੇਸ਼ਨ ਸਰਵਰ (ਮੂਲ ਸਰਵਰ) ਦੇ ਮੁਕਾਬਲੇ ਉਪਭੋਗਤਾ ਨੂੰ CDN ਪੁਆਇੰਟ ਦੀ ਨੇੜਤਾ। ਇਹ ਸਮਝਣਾ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿ ਇੱਕ CDN ਨੋਡ ਦੀ ਭੂਗੋਲਿਕ ਨੇੜਤਾ ਘੱਟ ਲੇਟੈਂਸੀ ਦੀ ਗਰੰਟੀ ਨਹੀਂ ਦਿੰਦੀ ਹੈ। ਕਲਾਇੰਟ ਅਤੇ CDN ਵਿਚਕਾਰ ਰੂਟਿੰਗ ਇਸ ਤਰੀਕੇ ਨਾਲ ਬਣਾਈ ਜਾ ਸਕਦੀ ਹੈ ਕਿ ਕਲਾਇੰਟ ਕਿਸੇ ਹੋਰ ਦੇਸ਼ ਵਿੱਚ ਹੋਸਟ ਨਾਲ ਜੁੜ ਜਾਵੇਗਾ, ਅਤੇ ਸੰਭਵ ਤੌਰ 'ਤੇ ਕਿਸੇ ਹੋਰ ਮਹਾਂਦੀਪ 'ਤੇ। ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਦੂਰਸੰਚਾਰ ਆਪਰੇਟਰਾਂ ਅਤੇ CDN ਸੇਵਾ (ਪੀਅਰਿੰਗ, ਕਨੈਕਸ਼ਨ, IX ਵਿੱਚ ਭਾਗੀਦਾਰੀ, ਆਦਿ) ਵਿਚਕਾਰ ਸਬੰਧ ਅਤੇ CDN ਦੀ ਟ੍ਰੈਫਿਕ ਰੂਟਿੰਗ ਨੀਤੀ ਆਪਣੇ ਆਪ ਵਿੱਚ ਲਾਗੂ ਹੁੰਦੀ ਹੈ। ਉਦਾਹਰਨ ਲਈ, Cloudflare, ਜਦੋਂ ਦੋ ਸ਼ੁਰੂਆਤੀ ਯੋਜਨਾਵਾਂ (ਮੁਫ਼ਤ ਅਤੇ ਸਸਤੇ) ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ, ਤਾਂ ਨਜ਼ਦੀਕੀ ਹੋਸਟ ਤੋਂ ਸਮੱਗਰੀ ਦੀ ਡਿਲਿਵਰੀ ਦੀ ਗਾਰੰਟੀ ਨਹੀਂ ਦਿੰਦੀ - ਘੱਟੋ ਘੱਟ ਲਾਗਤ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਹੋਸਟ ਦੀ ਚੋਣ ਕੀਤੀ ਜਾਵੇਗੀ।

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

CDN ਅੱਜ ਦੀ ਵਰਤੋਂ ਕਰਨਾ

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

1. JS ਲਾਇਬ੍ਰੇਰੀਆਂ (MaxCDN, Google. Yandex) ਨੂੰ ਵੰਡਣ ਲਈ ਮੁਫ਼ਤ CDN।
2. ਕਲਾਇੰਟ ਓਪਟੀਮਾਈਜੇਸ਼ਨ ਲਈ ਸੇਵਾਵਾਂ ਦਾ CDN (ਉਦਾਹਰਨ ਲਈ, ਫੌਂਟਾਂ ਲਈ Google ਫੌਂਟ, ਕਲਾਉਡਾਈਨਰੀ, ਚਿੱਤਰਾਂ ਲਈ ਕਲਾਉਡ ਇਮੇਜ)।
3. CMS ਵਿੱਚ ਸਥਿਰ ਅਤੇ ਸਰੋਤ ਅਨੁਕੂਲਨ ਲਈ CDN (ਬਿਟ੍ਰਿਕਸ, ਵਰਡਪਰੈਸ ਅਤੇ ਹੋਰਾਂ ਵਿੱਚ ਉਪਲਬਧ)।
4. ਆਮ ਮਕਸਦ CDN (ਸਟੈਕਪਾਥ, 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। ਇਹ ਫਾਰਮੂਲਾ ਡਿਵਾਈਸ ਦੇ ਰੇਡੀਓ ਚੈਨਲ (ਜੇਕਰ ਇਹ ਕਿਰਿਆਸ਼ੀਲ ਨਹੀਂ ਸੀ) ਦੀ ਸਰਗਰਮੀ ਲਈ ਮੋਬਾਈਲ ਨੈਟਵਰਕ ਵਿੱਚ ਦੇਰੀ ਅਤੇ ਸੈੱਲ ਟਾਵਰ 'ਤੇ ਦੇਰੀ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਨਹੀਂ ਰੱਖਦਾ।

ਸਾਈਟ ਦੇ ਲੋਡਿੰਗ ਵਾਟਰਫਾਲ 'ਤੇ ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਦਾ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ (CDN ਨਾਲ ਕਨੈਕਟ ਕਰਨ ਲਈ ਲੇਟੈਂਸੀ RTT 150 ms 'ਤੇ ਹਾਈਲਾਈਟ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ):

ਜੇਕਰ CDN ਸਾਰੇ ਸਾਈਟ ਟ੍ਰੈਫਿਕ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ (ਤੀਜੀ-ਧਿਰ ਦੀਆਂ ਸੇਵਾਵਾਂ ਨੂੰ ਛੱਡ ਕੇ), ਤਾਂ ਅਸੀਂ ਇੱਕ ਸਿੰਗਲ TCP ਕਨੈਕਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹਾਂ, ਵਾਧੂ ਹੋਸਟਾਂ ਨਾਲ ਜੁੜਨ ਵਿੱਚ ਦੇਰੀ ਨੂੰ ਬਚਾ ਸਕਦੇ ਹਾਂ। ਬੇਸ਼ੱਕ, ਇਹ HTTP/2 ਕਨੈਕਸ਼ਨਾਂ 'ਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ।

ਹੋਰ ਅੰਤਰ ਕਿਸੇ ਖਾਸ CDN ਦੀ ਕਾਰਜਕੁਸ਼ਲਤਾ ਦੁਆਰਾ ਨਿਰਧਾਰਤ ਕੀਤੇ ਜਾਂਦੇ ਹਨ - ਪਹਿਲੀ ਕਿਸਮ ਲਈ ਇਹ ਸਿਰਫ ਇੱਕ ਸਥਿਰ ਫਾਈਲ ਦੀ ਮੇਜ਼ਬਾਨੀ ਕਰ ਰਿਹਾ ਹੈ, ਪੰਜਵੇਂ ਲਈ ਇਹ ਅਨੁਕੂਲਨ ਦੇ ਉਦੇਸ਼ ਲਈ ਕਈ ਕਿਸਮ ਦੀਆਂ ਸਾਈਟ ਸਮੱਗਰੀ ਨੂੰ ਬਦਲ ਰਿਹਾ ਹੈ.

ਵੈੱਬਸਾਈਟ ਪ੍ਰਵੇਗ ਲਈ CDN ਸਮਰੱਥਾਵਾਂ

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

1. ਟੈਕਸਟ ਸਰੋਤਾਂ ਦਾ ਸੰਕੁਚਨ

ਸਭ ਤੋਂ ਬੁਨਿਆਦੀ ਅਤੇ ਸਮਝਣ ਯੋਗ ਵਿਸ਼ੇਸ਼ਤਾ, ਫਿਰ ਵੀ ਅਕਸਰ ਮਾੜੀ ਢੰਗ ਨਾਲ ਲਾਗੂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਸਾਰੇ CDN ਆਪਣੀ ਪ੍ਰਵੇਗ ਵਿਸ਼ੇਸ਼ਤਾ ਵਜੋਂ ਕੰਪਰੈਸ਼ਨ ਦੀ ਮੌਜੂਦਗੀ ਦਾ ਐਲਾਨ ਕਰਦੇ ਹਨ। ਪਰ ਜੇ ਤੁਸੀਂ ਵਧੇਰੇ ਵਿਸਥਾਰ ਨਾਲ ਦੇਖਦੇ ਹੋ, ਤਾਂ ਕਮੀਆਂ ਸਪੱਸ਼ਟ ਹੋ ਜਾਂਦੀਆਂ ਹਨ:

• ਡਾਇਨਾਮਿਕ ਕੰਪਰੈਸ਼ਨ ਲਈ ਘੱਟ ਡਿਗਰੀਆਂ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ - 5-6 (ਉਦਾਹਰਨ ਲਈ, gzip ਲਈ ਅਧਿਕਤਮ 9 ਹੈ);
• ਸਟੈਟਿਕ ਕੰਪਰੈਸ਼ਨ (ਕੈਸ਼ ਵਿੱਚ ਫਾਈਲਾਂ) ਵਾਧੂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਦੀ ਹੈ (ਉਦਾਹਰਨ ਲਈ, ਡਿਗਰੀ 11 ਦੇ ਨਾਲ ਜ਼ੋਪਫੀ ਜਾਂ ਬਰੋਟਲੀ)
• ਕੁਸ਼ਲ ਬਰੋਟਲੀ ਕੰਪਰੈਸ਼ਨ ਲਈ ਕੋਈ ਸਮਰਥਨ ਨਹੀਂ ਹੈ (ਜੀਜੀਪ ਦੇ ਮੁਕਾਬਲੇ ਲਗਭਗ 20% ਦੀ ਬਚਤ)।

ਜੇਕਰ ਤੁਸੀਂ ਇੱਕ CDN ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ, ਤਾਂ ਇਹ ਇਹਨਾਂ ਕੁਝ ਨੁਕਤਿਆਂ ਦੀ ਜਾਂਚ ਕਰਨ ਦੇ ਯੋਗ ਹੈ: CDN ਤੋਂ ਆਈ ਫਾਈਲ ਲਓ, ਇਸਦਾ ਸੰਕੁਚਿਤ ਆਕਾਰ ਰਿਕਾਰਡ ਕਰੋ ਅਤੇ ਤੁਲਨਾ ਕਰਨ ਲਈ ਇਸਨੂੰ ਹੱਥੀਂ ਕੰਪਰੈੱਸ ਕਰੋ (ਤੁਸੀਂ ਬ੍ਰੋਟਲੀ ਸਹਾਇਤਾ ਨਾਲ ਕੁਝ ਔਨਲਾਈਨ ਸੇਵਾ ਵਰਤ ਸਕਦੇ ਹੋ, ਉਦਾਹਰਣ ਲਈ vsszhat.rf).

2. ਕਲਾਇੰਟ ਕੈਚਿੰਗ ਹੈਡਰ ਸੈੱਟ ਕਰਨਾ

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

CDN ਅਧਿਕਤਮ-ਉਮਰ ਦੇ ਮੁੱਲ ਨੂੰ ਘਟਾ ਸਕਦੇ ਹਨ, ਉਪਭੋਗਤਾ ਨੂੰ ਸਥਿਰ ਸਮੱਗਰੀ ਨੂੰ ਅਕਸਰ ਮੁੜ ਲੋਡ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕਰਦੇ ਹਨ। ਇਹ ਸਪੱਸ਼ਟ ਨਹੀਂ ਹੈ ਕਿ ਇਹ ਕਿਸ ਨਾਲ ਜੁੜਿਆ ਹੋਇਆ ਹੈ: ਨੈਟਵਰਕ 'ਤੇ ਟ੍ਰੈਫਿਕ ਵਧਾਉਣ ਜਾਂ ਉਹਨਾਂ ਸਾਈਟਾਂ ਨਾਲ ਅਨੁਕੂਲਤਾ ਵਧਾਉਣ ਦੀ ਇੱਛਾ ਜੋ ਕੈਸ਼ ਨੂੰ ਰੀਸੈਟ ਕਰਨ ਬਾਰੇ ਨਹੀਂ ਜਾਣਦੇ ਹਨ. ਉਦਾਹਰਨ ਲਈ, ਡਿਫੌਲਟ Cloudflare ਸਿਰਲੇਖ ਕੈਸ਼ ਸਮਾਂ 1 ਘੰਟਾ ਹੈ, ਜੋ ਕਿ ਅਟੱਲ ਸਥਿਰ ਡੇਟਾ ਲਈ ਬਹੁਤ ਘੱਟ ਹੈ।

3. ਚਿੱਤਰ ਅਨੁਕੂਲਤਾ

ਕਿਉਂਕਿ CDN ਚਿੱਤਰਾਂ ਨੂੰ ਕੈਚ ਕਰਨ ਅਤੇ ਸਰਵ ਕਰਨ ਦੇ ਕਾਰਜਾਂ ਨੂੰ ਲੈਂਦਾ ਹੈ, ਇਸ ਲਈ ਉਹਨਾਂ ਨੂੰ CDN ਵਾਲੇ ਪਾਸੇ ਅਨੁਕੂਲ ਬਣਾਉਣਾ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਇਸ ਫਾਰਮ ਵਿੱਚ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਪ੍ਰਦਾਨ ਕਰਨਾ ਤਰਕਪੂਰਨ ਹੋਵੇਗਾ। ਚਲੋ ਤੁਰੰਤ ਇੱਕ ਰਿਜ਼ਰਵੇਸ਼ਨ ਕਰੀਏ ਕਿ ਇਹ ਵਿਸ਼ੇਸ਼ਤਾ ਸਿਰਫ CDN ਕਿਸਮਾਂ 2, 3 ਅਤੇ 5 ਲਈ ਉਪਲਬਧ ਹੈ।

ਤੁਸੀਂ ਕਈ ਤਰੀਕਿਆਂ ਨਾਲ ਚਿੱਤਰਾਂ ਨੂੰ ਅਨੁਕੂਲਿਤ ਕਰ ਸਕਦੇ ਹੋ: ਉੱਨਤ ਕੰਪਰੈਸ਼ਨ ਫਾਰਮੈਟਾਂ (ਜਿਵੇਂ ਕਿ WebP), ਵਧੇਰੇ ਕੁਸ਼ਲ ਏਨਕੋਡਰ (MozJPEG), ਜਾਂ ਸਿਰਫ਼ ਬੇਲੋੜੇ ਮੈਟਾਡੇਟਾ ਨੂੰ ਸਾਫ਼ ਕਰਨਾ।

ਆਮ ਤੌਰ 'ਤੇ, ਅਜਿਹੇ ਅਨੁਕੂਲਤਾ ਦੀਆਂ ਦੋ ਕਿਸਮਾਂ ਹਨ: ਗੁਣਵੱਤਾ ਦੇ ਨੁਕਸਾਨ ਦੇ ਨਾਲ ਅਤੇ ਗੁਣਵੱਤਾ ਦੇ ਨੁਕਸਾਨ ਤੋਂ ਬਿਨਾਂ। CDNs ਆਮ ਤੌਰ 'ਤੇ ਚਿੱਤਰ ਗੁਣਵੱਤਾ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਬਾਰੇ ਗਾਹਕਾਂ ਦੀਆਂ ਸੰਭਾਵਿਤ ਸ਼ਿਕਾਇਤਾਂ ਤੋਂ ਬਚਣ ਲਈ ਨੁਕਸਾਨ ਰਹਿਤ ਅਨੁਕੂਲਤਾ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ। ਅਜਿਹੇ ਹਾਲਾਤ ਵਿੱਚ, ਲਾਭ ਘੱਟ ਹੋਵੇਗਾ. ਵਾਸਤਵ ਵਿੱਚ, ਅਕਸਰ JPEG ਗੁਣਵੱਤਾ ਦਾ ਪੱਧਰ ਲੋੜ ਤੋਂ ਬਹੁਤ ਉੱਚਾ ਹੁੰਦਾ ਹੈ ਅਤੇ ਤੁਸੀਂ ਉਪਭੋਗਤਾ ਅਨੁਭਵ ਨਾਲ ਸਮਝੌਤਾ ਕੀਤੇ ਬਿਨਾਂ ਇੱਕ ਹੇਠਲੇ ਗੁਣਵੱਤਾ ਪੱਧਰ ਨਾਲ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਮੁੜ ਸੰਕੁਚਿਤ ਕਰ ਸਕਦੇ ਹੋ। ਦੂਜੇ ਪਾਸੇ, ਸਾਰੀਆਂ ਸੰਭਾਵਿਤ ਵੈਬ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਸਰਵ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਗੁਣਵੱਤਾ ਅਤੇ ਸੈਟਿੰਗਾਂ ਦੇ ਪੱਧਰ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੈ, ਇਸਲਈ CDN ਉਹਨਾਂ ਦੇ ਮੁਕਾਬਲੇ ਵਧੇਰੇ ਰੂੜੀਵਾਦੀ ਸੈਟਿੰਗਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ ਜੋ ਸੰਦਰਭ (ਚਿੱਤਰਾਂ ਦਾ ਉਦੇਸ਼, ਵੈਬ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਕਿਸਮ) ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ ਲਾਗੂ ਕੀਤੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ। , ਆਦਿ)

4. TLS ਕਨੈਕਸ਼ਨ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਣਾ

ਅੱਜ ਜ਼ਿਆਦਾਤਰ ਟ੍ਰੈਫਿਕ TLS ਕਨੈਕਸ਼ਨਾਂ 'ਤੇ ਯਾਤਰਾ ਕਰਦਾ ਹੈ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਅਸੀਂ TLS ਗੱਲਬਾਤ 'ਤੇ ਵਾਧੂ ਸਮਾਂ ਬਿਤਾਉਂਦੇ ਹਾਂ। ਹਾਲ ਹੀ ਵਿੱਚ, ਇਸ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਤੇਜ਼ ਕਰਨ ਲਈ ਨਵੀਆਂ ਤਕਨੀਕਾਂ ਵਿਕਸਿਤ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ। ਉਦਾਹਰਨ ਲਈ, ਇਹ EC ਕ੍ਰਿਪਟੋਗ੍ਰਾਫੀ, TLS 1.3, ਸੈਸ਼ਨ ਕੈਸ਼ ਅਤੇ ਟਿਕਟਾਂ, ਹਾਰਡਵੇਅਰ ਐਨਕ੍ਰਿਪਸ਼ਨ ਐਕਸਲਰੇਸ਼ਨ (AES-NI), ਆਦਿ ਹੈ। TLS ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਸੈੱਟ ਕਰਨ ਨਾਲ ਕਨੈਕਸ਼ਨ ਦੇ ਸਮੇਂ ਨੂੰ 0-1 RTT ਤੱਕ ਘਟਾਇਆ ਜਾ ਸਕਦਾ ਹੈ (DNS ਅਤੇ TCP ਦੀ ਗਿਣਤੀ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ)।

ਆਧੁਨਿਕ ਸੌਫਟਵੇਅਰ ਦੇ ਨਾਲ, ਅਜਿਹੇ ਅਭਿਆਸਾਂ ਨੂੰ ਆਪਣੇ ਆਪ ਲਾਗੂ ਕਰਨਾ ਮੁਸ਼ਕਲ ਨਹੀਂ ਹੈ.

ਸਾਰੇ CDNs TLS ਵਧੀਆ ਅਭਿਆਸਾਂ ਨੂੰ ਲਾਗੂ ਨਹੀਂ ਕਰਦੇ ਹਨ; ਤੁਸੀਂ TLS ਕਨੈਕਸ਼ਨ ਦੇ ਸਮੇਂ ਨੂੰ ਮਾਪ ਕੇ ਇਸਦੀ ਜਾਂਚ ਕਰ ਸਕਦੇ ਹੋ (ਉਦਾਹਰਨ ਲਈ, ਵੈੱਬਪੇਜ ਟੈਸਟ ਵਿੱਚ)। ਇੱਕ ਨਵੇਂ ਕਨੈਕਸ਼ਨ ਲਈ ਆਦਰਸ਼ - 1RTT, 2RTT - ਔਸਤ ਪੱਧਰ, 3RTT ਅਤੇ ਹੋਰ - ਖਰਾਬ।

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

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

5. ਕੁਨੈਕਸ਼ਨ ਦੇਰੀ ਘਟਾਓ

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

ਅਭਿਆਸ ਵਿੱਚ, ਵੱਖ-ਵੱਖ ਨੈੱਟਵਰਕਾਂ ਲਈ ਤਰਜੀਹਾਂ ਖਾਸ ਖੇਤਰਾਂ ਵਿੱਚ ਹੋ ਸਕਦੀਆਂ ਹਨ। ਉਦਾਹਰਨ ਲਈ, ਰੂਸੀ CDNs ਦੀ ਰੂਸ ਵਿੱਚ ਮੌਜੂਦਗੀ ਦੇ ਵਧੇਰੇ ਪੁਆਇੰਟ ਹੋਣਗੇ। ਅਮਰੀਕੀ ਲੋਕ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਅਮਰੀਕਾ ਵਿੱਚ ਨੈੱਟਵਰਕ ਵਿਕਸਿਤ ਕਰਨਗੇ। ਉਦਾਹਰਨ ਲਈ, ਸਭ ਤੋਂ ਵੱਡੇ CDN Cloudflare ਵਿੱਚੋਂ ਇੱਕ ਰੂਸ ਵਿੱਚ ਸਿਰਫ 2 ਪੁਆਇੰਟ ਹਨ - ਮਾਸਕੋ ਅਤੇ ਸੇਂਟ ਪੀਟਰਸਬਰਗ. ਭਾਵ, ਅਸੀਂ ਮਾਸਕੋ ਵਿੱਚ ਸਿੱਧੀ ਪਲੇਸਮੈਂਟ ਦੀ ਤੁਲਨਾ ਵਿੱਚ ਵੱਧ ਤੋਂ ਵੱਧ 10 ms ਲੇਟੈਂਸੀ ਬਚਾ ਸਕਦੇ ਹਾਂ।

ਜ਼ਿਆਦਾਤਰ ਪੱਛਮੀ CDN ਦੇ ਕੋਲ ਰੂਸ ਵਿੱਚ ਬਿੰਦੂ ਨਹੀਂ ਹਨ। ਉਹਨਾਂ ਨਾਲ ਜੁੜ ਕੇ, ਤੁਸੀਂ ਸਿਰਫ ਆਪਣੇ ਰੂਸੀ ਦਰਸ਼ਕਾਂ ਲਈ ਦੇਰੀ ਵਧਾ ਸਕਦੇ ਹੋ।

6. ਸਮਗਰੀ ਅਨੁਕੂਲਨ (ਮਿਨੀਫੀਕੇਸ਼ਨ, ਢਾਂਚਾਗਤ ਤਬਦੀਲੀਆਂ)

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

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

ਇੱਕ ਨਿਯਮ ਦੇ ਤੌਰ ਤੇ, ਅਜਿਹੇ ਸਾਰੇ ਅਨੁਕੂਲਨ ਸੈਟਿੰਗਾਂ ਦੁਆਰਾ ਨਿਯੰਤਰਿਤ ਕੀਤੇ ਜਾਂਦੇ ਹਨ ਅਤੇ ਸਭ ਤੋਂ ਖਤਰਨਾਕ ਲੋਕ ਮੂਲ ਰੂਪ ਵਿੱਚ ਅਸਮਰੱਥ ਹੁੰਦੇ ਹਨ.

CDN ਕਿਸਮ ਦੁਆਰਾ ਪ੍ਰਵੇਗ ਸਮਰੱਥਾ ਲਈ ਸਮਰਥਨ

ਇਸ ਲਈ ਆਓ ਦੇਖੀਏ ਕਿ ਵੱਖ-ਵੱਖ ਕਿਸਮਾਂ ਦੇ CDN ਕਿਹੜੇ ਸੰਭਾਵੀ ਪ੍ਰਵੇਗ ਮੌਕੇ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ।

ਸਹੂਲਤ ਲਈ, ਅਸੀਂ ਵਰਗੀਕਰਨ ਨੂੰ ਦੁਹਰਾਉਂਦੇ ਹਾਂ.

1. JS ਲਾਇਬ੍ਰੇਰੀਆਂ (MaxCDN, Google. Yandex) ਨੂੰ ਵੰਡਣ ਲਈ ਮੁਫ਼ਤ CDN।
2. ਕਲਾਇੰਟ ਓਪਟੀਮਾਈਜੇਸ਼ਨ ਲਈ ਸੇਵਾਵਾਂ ਦਾ CDN (ਉਦਾਹਰਨ ਲਈ, ਫੌਂਟਾਂ ਲਈ Google ਫੌਂਟ, ਕਲਾਉਡਾਈਨਰੀ, ਚਿੱਤਰਾਂ ਲਈ ਕਲਾਉਡ ਇਮੇਜ)।
3. CMS ਵਿੱਚ ਸਥਿਰ ਅਤੇ ਸਰੋਤ ਅਨੁਕੂਲਨ ਲਈ CDN (ਬਿਟ੍ਰਿਕਸ, ਵਰਡਪਰੈਸ ਅਤੇ ਹੋਰਾਂ ਵਿੱਚ ਉਪਲਬਧ)।
4. ਆਮ ਮਕਸਦ CDN (ਸਟੈਕਪਾਥ, CDNVideo, NGENIX, Megafon)।
5. ਵੈੱਬਸਾਈਟ ਪ੍ਰਵੇਗ ਲਈ CDN (Cloudflare, Imperva, Airi)।

ਹੁਣ ਆਓ CDN ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਅਤੇ ਕਿਸਮਾਂ ਦੀ ਤੁਲਨਾ ਕਰੀਏ।

ਮੌਕਾ
ਕਿਸਮ 1
ਕਿਸਮ 2
ਕਿਸਮ 3
ਕਿਸਮ 4
ਕਿਸਮ 5

ਟੈਕਸਟ ਕੰਪਰੈਸ਼ਨ
+-
-
+-
+-
+

ਕੈਸ਼ ਹੈਡਰ
+
+
+
+
+

ਤਸਵੀਰ
-
+-
+-
-
+

TLS
-
-
-
+-
+

ਦੇਰੀ
-
-
-
+
+

ਸਮੱਗਰੀ
-
-
-
-
+

ਇਸ ਸਾਰਣੀ ਵਿੱਚ, "+" ਨੂੰ ਪੂਰਾ ਸਮਰਥਨ ਦਰਸਾਉਣ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, "–" ਕੋਈ ਸਮਰਥਨ ਨਹੀਂ ਹੈ, ਅਤੇ "+-" ਅੰਸ਼ਕ ਸਮਰਥਨ ਹੈ। ਬੇਸ਼ੱਕ, ਅਸਲੀਅਤ ਵਿੱਚ ਇਸ ਸਾਰਣੀ ਤੋਂ ਭਟਕਣਾ ਹੋ ਸਕਦੀ ਹੈ (ਉਦਾਹਰਨ ਲਈ, ਕੁਝ ਆਮ-ਉਦੇਸ਼ CDN ਚਿੱਤਰਾਂ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਣ ਲਈ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਲਾਗੂ ਕਰੇਗਾ), ਪਰ ਇੱਕ ਆਮ ਵਿਚਾਰ ਲਈ ਇਹ ਲਾਭਦਾਇਕ ਹੈ।

ਨਤੀਜੇ

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

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

ਇਹ ਸੰਭਵ ਹੈ ਕਿ ਇਸ ਸਮੇਂ ਇੱਕ CDN ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਤੁਹਾਡੀ ਸਾਈਟ ਦੇ ਲੋਡ ਹੋਣ ਦੇ ਸਮੇਂ ਨੂੰ ਹੌਲੀ ਕਰ ਰਿਹਾ ਹੈ।

ਇੱਕ ਆਮ ਸਿਫ਼ਾਰਸ਼ ਦੇ ਤੌਰ 'ਤੇ, ਅਸੀਂ ਹੇਠਾਂ ਦਿੱਤੇ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰ ਸਕਦੇ ਹਾਂ: ਆਪਣੇ ਦਰਸ਼ਕਾਂ ਦਾ ਅਧਿਐਨ ਕਰੋ, ਇਸਦੇ ਭੂਗੋਲਿਕ ਦਾਇਰੇ ਦਾ ਪਤਾ ਲਗਾਓ। ਜੇਕਰ ਤੁਹਾਡੇ ਮੁੱਖ ਦਰਸ਼ਕ 1-2 ਹਜ਼ਾਰ ਕਿਲੋਮੀਟਰ ਦੇ ਘੇਰੇ ਵਿੱਚ ਕੇਂਦਰਿਤ ਹਨ, ਤਾਂ ਤੁਹਾਨੂੰ ਇਸਦੇ ਮੁੱਖ ਉਦੇਸ਼ ਲਈ ਇੱਕ CDN ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ - ਲੇਟੈਂਸੀ ਨੂੰ ਘਟਾਉਣਾ। ਇਸ ਦੀ ਬਜਾਏ, ਤੁਸੀਂ ਆਪਣੇ ਸਰਵਰ ਨੂੰ ਆਪਣੇ ਉਪਭੋਗਤਾਵਾਂ ਦੇ ਨੇੜੇ ਰੱਖ ਸਕਦੇ ਹੋ ਅਤੇ ਇਸ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਕੌਂਫਿਗਰ ਕਰ ਸਕਦੇ ਹੋ, ਲੇਖ ਵਿੱਚ ਵਰਣਨ ਕੀਤੇ ਗਏ ਜ਼ਿਆਦਾਤਰ ਅਨੁਕੂਲਤਾਵਾਂ (ਮੁਫ਼ਤ ਅਤੇ ਸਥਾਈ) ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ।

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

ਸਰੋਤ: www.habr.com