ਉਹ ਨੈੱਟਵਰਕ ਜੋ ਆਪਣੇ ਆਪ ਨੂੰ ਠੀਕ ਕਰਦਾ ਹੈ: ਫਲੋ ਲੇਬਲ ਦਾ ਜਾਦੂ ਅਤੇ ਕੋਰ ਡਿਟੈਕਟਿਵ Linuxਯਾਂਡੇਕਸ ਰਿਪੋਰਟ

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

- ਸ਼ੁਰੂ ਕਰਨ ਲਈ, ਮੈਂ ਉਹਨਾਂ ਲਈ ਇੱਕ ਕਾਫ਼ੀ ਵਿਸਤ੍ਰਿਤ ਜਾਣ-ਪਛਾਣ ਦੇਵਾਂਗਾ ਜੋ ਸ਼ਾਇਦ ਇੱਕ ਆਧੁਨਿਕ DC ਦੀ ਬਣਤਰ ਤੋਂ ਜਾਣੂ ਨਹੀਂ ਹਨ।


ਬਹੁਤ ਸਾਰੇ ਨੈਟਵਰਕ ਇੰਜਨੀਅਰਾਂ ਲਈ, ਇੱਕ ਡਾਟਾ ਸੈਂਟਰ ਨੈਟਵਰਕ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਬੇਸ਼ਕ, ToR ਦੇ ਨਾਲ, ਰੈਕ ਵਿੱਚ ਇੱਕ ਸਵਿੱਚ ਦੇ ਨਾਲ. ਟੀਓਆਰ ਵਿੱਚ ਆਮ ਤੌਰ 'ਤੇ ਦੋ ਤਰ੍ਹਾਂ ਦੇ ਲਿੰਕ ਹੁੰਦੇ ਹਨ। ਛੋਟੇ ਸਰਵਰਾਂ 'ਤੇ ਜਾਂਦੇ ਹਨ, ਦੂਸਰੇ - ਉਨ੍ਹਾਂ ਵਿਚੋਂ N ਗੁਣਾ ਜ਼ਿਆਦਾ ਹਨ - ਪਹਿਲੇ ਪੱਧਰ ਦੇ ਸਪਾਈਨਸ ਵੱਲ ਜਾਂਦੇ ਹਨ, ਯਾਨੀ ਇਸਦੇ ਅਪਲਿੰਕਸ ਵੱਲ. ਅੱਪਲਿੰਕਸ ਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਬਰਾਬਰ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਅੱਪਲਿੰਕਸ ਵਿਚਕਾਰ ਆਵਾਜਾਈ 5-ਟੂਪਲ ਤੋਂ ਹੈਸ਼ ਦੇ ਆਧਾਰ 'ਤੇ ਸੰਤੁਲਿਤ ਹੁੰਦੀ ਹੈ, ਜਿਸ ਵਿੱਚ ਪ੍ਰੋਟੋ, src_ip, dst_ip, src_port, dst_port ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ। ਇੱਥੇ ਕੋਈ ਹੈਰਾਨੀ ਨਹੀਂ।


ਅੱਗੇ, ਯੋਜਨਾ ਆਰਕੀਟੈਕਚਰ ਕਿਹੋ ਜਿਹਾ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ? ਪਹਿਲੇ ਪੱਧਰ ਦੇ ਸਪਾਈਨਸ ਇੱਕ ਦੂਜੇ ਨਾਲ ਨਹੀਂ ਜੁੜੇ ਹੋਏ ਹਨ, ਪਰ ਸੁਪਰਸਪਾਈਨ ਦੁਆਰਾ ਜੁੜੇ ਹੋਏ ਹਨ। ਅੱਖਰ X ਸੁਪਰਸਪਾਈਨ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੋਵੇਗਾ; ਇਹ ਲਗਭਗ ਇੱਕ ਕਰਾਸ-ਕਨੈਕਟ ਵਰਗਾ ਹੈ।


ਅਤੇ ਇਹ ਸਪੱਸ਼ਟ ਹੈ ਕਿ, ਦੂਜੇ ਪਾਸੇ, ਟੋਰੀ ਪਹਿਲੇ ਪੱਧਰ ਦੀਆਂ ਸਾਰੀਆਂ ਰੀੜ੍ਹਾਂ ਨਾਲ ਜੁੜੇ ਹੋਏ ਹਨ. ਇਸ ਤਸਵੀਰ ਵਿੱਚ ਕੀ ਮਹੱਤਵਪੂਰਨ ਹੈ? ਜੇਕਰ ਸਾਡੇ ਕੋਲ ਰੈਕ ਦੇ ਅੰਦਰ ਪਰਸਪਰ ਪ੍ਰਭਾਵ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਪਰਸਪਰ ਪ੍ਰਭਾਵ, ਬੇਸ਼ਕ, ਟੀ.ਆਰ. ਜੇਕਰ ਪਰਸਪਰ ਕਿਰਿਆ ਮੋਡੀਊਲ ਦੇ ਅੰਦਰ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਪਰਸਪਰ ਕ੍ਰਿਆ ਪਹਿਲੇ ਪੱਧਰ ਦੇ ਸਪਾਈਨਸ ਦੁਆਰਾ ਹੁੰਦੀ ਹੈ। ਜੇਕਰ ਪਰਸਪਰ ਕ੍ਰਿਆ ਇੰਟਰਮੋਡਿਊਲਰ ਹੈ - ਜਿਵੇਂ ਕਿ ਇੱਥੇ, ToR 1 ਅਤੇ ToR 2 - ਤਾਂ ਪਰਸਪਰ ਕ੍ਰਿਆ ਪਹਿਲੇ ਅਤੇ ਦੂਜੇ ਪੱਧਰਾਂ ਦੇ ਸਪਾਈਨਸ ਵਿੱਚੋਂ ਲੰਘੇਗੀ।


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


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


ਇੱਥੇ ਅੱਠ ਜਹਾਜ਼ ਹਨ, ਹਰੇਕ ਜਹਾਜ਼ ਵਿੱਚ 32 ਸੁਪਰਸਪਾਈਨ ਹਨ। ਨਤੀਜੇ ਵਜੋਂ, ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਮੋਡੀਊਲ ਦੇ ਅੰਦਰ ਅੱਠ ਮਾਰਗ ਹਨ, ਅਤੇ ਇੰਟਰਮੋਡਿਊਲ ਪਰਸਪਰ ਪ੍ਰਭਾਵ ਨਾਲ ਉਹਨਾਂ ਵਿੱਚੋਂ 256 ਪਹਿਲਾਂ ਹੀ ਹਨ।

ਭਾਵ, ਜੇਕਰ ਅਸੀਂ ਕੁੱਕਬੁੱਕ ਦਾ ਵਿਕਾਸ ਕਰ ਰਹੇ ਹਾਂ, ਇਹ ਸਿੱਖਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹਾਂ ਕਿ ਨੁਕਸ-ਸਹਿਣਸ਼ੀਲ ਡੇਟਾ ਸੈਂਟਰਾਂ ਨੂੰ ਕਿਵੇਂ ਬਣਾਇਆ ਜਾਵੇ ਜੋ ਆਪਣੇ ਆਪ ਨੂੰ ਠੀਕ ਕਰਦੇ ਹਨ, ਤਾਂ ਪਲੈਨਰ ​​ਆਰਕੀਟੈਕਚਰ ਸਹੀ ਚੋਣ ਹੈ। ਇਹ ਸਕੇਲਿੰਗ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਦਾ ਹੈ, ਅਤੇ ਸਿਧਾਂਤ ਵਿੱਚ ਇਹ ਆਸਾਨ ਹੈ. ਬਹੁਤ ਸਾਰੇ ਸੁਤੰਤਰ ਮਾਰਗ ਹਨ. ਸਵਾਲ ਰਹਿੰਦਾ ਹੈ: ਅਜਿਹੀ ਆਰਕੀਟੈਕਚਰ ਅਸਫਲਤਾਵਾਂ ਤੋਂ ਕਿਵੇਂ ਬਚਦਾ ਹੈ? ਵੱਖ-ਵੱਖ ਅਸਫਲਤਾਵਾਂ ਹਨ. ਅਤੇ ਅਸੀਂ ਹੁਣ ਇਸ ਬਾਰੇ ਚਰਚਾ ਕਰਾਂਗੇ.


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


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


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


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


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


ਕੀ ਹੁੰਦਾ ਹੈ ਜੇਕਰ ਅਸੀਂ ਪੈਕੇਟ 3 ਗੁਆ ਦਿੰਦੇ ਹਾਂ? ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਪ੍ਰਾਪਤਕਰਤਾ ਨੂੰ ਪੈਕੇਟ 1, 2 ਅਤੇ 4 ਪ੍ਰਾਪਤ ਹੋਣਗੇ। ਅਤੇ ਉਹ SACK ਵਿਕਲਪ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਭੇਜਣ ਵਾਲੇ ਨੂੰ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਦੱਸੇਗਾ: "ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ, ਤਿੰਨ ਆਏ, ਪਰ ਵਿਚਕਾਰਲਾ ਗੁਆਚ ਗਿਆ ਸੀ।" ਉਹ ਕਹਿੰਦਾ ਹੈ, "ਐਕ 2, ਸੈਕ 4।"


ਇਸ ਸਮੇਂ, ਭੇਜਣ ਵਾਲਾ ਬਿਨਾਂ ਕਿਸੇ ਸਮੱਸਿਆ ਦੇ ਉਸੇ ਪੈਕੇਟ ਨੂੰ ਦੁਹਰਾਉਂਦਾ ਹੈ ਜੋ ਗੁਆਚ ਗਿਆ ਸੀ.


ਪਰ ਜੇਕਰ ਵਿੰਡੋ ਵਿੱਚ ਆਖਰੀ ਪੈਕੇਟ ਗੁੰਮ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਸਥਿਤੀ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵੱਖਰੀ ਦਿਖਾਈ ਦੇਵੇਗੀ.

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


RTO ਸਮਾਂ ਸਮਾਪਤ ਕੀ ਹੈ? ਇਹ TCP ਸਟੈਕ ਦੁਆਰਾ ਗਿਣਿਆ ਗਿਆ RTT ਦਾ ਅਧਿਕਤਮ ਅਤੇ ਕੁਝ ਸਥਿਰ ਹੈ। ਇਹ ਕਿਸ ਕਿਸਮ ਦਾ ਸਥਿਰ ਹੈ, ਅਸੀਂ ਹੁਣ ਚਰਚਾ ਕਰਾਂਗੇ.


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


ਹੁਣ ਦੇਖਦੇ ਹਾਂ ਕਿ ਇਹ ਅਧਾਰ ਕਿਸ ਦੇ ਬਰਾਬਰ ਹੈ। ਮੂਲ ਰੂਪ ਵਿੱਚ, ਘੱਟੋ-ਘੱਟ RTO 200 ms ਹੈ। ਡਾਟਾ ਪੈਕੇਜਾਂ ਲਈ ਇਹ ਘੱਟੋ-ਘੱਟ RTO ਹੈ। SYN ਪੈਕੇਟਾਂ ਲਈ ਇਹ ਵੱਖਰਾ ਹੈ, 1 ਸਕਿੰਟ। ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ, ਪੈਕਟਾਂ ਨੂੰ ਦੁਬਾਰਾ ਭੇਜਣ ਦੀ ਪਹਿਲੀ ਕੋਸ਼ਿਸ਼ ਵੀ ਡਾਟਾ ਸੈਂਟਰ ਦੇ ਅੰਦਰ RTT ਨਾਲੋਂ 100 ਗੁਣਾ ਜ਼ਿਆਦਾ ਸਮਾਂ ਲਵੇਗੀ।


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


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


ਇੱਥੇ ਦੋ ਕਲਾਸਿਕ ਹੱਲ ਹਨ ਜੋ ਇੱਕ ਦੂਜੇ ਦੇ ਪੂਰਕ ਹਨ। ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਉਹ ਸੇਵਾਵਾਂ ਹਨ ਜੋ ਪਰਾਲੀ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਹੱਲ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੀਆਂ ਹਨ: “ਆਓ ਟੀਸੀਪੀ ਸਟੈਕ ਵਿੱਚ ਕੁਝ ਟਵੀਕ ਕਰੀਏ। ਆਓ ਐਪਲੀਕੇਸ਼ਨ ਪੱਧਰ ਜਾਂ ਅੰਦਰੂਨੀ ਸਿਹਤ ਜਾਂਚਾਂ ਦੇ ਨਾਲ ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਚੱਲਣ ਵਾਲੇ TCP ਸੈਸ਼ਨਾਂ 'ਤੇ ਸਮਾਂ ਸਮਾਪਤ ਕਰੀਏ। ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਅਜਿਹੇ ਹੱਲ: a) ਬਿਲਕੁਲ ਵੀ ਸਕੇਲ ਨਾ ਕਰੋ; b) ਬਹੁਤ ਮਾੜੀ ਜਾਂਚ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਭਾਵ, ਭਾਵੇਂ ਸੇਵਾ ਗਲਤੀ ਨਾਲ TCP ਸਟੈਕ ਨੂੰ ਇਸ ਤਰੀਕੇ ਨਾਲ ਕੌਂਫਿਗਰ ਕਰਦੀ ਹੈ ਜੋ ਇਸਨੂੰ ਬਿਹਤਰ ਬਣਾਉਂਦੀ ਹੈ, ਪਹਿਲਾਂ, ਇਹ ਸਾਰੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਅਤੇ ਸਾਰੇ ਡੇਟਾ ਸੈਂਟਰਾਂ ਲਈ ਲਾਗੂ ਹੋਣ ਦੀ ਸੰਭਾਵਨਾ ਨਹੀਂ ਹੈ, ਅਤੇ ਦੂਜਾ, ਸਭ ਤੋਂ ਵੱਧ ਸੰਭਾਵਨਾ ਹੈ, ਇਹ ਨਹੀਂ ਸਮਝੇਗਾ ਕਿ ਇਹ ਕੀਤਾ ਗਿਆ ਸੀ ਸਹੀ, ਅਤੇ ਕੀ ਨਹੀਂ. ਭਾਵ, ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ, ਪਰ ਇਹ ਮਾੜਾ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਸਕੇਲ ਨਹੀਂ ਕਰਦਾ. ਅਤੇ ਜੇਕਰ ਕੋਈ ਨੈੱਟਵਰਕ ਸਮੱਸਿਆ ਹੈ, ਤਾਂ ਕੌਣ ਜ਼ਿੰਮੇਵਾਰ ਹੈ? ਬੇਸ਼ੱਕ ਐਨ.ਓ.ਸੀ. NOC ਕੀ ਕਰਦਾ ਹੈ?

ਕਈ ਸੇਵਾਵਾਂ ਦਾ ਮੰਨਣਾ ਹੈ ਕਿ NOC ਵਿੱਚ ਕੰਮ ਕੁਝ ਅਜਿਹਾ ਹੁੰਦਾ ਹੈ। ਪਰ ਇਮਾਨਦਾਰ ਹੋਣ ਲਈ, ਸਿਰਫ ਇਹ ਹੀ ਨਹੀਂ.


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


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

ਪਰ ਇੱਥੇ ਇੱਕ ਸੂਖਮਤਾ ਹੈ. ਇਹ ਸਮਝਣ ਲਈ ਕਿ ਇਹ ਕੀ ਹੈ, ਸਾਨੂੰ ਇਹ ਦੇਖਣਾ ਹੋਵੇਗਾ ਕਿ ਧਾਗੇ ਕਿਵੇਂ ਸਥਾਪਿਤ ਕੀਤੇ ਜਾਂਦੇ ਹਨ।


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


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


ਸਾਡੀ ਕੀ ਮਦਦ ਕਰ ਸਕਦੀ ਹੈ? ਤੁਹਾਡੇ ਵਿੱਚੋਂ ਕੁਝ ਲੋਕਾਂ ਨੇ ਪਹਿਲਾਂ ਹੀ ਸਿਰਲੇਖ ਤੋਂ ਅੰਦਾਜ਼ਾ ਲਗਾ ਲਿਆ ਹੋਵੇਗਾ ਕਿ ਸਾਡੀ ਅਗਲੀ ਚਰਚਾ ਵਿੱਚ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਖੇਤਰ IPv6 ਫਲੋ ਲੇਬਲ ਹੈਡਰ ਖੇਤਰ ਹੋਵੇਗਾ। ਦਰਅਸਲ, ਇਹ ਖੇਤਰ, ਜੋ ਕਿ v6 ਵਿੱਚ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ ਅਤੇ v4 ਤੋਂ ਗੈਰਹਾਜ਼ਰ ਹੈ, 20 ਬਿੱਟਾਂ 'ਤੇ ਕਬਜ਼ਾ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਸਦੀ ਵਰਤੋਂ ਬਹੁਤ ਬਹਿਸ ਦਾ ਵਿਸ਼ਾ ਰਹੀ ਹੈ। ਇਹ ਬਹੁਤ ਦਿਲਚਸਪ ਹੈ - ਬਹਿਸ ਹੋਈ, RFC ਵਿੱਚ ਕੁਝ ਚੀਜ਼ਾਂ ਠੀਕ ਕੀਤੀਆਂ ਗਈਆਂ ਸਨ, ਅਤੇ Linux- ਉਸੇ ਸਮੇਂ, ਕਰਨਲ ਵਿੱਚ ਇੱਕ ਲਾਗੂਕਰਨ ਪ੍ਰਗਟ ਹੋਇਆ, ਜਿਸਦਾ ਕਿਤੇ ਵੀ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਸੀ।


ਮੈਂ ਤੁਹਾਨੂੰ ਇੱਕ ਛੋਟੀ ਜਿਹੀ ਜਾਂਚ 'ਤੇ ਮੇਰੇ ਨਾਲ ਜੁੜਨ ਲਈ ਸੱਦਾ ਦਿੰਦਾ ਹਾਂ। ਆਓ ਦੇਖੀਏ ਕਿ ਮੂਲ ਵਿੱਚ ਕੀ ਹੋ ਰਿਹਾ ਸੀ। Linux ਪਿਛਲੇ ਕੁਝ ਸਾਲਾਂ ਤੋਂ।

2014. ਇੱਕ ਵੱਡੀ ਅਤੇ ਸਤਿਕਾਰਤ ਕੰਪਨੀ ਦਾ ਇੱਕ ਇੰਜੀਨੀਅਰ ਕਰਨਲ ਵਿੱਚ ਕਾਰਜਸ਼ੀਲਤਾ ਜੋੜਦਾ ਹੈ Linux ਫਲੋ ਲੇਬਲ ਮੁੱਲ ਦੀ ਸਾਕਟ ਹੈਸ਼ 'ਤੇ ਨਿਰਭਰਤਾ। ਉਹ ਇੱਥੇ ਕੀ ਠੀਕ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਸਨ? ਇਹ RFC 6438 ਨਾਲ ਸਬੰਧਤ ਹੈ, ਜਿਸ ਨੇ ਹੇਠ ਲਿਖੀ ਸਮੱਸਿਆ 'ਤੇ ਚਰਚਾ ਕੀਤੀ। ਇੱਕ ਡੇਟਾ ਸੈਂਟਰ ਦੇ ਅੰਦਰ, IPv4 ਅਕਸਰ IPv6 ਪੈਕੇਟਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਫੈਬਰਿਕ ਖੁਦ IPv6 ਹੈ, ਪਰ IPv4 ਨੂੰ ਬਾਹਰੀ ਤੌਰ 'ਤੇ ਡਿਲੀਵਰ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਲੰਬੇ ਸਮੇਂ ਤੋਂ, ਸਵਿੱਚਾਂ ਨਾਲ ਸਮੱਸਿਆਵਾਂ ਸਨ ਜੋ TCP ਜਾਂ UDP ਤੱਕ ਪਹੁੰਚਣ ਅਤੇ src_ports ਅਤੇ dst_ports ਲੱਭਣ ਲਈ ਦੋ IP ਹੈੱਡਰਾਂ ਦੇ ਹੇਠਾਂ ਨਹੀਂ ਦੇਖ ਸਕਦੇ ਸਨ। ਇਸਦਾ ਮਤਲਬ ਸੀ ਕਿ ਹੈਸ਼, ਜਦੋਂ ਪਹਿਲੇ ਦੋ IP ਹੈੱਡਰਾਂ ਨੂੰ ਦੇਖਦੇ ਹੋ, ਤਾਂ ਵਿਵਹਾਰਕ ਤੌਰ 'ਤੇ ਠੀਕ ਹੋ ਗਿਆ ਸੀ। ਇਸ ਤੋਂ ਬਚਣ ਲਈ, ਅਤੇ ਇਸ ਇਨਕੈਪਸੂਲੇਟਡ ਟ੍ਰੈਫਿਕ ਦੇ ਸਹੀ ਸੰਤੁਲਨ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ, 5-ਟੂਪਲ ਇਨਕੈਪਸੂਲੇਟਡ ਪੈਕੇਟ ਦੇ ਹੈਸ਼ ਨੂੰ ਫਲੋ ਲੇਬਲ ਖੇਤਰ ਵਿੱਚ ਜੋੜਨ ਦਾ ਪ੍ਰਸਤਾਵ ਕੀਤਾ ਗਿਆ ਸੀ। ਮੋਟੇ ਤੌਰ 'ਤੇ ਇਹੀ ਹੋਰ ਇਨਕੈਪਸੂਲੇਸ਼ਨ ਸਕੀਮਾਂ ਲਈ ਕੀਤਾ ਗਿਆ ਸੀ, UDP ਲਈ ਅਤੇ GRE ਲਈ, GRE ਕੀ ਫੀਲਡ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਬਾਅਦ ਵਾਲੇ ਲਈ। ਕਿਸੇ ਵੀ ਸਥਿਤੀ ਵਿੱਚ, ਇੱਥੇ ਟੀਚੇ ਸਪੱਸ਼ਟ ਹਨ। ਅਤੇ ਘੱਟੋ ਘੱਟ ਉਸ ਸਮੇਂ ਉਹ ਉਪਯੋਗੀ ਸਨ।

2015 ਵਿੱਚ, ਇੱਕ ਨਵਾਂ ਪੈਚ ਉਸੇ ਮਾਣਯੋਗ ਇੰਜੀਨੀਅਰ ਤੋਂ ਆਇਆ ਹੈ. ਉਹ ਬਹੁਤ ਦਿਲਚਸਪ ਹੈ। ਇਹ ਹੇਠਾਂ ਦੱਸਦਾ ਹੈ - ਅਸੀਂ ਇੱਕ ਨਕਾਰਾਤਮਕ ਰੂਟਿੰਗ ਘਟਨਾ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਹੈਸ਼ ਨੂੰ ਬੇਤਰਤੀਬ ਕਰਾਂਗੇ. ਇੱਕ ਨਕਾਰਾਤਮਕ ਰੂਟਿੰਗ ਘਟਨਾ ਕੀ ਹੈ? ਇਹ ਉਹ ਆਰਟੀਓ ਹੈ ਜਿਸ ਬਾਰੇ ਅਸੀਂ ਪਹਿਲਾਂ ਚਰਚਾ ਕੀਤੀ ਸੀ, ਯਾਨੀ ਵਿੰਡੋ ਦੀ ਪੂਛ ਦਾ ਨੁਕਸਾਨ ਇੱਕ ਘਟਨਾ ਹੈ ਜੋ ਸੱਚਮੁੱਚ ਨਕਾਰਾਤਮਕ ਹੈ. ਇਹ ਸੱਚ ਹੈ, ਇਹ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣਾ ਮੁਕਾਬਲਤਨ ਮੁਸ਼ਕਲ ਹੈ ਕਿ ਇਹ ਇਹ ਹੈ.

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

ਹਾਲਾਂਕਿ ਨਹੀਂ, ਤੁਸੀਂ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਕਿਉਂਕਿ ਇਸ ਵਿਸ਼ੇ 'ਤੇ ਇੱਕ ਵੀ ਪ੍ਰਕਾਸ਼ਨ ਨਹੀਂ ਹੋਇਆ ਹੈ। ਪਰ ਅਸੀਂ ਜਾਣਦੇ ਹਾਂ!

ਅਤੇ ਜੇਕਰ ਤੁਸੀਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਹੀਂ ਸਮਝਦੇ ਹੋ ਕਿ ਕੀ ਕੀਤਾ ਗਿਆ ਸੀ, ਤਾਂ ਮੈਂ ਤੁਹਾਨੂੰ ਹੁਣ ਦੱਸਾਂਗਾ।


ਕਰਨਲ ਵਿੱਚ ਕੀ ਕੀਤਾ ਗਿਆ ਸੀ, ਕਿਹੜੀ ਕਾਰਜਸ਼ੀਲਤਾ ਜੋੜੀ ਗਈ ਸੀ? Linux? ਹਰੇਕ RTO ਘਟਨਾ ਤੋਂ ਬਾਅਦ txhash ਇੱਕ ਬੇਤਰਤੀਬ ਮੁੱਲ ਵਿੱਚ ਬਦਲ ਜਾਂਦਾ ਹੈ। ਇਹ ਉਹੀ ਨੈਗੇਟਿਵ ਰੂਟਿੰਗ ਨਤੀਜਾ ਹੈ। ਹੈਸ਼ ਇਸ txhash 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਫਲੋ ਲੇਬਲ skb ਹੈਸ਼ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਇੱਥੇ ਕੁਝ ਕਾਰਜਸ਼ੀਲ ਵਿਆਖਿਆਵਾਂ ਹਨ, ਪਰ ਇੱਕ ਸਲਾਈਡ ਸਾਰੇ ਵੇਰਵਿਆਂ ਨੂੰ ਕਵਰ ਨਹੀਂ ਕਰੇਗੀ। ਜੇਕਰ ਕੋਈ ਉਤਸੁਕ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਕਰਨਲ ਕੋਡ ਵਿੱਚੋਂ ਲੰਘ ਸਕਦੇ ਹੋ ਅਤੇ ਜਾਂਚ ਕਰ ਸਕਦੇ ਹੋ।

ਇੱਥੇ ਕੀ ਮਹੱਤਵਪੂਰਨ ਹੈ? ਪ੍ਰਵਾਹ ਲੇਬਲ ਖੇਤਰ ਦਾ ਮੁੱਲ ਹਰੇਕ RTO ਤੋਂ ਬਾਅਦ ਇੱਕ ਬੇਤਰਤੀਬ ਨੰਬਰ ਵਿੱਚ ਬਦਲ ਜਾਂਦਾ ਹੈ। ਇਹ ਸਾਡੀ ਮੰਦਭਾਗੀ TCP ਸਟ੍ਰੀਮ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ?


ਜੇਕਰ ਕੋਈ SACK ਵਾਪਰਦਾ ਹੈ, ਤਾਂ ਕੁਝ ਨਹੀਂ ਬਦਲਦਾ ਕਿਉਂਕਿ ਅਸੀਂ ਇੱਕ ਜਾਣੇ-ਪਛਾਣੇ ਗੁੰਮ ਹੋਏ ਪੈਕੇਟ ਨੂੰ ਦੁਬਾਰਾ ਭੇਜਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹਾਂ। ਹੁਣ ਤੱਕ ਬਹੁਤ ਵਧੀਆ.


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


ਇੱਕ ਸਮੱਸਿਆ ਰਹਿੰਦੀ ਹੈ - ਆਰ.ਟੀ.ਓ. ਬੇਸ਼ੱਕ, ਇੱਕ ਹੋਰ ਰਸਤਾ ਹੈ, ਪਰ ਇਸ 'ਤੇ ਬਹੁਤ ਸਾਰਾ ਸਮਾਂ ਬਰਬਾਦ ਹੁੰਦਾ ਹੈ. 200 ms ਬਹੁਤ ਹੈ। ਇੱਕ ਸਕਿੰਟ ਬਿਲਕੁਲ ਜੰਗਲੀ ਹੈ. ਪਹਿਲਾਂ, ਮੈਂ ਟਾਈਮਆਉਟ ਬਾਰੇ ਗੱਲ ਕੀਤੀ ਸੀ ਕਿ ਸੇਵਾਵਾਂ ਨੂੰ ਕੌਂਫਿਗਰ ਕੀਤਾ ਗਿਆ ਹੈ। ਇਸ ਲਈ, ਇੱਕ ਸਕਿੰਟ ਇੱਕ ਸਮਾਂ ਸਮਾਪਤ ਹੁੰਦਾ ਹੈ, ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਐਪਲੀਕੇਸ਼ਨ ਪੱਧਰ 'ਤੇ ਸੇਵਾ ਦੁਆਰਾ ਕੌਂਫਿਗਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਇਸ ਵਿੱਚ ਸੇਵਾ ਮੁਕਾਬਲਤਨ ਸਹੀ ਵੀ ਹੋਵੇਗੀ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਮੈਂ ਦੁਹਰਾਉਂਦਾ ਹਾਂ, ਆਧੁਨਿਕ ਡਾਟਾ ਸੈਂਟਰ ਦੇ ਅੰਦਰ ਅਸਲ RTT ਲਗਭਗ 1 ਮਿਲੀਸਕਿੰਟ ਹੈ।


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


ਇਹ ਸੱਚ ਹੈ, SYN_RTO ਨਾਲ ਸਭ ਕੁਝ ਥੋੜਾ ਬੁਰਾ ਹੈ। ਇਹ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਨੱਕੋ-ਨੱਕ ਭਰਿਆ ਹੋਇਆ ਹੈ। ਕਰਨਲ ਦਾ 1 ਸਕਿੰਟ ਦਾ ਇੱਕ ਨਿਸ਼ਚਿਤ ਮੁੱਲ ਹੈ, ਅਤੇ ਇਹ ਹੈ। ਤੁਸੀਂ ਉਪਭੋਗਤਾ ਸਪੇਸ ਤੋਂ ਉੱਥੇ ਨਹੀਂ ਪਹੁੰਚ ਸਕਦੇ ਹੋ। ਇੱਕ ਹੀ ਤਰੀਕਾ ਹੈ।


eBPF ਬਚਾਅ ਲਈ ਆਉਂਦਾ ਹੈ। ਇਸਨੂੰ ਸਧਾਰਨ ਰੂਪ ਵਿੱਚ ਕਹਿਣ ਲਈ, ਇਹ ਛੋਟੇ C ਪ੍ਰੋਗਰਾਮ ਹਨ। ਇਹਨਾਂ ਨੂੰ ਕਰਨਲ ਸਟੈਕ ਅਤੇ TCP ਸਟੈਕ ਦੇ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਥਾਵਾਂ ਤੇ ਹੁੱਕਾਂ ਵਿੱਚ ਪਾਇਆ ਜਾ ਸਕਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਤੁਸੀਂ ਬਹੁਤ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਸੈਟਿੰਗਾਂ ਨੂੰ ਬਦਲ ਸਕਦੇ ਹੋ। ਆਮ ਤੌਰ 'ਤੇ, eBPF ਇੱਕ ਲੰਬੇ ਸਮੇਂ ਦਾ ਰੁਝਾਨ ਹੈ। ਦਰਜਨਾਂ ਨਵੇਂ sysctl ਪੈਰਾਮੀਟਰਾਂ ਨੂੰ ਕੱਟਣ ਅਤੇ IP ਉਪਯੋਗਤਾ ਦਾ ਵਿਸਥਾਰ ਕਰਨ ਦੀ ਬਜਾਏ, ਅੰਦੋਲਨ eBPF ਵੱਲ ਵਧ ਰਿਹਾ ਹੈ ਅਤੇ ਇਸਦੀ ਕਾਰਜਸ਼ੀਲਤਾ ਨੂੰ ਵਧਾ ਰਿਹਾ ਹੈ. eBPF ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਤੁਸੀਂ ਭੀੜ-ਭੜੱਕੇ ਦੇ ਨਿਯੰਤਰਣ ਅਤੇ ਕਈ ਹੋਰ TCP ਸੈਟਿੰਗਾਂ ਨੂੰ ਗਤੀਸ਼ੀਲ ਰੂਪ ਵਿੱਚ ਬਦਲ ਸਕਦੇ ਹੋ।


ਪਰ ਇਹ ਸਾਡੇ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿ ਇਸਦੀ ਵਰਤੋਂ SYN_RTO ਮੁੱਲਾਂ ਨੂੰ ਬਦਲਣ ਲਈ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਇੱਥੇ ਇੱਕ ਜਨਤਕ ਤੌਰ 'ਤੇ ਪੋਸਟ ਕੀਤੀ ਗਈ ਉਦਾਹਰਣ ਹੈ: https://elixir.bootlin.com/linux/latest/source/samples/bpf/tcp_synrto_kern.c. ਇੱਥੇ ਕੀ ਕੀਤਾ ਗਿਆ ਹੈ? ਉਦਾਹਰਣ ਕੰਮ ਕਰ ਰਹੀ ਹੈ, ਪਰ ਆਪਣੇ ਆਪ ਵਿਚ ਬਹੁਤ ਮੋਟਾ ਹੈ. ਇੱਥੇ ਇਹ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ ਕਿ ਡੇਟਾ ਸੈਂਟਰ ਦੇ ਅੰਦਰ ਅਸੀਂ ਪਹਿਲੇ 44 ਬਿੱਟਾਂ ਦੀ ਤੁਲਨਾ ਕਰਦੇ ਹਾਂ; ਜੇਕਰ ਉਹ ਮੇਲ ਖਾਂਦੇ ਹਨ, ਤਾਂ ਅਸੀਂ ਡੇਟਾ ਸੈਂਟਰ ਦੇ ਅੰਦਰ ਹਾਂ. ਅਤੇ ਇਸ ਸਥਿਤੀ ਵਿੱਚ ਅਸੀਂ SYN_RTO ਸਮਾਂ ਸਮਾਪਤੀ ਮੁੱਲ ਨੂੰ 4ms ਵਿੱਚ ਬਦਲਦੇ ਹਾਂ। ਉਹੀ ਕੰਮ ਹੋਰ ਵੀ ਸ਼ਾਨਦਾਰ ਢੰਗ ਨਾਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਪਰ ਇਹ ਸਧਾਰਨ ਉਦਾਹਰਣ ਦਰਸਾਉਂਦੀ ਹੈ ਕਿ ਇਹ ਇੱਕ) ਸੰਭਵ ਹੈ; b) ਮੁਕਾਬਲਤਨ ਸਧਾਰਨ.

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


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


ਤੁਸੀਂ ਇੱਥੇ ਕੀ ਕਰ ਸਕਦੇ ਹੋ? ਤੁਹਾਡੇ ਨਿਯੰਤਰਿਤ ਵਾਤਾਵਰਣ ਦੇ ਅੰਦਰ, ਜਿੱਥੇ ਤੁਸੀਂ ਪ੍ਰਵਾਹ ਲੇਬਲ ਸੰਤੁਲਨ ਨੂੰ ਸਮਰੱਥ ਬਣਾਉਂਦੇ ਹੋ, ਤੁਹਾਨੂੰ ਕਿਸੇ ਵੀ ਕਾਸਟ ਸਰਵਰ ਤੱਕ ਪਹੁੰਚ ਕਰਨ ਵੇਲੇ ਪ੍ਰਵਾਹ ਲੇਬਲ ਦੇ ਮੁੱਲ ਨੂੰ ਰਿਕਾਰਡ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇੱਕੋ ਈਬੀਪੀਐਫ ਪ੍ਰੋਗਰਾਮ ਰਾਹੀਂ ਅਜਿਹਾ ਕਰਨਾ ਸਭ ਤੋਂ ਆਸਾਨ ਤਰੀਕਾ ਹੈ। ਪਰ ਇੱਥੇ ਇੱਕ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਨੁਕਤਾ ਹੈ - ਜੇਕਰ ਤੁਸੀਂ ਇੱਕ ਡਾਟਾ ਸੈਂਟਰ ਨੈਟਵਰਕ ਨਹੀਂ ਚਲਾਉਂਦੇ, ਪਰ ਇੱਕ ਟੈਲੀਕਾਮ ਆਪਰੇਟਰ ਹੋ ਤਾਂ ਕੀ ਕਰਨਾ ਹੈ? ਇਹ ਤੁਹਾਡੀ ਸਮੱਸਿਆ ਵੀ ਹੈ: ਜੂਨੀਪਰ ਅਤੇ ਅਰਿਸਟਾ ਦੇ ਕੁਝ ਸੰਸਕਰਣਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋਏ, ਉਹ ਡਿਫੌਲਟ ਤੌਰ 'ਤੇ ਆਪਣੇ ਹੈਸ਼ ਫੰਕਸ਼ਨਾਂ ਵਿੱਚ ਇੱਕ ਪ੍ਰਵਾਹ ਲੇਬਲ ਸ਼ਾਮਲ ਕਰਦੇ ਹਨ - ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ, ਇੱਕ ਕਾਰਨ ਕਰਕੇ ਜੋ ਮੇਰੇ ਲਈ ਅਸਪਸ਼ਟ ਹੈ। ਇਹ ਤੁਹਾਡੇ ਨੈੱਟਵਰਕ ਵਿੱਚੋਂ ਲੰਘਣ ਵਾਲੇ ਉਪਭੋਗਤਾਵਾਂ ਤੋਂ TCP ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਛੱਡਣ ਦਾ ਕਾਰਨ ਬਣ ਸਕਦਾ ਹੈ। ਇਸ ਲਈ ਮੈਂ ਇੱਥੇ ਆਪਣੀਆਂ ਰਾਊਟਰ ਸੈਟਿੰਗਾਂ ਦੀ ਜਾਂਚ ਕਰਨ ਦੀ ਜ਼ੋਰਦਾਰ ਸਿਫਾਰਸ਼ ਕਰਦਾ ਹਾਂ.

ਇੱਕ ਤਰੀਕੇ ਨਾਲ ਜਾਂ ਕੋਈ ਹੋਰ, ਇਹ ਮੈਨੂੰ ਜਾਪਦਾ ਹੈ ਕਿ ਅਸੀਂ ਪ੍ਰਯੋਗਾਂ ਲਈ ਅੱਗੇ ਵਧਣ ਲਈ ਤਿਆਰ ਹਾਂ.


ਜਦੋਂ ਅਸੀਂ ToR 'ਤੇ ਪ੍ਰਵਾਹ ਲੇਬਲ ਨੂੰ ਸਮਰੱਥ ਬਣਾਇਆ, eBPF ਏਜੰਟ ਤਿਆਰ ਕੀਤਾ, ਜੋ ਹੁਣ ਮੇਜ਼ਬਾਨਾਂ 'ਤੇ ਰਹਿੰਦਾ ਹੈ, ਅਸੀਂ ਅਗਲੀ ਵੱਡੀ ਅਸਫਲਤਾ ਦੀ ਉਡੀਕ ਕਰਨ ਦਾ ਨਹੀਂ, ਪਰ ਨਿਯੰਤਰਿਤ ਵਿਸਫੋਟ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ। ਅਸੀਂ ToR ਲਿਆ, ਜਿਸ ਵਿੱਚ ਚਾਰ ਅਪਲਿੰਕ ਹਨ, ਅਤੇ ਉਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਉੱਤੇ ਡ੍ਰੌਪ ਸੈੱਟ ਕੀਤੇ। ਉਨ੍ਹਾਂ ਨੇ ਇੱਕ ਨਿਯਮ ਬਣਾਇਆ ਅਤੇ ਕਿਹਾ - ਹੁਣ ਤੁਸੀਂ ਸਾਰੇ ਪੈਕਟ ਗੁਆ ਰਹੇ ਹੋ। ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਖੱਬੇ ਪਾਸੇ ਦੇਖ ਸਕਦੇ ਹੋ, ਸਾਡੇ ਕੋਲ ਪ੍ਰਤੀ-ਪੈਕੇਟ ਨਿਗਰਾਨੀ ਹੈ, ਜੋ ਕਿ ਘਟ ਕੇ 75% ਹੋ ਗਈ ਹੈ, ਯਾਨੀ 25% ਪੈਕੇਟ ਗੁੰਮ ਹੋ ਗਏ ਹਨ। ਸੱਜੇ ਪਾਸੇ ਇਸ ਟੀਓਆਰ ਦੇ ਪਿੱਛੇ ਰਹਿ ਰਹੀਆਂ ਸੇਵਾਵਾਂ ਦੇ ਗ੍ਰਾਫ ਹਨ। ਅਸਲ ਵਿੱਚ, ਇਹ ਰੈਕ ਦੇ ਅੰਦਰ ਸਰਵਰਾਂ ਦੇ ਨਾਲ ਇੰਟਰਫੇਸ ਦੇ ਟ੍ਰੈਫਿਕ ਗ੍ਰਾਫ ਹਨ. ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ, ਉਹ ਹੋਰ ਵੀ ਹੇਠਾਂ ਡੁੱਬ ਗਏ. ਉਹ ਘੱਟ ਕਿਉਂ ਹੋਏ - 25% ਨਹੀਂ, ਪਰ ਕੁਝ ਮਾਮਲਿਆਂ ਵਿੱਚ 3-4 ਵਾਰ? ਜੇਕਰ TCP ਕੁਨੈਕਸ਼ਨ ਬਦਕਿਸਮਤ ਹੈ, ਤਾਂ ਇਹ ਟੁੱਟੇ ਜੰਕਸ਼ਨ ਰਾਹੀਂ ਪਹੁੰਚਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨਾ ਜਾਰੀ ਰੱਖਦਾ ਹੈ। ਇਹ DC ਦੇ ਅੰਦਰ ਸੇਵਾ ਦੇ ਆਮ ਵਿਵਹਾਰ ਦੁਆਰਾ ਵਧਦਾ ਹੈ - ਇੱਕ ਉਪਭੋਗਤਾ ਬੇਨਤੀ ਲਈ, ਅੰਦਰੂਨੀ ਸੇਵਾਵਾਂ ਲਈ N ਬੇਨਤੀਆਂ ਤਿਆਰ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਅਤੇ ਜਵਾਬ ਉਪਭੋਗਤਾ ਨੂੰ ਜਾਂ ਤਾਂ ਉਦੋਂ ਜਾਵੇਗਾ ਜਦੋਂ ਸਾਰੇ ਡੇਟਾ ਸਰੋਤ ਜਵਾਬ ਦਿੰਦੇ ਹਨ, ਜਾਂ ਜਦੋਂ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਸਮਾਂ ਸਮਾਪਤ ਹੁੰਦਾ ਹੈ ਪੱਧਰ, ਜਿਸ ਨੂੰ ਅਜੇ ਵੀ ਸੰਰਚਿਤ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਭਾਵ, ਸਭ ਕੁਝ ਬਹੁਤ, ਬਹੁਤ ਬੁਰਾ ਹੈ.


ਹੁਣ ਉਹੀ ਪ੍ਰਯੋਗ ਹੈ, ਪਰ ਪ੍ਰਵਾਹ ਲੇਬਲ ਮੁੱਲ ਦੇ ਨਾਲ ਸਮਰੱਥ ਹੈ। ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਵੇਖ ਸਕਦੇ ਹੋ, ਖੱਬੇ ਪਾਸੇ ਸਾਡੇ ਬੈਚ ਦੀ ਨਿਗਰਾਨੀ ਉਸੇ 25% ਦੁਆਰਾ ਘਟੀ ਹੈ. ਇਹ ਬਿਲਕੁਲ ਸਹੀ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਰੀਟ੍ਰਾਂਸਮਿਟਾਂ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਜਾਣਦਾ, ਇਹ ਪੈਕੇਟ ਭੇਜਦਾ ਹੈ ਅਤੇ ਬਸ ਡਿਲੀਵਰ ਕੀਤੇ ਅਤੇ ਗੁੰਮ ਹੋਏ ਪੈਕੇਟਾਂ ਦੀ ਸੰਖਿਆ ਦੇ ਅਨੁਪਾਤ ਦੀ ਗਿਣਤੀ ਕਰਦਾ ਹੈ।

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

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

ਨੈਟਵਰਕ ਇੰਜਨੀਅਰਾਂ ਨੂੰ ਇੱਕ ਸੰਕਲਪਿਕ ਸ਼ਿਫਟ ਤੋਂ ਗੁਜ਼ਰਨਾ ਚਾਹੀਦਾ ਹੈ: ਨੈਟਵਰਕ ToR ਨਾਲ ਨਹੀਂ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਨੈਟਵਰਕ ਡਿਵਾਈਸ ਨਾਲ ਨਹੀਂ, ਪਰ ਹੋਸਟ ਨਾਲ. ਇੱਕ ਬਹੁਤ ਹੀ ਸ਼ਾਨਦਾਰ ਉਦਾਹਰਨ ਇਹ ਹੈ ਕਿ ਅਸੀਂ RTO ਨੂੰ ਬਦਲਣ ਅਤੇ ਕਿਸੇ ਵੀ ਕਾਸਟ ਸੇਵਾਵਾਂ ਲਈ ਪ੍ਰਵਾਹ ਲੇਬਲ ਨੂੰ ਠੀਕ ਕਰਨ ਲਈ eBPF ਦੀ ਵਰਤੋਂ ਕਿਵੇਂ ਕਰਦੇ ਹਾਂ।

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

ਸਰੋਤ: www.habr.com