VPN ryšių limitai: tiesioginė būsena ar saugoma istorija
Trijų ryšių limitui reikia tiesioginės lizdų būsenos, o ne naršymo istorijos: ką mechanizmas turi saugoti, ką gali atmesti ir kur ta būsena vėliau patenka.
Trys vienalaikiai ryšiai yra priėmimo sprendimas, o norint į jį atsakyti reikia žinoti, kurie lizdai užimti dabar, o ne ką nutiko praėjusį mėnesį. Paslauga gali atmesti ketvirtą sesiją pagal mažą aktyvių įrašų lentelę ir niekada nesukurti laiko juostos. Tai teiginys apie mechanizmą, o ne apie operatorių, ir skirtumas svarbus skaitant privatumo politiką. Toliau pateiktas modelis rodo, ko sprendimui reikia ir ką jis gali atmesti.
Mechanizmas: lizdų lentelė, o ne žurnalas
Paprasčiausia įgyvendinimo versija susieja prenumeratą su ne daugiau kaip trimis aktyviais sesijos įrašais. Kiekviena priimta sesija užima vieną lizdą, o lizdas atlaisvinamas, kai paslauga nusprendžia, kad ta sesija baigėsi. Įrašui reikia pakankamai konkretaus identiteto, kad vieno ryšio atlaisvinimas neatlaisvintų kito ryšio lizdo; todėl sesijos identifikatorius svarbesnis už paskyros pavadinimą.
Užimtumas ir istorija yra skirtingos duomenų struktūros. Užimtumas atsako į taip-ar-ne klausimą apie dabartį ir gali būti atmestas tą akimirką, kai sesija baigiasi. Istorija yra tik papildomas įvykių srautas, ir ji išlieka todėl, kad kažkas nusprendė ją saugoti. Paslauga gali turėti vieną, abu arba nė vieno.
Skirtumas iš išorės nematomas. Matomas ryšių limitas suderinamas su mažu skaitikliu atmintyje, bendra duomenų bazės lentele ir visu įvykių archyvu su prietaisų skydeliu. Niekas pačiame limite nepasako, kuris iš jų veikia.
| What is stored | Why it exists |
|---|---|
| Active session slots | To admit or refuse the next connection |
| Session event log | To investigate or bill later |
| Monitoring series | To watch capacity and error rates |
| Backup copies | To restore any of the above |
Kodėl tiesioginiam modeliui vis tiek reikia koordinavimo
Nutrūkęs ryšys gali būti ne iš karto atpažintas kaip pasibaigęs. Tinklų sietuvas laukia laiko limito, keepalive gedimo ar apskaitos sustabdymo, ir kol kuris nors iš jų neateina, lizdas lieka užimtas. Naudotojas, kuris tuo metu prisijungia iš naujo, sulaukia atsisakymo, neturinčio nieko bendra su ketvirtuoju įrenginiu.
Paleistas iš naujo serveris turi suderinti savo būseną, o keli tinklų sietuvai, aptarnaujantys tą pačią paskyrą, turi priimti bendrą sprendimą. Priešingu atveju paskyra gali viršyti savo kvotą prisijungdama prie skirtingų vietų. Bendra arba atkuriama būsena tai išsprendžia, o bendra būsena yra projektavimo reikalavimas, o ne stebėjimo įrodymas.
Nė viena to koordinavimo dalis nereikalauja naršymo istorijų. Paketus persiunčiantis tinklų sietuvas, kad suskaičiuotų sesijas, neturi žinoti, kokias svetaines sesija aplankė, ir šiuos du duomenų srautus paprastai tvarko visiškai skirtingi komponentai.
Skaitiklio laikymas atmintyje taip pat nepadaro susijusių faktų anoniminiais. Kol paslauga veikia, su prenumerata susietas įrašas atskleidžia, kad paskyra turi aktyvių ryšių, ir tiek prieiga prie šios būsenos, tiek jos trukmė verti klausimo.
Kur būsena vėliau patenka
Privatumo klausimas nėra tai, ar serveris gali skaičiuoti. Paklauskite, kas nutinka pasibaigusiai sesijai: įrašas pašalinamas ar jis tampa įvykiu stebėjimo serijoje? Tada paklauskite, kurie kiti komponentai matė tą patį įvykį, nes autentifikavimo žurnalai, apskaitos įrašai ir atsarginės kopijos gali kiekvienas saugoti kopiją, kurią vykdymo kelias atmetė.
RADIUS apskaita yra aiškiausias pavyzdys. Start ir Stop pora egzistuoja atsiskaitymui ir sesijų kontrolei palaikyti, ir ji sukuria ryšio įrašą nepriklausomai nuo to, ar kas nors kada nors teiraujasi jo kaip istorijos. Todėl paslauga, kuri limituoja per apskaitą, iš prigimties saugo daugiau nei lizdų lentelę.
Trynimas taip pat turi formą. Įrašas, pašalintas iš tiesioginės lentelės, gali išlikti prieš valandą darytoje atsarginėje kopijoje, o tos kopijos saugojimo laikotarpis yra atskiras politikos pareiškimas. Skaitant tik pagrindinę saugyklą gaunamas neišsamus atsakymas.
Užduokite klausimą laukų terminais
RFC 6973 duomenų mažinimo gairės sieja renkamus ir saugomus duomenis su aptarnaujamu tikslu. Taikant čia, naudingas klausimas yra kokių laukų vienalaikio priėmimo užduočiai iš tikrųjų reikia ir koks tikslas pateisina kiekvieno jų saugojimą po tos užduoties pabaigos.
Tikslus paslaugos pareiškimas atskiria tiesioginę ryšio būseną, naudojamą kvotai vykdyti, nuo bet kokių įrašų, saugomų po nutraukimo, ir įvardija kitas sistemas pažado apimtyje. Sakinys, kuriame sakoma tik kad vykdomi trys ryšiai, nenustato nei kad archyvas egzistuoja, nei kad jo nėra.
Kai gyvavimo ciklas neaiškus, užrašykite tai kaip neatsakytą saugojimo klausimą, o ne verdiktą. Limito buvimas nėra paslėptos istorijos įrodymas, o tikėtinas tiesioginės būsenos paaiškinimas nėra tiekėjo auditas.