ਫਾਰਵਰਡ ਪ੍ਰੌਕਸੀ ਸਟ੍ਰੀਮਿੰਗ ਬਨਾਮ ਪੂਰੀ-ਪ੍ਰਤੀਕਿਰਿਆ ਬਫਰਿੰਗ

ਜਦੋਂ ਡਾਊਨਲੋਡ ਉਡੀਕਦਾ ਦਿਸੇ ਤਾਂ ਤਿੰਨ ਘਟਨਾਵਾਂ ਵੱਖ ਕਰੋ: ਪ੍ਰਤੀਕਿਰਿਆ ਹੈਡਰ ਆਉਣਾ, ਬਾਡੀ ਬਾਈਟ ਆਉਣਾ, ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਨਤੀਜਾ ਵਰਤਣ ਜਾਂ ਦਿਖਾਉਣ ਦੇ ਸਮਰੱਥ ਹੋਣਾ। ਸਿਰਫ਼ ਸਪਿਨਰ ਇਹ ਨਹੀਂ ਦੱਸ ਸਕਦਾ ਕਿ ਕਿਹੜੀ ਚੀਜ਼ ਦੇਰੀ ਨਾਲ ਹੈ।

ਆਮ ਸਟ੍ਰੀਮਿੰਗ ਪੜਾਅ ਇੱਕ-ਦੂਜੇ ਉੱਤੇ ਆ ਸਕਦੇ ਹਨ:

origin produces a chunk → proxy forwards bytes → client consumes them

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

ਹੌਲੀ ਕਲਾਇੰਟ ਆਊਟਪੁੱਟ ਕਤਾਰਾਂ ਭਰ ਦੇਵੇ ਤਾਂ ਬੈਕਪ੍ਰੈਸ਼ਰ ਉੱਪਰਲੀ ਪੜ੍ਹਾਈ ਨੂੰ ਅਸਥਾਈ ਤੌਰ 'ਤੇ ਰੋਕ ਸਕਦਾ ਹੈ। Content-Length ਵੀ ਪੂਰੀ ਬਫਰਿੰਗ ਤੋਂ ਬਿਨਾਂ ਲੰਬਾਈ ਦਿੰਦਾ ਹੈ। HTTP/1.1 chunked ਐਨਕੋਡਿੰਗ ਕ੍ਰਮਿਕ ਡਿਲਿਵਰੀ ਦੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ, ਪਰ ਜੇ ਪਹਿਲਾਂ ਦਾ ਹਿੱਸਾ ਡੇਟਾ ਰੋਕੀ ਰੱਖੇ ਤਾਂ ਘੱਟ ਲੈਟੈਂਸੀ ਦਾ ਵਾਅਦਾ ਨਹੀਂ ਕਰ ਸਕਦੀ।

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

ਸਫਲ CONNECT ਤੋਂ ਬਾਅਦ ਆਮ ਪ੍ਰੌਕਸੀ ਟਨਲ ਕੀਤੀ ਫਾਈਲ ਦੀ ਅੰਤਿਮ ਲੰਬਾਈ ਜਾਣੇ ਬਿਨਾਂ ਸੇਵਾ ਸਟ੍ਰੀਮ ਰੀਲੇ ਕਰਦਾ ਹੈ। ਬਫਰ ਜਾਂ ਟਾਈਮਆਊਟ ਸੈਟਿੰਗਾਂ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਉੱਪਰ ਦਿੱਤੀ ਪਹਿਲੀ ਗੁੰਮ ਘਟਨਾ ਦੀ ਪਾਲਣਾ ਕਰੋ। ਜਦੋਂ curl ਨਿਰੀਖਕ ਹੁੰਦਾ ਹੈ, ਇਸ ਦਾ no-buffer ਵਿਕਲਪ ਸਥਾਨਕ ਆਊਟਪੁੱਟ ਪੜਾਅ ਬਦਲਦਾ ਹੈ।