ਕਾਰਵਾਈ ਵਿੱਚ QUIC ਪ੍ਰੋਟੋਕੋਲ: Uber ਨੇ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਣ ਲਈ ਇਸਨੂੰ ਕਿਵੇਂ ਲਾਗੂ ਕੀਤਾ

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

ਤਸਵੀਰਾਂ ਕਲਿੱਕ ਕਰਨ ਯੋਗ ਹਨ। ਪੜ੍ਹਨ ਦਾ ਆਨੰਦ ਮਾਣੋ!

ਉਬੇਰ ਦਾ ਇੱਕ ਗਲੋਬਲ ਪੱਧਰ ਹੈ, ਅਰਥਾਤ ਮੌਜੂਦਗੀ ਵਾਲੇ 600 ਸ਼ਹਿਰ ਹਨ, ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਹਰੇਕ ਵਿੱਚ ਐਪਲੀਕੇਸ਼ਨ 4500 ਤੋਂ ਵੱਧ ਸੈਲੂਲਰ ਆਪਰੇਟਰਾਂ ਤੋਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵਾਇਰਲੈੱਸ ਇੰਟਰਨੈਟ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ। ਉਪਭੋਗਤਾ ਉਮੀਦ ਕਰਦੇ ਹਨ ਕਿ ਐਪ ਸਿਰਫ ਤੇਜ਼ ਨਹੀਂ, ਬਲਕਿ ਅਸਲ ਸਮੇਂ ਵਿੱਚ - ਇਸ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ, Uber ਐਪ ਨੂੰ ਘੱਟ ਲੇਟੈਂਸੀ ਅਤੇ ਇੱਕ ਬਹੁਤ ਹੀ ਭਰੋਸੇਯੋਗ ਕਨੈਕਸ਼ਨ ਦੀ ਲੋੜ ਹੈ। ਹਾਏ, ਪਰ ਸਟੈਕ HTTP / 2 ਗਤੀਸ਼ੀਲ ਅਤੇ ਘਾਟੇ ਵਾਲੇ ਵਾਇਰਲੈੱਸ ਨੈੱਟਵਰਕਾਂ ਵਿੱਚ ਚੰਗਾ ਕੰਮ ਨਹੀਂ ਕਰਦਾ। ਅਸੀਂ ਮਹਿਸੂਸ ਕੀਤਾ ਕਿ ਇਸ ਕੇਸ ਵਿੱਚ, ਘੱਟ ਕਾਰਗੁਜ਼ਾਰੀ ਦਾ ਸਿੱਧਾ ਸਬੰਧ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਕਰਨਲ ਵਿੱਚ TCP ਲਾਗੂ ਕਰਨ ਨਾਲ ਹੈ।

ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ, ਅਸੀਂ ਅਰਜ਼ੀ ਦਿੱਤੀ QUIC, ਇੱਕ ਆਧੁਨਿਕ ਚੈਨਲ ਮਲਟੀਪਲੈਕਸਿੰਗ ਪ੍ਰੋਟੋਕੋਲ ਜੋ ਸਾਨੂੰ ਟ੍ਰਾਂਸਪੋਰਟ ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ 'ਤੇ ਵਧੇਰੇ ਨਿਯੰਤਰਣ ਦਿੰਦਾ ਹੈ। ਵਰਤਮਾਨ ਵਿੱਚ ਕਾਰਜ ਸਮੂਹ ਆਈ.ਈ.ਟੀ.ਐੱਫ QUIC ਨੂੰ ਮਾਨਕੀਕਰਨ ਕਰਦਾ ਹੈ HTTP / 3.

ਵਿਆਪਕ ਜਾਂਚ ਤੋਂ ਬਾਅਦ, ਅਸੀਂ ਸਿੱਟਾ ਕੱਢਿਆ ਕਿ ਸਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ QUIC ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੇ ਨਤੀਜੇ ਵਜੋਂ TCP ਦੇ ਮੁਕਾਬਲੇ ਘੱਟ ਟੇਲ ਲੇਟੈਂਸੀ ਹੋਵੇਗੀ। ਅਸੀਂ ਡਰਾਈਵਰ ਅਤੇ ਯਾਤਰੀ ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿੱਚ HTTPS ਟ੍ਰੈਫਿਕ ਲਈ 10-30% ਦੀ ਰੇਂਜ ਵਿੱਚ ਕਮੀ ਵੇਖੀ ਹੈ। QUIC ਨੇ ਸਾਨੂੰ ਉਪਭੋਗਤਾ ਪੈਕੇਜਾਂ 'ਤੇ ਅੰਤ ਤੋਂ ਅੰਤ ਤੱਕ ਨਿਯੰਤਰਣ ਵੀ ਦਿੱਤਾ ਹੈ।

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

ਨਵੀਨਤਮ ਤਕਨਾਲੋਜੀ: TCP

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

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

ਚਿੱਤਰ 1: ਉਬੇਰ ਦੇ ਮੁੱਖ ਸ਼ਹਿਰਾਂ ਵਿੱਚ ਟੇਲ ਲੇਟੈਂਸੀ ਵੱਖਰੀ ਹੁੰਦੀ ਹੈ।

ਹਾਲਾਂਕਿ ਭਾਰਤੀ ਅਤੇ ਬ੍ਰਾਜ਼ੀਲੀਅਨ ਨੈੱਟਵਰਕਾਂ ਵਿੱਚ ਲੇਟੈਂਸੀ ਯੂ.ਐੱਸ. ਅਤੇ ਯੂ.ਕੇ. ਦੇ ਮੁਕਾਬਲੇ ਜ਼ਿਆਦਾ ਸੀ, ਟੇਲ ਲੇਟੈਂਸੀ ਔਸਤ ਲੇਟੈਂਸੀ ਨਾਲੋਂ ਕਾਫ਼ੀ ਜ਼ਿਆਦਾ ਹੈ। ਅਤੇ ਇਹ ਅਮਰੀਕਾ ਅਤੇ ਯੂਕੇ ਲਈ ਵੀ ਸੱਚ ਹੈ।

ਹਵਾ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ 'ਤੇ ਟੀ.ਸੀ.ਪੀ

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

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

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

ਚਿੱਤਰ 2. ਉਦਾਹਰਨ ਵਜੋਂ 2 ਕਿਲੋਮੀਟਰ ਦੇ ਘੇਰੇ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਦੇਰੀ। ਦਿੱਲੀ, ਭਾਰਤ।

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

ਚਿੱਤਰ 3. ਟੇਲ ਦੇਰੀ ਦਿਨਾਂ ਦੇ ਵਿਚਕਾਰ ਮਹੱਤਵਪੂਰਨ ਤੌਰ 'ਤੇ ਬਦਲ ਸਕਦੀ ਹੈ, ਪਰ ਇੱਕੋ ਓਪਰੇਟਰ ਲਈ।

ਉੱਪਰ ਦਿੱਤੇ ਸਾਰੇ ਕਾਰਨ ਵਾਇਰਲੈੱਸ ਨੈੱਟਵਰਕਾਂ ਵਿੱਚ TCP ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਬੇਅਸਰ ਹੋ ਜਾਂਦੀ ਹੈ। ਹਾਲਾਂਕਿ, TCP ਦੇ ਵਿਕਲਪਾਂ ਦੀ ਭਾਲ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਅਸੀਂ ਹੇਠਾਂ ਦਿੱਤੇ ਨੁਕਤਿਆਂ 'ਤੇ ਇੱਕ ਸਟੀਕ ਸਮਝ ਵਿਕਸਿਤ ਕਰਨਾ ਚਾਹੁੰਦੇ ਸੀ:

• ਕੀ ਸਾਡੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿੱਚ ਟੇਲ ਲੇਟੈਂਸੀ ਦੇ ਪਿੱਛੇ TCP ਮੁੱਖ ਦੋਸ਼ੀ ਹੈ?
• ਕੀ ਆਧੁਨਿਕ ਨੈੱਟਵਰਕਾਂ ਵਿੱਚ ਮਹੱਤਵਪੂਰਨ ਅਤੇ ਵਿਭਿੰਨ ਰਾਉਂਡ-ਟ੍ਰਿਪ ਦੇਰੀ (RTT) ਹਨ?
• TCP ਪ੍ਰਦਰਸ਼ਨ 'ਤੇ RTT ਅਤੇ ਨੁਕਸਾਨ ਦਾ ਕੀ ਪ੍ਰਭਾਵ ਹੈ?

TCP ਪ੍ਰਦਰਸ਼ਨ ਵਿਸ਼ਲੇਸ਼ਣ

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

ਜੇਕਰ ਇੱਕ ਪੈਕੇਟ ਜਾਂ ACK ਗੁੰਮ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਭੇਜਣ ਵਾਲਾ ਸਮਾਂ ਸਮਾਪਤ ਹੋਣ ਤੋਂ ਬਾਅਦ ਮੁੜ ਪ੍ਰਸਾਰਿਤ ਕਰਦਾ ਹੈ (RTO, ਮੁੜ ਪ੍ਰਸਾਰਣ ਦਾ ਸਮਾਂ ਸਮਾਪਤ). RTO ਦੀ ਗਣਨਾ ਵੱਖ-ਵੱਖ ਕਾਰਕਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਜਿਵੇਂ ਕਿ ਭੇਜਣ ਵਾਲੇ ਅਤੇ ਪ੍ਰਾਪਤਕਰਤਾ ਵਿਚਕਾਰ ਸੰਭਾਵਿਤ RTT ਦੇਰੀ।

ਚਿੱਤਰ 4. TCP/TLS ਉੱਤੇ ਪੈਕੇਟ ਐਕਸਚੇਂਜ ਵਿੱਚ ਇੱਕ ਰੀਟ੍ਰਾਂਸਮਿਸ਼ਨ ਵਿਧੀ ਸ਼ਾਮਲ ਹੁੰਦੀ ਹੈ।

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

ਦੋਵਾਂ ਪ੍ਰਯੋਗਾਂ ਦੇ ਨਤੀਜੇ ਇਕ ਦੂਜੇ ਦੇ ਨਾਲ ਇਕਸਾਰ ਸਨ। ਅਸੀਂ ਉੱਚ RTT ਲੇਟੈਂਸੀ ਦੇਖੀ; ਪੂਛ ਦੇ ਮੁੱਲ ਮੱਧਮ ਮੁੱਲ ਨਾਲੋਂ ਲਗਭਗ 6 ਗੁਣਾ ਵੱਧ ਸਨ; ਦੇਰੀ ਦੀ ਗਣਿਤ ਔਸਤ 1 ਸਕਿੰਟ ਤੋਂ ਵੱਧ ਹੈ। ਬਹੁਤ ਸਾਰੇ ਕਨੈਕਸ਼ਨ ਨੁਕਸਾਨੇ ਗਏ ਸਨ, ਜਿਸ ਕਾਰਨ TCP ਨੇ ਸਾਰੇ ਪੈਕੇਟਾਂ ਦੇ 3,5% ਨੂੰ ਮੁੜ ਪ੍ਰਸਾਰਿਤ ਕੀਤਾ। ਭੀੜ-ਭੜੱਕੇ ਵਾਲੇ ਖੇਤਰਾਂ ਜਿਵੇਂ ਕਿ ਹਵਾਈ ਅੱਡਿਆਂ ਅਤੇ ਰੇਲਵੇ ਸਟੇਸ਼ਨਾਂ ਵਿੱਚ, ਅਸੀਂ 7% ਨੁਕਸਾਨ ਦੇਖਿਆ। ਇਹਨਾਂ ਨਤੀਜਿਆਂ ਨੇ ਪਰੰਪਰਾਗਤ ਬੁੱਧੀ 'ਤੇ ਸ਼ੱਕ ਪੈਦਾ ਕੀਤਾ ਹੈ ਜੋ ਸੈਲੂਲਰ ਨੈਟਵਰਕਾਂ ਵਿੱਚ ਵਰਤੇ ਜਾਂਦੇ ਹਨ ਐਡਵਾਂਸਡ ਰੀਟ੍ਰਾਂਸਮਿਸ਼ਨ ਸਰਕਟ ਟਰਾਂਸਪੋਰਟ ਪੱਧਰ 'ਤੇ ਘਾਟੇ ਨੂੰ ਕਾਫ਼ੀ ਘੱਟ ਕਰਦਾ ਹੈ। ਹੇਠਾਂ "ਸਿਮੂਲੇਟਰ" ਐਪਲੀਕੇਸ਼ਨ ਤੋਂ ਟੈਸਟ ਦੇ ਨਤੀਜੇ ਹਨ:

ਨੈੱਟਵਰਕ ਮੈਟ੍ਰਿਕਸ
ਮੁੱਲ

RTT, ਮਿਲੀਸਕਿੰਟ [50%,75%, 95%,99%]
[350, 425, 725, 2300]

RTT ਵਿਭਿੰਨਤਾ, ਸਕਿੰਟ
ਔਸਤਨ ~1,2 ਸਕਿੰਟ

ਅਸਥਿਰ ਕਨੈਕਸ਼ਨਾਂ 'ਤੇ ਪੈਕੇਟ ਦਾ ਨੁਕਸਾਨ
ਔਸਤ ~3.5% (7% ਓਵਰਲੋਡ ਖੇਤਰਾਂ ਵਿੱਚ)

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

ਡਾਟਾ ਪੈਕੇਟਾਂ ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਉੱਚ ਆਰਟੀਓ ਮੁੱਲ ਵਾਇਰਲੈੱਸ ਨੈਟਵਰਕਾਂ ਵਿੱਚ ਅਸਥਾਈ ਨੁਕਸਾਨਾਂ ਦੀ ਮੌਜੂਦਗੀ ਵਿੱਚ ਨੈਟਵਰਕ ਦੀ ਉਪਯੋਗੀ ਉਪਯੋਗਤਾ ਨੂੰ ਬਹੁਤ ਘੱਟ ਕਰਦੇ ਹਨ। ਅਸੀਂ ਪਾਇਆ ਕਿ ਔਸਤ ਰੀਟ੍ਰਾਂਸਮਿਸ਼ਨ ਸਮਾਂ ਲਗਭਗ 1 ਸਕਿੰਟਾਂ ਦੀ ਪੂਛ ਦੇਰੀ ਦੇ ਨਾਲ ਲਗਭਗ 30 ਸਕਿੰਟ ਹੈ। TCP ਪੱਧਰ 'ਤੇ ਇਹ ਉੱਚ ਲੇਟੈਂਸੀ HTTPS ਟਾਈਮਆਉਟ ਅਤੇ ਦੁਬਾਰਾ ਬੇਨਤੀਆਂ ਦਾ ਕਾਰਨ ਬਣਦੀ ਹੈ, ਜਿਸ ਨਾਲ ਨੈੱਟਵਰਕ ਲੇਟੈਂਸੀ ਅਤੇ ਅਕੁਸ਼ਲਤਾ ਵਧਦੀ ਹੈ।

ਜਦੋਂ ਕਿ ਮਾਪਿਆ ਗਿਆ RTT ਦਾ 75ਵਾਂ ਪਰਸੈਂਟਾਈਲ ਲਗਭਗ 425 ms ਸੀ, TCP ਲਈ 75ਵਾਂ ਪ੍ਰਤੀਸ਼ਤ ਲਗਭਗ 3 ਸਕਿੰਟ ਸੀ। ਇਹ ਸੰਕੇਤ ਦਿੰਦਾ ਹੈ ਕਿ ਨੁਕਸਾਨ ਦੇ ਕਾਰਨ TCP ਨੂੰ ਡੇਟਾ ਨੂੰ ਸਫਲਤਾਪੂਰਵਕ ਸੰਚਾਰਿਤ ਕਰਨ ਲਈ 7-10 ਪਾਸ ਕਰਨੇ ਪਏ। ਇਹ ਅਕੁਸ਼ਲ RTO ਗਣਨਾ ਦਾ ਨਤੀਜਾ ਹੋ ਸਕਦਾ ਹੈ, ਨੁਕਸਾਨ ਦਾ ਤੁਰੰਤ ਜਵਾਬ ਦੇਣ ਵਿੱਚ TCP ਦੀ ਅਸਮਰੱਥਾ ਨਵੀਨਤਮ ਪੈਕੇਜ ਵਿੰਡੋ ਵਿੱਚ ਅਤੇ ਭੀੜ ਨਿਯੰਤਰਣ ਐਲਗੋਰਿਦਮ ਦੀ ਅਕੁਸ਼ਲਤਾ, ਜੋ ਕਿ ਵਾਇਰਲੈੱਸ ਘਾਟੇ ਅਤੇ ਨੈਟਵਰਕ ਭੀੜ ਕਾਰਨ ਹੋਣ ਵਾਲੇ ਨੁਕਸਾਨਾਂ ਵਿੱਚ ਫਰਕ ਨਹੀਂ ਕਰਦਾ ਹੈ। ਹੇਠਾਂ TCP ਨੁਕਸਾਨ ਟੈਸਟਾਂ ਦੇ ਨਤੀਜੇ ਹਨ:

TCP ਪੈਕੇਟ ਨੁਕਸਾਨ ਦੇ ਅੰਕੜੇ
ਮੁੱਲ

ਘੱਟੋ-ਘੱਟ 1 ਪੈਕੇਟ ਦੇ ਨੁਕਸਾਨ ਦੇ ਨਾਲ ਕੁਨੈਕਸ਼ਨਾਂ ਦਾ ਪ੍ਰਤੀਸ਼ਤ
45%

ਕੁਨੈਕਸ਼ਨ ਸੈੱਟਅੱਪ ਦੌਰਾਨ ਨੁਕਸਾਨਾਂ ਵਾਲੇ ਕੁਨੈਕਸ਼ਨਾਂ ਦਾ ਪ੍ਰਤੀਸ਼ਤ
30%

ਡਾਟਾ ਐਕਸਚੇਂਜ ਦੇ ਦੌਰਾਨ ਨੁਕਸਾਨ ਦੇ ਨਾਲ ਕੁਨੈਕਸ਼ਨਾਂ ਦਾ ਪ੍ਰਤੀਸ਼ਤ
76%

ਰੀਟ੍ਰਾਂਸਮਿਸ਼ਨ ਵਿੱਚ ਦੇਰੀ ਦੀ ਵੰਡ, ਸਕਿੰਟ [50%, 75%, 95%,99%] [1, 2.8, 15, 28]

ਇੱਕ ਪੈਕੇਟ ਜਾਂ TCP ਹਿੱਸੇ ਲਈ ਮੁੜ ਪ੍ਰਸਾਰਣ ਦੀ ਸੰਖਿਆ ਦੀ ਵੰਡ
[1,3,6,7]

QUIC ਦੀ ਅਰਜ਼ੀ

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

ਚਿੱਤਰ 5: QUIC HTTP/3 ਦੇ ਅਧੀਨ ਚੱਲਦਾ ਹੈ, TLS ਦੀ ਥਾਂ ਲੈਂਦਾ ਹੈ, ਜੋ ਪਹਿਲਾਂ HTTP/2 ਅਧੀਨ ਚੱਲਦਾ ਸੀ।

ਹੇਠਾਂ ਉਹ ਕਾਰਨ ਹਨ ਜਿਨ੍ਹਾਂ ਨੇ ਸਾਨੂੰ TCP ਪ੍ਰਸਾਰਣ ਲਈ QUIC ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ ਯਕੀਨ ਦਿਵਾਇਆ:

• 0-RTT ਕਨੈਕਸ਼ਨ ਸਥਾਪਨਾ। QUIC ਸੁਰੱਖਿਆ ਹੈਂਡਸ਼ੇਕ ਦੀ ਗਿਣਤੀ ਨੂੰ ਘਟਾਉਂਦੇ ਹੋਏ, ਪਿਛਲੇ ਕਨੈਕਸ਼ਨਾਂ ਤੋਂ ਅਧਿਕਾਰਾਂ ਦੀ ਮੁੜ ਵਰਤੋਂ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ। ਭਵਿੱਖ ਵਿੱਚ TLS1.3 0-RTT ਦਾ ਸਮਰਥਨ ਕਰੇਗਾ, ਪਰ ਇੱਕ ਤਿੰਨ-ਪੱਖੀ TCP ਹੈਂਡਸ਼ੇਕ ਦੀ ਅਜੇ ਵੀ ਲੋੜ ਹੋਵੇਗੀ।
• HoL ਬਲਾਕਿੰਗ 'ਤੇ ਕਾਬੂ ਪਾਉਣਾ। HTTP/2 ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਣ ਲਈ ਪ੍ਰਤੀ ਕਲਾਇੰਟ ਇੱਕ TCP ਕਨੈਕਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਪਰ ਇਸ ਨਾਲ HoL (ਹੈੱਡ-ਆਫ-ਲਾਈਨ) ਬਲਾਕਿੰਗ ਹੋ ਸਕਦੀ ਹੈ। QUIC ਮਲਟੀਪਲੈਕਸਿੰਗ ਨੂੰ ਸਰਲ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ ਬੇਨਤੀਆਂ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।
• ਭੀੜ ਕੰਟਰੋਲ. QUIC ਐਪਲੀਕੇਸ਼ਨ ਲੇਅਰ 'ਤੇ ਰਹਿੰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਮੁੱਖ ਟਰਾਂਸਪੋਰਟ ਐਲਗੋਰਿਦਮ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨਾ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ ਜੋ ਨੈੱਟਵਰਕ ਪੈਰਾਮੀਟਰਾਂ (ਨੁਕਸਾਨ ਦੀ ਸੰਖਿਆ ਜਾਂ RTT) ਦੇ ਆਧਾਰ 'ਤੇ ਭੇਜਣ ਨੂੰ ਕੰਟਰੋਲ ਕਰਦਾ ਹੈ। ਜ਼ਿਆਦਾਤਰ TCP ਲਾਗੂਕਰਨ ਐਲਗੋਰਿਦਮ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ ਘਣ, ਜੋ ਕਿ ਲੇਟੈਂਸੀ-ਸੰਵੇਦਨਸ਼ੀਲ ਟ੍ਰੈਫਿਕ ਲਈ ਅਨੁਕੂਲ ਨਹੀਂ ਹੈ। ਹਾਲ ਹੀ ਵਿੱਚ ਵਿਕਸਤ ਐਲਗੋਰਿਦਮ ਵਰਗੇ ਬੀਬੀਆਰ, ਵਧੇਰੇ ਸਹੀ ਢੰਗ ਨਾਲ ਨੈੱਟਵਰਕ ਦਾ ਮਾਡਲ ਬਣਾਓ ਅਤੇ ਲੇਟੈਂਸੀ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਓ। QUIC ਤੁਹਾਨੂੰ BBR ਦੀ ਵਰਤੋਂ ਕਰਨ ਅਤੇ ਇਸ ਐਲਗੋਰਿਦਮ ਨੂੰ ਅਪਡੇਟ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਜਿਵੇਂ ਕਿ ਇਹ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। ਸੁਧਾਰ.
• ਨੁਕਸਾਨ ਦੀ ਭਰਪਾਈ. QUIC ਦੋ TLP ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ (ਪੂਛ ਦੇ ਨੁਕਸਾਨ ਦੀ ਜਾਂਚRTO ਦੇ ਚਾਲੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ - ਭਾਵੇਂ ਨੁਕਸਾਨ ਬਹੁਤ ਧਿਆਨ ਦੇਣ ਯੋਗ ਹੋਵੇ। ਇਹ TCP ਲਾਗੂਕਰਨ ਤੋਂ ਵੱਖਰਾ ਹੈ। TLP ਤੇਜ਼ੀ ਨਾਲ ਮੁੜ ਭਰਨ ਲਈ ਮੁੱਖ ਤੌਰ 'ਤੇ ਆਖਰੀ ਪੈਕੇਟ (ਜਾਂ ਨਵਾਂ, ਜੇਕਰ ਕੋਈ ਹੈ) ਨੂੰ ਮੁੜ ਪ੍ਰਸਾਰਿਤ ਕਰਦਾ ਹੈ। ਟੇਲ ਦੇਰੀ ਨਾਲ ਨਜਿੱਠਣਾ ਖਾਸ ਤੌਰ 'ਤੇ ਉਬੇਰ ਦੁਆਰਾ ਆਪਣੇ ਨੈੱਟਵਰਕ ਨੂੰ ਚਲਾਉਣ ਦੇ ਤਰੀਕੇ ਲਈ ਲਾਭਦਾਇਕ ਹੈ, ਅਰਥਾਤ ਛੋਟੇ, ਛਿੱਟੇ, ਅਤੇ ਲੇਟੈਂਸੀ-ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਟ੍ਰਾਂਸਫਰ ਲਈ।
• ਅਨੁਕੂਲਿਤ ACK. ਕਿਉਂਕਿ ਹਰੇਕ ਪੈਕੇਟ ਦਾ ਇੱਕ ਵਿਲੱਖਣ ਕ੍ਰਮ ਨੰਬਰ ਹੁੰਦਾ ਹੈ, ਕੋਈ ਸਮੱਸਿਆ ਨਹੀਂ ਹੈ ਭਿੰਨਤਾਵਾਂ ਪੈਕੇਟ ਜਦੋਂ ਉਹਨਾਂ ਨੂੰ ਮੁੜ ਪ੍ਰਸਾਰਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ACK ਪੈਕੇਟਾਂ ਵਿੱਚ ਪੈਕੇਟ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਨ ਅਤੇ ਕਲਾਇੰਟ ਸਾਈਡ 'ਤੇ ACK ਬਣਾਉਣ ਲਈ ਸਮਾਂ ਵੀ ਹੁੰਦਾ ਹੈ। ਇਹ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਯਕੀਨੀ ਬਣਾਉਂਦੀਆਂ ਹਨ ਕਿ QUIC RTT ਦੀ ਗਣਨਾ ਵਧੇਰੇ ਸਟੀਕਤਾ ਨਾਲ ਕਰਦਾ ਹੈ। QUIC ਵਿੱਚ ACK 256 ਬੈਂਡ ਤੱਕ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ NACK, ਭੇਜਣ ਵਾਲੇ ਨੂੰ ਪੈਕੇਟ ਸ਼ਫਲਿੰਗ ਲਈ ਵਧੇਰੇ ਲਚਕੀਲਾ ਬਣਨ ਅਤੇ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਘੱਟ ਬਾਈਟਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਨਾ। ਚੋਣਵੇਂ ACK (SACKTCP ਵਿੱਚ ) ਸਾਰੇ ਮਾਮਲਿਆਂ ਵਿੱਚ ਇਸ ਸਮੱਸਿਆ ਦਾ ਹੱਲ ਨਹੀਂ ਕਰਦਾ ਹੈ।
• ਕੁਨੈਕਸ਼ਨ ਮਾਈਗਰੇਸ਼ਨ. QUIC ਕਨੈਕਸ਼ਨਾਂ ਦੀ ਪਛਾਣ 64-ਬਿੱਟ ID ਦੁਆਰਾ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਇਸਲਈ ਜੇਕਰ ਕੋਈ ਕਲਾਇੰਟ IP ਐਡਰੈੱਸ ਬਦਲਦਾ ਹੈ, ਤਾਂ ਪੁਰਾਣੇ ਕਨੈਕਸ਼ਨ ID ਨੂੰ ਬਿਨਾਂ ਕਿਸੇ ਰੁਕਾਵਟ ਦੇ ਨਵੇਂ IP ਐਡਰੈੱਸ 'ਤੇ ਵਰਤਿਆ ਜਾਣਾ ਜਾਰੀ ਰੱਖਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਇਹ ਮੋਬਾਈਲ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਇੱਕ ਬਹੁਤ ਆਮ ਅਭਿਆਸ ਹੈ ਜਿੱਥੇ ਉਪਭੋਗਤਾ Wi-Fi ਅਤੇ ਸੈਲੂਲਰ ਕਨੈਕਸ਼ਨਾਂ ਵਿਚਕਾਰ ਸਵਿਚ ਕਰਦਾ ਹੈ।

QUIC ਦੇ ਵਿਕਲਪ

ਅਸੀਂ QUIC ਦੀ ਚੋਣ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਵਿਕਲਪਕ ਪਹੁੰਚਾਂ 'ਤੇ ਵਿਚਾਰ ਕੀਤਾ।

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

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

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

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

ਪਲੇਟਫਾਰਮ ਵਿੱਚ QUIC ਦਾ ਏਕੀਕਰਣ

QUIC ਨੂੰ ਸਫਲਤਾਪੂਰਵਕ ਏਮਬੇਡ ਕਰਨ ਅਤੇ ਮਾੜੇ ਕਨੈਕਟੀਵਿਟੀ ਵਾਤਾਵਰਨ ਵਿੱਚ ਐਪਲੀਕੇਸ਼ਨ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਣ ਲਈ, ਅਸੀਂ ਪੁਰਾਣੇ ਸਟੈਕ (HTTP/2 ਓਵਰ TLS/TCP) ਨੂੰ QUIC ਪ੍ਰੋਟੋਕੋਲ ਨਾਲ ਬਦਲ ਦਿੱਤਾ ਹੈ। ਅਸੀਂ ਨੈੱਟਵਰਕ ਲਾਇਬ੍ਰੇਰੀ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਹੈ ਕਰੋਨੇਟ ਤੱਕ Chromium ਪ੍ਰੋਜੈਕਟਸ, ਜਿਸ ਵਿੱਚ ਪ੍ਰੋਟੋਕੋਲ ਦਾ ਅਸਲੀ, Google ਸੰਸਕਰਣ ਸ਼ਾਮਲ ਹੈ - gQUIC। ਨਵੀਨਤਮ IETF ਨਿਰਧਾਰਨ ਦੀ ਪਾਲਣਾ ਕਰਨ ਲਈ ਇਸ ਲਾਗੂਕਰਨ ਨੂੰ ਲਗਾਤਾਰ ਸੁਧਾਰਿਆ ਜਾ ਰਿਹਾ ਹੈ।

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

ਐਂਡਰੌਇਡ ਡਿਵਾਈਸਾਂ ਲਈ ਪਹੁੰਚ ਦੇ ਸਮਾਨ, ਅਸੀਂ ਨੈੱਟਵਰਕ ਤੋਂ HTTP ਟ੍ਰੈਫਿਕ ਨੂੰ ਰੋਕਦੇ ਹੋਏ, iOS 'ਤੇ Uber ਐਪਸ ਵਿੱਚ Cronet ਨੂੰ ਲਾਗੂ ਕੀਤਾ ਹੈ। APIਵਰਤਦੇ ਹੋਏ NSURLਪ੍ਰੋਟੋਕਾਲ. ਆਈਓਐਸ ਫਾਊਂਡੇਸ਼ਨ ਦੁਆਰਾ ਪ੍ਰਦਾਨ ਕੀਤਾ ਗਿਆ ਇਹ ਐਬਸਟਰੈਕਸ਼ਨ, ਪ੍ਰੋਟੋਕੋਲ-ਵਿਸ਼ੇਸ਼ URL ਡੇਟਾ ਨੂੰ ਹੈਂਡਲ ਕਰਦਾ ਹੈ ਅਤੇ ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਅਸੀਂ ਮਹੱਤਵਪੂਰਨ ਮਾਈਗ੍ਰੇਸ਼ਨ ਲਾਗਤਾਂ ਤੋਂ ਬਿਨਾਂ ਸਾਡੇ iOS ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿੱਚ ਕਰੋਨੇਟ ਨੂੰ ਏਕੀਕ੍ਰਿਤ ਕਰ ਸਕਦੇ ਹਾਂ।

Google ਕਲਾਊਡ ਬੈਲੇਂਸਰਾਂ 'ਤੇ QUIC ਨੂੰ ਪੂਰਾ ਕਰਨਾ

ਬੈਕਐਂਡ ਵਾਲੇ ਪਾਸੇ, QUIC ਸੰਪੂਰਨਤਾ ਗੂਗਲ ਕਲਾਉਡ ਲੋਡ ਬੈਲੇਂਸਿੰਗ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੁਆਰਾ ਪ੍ਰਦਾਨ ਕੀਤੀ ਗਈ ਹੈ, ਜੋ ਕਿ alt-svc QUIC ਦੇ ਸਮਰਥਨ ਲਈ ਜਵਾਬਾਂ ਵਿੱਚ ਸਿਰਲੇਖ। ਆਮ ਤੌਰ 'ਤੇ, ਬੈਲੇਂਸਰ ਹਰੇਕ HTTP ਬੇਨਤੀ ਲਈ ਇੱਕ alt-svc ਸਿਰਲੇਖ ਜੋੜਦਾ ਹੈ, ਅਤੇ ਇਹ ਪਹਿਲਾਂ ਹੀ ਡੋਮੇਨ ਲਈ QUIC ਸਮਰਥਨ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਇੱਕ ਕਰੋਨੇਟ ਕਲਾਇੰਟ ਨੂੰ ਇਸ ਸਿਰਲੇਖ ਨਾਲ ਇੱਕ HTTP ਜਵਾਬ ਪ੍ਰਾਪਤ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਇਹ ਉਸ ਡੋਮੇਨ ਲਈ ਅਗਲੀਆਂ HTTP ਬੇਨਤੀਆਂ ਲਈ QUIC ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਇੱਕ ਵਾਰ ਬੈਲੇਂਸਰ QUIC ਨੂੰ ਪੂਰਾ ਕਰਦਾ ਹੈ, ਸਾਡਾ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਇਸ ਕਾਰਵਾਈ ਨੂੰ HTTP2/TCP 'ਤੇ ਸਾਡੇ ਡੇਟਾ ਸੈਂਟਰਾਂ ਨੂੰ ਭੇਜਦਾ ਹੈ।

ਪ੍ਰਦਰਸ਼ਨ: ਨਤੀਜੇ

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

ਪ੍ਰਯੋਗ 1

ਪ੍ਰਯੋਗ ਲਈ ਉਪਕਰਣ:

• ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਕਿ ਅਸੀਂ ਕ੍ਰਮਵਾਰ TCP ਅਤੇ QUIC ਉੱਤੇ HTTPS ਟ੍ਰੈਫਿਕ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਾਂ, OkHttp ਅਤੇ Cronet ਸਟੈਕ ਨਾਲ ਐਂਡਰੌਇਡ ਡਿਵਾਈਸਾਂ ਦੀ ਜਾਂਚ ਕਰੋ;
• ਇੱਕ ਜਾਵਾ-ਅਧਾਰਿਤ ਇਮੂਲੇਸ਼ਨ ਸਰਵਰ ਜੋ ਜਵਾਬਾਂ ਵਿੱਚ ਇੱਕੋ ਕਿਸਮ ਦੇ HTTPS ਸਿਰਲੇਖ ਭੇਜਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਤੋਂ ਬੇਨਤੀਆਂ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਕਲਾਇੰਟ ਡਿਵਾਈਸਾਂ ਨੂੰ ਲੋਡ ਕਰਦਾ ਹੈ;
• ਕਲਾਉਡ ਪ੍ਰੌਕਸੀਜ਼ ਜੋ ਕਿ TCP ਅਤੇ QUIC ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਖਤਮ ਕਰਨ ਲਈ ਸਰੀਰਕ ਤੌਰ 'ਤੇ ਭਾਰਤ ਦੇ ਨੇੜੇ ਸਥਿਤ ਹਨ। ਜਦੋਂ ਕਿ TCP ਸਮਾਪਤੀ ਲਈ ਅਸੀਂ ਇੱਕ ਰਿਵਰਸ ਪ੍ਰੌਕਸੀ ਚਾਲੂ ਕੀਤੀ ਹੈ NGINX, QUIC ਲਈ ਇੱਕ ਓਪਨ ਸੋਰਸ ਰਿਵਰਸ ਪ੍ਰੌਕਸੀ ਲੱਭਣਾ ਮੁਸ਼ਕਲ ਸੀ। ਅਸੀਂ ਕ੍ਰੋਮੀਅਮ ਅਤੇ ਪ੍ਰਕਾਸ਼ਤ ਇਸਨੂੰ ਕ੍ਰੋਮੀਅਮ ਵਿੱਚ ਓਪਨ ਸੋਰਸ ਦੇ ਰੂਪ ਵਿੱਚ।

ਚਿੱਤਰ 6. TCP ਬਨਾਮ QUIC ਰੋਡ ਟੈਸਟ ਸੂਟ ਵਿੱਚ OkHttp ਅਤੇ Cronet ਨਾਲ Android ਡਿਵਾਈਸਾਂ, ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਖਤਮ ਕਰਨ ਲਈ ਕਲਾਉਡ ਪ੍ਰੌਕਸੀ, ਅਤੇ ਇੱਕ ਇਮੂਲੇਸ਼ਨ ਸਰਵਰ ਸ਼ਾਮਲ ਹਨ।

ਪ੍ਰਯੋਗ 2

ਜਦੋਂ Google ਨੇ QUIC ਨਾਲ ਉਪਲਬਧ ਕਰਵਾਇਆ ਗੂਗਲ ਕਲਾਉਡ ਲੋਡ ਸੰਤੁਲਨ, ਅਸੀਂ ਇੱਕੋ ਵਸਤੂ ਸੂਚੀ ਦੀ ਵਰਤੋਂ ਕੀਤੀ, ਪਰ ਇੱਕ ਸੋਧ ਦੇ ਨਾਲ: NGINX ਦੀ ਬਜਾਏ, ਅਸੀਂ ਡਿਵਾਈਸਾਂ ਤੋਂ TCP ਅਤੇ QUIC ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਖਤਮ ਕਰਨ ਲਈ, ਨਾਲ ਹੀ HTTPS ਟ੍ਰੈਫਿਕ ਨੂੰ ਇਮੂਲੇਸ਼ਨ ਸਰਵਰ ਤੱਕ ਰੂਟ ਕਰਨ ਲਈ Google ਲੋਡ ਬੈਲੈਂਸਰ ਲਏ। ਬੈਲੇਂਸਰਾਂ ਨੂੰ ਪੂਰੀ ਦੁਨੀਆ ਵਿੱਚ ਵੰਡਿਆ ਜਾਂਦਾ ਹੈ, ਪਰ ਡਿਵਾਈਸ ਦੇ ਸਭ ਤੋਂ ਨੇੜੇ ਦੇ PoP ਸਰਵਰ ਦੀ ਵਰਤੋਂ ਕਰੋ (ਭੂ-ਸਥਾਨ ਲਈ ਧੰਨਵਾਦ)।

ਚਿੱਤਰ 7. ਦੂਜੇ ਪ੍ਰਯੋਗ ਵਿੱਚ, ਅਸੀਂ TCP ਅਤੇ QUIC ਦੀ ਪੂਰਤੀ ਲੇਟੈਂਸੀ ਦੀ ਤੁਲਨਾ ਕਰਨਾ ਚਾਹੁੰਦੇ ਸੀ: ਗੂਗਲ ਕਲਾਉਡ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਅਤੇ ਸਾਡੇ ਕਲਾਉਡ ਪ੍ਰੌਕਸੀ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ।

ਨਤੀਜੇ ਵਜੋਂ, ਕਈ ਖੁਲਾਸੇ ਸਾਡੀ ਉਡੀਕ ਕਰ ਰਹੇ ਸਨ:

• PoP ਰਾਹੀਂ ਸਮਾਪਤੀ TCP ਕਾਰਗੁਜ਼ਾਰੀ ਵਿੱਚ ਸੁਧਾਰ ਕਰਦੀ ਹੈ। ਕਿਉਂਕਿ ਬੈਲੈਂਸਰ ਉਪਭੋਗਤਾਵਾਂ ਦੇ ਨੇੜੇ TCP ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਖਤਮ ਕਰਦੇ ਹਨ ਅਤੇ ਬਹੁਤ ਜ਼ਿਆਦਾ ਅਨੁਕੂਲਿਤ ਹੁੰਦੇ ਹਨ, ਇਸਦੇ ਨਤੀਜੇ ਵਜੋਂ ਘੱਟ RTTs ਹੁੰਦੇ ਹਨ, ਜੋ TCP ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਂਦਾ ਹੈ। ਅਤੇ ਹਾਲਾਂਕਿ QUIC ਘੱਟ ਪ੍ਰਭਾਵਿਤ ਹੋਇਆ ਸੀ, ਇਸਨੇ ਅਜੇ ਵੀ ਟੇਲ ਲੇਟੈਂਸੀ (10-30 ਪ੍ਰਤੀਸ਼ਤ ਦੁਆਰਾ) ਨੂੰ ਘਟਾਉਣ ਦੇ ਮਾਮਲੇ ਵਿੱਚ TCP ਨੂੰ ਪਛਾੜ ਦਿੱਤਾ ਹੈ।
• ਪੂਛਾਂ ਪ੍ਰਭਾਵਿਤ ਹੁੰਦੀਆਂ ਹਨ ਨੈੱਟਵਰਕ hops. ਹਾਲਾਂਕਿ ਸਾਡੀ QUIC ਪ੍ਰੌਕਸੀ ਗੂਗਲ ਦੇ ਲੋਡ ਬੈਲੇਂਸਰਾਂ ਨਾਲੋਂ ਡਿਵਾਈਸਾਂ (ਲਗਭਗ 50 ms ਵੱਧ ਲੇਟੈਂਸੀ) ਤੋਂ ਅੱਗੇ ਸੀ, ਇਸਨੇ ਸਮਾਨ ਪ੍ਰਦਰਸ਼ਨ ਪ੍ਰਦਾਨ ਕੀਤਾ - ਲੇਟੈਂਸੀ ਵਿੱਚ 15% ਕਮੀ ਬਨਾਮ TCP ਲਈ 20 ਵੇਂ ਪ੍ਰਤੀਸ਼ਤ ਵਿੱਚ 99% ਦੀ ਕਮੀ। ਇਹ ਸੁਝਾਅ ਦਿੰਦਾ ਹੈ ਕਿ ਆਖਰੀ ਮੀਲ ਦੀ ਤਬਦੀਲੀ ਨੈਟਵਰਕ ਵਿੱਚ ਇੱਕ ਰੁਕਾਵਟ ਹੈ.

ਚਿੱਤਰ 8: ਦੋ ਪ੍ਰਯੋਗਾਂ ਦੇ ਨਤੀਜੇ ਦਿਖਾਉਂਦੇ ਹਨ ਕਿ QUIC ਮਹੱਤਵਪੂਰਨ ਤੌਰ 'ਤੇ TCP ਨੂੰ ਪਛਾੜਦਾ ਹੈ।

ਲੜਾਈ ਟ੍ਰੈਫਿਕ

ਪ੍ਰਯੋਗ ਦੁਆਰਾ ਪ੍ਰੇਰਿਤ, ਅਸੀਂ ਆਪਣੇ ਐਂਡਰੌਇਡ ਅਤੇ iOS ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿੱਚ QUIC ਸਹਾਇਤਾ ਨੂੰ ਲਾਗੂ ਕੀਤਾ ਹੈ। ਅਸੀਂ ਉਹਨਾਂ ਸ਼ਹਿਰਾਂ ਵਿੱਚ QUIC ਦੇ ਪ੍ਰਭਾਵ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਨ ਲਈ A/B ਟੈਸਟਿੰਗ ਕੀਤੀ ਜਿੱਥੇ Uber ਕੰਮ ਕਰਦਾ ਹੈ। ਆਮ ਤੌਰ 'ਤੇ, ਅਸੀਂ ਦੋਵਾਂ ਖੇਤਰਾਂ, ਦੂਰਸੰਚਾਰ ਆਪਰੇਟਰਾਂ ਅਤੇ ਨੈੱਟਵਰਕ ਕਿਸਮ ਵਿੱਚ ਟੇਲ ਦੇਰੀ ਵਿੱਚ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਕਮੀ ਦੇਖੀ ਹੈ।

ਹੇਠਾਂ ਦਿੱਤੇ ਗ੍ਰਾਫ਼ ਮੈਕਰੋ-ਖੇਤਰ ਅਤੇ ਵੱਖ-ਵੱਖ ਨੈੱਟਵਰਕ ਕਿਸਮਾਂ - LTE, 95G, 99G ਦੁਆਰਾ ਟੇਲਾਂ (3 ਅਤੇ 2 ਪ੍ਰਤੀਸ਼ਤ) ਵਿੱਚ ਪ੍ਰਤੀਸ਼ਤ ਸੁਧਾਰ ਦਿਖਾਉਂਦੇ ਹਨ।

ਚਿੱਤਰ 9. ਲੜਾਈ ਦੇ ਟੈਸਟਾਂ ਵਿੱਚ, QUIC ਨੇ ਲੇਟੈਂਸੀ ਦੇ ਮਾਮਲੇ ਵਿੱਚ TCP ਨੂੰ ਪਛਾੜ ਦਿੱਤਾ।

ਸਿਰਫ ਅੱਗੇ

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

ਕਵਰੇਜ ਵਧਾਈ ਗਈ

ਅਸਲ ਟ੍ਰੈਫਿਕ 'ਤੇ ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਅਸੀਂ ਦੇਖਿਆ ਕਿ ਲਗਭਗ 80% ਸੈਸ਼ਨਾਂ ਨੇ ਸਫਲਤਾਪੂਰਵਕ QUIC ਦੀ ਵਰਤੋਂ ਕੀਤੀ всех ਬੇਨਤੀਆਂ, ਜਦੋਂ ਕਿ 15% ਸੈਸ਼ਨਾਂ ਨੇ QUIC ਅਤੇ TCP ਦੇ ਸੁਮੇਲ ਦੀ ਵਰਤੋਂ ਕੀਤੀ। ਅਸੀਂ ਇਹ ਮੰਨਦੇ ਹਾਂ ਕਿ ਇਹ ਸੁਮੇਲ ਕ੍ਰੋਨੇਟ ਲਾਇਬ੍ਰੇਰੀ ਦੇ TCP 'ਤੇ ਵਾਪਸ ਜਾਣ ਦੇ ਕਾਰਨ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਅਸਲ UDP ਅਸਫਲਤਾਵਾਂ ਅਤੇ ਮਾੜੀ ਨੈੱਟਵਰਕ ਸਥਿਤੀਆਂ ਵਿਚਕਾਰ ਫਰਕ ਨਹੀਂ ਕਰ ਸਕਦਾ ਹੈ। ਅਸੀਂ ਵਰਤਮਾਨ ਵਿੱਚ ਇਸ ਸਮੱਸਿਆ ਦਾ ਹੱਲ ਲੱਭ ਰਹੇ ਹਾਂ ਕਿਉਂਕਿ ਅਸੀਂ QUIC ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ ਕੰਮ ਕਰਦੇ ਹਾਂ।

QUIC ਓਪਟੀਮਾਈਜੇਸ਼ਨ

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

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

ਸਰੋਤ: www.habr.com