Squid-caching van externe ACL's: waarom de helper niet elke keer wordt aangeroepen
Ontwerp Squid-helpers voor externe ACL's rond persistente processen, cachesleutels voor beslissingen en een expliciete eis van versheid van autorisatie.
Een helper die één verzoek logt en daarna stil wordt, kan normaal zijn. Squid kan een regel evalueren met een gecacht resultaat van een externe ACL zonder de helper nog een query te sturen.
Definieer eerst de herbruikbare beslissing. 'Mag dit account de proxy gebruiken?' vereist andere invoer dan 'Mag dit account deze bestemming bereiken?' Het uitgebreide externe-ACL-formaat vormt de cachesleutel. Als de helper beslist op gebruikersnaam en bestemming maar de sleutel bevat alleen de gebruikersnaam, kan een gecachte goedkeuring breder gelden dan bedoeld. Neem elke invoer op die het antwoord verandert en vermijd details die alleen gelijkwaardige beslissingen versnipperen.
Kies daarna de versheid. Positieve ttl en negative_ttl bepalen overeenkomende en niet-overeenkomende resultaten; grace kan een verversing starten voordat een item verloopt. Bepaal hoe lang de gecachte goedkeuring van een ingetrokken account latere beslissingen mag beïnvloeden. Geen van deze instellingen autoriseert een bestaande CONNECT-tunnel opnieuw voor elke byte of interne HTTPS-aanvraag. Als de helper een verkeersquotum handhaaft, kunnen toegestane overdrachten doorgaan nadat het saldo verandert.
De helper is een persistente protocoldeelnemer, niet noodzakelijk een nieuw scriptproces voor elk verzoek. Houd hem gereed voor opeenvolgende queryregels en stuur elk antwoord snel. Zet diagnostiek op een ander kanaal. Bij ingeschakelde gelijktijdigheid, retourneer de overeenkomstige meegegeven kanaalidentificatie.
Definieer ten slotte langzame, niet-beschikbare en interne foutuitkomsten, en zorg dat de omringende ACL-volgorde ze produceert. Het ontwerp is compleet wanneer zowel de specificiteit als de toegestane leeftijd van een herbruikbaar antwoord overeenkomen met de toegangseis.