Cache sa likod ng VPN: ano pa ang itinatago ng HTTPS

Ang cache sa tabi ng VPN server ay parang libreng bandwidth para sa lahat sa likod ng tunnel. Hindi ito ganoon, dahil ang mga byte na dumadaan sa puntong iyon ay nananatiling protektado ng TLS session na ang mga dulo ay ang browser at ang website. Tinatanggal ng VPN gateway ang sarili nitong panlabas na encryption, hindi ang sa aplikasyon. Magpasya kung aling paulit-ulit na bagay ang gusto mong gamitin muli bago magdagdag ng hardware.

Ang TLS session ay pag-aari ng browser

Sa ordinaryong HTTPS, nakikipag-usap ang browser sa site para sa mga key, at bawat record pagkatapos ng handshake ay naka-encrypt para sa pares ng dulo. Binabasa ng VPN gateway ang tunnel na ginawa nito at pagkatapos ay ipinapasa ang mga opaque na TLS record. Nakikita nito ang mga destinasyon, oras at dami, hindi ang linya ng kahilingan o ang katawan ng tugon. Iyon ang hangganang kailangang pakisamahan ng anumang cache.

Anumang disenyo na sumisira nito ay disenyo ng interception ng TLS, na may sariling mga bunga sa pagtitiwala sa sertipiko at pamamahala ng device.

Ang CONNECT ay tunnel, hindi cache

Ang tahasang forward proxy ay karaniwang tumatanggap ng HTTP CONNECT na kahilingan at pagkatapos ay nagpapasa ng mga byte sa dalawang direksyon. Ang pagpapasa ang mahalagang salita: hindi sinusuri ng proxy ang naka-encrypt na usapan.

curl -sSI -x http://proxy.example:3128 https://example.com/

Ang mga header ng tugon ay nagmumula sa paghawak ng proxy sa tunnel, hindi sa naka-cache na kopya ng pahina. Ang matagumpay na CONNECT ay nangangahulugang gumagana ang landas, hindi na may nakaimbak para gamitin muli. Ituro ang port 443 sa isang cache ay hindi rin nagtuturo nitong magsalita ng TLS, dahil ang caching ay nangangailangan ng nababasang mensahe. Dapat gamitin ng configuration ng kliyente ang sinusuportahang tahasang setting ng proxy, hindi ang hindi maipaliwanag na redirect.

I-cache ang pinapatakbo mo, hindi ang binibisita mo

Kung sa iyo ang nilalaman, maaaring tapusin ng reverse proxy ang TLS at sadyang mag-imbak ng mga aprubadong tugon. Kung pag-aari ito ng repositoryo ng package, gamitin ang mirror na sinusuportahan ng proyekto.

nginx -T | grep -n "proxy_cache"
curl -sSI https://mirror.example/pkg/index.json | grep -i -E "cache-control|age"

Ipinapakita ng unang utos kung may naka-configure na cache zone at saan ito naaangkop, habang ang pangalawa ay nagpapakita ng sariling mga direktiba ng caching ng pinagmulan para sa isang bagay. Ang shared cache ay dapat gumalang sa freshness, mga kontrol ng cache at mga katangian ng kahilingan na nagtatangi ng mga representasyon; private at no-store ay magkaibang kahulugan at wala sa dalawa ang dapat alisin para mapataas ang hit rate. Nililimitahan din ng mga tuntunin ng HTTP caching ang pag-imbak ng mga tugon sa mga awtentikadong kahilingan, at doon mismo nagiging paglantad ng data ang isang personalisadong pahina. Panatilihing limitado ang proxy sa mga aprubadong kliyente sa halip na maglantad ng bukas na relay.

Sukatin ang hit, hindi ang stopwatch

Ang mas mabilis na pangalawang kahilingan ay hindi nagpapatunay na may ginawa ang bagong cache, dahil ang mga browser at operating system ay agresibong nag-cache nang mag-isa. Humingi ng hit at miss counters sa proxy at panoorin ang trapiko ng pinagmulan sa isang kontroladong pag-uulit. Gumamit ng isang paulit-ulit na download ng kilalang bagay, una ay bukas ang cache at pagkatapos ay nilaktawan, at ihambing ang mga byte na inihain ng pinagmulan kaysa sa lumipas na oras. Pagkatapos ay suriin ang hangganan ng awtorisasyon: ang resource na nangangailangan ng login ay hindi dapat ihain sa ibang kliyente.

Itala ang workload, ang cache key at ang patakarang nagpahintulot ng muling paggamit. Ang cache ay desisyon sa pagbabahagi ng data na nakasuot ng kasuutan ng optimization.