02 ਅਪ੍ਰੈ 2025·8 ਮਿੰਟ
Bob Kahn ਅਤੇ TCP/IP: ਐਪਸ ਨੂੰ ਚਲਾਉਣ ਵਾਲੀ ਅਦ੍ਰਿਸ਼੍ਯ ਪਰਤ
ਜਾਣੋ ਕਿ Bob Kahn ਨੇ TCP/IP ਨੂੰ ਕਿਵੇਂ ਰੂਪ ਦਿੱਤਾ, ਕਿਉਂ ਭਰੋਸੇਯੋਗ ਪੈਕੇਟ ਨੈੱਟਵਰਕਿੰਗ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਅਤੇ ਇਹ ਡਿਜ਼ਾਈਨ ਅਜੇ ਵੀ ਐਪਸ, APIs ਅਤੇ ਕਲਾਉਡ ਸਰਵਿਸਜ਼ ਨੂੰ ਕਿਵੇਂ ਸਹਾਰਦਾ ਹੈ।
ਜਾਣੋ ਕਿ Bob Kahn ਨੇ TCP/IP ਨੂੰ ਕਿਵੇਂ ਰੂਪ ਦਿੱਤਾ, ਕਿਉਂ ਭਰੋਸੇਯੋਗ ਪੈਕੇਟ ਨੈੱਟਵਰਕਿੰਗ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਅਤੇ ਇਹ ਡਿਜ਼ਾਈਨ ਅਜੇ ਵੀ ਐਪਸ, APIs ਅਤੇ ਕਲਾਉਡ ਸਰਵਿਸਜ਼ ਨੂੰ ਕਿਵੇਂ ਸਹਾਰਦਾ ਹੈ।
ਜ਼ਿਆਦਾਤਰ ਐਪਸ “ਤੁਰੰਤ” ਮਹਿਸੂਸ ਹੁੰਦੇ ਹਨ: ਤੁਸੀਂ ਬਟਨ ਦਬਾਉਂਦੇ ਹੋ, ਫੀਡ ਰੀਫ੍ਰੈਸ਼ ਹੁੰਦੀ ਹੈ, ਭੁਗਤਾਨ ਹੋ ਜਾਂਦਾ ਹੈ, ਵੀਡੀਓ ਸ਼ੁਰੂ ਹੋ ਜਾਂਦੀ ਹੈ। ਜੋ ਤੁਹਾਨੂੰ ਨਹੀਂ ਦਿਖਾਈ ਦਿੰਦਾ ਉਹ ਹੈ ਛੋਟੀ-ਛੋਟੀ ਡੇਟਾ ਦੀਆਂ ਕੜੀਆਂ Wi‑Fi, ਸੈੱਲੂਲਰ ਨੈੱਟਵਰਕਾਂ, ਘਰੇਲੂ ਰਾਊਟਰਾਂ ਅਤੇ ਡੇਟਾ ਸੈਂਟਰਾਂ ਰਾਹੀਂ ਲੰਘਦੀਆਂ—ਕਈ ਵਾਰੀ ਵੱਖ-ਵੱਖ ਦੇਸ਼ਾਂ ਵਿੱਚ—ਬਿਨਾ ਤੁਸੀਂ ਵਿਚਕਾਰ ਦੀ ਗੰਦੀ ਚੀਜ਼ਾਂ ਬਾਰੇ ਸੋਚੇ।
ਇਹ ਗੁਪਤਤਾ ਉਹੀ ਵਾਅਦਾ ਹੈ ਜੋ TCP/IP ਪੂਰਾ ਕਰਦਾ ਹੈ। ਇਹ ਕੋਈ ਇੱਕ ਉਤਪਾਦ ਜਾਂ ਕਲਾਉਡ ਫੀਚਰ ਨਹੀਂ; ਇਹ ਨਿਯਮਾਂ ਦਾ ਇੱਕ ਸਮੂਹ ਹੈ ਜੋ ਡਿਵਾਈਸਾਂ ਅਤੇ ਸਰਵਰਾਂ ਨੂੰ ਇਕੱਠੇ ਗੱਲ ਕਰਨ ਦਿੰਦਾ ਹੈ ਇਸ ਤਰੀਕੇ ਨਾਲ ਕਿ ਅਕਸਰ ਇਹ ਫ਼ਲਿਕ ਅਤੇ ਭਰੋਸੇਯੋਗ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ, ਭਾਵੇਂ ਨੈੱਟਵਰਕ ਸ਼ੋਰ ਵਾਲਾ, ਭੀੜ-ਭਰਿਆ ਜਾਂ ਅੰਸ਼ਕ ਤੌਰ 'ਤੇ ਫੇਲ ਹੁੰਦਾ ਹੋਵੇ।
Bob Kahn ਉਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਵਿਅਕਤੀ ਸੀ ਜਿਨ੍ਹਾਂ ਨੇ ਇਹ ਸਾਦਗੀ ਸੰਭਵ ਬਣਾਈ। Vint Cerf ਵਰਗੇ ਸਹਿਯੋਗੀਆਂ ਨਾਲ, Kahn ਨੇ ਉਹ ਆਈਡਿਆਜ਼ ਰੂਪ ਦਿੱਤੇ ਜੋ TCP/IP ਬਣੇ: ਨੈੱਟਵਰਕਾਂ ਲਈ ਇੱਕ ਸਾਂਝੀ “ਭਾਸ਼ਾ” ਅਤੇ ਡੇਟਾ ਅਜਿਹੇ ਤਰੀਕੇ ਨਾਲ ਪਹੁੰਚਾਉਣ ਦੀ ਵਿਧੀ ਜੋ ਐਪਲੀਕੇਸ਼ਨ ਭਰੋਸਾ ਕਰ ਸਕਣ। ਕੋਈ ਸ਼ੋਰ ਨਹੀਂ—ਇਹ ਕੰਮ ਇਸ ਲਈ ਮਹੱਤਵਪੂਰਨ ਸੀ ਕਿਉਂਕਿ ਇਸਨੇ ਅਣਭਰੋਸੇਯੋਗ ਕੰਨੇਕਸ਼ਨਾਂ ਨੂੰ ਅਜਿਹਾ ਬਣਾ ਦਿੱਤਾ ਕਿ ਸਾਫਟਵੇਅਰ ਇਸ 'ਤੇ ਭਰੋਸਾ ਕਰ ਸਕੇ।
ਇੱਕ ਲਗਾਤਾਰ ਸੁਨੇਹੇ ਨੂੰ ਇੱਕ ਹੀ ਸਟ੍ਰੀਮ ਵਾਂਗ ਨਹੀਂ ਭੇਜਣ ਦੀ ਬਜਾਏ, ਪੈਕੇਟ ਨੈੱਟਵਰਕਿੰਗ ਇਸਨੂੰ ਛੋਟੇ ਹਿੱਸਿਆਂ — ਪੈਕੇਟਾਂ — ਵਿੱਚ ਤੋੜ ਦਿੰਦੀ ਹੈ। ਹਰ ਪੈਕੇਟ ਆਪਣਾ ਰਸਤਾ ਲੈ ਸਕਦਾ ਹੈ ਮੰਜ਼ਿਲ ਤੱਕ, ਇਕੱਠੇ ਖਤਾਂ ਵਾਂਗ ਜਿਹੜੇ ਅਲੱਗ-ਅਲੱਗ ਡਾਕ ਘਰ ਰਾਹੀਂ ਜਾਂਦੇ ਹਨ।
ਅਸੀਂ ਵੇਖਾਂਗੇ ਕਿ TCP ਕਿਵੇਂ ਭਰੋਸੇ ਦੀ ਭਾਵਨਾ ਬਣਾਉਂਦਾ ਹੈ, ਕਿਉਂ IP ਜਾਣ-ਬੂਝ ਕੇ ਪੂਰਨ ਗਰੰਟੀ ਨਹੀਂ ਦਿੰਦਾ, ਅਤੇ ਕਿਵੇਂ ਲੇਅਰਿੰਗ ਸਿਸਟਮ ਨੂੰ ਸਮਝਣਯੋਗ ਰੱਖਦੀ ਹੈ। ਆਖਿਰ ਵਿੱਚ, ਤੁਸੀਂ ਇੱਕ API ਕਾਲ ਹੋਣ ਵੇਲੇ ਕੀ ਹੋ ਰਿਹਾ ਹੈ ਦੀ ਤਸਵੀਰ ਦੇਖ ਸਕੋਗੇ—ਅਤੇ ਕਿਉਂ ਇਹ ਦਹਾਕਿਆਂ ਪੁਰਾਣੀਆਂ ਵਿਚਾਰਧਾਰਾਵਾਂ ਅਜੇ ਵੀ ਆਧੁਨਿਕ ਕਲਾਉਡ ਸਰਵਿਸਜ਼ ਨੂੰ ਚਲਾਉਂਦੀਆਂ ਹਨ।
ਸ਼ੁਰੂਆਤੀ ਕੰਪਿਊਟਰ ਨੈੱਟਵਰਕ "ਇੰਟਰਨੈੱਟ" ਵਜੋਂ ਪੈਦਾ ਨਹੀਂ ਹੋਏ। ਉਹ ਕਿਸੇ ਵਿਸ਼ੇਸ਼ ਸਮੂਹ ਲਈ ਬਣਾਏ ਗਏ ਸਨ: ਇੱਥੇ ਇੱਕ ਯੂਨੀਵਰਸਿਟੀ ਨੈੱਟਵਰਕ, ਉੱਥੇ ਮਿਲਟਰੀ ਨੈੱਟਵਰਕ, ਕਿਸੇ ਹੋਰ ਥਾਂ ਰਿਸਰਚ ਲੈਬ ਦਾ ਨੈੱਟਵਰਕ। ਹਰ ਇੱਕ ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ ਠੀਕ ਕੰਮ ਕਰ ਸਕਦਾ ਸੀ, ਪਰ ਅਕਸਰ ਉਹ ਵੱਖ-ਵੱਖ ਹਾਰਡਵੇਅਰ, ਸੁਨੇਹਾ ਫਾਰਮੈਟ ਅਤੇ ਡੇਟਾ ਦੇ ਯਾਤਰਾ ਨਿਯਮ ਵਰਤਦੇ ਸਨ।
ਇਸਦਾ ਨਤੀਜਾ ਇਹ ਸੀ ਕਿ ਦੋ ਕੰਪਿਊਟਰਨਾਂ ਦੇ "ਨੈੱਟਵਰਕ" ਵਾਲੇ ਹੋਣ ਦੇ ਬਾਵਜੂਦ ਵੀ ਉਹ ਇਕੱਠੇ ਜਾਣਕਾਰੀ ਨਹੀਂ ਸਾਂਝਾ ਕਰ ਸਕਦੇ। ਇਹ ਕੁਝ ਇਸ ਤਰ੍ਹਾਂ ਸੀ ਜਿਵੇਂ ਕਈ ਰੇਲ ਪ੍ਰਣਾਲੀਆਂ ਹੋਣ ਜਿੱਥੇ ਟਰੈਕ ਦੀ ਚੌੜਾਈ ਵੱਖਰੀ ਹੋਵੇ ਅਤੇ ਸਿਗਨਲਾਂ ਦੇ ਅਰਥ ਵੱਖ-ਵੱਖ ਹੋਣ। ਇਕ ਹੀ ਪ੍ਰਣਾਲੀ ਅੰਦਰ ਟ੍ਰੇਨ ਚੱਲ ਸਕਦੀ ਹੈ, ਪਰ ਦੂਜੇ ਸਿਸਟਮ ਵਿੱਚ ਜਾਣا ਮਹਿੰਗਾ, ਗੁੰਝਲਦਾਰ ਜਾਂ ਅਸੰਭਵ ਹੋ ਸਕਦਾ ਹੈ।
Bob Kahn ਦੀ ਮੁੱਖ ਚੁਣੌਤੀ ਸਿਰਫ਼ "ਕੰਪਿਊਟਰ A ਨੂੰ B ਨਾਲ ਜੋੜੋ" ਨਹੀਂ ਸੀ। ਇਹ ਸੀ: ਕਿਵੇਂ ਤੁਸੀਂ ਨੈੱਟਵਰਕਾਂ ਨੂੰ ਇਕੱਠਾ ਜੋੜ ਸਕਦੇ ਹੋ ਤਾਂ ਕਿ ਟ੍ਰੈਫਿਕ ਅਨੇਕ ਅਜਿਹੇ ਨਿੱਜੀ ਸਿਸਟਮਾਂ ਵਿੱਚੋਂ ਲੰਘ ਕੇ ਵੀ ਇੱਕ ਵੱਡੇ ਸਿਸਟਮ ਵਰਗਾ ਲੱਗੇ?
ਇਹੀ "internetworking" ਦਾ ਮਤਲਬ ਹੈ—ਅਜਿਹਾ ਤਰੀਕਾ ਬਣਾਉਣਾ ਜੋ ਡੇਟਾ ਨੂੰ ਇੱਕ ਨੈੱਟਵਰਕ ਤੋਂ ਦੂਜੇ ਨੈੱਟਵਰਕ ਤੱਕ ਛੱਡ ਸਕੇ, ਚਾਹੇ ਉਹ ਨੈੱਟਵਰਕ ਵੱਖਰੇ ਡਿਜ਼ਾਈਨ ਅਤੇ ਵੱਖ-ਵੱਖ ਪ੍ਰਬੰਧਨ ਵਾਲੇ ਹੋਣ।
ਬੜੇ ਪੱਧਰ 'ਤੇ internetworking ਕੰਮ ਕਰਨ ਲਈ ਹਰ ਇੱਕ ਨੂੰ ਸਾਂਝੇ ਨਿਯਮ ਚਾਹੀਦੇ ਸਨ—ਇਹਨਾਂ ਨਿਯਮਾਂ ਨੂੰ ਕਿਸੇ ਇੱਕ ਨੈੱਟਵਰਕ ਦੀ ਅੰਦਰੂਨੀ ਡਿਜ਼ਾਈਨ 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ। ਉਹ ਨਿਯਮ ਹਕੀਕਤੀਆਂ ਨੂੰ ਵੀ ਧਿਆਨ ਵਿੱਚ ਰੱਖਣੇ ਚਾਹੀਦੇ ਸਨ:
TCP/IP ਵਿਆਵਹਾਰਿਕ ਜਵਾਬ ਬਣਿਆ: ਇੱਕ ਸਾਂਝੀ "ਇਕਰਾਰਨਾਮਾ" ਜੋ ਅਜ਼ਾਦ ਨੈੱਟਵਰਕਾਂ ਨੂੰ ਇਕੱਠਾ ਜੋੜਨ ਦਿੰਦਾ ਅਤੇ ਹਾਲੀ-ਹਾਲੀ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਕਾਫ਼ੀ ਭਰੋਸੇਯੋਗ ਟ੍ਰਾਂਸਫਰ ਮੁਹੱਈਆ ਕਰਦਾ।
Bob Kahn ਨੂੰ ਇੰਟਰਨੈੱਟ ਦੇ "ਟ੍ਰੈਫਿਕ ਦੇ ਨਿਯਮ" ਦੇ ਇੱਕ ਮੁੱਖ ਆਰਕੀਟੈਕਟ ਵਜੋਂ ਜਾਣਿਆ ਜਾਂਦਾ ਹੈ। 1970s ਵਿੱਚ DARPA 'ਤੇ ਕੰਮ ਕਰਦਿਆਂ, ਉਸਨੇ ਨੈੱਟਵਰਕਿੰਗ ਨੂੰ ਇੱਕ ਚਤੁਰ ਅਨੁਸ਼ੀਲਨ ਤੋਂ ਇਸ ਪੱਧਰ ਤੱਕ ਖਿੱਚਿਆ ਕਿ ਵੱਖ-ਵੱਖ ਕਿਸਮਾਂ ਦੇ ਨੈੱਟਵਰਕ ਇੱਕ-ਦੂਜੇ ਨਾਲ ਜੁੜ ਸਕਣ—ਬਿਨਾ ਇਹ ਮੰਗ ਕਰਨ ਦੇ ਕਿ ਉਹ ਸਾਰਿਆਂ ਨੇ ਇੱਕੋ ਹਾਰਡਵੇਅਰ, ਤਾਰ-ਵਤਨ ਜਾਂ ਅੰਦਰੂਨੀ ਡਿਜ਼ਾਈਨ ਵਰਤੇ।
ARPANET ਨੇ ਦਿਖਾਇਆ ਕਿ ਕਮਪਿਊਟਰ ਪੈਕੇਟ-ਸਵਿੱਚਡ ਲਿੰਕਾਂ 'ਤੇ ਗੱਲਬਾਤ ਕਰ ਸਕਦੇ ਹਨ। ਪਰ ਹੋਰ ਨੈੱਟਵਰਕ ਵੀ ਆ ਰਹੇ ਸਨ—ਰੇਡੀਓ-ਅਧਾਰਤ ਸਿਸਟਮ, ਸੈਟਲਾਈਟ ਲਿੰਕ, ਅਤੇ ਹੋਰ ਪ੍ਰਯੋਗਾਤਮਕ ਨੈੱਟਵਰਕ—ਹਰ ਇੱਕ ਦੀ ਆਪਣੀ ਵਿਸ਼ੇਸ਼ਤਾ। Kahn ਦਾ ਧਿਆਨ interoperability ਤੇ ਸੀ: ਇੱਕ ਸੁਨੇਹਾ ਕਈ ਨੈੱਟਵਰਕਾਂ 'ਚੋਂ ਲੰਘ ਕੇ ਵੀ ਇੱਕ ਹੀ ਨੈੱਟਵਰਕ ਵਾਂਗ ਪਹੁੰਚ ਸਕੇ।
ਉਸਦੀ ਪਹੁੰਚ ਇਹ ਸੀ:
Vint Cerf ਨਾਲ ਮਿਲ ਕੇ, Kahn ਨੇ ਉਹ ਡਿਜ਼ਾਈਨ ਬਣਾਇਆ ਜੋ TCP/IP ਬਣਿਆ। ਇਕ ਲੰਬੇ ਸਮੇਂ ਦਾ ਨਤੀਜਾ ਇਹ ਸਾਫ਼ ਜ਼ਿੰਮੇਵਾਰੀ ਵੰਡ ਸੀ: IP ਪਤੇ ਅਤੇ ਨੈੱਟਵਰਕਾਂ ਵਿਚਕਾਰ ਫਾਰਵਰਡਿੰਗ ਦਾ ਕੰਮ ਕਰਦਾ ਹੈ, ਜਦਕਿ TCP ਉਸ ਉੱਤੇ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਭਰੋਸੇਯੋਗ ਡਿਲਿਵਰੀ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਕਦੇ API ਕਾਲ ਕੀਤੀ ਹੈ, ਵੈਬ ਪੇਜ ਲੋਡ ਕੀਤਾ ਹੈ, ਜਾਂ ਕਿਸੇ ਕੰਟੇਨਰ ਤੋਂ ਲਾਗਜ਼ ਇੱਕ ਮਾਨਿਟਰਿੰਗ ਸਰਵਿਸ ਨੂੰ ਭੇਜੇ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਉਸ internetworking ਮਾਡਲ 'ਤੇ ਨਿਰਭਰ ਹੋ ਜੋ Kahn ਨੇ ਅੱਗੇ ਵਧਾਇਆ। ਤੁਹਾਨੂੰ ਇਹ ਨਹੀਂ ਪਤਾ ਲਗਾਉਣਾ ਪੈਂਦਾ ਕਿ ਪੈਕੇਟ Wi‑Fi, ਫਾਈਬਰ, LTE ਜਾਂ ਕਲਾਉਡ ਬੈਕਬੋਨ ਰਾਹੀਂ ਕਿਵੇਂ ਜਾਂਦੇ ਹਨ। TCP/IP ਇਹ ਸਾਰਾ ਕੁਝ ਇਕ ਲਗਾਤਾਰ ਪ੍ਰਣਾਲੀ ਵਾਂਗ ਦਿਖਾਉਂਦਾ ਹੈ—ਤਾਂ ਜੋ ਸਾਫਟਵੇਅਰ ਫੀਚਰਾਂ 'ਤੇ ਧਿਆਨ ਦੇ ਸਕੇ, ਤਾਰ-ਤੰਤਰ 'ਤੇ ਨਹੀਂ।
TCP/IP ਦੇ ਪਿੱਛੇ ਇੱਕ ਸਭ ਤੋਂ ਚਤੁਰ ਵਿਚਾਰ ਹੈ ਲੇਅਰਿੰਗ: ਇੱਕ ਵੱਡੇ "ਸਭ ਕੁਝ ਕਰਨ ਵਾਲੇ" ਨੈੱਟਵਰਕ ਸਿਸਟਮ ਦੀ ਥਾਂ, ਤੁਸੀਂ ਛੋਟੀਆਂ ਪਰਤਾਂ ਨੂੰ ਗੜੀਚੜ੍ਹੀ ਰੱਖਦੇ ਹੋ ਜਿੱਥੇ ਹਰ ਲੇਅਰ ਇਕ ਕੰਮ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕਰਦੀ ਹੈ।
ਇਹ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ ਕਿਉਂਕਿ ਨੈੱਟਵਰਕ ਇਕੋ ਜਿਹੇ ਨਹੀਂ ਹੁੰਦੇ। ਵੱਖ-ਵੱਖ ਤਾਰੇ, ਰੇਡੀਓ, ਰਾਊਟਰ ਅਤੇ ਪ੍ਰੋਵਾਇਡਰ ਫਿਰ ਵੀ ਉਹੀ ਤਰੀਕੇ ਨਾਲ ਇੰਟਰਓਪਰੇਟ ਕਰ ਸਕਦੇ ਹਨ ਜਦੋਂ ਉਹ ਕੁਝ ਸਾਫ਼ ਜ਼ਿੰਮੇਵਾਰੀਆਂ 'ਤੇ ਸਹਿਮਤ ਹੋ ਜਾਣ।
IP (Internet Protocol) ਇਸ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ: ਇਹ ਡੇਟਾ ਕਿੱਥੇ ਜਾ ਰਿਹਾ ਹੈ, ਅਤੇ ਅਸੀਂ ਇਸਨੂੰ ਉਸ ਥਾਂ ਵੱਲ ਕਿਵੇਂ ਲਿਜਾਏਂਗੇ?
IP ਪਤੇ ਦਿੰਦਾ ਹੈ (ਤਾਂ ਜੋ ਮਸ਼ੀਨਾਂ ਦੀ ਪਛਾਣ ਹੋ ਸਕੇ) ਅਤੇ ਬੁਨਿਆਦੀ ਰਾਊਟਿੰਗ ਮੁਹੱਈਆ ਕਰਦਾ ਹੈ (ਤਾਂ ਜੋ ਪੈਕੇਟਾਂ ਨੈੱਟਵਰਕ ਤੋਂ ਨੈੱਟਵਰਕ ਹੋ ਕੇ ਹੌਲੀ-ਹੌਲੀ ਅੱਗੇ ਵਧ ਸਕਣ)। ਜ਼ਰੂਰੀ ਗੱਲ ਇਹ ਹੈ ਕਿ IP ਪੂਰਨਤਾ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਕਰਦਾ। ਇਹ ਹਰ ਇੱਕ ਕਦਮ ਤੇ ਪੈਕੇਟਾਂ ਨੂੰ ਅੱਗੇ ਭੇਜਣ 'ਤੇ ਧਿਆਨ ਦਿੰਦਾ ਹੈ, ਭਾਵੇਂ ਰਸਤਾ ਬਦਲ ਜਾਵੇ।
TCP (Transmission Control Protocol) IP ਦੇ ਉੱਪਰ ਬੈਠਦਾ ਹੈ ਅਤੇ ਇਹ ਸਵਾਲ ਪੂਰਾ ਕਰਦਾ ਹੈ: ਅਸੀਂ ਇਸਨੂੰ ਇੱਕ ਭਰੋਸੇਯੋਗ ਕਨੈਕਸ਼ਨ ਵਰਗਾ ਕਿਵੇਂ ਮਹਿਸੂਸ ਕਰਵਾਈਏ?
TCP ਉਹ “ਰਿਲਾਇਬਿਲਿਟੀ” ਕੰਮ ਸੰਭਾਲਦਾ ਹੈ ਜੋ ਐਪਸ ਆਮ ਤੌਰ 'ਤੇ ਚਾਹੁੰਦੀਆਂ ਹਨ: ਡੇਟਾ ਨੂੰ ਸਹੀ ਕ੍ਰਮ ਵਿੱਚ ਪੁਹੁੰਚਾਉਣਾ, ਗੁੰਮ ਹੋਏ ਹਿੱਸਿਆਂ ਦੀ ਪਛਾਣ ਕਰਨਾ, ਜ਼ਰੂਰਤ ਪੈਣ 'ਤੇ ਮੁੜ ਭੇਜਣਾ, ਅਤੇ ਸੈਂਡਰ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਪੇਸ ਕਰਨਾ ਕਿ ਉਹ ਰਿਸੀਵਰ ਜਾਂ ਨੈੱਟਵਰਕ ਨੂੰ ਓਵਰਵੈਲਮ ਨਾ ਕਰੇ।
ਇੱਕ ਸੁਝਾਉਣਾ ਤਰੀਕਾ:
ਤੁਸੀਂ ਆਡਰੈੱਸ ਤੋਂ ਇਹ ਉਮੀਦ ਨਹੀਂ ਕਰਦੇ ਕਿ ਪੈਕੇਜ ਜ਼ਰੂਰ ਪਹੁੰਚੇ; ਤੁਸੀਂ ਉਹ ਯਕੀਨੀਤਾ ਉੱਪਰਲੇ ਸਤਰ 'ਤੇ ਬਣਾ ਰਹੇ ਹੋ।
ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਦੇ ਵੰਡ ਹੋਣ ਕਾਰਨ, ਤੁਸੀਂ ਇੱਕ ਲੇਅਰ ਨੂੰ ਬਦਲ ਸਕਦੇ ਹੋ ਬਿਨਾ ਸਭ ਕੁਝ ਨਵੇਂ ਸਿਰੇ ਤੋਂ ਬਣਾਏ। ਨਵੇਂ ਭੌਤਿਕ ਨੈੱਟਵਰਕ IP ਚਲਾਉਂਦੇ ਰਹਿ ਸਕਦੇ ਹਨ, ਅਤੇ ਐਪ TCP ਦੇ ਵਿਹਾਰ 'ਤੇ ਭਰੋਸਾ ਕਰ ਸਕਦੇ ਹਨ ਬਿਨਾ ਰਾਊਟਿੰਗ ਨੂੰ ਸਮਝਣ ਦੀ ਲੋੜ ਦੇ। ਇਹ ਸਾਫ਼ ਵੰਡ TCP/IP ਨੂੰ ਲਗਭਗ ਹਰ ਐਪ ਅਤੇ API ਦੇ ਹੇਠਾਂ ਇੱਕ ਅਦ੍ਰਿਸ਼੍ਯ, ਸਾਂਝੀ ਬੁਨਿਆਦ ਬਣਾਉਂਦੀ ਹੈ।
ਪੈਕੇਟ ਸਵਿੱਚਿੰਗ ਉਹ ਵਿਚਾਰ ਹੈ ਜਿਸ ਨੇ ਵੱਡੇ ਨੈੱਟਵਰਕਾਂ ਨੂੰ ਕਾਰਗਰ ਬਣਾਇਆ: ਤੁਸੀਂ ਆਪਣੇ ਸੁਨੇਹੇ ਲਈ ਇੱਕ ਨਿਰਧਾਰਤ ਲਾਈਨ ਰਿਜ਼ਰਵ ਨਹੀਂ ਕਰਦੇ, ਬਲਕਿ ਸੁਨੇਹੇ ਨੂੰ ਛੋਟੇ ਹਿੱਸਿਆਂ ਵਿੱਚ ਤੋੜ ਦਿੰਦੇ ਹੋ ਅਤੇ ਹਰ ਹਿੱਸਾ ਅਲੱਗ-ਅਲੱਗ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ।
ਇੱਕ ਪੈਕੇਟ ਡੇਟਾ ਦਾ ਛੋਟਾ ਗੱਠ (header ਦੇ ਨਾਲ—ਜਿਸ ਵਿੱਚ ਭੇਜਨ ਵਾਲਾ, ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲਾ ਅਤੇ ਹੋਰ ਰਾਊਟਿੰਗ ਜਾਣਕਾਰੀ ਹੁੰਦੀ ਹੈ) ਅਤੇ ਸਮੱਗਰੀ ਦਾ ਇੱਕ ਟੁਕੜਾ ਹੁੰਦਾ ਹੈ।
ਡੇਟਾ ਨੂੰ ਹਿੱਸਿਆਂ ਵਿੱਚ ਵਾਂਟਣ ਨਾਲ ਨੈੱਟਵਰਕ ਕਰਨ ਯੋਗ ਹੁੰਦਾ ਹੈ:
ਇਥੇ ਹੀ "ਬੇਤਰਤੀਬੀ" ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ। ਇੱਕੋ ਡਾਊਨਲੋਡ ਜਾਂ API ਕਾਲ ਦੇ ਪੈਕੇਟ ਵੱਖ-ਵੱਖ ਰਸਤੇ ਲੈ ਸਕਦੇ ਹਨ, ਜੋ ਕਿਸੇ ਸਮੇਂ ਉੱਪਰ ਭਰਪੂਰ ਜਾਂ ਉਪਲਬਧਤਾ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਇਸਦਾ ਨਤੀਜਾ ਇਹ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਉਹ ਆਉਣ 'ਤੇ ਕ੍ਰਮ ਤੋਂ ਬਾਹਰ ਹੋਣ—ਜਿਵੇਂ ਕਿ ਪੈਕੇਟ #12 ਪਹਿਲਾਂ ਪਹੁੰਚ ਜਾਵੇ ਅਤੇ #5 ਬਾਅਦ ਵਿੱਚ।
ਪੈਕੇਟ ਸਵਿੱਚਿੰਗ ਇਸਨੂੰ ਰੋਕਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਕਰਦੀ। ਇਹ ਇਸ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦੀ ਹੈ ਕਿ ਪੈਕੇਟ ਤੇਜ਼ੀ ਨਾਲ ਪਹੁੰਚਣ, ਭਾਵੇਂ ਆਉਣ ਵਾਲਾ ਕ੍ਰਮ ਗੜਬੜ ਹੋਵੇ।
ਪੈਕੇਟ ਲਾਸ ਸਾਧਾਰਨ ਹੈ, ਅਤੇ ਇਹ ਹਮੇਸ਼ਾਂ ਕਿਸੇ ਦੀ ਗਲਤੀ ਨਹੀਂ ਹੁੰਦੀ। ਆਮ ਕਾਰਨ:
ਮੁੱਖ ਡਿਜ਼ਾਈਨ ਚੋਣ ਇਹ ਸੀ ਕਿ ਨੈੱਟਵਰਕ ਅਪਰਫੈਕਟ ਹੋ ਸਕਦਾ ਹੈ। IP ਦਾ ਫੋਕਸ ਪੈਕੇਟਾਂ ਨੂੰ ਵਧੀਆ ਤਰੀਕੇ ਨਾਲ ਅੱਗੇ ਭੇਜਣਾ ਹੈ, ਡਿਲਿਵਰੀ ਜਾਂ ਕ੍ਰਮ ਦੀ ਗਰੰਟੀ ਨਹੀਂ। ਇਹ ਆਜ਼ਾਦੀ ਨੈੱਟਵਰਕਾਂ ਨੂੰ ਸਕੇਲ ਕਰਨ ਦੇ ਯੋਗ ਬਣਾਉਂਦੀ ਹੈ—ਅਤੇ ਇਹੀ ਕਾਰਨ ਹੈ ਕਿ ਉੱਚ ਪੱਧਰ (ਜਿਵੇਂ TCP) ਮੌਜੂਦ ਹੋ ਕੇ ਗੜਬੜ ਨੂੰ ਸਾਫ਼ ਕਰਦੇ ਹਨ।
IP ਪੈਕੇਟਾਂ ਨੂੰ "best effort" ਤਰੀਕੇ ਨਾਲ ਡਿਲਿਵਰ ਕਰਦਾ ਹੈ: ਕੁਝ ਦੇਰੀ ਨਾਲ, ਕ੍ਰਮ ਤੋਂ ਬਾਹਰ, ਡੁਪਲਿਕੇਟ ਜਾਂ ਗੁੰਮ ਹੋ ਸਕਦੇ ਹਨ। TCP ਇਸਦੇ ਉੱਪਰ ਬੈਠ ਕੇ ਐਪਲੀਕੇਸ਼ਨ ਲਈ ਇੱਕ ਇਕੱਲਾ, ਕ੍ਰਮਬੱਧ, ਪੂਰਾ ਬਾਈਟ ਸਟ੍ਰੀਮ ਬਣਾਉਂਦਾ ਹੈ—ਉਸ ਤਰ੍ਹਾਂ ਦੀ ਕਨੈਕਸ਼ਨ ਜੋ ਤੁਸੀਂ ਫਾਈਲ ਅੱਪਲੋਡ, ਵੈਬ ਪੇਜ ਲੋਡ ਜਾਂ API ਕਾਲ ਦੌਰਾਨ ਉਮੀਦ ਕਰਦੇ ਹੋ।
ਜਦ ਲੋਕ ਕਹਿੰਦੇ ਹਨ TCP "ਭਰੋਸੇਯੋਗ" ਹੈ, ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਮਤਲਬ ਲੈਂਦੇ ਹਨ:
TCP ਤੁਹਾਡੇ ਡੇਟਾ ਨੂੰ ਹਿੱਸਿਆਂ ਵਿੱਚ ਤੋੜਦਾ ਹੈ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਸੀਕੁਐੰਸ ਨੰਬਰ ਦਿੰਦਾ ਹੈ। ਰਿਸੀਵਰ ACKs ਭੇਜਦਾ ਹੈ ਤਾਂ ਜੋ ਦੱਸਿਆ ਜਾ ਸਕੇ ਕਿ ਕੀ ਮਿਲਿਆ।
ਜੇ ਸੈਂਡਰ ਨੂੰ ਸਮੇਤ ACK ਨਹੀਂ ਮਿਲਦਾ, ਤਾਂ ਉਹ ਸੋਚਦਾ ਹੈ ਕਿ ਕੁਝ ਗੁੰਮ ਹੋ ਗਿਆ ਅਤੇ ਰੀਟ੍ਰਾਂਸਮਿਟ ਕਰਦਾ ਹੈ। ਇਹੀ ਮੁੱਖ "ਭ੍ਰਮ" ਹੈ: ਭਾਵੇਂ ਨੈੱਟਵਰਕ ਕੋਈ ਪੈਕੇਟ ਗੁਆ ਦੇਵੇ, TCP ਲਗਾਤਾਰ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ ਜਦ ਤੱਕ ਰਿਸੀਵਰ ਪੁਸ਼ਟੀ ਨਾ ਕਰੇ।
ਇਹ ਦੋ ਅਲੱਗ ਚੀਜ਼ਾਂ ਹਵਾਲੇ ਨਾਲ:
ਇੱਕਠੇ, ਇਹ TCP ਨੂੰ ਤੇਜ਼ ਅਤੇ ਬੇਹਦ ਜ਼ਿਆਦਾ ਬੇਫਿਕਰ ਨਾ ਬਣਨ ਦਿੰਦੇ।
ਇੱਕ ਫਿਕਸਡ ਟਾਈਮਆਉਟ ਧੀਮੇ ਅਤੇ ਤੇਜ਼ ਦੋਹਾਂ ਨੈੱਟਵਰਕਾਂ 'ਤੇ ਨਾਕਾਮ ਰਹੇਗਾ। TCP ਲਗਾਤਾਰ ਆਪਣਾ ਟਾਈਮਆਉਟ ਸੰਚੀਤ round-trip ਸਮਾਂ ਮਾਪ ਕੇ ਢਾਲਦਾ ਹੈ। ਜੇ ਹਾਲਾਤ ਖਰਾਬ ਹੁੰਦੇ ਹਨ, ਤਾਂ ਇਹ ਮੁੜ ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਵੱਧ ਸਮਾਂ ਉਡੀਕਦਾ ਹੈ; ਜੇ ਗਤੀ ਤੇਜ਼ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਜ਼ਿਆਦਾ ਜਵਾਬਦੇਹ ਹੋ ਜਾਂਦਾ ਹੈ। ਇਹ ਢਲਣ TCP ਨੂੰ Wi‑Fi, ਮੋਬਾਈਲ ਨੈੱਟਵਰਕਾਂ ਅਤੇ ਲੰਮੇ-ਫਾਸਲੇ ਲਿੰਕਾਂ 'ਤੇ ਕੰਮ ਕਰਨਯੋਗ ਬਣਾਉਂਦੀ ਹੈ।
TCP/IP ਦੇ ਪਿੱਛੇ ਸਭ ਤੋਂ ਅਹੰਕਾਰਪੂਰਨ ਵਿਚਾਰਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ ਐਂਡ-ਟੂ-ਐਂਡ ਸਿਧਾਂਤ: ਨੈੱਟਵਰਕ ਦੇ ਐਂਡਪੌਇੰਟਸ (ਅੰਤ) 'ਤੇ "ਸਮਾਰਟ" ਰੱਖੋ, ਅਤੇ ਨੈੱਟਵਰਕ ਦੇ ਮੱਧ ਨੂੰ نسبتا सरल ਰੱਖੋ।
ਸਧਾਰਨ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਐਂਡਪੌਇੰਟਸ ਉਹ ਡਿਵਾਈਸਾਂ ਅਤੇ ਪ੍ਰੋਗਰਾਮ ਹਨ ਜੋ ਹਕੀਕਤ ਵਿੱਚ ਡੇਟਾ ਦੀ ਪਰਵਾਹ ਕਰਦੇ ਹਨ: ਤੁਹਾਡੇ ਫੋਨ, ਲੈਪਟੌਪ, ਸਰਵਰ, ਅਤੇ ਉਨ੍ਹਾਂ 'ਤੇ ਚੱਲ ਰਹੀ ਓਐਸਾਂ ਅਤੇ ਐਪਸ। ਨੈੱਟਵਰਕ ਕੋਰ—ਰਾਊਟਰਾਂ ਅਤੇ ਲਿੰਕਾਂ—ਮੂਲਤ: ਪੈਕੇਟਾਂ ਨੂੰ ਅੱਗੇ ਭੇਜਣ 'ਤੇ ਧਿਆਨ ਦਿੰਦੇ ਹਨ।
ਸਭ ਰਾਊਟਰਾਂ ਨੂੰ ਹਰ ਐਪ ਦੀ ਲੋੜ ਸਮਝਣ ਦੀ ਜਰੂਰਤ ਨਹੀਂ ਹੋਣੀ ਚਾਹੀਦੀ।
ਕੋਰ ਨੂੰ ਸਧਾਰਨ ਰੱਖਣ ਨਾਲ ਇੰਟਰਨੈੱਟ ਦਾ ਵਧਣਾ ਆਸਾਨ ਹੋ ਗਿਆ। ਨਵੀਆਂ ਨੈੱਟਵਰਕਾਂ ਨੂੰ ਜੁੜਨ ਲਈ ਹਰ ਰਾਊਟਰ ਨੂੰ ਹਰ ਐਪ ਦੀ ਲੋੜ ਸਮਝਣ ਦੀ ਲੋੜ ਨਹੀਂ ਪਈ। ਰਾਊਟਰਾਂ ਨੂੰ ਪਤਾ ਨਹੀਂ ਹੁੰਦਾ ਕਿ ਕੋਈ ਪੈਕੇਟ ਵੀਡੀਓ ਕਾਲ ਦਾ ਹੈ, ਫਾਈਲ ਡਾਊਨਲੋਡ ਦਾ ਹੈ ਜਾਂ API ਬੇਨਤੀ ਦਾ—ਉਹ ਸਿਰਫ਼ ਅੱਗੇ ਭੇਜਦੇ ਹਨ।
ਐਂਡਪੌਇੰਟਸ 'ਤੇ ਆਮ ਤੌਰ 'ਤੇ ਤੁਸੀਂ ਸੰਭਾਲਦੇ ਹੋ:
ਨੈੱਟਵਰਕ ਵਿੱਚ ਆਮ ਤੌਰ 'ਤੇ ਤੁਸੀਂ ਸੰਭਾਲਦੇ ਹੋ:
ਐਂਡ-ਟੂ-ਐਂਡ ਸੋਚ ਚੰਗਾ ਸਕੇਲ ਕਰਦੀ ਹੈ, ਪਰ ਇਸ ਨਾਲ ਜ਼ਿੰਮੇਵਾਰੀ ਬਾਹਰ ਵਧ ਜਾਂਦੀ ਹੈ। ਓਐਸ, ਲਾਈਬਰੇਰੀਆਂ ਅਤੇ ਐਪਸ ਨੂੰ ਗੰਦੇ ਨੈੱਟਵਰਕ ਤੇ ਕੰਮ ਕਰਨ ਲਈ "ਇੱਕਠੇ ਕਰਨਾ" ਪੈਂਦਾ ਹੈ। ਇਹ ਲਚਕੀਲਾਪਨ ਲਈ ਵਧੀਆ ਹੈ, ਪਰ ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਬੱਗ, ਗਲਤ ਟਾਈਮਆਉਟ ਜਾਂ ਜ਼ਿਆਦਾ ਅੱਗੇ-ਵਧਨ ਵਾਲੀਆਂ ਰੀਟ੍ਰਾਈਜ਼ਾਂ ਸੱਚੀ ਯੂਜ਼ਰ-ਸਮਾਗਮ ਸਮੱਸਿਆ ਪੈਦਾ ਕਰ ਸਕਦੀਆਂ ਹਨ।
IP (Internet Protocol) ਇਕ ਸਧਾਰਨ ਵਾਅਦਾ ਕਰਦਾ ਹੈ: ਇਹ ਕੋਸ਼ਿਸ਼ ਕਰੇਗਾ ਕਿ ਤੁਹਾਡੇ ਪੈਕੇਟਾਂ ਨੂੰ ਉਨ੍ਹਾਂ ਦੇ ਗੰਤਵ੍ਯ ਵੱਲ ਭੇਜੇ। بس। ਕੋਈ ਗਰੰਟੀ ਨਹੀਂ ਕਿ ਪੈਕੇਟ ਪਹੁੰਚੇਗਾ, ਇਕ ਹੀ ਵਾਰੀ ਪਹੁੰਚੇਗਾ, ਕ੍ਰਮ ਵਿੱਚ ਹੋਵੇਗਾ, ਜਾਂ ਕਿਸੇ ਨਿਰਧਾਰਤ ਸਮੇਂ ਵਿੱਚ ਪਹੁੰਚੇਗਾ।
ਇਹ ਸੁਣਨ ਵਿੱਚ ਕਮਜ਼ੋਰੀ ਲੱਗ ਸਕਦੀ ਹੈ—ਪਰ ਜਦ ਤੁਸੀਂ ਦੇਖਦੇ ਹੋ ਕਿ ਇੰਟਰਨੈੱਟ ਨੂੰ ਕੀ ਬਣਨਾ ਸੀ: ਸਭ ਤੋੰ ਵੱਡਾ ਨੈੱਟਵਰਕ ਜੋ ਕਈ ਛੋਟੇ-ਛੋਟੇ ਨੈੱਟਵਰਕਾਂ ਦਾ ਗਠਜੋੜ ਹੈ, ਉਹਨਾਂ ਵੱਲੋਂ ਬਣਾਇਆ ਗਿਆ—ਤਾਂ ਇਹ ਮਾਡਲ ਲਾਜ਼ਮੀ ਸੀ।
ਰਾਊਟਰ IP ਦੇ "ਟ੍ਰੈਫਿਕ ਡਾਇਰੈਕਟਰ" ਹਨ। ਉਹਨਾਂ ਦਾ ਮੁੱਖ ਕੰਮ ਫਾਰਵਰਡਿੰਗ ਹੈ: ਜਦ ਇੱਕ ਪੈਕੇਟ ਆਉਂਦਾ ਹੈ, ਰਾਊਟਰ ਡੈਸਟਿਨੇਸ਼ਨ ਪਤਾ ਵੇਖ ਕੇ ਅਗਲਾ ਹੋਪ ਚੁਣਦਾ ਹੈ ਜੋ ਹੁਣ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ ਲੱਗਦਾ ਹੈ।
ਰਾਊਟਰ ਇਕ ਗੱਲਬਾਤ ਦਾ ਟਰੈਕ ਨਹੀਂ ਰੱਖਦੇ ਜਿਵੇਂ ਇੱਕ ਫ਼ੋਨ ਆਪਰੇਟਰ ਕਰਦਾ। ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਤੁਹਾਡੇ ਲਈ ਸਮਰੱਥਾ ਰਿਜ਼ਰਵ ਨਹੀਂ ਕਰਦੇ, ਅਤੇ ਬਾ ਨਹੀਂ ਰਹਿੰਦੇ ਕਿ ਕੋਈ ਪੈਕੇਟ ਪੁਹੁੰਚਿਆ ਕਿ ਨਹੀਂ। ਰਾਊਟਰਾਂ ਨੂੰ ਫਾਰਵਰਡਿੰਗ 'ਤੇ ਧਿਆਨ ਕੇਂਦ੍ਰਿਤ ਰੱਖ ਕੇ, ਨੈੱਟਵਰਕ ਦਾ ਕੋਰ ਸਧਾਰਨ ਰਹਿੰਦਾ—ਅਤੇ ਇਹ ਬੇਹੱਦ ਜ਼ਿਆਦਾ ਯੰਤਰਾਂ ਅਤੇ ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਸਹਾਰ ਸਕਦਾ ਹੈ।
ਗਰੰਟੀ ਮਹਿੰਗੀ ਹੁੰਦੀ ਹੈ। ਜੇ IP ਹਰ ਪੈਕੇਟ ਲਈ ਡਿਲਿਵਰੀ, ਕ੍ਰਮ ਅਤੇ ਸਮਿਆਂ ਦੀ ਗਰੰਟੀ ਦੇਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ, ਤਾਂ ਧਰਤੀ ਦੇ ਹਰੇਕ ਨੈੱਟਵਰਕ ਨੂੰ ਕੜੀ ਤਰ੍ਹਾਂ ਕੋਆਰਡੀਨੇਟ ਕਰਨਾ ਪੈਂਦਾ, ਬਹੁਤ ਸਾਰਾ ਸਟੇਟ ਸਟੋਰ ਕਰਨਾ ਪੈਂਦਾ, ਅਤੇ ਫੇਲ੍ਹ ਹੋਣ 'ਤੇ ਇੱਕੋ ਤਰੀਕੇ ਨਾਲ ਰਿਕਵਰ ਕਰਨਾ ਪੈਂਦਾ। ਇਹ ਕੋਆਰਡੀਨੇਸ਼ਨ ਦਾ ਮੋਹਰਨਾ ਵਾਧਾ ਕਰ ਦਿੰਦਾ ਅਤੇ ਵਿਕਾਸ ਨੂੰ ਰੋਕ ਦਿੰਦਾ।
ਇਸ ਦੀ ਥਾਂ, IP ਗਲਤੀਆਂ ਨੂੰ ਬਰਦਾਸ਼ਤ ਕਰਦਾ ਹੈ। ਜੇ ਕੋਈ ਲਿੰਕ ਫੇਲ ਹੋ ਜਾਂਦਾ ਹੈ, ਇੱਕ ਰਾਊਟਰ ਪੈਕੇਟਾਂ ਨੂੰ ਵੱਖ-ਵੱਖ ਰੂਟ ਰਾਹੀਂ ਭੇਜ ਸਕਦਾ ਹੈ। ਜੇ ਕੋਈ ਰਾਹ ਭੀੜ ਭਰ ਜਾਂਦਾ ਹੈ, ਪੈਕੇਟਾਂ ਨੂੰ ਦੇਰੀ ਜਾਂ ਡ੍ਰਾਪ ਹੋ ਸਕਦੀ ਹੈ, ਪਰ ਟ੍ਰੈਫਿਕ ਅਕਸਰ ਵਿਕਲਪਿਕ ਰਸਤੇ ਰਾਹੀਂ ਜਾਰੀ ਰਹਿ ਸਕਦਾ ਹੈ।
ਨਤੀਜਾ ਇਹ ਹੈ ਕਿ ਇੰਟਰਨੈੱਟ ਸਹਿਯੋਗੀ ਰਹਿ ਸਕਦਾ ਹੈ ਭਾਵੇਂ ਉਸਦੇ ਕੁਝ ਹਿੱਸੇ ਟੁੱਟ ਜਾਂ ਬਦਲ ਜਾਣ—ਕਿਉਂਕਿ ਨੈੱਟਵਰਕ ਨੂੰ ਪੂਰਾ ਹੋਣ ਦੀ ਜ਼ਰੂਰਤ ਨਹੀਂ ਸੀ ਤਾਂ ਕਿ ਉਹ ਉਪਯੋਗੀ ਰਹੇ।
ਜਦ ਤੁਸੀਂ fetch() ਨਾਲ API ਕਾਲ ਕਰਦੇ ਹੋ, "Save" 'ਤੇ ਕਲਿੱਕ ਕਰਦੇ ਹੋ, ਜਾਂ ਇੱਕ websocket ਖੋਲ੍ਹਦੇ ਹੋ, ਤੁਸੀਂ ਇੱਕ ਨਰਮ, ਇਕੱਲੀ ਗੱਲ ਨਹੀਂ ਕਰ ਰਹੇ। ਤੁਹਾਡੀ ਐਪ ਓਐਸ ਨੂੰ ਡੇਟਾ ਦੇਂਦੀ ਹੈ, ਜੋ ਉਸਨੂੰ ਪੈਕੇਟਾਂ ਵਿੱਚ ਤੋੜਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਕਈ ਵੱਖ-ਵੱਖ ਨੈੱਟਵਰਕਾਂ ਰਾਹੀਂ ਭੇਜਦਾ ਹੈ—ਹਰ ਹੋਪ ਆਪਣਾ ਫੈਸਲਾ ਕਰਦਾ ਹੈ।
ਇੱਕ ਆਮ ਹੈਰਾਨੀ: ਤੁਹਾਡੇ ਕੋਲ ਵਧੀਆ throughput ਹੋ ਸਕਦਾ ਹੈ ਫਿਰ ਵੀ UI ਸੁਸਤ ਮਹਿਸੂਸ ਹੋਵੇ—ਕਿਉਂਕਿ ਹਰ ਬੇਨਤੀ ਰਾਊਂਡ ਟਰਿਪ ਦਾ ਇੰਤਜ਼ਾਰ ਕਰਦੀ ਹੈ।
TCP ਗੁੰਮ ਹੋਏ ਪੈਕੇਟਾਂ ਨੂੰ ਮੁੜ ਭੇਜਦਾ ਹੈ, ਪਰ ਇਹ ਨਹੀਂ ਜਾਣਦਾ ਕਿ ਤੁਹਾਡੇ ਯੂਜ਼ਰ ਲਈ "ਬਹੁਤ ਦੇਰ" ਕੀ ਹੈ। ਇਸ ਲਈ ਐਪਲੀਕੇਸ਼ਨ ਨਿਮਨ ਸ਼ਾਮِل ਕਰਦੀਆਂ ਹਨ:
ਪੈਕੇਟਾਂ ਦੇ ਦੇਰੀ ਹੋਣ, ਕ੍ਰਮ ਤੋਂ ਬਾਹਰ, ਡੁਪਲਿਕੇਟ ਹੋਣ ਜਾਂ ਗੁੰਮ ਹੋਣ ਦੀ ਸੰਭਾਵਨਾ ਹੁੰਦੀ ਹੈ। ਭੀੜ latency ਸਕਾਈਕ ਕਰ ਸਕਦੀ ਹੈ। ਇੱਕ ਸਰਵਰ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਪਰ ਜਵਾਬ ਤੁਹਾਡੇ ਕੋਲ ਨਹੀਂ ਪਹੁੰਚਦਾ। ਇਹ flaky tests, ਰੈੰਡਮ 504s, ਜਾਂ "ਮੇਰੀ ਮਸ਼ੀਨ 'ਤੇ ਚੱਲਦਾ ਹੈ" ਵੱਡੇ ਲੱਛਣ ਹਨ। ਅਕਸਰ ਕੋਡ ਠੀਕ ਹੁੰਦਾ ਹੈ—ਪਰ ਮਸ਼ੀਨਾਂ ਦੇ ਵਿਚਕਾਰ ਰਸਤਾ ਨਹੀਂ।
ਕਲਾਉਡ ਪਲੇਟਫਾਰਮ ਅਜਿਹਾ ਮਹਿਸੂਸ ਕਰ ਸਕਦੇ ਹਨ ਜਿਵੇਂ ਇਕ ਨਵੀਂ ਕਿਸਮ ਦੀ computing ਹੋ—ਮੈਨੇਜਡ ਡੇਟਾਬੇਸ, serverless ਫੰਕਸ਼ਨ, "ਅਨੰਤ" ਸਕੇਲਿੰਗ। ਉਸ ਤਹਿਤ, ਤੁਹਾਡੇ ਨਿਕਟਲੇ ਬੇਨਤੀਆਂ ਹਜੇ ਵੀ ਉਹੀ TCP/IP ਨੀਵਾਂ ਉਪਰ ਸਵਾਰੀ ਹੁੰਦੀਆਂ ਹਨ ਜੋ Bob Kahn ਨੇ ਸੁਰੱਖਿਅਤ ਕੀਤਾ: IP ਪੈਕੇਟਾਂ ਨੂੰ ਨੈੱਟਵਰਕਾਂ 'ਤੇ ਚਲਾਉਂਦਾ ਹੈ, ਅਤੇ TCP (ਜਾਂ ਕਦੇ-ਕਦੇ UDP) ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਨੈੱਟਵਰਕ ਦਾ ਅਨੁਭਵ ਘੜਦਾ ਹੈ।
ਵਰਚੁਅਲਾਈਜੇਸ਼ਨ ਅਤੇ ਕੰਟੇਨਰ ਇਹ ਬਦਲਦੇ ਹਨ ਕਿ ਸਾਫਟਵੇਅਰ ਕਿੱਥੇ ਚੱਲਦਾ ਹੈ ਅਤੇ ਕਿਵੇਂ ਪੈਕੇਜ਼ ਕੀਤਾ ਜਾਂਦਾ ਹੈ:
ਪਰ ਇਹ ਡਿਪਲੋਇਮੈਂਟ ਵੇਰਵੇ ਹਨ। ਪੈਕੇਟਾਂ ਅਜੇ ਵੀ IP ਪਤੇ ਅਤੇ ਰਾਊਟਿੰਗ ਵਰਤਦੀਆਂ ਹਨ, ਅਤੇ ਬਹੁਤ ਸਾਰੇ ਕਨੈਕਸ਼ਨ ਹਜੇ ਵੀ TCP 'ਤੇ ਨਿਰਭਰ ਹਨ।
ਆਮ ਕਲਾਉਡ ਆਰਕੀਟੈਕਚਰ ਪਛਾਣੇ ਹੋਏ ਨੈੱਟਵਰਕਿੰਗ ਬਲਾਕਾਂ ਤੋਂ ਬਣੇ ਹੁੰਦੇ ਹਨ:
ਭਾਵੇਂ ਤੁਸੀਂ ਕਦੇ "IP ਪਤਾ" ਨਾ ਵੇਖੋ, ਪਲੇਟਫਾਰਮ ਉਹਨਾਂ ਨੂੰ ਅਲੋਕੇਟ, ਰੂਟ ਕਰਦਾ ਅਤੇ ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਟਰੈਕ ਕਰ ਰਿਹਾ ਹੈ ਪਿੱਛੇ-ਪਿੱਛੇ।
TCP ਡ੍ਰੌਪ ਹੋਏ ਪੈਕੇਟਾਂ ਨੂੰ ਰਿਕਵਰ ਕਰ ਸਕਦਾ ਹੈ, ਡਿਲਿਵਰੀ ਦੀ ਕ੍ਰਮਬੱਧਤਾ ਮੁਹੱਈਆ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਭੀੜ ਦੇ ਅਨੁਸਾਰ ਢਲਵਾਂ ਕਰ ਸਕਦਾ ਹੈ—ਪਰ ਇਹ ਅਸੰਭਵ ਚੀਜ਼ ਦਾ ਵਾਅਦਾ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਕਲਾਉਡ ਸਿਸਟਮਾਂ ਵਿੱਚ, ਭਰੋਸੇਯੋਗਤਾ ਇੱਕ ਟੀਮ ਦਾ ਕੰਮ ਹੈ:
ਇਸੇ ਕਾਰਨ "vibe-coding" ਪਲੇਟਫਾਰਮ ਜੋ ਪੂਰਾ-ਸਟੈਕ ਐਪ ਬਣਾਉਂਦੇ ਹਨ, ਹਾਲਾਂਕਿ ਤੇਜ਼ ਤਰ੍ਹਾਂ ਤਿਆਰ ਕਰਦੇ ਹਨ, ਉਹ ਵੀ انہੀ ਨੀਵਾਂ 'ਤੇ ਨਿਰਭਰ ਹੁੰਦੇ ਹਨ। ਉਦਾਹਰਨ ਲਈ, Koder.ai ਤੁਹਾਨੂੰ React ਵੈੱਬ ਐਪ, Go ਬੈਕਐਂਡ ਅਤੇ PostgreSQL ਤੇਜ਼ੀ ਨਾਲ ਚਲਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਜਦੋਂ ਉਹ ਐਪ API, ਡੇਟਾਬੇਸ ਜਾਂ ਮੋਬਾਈਲ ਕਲਾਇੰਟ ਨਾਲ ਗੱਲ ਕਰਦੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਮੁੜ TCP/IP ਖੇਤਰ ਵਿੱਚ ਆ ਜਾਂਦੇ ਹੋ—ਕਨੈਕਸ਼ਨ, ਟਾਈਮਆਉਟ, ਰੀਟ੍ਰਾਈਜ਼ ਅਤੇ ਸਭ ਕੁਝ।
ਜਦ ਡਿਵੈਲਪਰ "ਨੈੱਟਵਰਕ" ਦੱਸਦੇ ਹਨ, ਉਹ ਅਕਸਰ ਦੋ ਮੁੱਖ ਟਰਾਂਸਪੋਰਟ ਵਿੱਚੋਂ ਚੁਣਦਾ ਹੈ: TCP ਜਾਂ UDP। ਦੋਹੁੰ IP ਦੇ ਉੱਪਰ ਬੈਠਦੇ ਹਨ, ਪਰ ਵੱਖ-ਵੱਖ ਤਰਜੀਹਾਂ ਕਰਦੇ ਹਨ।
TCP ਉਸ ਵੇਲੇ ਵਧੀਆ ਹੁੰਦਾ ਹੈ ਜਦ ਤੁਹਾਨੂੰ ਡੇਟਾ ਕ੍ਰਮ ਵਿੱਚ, ਬਿਨਾ ਖਾਲੀ ਜਗ੍ਹਾ ਆਉਣਾ ਲਾਜ਼ਮੀ ਹੋਵੇ। ਸੋਚੋ: ਵੈਬ ਪੇਜ, API ਕਾਲ, ਫਾਈਲ ਟ੍ਰਾਂਸਫਰ, ਡੇਟਾਬੇਸ ਕਨੈਕਸ਼ਨ।
ਇਸ ਲਈ ਦੈਨੀਕ ਇੰਟਰਨੈੱਟ ਉਨ੍ਹਾਂ 'ਤੇ منحصر ਹੈ—HTTPS TCP 'ਤੇ ਚੱਲਦਾ ਹੈ (TLS ਰਾਹੀਂ), ਅਤੇ ਜ਼ਿਆਦਾਤਰ request/response ਸਾਫਟਵੇਅਰ TCP ਦੇ ਵਿਹਾਰ ਨੂੰ ਮੰਨਦਾ ਹੈ।
ਕੈਚ: TCP ਦੀ ਭਰੋਸੇਯੋਗਤਾ ਲੈਟੈਂਸੀ ਨੂੰ ਵਧਾ ਸਕਦੀ ਹੈ। ਜੇ ਇੱਕ ਪੈਕੇਟ ਗੁੰਮ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਦ ਬਾਅਦ ਵਾਲੇ ਪੈਕੇਟਾਂ ਨੂੰ ਉਸ ਖ਼ਾਲੀ ਹਿੱਸੇ ਦੀ ਭਰਪਾਈ ਲਈ ਰੋਕਿਆ ਜਾ ਸਕਦਾ ਹੈ ("head-of-line blocking"). ਇੰਟਰਐਕਟਿਵ ਤਜਰਬੇ ਲਈ, ਉਹ ਇੰਤਜ਼ਾਰ ਕਈ ਵਾਰ ਇੱਕ ਛੋਟੀ ਗਲਤੀ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਖਰਾਬ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ।
UDP ਜ਼ਿਆਦਾ-ਕੁਝ ਇਸ ਤਰ੍ਹਾਂ ਹੈ: "ਸੁਨੇਹਾ ਭੇਜੋ ਅਤੇ ਆਸ ਕਰੋ ਕਿ ਆ ਜਾਵੇ"। UDP 'ਤੇ ordering, retransmission ਜਾਂ congestion handling ਨਾਹੀਂ ਹੁੰਦੀ।
ਡਿਵੈਲਪਰ UDP ਨੂੰ ਉਸ ਵੇਲੇ ਚੁਣਦੇ ਹਨ ਜਦ ਸਮਾਂ-ਸੁਚੀਤਾ ਬਹੁਤ ਜ਼ਿਆਦਾ ਮਹੱਤਵਪੂਰਨ ਹੋਵੇ, ਜਿਵੇਂ live audio/video, ਗੇਮਿੰਗ, ਜਾਂ ਰੀਅਲ-ਟਾਈਮ ਟੈਲੀਮੇਟਰੀ। ਇਨ੍ਹਾਂ ਐਪਾਂ ਵਿੱਚ ਬਹੁਤ ਵਾਰੀ ਆਪਣੀ ਹਲਕੀ ਭਰੋਸੇਯੋਗਤਾ (ਜਾਂ ਬਿਲਕੁਲ ਨਹੀਂ) ਬਣਾਈ ਜਾਂਦੀ ਹੈ ਜੋ ਯੂਜ਼ਰ ਸੱਚਮੁਚ ਮਹਿਸੂਸ ਕਰਦਾ ਹੈ।
ਆਧੁਨਿਕ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਉਦਾਹਰਨ: QUIC UDP 'ਤੇ ਚੱਲਦਾ ਹੈ, ਜੋ ਐਪਸ ਨੂੰ ਤੇਜ਼ ਕਨੈਕਸ਼ਨ ਸੈੱਟਅਪ ਦੇਣ ਅਤੇ ਕੁਝ TCP ਸੀਮਾਵਾਂ ਤੋਂ ਬਚਣ ਵਿੱਚ ਸਹਾਇਤਾ ਕਰਦਾ—ਬਿਨਾ ਹੇਠਾਂਲੇ IP ਨੈੱਟਵਰਕ ਵਿੱਚ ਬਦਲਾਅ ਕੀਤੇ।
ਆਧਾਰ 'ਤੇ ਚੁਣੋ:
TCP ਨੂੰ ਅਕਸਰ "ਭਰੋਸੇਯੋਗ" ਕਿਹਾ ਜਾਂਦਾ ਹੈ, ਪਰ ਇਸਦਾ ਅਰਥ ਇਹ ਨਹੀਂ ਕਿ ਤੁਹਾਡੀ ਐਪ ਹਮੇਸ਼ਾ ਭਰੋਸੇਯੋਗ ਮਹਿਸੂਸ ਕਰੇਗੀ। TCP ਬਹੁਤ ਸਾਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਤੋਂ ਬਚਾ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਨਿਯਮਤ ਸਮਾਂ, ਨਿਰੰਤਰ throughput, ਜਾਂ ਇੱਕ ਚੰਗਾ ਯੂਜ਼ਰ ਅਨੁਭਵ ਨਹੀਂ ਗਰੰਟੀ ਕਰ ਸਕਦਾ ਜਦੋਂ ਦੋ ਸਿਸਟਮਾਂ ਦਰਮਿਆਨ ਰਸਤਾ ਅਸਥਿਰ ਹੋਵੇ।
ਪੈਕੇਟ ਲਾਸ TCP ਨੂੰ ਰੀਟ੍ਰਾਂਸਮਿਟ ਕਰਨ 'ਤੇ ਮਜਬੂਰ ਕਰਦਾ ਹੈ। ਭਰੋਸੇਯੋਗਤਾ ਬਚ ਜਾਂਦੀ ਹੈ, ਪਰ ਪ੍ਰਦਰਸ਼ਨ ਡਿੱਗ ਸਕਦਾ ਹੈ।
ਉੱਚ ਲੈਟੈਂਸੀ (ਲੰਮਾ round-trip ਸਮਾਂ) ਹਰ request/response ਚੱਕਰ ਨੂੰ ਸੌਝਾ ਕਰ ਦਿੰਦਾ ਹੈ, ਭਾਵੇਂ ਕੋਈ ਪੈਕੇਟ ਗੁੰਮ ਨਾ ਹੋਏ।
Bufferbloat ਉਸ ਵੇਲੇ ਹੁੰਦਾ ਹੈ ਜਦ ਰਾਊਟਰ ਜਾਂ OS ਕਤਾਰਾਂ ਬਹੁਤ ਜ਼ਿਆਦਾ ਡੇਟਾ ਰੱਖਣ ਲੱਗਦੇ ਹਨ। TCP ਘੱਟ ਲਾਸ ਵੇਖਦਾ ਹੈ, ਪਰ ਯੂਜ਼ਰ ਨੂੰ ਵੱਡੇ ਦੇਰੀ ਅਤੇ "ਲੈਗ" ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ।
ਗਲਤ MTU ਵਿਵਸਥਾ ਫ੍ਰੈਗਮੈਂਟੇਸ਼ਨ ਜਾਂ blackholing ਪੈਦਾ ਕਰ ਸਕਦੀ ਹੈ (ਜਦ ਪੈਕੇਟ "ਬਹੁਤ ਵੱਡੇ" ਹੋਣ 'ਤੇ ਗੁਮ ਹੋ ਜਾਂਦੇ ਹਨ), ਜਿਸ ਨਾਲ ਸਮਝਦਾਰ ਫੇਲਾਂ ਹੁੰਦੀਆਂ ਹਨ ਜੋ ਰੈਂਡਮ ਟਾਈਮਆਉਟ ਵਾਂਗ ਲੱਗਦੀਆਂ ਹਨ।
ਸਾਫ-ਸੁਥਰੇ "ਨੈੱਟਵਰਕ ਐਰਰ" ਦੀ ਥਾਂ, ਅਕਸਰ ਤੁਸੀਂ ਵੇਖੋਂਗੇ:
ਇਹ ਲੱਛਣ ਸੱਚ ਹਨ, ਪਰ ਉਹ ਸਦਾ ਤੁਹਾਡੇ ਕੋਡ ਕਰਕੇ ਨਹੀਂ; ਅਕਸਰ TCP ਆਪਣਾ ਕੰਮ ਕਰ ਰਿਹਾ ਹੁੰਦਾ ਹੈ—ਰੀਟ੍ਰਾਂਸਮਿਟ, ਬੈਕ ਆਫ਼, ਅਤੇ ਉਡੀਕ—ਜਦ ਕਿ ਤੁਹਾਡੀ ਐਪ ਦੀ ਘੜੀ ਟਿਕ-ਟਿਕ ਕਰਦੀ ਰਹਿੰਦੀ ਹੈ।
ਮੁੱਢਲਾ ਕਲਾਸੀਫਿਕੇਸ਼ਨ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ: ਸਮੱਸਿਆ ਜ਼ਿਆਦਾ ਤੌਰ 'ਤੇ ਲਾਸ, ਲੈਟੈਂਸੀ, ਜਾਂ ਰਸਤੇ ਦੇ ਬਦਲਾਅ ਵਿੱਚੋਂ ਕਿਹੜੀ ਹੈ?
ਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਉਂਦੇ ਹੋ (ਉਦਾਹਰਨ ਲਈ, Koder.ai ਵਿੱਚ ਇੱਕ ਸਰਵਿਸ ਪ੍ਰੋਟੋਟਾਈਪ ਕਰਕੇ ਅਤੇ ਹੋਸਟ ਕਰਕੇ), ਤਾਂ ਇਹ ਵORTH ਹੈ ਕਿ ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਇਹ ਅਬਜ਼ਰਵੇਬਿਲਟੀ ਮੁਢਲੇ ਕੰਮਾਂ ਵਿੱਚ ਸ਼ਾਮਿਲ ਕਰੋ—ਕਿਉਂਕਿ ਨੈੱਟਵਰਕ ਫੇਲ੍ਹ ਹੋਣ ਦੀਆਂ ਸੂਚਨਾਵਾਂ ਪਹਿਲਾਂ ਟਾਈਮਆਉਟਾਂ ਅਤੇ ਰੀਟ੍ਰਾਈਜ਼ਾਂ ਦੇ ਰੂਪ ਵਿੱਚ ਦਿਖਾਈ ਦਿੰਦੀਆਂ ਹਨ, ਨਾ ਕਿ ਸਾਫ਼ ਐਕਸੈਪਸ਼ਨ ਵਾਂਗ।
ਨੈੱਟਵਰਕ ਮਿਟਿਆ-ਕਰਦੇ ਰਹਿੰਦਾ ਹੈ। ਟਾਈਮਆਉਟ, ਏਕਸਪੋਨੈਂਸ਼ਲ ਬੈਕ ਆਫ਼ ਨਾਲ ਰੀਟ੍ਰਾਈਜ਼ ਵਰਤੋ, ਅਤੇ ਓਪਰੇਸ਼ਨਾਂ ਨੂੰ idempotent ਬਨਾਓ ਤਾਂ ਕਿ ਰੀਟ੍ਰਾਈਜ਼ਾਂ ਤੋਂ ਦੋਹਰਾਉਂ ਨਾ ਹੋਵੇ, ਡੁੱਠ-ਸੰਸਕਾਰ ਨਹੀਂ ਬਣਦਾ।
TCP/IP ਇੱਕ ਸਾਂਝੀ ਨੈੱਟਵਰਕਿੰਗ ਨਿਯਮਾਂ ਦਾ ਸੈੱਟ ਹੈ ਜੋ ਵੱਖ-ਵੱਖ ਨੈੱਟਵਰਕਾਂ ਨੂੰ ਇਕੱਠੇ ਕੰਮ ਕਰਨ ਯੋਗ ਬਣਾਉਂਦਾ ਹੈ।
ਇਹ ਇਸ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਇਹ ਬੇਵੱਕੂਫ਼, ਵੱਖ-ਵੱਖ ਲਿੰਕ (Wi‑Fi, LTE, fiber, satellite) ਨੂੰ ਸੌਫਟਵੇਅਰ ਲਈ ਵਰਤਣ ਯੋਗ ਬਣਾਉਂਦਾ ਹੈ—ਤਾਂ ਜੋ ਐਪਸ ਬਿਨਾ ਭੌਤਿਕ ਨੈੱਟਵਰਕ ਵਿਵਰਣਾਂ ਦੇ ਸਮਝਣ ਦੇ, ਬਾਈਟ ਭੇਜ ਕੇ ਜਵਾਬ ਲੈ ਸਕਣ।
Bob Kahn ਨੇ “internetworking” ਦਾ ਵਿਚਾਰ ਅੱਗੇ ਵਧਾਇਆ: ਵੱਖ-ਵੱਖ ਇੰਟਰਨਲ ਹਾਰਡਵੇਅਰ ਜਾਂ ਡਿਜ਼ਾਈਨ ਨੂੰ ਬਦਲਣ ਬਗੈਰ ਨੈੱਟਵਰਕਾਂ ਨੂੰ ਇਕੱਠਾ ਜੋੜਨਾ।
ਉਸ ਕੰਮ, ਜਿਸ ਵਿੱਚ Vint Cerf ਵਰਗੇ ਸਹਿਯੋਗੀ ਸ਼ਾਮਿਲ ਸਨ, ਨੇ ਉਹ ਵੱਖਰਾ ਵਿਭਾਜਨ ਬਣਾਇਆ ਕਿ IP ਨੈੱਟਵਰਕਾਂ ਵਿੱਚ ਪਤੇ ਅਤੇ ਫਾਰਵਰਡਿੰਗ ਦਾ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ TCP ਐਪਲੀਕੇਸ਼ਨ ਲਈ ਭਰੋਸੇਯੋਗ ਡਿਲਿਵਰੀ ਦਿੰਦਾ ਹੈ।
ਪੈਕੇਟ ਸਵਿੱਚਿੰਗ ਇੱਕ ਸੁਧਾਰਤ ਤਰੀਕਾ ਹੈ ਜਿਸ ਵਿੱਚ ਇੱਕ ਸੁਨੇਹੇ ਨੂੰ ਛੋਟੇ ਪੈਕੇਟਾਂ ਵਿੱਚ ਤੋੜਿਆ ਜਾਂਦਾ ਹੈ ਜੋ ਸਵਤੰਤਰ ਢੰਗ ਨਾਲ ਗੰਤਵ੍ਯ ਤੱਕ ਪਹੁੰਚ ਸਕਦੇ ਹਨ।
ਫਾਇਦੇ:
IP ਇੱਕ ਸਿਰਫ਼ ਇੱਕ ਕੰਮ ਦੀ ਗਰੰਟੀ ਕਰਦਾ ਹੈ: ਪੈਕੇਟਾਂ ਨੂੰ ਇੱਕ ਡੈਸਟਿਨੇਸ਼ਨ ਪਤੇ ਵੱਲ ਅੱਗੇ ਵਧਾਉਣਾ। ਇਹ ਡਿਲਿਵਰੀ, ਆਰਡਰ ਜਾਂ ਸਮੇਂ ਦੀ ਗਰੰਟੀ ਨਹੀਂ ਦਿੰਦਾ।
ਇਹ "best effort" ਮਾਡਲ ਗਲੋਬਲ ਪੱਧਰ 'ਤੇ ਸਕੇਲ ਹੋ ਜਾਂਦਾ ਹੈ ਕਿਉਂਕਿ ਰਾਊਟਰ ਸਧਾਰਨ ਤੇਜ਼ ਫਾਰਵਰਡਿੰਗ 'ਤੇ ਧਿਆਨ ਰੱਖਦੇ ਹਨ, ਅਤੇ ਨਵੀਆਂ ਨੈੱਟਵਰਕਾਂ ਆਸਾਨੀ ਨਾਲ ਜੁੜ ਸਕਦੀਆਂ ਹਨ।
TCP IP ਦੇ ਬੇਸ੍ਟ-ਏਫੋਰਟ ਪੈਕੇਟਾਂ ਨੂੰ ਐਪਲੀਕੇਸ਼ਨ-ਫਰੈਂਡਲੀ ਕ੍ਰਮਿਕ ਬਾਈਟ ਸਟ੍ਰੀਮ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।
ਇਹ ਇਹਨਾਂ ਤਰੀਕਿਆਂ ਨਾਲ ਕਰਦਾ ਹੈ:
ਉਹ ਵੱਖ-ਵੱਖ ਸਮੱਸਿਆਵਾਂ ਹੱਲ ਕਰਦੇ ਹਨ:
ਜੋਡੀਦਾਰੀ ਦੋਹਾਂ ਦੀ ਲੋੜ ਹੈ: ਤੇਜ਼ ਸੈਂਡਰ ਨੂੰ ਰਿਸੀਵਰ ਅਤੇ ਨੈੱਟਵਰਕ ਦੋਹਾਂ ਦੀ ਇੱਜ਼ਤ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ।
ਲੇਅਰਿੰਗ ਇਸ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿ ਹਰ ਪੱਧਰ ਇੱਕ ਖਾਸ ਜ਼ਿੰਮੇਵਾਰੀ ਨਿਭਾਂਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਇੱਕ-ਇਕ ਆਲੇ-ਦੁਆਲੇ ਸਿਸਟਮ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਉਣ ਦੀ ਜ਼ਰੂਰਤ ਨਹੀਂ ਰਹਿੰਦੀ।
ਡਿਵੈਲਪਰਾਂ ਲਈ ਇਹ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ ਹਰ ਨੈੱਟਵਰਕ ਕਿਸਮ ਲਈ ਆਪਣੀ ਐਪ ਨੂੰ ਮੁੜ ਡਿਜ਼ਾਈਨ ਕਰਨ ਦੀ ਲੋੜ ਤੋਂ ਬਚ ਸਕਦੇ ਹੋ।
ਐਂਡ-ਟੂ-ਐਂਡ ਸਿਧਾਂਤ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਨੈੱਟਵਰਕ ਕੋਰ (ਰਾਊਟਰ) ਸਧਾਰਨ ਰਹੇ ਅਤੇ "ਸਮਾਰਟ" ਕੰਮ ਐਂਡਪੌਇੰਟਸ (ਡਿਵਾਈਸ/ਐਪ) ਤੇ ਛੱਡੇ ਜਾਣ।
ਅਸਲ ਪ੍ਰਭਾਵ ਇਹ ਹੈ ਕਿ ਰੀਲਾਇਬਿਲਿਟੀ, ਟਾਈਮਆਉਟ, ਰੀਟ੍ਰਾਈਜ਼ ਅਤੇ ਗੁਪਤਤਾ ਜਿਵੇਂ ਕੰਮ ਐਪ ਅਤੇ ਓਐਸ ਲੈਅਰ ਤੇ ਸੰਭਾਲੇ ਜਾਂਦੇ ਹਨ, ਕਿਉਂਕਿ ਨੈੱਟਵਰਕ ਹਰ ਐਪ ਦੀ ਲੋੜ ਅਨੁਸਾਰ ਵਿਅਕਤੀਗਤ ਤਰੀਕੇ ਨਾਲ ਕਰ ਸਕਦਾ ਨਹੀਂ।
Latency ਰਾਊਂਡ-ਟ੍ਰਿਪ ਸਮਾਂ ਹੈ; ਇਹ ਚੈਟੀ ਪੈਟਰਨ (ਛੋਟੇ-ਛੋਟੇ ਬੇਨਤੀ) ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾਉਂਦਾ ਹੈ।
Throughput ਬਾਈਟ ਪ੍ਰਤੀ ਸਕਿੰਟ ਹੈ; ਇਹ ਵੱਡੀਆਂ ਫਾਇਲਾਂ/ਟ੍ਰਾਂਸਫਰਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ।
ਕੁਝ ਅਮਲੀ ਸੁਝਾਅ:
ਚੁਣੋ ਇਸ ਅਧਾਰ 'ਤੇ:
ਕੁੱਲ ਨਿਯਮ: ਜੇ ਤੁਹਾਡੀ ਐਪ request/response ਹੈ ਅਤੇ correctness ਪਹਿਲਾਂ ਹੈ, TCP (ਜਾਂ HTTP/3 ਲਈ QUIC) ਅਮੂਮਨ ਸ਼ੁਰੂਆਤ ਦਾ ਨੁਕਤਾ ਹੈ।