Bakit Hindi Pinupuno ng CONNECT Traffic ang Object Cache ng Squid

Ang karaniwang CONNECT tunnel ay nagbibigay sa Squid ng mga naka-encrypt na byte sa halip na tugon ng website na maaaring i-cache. Kaya maaaring magdagdag ng maraming traffic ang malaking HTTPS download nang walang naidaragdag na magagamit-muling entry sa object cache.

Maaaring itala ng Squid ang destinasyon ng tunnel, tagal nito, at bilang ng mga byte. Hindi nito natatanggap ang panloob na URL path, mga cache directive, representation, at validator bilang karaniwang HTTP message na maaari nitong iimbak at gamitin muli. Hindi maihahayag ang mga ito sa pagdaragdag ng disk space o pagpapalaki ng limitasyon sa laki ng object.

Suriin ang mga request method at tala ng tunnel bago sabihing sira ang caching. Maaaring magsabay ang malalaking paglilipat at kaunting paggamit muli ng mga object sa workload na pinangingibabawan ng CONNECT. Para sa tunay na pagsusuri ng cache, gumamit ng HTTP resource na kontrolado mo, may tahasang cache header, at may kilalang nilalaman; tiyaking ang sinusubok ay ang object processing path ng Squid at hindi ang tunnel, cache ng browser, o CDN ng destinasyon.

Ang TLS papunta sa proxy ay hiwalay na layer. Pagkatapos tapusin ang TLS connection sa sarili nitong listener, maaaring magproseso ang Squid ng karaniwang request sa isang HTTP destination. Kung sa halip ay humiling ang koneksiyong iyon ng CONNECT patungo sa HTTPS, nananatiling hiwalay at hindi nakikita ang nilalaman ng panloob na TLS ng destinasyon.

Binabago ng HTTPS interception ang mga kinakailangan sa tiwala sa certificate, awtorisasyon, at privacy. Hindi ito karaniwang pagsasaayos ng espasyo ng cache, at hindi kailangan ng normal na forward proxy ang interception upang gumana.