Kodėl CONNECT srautas neužpildo Squid objektų podėlio
Kodėl įprastas HTTPS tunelis gali perduoti daug baitų nesuteikdamas tiesioginiam tarpiniam serveriui pakartotinai naudojamų HTTP atsako objektų.
Įprastas CONNECT tunelis pateikia Squid užšifruotus baitus, o ne svetainės atsaką, kurį galima išsaugoti podėlyje. Todėl didelis HTTPS atsisiuntimas gali sukurti daug srauto, nepridėdamas nė vieno pakartotinai naudojamo įrašo į objektų podėlį.
Squid gali užregistruoti tunelio paskirties vietą, trukmę ir baitų skaičių. Vidinio URL kelio, podėlio direktyvų, pateikties ir tikrintuvų jis negauna kaip įprastų HTTP pranešimų, kuriuos galėtų išsaugoti ir naudoti pakartotinai. Daugiau vietos diske ar didesnė objekto dydžio riba jų neatskleidžia.
Prieš nuspręsdami, kad podėlis neveikia, patikrinkite užklausų metodus ir tunelių įrašus. Kai vyrauja CONNECT, didelis perduodamų duomenų kiekis ir menkas objektų pakartotinis naudojimas vienas kitam neprieštarauja. Norėdami iš tikrųjų patikrinti podėlį, naudokite savo valdomą HTTP išteklių su aiškiomis podėlio antraštėmis ir žinomu turiniu; įsitikinkite, kad tikrinate Squid objektų apdorojimo kelią, o ne tunelį, naršyklės podėlį ar paskirties CDN.
TLS ryšys su tarpiniu serveriu yra atskiras sluoksnis. Užbaigęs TLS ryšį savo klausymo taške, Squid gali apdoroti įprastą užklausą HTTP paskirties vietai. Jei per tą ryšį vietoj to prašoma CONNECT į HTTPS, vidinis paskirties vietos TLS lieka atskiras ir nepermatomas.
HTTPS perėmimas keičia pasitikėjimo sertifikatais, įgaliojimų ir privatumo reikalavimus. Tai nėra įprastas podėlio vietos reguliavimas, o normaliam tiesioginiam tarpiniam serveriui perėmimo nereikia, kad jis veiktų.