Shënimi i portës së VPN nuk u jep përparësi thirrjeve zanore

Shënimi i portës UDP të VPN-së si përparësi e lartë është ndryshimi më i zakonshëm i QoS-së për zërin dhe nuk e ndan thirrjen nga transferimi i skedarëve që ndan të njëjtin tunel. Të dy rrjedhat dalin përmes të njëjtit socket të kriptuar. Shënimi i thotë hopit tjetër se gjithçka ka të njëjtën rëndësi, që është njësoj si t'i thuash asgjë. Ajo që mbron një thirrje është një klasifikim i besueshëm para kriptimit plus një radhë që ju e kontrolloni vërtet.

Tuneli fsheh rrjedhën që deshët të klasifikoni

Kriptimi zëvendëson titujt e brendshëm me një titull të jashtëm për çdo tunel. Pas kësaj, zëri dhe trafiku rezervë paraqesin të njëjtin burim, destinacion dhe portë transporti, kështu që një klasifikues i bazuar në portën e tunelit nuk mund t'i dallojë ato. Çfarëdo që nxitni, e nxitni në bllok.

Një vlerë DSCP e vendosur nga aplikacioni origjinal mbijeton vetëm nëse diçka e kopjon nga jashtë. OpenVPN 2.6 ka passtos, të dokumentuar me shtrirje IPv4; IPsec zbaton politikën e vet të kopjimit ose të hartëzimit në kufirin e tunelit. Pa atë hap, paketa e jashtme shënohet me çdo vlerë të parazgjedhur që përdor ndërfaqja e tunelit, dhe radha më poshtë nuk mëson kurrë se brenda ka një thirrje.

Shënimet e kopjuara meritojnë të njëjtin dyshim si çdo vlerë e ofruar nga klienti. Një stacion pune mund të kërkojë përcjellje të përshpejtuar për një detyrë rezervë, prandaj pranimi dhe rishënimi në kufirin e besimit duhet të jenë në projekt përpara se shënimit t'i besohet.

Përparësia llogaritet vetëm aty ku formohet radha

Një lidhje e ngarkuar lart është ajo që e kthen një codec të mirë në zë robotik, dhe radha që mbushet zakonisht është në pajisjen e aksesit ose në tamponin e ofruesit. Formësimi i rrugës dalëse në shpejtësinë e përdorshme, minus kostot e tunelit dhe të lidhjes, është ajo që e mban atë radhë në harduerin që ju administroni, jo në tamponin e dikujt tjetër.

Radhitja e drejtë dhe menaxhimi aktiv i radhëve ndihmojnë edhe pa një klasë zëri, sepse pengojnë një rrjedhë masive të mbushë tamponin. CAKE në Linux bashkon formësimin, drejtësinë për rrjedhë dhe klasat opsionale Diffserv në një qdisc, dhe menaxheri i rrjetit i vendosur duhet të zotërojë atë konfigurim në vend të një radhe të dytë konkurruese. Pa formësim, një klasë mbi trafikun masiv pret përsëri pas një tamponi tashmë të plotë.

Trajtimi i trafikut hyrës nuk është i padobishëm, por vepron pasi paketa ka kaluar lidhjen marrëse. Mund të ndikojë te një dërgues reagues dhe nuk mund të kthejë vonesën tashmë të shpenzuar në rrjedhën e sipërme, prandaj është zbutje dhe jo garanci.

Çfarë mbijeton në internetin publik

Arkitektura Diffserv përshkruan trajtimin brenda domeneve administrative, prandaj një ofrues mund të injorojë ose të rishkruajë një shënim në një kufi. Pohimi i kundërt, se çdo rrjet e heq gjithmonë, është po aq i pambështetur. Pyetja e ndershme është për çfarë është kontraktuar dhe kontrolluar kjo rrugë konkrete. Provojeni me një sondë të shënuar në vend që të përsërisni një rregull që e keni lexuar diku.

Pyetni çfarë bën ofruesi me klasën dhe më pas mateni. Një shënim që ruhet por nuk planifikohet është dekor; një rrugë që planifikon pa e parë shënimin është problem tjetër, dhe të dyja kërkojnë rregullime të ndryshme.

Një plan matjeje që izolon fazën

Bëni një thirrje të zakonshme me një ngarkim konkurrues të kontrolluar, më pas përsëriteni në një lidhje me kabllo. Shikoni çfarë humbi thirrja, çfarë regjistruan numëruesit e klasës dhe sa afër shkon ndërfaqja me kufirin e saj real e jo me shpejtësinë e reklamuar të planit.

tc -s qdisc show dev eth0
tc -s class show dev eth0
mtr -rwzbc 50 voice.example.net

Nëse numëruesi i klasës së zërit mbetet në zero, klasifikimi ose kopjimi i shënimit është prishur dhe asnjë përparësi nuk do të ndihmojë. Nëse numëruesi i klasës lëviz lokalisht ndërsa vonesa vazhdon të rritet, pengesa është përtej portës tuaj. Asnjëri prej dy rezultateve nuk rregullohet duke ngritur vlerën e përparësisë.