Shkarkime të mëdha kundrejt VPN-së: zgjidhni rrugën në kërkesë

«Dërgo shkarkimet e mëdha rreth VPN-së dhe mbaji përgjigjet e vogla mbi të» tingëllon si politikë rrugëtimi, por nuk është. Routeri vendos me informacionin e disponueshëm në atë moment: adresa, porta, protokoll, shenja firewall, një rrjedhë e identifikuar. Madhësia përfundimtare e përgjigjes nuk është në atë grup, sepse nuk ka mbërritur ende, dhe kur routeri mund të maste bajtët, ai tashmë po i transporton. Nëse dëshironi drejtim sipas detyrës, vendimi duhet të kalojë në një pikë që e njeh detyrën, dhe lista e kontrollit më poshtë tregon nëse dizajni juaj ka një pikë të tillë.

Pse një router nuk mund të masë një përgjigje

Në momentin kur një paketë ka nevojë për një rrugë, routeri ka parë më së shumti paketat e para të një rrjedhe. Ai mund të thotë kush flet me kë, përmes cilit protokoll, me cilën shenjë, dhe sa bajtë kanë kaluar deri tani. Bajtët deri tani përshkruajnë të shkuarën. Madhësia e përgjigjes është veti e një përgjigjeje që nuk është krijuar ende, dhe në përgjigjet e ndara ose në transmetim mund të mos jetë kurrë e njohur paraprakisht.

Edhe metadatat e vetë protokollit janë më të dobëta nga sa duken. HTTP lejon përgjigje gjatësia e të cilave nuk shpallet para trupit, dhe një veprim i vetëm përdoruesi mund të prodhojë shumë kërkesa kostoja e kombinuar e të cilave nuk i ngjan asnjë vlere të vetme header-i. Trajtimi i një header-i si madhësia e një detyre është gabim modelimi përpara se të jetë gabim rrugëtimi.

Kontrolli 1: a ka një pikë vendimi që mund të zgjedhë një rrugë?

Emërtoni komponentin që do të bëjë zgjedhjen, dhe pastaj emërtoni çfarë di në momentin e zgjedhjes. Një përditësues që shkarkon nga një grup i dokumentuar hostesh e njeh qëllimin e vet para se të nisë transferimi. Një shërbim shkarkimi që shikon metadatat dhe pastaj hap kërkesën e njeh detyrën para se të ekzistojë lidhja. Një proxy bashkëpunues mund të zbatojë politikë në nivel kërkese ose të ruajë përgjigjen në cache pa u shtirur si router.

Nëse përgjigja është «gateway», lista e kontrollit ka dështuar tashmë. Një gateway mund të klasifikojë rrjedhat e njohura sipas destinacionit, shenjës ose segmentit të klientit dhe t'i dërgojë ato në një rrugë të përcaktuar që nga paketa e parë, gjë që shpesh mjafton për një përditësues të miratuar dhe nuk mjafton kurrë për një madhësi të panjohur përgjigjeje.

Kontrolli 2: çfarë ju thonë vërtet metadatat?

Drejtimi i vetëdijshëm për aplikacionin është aq i mirë sa fushat që lexon. Rregullat e gjatësisë së përgjigjes në semantika e HTTP lejojnë raste kur gjatësia nuk është e disponueshme në fillim, dhe kodimet e përmbajtjes e bëjnë gjithsesi numrin e bajtëve të transferuar të ndryshëm nga madhësia e paraqitjes. Prandaj një politikë që ndryshon rrugë kur një header kalon një prag do të sillet në mënyrë jo konsistente, dhe kryesisht pikërisht në transferimet e mëdha që duhej të kapte.

Ajo që metadatat e aplikacionit mund të mbështesin është një vendim për një detyrë: kjo rrjedhë pune është sinkronizim masiv, kjo është interaktive, kjo është një përditësim softueri nga një burim i njohur. Kjo është një politikë e shkruar në terma qëllimi, dhe është mjaft e qëndrueshme për t'u testuar. «Kjo përgjigje do të jetë më e madhe se dyzet megabajtë» nuk është ajo lloj politike.

Kontrolli 3: a ekziston rrjedha tashmë?

Rrugëtimi mund të ndryshojë për një rrjedhë pa ndryshuar identitetin e lidhjes, dhe ky dallim ia vlen të mbahet saktë. Një lidhje TCP identifikohet nga adresat dhe portat e skajeve të saj, dhe paketat mund të marrin një rrugë tjetër nëse tabela e rrugëtimit ndryshon nën to. Ajo që nuk mund të ndryshojë në mënyrë të padukshme është gjendja e përkthimit të adresave të rrjetit: zhvendosja e trafikut në një dalje tjetër zakonisht ndryshon tupin e burimit publik, dhe skaji i largët do të shohë një partner tjetër pa gjendje përputhëse.

conntrack -L -p tcp --dport 443 | head -5
ip route get 203.0.113.10
ss -tn state established dst 203.0.113.10

Pra rregulli praktik është se një zhvendosje në mes të lidhjes nga një dalje në tjetrën është një marrëdhënie e re, jo një migrim. Nëse dizajni kërkon që e njëjta lidhje të vazhdojë, vendimi duhej marrë para SYN-it të parë, dhe asnjë rregull paketash i shtuar më vonë nuk mund ta rindërtojë pastër.

Kontrolli 4: a është kërkesa e vërtetë vonesa, jo dalja?

Shumë kërkesa për «dërgo trafikun masiv diku tjetër» janë në fakt ankesa se një transferim i madh e bën punën interaktive të duket e ngadaltë. Ky është problem planifikimi, dhe ka një përgjigje planifikimi: radhë e drejtë ose një politikë e mbështetur e gjerësisë së brezit në rrugën ekzistuese e pengon një rrjedhë masive të uriturit e një mesazhi chat-i pa zhvendosur asnjërën prej tyre.

tc qdisc replace dev eth0 root cake bandwidth 100mbit

Trajtimi i simptomës në këtë mënyrë e mban vendimin e daljes atje ku e vendosi politika e sigurisë, dhe është i kthyeshëm me një komandë. Ndryshimi i daljes për një klasë të tërë trafiku është një ndryshim politike me pasoja për autentikimin, regjistrimin dhe rregullat e aksesit, prandaj nuk duhet të jetë mjeti i parë për një ankesë vonese.

Nëse kërkesa është me të vërtetë një dalje tjetër interneti, thojeni me ato fjalë dhe zbatojeni në një kufi të mbështetur: një lidhje e re nga një rrjedhë pune e miratuar, ose një aplikacion që hap kërkesën e vet përmes një daljeje të zgjedhur. Pastaj regjistroni cilat detyra përdorin cilën dalje, që personi tjetër të mos duhet ta nxjerrë nga një tabelë rrugëtimi.

Mbani listën e kontrollit në regjistrin e ndryshimit: pikën e vendimit, fushën ose detyrën që e drejton, nëse rrjedha ekziston tashmë dhe nëse simptoma e matur ishte vonesë apo dalje. Katër pyetje, dhe një politikë që përgjigjet për të katërtat është një që mund ta operoni në vend që ta mbroni.