Squid ਕਦੋਂ APT ਪੈਕੇਜ ਕੈਸ਼ ਕਰ ਸਕਦਾ ਹੈ
ਪੈਕੇਜ ਬੇਨਤੀਆਂ ਦੇ Squid ਹਿੱਟ ਬਣਨ ਦੀ ਉਮੀਦ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ HTTP ਆਵਾਜਾਈ, ਕੈਸ਼ ਸਟੋਰੇਜ, ਆਬਜੈਕਟ ਆਕਾਰ ਅਤੇ APT ਦੀਆਂ cache-control ਸੈਟਿੰਗਾਂ ਦੀ ਜਾਂਚ ਕਰੋ।
APT ਅਤੇ aptitude HTTP ਰਾਹੀਂ ਰਿਪੋਜ਼ਟਰੀ ਫਾਈਲਾਂ ਲੈ ਸਕਦੇ ਹਨ। Squid ਯੋਗ HTTP ਜਵਾਬ ਕੈਸ਼ ਕਰ ਸਕਦਾ ਹੈ; ਕਲਾਇੰਟ ਦਾ ਵੈੱਬ ਬ੍ਰਾਊਜ਼ਰ ਹੋਣਾ ਜ਼ਰੂਰੀ ਨਹੀਂ।
Squid 6 ਜਾਂ 7 ਤੈਨਾਤੀ ਵਿੱਚ, ਜਦੋਂ ਹਰ ਪੈਕੇਜ ਟ੍ਰਾਂਸਫਰ ਅਜੇ ਵੀ ਸਰੋਤ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ, ਇਹ ਇਨਪੁਟ ਜਾਂਚੋ:
- ਡਾਊਨਲੋਡ HTTP ਵਰਤਦਾ ਹੈ, ਜਾਂ Squid ਕੋਲ HTTP ਵਟਾਂਦਰੇ ਤੱਕ ਹੋਰ ਤਰੀਕੇ ਨਾਲ ਪਹੁੰਚ ਹੈ। ਸਿਰਫ਼ HTTPS CONNECT ਸੁਰੰਗ ਪੈਕੇਜ ਜਵਾਬ ਨੂੰ ਕੈਸ਼ ਲਈ ਜ਼ਾਹਰ ਨਹੀਂ ਕਰਦੀ।
- ਕੈਸ਼ ਵਿੱਚ ਢੁਕਵਾਂ ਸਟੋਰੇਜ ਕਨਫਿਗਰ ਹੈ। ਸਫਲ ਫਾਰਵਰਡਿੰਗ ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦੀ ਕਿ ਡਿਸਕ ਕੈਸ਼ ਮੌਜੂਦ ਹੈ।
- ਆਰਕਾਈਵ ਲਾਗੂ ਕੈਸ਼ ਡਾਇਰੈਕਟਰੀ ਦੇ ਵੱਧ ਤੋਂ ਵੱਧ ਆਬਜੈਕਟ ਆਕਾਰ ਵਿੱਚ ਫਿੱਟ ਹੁੰਦਾ ਹੈ। ਛੋਟਾ ਮੈਟਾਡੇਟਾ ਅਤੇ ਵੱਡਾ .deb ਵੱਖਰੇ ਨਤੀਜੇ ਦੇ ਸਕਦੇ ਹਨ।
- ਬੇਨਤੀ ਅਤੇ ਜਵਾਬ ਆਪਣੀ cache-control ਨੀਤੀ ਅਧੀਨ ਸਟੋਰੇਜ ਅਤੇ ਮੁੜ ਵਰਤੋਂ ਦੀ ਆਗਿਆ ਦਿੰਦੇ ਹਨ।
APT Acquire::http::No-Cache, Max-Age ਅਤੇ No-Store ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। No-Store ਬੇਨਤੀ ਕੀਤੀਆਂ ਆਰਕਾਈਵ ਫਾਈਲਾਂ ਨੂੰ ਸਟੋਰ ਹੋਣ ਤੋਂ ਰੋਕ ਸਕਦਾ ਹੈ। No-Cache ਸਟੋਰ ਕੀਤੇ ਜਵਾਬ ਦੀ ਮੁੜ ਵਰਤੋਂ ਤੋਂ ਪਹਿਲਾਂ ਮੁੜ-ਪ੍ਰਮਾਣਿਕਤਾ ਮੰਗਦਾ ਹੈ। ਪ੍ਰਭਾਵੀ APT ਕਨਫਿਗਰੇਸ਼ਨ ਅਤੇ Squid ਦੀ ਨੀਤੀ ਦੋਵੇਂ ਜਾਂਚੋ।
ਉਹੀ ਪੂਰਾ URL ਤੁਲਨਾ ਕਰੋ ਅਤੇ access.log ਵਿੱਚ ਕੈਸ਼ ਨਤੀਜਾ ਜਾਂਚੋ। ਵੱਖਰੇ ਮਿਰਰ ਹੋਸਟ, ਬਦਲੇ ਹੋਏ ਰਿਪੋਜ਼ਟਰੀ ਰਾਹ ਜਾਂ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਕੈਸ਼ ਕੀਤਾ ਪੈਕੇਜ ਇਸ ਦਾ ਅਰਥ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਦੋ ਇੰਸਟਾਲ ਕਦੇ ਵੀ ਇੱਕੋ ਨੈੱਟਵਰਕ ਆਬਜੈਕਟ ਦੀ ਬੇਨਤੀ ਨਹੀਂ ਕਰਦੇ।
ਰਿਪੋਜ਼ਟਰੀ ਮਿਰਰ ਰਿਪੋਜ਼ਟਰੀ ਸਮੱਗਰੀ ਨੂੰ ਜਾਣਬੁੱਝ ਕੇ ਕਾਇਮ ਰੱਖਦਾ ਹੈ, ਸਿਰਫ਼ ਮੰਗ-ਆਧਾਰਿਤ HTTP ਕੈਸ਼ ਮੁੜ ਵਰਤੋਂ 'ਤੇ ਨਿਰਭਰ ਕਰਨ ਦੀ ਬਜਾਏ।