ਫਾਰਵਰਡ ਪ੍ਰੌਕਸੀ TCP ਸੈਗਮੈਂਟ ਦੀਆਂ ਹੱਦਾਂ ਨਹੀਂ ਸੰਭਾਲਦੀ

ਮੰਨ ਲਓ ਕਿ Squid ਵਿਚੋਂ ਲੰਘਣ ਤੋਂ ਬਾਅਦ HTTP ਜਵਾਬ ਕਈ ਕੈਪਚਰ ਕੀਤੇ TCP ਸੈਗਮੈਂਟਾਂ ਵਿੱਚ ਦਿਖਦਾ ਹੈ। ਇਹ ਆਮ TCP ਵਿਵਹਾਰ ਹੋ ਸਕਦਾ ਹੈ, ਜਵਾਬ ਗਲਤ ਢੰਗ ਨਾਲ ਵੰਡਿਆ ਗਿਆ ਹੋਣ ਦਾ ਸਬੂਤ ਨਹੀਂ।

ਫਾਰਵਰਡ ਪ੍ਰੌਕਸੀ ਕੋਲ ਆਮ ਤੌਰ ’ਤੇ ਦੋ ਕਨੈਕਸ਼ਨ ਹੁੰਦੇ ਹਨ:

client ⇄ TCP connection A ⇄ proxy ⇄ TCP connection B ⇄ origin

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

ਵੱਖ ਰੱਖਣ ਯੋਗ ਤਿੰਨ ਹੱਦਾਂ

ਇੱਕ ਪੜ੍ਹਤ ਵਿੱਚ ਹੈਡਰ ਦਾ ਕੋਈ ਹਿੱਸਾ, ਪੂਰਾ ਹੈਡਰ ਸਮੇਤ ਬਾਡੀ ਬਾਈਟ, ਜਾਂ ਇੱਕ ਤੋਂ ਵੱਧ ਐਪਲੀਕੇਸ਼ਨ-ਪੱਧਰ ਦੀਆਂ ਹੱਦਾਂ ਪਾਰ ਕਰਨ ਵਾਲਾ ਡੇਟਾ ਹੋ ਸਕਦਾ ਹੈ। TCP “HTTP ਜਵਾਬ ਦਾ ਅੰਤ” ਸਫਲ ਪੜ੍ਹਤ ਦੇ ਅੰਤ ਨਾਲ ਨਹੀਂ ਜੋੜਦਾ।

ਇਸ ਲਈ HTTP/1.1 ਪਾਰਸਰ ਹੈਡਰ ਇਕੱਠੇ ਕਰਕੇ ਲਾਗੂ ਬਾਡੀ-ਫਰੇਮਿੰਗ ਨਿਯਮ ਵਰਤਦਾ ਹੈ, ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਲੰਬਾਈ, ਟ੍ਰਾਂਸਫਰ ਕੋਡਿੰਗ ਜਾਂ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਕਨੈਕਸ਼ਨ ਬੰਦ ਹੋਣਾ ਸ਼ਾਮਲ ਹੈ। HTTP/2 ਫਰੇਮ ਇੱਕ ਪ੍ਰੋਟੋਕੋਲ ਬਣਤਰ ਹੈ ਜੋ ਆਪ ਹੀ TCP ਸੈਗਮੈਂਟ ਪਾਰ ਕਰ ਸਕਦੀ ਹੈ; ਇਹ ਨੈੱਟਵਰਕ ਪੈਕਟ ਦਾ ਦੂਜਾ ਨਾਮ ਨਹੀਂ।

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

ਖਰਾਬੀ ਦੀ ਜਾਂਚ ਕਰਦੇ ਸਮੇਂ ਦੁਬਾਰਾ ਜੋੜੇ ਐਪਲੀਕੇਸ਼ਨ ਡੇਟਾ ਦੀ ਤੁਲਨਾ ਕਰੋ। ਪੈਕਟ ਗਿਣਤੀਆਂ ਦੀ ਤੁਲਨਾ ਕਰਨਾ ਜਾਂ ਦੋਵੇਂ ਪਾਸਿਆਂ ਇੱਕੋ ਪੈਕਟ ਲੰਬਾਈ ਦੀ ਆਸ ਕਰਨਾ TCP ਤੋਂ ਉਹ ਹੱਦ-ਗਾਰੰਟੀ ਮੰਗਣਾ ਹੈ ਜੋ ਇਹ ਨਹੀਂ ਦਿੰਦਾ।