Kāpēc CONNECT datplūsma neaizpilda Squid objektu kešatmiņu
Kāpēc parasts HTTPS tunelis var pārsūtīt daudz baitu, nesniedzot pārsūtīšanas starpniekserverim atkārtoti izmantojamus HTTP atbildes objektus.
Parasts CONNECT tunelis sniedz Squid šifrētus baitus, nevis kešatmiņā saglabājamu vietnes atbildi. Tādēļ liela HTTPS lejupielāde var radīt daudz datplūsmas, nepievienojot objektu kešatmiņai nevienu atkārtoti izmantojamu ierakstu.
Squid var reģistrēt tuneļa galamērķi, ilgumu un baitu skaitu. Tas nesaņem iekšējo URL ceļu, kešatmiņas direktīvas, reprezentāciju un validatorus kā parastus HTTP ziņojumus, kurus varētu saglabāt un izmantot atkārtoti. Lielāka diska vieta vai lielāks objekta izmēra ierobežojums tos neatklāj.
Pirms secināt, ka kešatmiņa nedarbojas, pārbaudiet pieprasījumu metodes un tuneļu ierakstus. Slodzē, kurā dominē CONNECT, liels pārsūtīto datu apjoms ir savienojams ar nelielu objektu atkārtotu izmantošanu. Lai patiešām pārbaudītu kešatmiņu, izmantojiet jūsu pārvaldītu HTTP resursu ar skaidri norādītām kešatmiņas galvenēm un zināmu saturu; pārliecinieties, ka pārbaudāt Squid objektu apstrādes ceļu, nevis tuneli, pārlūka kešatmiņu vai galamērķa CDN.
TLS savienojums ar starpniekserveri ir atsevišķs slānis. Pēc TLS savienojuma terminēšanas savā klausītājā Squid var apstrādāt parastu pieprasījumu HTTP galamērķim. Ja šajā savienojumā tā vietā tiek pieprasīts CONNECT uz HTTPS, galamērķa iekšējais TLS paliek atsevišķs un necaurredzams.
HTTPS pārtveršana maina prasības attiecībā uz uzticēšanos sertifikātiem, autorizāciju un privātumu. Tā nav parasta kešatmiņas vietas pielāgošana, un parastam pārsūtīšanas starpniekserverim pārtveršana nav vajadzīga, lai darbotos.