Miért nem tölti a CONNECT a Squid objektumgyorsítótárát
Miért vihet át egy szokásos HTTPS-alagút sok bájtot anélkül, hogy a proxynak újrahasználható HTTP-válaszobjektumokat adna.
Egy szokásos CONNECT-alagút titkosított bájtokat ad a Squidnek, nem gyorsítótárazható webhelyválaszt. Egy nagy HTTPS-letöltés ezért sok forgalmat hozhat létre újrahasználható objektumbejegyzés nélkül.
A Squid rögzítheti az alagút célját, időtartamát és bájtszámát. A belső URL-útvonalat, gyorsítótár-utasításokat, reprezentációt és ellenőrző értékeket nem kapja meg szokásos, menthető és újrahasználható HTTP-üzenetként. Nagyobb lemez vagy magasabb objektumméret-korlát nem teszi őket láthatóvá.
Nézze meg a kérésmódszereket és az alagútbejegyzéseket, mielőtt hibásnak minősíti a gyorsítótárat. A CONNECT-domináns terhelés illik a nagy átvitelhez és kevés objektum-újrafelhasználáshoz. Valódi teszthez saját HTTP-erőforrást használjon explicit cache-fejlécekkel és ismert tartalommal; igazolja, hogy a Squid objektumútját teszteli, nem alagutat, böngészőgyorsítótárat vagy a cél CDN-jét.
A proxyhoz menő TLS külön réteg. Saját TLS-figyelőjének lezárása után a Squid szokásos HTTP-célkérést dolgozhat fel. Ha a kapcsolat inkább CONNECT-et kér HTTPS-hez, a belső cél-TLS külön és átláthatatlan marad.
A HTTPS-elfogás megváltoztatja a tanúsítványbizalom, jogosultság és adatvédelem követelményeit. Nem szokásos gyorsítótárhely-beállítás, és egy normál továbbító proxynak a működéshez nincs szüksége elfogásra.