ਵੈੱਬ ਹਾਈਲੋਡ - ਅਸੀਂ ਹਜ਼ਾਰਾਂ ਡੋਮੇਨਾਂ ਲਈ ਟ੍ਰੈਫਿਕ ਦਾ ਪ੍ਰਬੰਧਨ ਕਿਵੇਂ ਕਰਦੇ ਹਾਂ

DDoS-ਗਾਰਡ ਨੈੱਟਵਰਕ 'ਤੇ ਜਾਇਜ਼ ਟਰੈਫਿਕ ਹਾਲ ਹੀ ਵਿੱਚ ਪ੍ਰਤੀ ਸਕਿੰਟ ਸੌ ਗੀਗਾਬਾਈਟ ਤੋਂ ਵੱਧ ਗਿਆ ਹੈ। ਵਰਤਮਾਨ ਵਿੱਚ, ਸਾਡੇ ਸਾਰੇ ਟ੍ਰੈਫਿਕ ਦਾ 50% ਕਲਾਇੰਟ ਵੈਬ ਸੇਵਾਵਾਂ ਦੁਆਰਾ ਤਿਆਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇਹ ਬਹੁਤ ਸਾਰੇ ਹਜ਼ਾਰਾਂ ਡੋਮੇਨ ਹਨ, ਬਹੁਤ ਵੱਖਰੇ ਅਤੇ ਜ਼ਿਆਦਾਤਰ ਮਾਮਲਿਆਂ ਵਿੱਚ ਇੱਕ ਵਿਅਕਤੀਗਤ ਪਹੁੰਚ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਕੱਟ ਦੇ ਹੇਠਾਂ ਇਹ ਹੈ ਕਿ ਅਸੀਂ ਫਰੰਟ ਨੋਡਾਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਿਵੇਂ ਕਰਦੇ ਹਾਂ ਅਤੇ ਸੈਂਕੜੇ ਹਜ਼ਾਰਾਂ ਸਾਈਟਾਂ ਲਈ SSL ਸਰਟੀਫਿਕੇਟ ਜਾਰੀ ਕਰਦੇ ਹਾਂ।

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

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

ਦੁਨੀਆ ਭਰ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਭਰੋਸੇਮੰਦ ਨੋਡ ਕਿਉਂ ਹਨ?

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

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

• ਸੇਵਾ ਦੀ ਨਿਰੰਤਰਤਾ ਲਈ ਸਖਤ ਲੋੜਾਂ - ਸਫਾਈ ਕੇਂਦਰਾਂ ਨੂੰ ਸਾਡੀ ਤੇਜ਼ੀ ਨਾਲ ਬਦਲ ਰਹੀ ਦੁਨੀਆ ਵਿੱਚ ਇੱਕ ਦੂਜੇ 'ਤੇ ਜਾਂ ਸਥਾਨਕ ਸਮਾਗਮਾਂ 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਕੀ ਤੁਸੀਂ ਇੱਕ ਹਫ਼ਤੇ ਲਈ MMTS-11 ਦੀਆਂ ਸਾਰੀਆਂ 9 ਮੰਜ਼ਿਲਾਂ ਦੀ ਬਿਜਲੀ ਕੱਟ ਦਿੱਤੀ ਸੀ? - ਕੋਈ ਸਮੱਸਿਆ ਨਹੀ. ਇੱਕ ਵੀ ਕਲਾਇੰਟ ਜਿਸ ਕੋਲ ਇਸ ਵਿਸ਼ੇਸ਼ ਸਥਾਨ ਵਿੱਚ ਕੋਈ ਭੌਤਿਕ ਕਨੈਕਸ਼ਨ ਨਹੀਂ ਹੈ, ਨੂੰ ਨੁਕਸਾਨ ਨਹੀਂ ਹੋਵੇਗਾ, ਅਤੇ ਵੈਬ ਸੇਵਾਵਾਂ ਨੂੰ ਕਿਸੇ ਵੀ ਸਥਿਤੀ ਵਿੱਚ ਨੁਕਸਾਨ ਨਹੀਂ ਹੋਵੇਗਾ।

ਇਸ ਸਭ ਦਾ ਪ੍ਰਬੰਧ ਕਿਵੇਂ ਕਰਨਾ ਹੈ?

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

nginx ਸੰਰਚਨਾ ਨੂੰ ਮੁੜ ਲੋਡ ਕਰਨ ਵੇਲੇ, ਹੇਠ ਦਿੱਤੀ ਤਸਵੀਰ ਕਾਫ਼ੀ ਆਮ ਹੈ:

ਮੈਮੋਰੀ ਦੀ ਵਰਤੋਂ 'ਤੇ:

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

ਇਹ ਇੱਕ ਮੁੱਦਾ ਕਿਉਂ ਨਹੀਂ ਸੀ ਜਦੋਂ nginx ਹੁਣੇ ਸ਼ੁਰੂ ਹੋ ਰਿਹਾ ਸੀ? ਇੱਥੇ ਕੋਈ HTTP/2 ਨਹੀਂ ਸੀ, ਕੋਈ WebSocket ਨਹੀਂ ਸੀ, ਕੋਈ ਵਿਸ਼ਾਲ ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਚੱਲਣ ਵਾਲੇ ਕੁਨੈਕਸ਼ਨ ਨਹੀਂ ਸਨ। ਸਾਡੇ ਵੈਬ ਟ੍ਰੈਫਿਕ ਦਾ 70% HTTP/2 ਹੈ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਬਹੁਤ ਲੰਬੇ ਕਨੈਕਸ਼ਨ।

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

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

ਇਹ ਉਹੀ ਵਿਧੀ ਸਾਨੂੰ ਤੁਰੰਤ ਜਾਰੀ ਕਰਨ ਅਤੇ Let's Encrypt ਸਰਟੀਫਿਕੇਟਾਂ ਨੂੰ ਨਵਿਆਉਣ ਦੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ। ਬਹੁਤ ਹੀ ਸਧਾਰਨ ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦਾ ਹੈ:

1. ਜਿਵੇਂ ਹੀ ਅਸੀਂ ਆਪਣੇ ਕਲਾਇੰਟ ਦੇ ਡੋਮੇਨ ਲਈ ਪ੍ਰਮਾਣ-ਪੱਤਰ (ਜਾਂ ਮਿਆਦ ਪੁੱਗ ਚੁੱਕੇ ਸਰਟੀਫਿਕੇਟ ਦੇ ਨਾਲ) ਲਈ ਘੱਟੋ-ਘੱਟ ਇੱਕ HTTPS ਬੇਨਤੀ ਦੇਖਦੇ ਹਾਂ, ਤਾਂ ਬਾਹਰੀ ਨੋਡ ਜਿਸਨੇ ਬੇਨਤੀ ਨੂੰ ਸਵੀਕਾਰ ਕੀਤਾ ਹੈ, ਅੰਦਰੂਨੀ ਪ੍ਰਮਾਣੀਕਰਣ ਅਥਾਰਟੀ ਨੂੰ ਇਸਦੀ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ।

   

2. ਜੇਕਰ ਉਪਭੋਗਤਾ ਨੇ Let's Encrypt ਜਾਰੀ ਕਰਨ ਦੀ ਮਨਾਹੀ ਨਹੀਂ ਕੀਤੀ ਹੈ, ਤਾਂ ਪ੍ਰਮਾਣੀਕਰਣ ਅਥਾਰਟੀ ਇੱਕ CSR ਤਿਆਰ ਕਰਦੀ ਹੈ, LE ਤੋਂ ਇੱਕ ਪੁਸ਼ਟੀਕਰਣ ਟੋਕਨ ਪ੍ਰਾਪਤ ਕਰਦੀ ਹੈ ਅਤੇ ਇਸਨੂੰ ਇੱਕ ਐਨਕ੍ਰਿਪਟਡ ਚੈਨਲ ਉੱਤੇ ਸਾਰੇ ਮੋਰਚਿਆਂ ਵਿੱਚ ਭੇਜਦੀ ਹੈ। ਹੁਣ ਕੋਈ ਵੀ ਨੋਡ LE ਤੋਂ ਪ੍ਰਮਾਣਿਤ ਬੇਨਤੀ ਦੀ ਪੁਸ਼ਟੀ ਕਰ ਸਕਦਾ ਹੈ।

   

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

   

4. ਮਿਆਦ ਪੁੱਗਣ ਦੀ ਮਿਤੀ ਤੋਂ 7 ਦਿਨ ਪਹਿਲਾਂ, ਸਰਟੀਫਿਕੇਟ ਦੁਬਾਰਾ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਸ਼ੁਰੂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ

ਇਸ ਸਮੇਂ ਅਸੀਂ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਪੂਰੀ ਤਰ੍ਹਾਂ ਪਾਰਦਰਸ਼ੀ, ਰੀਅਲ ਟਾਈਮ ਵਿੱਚ 350k ਸਰਟੀਫਿਕੇਟ ਘੁੰਮਾ ਰਹੇ ਹਾਂ।

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

ਸਿਰਫ਼ ਰਜਿਸਟਰਡ ਉਪਭੋਗਤਾ ਹੀ ਸਰਵੇਖਣ ਵਿੱਚ ਹਿੱਸਾ ਲੈ ਸਕਦੇ ਹਨ। ਸਾਈਨ - ਇਨ, ਤੁਹਾਡਾ ਸੁਆਗਤ ਹੈ.

ਤੁਸੀਂ ਪਹਿਲਾਂ ਕੀ ਜਾਣਨਾ ਚਾਹੋਗੇ?

• 14,3%ਕਲੱਸਟਰਿੰਗ ਅਤੇ ਵੈੱਬ ਟ੍ਰੈਫਿਕ ਦੀ ਗੁਣਵੱਤਾ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨ ਲਈ ਐਲਗੋਰਿਦਮ <3

• 33,3%DDoS-Guard7 ਬੈਲੇਂਸਰਾਂ ਦੇ ਅੰਦਰੂਨੀ

• 9,5%ਆਵਾਜਾਈ L3/L4 ਆਵਾਜਾਈ ਦੀ ਸੁਰੱਖਿਆ2

• 0,0%ਟ੍ਰਾਂਜ਼ਿਟ ਟ੍ਰੈਫਿਕ0 'ਤੇ ਵੈਬਸਾਈਟਾਂ ਦੀ ਸੁਰੱਖਿਆ ਕਰਨਾ

• 14,3%ਵੈੱਬ ਐਪਲੀਕੇਸ਼ਨ ਫਾਇਰਵਾਲ 3

• 28,6%ਪਾਰਸਿੰਗ ਅਤੇ ਕਲਿੱਕ ਕਰਨ ਤੋਂ ਸੁਰੱਖਿਆ 6

21 ਉਪਭੋਗਤਾਵਾਂ ਨੇ ਵੋਟ ਕੀਤਾ। 6 ਉਪਭੋਗਤਾ ਪਰਹੇਜ਼ ਰਹੇ।

ਸਰੋਤ: www.habr.com