ਟਿੱਪਣੀ ਦਾ ਵਿਸਤ੍ਰਿਤ ਜਵਾਬ, ਅਤੇ ਨਾਲ ਹੀ ਰਸ਼ੀਅਨ ਫੈਡਰੇਸ਼ਨ ਵਿੱਚ ਪ੍ਰਦਾਤਾਵਾਂ ਦੇ ਜੀਵਨ ਬਾਰੇ ਥੋੜਾ ਜਿਹਾ

ਮੈਨੂੰ ਇਸ ਪੋਸਟ ਲਈ ਪ੍ਰੇਰਿਤ ਕੀਤਾ ਇਹ ਟਿੱਪਣੀ ਹੈ.

ਮੈਂ ਇਸਦਾ ਇੱਥੇ ਹਵਾਲਾ ਦਿੰਦਾ ਹਾਂ:

ਕਾਲੇਮੈਨ ਅੱਜ 18:53 ਵਜੇ

ਮੈਂ ਅੱਜ ਪ੍ਰਦਾਤਾ ਤੋਂ ਖੁਸ਼ ਸੀ। ਸਾਈਟ ਬਲਾਕਿੰਗ ਸਿਸਟਮ ਦੇ ਅੱਪਡੇਟ ਦੇ ਨਾਲ, ਉਸਦੇ ਮੇਲਰ mail.ru 'ਤੇ ਪਾਬੰਦੀ ਲਗਾ ਦਿੱਤੀ ਗਈ ਸੀ ਮੈਂ ਸਵੇਰ ਤੋਂ ਤਕਨੀਕੀ ਸਹਾਇਤਾ ਨੂੰ ਕਾਲ ਕਰ ਰਿਹਾ ਹਾਂ, ਪਰ ਉਹ ਕੁਝ ਨਹੀਂ ਕਰ ਸਕਦੇ. ਪ੍ਰਦਾਤਾ ਛੋਟਾ ਹੈ, ਅਤੇ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਉੱਚ ਦਰਜੇ ਵਾਲੇ ਪ੍ਰਦਾਤਾ ਇਸ ਨੂੰ ਰੋਕਦੇ ਹਨ। ਮੈਂ ਸਾਰੀਆਂ ਸਾਈਟਾਂ ਦੇ ਖੁੱਲਣ ਵਿੱਚ ਇੱਕ ਮੰਦੀ ਨੂੰ ਵੀ ਦੇਖਿਆ, ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਉਹਨਾਂ ਨੇ ਕਿਸੇ ਕਿਸਮ ਦੇ ਟੇਢੇ DLP ਨੂੰ ਸਥਾਪਿਤ ਕੀਤਾ ਹੋਵੇ? ਪਹਿਲਾਂ ਪਹੁੰਚ ਨਾਲ ਕੋਈ ਸਮੱਸਿਆ ਨਹੀਂ ਸੀ। RuNet ਦੀ ਤਬਾਹੀ ਮੇਰੀਆਂ ਅੱਖਾਂ ਦੇ ਸਾਹਮਣੇ ਹੋ ਰਹੀ ਹੈ...

ਤੱਥ ਇਹ ਹੈ ਕਿ ਅਜਿਹਾ ਲਗਦਾ ਹੈ ਕਿ ਅਸੀਂ ਉਹੀ ਪ੍ਰਦਾਤਾ ਹਾਂ :)

ਅਤੇ ਸੱਚਮੁੱਚ, ਕਾਲੇਮੈਨ ਮੈਂ ਲਗਭਗ mail.ru ਨਾਲ ਸਮੱਸਿਆਵਾਂ ਦੇ ਕਾਰਨ ਦਾ ਅੰਦਾਜ਼ਾ ਲਗਾਇਆ (ਹਾਲਾਂਕਿ ਅਸੀਂ ਲੰਬੇ ਸਮੇਂ ਲਈ ਅਜਿਹੀ ਚੀਜ਼ ਵਿੱਚ ਵਿਸ਼ਵਾਸ ਕਰਨ ਤੋਂ ਇਨਕਾਰ ਕਰ ਦਿੱਤਾ ਸੀ).

ਹੇਠ ਲਿਖੇ ਨੂੰ ਦੋ ਭਾਗਾਂ ਵਿੱਚ ਵੰਡਿਆ ਜਾਵੇਗਾ:

1. mail.ru ਨਾਲ ਸਾਡੀਆਂ ਮੌਜੂਦਾ ਸਮੱਸਿਆਵਾਂ ਦੇ ਕਾਰਨ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਲੱਭਣ ਦੀ ਦਿਲਚਸਪ ਖੋਜ
2. ਅੱਜ ਦੀਆਂ ਹਕੀਕਤਾਂ ਵਿੱਚ ISP ਦੀ ਹੋਂਦ, ਪ੍ਰਭੂਸੱਤਾ RuNet ਦੀ ਸਥਿਰਤਾ।

mail.ru ਨਾਲ ਪਹੁੰਚਯੋਗਤਾ ਸਮੱਸਿਆਵਾਂ

ਓਹ, ਇਹ ਕਾਫੀ ਲੰਬੀ ਕਹਾਣੀ ਹੈ।

ਤੱਥ ਇਹ ਹੈ ਕਿ ਰਾਜ ਦੀਆਂ ਲੋੜਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ (ਦੂਜੇ ਭਾਗ ਵਿੱਚ ਹੋਰ ਵੇਰਵੇ), ਅਸੀਂ ਕੁਝ ਸਾਜ਼ੋ-ਸਾਮਾਨ ਖਰੀਦੇ, ਸੰਰਚਿਤ ਕੀਤੇ ਅਤੇ ਸਥਾਪਿਤ ਕੀਤੇ - ਵਰਜਿਤ ਸਰੋਤਾਂ ਨੂੰ ਫਿਲਟਰ ਕਰਨ ਲਈ ਅਤੇ ਲਾਗੂ ਕਰਨ ਲਈ। NAT ਅਨੁਵਾਦ ਗਾਹਕ।

ਕੁਝ ਸਮਾਂ ਪਹਿਲਾਂ, ਅਸੀਂ ਅੰਤ ਵਿੱਚ ਨੈਟਵਰਕ ਕੋਰ ਨੂੰ ਇਸ ਤਰੀਕੇ ਨਾਲ ਦੁਬਾਰਾ ਬਣਾਇਆ ਹੈ ਕਿ ਸਾਰੇ ਗਾਹਕ ਟ੍ਰੈਫਿਕ ਸਹੀ ਦਿਸ਼ਾ ਵਿੱਚ ਸਖਤੀ ਨਾਲ ਇਸ ਉਪਕਰਣ ਵਿੱਚੋਂ ਲੰਘਦੇ ਹਨ.

ਕੁਝ ਦਿਨ ਪਹਿਲਾਂ ਅਸੀਂ ਇਸ 'ਤੇ ਪਾਬੰਦੀਸ਼ੁਦਾ ਫਿਲਟਰਿੰਗ ਨੂੰ ਚਾਲੂ ਕਰ ਦਿੱਤਾ ਸੀ (ਜਦੋਂ ਕਿ ਪੁਰਾਣੇ ਸਿਸਟਮ ਨੂੰ ਕੰਮ ਕਰਨਾ ਛੱਡਦੇ ਹੋਏ) - ਸਭ ਕੁਝ ਠੀਕ ਜਾਪਦਾ ਸੀ।

ਅੱਗੇ, ਉਹਨਾਂ ਨੇ ਹੌਲੀ-ਹੌਲੀ ਗਾਹਕਾਂ ਦੇ ਵੱਖ-ਵੱਖ ਹਿੱਸਿਆਂ ਲਈ ਇਸ ਉਪਕਰਣ 'ਤੇ NAT ਨੂੰ ਸਮਰੱਥ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ। ਇਸ ਦੀ ਦਿੱਖ ਤੋਂ ਵੀ ਸਭ ਕੁਝ ਠੀਕ-ਠਾਕ ਜਾਪਦਾ ਸੀ।

ਪਰ ਅੱਜ, ਗਾਹਕਾਂ ਦੇ ਅਗਲੇ ਹਿੱਸੇ ਲਈ ਸਾਜ਼ੋ-ਸਾਮਾਨ 'ਤੇ NAT ਨੂੰ ਸਮਰੱਥ ਕਰਨ ਨਾਲ, ਸਵੇਰ ਤੋਂ ਹੀ ਸਾਨੂੰ ਅਣਉਪਲਬਧਤਾ ਜਾਂ ਅੰਸ਼ਕ ਉਪਲਬਧਤਾ ਬਾਰੇ ਬਹੁਤ ਸਾਰੀਆਂ ਸ਼ਿਕਾਇਤਾਂ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪਿਆ। mail.ru ਅਤੇ ਹੋਰ ਮੇਲ Ru ਗਰੁੱਪ ਸਰੋਤ।

ਉਹ ਜਾਂਚ ਕਰਨ ਲੱਗੇ: ਕਿਤੇ ਕੁਝ ਕਦੇ ਕਦੇ, ਕਦੇ ਕਦੇ ਭੇਜਦਾ ਹੈ TCP RST ਸਿਰਫ਼ mail.ru ਨੈੱਟਵਰਕਾਂ ਲਈ ਬੇਨਤੀਆਂ ਦੇ ਜਵਾਬ ਵਿੱਚ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਇਹ ਗਲਤ ਤਰੀਕੇ ਨਾਲ ਤਿਆਰ ਕੀਤਾ (ACK ਤੋਂ ਬਿਨਾਂ), ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਨਕਲੀ TCP RST ਭੇਜਦਾ ਹੈ। ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਸੀ:

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

ਅਨੁਮਾਨ ਕਾਲੇਮੈਨ ਅਸੀਂ ਇਹ ਵਿਚਾਰ ਵੀ ਅੱਗੇ ਰੱਖਿਆ ਕਿ ਕੋਈ "ਉੱਤਮ" ਫਿਲਟਰ ਕਰ ਰਿਹਾ ਹੈ, ਪਰ ਤੁਰੰਤ ਇਸਨੂੰ ਰੱਦ ਕਰ ਦਿੱਤਾ।

ਪਹਿਲਾਂ, ਸਾਡੇ ਕੋਲ ਕਾਫ਼ੀ ਸਮਝਦਾਰ ਅਪਲਿੰਕਸ ਹਨ ਤਾਂ ਜੋ ਸਾਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਦਾ ਦੁੱਖ ਨਾ ਝੱਲਣਾ ਪਵੇ :)

ਦੂਜਾ, ਅਸੀਂ ਕਈਆਂ ਨਾਲ ਜੁੜੇ ਹੋਏ ਹਾਂ IX ਮਾਸਕੋ ਵਿੱਚ, ਅਤੇ mail.ru ਦਾ ਟ੍ਰੈਫਿਕ ਉਹਨਾਂ ਵਿੱਚੋਂ ਲੰਘਦਾ ਹੈ - ਅਤੇ ਉਹਨਾਂ ਕੋਲ ਟ੍ਰੈਫਿਕ ਨੂੰ ਫਿਲਟਰ ਕਰਨ ਲਈ ਨਾ ਤਾਂ ਕੋਈ ਜ਼ਿੰਮੇਵਾਰੀ ਹੈ ਅਤੇ ਨਾ ਹੀ ਕੋਈ ਹੋਰ ਉਦੇਸ਼ ਹੈ।

ਦਿਨ ਦਾ ਅਗਲਾ ਅੱਧ ਉਸ 'ਤੇ ਬਿਤਾਇਆ ਗਿਆ ਜਿਸ ਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਸ਼ਮਨਵਾਦ ਕਿਹਾ ਜਾਂਦਾ ਹੈ - ਉਪਕਰਣ ਵਿਕਰੇਤਾ ਦੇ ਨਾਲ, ਜਿਸ ਲਈ ਅਸੀਂ ਉਨ੍ਹਾਂ ਦਾ ਧੰਨਵਾਦ ਕਰਦੇ ਹਾਂ, ਉਨ੍ਹਾਂ ਨੇ ਹਾਰ ਨਹੀਂ ਮੰਨੀ :)

• ਫਿਲਟਰਿੰਗ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਸਮਰੱਥ ਸੀ
• NAT ਨੂੰ ਨਵੀਂ ਸਕੀਮ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਅਯੋਗ ਬਣਾਇਆ ਗਿਆ ਸੀ
• ਟੈਸਟ ਪੀਸੀ ਨੂੰ ਇੱਕ ਵੱਖਰੇ ਵੱਖਰੇ ਪੂਲ ਵਿੱਚ ਰੱਖਿਆ ਗਿਆ ਸੀ
• IP ਐਡਰੈੱਸਿੰਗ ਬਦਲੀ ਗਈ

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

ਅੰਤ ਵਿੱਚ, ਵਿਕਰੇਤਾ ਦੇ ਨੁਮਾਇੰਦੇ ਨੇ ਭਰੋਸੇ ਨਾਲ ਕਿਹਾ ਕਿ ਹਾਰਡਵੇਅਰ ਦਾ ਇਸ ਨਾਲ ਬਿਲਕੁਲ ਕੋਈ ਲੈਣਾ-ਦੇਣਾ ਨਹੀਂ ਸੀ: rsts ਕਿਤੇ ਉੱਚੇ ਤੋਂ ਆਉਂਦੇ ਹਨ।

ਟਿੱਪਣੀਇਸ ਬਿੰਦੂ 'ਤੇ, ਕੋਈ ਕਹਿ ਸਕਦਾ ਹੈ: ਪਰ ਟੈਸਟ ਪੀਸੀ ਤੋਂ ਨਹੀਂ, ਬਲਕਿ ਡੀਪੀਆਈ ਦੇ ਉੱਪਰ ਹਾਈਵੇਅ ਤੋਂ ਡੰਪ ਲੈਣਾ ਬਹੁਤ ਸੌਖਾ ਸੀ?

ਨਹੀਂ, ਬਦਕਿਸਮਤੀ ਨਾਲ, 40+gbps ਦਾ ਡੰਪ ਲੈਣਾ (ਅਤੇ ਸਿਰਫ਼ ਮਿਰਰਿੰਗ ਵੀ) ਬਿਲਕੁਲ ਮਾਮੂਲੀ ਨਹੀਂ ਹੈ।

ਇਸ ਤੋਂ ਬਾਅਦ, ਸ਼ਾਮ ਨੂੰ, ਉੱਪਰੋਂ ਕਿਤੇ ਅਜੀਬ ਛਾਨਣ ਦੀ ਧਾਰਨਾ 'ਤੇ ਪਰਤਣ ਤੋਂ ਇਲਾਵਾ ਹੋਰ ਕੁਝ ਨਹੀਂ ਸੀ.

ਮੈਂ ਦੇਖਿਆ ਕਿ ਕਿਸ IX ਰਾਹੀਂ MRG ਨੈੱਟਵਰਕਾਂ ਦਾ ਟ੍ਰੈਫਿਕ ਹੁਣ ਲੰਘ ਰਿਹਾ ਹੈ ਅਤੇ ਬਸ ਇਸਦੇ ਲਈ bgp ਸੈਸ਼ਨਾਂ ਨੂੰ ਰੱਦ ਕਰ ਦਿੱਤਾ ਹੈ। ਅਤੇ - ਵੇਖੋ ਅਤੇ ਵੇਖੋ! - ਸਭ ਕੁਝ ਤੁਰੰਤ ਆਮ ਵਾਂਗ ਵਾਪਸ ਆ ਗਿਆ 🙁

ਇੱਕ ਪਾਸੇ, ਇਹ ਸ਼ਰਮ ਦੀ ਗੱਲ ਹੈ ਕਿ ਸਾਰਾ ਦਿਨ ਸਮੱਸਿਆ ਦੀ ਖੋਜ ਵਿੱਚ ਬਿਤਾਇਆ ਗਿਆ ਸੀ, ਹਾਲਾਂਕਿ ਇਹ ਪੰਜ ਮਿੰਟਾਂ ਵਿੱਚ ਹੱਲ ਹੋ ਗਿਆ ਸੀ.

ਦੂਜੇ ਪਾਸੇ:

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

- ਹਾਲਾਤਾਂ ਦਾ ਇੱਕ ਅਦੁੱਤੀ ਕਿਸਮਤ ਵਾਲਾ ਇਤਫ਼ਾਕ: ਇੱਕ ਨਵਾਂ ਗੁੰਝਲਦਾਰ ਹਾਰਡਵੇਅਰ ਜੋ ਖਾਸ ਤੌਰ 'ਤੇ ਭਰੋਸੇਯੋਗ ਨਹੀਂ ਹੈ ਅਤੇ ਜਿਸ ਤੋਂ ਇਹ ਸਪੱਸ਼ਟ ਨਹੀਂ ਹੈ ਕਿ ਕੀ ਉਮੀਦ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ — ਖਾਸ ਤੌਰ 'ਤੇ ਟੀਸੀਪੀ RSTs ਸਮੇਤ ਸਰੋਤਾਂ ਨੂੰ ਰੋਕਣ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ।

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

ਇਹ ਆਪਣੇ ਆਪ ਨੂੰ ਸਹੀ ਠਹਿਰਾਉਣ ਦੀ ਇੱਕ ਛੋਟੀ ਜਿਹੀ ਕੋਸ਼ਿਸ਼ ਸੀ, ਕਿਰਪਾ ਕਰਕੇ ਸਮਝੋ ਅਤੇ ਮਾਫ ਕਰੋ :)

PS: ਮੈਂ ਜਾਣਬੁੱਝ ਕੇ DPI/NAT ਜਾਂ IX ਦੇ ਨਿਰਮਾਤਾ ਦਾ ਨਾਮ ਨਹੀਂ ਲੈਂਦਾ (ਅਸਲ ਵਿੱਚ, ਮੈਨੂੰ ਉਹਨਾਂ ਬਾਰੇ ਕੋਈ ਖਾਸ ਸ਼ਿਕਾਇਤ ਵੀ ਨਹੀਂ ਹੈ, ਮੁੱਖ ਗੱਲ ਇਹ ਸਮਝਣਾ ਹੈ ਕਿ ਇਹ ਕੀ ਸੀ)

ਇੰਟਰਨੈਟ ਪ੍ਰਦਾਤਾ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ ਅੱਜ ਦੀ (ਨਾਲ ਹੀ ਕੱਲ੍ਹ ਅਤੇ ਕੱਲ੍ਹ ਦੇ ਦਿਨ ਤੋਂ ਪਹਿਲਾਂ) ਅਸਲੀਅਤ

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

ਇਸ ਭਾਗ ਵਿੱਚ, ਮੈਂ ਪਿਛਲੇ ਦਸ ਸਾਲਾਂ ਵਿੱਚ ਇੱਕ ਆਮ ISP ਦੇ ਨੈਟਵਰਕ ਕੋਰ ਦੇ "ਵਿਕਾਸ" ਦਾ ਵਰਣਨ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਾਂਗਾ।

ਦਸ ਸਾਲ ਪਹਿਲਾਂ।

ਉਹਨਾਂ ਮੁਬਾਰਕ ਸਮਿਆਂ ਵਿੱਚ, ਇੱਕ ਪ੍ਰਦਾਤਾ ਨੈਟਵਰਕ ਦਾ ਮੂਲ ਟ੍ਰੈਫਿਕ ਜਾਮ ਜਿੰਨਾ ਸਰਲ ਅਤੇ ਭਰੋਸੇਮੰਦ ਹੋ ਸਕਦਾ ਹੈ:

ਇਸ ਬਹੁਤ ਹੀ, ਬਹੁਤ ਸਰਲ ਤਸਵੀਰ ਵਿੱਚ, ਕੋਈ ਤਣੇ, ਰਿੰਗ, ip/mpls ਰੂਟਿੰਗ ਨਹੀਂ ਹਨ।

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

ਅਜਿਹੀ ਸਕੀਮ L3 (ਡਾਇਨਾਮਿਕ ਰੂਟਿੰਗ) ਅਤੇ L2 (MPLS) ਦੋਵਾਂ 'ਤੇ ਰਿਜ਼ਰਵ ਕਰਨਾ ਬਹੁਤ, ਬਹੁਤ ਆਸਾਨ ਹੈ।

ਤੁਸੀਂ ਕਿਸੇ ਵੀ ਚੀਜ਼ ਦਾ N+1 ਸਥਾਪਤ ਕਰ ਸਕਦੇ ਹੋ: ਸਰਵਰ, ਸਵਿੱਚਾਂ, ਬਾਰਡਰਾਂ ਤੱਕ ਪਹੁੰਚ - ਅਤੇ ਇੱਕ ਜਾਂ ਦੂਜੇ ਤਰੀਕੇ ਨਾਲ ਉਹਨਾਂ ਨੂੰ ਆਟੋਮੈਟਿਕ ਫੇਲਓਵਰ ਲਈ ਰਿਜ਼ਰਵ ਕਰੋ।

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

ਉਪਭੋਗਤਾ ਟ੍ਰੈਫਿਕ ਨੂੰ ਫਿਲਟਰ ਕਰਨ ਦੇ ਤਰੀਕੇ ਲੱਭਣ ਦੀ ਤੁਰੰਤ ਲੋੜ ਸੀ।

ਇੱਥੇ ਵੱਖ-ਵੱਖ ਪਹੁੰਚ ਹਨ.

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

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

ਇੱਕ ਸਮੇਂ, ਇਹਨਾਂ ਉਦੇਸ਼ਾਂ ਲਈ, ਮੈਂ ਇੱਕ ਸਧਾਰਨ ਲਿਖਿਆ ਸੀ mini dpi - ਹਾਲਾਂਕਿ ਮੈਂ ਉਸ ਨੂੰ ਬੁਲਾਉਣ ਦੀ ਹਿੰਮਤ ਵੀ ਨਹੀਂ ਕਰਦਾ. ਇਹ ਬਹੁਤ ਸਧਾਰਨ ਹੈ ਅਤੇ ਬਹੁਤ ਲਾਭਕਾਰੀ ਨਹੀਂ ਹੈ - ਹਾਲਾਂਕਿ, ਇਸਨੇ ਸਾਨੂੰ ਅਤੇ ਦਰਜਨਾਂ (ਜੇ ਸੈਂਕੜੇ ਨਹੀਂ) ਹੋਰ ਪ੍ਰਦਾਤਾਵਾਂ ਨੂੰ ਤੁਰੰਤ ਉਦਯੋਗਿਕ DPI ਪ੍ਰਣਾਲੀਆਂ 'ਤੇ ਲੱਖਾਂ ਨੂੰ ਬਾਹਰ ਕੱਢਣ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਦਿੱਤੀ, ਪਰ ਕਈ ਵਾਧੂ ਸਾਲਾਂ ਦਾ ਸਮਾਂ ਦਿੱਤਾ।

ਤਰੀਕੇ ਨਾਲ, ਉਸ ਸਮੇਂ ਅਤੇ ਮੌਜੂਦਾ ਡੀ.ਪੀ.ਆਈਤਰੀਕੇ ਨਾਲ, ਬਹੁਤ ਸਾਰੇ ਜਿਨ੍ਹਾਂ ਨੇ ਉਸ ਸਮੇਂ ਮਾਰਕੀਟ ਵਿੱਚ ਉਪਲਬਧ DPI ਸਿਸਟਮਾਂ ਨੂੰ ਖਰੀਦਿਆ ਸੀ, ਉਹਨਾਂ ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਸੁੱਟ ਦਿੱਤਾ ਸੀ। ਖੈਰ, ਉਹ ਇਸਦੇ ਲਈ ਤਿਆਰ ਨਹੀਂ ਕੀਤੇ ਗਏ ਹਨ: ਸੈਂਕੜੇ ਹਜ਼ਾਰਾਂ ਪਤੇ, ਹਜ਼ਾਰਾਂ URL.

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

ਮੈਂ ਮਾਣ ਕਰਨਾ ਚਾਹਾਂਗਾ, ਪਰ ਥੋੜਾ ਉਦਾਸ =)

ਹੁਣ ਸਭ ਕੁਝ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਸੀ:

ਇੱਕ ਦੋ ਹੋਰ ਸਾਲਾਂ ਵਿੱਚ ਹਰ ਕਿਸੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਆਡੀਟਰ ਸਨ; ਰਜਿਸਟਰੀ ਵਿੱਚ ਹੋਰ ਅਤੇ ਹੋਰ ਸਰੋਤ ਸਨ. ਕੁਝ ਪੁਰਾਣੇ ਉਪਕਰਨਾਂ (ਉਦਾਹਰਨ ਲਈ, ਸਿਸਕੋ 7600) ਲਈ, "ਸਾਈਡ-ਫਿਲਟਰਿੰਗ" ਸਕੀਮ ਸਿਰਫ਼ ਲਾਗੂ ਨਹੀਂ ਹੋ ਗਈ: 76 ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ ਰੂਟਾਂ ਦੀ ਗਿਣਤੀ 4 ਤੱਕ ਸੀਮਤ ਹੈ, ਜਦੋਂ ਕਿ ਅੱਜ ਇਕੱਲੇ IPv800 ਰੂਟਾਂ ਦੀ ਗਿਣਤੀ 6 ਦੇ ਨੇੜੇ ਹੈ। ਹਜ਼ਾਰ. ਅਤੇ ਜੇਕਰ ਇਹ ipv900000 ਵੀ ਹੈ... ਅਤੇ ਇਹ ਵੀ... ਕਿੰਨਾ ਹੈ? RKN ਪਾਬੰਦੀ ਵਿੱਚ XNUMX ਵਿਅਕਤੀਗਤ ਪਤੇ? =)

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

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

ਵੱਧ ਤੋਂ ਵੱਧ ਪ੍ਰਦਾਤਾਵਾਂ ਨੂੰ ਹਾਈਵੇਅ 'ਤੇ ਭਰੋਸੇਯੋਗਤਾ ਦੀਆਂ ਵੱਖ-ਵੱਖ ਡਿਗਰੀਆਂ ਦੇ DPI ਸਿਸਟਮ ਸਥਾਪਤ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਇੱਕ ਜਾਂ ਦੋ ਸਾਲ ਪਹਿਲਾਂ ਅਫਵਾਹਾਂ ਦੇ ਅਨੁਸਾਰ, ਲਗਭਗ ਸਾਰੇ FSB ਨੇ ਸਾਜ਼-ਸਾਮਾਨ ਦੀ ਅਸਲ ਸਥਾਪਨਾ ਦੀ ਮੰਗ ਕਰਨੀ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤੀ SORM (ਪਹਿਲਾਂ, ਜ਼ਿਆਦਾਤਰ ਪ੍ਰਦਾਤਾ ਅਧਿਕਾਰੀਆਂ ਦੀ ਪ੍ਰਵਾਨਗੀ ਨਾਲ ਪ੍ਰਬੰਧਿਤ ਕਰਦੇ ਸਨ SORM ਯੋਜਨਾ - ਕਿਤੇ ਕੁਝ ਲੱਭਣ ਦੀ ਜ਼ਰੂਰਤ ਦੀ ਸਥਿਤੀ ਵਿੱਚ ਕਾਰਜਸ਼ੀਲ ਉਪਾਵਾਂ ਦੀ ਯੋਜਨਾ)

ਪੈਸਿਆਂ ਤੋਂ ਇਲਾਵਾ (ਬਿਲਕੁਲ ਬਹੁਤ ਜ਼ਿਆਦਾ ਨਹੀਂ, ਪਰ ਫਿਰ ਵੀ ਲੱਖਾਂ), SORM ਨੂੰ ਨੈੱਟਵਰਕ ਦੇ ਨਾਲ ਹੋਰ ਬਹੁਤ ਸਾਰੇ ਹੇਰਾਫੇਰੀ ਦੀ ਲੋੜ ਹੈ।

• SORM ਨੂੰ nat ਅਨੁਵਾਦ ਤੋਂ ਪਹਿਲਾਂ "ਸਲੇਟੀ" ਉਪਭੋਗਤਾ ਪਤੇ ਦੇਖਣ ਦੀ ਲੋੜ ਹੈ
• SORM ਕੋਲ ਸੀਮਤ ਗਿਣਤੀ ਵਿੱਚ ਨੈੱਟਵਰਕ ਇੰਟਰਫੇਸ ਹਨ

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

ਭਾਵ, ਬਹੁਤ ਸਰਲ, ਇਹ ਸੀ (ਖੱਬੇ) ਬਨਾਮ ਬਣ ਗਿਆ (ਸੱਜੇ):

ਹੁਣ ਜ਼ਿਆਦਾਤਰ ਪ੍ਰਦਾਤਾਵਾਂ ਨੂੰ SORM-3 ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੀ ਵੀ ਲੋੜ ਹੁੰਦੀ ਹੈ - ਜਿਸ ਵਿੱਚ, ਹੋਰ ਚੀਜ਼ਾਂ ਦੇ ਨਾਲ, ਨੈਟ ਪ੍ਰਸਾਰਣ ਦਾ ਲੌਗਿੰਗ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ।

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

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

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

ਅਤੇ ਯਾਰੋਵਾਯਾ ਅਜੇ ਵੀ ਅੱਗੇ ਹੈ।

ਸਰੋਤ: www.habr.com