Lieli lejupielādes pret VPN: izvēlieties ceļu pieprasījumā
Maršrutētājs nevar izmērīt atbildes lielumu pirms tā nonākšanas. Vadība pēc uzdevuma prasa lēmuma punktu lietotnē vai rindas politiku, kas saglabā esošo ceļu.
„Sūti lielos lejupielādes ap VPN un turi mazās atbildes uz tā“ izklausās kā maršrutēšanas politika, bet tā nav. Maršrutētājs izlemj ar informāciju, kas pieejama tajā brīdī: adreses, porti, protokols, firewall atzīmes, identificēta plūsma. Atbildes galīgais lielums šajā kopā nav, jo tā vēl nav pienākusi, un brīdī, kad maršrutētājs varētu izmērīt baitus, tas jau tos pārsūta. Ja vēlaties vadīt pēc uzdevuma, lēmumam jāpārvietojas uz punktu, kas zina uzdevumu, un zemāk esošais kontrolsaraksts parāda, vai jūsu projektā ir šāds punkts.
Kāpēc maršrutētājs nevar izmērīt atbildi
Brīdī, kad pakei vajadzīgs maršruts, maršrutētājs ir redzējis augstākais pirmos dažus plūsmas pakešus. Tas var pateikt, kas ar ko runā, ar kādu protokolu, ar kādu atzīmi un cik baitu jau ir pagājuši. Līdz šim pagājušie baiti raksturo pagātni. Atbildes lielums ir vēl neizveidotas atbildes īpašība, un sadalītās vai straumētās atbildēs tas var būt nekad iepriekš nezināms.
Pat paša protokola metadati ir vājāki, nekā šķiet. HTTP pieļauj atbildes, kuru garums netiek paziņots pirms pamatteksta, un viena lietotāja darbība var radīt daudz pieprasījumu, kuru kopējās izmaksas nav līdzīgas nevienai vienai galvenes vērtībai. Uzskatīt galveni par uzdevuma lielumu ir modelēšanas kļūda pirms tā ir maršrutēšanas kļūda.
Pārbaude 1: vai ir lēmuma punkts, kas var izvēlēties ceļu?
Nosauciet komponentu, kas veiks izvēli, un tad nosauciet, ko tā zina izvēles brīdī. Atjauninātājs, kas lejupielādē no dokumentētas hostu kopas, zina savu mērķi pirms pārsūtīšanas sākuma. Lejupielādes pakalpojums, kas apskata metadatus un tad atver pieprasījumu, zina uzdevumu pirms savienojuma pastāvēšanas. Sadarbojošs proxy var piemērot pieprasījuma līmeņa politiku vai kešatmiņā saglabāt atbildi, neizliekoties par maršrutētāju.
Ja atbilde ir „vārteja“, kontrolsaraksts jau ir cietis neveiksmi. Vārteja var klasificēt zināmās plūsmas pēc galamērķa, atzīmes vai klienta segmenta un nosūtīt tās pa noteiktu ceļu no pirmās paketes, kas bieži ir pietiekami apstiprinātam atjauninātājam un nekad nav pietiekami nezināmam atbildes lielumam.
Pārbaude 2: ko metadati jums patiešām saka?
Lietotni apzināta vadība ir tik laba, cik labi ir lauki, ko tā lasa. HTTP semantika atbildes garuma noteikumi pieļauj gadījumus, kad garums sākumā nav pieejams, un satura kodējumi jau tāpat padara pārsūtīto baitu skaitu atšķirīgu no attēlojuma lieluma. Tāpēc politika, kas maina ceļu, kad galvene šķērso slieksni, uzvedīsies nekonsekventi, un galvenokārt tieši tajos lielajos pārsūtījumos, kurus tai bija jānoķer.
Ko lietotnes metadati var atbalstīt, ir lēmums par uzdevumu: šī darbplūsma ir masveida sinhronizācija, šī ir interaktīva, šī ir programmatūras atjauninājums no zināma avota. Tā ir politika, kas rakstīta nodoma terminos, un tā ir pietiekami stabila, lai to pārbaudītu. „Šī atbilde būs lielāka par četrdesmit megabaitiem“ nav tāda politika.
Pārbaude 3: vai plūsma jau pastāv?
Maršrutēšana var mainīties plūsmai, nemainot savienojuma identitāti, un šo atšķirību ir vērts saglabāt precīzu. TCP savienojumu identificē pēc tā galapunktu adresēm un portiem, un pakes var iet citu ceļu, ja maršrutēšanas tabula mainās zem tām. Kas nevar mainīties neredzami, ir tīkla adrešu tulkošanas stāvoklis: trafika pārvietošana uz citu izeju parasti maina publisko avota kortežu, un tālā puse redzēs citu partneri bez atbilstoša stāvokļa.
conntrack -L -p tcp --dport 443 | head -5
ip route get 203.0.113.10
ss -tn state established dst 203.0.113.10
Tāpēc praktiskais noteikums ir tāds, ka pārvietošana savienojuma vidū no vienas izejas uz citu ir jaunas attiecības, nevis migrācija. Ja projekts prasa, lai tas pats savienojums turpinātos, lēmums bija jāpieņem pirms pirmā SYN, un neviens vēlāk pievienots pakešu noteikums to nevar tīri rekonstruēt.
Pārbaude 4: vai īstā prasība ir aizture, nevis izeja?
Ļoti daudzi pieprasījumi „sūti masveida trafiku citur“ patiesībā ir sūdzības, ka liels pārsūtījums liek interaktīvam darbam šķist lēnam. Tā ir plānošanas problēma, un tai ir plānošanas atbilde: godīga rinda vai atbalstīta joslas platuma politika esošajā ceļā neļauj masveida plūsmai izbadot čata ziņojumu, nepārvietojot nevienu no abiem.
tc qdisc replace dev eth0 root cake bandwidth 100mbit
Šāda simptoma risināšana atstāj izejas lēmumu tur, kur to nolikusi drošības politika, un to var atcelt ar vienu komandu. Izejas maiņa visai trafika klasei ir politikas maiņa ar sekām autentifikācijai, žurnālēšanai un piekļuves noteikumiem, tāpēc tai nevajadzētu būt pirmajam rīkam aiztures sūdzības gadījumā.
Ja prasība patiešām ir cita interneta izeja, sakiet to ar šiem vārdiem un īstenojiet atbalstītā robežā: jauns savienojums no apstiprinātas darbplūsmas, vai lietotne, kas atver savu pieprasījumu caur izvēlētu izeju. Pēc tam pierakstiet, kuri uzdevumi izmanto kuru izeju, lai nākamajai personai tas nav jāsecina no maršrutēšanas tabulas.
Turiet kontrolsarakstu izmaiņu ierakstā: lēmuma punktu, to virzošo lauku vai uzdevumu, vai plūsma jau pastāv un vai izmērītais simptoms bija aizture vai izeja. Četri jautājumi, un politika, kas atbild uz visiem četriem, ir tāda, ko varat pārvaldīt, nevis aizstāvēt.