Hvorfor CONNECT-trafikk ikke fyller Squids objektbuffer
Hvorfor en vanlig HTTPS-tunnel kan overføre mange byte uten å gi en forward proxy gjenbrukbare HTTP-svarobjekter.
En vanlig CONNECT-tunnel gir Squid krypterte byte fremfor et nettstedssvar som kan mellomlagres. En stor HTTPS-nedlasting kan derfor gi mye trafikk uten en gjenbrukbar oppføring i objektbufferen.
Squid kan registrere tunnelens destinasjon, varighet og byteantall. Det mottar ikke den indre URL-stien, bufferinstruksjoner, representasjon og validatorer som vanlige HTTP-meldinger det kan lagre og gjenbruke. Mer diskplass eller en større objektgrense kan ikke avdekke dem.
Kontroller forespørselsmetoder og tunneloppføringer før du erklærer mellomlagring ødelagt. En CONNECT-dominert arbeidsmengde passer med store overføringer og lite objektgjenbruk. Bruk til en faktisk buffertest en HTTP-ressurs du kontrollerer med eksplisitte cache-headere og kjent innhold; bekreft at du tester Squids objektvei, ikke en tunnel, nettleserbuffer eller destinasjonens CDN.
TLS til proxyen er et separat lag. Etter å ha terminert sin egen TLS-lytter kan Squid behandle en vanlig HTTP-destinasjonsforespørsel. Ber forbindelsen i stedet om CONNECT til HTTPS, forblir den indre destinasjons-TLS-en separat og ugjennomsiktig.
HTTPS-avskjæring endrer krav til sertifikattillit, autorisasjon og personvern. Det er ingen vanlig justering av bufferplass, og en normal forward proxy trenger ikke avskjæring for å fungere.