2 ਜੁਲਾਈ, 2019 ਨੂੰ ਕਲਾਉਡਫਲੇਅਰ ਆਊਟੇਜ ਦੇ ਵੇਰਵੇ

ਲਗਭਗ 9 ਸਾਲ ਪਹਿਲਾਂ Cloudflare ਇੱਕ ਛੋਟੀ ਕੰਪਨੀ ਸੀ, ਅਤੇ ਮੈਂ ਇਸਦੇ ਲਈ ਕੰਮ ਨਹੀਂ ਕੀਤਾ, ਮੈਂ ਸਿਰਫ਼ ਇੱਕ ਗਾਹਕ ਸੀ। Cloudflare ਨੂੰ ਲਾਂਚ ਕਰਨ ਤੋਂ ਇੱਕ ਮਹੀਨੇ ਬਾਅਦ, ਮੈਨੂੰ ਇੱਕ ਸੂਚਨਾ ਮਿਲੀ ਕਿ ਮੇਰੀ ਵੈਬਸਾਈਟ jgc.orgDNS ਕੰਮ ਨਹੀਂ ਕਰ ਰਿਹਾ ਜਾਪਦਾ ਹੈ। Cloudflare ਵਿੱਚ ਇੱਕ ਤਬਦੀਲੀ ਕੀਤੀ ਹੈ ਪ੍ਰੋਟੋਕੋਲ ਬਫਰ, ਅਤੇ ਇੱਕ ਟੁੱਟਿਆ DNS ਸੀ।

ਮੈਂ ਤੁਰੰਤ ਮੈਥਿਊ ਪ੍ਰਿੰਸ ਨੂੰ "ਮੇਰਾ DNS ਕਿੱਥੇ ਹੈ?" ਸਿਰਲੇਖ ਨਾਲ ਲਿਖਿਆ ਅਤੇ ਉਸਨੇ ਤਕਨੀਕੀ ਵੇਰਵਿਆਂ ਨਾਲ ਭਰਿਆ ਇੱਕ ਲੰਮਾ ਜਵਾਬ ਵਾਪਸ ਭੇਜਿਆ (ਇੱਥੇ ਸਾਰਾ ਪੱਤਰ-ਵਿਹਾਰ ਪੜ੍ਹੋ), ਜਿਸਦਾ ਮੈਂ ਜਵਾਬ ਦਿੱਤਾ:

ਵੱਲੋਂ: ਜੌਨ ਗ੍ਰਾਹਮ-ਕਮਿੰਗ
ਮਿਤੀ: ਅਕਤੂਬਰ 7, 2010, 9:14
ਵਿਸ਼ਾ: ਪੁਨਰ: ਮੇਰਾ DNS ਕਿੱਥੇ ਹੈ?
ਨੂੰ: ਮੈਥਿਊ ਪ੍ਰਿੰਸ

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

ਮੇਰੀ ਸਾਈਟ 'ਤੇ ਮੇਰੀ ਚੰਗੀ ਨਿਗਰਾਨੀ ਹੈ, ਅਤੇ ਮੈਨੂੰ ਹਰ ਅਸਫਲਤਾ ਬਾਰੇ ਇੱਕ SMS ਪ੍ਰਾਪਤ ਹੁੰਦਾ ਹੈ। ਨਿਗਰਾਨੀ ਦਰਸਾਉਂਦੀ ਹੈ ਕਿ ਅਸਫਲਤਾ 13:03:07 ਤੋਂ 14:04:12 ਤੱਕ ਆਈ ਹੈ। ਟੈਸਟ ਹਰ ਪੰਜ ਮਿੰਟ ਵਿੱਚ ਕੀਤੇ ਜਾਂਦੇ ਹਨ।

ਮੈਨੂੰ ਯਕੀਨ ਹੈ ਕਿ ਤੁਸੀਂ ਇਸਦਾ ਪਤਾ ਲਗਾ ਲਵੋਗੇ। ਕੀ ਤੁਹਾਨੂੰ ਯਕੀਨ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਯੂਰਪ ਵਿੱਚ ਆਪਣੇ ਖੁਦ ਦੇ ਵਿਅਕਤੀ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ? 🙂

ਅਤੇ ਉਸਨੇ ਜਵਾਬ ਦਿੱਤਾ:

ਵੱਲੋਂ: ਮੈਥਿਊ ਪ੍ਰਿੰਸ
ਮਿਤੀ: ਅਕਤੂਬਰ 7, 2010, 9:57
ਵਿਸ਼ਾ: ਪੁਨਰ: ਮੇਰਾ DNS ਕਿੱਥੇ ਹੈ?
ਪ੍ਰਤੀ: ਜੌਨ ਗ੍ਰਾਹਮ-ਕਮਿੰਗ

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

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

2 ਜੁਲਾਈ ਦੀਆਂ ਘਟਨਾਵਾਂ

2 ਜੁਲਾਈ ਨੂੰ ਅਸੀਂ WAFs ਲਈ ਪ੍ਰਬੰਧਿਤ ਨਿਯਮਾਂ ਵਿੱਚ ਇੱਕ ਨਵਾਂ ਨਿਯਮ ਲਾਗੂ ਕੀਤਾ ਹੈ ਜਿਸਦੇ ਕਾਰਨ CPU ਸਰੋਤ ਖਤਮ ਹੋ ਰਹੇ ਸਨ ਦੁਨੀਆ ਭਰ ਵਿੱਚ Cloudflare ਨੈੱਟਵਰਕ 'ਤੇ ਹਰ ਪ੍ਰੋਸੈਸਰ ਕੋਰ ਪ੍ਰੋਸੈਸਿੰਗ HTTP/HTTPS ਟ੍ਰੈਫਿਕ 'ਤੇ। ਅਸੀਂ ਨਵੀਆਂ ਕਮਜ਼ੋਰੀਆਂ ਅਤੇ ਖਤਰਿਆਂ ਦੇ ਜਵਾਬ ਵਿੱਚ WAFs ਲਈ ਪ੍ਰਬੰਧਿਤ ਨਿਯਮਾਂ ਵਿੱਚ ਲਗਾਤਾਰ ਸੁਧਾਰ ਕਰ ਰਹੇ ਹਾਂ। ਮਈ ਵਿੱਚ, ਉਦਾਹਰਨ ਲਈ, ਅਸੀਂ ਜਲਦਬਾਜ਼ੀ ਕੀਤੀ ਨਿਯਮ ਸ਼ਾਮਲ ਕਰੋSharePoint ਵਿੱਚ ਇੱਕ ਗੰਭੀਰ ਕਮਜ਼ੋਰੀ ਤੋਂ ਬਚਾਉਣ ਲਈ। ਸਾਡੇ WAF ਦਾ ਪੂਰਾ ਬਿੰਦੂ ਤੇਜ਼ੀ ਨਾਲ ਅਤੇ ਵਿਸ਼ਵ ਪੱਧਰ 'ਤੇ ਨਿਯਮਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੀ ਯੋਗਤਾ ਹੈ।

ਬਦਕਿਸਮਤੀ ਨਾਲ, ਪਿਛਲੇ ਵੀਰਵਾਰ ਦੇ ਅੱਪਡੇਟ ਵਿੱਚ ਇੱਕ ਨਿਯਮਤ ਸਮੀਕਰਨ ਸ਼ਾਮਲ ਸੀ ਜਿਸ ਨੇ ਬੈਕਟ੍ਰੈਕਿੰਗ 'ਤੇ ਬਹੁਤ ਜ਼ਿਆਦਾ HTTP/HTTPS CPU ਸਰੋਤ ਬਰਬਾਦ ਕੀਤੇ ਸਨ। ਨਤੀਜੇ ਵਜੋਂ ਸਾਡੇ ਕੋਰ ਪ੍ਰੌਕਸੀ, CDN, ਅਤੇ WAF ਫੰਕਸ਼ਨਾਂ ਨੂੰ ਨੁਕਸਾਨ ਹੋਇਆ। ਗ੍ਰਾਫ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ HTTP/HTTPS ਟ੍ਰੈਫਿਕ ਦੀ ਸੇਵਾ ਲਈ ਪ੍ਰੋਸੈਸਰ ਸਰੋਤ ਸਾਡੇ ਨੈਟਵਰਕ ਵਿੱਚ ਸਰਵਰਾਂ 'ਤੇ ਲਗਭਗ 100% ਤੱਕ ਪਹੁੰਚਦੇ ਹਨ।

ਇੱਕ ਘਟਨਾ ਦੌਰਾਨ ਮੌਜੂਦਗੀ ਦੇ ਇੱਕ ਬਿੰਦੂ 'ਤੇ CPU ਵਰਤੋਂ

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

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

ਜੇਕਰ ਤੁਸੀਂ ਇਹਨਾਂ ਗਾਹਕਾਂ ਵਿੱਚੋਂ ਇੱਕ ਸੀ, ਤਾਂ ਤੁਸੀਂ ਸ਼ਾਇਦ ਡਰੇ ਹੋਏ, ਗੁੱਸੇ ਅਤੇ ਪਰੇਸ਼ਾਨ ਹੋ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਸਾਡੇ ਕੋਲ ਏ ਗਲੋਬਲ ਰੁਕਾਵਟ. ਉੱਚ CPU ਖਪਤ ਇੱਕ WAF ਨਿਯਮ ਦੇ ਕਾਰਨ ਇੱਕ ਮਾੜੇ ਸ਼ਬਦਾਂ ਵਾਲੇ ਨਿਯਮਤ ਸਮੀਕਰਨ ਦੇ ਕਾਰਨ ਸੀ ਜਿਸਦੇ ਨਤੀਜੇ ਵਜੋਂ ਬਹੁਤ ਜ਼ਿਆਦਾ ਬੈਕਟ੍ਰੈਕਿੰਗ ਹੋਈ। ਇੱਥੇ ਦੋਸ਼ੀ ਸਮੀਕਰਨ ਹੈ: (?:(?:"|'|]|}||d|(?:nan|infinity|true|false|null|undefined|symbol|math)|`|-|+)+[)]*;?((?:s|-|~|!|{}||||+)*.*(?:.*=.*)))

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

ਕੀ ਹੋਇਆ ਹੈ

ਆਉ ਕ੍ਰਮ ਵਿੱਚ ਸ਼ੁਰੂ ਕਰੀਏ. ਇੱਥੇ ਹਰ ਸਮੇਂ UTC ਵਿੱਚ ਹਨ।

ਦੁਪਹਿਰ 13:42 ਵਜੇ, ਫਾਇਰਵਾਲ ਟੀਮ ਦੇ ਇੱਕ ਇੰਜੀਨੀਅਰ ਨੇ ਖੋਜ ਨਿਯਮਾਂ ਵਿੱਚ ਇੱਕ ਛੋਟੀ ਜਿਹੀ ਤਬਦੀਲੀ ਕੀਤੀ। XSS ਇੱਕ ਆਟੋਮੈਟਿਕ ਪ੍ਰਕਿਰਿਆ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ. ਇਸ ਅਨੁਸਾਰ, ਇੱਕ ਤਬਦੀਲੀ ਬੇਨਤੀ ਟਿਕਟ ਬਣਾਈ ਗਈ ਸੀ. ਅਸੀਂ ਜੀਰਾ (ਹੇਠਾਂ ਸਕ੍ਰੀਨਸ਼ੌਟ) ਰਾਹੀਂ ਅਜਿਹੀਆਂ ਟਿਕਟਾਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਦੇ ਹਾਂ।

3 ਮਿੰਟਾਂ ਬਾਅਦ, ਪੇਜਰਡਿਊਟੀ ਦਾ ਪਹਿਲਾ ਪੰਨਾ ਦਿਖਾਈ ਦਿੱਤਾ, WAF ਨਾਲ ਸਮੱਸਿਆ ਦੀ ਰਿਪੋਰਟ ਕੀਤੀ। ਇਹ ਇੱਕ ਸਿੰਥੈਟਿਕ ਟੈਸਟ ਸੀ ਜੋ ਆਮ ਕਾਰਵਾਈ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨ ਲਈ Cloudflare ਦੇ ਬਾਹਰ WAFs (ਸਾਡੇ ਕੋਲ ਸੈਂਕੜੇ ਹਨ) ਦੀ ਕਾਰਜਕੁਸ਼ਲਤਾ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ। ਇਸ ਤੋਂ ਤੁਰੰਤ ਬਾਅਦ ਹੋਰ ਕਲਾਉਡਫਲੇਅਰ ਐਂਡ-ਟੂ-ਐਂਡ ਸਰਵਿਸ ਟੈਸਟਾਂ ਦੇ ਫੇਲ੍ਹ ਹੋਣ, ਗਲੋਬਲ ਟ੍ਰੈਫਿਕ ਮੁੱਦਿਆਂ, ਵਿਆਪਕ 502 ਗਲਤੀਆਂ, ਅਤੇ ਦੁਨੀਆ ਭਰ ਦੇ ਸ਼ਹਿਰਾਂ ਵਿੱਚ ਸਾਡੇ ਪੁਆਇੰਟਸ ਆਫ ਪ੍ਰੇਜ਼ੈਂਸ (ਪੀਓਪੀ) ਦੀਆਂ ਬਹੁਤ ਸਾਰੀਆਂ ਰਿਪੋਰਟਾਂ ਬਾਰੇ ਚੇਤਾਵਨੀਆਂ ਦੇ ਪੰਨਿਆਂ ਤੋਂ ਬਾਅਦ ਕੀਤਾ ਗਿਆ ਜੋ ਕਿ ਘਾਟ ਦਾ ਸੰਕੇਤ ਦਿੰਦਾ ਹੈ। CPU ਸਰੋਤਾਂ ਦਾ।

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

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

ਸਾਡੇ ਲੰਡਨ ਦੇ ਇੰਜੀਨੀਅਰ ਉਸ ਸਮੇਂ ਮੇਨ ਹਾਲ ਵਿਚ ਇਕ ਲੈਕਚਰ ਸੁਣ ਰਹੇ ਸਨ। ਲੈਕਚਰ ਵਿੱਚ ਵਿਘਨ ਪਾਉਣਾ ਪਿਆ, ਸਾਰੇ ਇੱਕ ਵੱਡੇ ਕਾਨਫਰੰਸ ਰੂਮ ਵਿੱਚ ਇਕੱਠੇ ਹੋਏ, ਅਤੇ ਹੋਰ ਮਾਹਰਾਂ ਨੂੰ ਬੁਲਾਇਆ ਗਿਆ। ਇਹ ਕੋਈ ਆਮ ਸਮੱਸਿਆ ਨਹੀਂ ਸੀ ਜਿਸ ਨਾਲ SREs ਆਪਣੇ ਆਪ ਨਾਲ ਨਜਿੱਠ ਸਕਦੇ ਸਨ। ਸਹੀ ਮਾਹਿਰਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰਨਾ ਜ਼ਰੂਰੀ ਸੀ।

14:00 ਵਜੇ ਅਸੀਂ ਨਿਰਧਾਰਿਤ ਕੀਤਾ ਕਿ ਸਮੱਸਿਆ WAF ਨਾਲ ਸੀ ਅਤੇ ਕੋਈ ਹਮਲਾ ਨਹੀਂ ਹੋਇਆ ਸੀ। ਪ੍ਰਦਰਸ਼ਨ ਟੀਮ ਨੇ CPU ਡੇਟਾ ਨੂੰ ਖਿੱਚਿਆ ਅਤੇ ਇਹ ਸਪੱਸ਼ਟ ਹੋ ਗਿਆ ਕਿ WAF ਨੂੰ ਜ਼ਿੰਮੇਵਾਰ ਠਹਿਰਾਉਣਾ ਸੀ। ਇੱਕ ਹੋਰ ਕਰਮਚਾਰੀ ਨੇ ਸਟ੍ਰੈਸ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇਸ ਸਿਧਾਂਤ ਦੀ ਪੁਸ਼ਟੀ ਕੀਤੀ। ਕਿਸੇ ਹੋਰ ਨੇ ਲੌਗਸ ਵਿੱਚ ਦੇਖਿਆ ਕਿ WAF ਵਿੱਚ ਕੋਈ ਸਮੱਸਿਆ ਸੀ। ਦੁਪਹਿਰ 14:02 ਵਜੇ, ਪੂਰੀ ਟੀਮ ਮੇਰੇ ਕੋਲ ਆਈ ਜਦੋਂ ਇਸਨੂੰ ਗਲੋਬਲ ਕਿੱਲ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦਾ ਪ੍ਰਸਤਾਵ ਦਿੱਤਾ ਗਿਆ ਸੀ, ਕਲਾਉਡਫਲੇਅਰ ਵਿੱਚ ਬਣੀ ਇੱਕ ਵਿਧੀ ਜੋ ਦੁਨੀਆ ਭਰ ਵਿੱਚ ਇੱਕ ਹਿੱਸੇ ਨੂੰ ਬੰਦ ਕਰ ਦਿੰਦੀ ਹੈ।

Как мы сделали global kill для WAF — это отдельная история. Все не так просто. Мы используем собственные продукты, а раз наш сервис ਪਹੁੰਚ ਕੰਮ ਨਹੀਂ ਕੀਤਾ, ਅਸੀਂ ਅੰਦਰੂਨੀ ਕੰਟਰੋਲ ਪੈਨਲ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਅਤੇ ਲੌਗਇਨ ਨਹੀਂ ਕਰ ਸਕੇ (ਜਦੋਂ ਸਭ ਕੁਝ ਠੀਕ ਹੋ ਗਿਆ ਸੀ, ਸਾਨੂੰ ਪਤਾ ਲੱਗਾ ਕਿ ਕੁਝ ਟੀਮ ਮੈਂਬਰਾਂ ਨੇ ਇੱਕ ਸੁਰੱਖਿਆ ਵਿਸ਼ੇਸ਼ਤਾ ਦੇ ਕਾਰਨ ਪਹੁੰਚ ਗੁਆ ਦਿੱਤੀ ਹੈ ਜੋ ਕ੍ਰੇਡੇੰਸ਼ਿਅਲ ਨੂੰ ਅਯੋਗ ਕਰ ਦਿੰਦੀ ਹੈ ਜੇਕਰ ਅੰਦਰੂਨੀ ਕੰਟਰੋਲ ਪੈਨਲ ਨੂੰ ਇੱਕ ਲਈ ਵਰਤਿਆ ਨਹੀਂ ਜਾਂਦਾ ਹੈ ਲੰਬਾ ਸਮਾ).

ਅਤੇ ਅਸੀਂ ਆਪਣੀਆਂ ਅੰਦਰੂਨੀ ਸੇਵਾਵਾਂ, ਜਿਵੇਂ ਜੀਰਾ ਜਾਂ ਬਿਲਡ ਸਿਸਟਮ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚ ਸਕੇ। ਸਾਨੂੰ ਇੱਕ ਕਾਰਜ-ਪ੍ਰਣਾਲੀ ਦੀ ਲੋੜ ਸੀ, ਜਿਸਦੀ ਅਸੀਂ ਕਦੇ-ਕਦਾਈਂ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ (ਇਸ ਨੂੰ ਵੀ ਕੰਮ ਕਰਨ ਦੀ ਲੋੜ ਹੋਵੇਗੀ)। ਅੰਤ ਵਿੱਚ, ਇੱਕ ਇੰਜੀਨੀਅਰ 14:07 'ਤੇ WAF ਨੂੰ ਅਯੋਗ ਕਰਨ ਵਿੱਚ ਕਾਮਯਾਬ ਹੋ ਗਿਆ, ਅਤੇ 14:09 'ਤੇ, ਆਵਾਜਾਈ ਅਤੇ CPU ਪੱਧਰ ਹਰ ਥਾਂ ਆਮ ਵਾਂਗ ਹੋ ਗਏ। ਕਲਾਉਡਫਲੇਅਰ ਦੇ ਬਾਕੀ ਸੁਰੱਖਿਆ ਤੰਤਰ ਨੇ ਆਮ ਵਾਂਗ ਕੰਮ ਕੀਤਾ।

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

14:52 'ਤੇ ਸਾਨੂੰ ਯਕੀਨ ਹੋ ਗਿਆ ਕਿ ਅਸੀਂ ਕਾਰਨ ਨੂੰ ਸਮਝ ਲਿਆ ਹੈ ਅਤੇ ਇੱਕ ਸੁਧਾਰ ਕੀਤਾ ਹੈ, ਅਤੇ WAF ਨੂੰ ਦੁਬਾਰਾ ਚਾਲੂ ਕੀਤਾ ਹੈ।

Cloudflare ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ

Cloudflare ਕੋਲ WAFs ਲਈ ਨਿਯਮਾਂ ਦੇ ਪ੍ਰਬੰਧਨ ਲਈ ਸਮਰਪਿਤ ਇੰਜੀਨੀਅਰਾਂ ਦੀ ਇੱਕ ਟੀਮ ਹੈ। ਉਹ ਖੋਜ ਦਰਾਂ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਣ, ਝੂਠੇ ਸਕਾਰਾਤਮਕ ਨੂੰ ਘਟਾਉਣ, ਅਤੇ ਨਵੇਂ ਖਤਰਿਆਂ ਦੇ ਸਾਹਮਣੇ ਆਉਣ 'ਤੇ ਤੁਰੰਤ ਜਵਾਬ ਦੇਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ। ਪਿਛਲੇ 60 ਦਿਨਾਂ ਵਿੱਚ, WAF (ਔਸਤਨ ਹਰ 476 ਘੰਟੇ ਵਿੱਚ ਇੱਕ) ਲਈ ਪ੍ਰਬੰਧਿਤ ਨਿਯਮਾਂ ਲਈ 3 ਤਬਦੀਲੀ ਬੇਨਤੀਆਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕੀਤੀ ਗਈ ਹੈ।

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

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

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

ਜੇਕਰ ਬਿਲਡ ਅਤੇ ਟੈਸਟ ਸਫਲਤਾਪੂਰਵਕ ਮੁਕੰਮਲ ਹੋ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਜੀਰਾ ਵਿੱਚ ਇੱਕ ਤਬਦੀਲੀ ਦੀ ਬੇਨਤੀ ਬਣਾਈ ਜਾਂਦੀ ਹੈ ਅਤੇ ਉਚਿਤ ਮੈਨੇਜਰ ਜਾਂ ਲੀਡ ਨੂੰ ਤਬਦੀਲੀ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦੇਣੀ ਚਾਹੀਦੀ ਹੈ। ਮਨਜ਼ੂਰੀ ਤੋਂ ਬਾਅਦ, ਤੈਨਾਤੀ ਅਖੌਤੀ "PoP ਮੈਨੇਜਰੀ" ਵਿੱਚ ਹੁੰਦੀ ਹੈ: DOG, PIG ਅਤੇ ਕੈਨਰੀ (ਕੁੱਤੇ, ਸੂਰ ਅਤੇ ਕੈਨਰੀ).

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

ਜੇਕਰ DOG ਟੈਸਟ ਸਫਲ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਕੋਡ PIG (ਗਿੰਨੀ ਪਿਗ) ਪੜਾਅ 'ਤੇ ਚਲਾ ਜਾਂਦਾ ਹੈ। ਇਹ Cloudflare PoP ਹੈ, ਜਿੱਥੇ ਥੋੜ੍ਹੇ ਜਿਹੇ ਮੁਫਤ ਗਾਹਕ ਟ੍ਰੈਫਿਕ ਨਵੇਂ ਕੋਡ ਰਾਹੀਂ ਵਹਿੰਦੇ ਹਨ।
ਜੇ ਸਭ ਠੀਕ ਹੈ, ਤਾਂ ਕੋਡ ਕੈਨਰੀ ਵਿੱਚ ਚਲਾ ਜਾਂਦਾ ਹੈ। ਸਾਡੇ ਕੋਲ ਦੁਨੀਆ ਦੇ ਵੱਖ-ਵੱਖ ਹਿੱਸਿਆਂ ਵਿੱਚ ਤਿੰਨ ਕੈਨਰੀ ਪੀਓਪੀ ਹਨ। ਉਹਨਾਂ ਵਿੱਚ, ਅਦਾਇਗੀ ਅਤੇ ਮੁਫਤ ਗਾਹਕਾਂ ਦਾ ਟ੍ਰੈਫਿਕ ਨਵੇਂ ਕੋਡ ਵਿੱਚੋਂ ਲੰਘਦਾ ਹੈ, ਅਤੇ ਇਹ ਗਲਤੀਆਂ ਲਈ ਆਖਰੀ ਜਾਂਚ ਹੈ.

Cloudflare 'ਤੇ ਸਾਫਟਵੇਅਰ ਰਿਲੀਜ਼ ਪ੍ਰਕਿਰਿਆ

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

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

ਸਰੋਤ: https://cvedetails.com/

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

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

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

ਸਰੋਤ: https://cvedetails.com/

WAF ਲਈ ਇੱਕ ਪ੍ਰਬੰਧਿਤ ਨਿਯਮ ਨੂੰ ਬਦਲਣ ਦੀ ਮਿਆਰੀ ਪ੍ਰਕਿਰਿਆ ਗਲੋਬਲ ਤੈਨਾਤੀ ਤੋਂ ਪਹਿਲਾਂ ਨਿਰੰਤਰ ਏਕੀਕਰਣ (CI) ਟੈਸਟਿੰਗ ਕਰਵਾਉਣਾ ਹੈ। ਪਿਛਲੇ ਵੀਰਵਾਰ ਅਸੀਂ ਅਜਿਹਾ ਕੀਤਾ ਅਤੇ ਨਿਯਮਾਂ ਨੂੰ ਲਾਗੂ ਕੀਤਾ। ਦੁਪਹਿਰ 13:31 ਵਜੇ, ਇੱਕ ਇੰਜੀਨੀਅਰ ਨੇ ਇੱਕ ਤਬਦੀਲੀ ਦੇ ਨਾਲ ਇੱਕ ਪ੍ਰਵਾਨਿਤ ਪੁੱਲ ਬੇਨਤੀ ਦਰਜ ਕੀਤੀ।

13:37 'ਤੇ ਟੀਮਸਿਟੀ ਨੇ ਨਿਯਮ ਇਕੱਠੇ ਕੀਤੇ, ਟੈਸਟ ਕਰਵਾਏ ਅਤੇ ਅੱਗੇ ਵਧਾਇਆ। WAF ਟੈਸਟ ਸੂਟ WAF ਦੀ ਮੁੱਖ ਕਾਰਜਸ਼ੀਲਤਾ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ ਅਤੇ ਵਿਅਕਤੀਗਤ ਫੰਕਸ਼ਨਾਂ ਲਈ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਯੂਨਿਟ ਟੈਸਟਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ। ਯੂਨਿਟ ਟੈਸਟਾਂ ਤੋਂ ਬਾਅਦ, ਅਸੀਂ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ HTTP ਬੇਨਤੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ WAF ਲਈ ਨਿਯਮਾਂ ਦੀ ਜਾਂਚ ਕੀਤੀ। HTTP ਬੇਨਤੀਆਂ ਇਹ ਜਾਂਚ ਕਰਦੀਆਂ ਹਨ ਕਿ WAF (ਹਮਲੇ ਨੂੰ ਰੋਕਣ ਲਈ) ਦੁਆਰਾ ਕਿਹੜੀਆਂ ਬੇਨਤੀਆਂ ਨੂੰ ਬਲੌਕ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਕਿਸ ਦੁਆਰਾ ਆਗਿਆ ਦਿੱਤੀ ਜਾ ਸਕਦੀ ਹੈ (ਤਾਂ ਕਿ ਹਰ ਚੀਜ਼ ਨੂੰ ਬਲੌਕ ਨਾ ਕੀਤਾ ਜਾ ਸਕੇ ਅਤੇ ਝੂਠੇ ਸਕਾਰਾਤਮਕ ਤੋਂ ਬਚਿਆ ਜਾ ਸਕੇ)। ਪਰ ਅਸੀਂ ਬਹੁਤ ਜ਼ਿਆਦਾ CPU ਵਰਤੋਂ ਲਈ ਟੈਸਟ ਨਹੀਂ ਕੀਤਾ, ਅਤੇ ਪਿਛਲੇ WAF ਬਿਲਡਜ਼ ਦੇ ਲੌਗਸ ਦੀ ਜਾਂਚ ਕਰਨ ਤੋਂ ਪਤਾ ਲੱਗਦਾ ਹੈ ਕਿ ਨਿਯਮ ਟੈਸਟ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਸਮਾਂ ਨਹੀਂ ਵਧਿਆ, ਅਤੇ ਇਹ ਸ਼ੱਕ ਕਰਨਾ ਮੁਸ਼ਕਲ ਸੀ ਕਿ ਲੋੜੀਂਦੇ ਸਰੋਤ ਨਹੀਂ ਹੋਣਗੇ।

ਟੈਸਟ ਪਾਸ ਹੋ ਗਏ ਅਤੇ ਟੀਮਸਿਟੀ ਨੇ ਦੁਪਹਿਰ 13:42 ਵਜੇ ਆਪਣੇ ਆਪ ਤਬਦੀਲੀ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ।

Quicksilver

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

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

ਦੁਨੀਆ ਭਰ ਵਿੱਚ ਇੱਕ ਸੰਰਚਨਾ ਤਬਦੀਲੀ ਕਰਨ ਲਈ ਇੱਕ ਡੈਸ਼ਬੋਰਡ 'ਤੇ ਇੱਕ ਬਟਨ ਨੂੰ ਕਲਿੱਕ ਕਰਨ ਜਾਂ API ਨੂੰ ਕਾਲ ਕਰਨ ਤੋਂ ਸਿਰਫ ਕੁਝ ਸਕਿੰਟ ਲੱਗਦੇ ਹਨ। ਗਾਹਕਾਂ ਨੇ ਸੈੱਟਅੱਪ ਦੀ ਇਸ ਗਤੀ ਨੂੰ ਪਸੰਦ ਕੀਤਾ। ਅਤੇ ਵਰਕਰ ਉਹਨਾਂ ਨੂੰ ਲਗਭਗ ਤਤਕਾਲ ਗਲੋਬਲ ਸੌਫਟਵੇਅਰ ਤੈਨਾਤੀ ਦਿੰਦੇ ਹਨ। ਔਸਤਨ, Quicksilver ਪ੍ਰਤੀ ਸਕਿੰਟ ਲਗਭਗ 350 ਤਬਦੀਲੀਆਂ ਦਾ ਪ੍ਰਚਾਰ ਕਰਦਾ ਹੈ।

ਅਤੇ Quicksilver ਬਹੁਤ ਤੇਜ਼ ਹੈ. ਔਸਤਨ, ਅਸੀਂ ਦੁਨੀਆ ਭਰ ਵਿੱਚ ਹਰ ਕੰਪਿਊਟਰ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਦਾ ਪ੍ਰਚਾਰ ਕਰਨ ਲਈ 99 ਸਕਿੰਟਾਂ ਦਾ 2,29ਵਾਂ ਪ੍ਰਤੀਸ਼ਤ ਪ੍ਰਾਪਤ ਕੀਤਾ ਹੈ। ਸਪੀਡ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਚੰਗੀ ਚੀਜ਼ ਹੈ. ਆਖ਼ਰਕਾਰ, ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਫੰਕਸ਼ਨ ਨੂੰ ਸਮਰੱਥ ਕਰਦੇ ਹੋ ਜਾਂ ਕੈਸ਼ ਨੂੰ ਸਾਫ਼ ਕਰਦੇ ਹੋ, ਇਹ ਲਗਭਗ ਤੁਰੰਤ ਅਤੇ ਹਰ ਜਗ੍ਹਾ ਵਾਪਰਦਾ ਹੈ। Cloudflare ਵਰਕਰਾਂ ਦੁਆਰਾ ਕੋਡ ਭੇਜਣਾ ਉਸੇ ਗਤੀ ਨਾਲ ਹੁੰਦਾ ਹੈ। ਕਲਾਉਡਫਲੇਅਰ ਆਪਣੇ ਗਾਹਕਾਂ ਨੂੰ ਸਹੀ ਸਮੇਂ 'ਤੇ ਤੇਜ਼ੀ ਨਾਲ ਅਪਡੇਟ ਕਰਨ ਦਾ ਵਾਅਦਾ ਕਰਦਾ ਹੈ।

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

ਨਿਯਮਾਂ ਦੇ ਤੈਨਾਤ ਕੀਤੇ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ, ਸਭ ਕੁਝ ਸੁਚਾਰੂ ਢੰਗ ਨਾਲ ਚਲਿਆ ਗਿਆ: ਪੁੱਲ ਬੇਨਤੀ ਬਣਾਈ ਗਈ ਅਤੇ ਮਨਜ਼ੂਰ ਕੀਤੀ ਗਈ, CI/CD ਪਾਈਪਲਾਈਨ ਨੇ ਕੋਡ ਨੂੰ ਇਕੱਠਾ ਕੀਤਾ ਅਤੇ ਟੈਸਟ ਕੀਤਾ, ਤਬਦੀਲੀ ਦੀ ਬੇਨਤੀ SOP ਦੇ ਅਨੁਸਾਰ ਜਮ੍ਹਾਂ ਕੀਤੀ ਗਈ ਸੀ ਜੋ ਕਿ ਤੈਨਾਤੀ ਅਤੇ ਰੋਲਬੈਕ ਨੂੰ ਨਿਯੰਤ੍ਰਿਤ ਕਰਦੀ ਹੈ, ਅਤੇ ਤੈਨਾਤੀ ਪੂਰੀ ਹੋ ਗਈ ਸੀ।

Cloudflare WAF ਤੈਨਾਤੀ ਪ੍ਰਕਿਰਿਆ

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

1. ਇੱਕ ਇੰਜੀਨੀਅਰ ਨੇ ਇੱਕ ਨਿਯਮਤ ਸਮੀਕਰਨ ਲਿਖਿਆ ਜਿਸਦਾ ਨਤੀਜਾ ਬਹੁਤ ਜ਼ਿਆਦਾ ਹੋ ਸਕਦਾ ਹੈ ਬੈਕਟਰੈਕਿੰਗ.
2. ਇੱਕ ਵਿਸ਼ੇਸ਼ਤਾ ਜੋ ਨਿਯਮਤ ਸਮੀਕਰਨ ਨੂੰ ਬਹੁਤ ਜ਼ਿਆਦਾ CPU ਨੂੰ ਬਰਬਾਦ ਕਰਨ ਤੋਂ ਰੋਕ ਸਕਦੀ ਸੀ, ਨੂੰ ਕਈ ਹਫ਼ਤੇ ਪਹਿਲਾਂ WAF ਦੀ ਇੱਕ ਰੀਫੈਕਟਰਿੰਗ ਵਿੱਚ ਗਲਤੀ ਨਾਲ ਹਟਾ ਦਿੱਤਾ ਗਿਆ ਸੀ — WAF ਨੂੰ ਘੱਟ ਸਰੋਤਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ ਰੀਫੈਕਟਰਿੰਗ ਦੀ ਲੋੜ ਸੀ।
3. ਨਿਯਮਤ ਸਮੀਕਰਨ ਇੰਜਣ ਦੀ ਕੋਈ ਗੁੰਝਲਤਾ ਗਾਰੰਟੀ ਨਹੀਂ ਸੀ।
4. ਟੈਸਟ ਸੂਟ ਬਹੁਤ ਜ਼ਿਆਦਾ CPU ਖਪਤ ਦਾ ਪਤਾ ਨਹੀਂ ਲਗਾ ਸਕਿਆ।
5. SOP ਗੈਰ-ਜ਼ਰੂਰੀ ਨਿਯਮ ਤਬਦੀਲੀਆਂ ਨੂੰ ਬਹੁ-ਪੜਾਵੀ ਪ੍ਰਕਿਰਿਆ ਤੋਂ ਬਿਨਾਂ ਵਿਸ਼ਵ ਪੱਧਰ 'ਤੇ ਰੋਲਆਊਟ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ।
6. ਰੋਲਬੈਕ ਯੋਜਨਾ ਲਈ ਇੱਕ ਪੂਰੀ WAF ਬਿਲਡ ਨੂੰ ਦੋ ਵਾਰ ਚਲਾਉਣ ਦੀ ਲੋੜ ਸੀ, ਜਿਸ ਵਿੱਚ ਲੰਬਾ ਸਮਾਂ ਲੱਗਿਆ।
7. ਗਲੋਬਲ ਟ੍ਰੈਫਿਕ ਸਮੱਸਿਆਵਾਂ ਬਾਰੇ ਪਹਿਲੀ ਚੇਤਾਵਨੀ ਬਹੁਤ ਦੇਰ ਨਾਲ ਸ਼ੁਰੂ ਕੀਤੀ ਗਈ ਸੀ।
8. ਸਾਨੂੰ ਸਥਿਤੀ ਪੰਨੇ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨ ਵਿੱਚ ਕੁਝ ਸਮਾਂ ਲੱਗਾ।
9. ਸਾਨੂੰ ਇੱਕ ਗੜਬੜ ਦੇ ਕਾਰਨ ਸਿਸਟਮ ਤੱਕ ਪਹੁੰਚ ਕਰਨ ਵਿੱਚ ਸਮੱਸਿਆਵਾਂ ਸਨ, ਅਤੇ ਬਾਈਪਾਸ ਪ੍ਰਕਿਰਿਆ ਚੰਗੀ ਤਰ੍ਹਾਂ ਸਥਾਪਤ ਨਹੀਂ ਸੀ।
10. SRE ਇੰਜੀਨੀਅਰਾਂ ਨੇ ਕੁਝ ਸਿਸਟਮਾਂ ਤੱਕ ਪਹੁੰਚ ਗੁਆ ਦਿੱਤੀ ਕਿਉਂਕਿ ਸੁਰੱਖਿਆ ਕਾਰਨਾਂ ਕਰਕੇ ਉਹਨਾਂ ਦੇ ਪ੍ਰਮਾਣ ਪੱਤਰਾਂ ਦੀ ਮਿਆਦ ਖਤਮ ਹੋ ਗਈ ਸੀ।
11. ਸਾਡੇ ਗਾਹਕਾਂ ਕੋਲ Cloudflare ਡੈਸ਼ਬੋਰਡ ਜਾਂ API ਤੱਕ ਪਹੁੰਚ ਨਹੀਂ ਸੀ ਕਿਉਂਕਿ ਉਹ Cloudflare ਖੇਤਰ ਵਿੱਚੋਂ ਲੰਘਦੇ ਹਨ।

ਪਿਛਲੇ ਵੀਰਵਾਰ ਤੋਂ ਕੀ ਬਦਲਿਆ ਹੈ

ਪਹਿਲਾਂ, ਅਸੀਂ WAF ਲਈ ਰੀਲੀਜ਼ਾਂ 'ਤੇ ਸਾਰੇ ਕੰਮ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਰੋਕ ਦਿੱਤਾ ਹੈ ਅਤੇ ਹੇਠਾਂ ਦਿੱਤੇ ਕੰਮ ਕਰ ਰਹੇ ਹਾਂ:

1. ਅਸੀਂ CPU ਦੀ ਜ਼ਿਆਦਾ ਵਰਤੋਂ ਸੁਰੱਖਿਆ ਨੂੰ ਦੁਬਾਰਾ ਪੇਸ਼ ਕਰ ਰਹੇ ਹਾਂ ਜਿਸ ਨੂੰ ਅਸੀਂ ਹਟਾ ਦਿੱਤਾ ਹੈ। (ਤਿਆਰ)
2. ਬਹੁਤ ਜ਼ਿਆਦਾ ਬੈਕਟ੍ਰੈਕਿੰਗ ਦੇ ਹੋਰ ਸੰਭਾਵੀ ਮਾਮਲਿਆਂ ਨੂੰ ਲੱਭਣ ਅਤੇ ਠੀਕ ਕਰਨ ਲਈ WAF ਲਈ ਪ੍ਰਬੰਧਿਤ ਨਿਯਮਾਂ ਵਿੱਚ ਸਾਰੇ 3868 ਨਿਯਮਾਂ ਦੀ ਦਸਤੀ ਜਾਂਚ ਕਰਨਾ। (ਪੁਸ਼ਟੀਕਰਨ ਪੂਰਾ ਹੋਇਆ)
3. ਅਸੀਂ ਟੈਸਟ ਸੈੱਟ ਵਿੱਚ ਸਾਰੇ ਨਿਯਮਾਂ ਲਈ ਪ੍ਰਦਰਸ਼ਨ ਪ੍ਰੋਫਾਈਲਿੰਗ ਸ਼ਾਮਲ ਕਰਦੇ ਹਾਂ। (ਉਮੀਦ: 19 ਜੁਲਾਈ)
4. ਇੱਕ ਨਿਯਮਤ ਸਮੀਕਰਨ ਇੰਜਣ 'ਤੇ ਸਵਿਚ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ re2 ਜ ਜੰਗਾਲ - ਦੋਵੇਂ ਰਨਟਾਈਮ ਗਾਰੰਟੀ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ। (ਉਮੀਦ: 31 ਜੁਲਾਈ)
5. ਅਸੀਂ ਕਲਾਉਡਫਲੇਅਰ ਵਿੱਚ ਦੂਜੇ ਸੌਫਟਵੇਅਰ ਵਾਂਗ, ਪੜਾਵਾਂ ਵਿੱਚ ਨਿਯਮਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ SOP ਨੂੰ ਦੁਬਾਰਾ ਲਿਖ ਰਹੇ ਹਾਂ, ਪਰ ਉਸੇ ਸਮੇਂ ਜੇਕਰ ਹਮਲੇ ਪਹਿਲਾਂ ਹੀ ਸ਼ੁਰੂ ਹੋ ਚੁੱਕੇ ਹਨ ਤਾਂ ਸੰਕਟਕਾਲੀਨ ਗਲੋਬਲ ਤੈਨਾਤੀ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਹੈ।
6. ਅਸੀਂ Cloudflare ਖੇਤਰ ਤੋਂ Cloudflare ਡੈਸ਼ਬੋਰਡ ਅਤੇ API ਨੂੰ ਤੁਰੰਤ ਹਟਾਉਣ ਦੀ ਸਮਰੱਥਾ ਵਿਕਸਿਤ ਕਰ ਰਹੇ ਹਾਂ।
7. ਪੰਨਾ ਅੱਪਡੇਟ ਸਵੈਚਲਿਤ ਕਰਨਾ ਕਲਾਉਡਫਲੇਅਰ ਸਥਿਤੀ.

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

ਸਿੱਟਾ

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

ਅਸੀਂ ਇਸ ਆਊਟੇਜ ਬਾਰੇ ਬਹੁਤ ਸ਼ਰਮਿੰਦਾ ਹਾਂ ਅਤੇ ਆਪਣੇ ਗਾਹਕਾਂ ਤੋਂ ਮੁਆਫੀ ਮੰਗਦੇ ਹਾਂ। ਅਸੀਂ ਉਮੀਦ ਕਰਦੇ ਹਾਂ ਕਿ ਇਹ ਬਦਲਾਅ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਗੇ ਕਿ ਅਜਿਹਾ ਦੁਬਾਰਾ ਨਾ ਹੋਵੇ।

ਐਪਲੀਕੇਸ਼ਨ. ਰੈਗੂਲਰ ਸਮੀਕਰਨਾਂ ਨੂੰ ਬੈਕਟ੍ਰੈਕ ਕਰਨਾ

ਇਹ ਸਮਝਣ ਲਈ ਕਿ ਸਮੀਕਰਨ ਕਿਵੇਂ ਹੈ:

(?:(?:"|'|]|}||d
(?:nan|infinity|true|false|null|undefined|symbol|math)|`|-
|+)+[)]*;?((?:s|-|~|!|{}||||+)*.*(?:.*=.*)))

ਸਾਰੇ CPU ਸਰੋਤਾਂ ਨੂੰ ਖਾ ਲਿਆ, ਤੁਹਾਨੂੰ ਇਸ ਬਾਰੇ ਥੋੜਾ ਜਿਹਾ ਜਾਣਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਕਿ ਮਿਆਰੀ ਨਿਯਮਤ ਸਮੀਕਰਨ ਇੰਜਣ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ। ਇੱਥੇ ਸਮੱਸਿਆ ਪੈਟਰਨ ਹੈ .*(?:.*=.*). (?: ਅਤੇ ਅਨੁਸਾਰੀ ) ਇੱਕ ਗੈਰ-ਕੈਪਚਰਿੰਗ ਸਮੂਹ ਹੈ (ਅਰਥਾਤ, ਬਰੈਕਟਾਂ ਵਿੱਚ ਸਮੀਕਰਨ ਇੱਕ ਸਿੰਗਲ ਸਮੀਕਰਨ ਦੇ ਰੂਪ ਵਿੱਚ ਸਮੂਹਬੱਧ ਕੀਤਾ ਗਿਆ ਹੈ)।

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

ਨਿਯਮਤ ਸਮੀਕਰਨ ਵਿੱਚ . ਮਤਲਬ ਕਿ ਤੁਹਾਨੂੰ ਇੱਕ ਅੱਖਰ ਨਾਲ ਮੇਲ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, .* - ਜ਼ੀਰੋ ਜਾਂ ਵਧੇਰੇ ਅੱਖਰਾਂ ਨੂੰ "ਲਾਲਚੀ" ਨਾਲ ਮੇਲ ਕਰੋ, ਭਾਵ, ਵੱਧ ਤੋਂ ਵੱਧ ਅੱਖਰ ਕੈਪਚਰ ਕਰਨਾ, ਤਾਂ ਜੋ .*.*=.* ਮਤਲਬ ਜ਼ੀਰੋ ਜਾਂ ਵਧੇਰੇ ਅੱਖਰਾਂ ਨਾਲ ਮੇਲ ਕਰੋ, ਫਿਰ ਜ਼ੀਰੋ ਜਾਂ ਵੱਧ ਅੱਖਰਾਂ ਨਾਲ ਮੇਲ ਕਰੋ, ਸ਼ਾਬਦਿਕ = ਅੱਖਰ ਲੱਭੋ, ਜ਼ੀਰੋ ਜਾਂ ਵੱਧ ਅੱਖਰਾਂ ਨਾਲ ਮੇਲ ਕਰੋ।

ਆਓ ਟੈਸਟ ਲਾਈਨ ਲੈਂਦੇ ਹਾਂ x=x. ਇਹ ਸਮੀਕਰਨ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ .*.*=.*. .*.* ਬਰਾਬਰ ਚਿੰਨ੍ਹ ਪਹਿਲੇ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ x (ਸਮੂਹ ਵਿੱਚੋਂ ਇੱਕ .* ਨਾਲ ਸੰਬੰਧਿਤ ਹੈ x, ਅਤੇ ਦੂਜਾ - ਜ਼ੀਰੋ ਅੱਖਰ). .* ਬਾਅਦ = ਆਖਰੀ ਮੈਚ x.

ਇਸ ਤੁਲਨਾ ਲਈ 23 ਕਦਮਾਂ ਦੀ ਲੋੜ ਹੈ। ਪਹਿਲਾ ਸਮੂਹ .* в .*.*=.* ਲਾਲਚ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਪੂਰੀ ਸਤਰ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ x=x. ਇੰਜਣ ਅਗਲੇ ਸਮੂਹ ਵਿੱਚ ਜਾਂਦਾ ਹੈ .*. ਸਾਡੇ ਕੋਲ ਮੇਲ ਕਰਨ ਲਈ ਕੋਈ ਹੋਰ ਅੱਖਰ ਨਹੀਂ ਹਨ, ਇਸਲਈ ਦੂਜਾ ਸਮੂਹ .* ਜ਼ੀਰੋ ਅੱਖਰਾਂ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ (ਇਸਦੀ ਇਜਾਜ਼ਤ ਹੈ)। ਫਿਰ ਇੰਜਣ ਸਾਈਨ ਵੱਲ ਜਾਂਦਾ ਹੈ =. ਇੱਥੇ ਕੋਈ ਹੋਰ ਚਿੰਨ੍ਹ ਨਹੀਂ ਹਨ (ਪਹਿਲਾ ਸਮੂਹ .* ਪੂਰੇ ਸਮੀਕਰਨ ਦੀ ਵਰਤੋਂ ਕੀਤੀ x=x), ਕੋਈ ਤੁਲਨਾ ਨਹੀਂ ਹੁੰਦੀ।

ਅਤੇ ਫਿਰ ਰੈਗੂਲਰ ਸਮੀਕਰਨ ਇੰਜਣ ਸ਼ੁਰੂ ਵਿੱਚ ਵਾਪਸ ਆ ਜਾਂਦਾ ਹੈ। ਉਹ ਪਹਿਲੇ ਗਰੁੱਪ ਵੱਲ ਵਧਦਾ ਹੈ .* ਅਤੇ ਇਸਦੀ ਤੁਲਨਾ ਕਰਦਾ ਹੈ с x= (ਦੀ ਬਜਾਏ x=x), ਅਤੇ ਫਿਰ ਦੂਜੇ ਸਮੂਹ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ .*. ਦੂਜਾ ਸਮੂਹ .* ਦੂਜੇ ਨਾਲ ਤੁਲਨਾ ਕੀਤੀ ਜਾਂਦੀ ਹੈ x, ਅਤੇ ਸਾਡੇ ਕੋਲ ਦੁਬਾਰਾ ਕੋਈ ਅੱਖਰ ਨਹੀਂ ਬਚੇ ਹਨ। ਅਤੇ ਜਦੋਂ ਇੰਜਣ ਦੁਬਾਰਾ ਪਹੁੰਚਦਾ ਹੈ = в .*.*=.*, ਕੁਝ ਵੀ ਕੰਮ ਨਹੀਂ ਕਰਦਾ। ਅਤੇ ਉਹ ਫਿਰ ਪਿੱਛੇ ਹਟ ਜਾਂਦਾ ਹੈ।

ਇਸ ਵਾਰ ਸਮੂਹ .* ਅਜੇ ਵੀ ਮੇਲ ਖਾਂਦਾ ਹੈ x=, ਪਰ ਦੂਜਾ ਸਮੂਹ .* ਹੋਰ ਨਹੀਂ x, ਅਤੇ ਜ਼ੀਰੋ ਅੱਖਰ। ਇੰਜਣ ਇੱਕ ਸ਼ਾਬਦਿਕ ਅੱਖਰ ਲੱਭਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ ਹੈ = ਪੈਟਰਨ ਵਿੱਚ .*.*=.*, ਪਰ ਬਾਹਰ ਨਹੀਂ ਆਉਂਦਾ (ਆਖ਼ਰਕਾਰ, ਪਹਿਲੇ ਸਮੂਹ ਨੇ ਪਹਿਲਾਂ ਹੀ ਇਸ 'ਤੇ ਕਬਜ਼ਾ ਕਰ ਲਿਆ ਹੈ .*). ਅਤੇ ਉਹ ਫਿਰ ਪਿੱਛੇ ਹਟ ਜਾਂਦਾ ਹੈ।

ਇਸ ਵਾਰ ਪਹਿਲਾ ਗਰੁੱਪ .* ਸਿਰਫ਼ ਪਹਿਲਾ x ਲੈਂਦਾ ਹੈ। ਪਰ ਦੂਜਾ ਗਰੁੱਪ .* "ਲਾਲਚੀ" ਕੈਪਚਰ ਕਰਦਾ ਹੈ =x. ਕੀ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਅੰਦਾਜ਼ਾ ਲਗਾਇਆ ਹੈ ਕਿ ਕੀ ਹੋਵੇਗਾ? ਇੰਜਣ ਸ਼ਾਬਦਿਕ ਨਾਲ ਮੇਲ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ =, ਅਸਫਲ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ ਇੱਕ ਹੋਰ ਬੈਕਟਰੈਕਿੰਗ ਬਣਾਉਂਦਾ ਹੈ।

ਪਹਿਲਾ ਸਮੂਹ .* ਅਜੇ ਵੀ ਪਹਿਲੇ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ x... ਦੂਜਾ .* ਸਿਰਫ ਲੈਂਦਾ ਹੈ =. ਬੇਸ਼ੱਕ, ਇੰਜਣ ਸ਼ਾਬਦਿਕ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ =, ਕਿਉਂਕਿ ਦੂਜਾ ਸਮੂਹ ਪਹਿਲਾਂ ਹੀ ਅਜਿਹਾ ਕਰ ਚੁੱਕਾ ਹੈ .*. ਅਤੇ ਦੁਬਾਰਾ ਪਿੱਛੇ ਹਟ ਰਿਹਾ ਹੈ। ਅਤੇ ਅਸੀਂ ਤਿੰਨ ਅੱਖਰਾਂ ਦੀ ਇੱਕ ਸਤਰ ਨਾਲ ਮੇਲ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹਾਂ!

ਨਤੀਜੇ ਵਜੋਂ, ਪਹਿਲਾ ਸਮੂਹ .* ਸਿਰਫ਼ ਪਹਿਲੇ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ x, ਦੂਜਾ .* - ਜ਼ੀਰੋ ਅੱਖਰਾਂ ਦੇ ਨਾਲ, ਅਤੇ ਇੰਜਣ ਅੰਤ ਵਿੱਚ ਸ਼ਾਬਦਿਕ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ = ਪ੍ਰਗਟਾਵੇ ਵਿੱਚ с = ਇਨ ਲਾਇਨ. ਅਗਲਾ ਆਖਰੀ ਸਮੂਹ ਹੈ .* ਪਿਛਲੇ ਇੱਕ ਨਾਲ ਤੁਲਨਾ ਕੀਤੀ ਗਈ ਹੈ x.

ਲਈ ਸਿਰਫ 23 ਕਦਮ x=x. ਪਰਲ ਦੀ ਵਰਤੋਂ ਕਰਨ ਬਾਰੇ ਇੱਕ ਛੋਟਾ ਵੀਡੀਓ ਦੇਖੋ Regexp::ਡੀਬਗਰ, ਜੋ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਕਦਮ ਅਤੇ ਪਿੱਛੇ ਕਿਵੇਂ ਆਉਂਦੇ ਹਨ।

ਇਹ ਪਹਿਲਾਂ ਹੀ ਬਹੁਤ ਸਾਰਾ ਕੰਮ ਹੈ, ਪਰ ਜੇ ਇਸ ਦੀ ਬਜਾਏ x=x ਸਾਡੇ ਕੋਲ ਹੋਵੇਗਾ x=xx? ਇਹ 33 ਕਦਮ ਹੈ। ਅਤੇ ਜੇਕਰ x=xxx? 45. ਰਿਸ਼ਤਾ ਰੇਖਿਕ ਨਹੀਂ ਹੈ। ਗ੍ਰਾਫ ਤੋਂ ਤੁਲਨਾ ਦਿਖਾਉਂਦਾ ਹੈ x=x ਨੂੰ x=xxxxxxxxxxxxxxxxxxxx (20 x после =). ਜੇਕਰ ਸਾਡੇ ਕੋਲ 20 x ਬਾਅਦ ਵਿੱਚ ਹੈ =, ਇੰਜਣ 555 ਕਦਮਾਂ ਵਿੱਚ ਮੇਲ ਖਾਂਦਾ ਹੈ! (ਇਸ ਤੋਂ ਇਲਾਵਾ, ਜੇ ਅਸੀਂ ਹਾਰ ਗਏ ਹਾਂ x= ਅਤੇ ਸਤਰ ਵਿੱਚ ਸਿਰਫ਼ 20 ਹੁੰਦੇ ਹਨ x, ਇੰਜਣ ਇਹ ਸਮਝਣ ਲਈ 4067 ਕਦਮ ਚੁੱਕੇਗਾ ਕਿ ਕੋਈ ਮੇਲ ਨਹੀਂ ਹੈ)।

ਇਹ ਵੀਡੀਓ ਤੁਲਨਾ ਲਈ ਸਾਰੇ ਬੈਕਟਰੈਕਿੰਗ ਦਿਖਾਉਂਦਾ ਹੈ x=xxxxxxxxxxxxxxxxxxxx:

ਮੁਸੀਬਤ ਇਹ ਹੈ ਕਿ ਜਿਵੇਂ-ਜਿਵੇਂ ਸਤਰ ਦਾ ਆਕਾਰ ਵਧਦਾ ਹੈ, ਮੇਲਣ ਦਾ ਸਮਾਂ ਸੁਪਰ-ਰੇਖਿਕ ਤੌਰ 'ਤੇ ਵਧਦਾ ਹੈ। ਪਰ ਚੀਜ਼ਾਂ ਹੋਰ ਵੀ ਵਿਗੜ ਸਕਦੀਆਂ ਹਨ ਜੇਕਰ ਨਿਯਮਤ ਸਮੀਕਰਨ ਨੂੰ ਥੋੜ੍ਹਾ ਜਿਹਾ ਸੋਧਿਆ ਜਾਂਦਾ ਹੈ। ਮੰਨ ਲਓ ਕਿ ਸਾਡੇ ਕੋਲ ਸੀ .*.*=.*; (ਭਾਵ, ਪੈਟਰਨ ਦੇ ਅੰਤ ਵਿੱਚ ਇੱਕ ਸ਼ਾਬਦਿਕ ਸੈਮੀਕੋਲਨ ਸੀ)। ਉਦਾਹਰਨ ਲਈ, ਵਰਗੇ ਸਮੀਕਰਨ ਨਾਲ ਮੇਲ ਕਰਨ ਲਈ foo=bar;.

ਅਤੇ ਇੱਥੇ ਪਿੱਛੇ ਮੁੜਨਾ ਇੱਕ ਅਸਲ ਤਬਾਹੀ ਹੋਵੇਗੀ. ਤੁਲਨਾ ਲਈ x=x ਇਹ 90 ਕਦਮ ਲਵੇਗਾ, 23 ਨਹੀਂ। ਅਤੇ ਇਹ ਗਿਣਤੀ ਤੇਜ਼ੀ ਨਾਲ ਵਧ ਰਹੀ ਹੈ। ਤੁਲਨਾ ਕਰਨ ਲਈ x= ਅਤੇ 20 x, 5353 ਕਦਮਾਂ ਦੀ ਲੋੜ ਹੈ। ਇੱਥੇ ਚਾਰਟ ਹੈ. ਧੁਰੇ ਦੇ ਮੁੱਲਾਂ ਨੂੰ ਦੇਖੋ Y ਪਿਛਲੇ ਚਾਰਟ ਦੇ ਮੁਕਾਬਲੇ.

ਜੇਕਰ ਤੁਸੀਂ ਦਿਲਚਸਪੀ ਰੱਖਦੇ ਹੋ, ਤਾਂ ਸਾਰੇ 5353 ਅਸਫਲ ਮੈਚਿੰਗ ਕਦਮਾਂ ਨੂੰ ਦੇਖੋ x=xxxxxxxxxxxxxxxxxxxx и .*.*=.*;

ਲਾਲਚੀ ਮੇਲ ਦੀ ਬਜਾਏ ਆਲਸੀ ਵਰਤ ਕੇ, ਪਿਛਾਖੜੀ ਦੀ ਹੱਦ ਨੂੰ ਕਾਬੂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ. ਜੇਕਰ ਅਸੀਂ ਮੂਲ ਸਮੀਕਰਨ ਨੂੰ ਬਦਲਦੇ ਹਾਂ .*?.*?=.*?, ਤੁਲਨਾ ਲਈ x=x ਇਹ 11 ਕਦਮ ਲਵੇਗਾ (23 ਨਹੀਂ)। ਜਿੱਥੇ ਤੱਕ x=xxxxxxxxxxxxxxxxxxxx... ਸਾਰੇ ਕਿਉਂਕਿ ? после .* ਇੰਜਣ ਨੂੰ ਅੱਗੇ ਵਧਣ ਤੋਂ ਪਹਿਲਾਂ ਘੱਟੋ-ਘੱਟ ਅੱਖਰਾਂ ਨਾਲ ਮੇਲ ਕਰਨ ਲਈ ਕਹਿੰਦਾ ਹੈ।

ਪਰ ਆਲਸੀ ਮੈਪਿੰਗ ਬੈਕਟਰੈਕਿੰਗ ਸਮੱਸਿਆ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਹੱਲ ਨਹੀਂ ਕਰਦੇ। ਜੇ ਅਸੀਂ ਵਿਨਾਸ਼ਕਾਰੀ ਉਦਾਹਰਣ ਨੂੰ ਬਦਲਦੇ ਹਾਂ .*.*=.*; 'ਤੇ .*?.*?=.*?;, ਲਾਗੂ ਕਰਨ ਦਾ ਸਮਾਂ ਇੱਕੋ ਜਿਹਾ ਰਹੇਗਾ। x=x ਅਜੇ ਵੀ 555 ਕਦਮਾਂ ਦੀ ਲੋੜ ਹੈ, ਅਤੇ x= ਅਤੇ 20 x - ਐਕਸਐਨਯੂਐਮਐਕਸ.

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

ਇਸ ਸਮੱਸਿਆ ਦਾ ਹੱਲ 1968 ਤੋਂ ਜਾਣਿਆ ਜਾਂਦਾ ਹੈ, ਜਦੋਂ ਕੈਂਟ ਥਾਮਸਨ ਨੇ ਇੱਕ ਲੇਖ ਲਿਖਿਆ ਸੀ ਪ੍ਰੋਗਰਾਮਿੰਗ ਤਕਨੀਕਾਂ: ਨਿਯਮਤ ਸਮੀਕਰਨ ਖੋਜ ਐਲਗੋਰਿਦਮ ("ਪ੍ਰੋਗਰਾਮਿੰਗ ਢੰਗ: ਨਿਯਮਤ ਸਮੀਕਰਨ ਖੋਜ ਐਲਗੋਰਿਦਮ")। ਲੇਖ ਇੱਕ ਵਿਧੀ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਇੱਕ ਨਿਯਮਤ ਸਮੀਕਰਨ ਨੂੰ ਗੈਰ-ਨਿਰਧਾਰਨਵਾਦੀ ਸੀਮਿਤ ਸਥਿਤੀ ਮਸ਼ੀਨਾਂ ਵਿੱਚ ਬਦਲਣ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਗੈਰ-ਨਿਰਧਾਰਨਵਾਦੀ ਸੀਮਿਤ ਅਵਸਥਾ ਮਸ਼ੀਨਾਂ ਵਿੱਚ ਰਾਜ ਤਬਦੀਲੀਆਂ ਤੋਂ ਬਾਅਦ, ਇੱਕ ਐਲਗੋਰਿਦਮ ਦੀ ਵਰਤੋਂ ਕਰੋ ਜਿਸਦਾ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਸਮਾਂ ਮੇਲ ਖਾਂਦੀ ਸਟ੍ਰਿੰਗ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ।

ਪ੍ਰੋਗਰਾਮਿੰਗ ਢੰਗ
ਨਿਯਮਤ ਸਮੀਕਰਨ ਖੋਜ ਐਲਗੋਰਿਦਮ
ਕੇਨ ਥਾਮਸਨ
ਬੇਲ ਟੈਲੀਫੋਨ ਲੈਬਾਰਟਰੀਆਂ, ਇੰਕ., ਮਰੇ ਹਿੱਲ, ਨਿਊ ਜਰਸੀ

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

ਐਲਗੋਰਿਥਮ
ਪਿਛਲੀ ਖੋਜ ਐਲਗੋਰਿਦਮ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਬੈਕਟ੍ਰੈਕਿੰਗ ਹੋ ਜਾਂਦੀ ਹੈ ਜੇਕਰ ਅੰਸ਼ਕ ਤੌਰ 'ਤੇ ਸਫਲ ਖੋਜ ਨਤੀਜਾ ਦੇਣ ਵਿੱਚ ਅਸਫਲ ਰਹੀ।

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

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

ਥੌਮਸਨ ਦਾ ਲੇਖ ਗੈਰ-ਨਿਰਧਾਰਤ ਸੀਮਤ ਸਥਿਤੀ ਮਸ਼ੀਨਾਂ ਬਾਰੇ ਗੱਲ ਨਹੀਂ ਕਰਦਾ, ਪਰ ਇਹ ਰੇਖਿਕ ਸਮਾਂ ਐਲਗੋਰਿਦਮ ਦੀ ਚੰਗੀ ਤਰ੍ਹਾਂ ਵਿਆਖਿਆ ਕਰਦਾ ਹੈ ਅਤੇ ਇੱਕ ALGOL-60 ਪ੍ਰੋਗਰਾਮ ਪੇਸ਼ ਕਰਦਾ ਹੈ ਜੋ IBM 7094 ਲਈ ਅਸੈਂਬਲੀ ਭਾਸ਼ਾ ਕੋਡ ਤਿਆਰ ਕਰਦਾ ਹੈ। ਲਾਗੂ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੈ, ਪਰ ਵਿਚਾਰ ਬਹੁਤ ਸਰਲ ਹੈ।

ਮੌਜੂਦਾ ਖੋਜ ਮਾਰਗ। ਇਸਨੂੰ ਇੱਕ ਇੰਪੁੱਟ ਅਤੇ ਦੋ ਆਉਟਪੁੱਟ ਦੇ ਨਾਲ ਇੱਕ ⊕ ਆਈਕਨ ਦੁਆਰਾ ਦਰਸਾਇਆ ਗਿਆ ਹੈ।
ਚਿੱਤਰ 1 ਰੈਗੂਲਰ ਸਮੀਕਰਨ ਉਦਾਹਰਨ ਨੂੰ ਬਦਲਦੇ ਸਮੇਂ ਤੀਜੇ ਸੰਕਲਨ ਪੜਾਅ ਦੇ ਫੰਕਸ਼ਨਾਂ ਨੂੰ ਦਿਖਾਉਂਦਾ ਹੈ। ਉਦਾਹਰਨ ਵਿੱਚ ਪਹਿਲੇ ਤਿੰਨ ਅੱਖਰ a, b, c ਹਨ ਅਤੇ ਹਰੇਕ ਇੱਕ ਸਟੈਕ ਐਂਟਰੀ S[i] ਅਤੇ ਇੱਕ NNODE ਫੀਲਡ ਬਣਾਉਂਦਾ ਹੈ।

ਇੱਕ ਸਿੰਗਲ ਸਟੈਕ ਐਂਟਰੀ ਵਿੱਚ ਨਤੀਜਾ ਰੈਗੂਲਰ ਸਮੀਕਰਨ ਬਣਾਉਣ ਲਈ ਮੌਜੂਦਾ ਕੋਡ ਨੂੰ NNODE (ਦੇਖੋ ਚਿੱਤਰ 5)

ਇਹ ਉਹ ਹੈ ਜੋ ਇੱਕ ਨਿਯਮਤ ਸਮੀਕਰਨ ਵਰਗਾ ਦਿਖਾਈ ਦੇਵੇਗਾ .*.*=.*, ਜੇ ਤੁਸੀਂ ਇਸ ਦੀ ਕਲਪਨਾ ਕਰਦੇ ਹੋ ਜਿਵੇਂ ਕਿ ਥੌਮਸਨ ਦੇ ਲੇਖ ਦੀਆਂ ਤਸਵੀਰਾਂ ਵਿੱਚ.

ਚਿੱਤਰ ਵਿੱਚ. 0 ਇੱਥੇ ਪੰਜ ਰਾਜ ਹਨ ਜੋ 0 ਤੋਂ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ, ਅਤੇ 3 ਚੱਕਰ ਹਨ ਜੋ ਰਾਜ 1, 2 ਅਤੇ 3 ਤੋਂ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ। ਇਹ ਤਿੰਨ ਚੱਕਰ ਤਿੰਨ ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਹਨ .* ਇੱਕ ਨਿਯਮਤ ਸਮੀਕਰਨ ਵਿੱਚ. ਬਿੰਦੀਆਂ ਵਾਲੇ 3 ਅੰਡਾਕਾਰ ਇੱਕ ਚਿੰਨ੍ਹ ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਹਨ। ਇੱਕ ਚਿੰਨ੍ਹ ਦੇ ਨਾਲ ਓਵਲ = ਇੱਕ ਸ਼ਾਬਦਿਕ ਅੱਖਰ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ =. ਰਾਜ 4 ਫਾਈਨਲ ਹੈ। ਜੇ ਅਸੀਂ ਇਸ ਤੱਕ ਪਹੁੰਚਦੇ ਹਾਂ, ਤਾਂ ਨਿਯਮਤ ਸਮੀਕਰਨ ਮੇਲ ਖਾਂਦਾ ਹੈ.

ਇਹ ਦੇਖਣ ਲਈ ਕਿ ਅਜਿਹੇ ਸਟੇਟ ਡਾਇਗਰਾਮ ਨੂੰ ਰੈਗੂਲਰ ਸਮੀਕਰਨ ਮੈਚਿੰਗ ਲਈ ਕਿਵੇਂ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ .*.*=.*, ਅਸੀਂ ਸਟ੍ਰਿੰਗ ਮੈਚਿੰਗ ਨੂੰ ਦੇਖਾਂਗੇ x=x. ਪ੍ਰੋਗਰਾਮ ਰਾਜ 0 ਤੋਂ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ ਚਿੱਤਰ ਵਿੱਚ ਦਿਖਾਇਆ ਗਿਆ ਹੈ। 1.

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

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

ਚਿੱਤਰ ਵਿੱਚ. 2 ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਜਦੋਂ ਉਹ ਪਹਿਲੀ ਵਾਰ ਵੇਖਦਾ ਹੈ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ x в x=x. x ਰਾਜ 1 ਤੋਂ ਅਤੇ ਰਾਜ 1 ਤੋਂ ਵਾਪਸ ਜਾ ਕੇ, ਸਿਖਰਲੇ ਬਿੰਦੂ ਤੇ ਮੈਪ ਕਰ ਸਕਦਾ ਹੈ। ਜਾਂ x ਸਟੇਟ 2 ਤੋਂ ਅਤੇ ਸਟੇਟ 2 ਤੋਂ ਵਾਪਸ ਜਾ ਕੇ, ਹੇਠਾਂ ਦਿੱਤੇ ਬਿੰਦੂ ਤੱਕ ਮੈਪ ਕਰ ਸਕਦਾ ਹੈ।

ਪਹਿਲੇ ਮੇਲ ਕਰਨ ਤੋਂ ਬਾਅਦ x в x=x ਅਸੀਂ ਅਜੇ ਵੀ ਰਾਜ 1 ਅਤੇ 2 ਵਿੱਚ ਹਾਂ। ਅਸੀਂ ਰਾਜ 3 ਜਾਂ 4 ਤੱਕ ਨਹੀਂ ਪਹੁੰਚ ਸਕਦੇ ਕਿਉਂਕਿ ਸਾਨੂੰ ਇੱਕ ਸ਼ਾਬਦਿਕ ਅੱਖਰ ਦੀ ਲੋੜ ਹੈ =.

ਐਲਗੋਰਿਦਮ ਫਿਰ ਵਿਚਾਰ ਕਰਦਾ ਹੈ = в x=x. ਇਸ ਤੋਂ ਪਹਿਲਾਂ x ਵਾਂਗ, ਇਸ ਨੂੰ ਰਾਜ 1 ਤੋਂ ਰਾਜ 1 ਜਾਂ ਰਾਜ 2 ਤੋਂ ਰਾਜ 2 ਤੱਕ ਚੋਟੀ ਦੇ ਦੋ ਲੂਪਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਨਾਲ ਮੇਲਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਪਰ ਐਲਗੋਰਿਦਮ ਸ਼ਾਬਦਿਕ ਨਾਲ ਮੇਲ ਕਰ ਸਕਦਾ ਹੈ = ਅਤੇ ਰਾਜ 2 ਤੋਂ ਰਾਜ 3 (ਅਤੇ ਤੁਰੰਤ 4) ਵਿੱਚ ਚਲੇ ਜਾਓ। ਇਹ ਚਿੱਤਰ ਵਿੱਚ ਦਿਖਾਇਆ ਗਿਆ ਹੈ. 3.

ਐਲਗੋਰਿਦਮ ਫਿਰ ਆਖਰੀ ਵੱਲ ਜਾਂਦਾ ਹੈ x в x=x. ਰਾਜ 1 ਅਤੇ 2 ਤੋਂ ਰਾਜ 1 ਅਤੇ 2 ਵਿੱਚ ਉਹੀ ਤਬਦੀਲੀ ਸੰਭਵ ਹੈ। ਰਾਜ 3 ਤੋਂ x ਸੱਜੇ ਪਾਸੇ ਦੇ ਬਿੰਦੂ ਨਾਲ ਮੇਲ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਰਾਜ 3 'ਤੇ ਵਾਪਸ ਜਾ ਸਕਦਾ ਹੈ।

ਇਸ ਪੜਾਅ 'ਤੇ, ਹਰੇਕ ਪਾਤਰ x=x ਮੰਨਿਆ, ਅਤੇ ਕਿਉਂਕਿ ਅਸੀਂ ਸਟੇਟ 4 'ਤੇ ਪਹੁੰਚ ਗਏ ਹਾਂ, ਰੈਗੂਲਰ ਸਮੀਕਰਨ ਉਸ ਸਤਰ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ। ਹਰੇਕ ਅੱਖਰ ਨੂੰ ਇੱਕ ਵਾਰ ਸੰਸਾਧਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਇਸਲਈ ਇਹ ਐਲਗੋਰਿਦਮ ਇਨਪੁਟ ਸਤਰ ਦੀ ਲੰਬਾਈ ਵਿੱਚ ਰੇਖਿਕ ਹੈ। ਅਤੇ ਕੋਈ ਪਿੱਛੇ ਨਹੀਂ।

ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ, ਰਾਜ 4 ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਬਾਅਦ (ਜਦੋਂ ਐਲਗੋਰਿਦਮ ਮੇਲ ਖਾਂਦਾ ਹੈ x=) ਸਾਰਾ ਨਿਯਮਤ ਸਮੀਕਰਨ ਮੇਲ ਖਾਂਦਾ ਹੈ, ਅਤੇ ਐਲਗੋਰਿਦਮ ਇਸ 'ਤੇ ਵਿਚਾਰ ਕੀਤੇ ਬਿਨਾਂ ਸਮਾਪਤ ਹੋ ਸਕਦਾ ਹੈ x.

ਇਹ ਐਲਗੋਰਿਦਮ ਇੰਪੁੱਟ ਸਤਰ ਦੇ ਆਕਾਰ 'ਤੇ ਰੇਖਿਕ ਤੌਰ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ।

ਸਰੋਤ: www.habr.com