Tre rreshta në një profil duken sikur të gjithë e fikin kompresimin, dhe vetëm njëri prej tyre e bën vërtet. Dallimi ka rëndësi sepse paralajmërimi që dëshironi të heshtni është simptomë, ndërsa politika është ajo që vendos nëse pala tjetër mund të kompresojë ende. Krahasimi i opsioneve në një aks të vetëm, pra çfarë lejon secili pas ndryshimit, heq pjesën më të madhe të paqartësisë. Cilin dëshironi varet nga fakti nëse po migroni apo po vendoseni.

Tre politika që duken njësoj në një skedar konfigurimi

Çdo opsion përgjigjet një pyetjeje tjetër. allow-compression no i refuzon drejtpërdrejt ngarkesat e kompresuara, allow-compression asym dekompreson atë që vjen dhe nuk kompreson kurrë atë që del, dhe comp-lzo no i vjetër lë vend për një push të palës tjetër që aktivizon kompresimin. Vetëm i pari është një politikë që një server nuk mund ta anulojë.

Shkruajini të tre në një tabelë përpara se të zgjidhni, sepse emrat janë mjaft të afërt për të mashtruar një recensues. Dy prej tyre ekzekutojnë ende kod dekompresimi në paketat e marra, dhe pikërisht për këtë është argumenti i sigurisë. I treti heq aftësinë në vend që të kufizojë drejtimin e saj. Nëse regjistri i ndryshimit thotë se kompresimi është çaktivizuar, pikërisht një rresht e plotëson atë fjali.

Paralajmërimi që nisi hetimin nuk është objektivi. Heshtja e tij duke lënë një politikë lejuese jep një regjistër të pastër dhe një ekspozim të pandryshuar.

SettingWhat it permitsWhen it is the right answer
allow-compression noNo compressed payloads, and no compression framing under offloadBoth ends can be changed now
allow-compression asymDecompress inbound onlyA dated migration while peers catch up
comp-lzo noOff locally, still pushable by a peerLegacy compatibility you can still justify

Çfarë do të thotë no në opsionin e vjetër LZO

Në opsionin e vjetruar LZO, no e çaktivizon kompresimin për anën lokale pa i ndaluar palës tjetër ta aktivizojë atje ku politika e lejon. Kjo asimetri është arsyeja pse kalimi i një profili në një refuzim të rreptë ndryshon sjelljen në mënyra që një test laboratori me një server të vetëm mund të mos i zbulojë kurrë.

Shqetësimi i sigurisë është i kushtëzuar, jo absolut. Kur një sulmues mund të vendosë tekst të qartë të zgjedhur pranë një sekreti dhe të vëzhgojë se si kompresimi ndryshon madhësinë e trafikut të enkriptuar, ekziston një kanal informacioni. Kalimi nga LZO në LZ4 ndryshon algoritmin dhe kornizimin, jo atë mekanizëm.

Prandaj korniza e sinqertë ka të bëjë me atë që jeni gati të lejoni, jo me atë algoritëm që rekomandohet tani. Refuzimi i rreptë është opsioni i vetëm që nuk varet nga bashkëpunimi i palës tjetër.

Vetëm pranimi është gjendje migrimi, jo destinacion

Pranimi asimetrik ekziston që njëra palë të mund të ndalojë kompresimin ndërsa tjetra ende e pret atë. Është një urë, dhe urat kanë nevojë për një datë përfundimi dhe një pronar. Regjistroni cilët partnerë ende dërgojnë trafik të kompresuar, sepse politika lejon pikërisht atë trafik. Pa atë listë, gjendja e migrimit bëhet konfigurimi i përhershëm nga inercia.

Një klient nuk mund ta detyrojë një server të papajtueshëm të heqë dorë nga kornizimi i vjetër duke redaktuar skedarin e vet. Drejtimi i push vendoset në server, prandaj migrimi në të vërtetë përfundon në konfigurimin e serverit dhe në skedarët e tij për çdo klient.

Modalitetet stub ruajnë kornizimin por anashkalojnë vetë punën e kompresimit, dhe nuk janë ekuivalent i drejtpërdrejtë i opsionit më të vjetër. Testojini ato ndaj partnerit më të vjetër që duhet ende të mbështesni përpara se të zgjidhni një.

Ku offload-i i kanalit të të dhënave ndryshon përgjigjen

Offload-i i kanalit të të dhënave e zhvendos përpunimin e paketave në kernel, dhe një profil që ende varet nga kornizimi i kompresimit mund të mos përshtatet në atë rrugë. Dështimi nuk është gjithmonë i zhurmshëm: një klient lidhet dhe pastaj sillet ndryshe nga tuneli që testuat.

Kontrolloni cila implementim është aktiv përpara dhe pas ndryshimit, jo vetëm nëse lidhja ka sukses. Kur rruga me offload refuzon kornizimin e kompresimit, një politikë e rreptë refuzimi dhe një vendosje me offload përputhen, ndërsa një politikë lejuese dhe një vendosje me offload nuk përputhen.

Ky kombinim meriton testin e vet, sepse pikërisht aty një skedar që duket i saktë është në heshtje jo ai që përdoret. Krahasoni gjendjen e negociuar me qëllimin e regjistruar në profil, sepse vetëm njëra prej tyre është e dukshme në një regjistër.

Zgjidhni një politikë dhe pastaj verifikoni rezultatin e negociuar

Zgjidhni refuzim të rreptë kur mund të ndryshoni të dy skajet, pranim asimetrik kur nuk mundeni ende, dhe kompresim të plotë vetëm kur mund të shpjegoni pse ekspozimi është i pranueshëm. Pastaj verifikoni çfarë u negociua dhe jo çfarë thotë skedari. Një regjistër më i qetë është provë vetëm kur përputhet me politikën që kishit ndërmend të vendosnit.

Mbajeni vendimin pranë profilit të cilit i aplikohet, me datën dhe partnerët ende të përjashtuar. Pas gjashtë muajsh, ai shënim është dallimi midis një përjashtimi të qëllimshëm dhe një aksidenti që askush nuk mund ta datojë. Shkruajeni në të njëjtin depo si profili, që redaktori i radhës ta shohë arsyen përpara direktivës.

Artikuj të ngjashëm