Squid-ի բայթային ո՞ր հաշվիչը պետք է օգտագործի թրաֆիկի քվոտան
Որոշեք՝ արդյոք proxy-ի քվոտան չափում է պատասխանները, հարցումները, վերին հանգույցի մարմինները, թե՞ հասանելիության հղումով երթևեկությունը, մինչ Squid-ի մատյանի դաշտերը գումարելը։
«Յուրաքանչյուր օգտատիրոջ տաս գիգաբայթ տվեք» արտահայտությունը ճշգրիտ է թվում, քանի դեռ երկու հաշվետվություն չեն հակասում միմյանց։ Մեկը գումարել էր հաճախորդներին ուղարկված պատասխանները, մյուսը հաշվել էր վերին հանգույցից բերված բայթերը։ Երկուսն էլ կարող են ճիշտ ներկայացնել իրենց ընտրած դաշտը։
Squid-ի մատյանի ձևաչափն ունի առանձին հաշվիչներ՝
| Դաշտ | Փաստագրված չափում |
|---|---|
%<st | Հաճախորդին ուղարկված պատասխանի ընդհանուր երթևեկությունը՝ հարմարեցումից հետո |
%>st | Հաճախորդից ստացված հարցման ընդհանուր չափը՝ բացառելով chunked կոդավորման բայթերը |
%<bs | Հաջորդ հոպից ստացված HTTP-համարժեք հաղորդագրության մարմնի բայթերը՝ փաստագրված բացառություններով |
Squid-ի սեփական մատյանի bytes սյունակը օգտագործում է հաճախորդի պատասխանի հաշվիչը։ Սա խոստում չէ, որ արժեքը հավասար է պահված ֆայլի երկարությանը, և չափում չէ ISP-ի գանձած յուրաքանչյուր Ethernet կամ IP բայթի։
Քեշի հիթերը ցույց են տալիս տարբերությունը. Squid-ը կարող է պատասխան ուղարկել՝ առանց վերին հանգույցից թարմ տվյալ բերելու։ Վերբեռնումով ծանր աշխատանքը ցույց է տալիս մեկ այլ բան. միայն պատասխանները հաշվելը հարցման ուղղությունը թողնում է բյուջեից դուրս։
CONNECT-ի դեպքում proxy-ն կարող է հաշվառել փոխանցված երթևեկությունը՝ չհասկանալով թունելի ներսում գտնվող յուրաքանչյուր գաղտնագրված ֆայլ կամ էջ։ Այն չի կարող թունելի բայթերի գումարը վերածել ներբեռնված ծրագրային օբյեկտների ճշգրիտ ցանկի։
Քվոտայի պայմանագիրը գրեք հաշվիչի կողքին՝ ուղղություն, դիտարկման կետ, հաշվառման ժամանակաշրջան և ինքնություն։ Ապա պահեք մատյանի ձևաչափի տարբերակը հաշվետվությունների հետ։ Բայթի իմաստի շուրջ անհամաձայնությունը չպետք է «ուղղվի»՝ յուրաքանչյուր արժեք գուշակված ուղղման գործակցով բազմապատկելով։ Կիրառման համար ավարտված գործարքների գումարները կարող են հետ մնալ կենդանի օգտագործումից։