Descărcări mari versus VPN: alegeți calea la cerere

„Trimite descărcările mari pe lângă VPN și ține răspunsurile mici pe el“ sună ca o politică de rutare, dar nu este. Un router decide cu informațiile disponibile în acel moment: adrese, porturi, protocol, marcaje de firewall, un flux identificat. Dimensiunea finală a unui răspuns nu face parte din această mulțime, pentru că încă nu a sosit, iar când routerul ar putea măsura octeții, îi transportă deja. Dacă vrei dirijare pe sarcină, decizia trebuie mutată într-un punct care cunoaște sarcina, iar lista de verificare de mai jos arată dacă proiectul tău are un astfel de punct.

De ce un router nu poate măsura un răspuns

În momentul în care un pachet are nevoie de o rută, routerul a văzut cel mult primele pachete ale unui flux. Poate spune cine vorbește cu cine, prin ce protocol, cu ce marcaj și câți octeți au trecut până acum. Octeții de până acum descriu trecutul. Dimensiunea răspunsului este o proprietate a unui răspuns care nu a fost generat încă, iar la răspunsurile fragmentate sau în streaming poate să nu fie niciodată cunoscută dinainte.

Chiar și metadatele protocolului sunt mai slabe decât par. HTTP permite răspunsuri a căror lungime nu este anunțată înaintea corpului, iar o singură acțiune a utilizatorului poate produce multe cereri al căror cost combinat nu seamănă cu nicio valoare de antet. A trata un antet ca dimensiune a unei sarcini este o eroare de modelare înainte de a fi o eroare de rutare.

Verificarea 1: există un punct de decizie care poate alege o cale?

Numește componenta care va face alegerea, și apoi numește ce știe în momentul alegerii. Un actualizator care descarcă dintr-un set documentat de gazde își cunoaște scopul înainte de începerea transferului. Un serviciu de descărcare care consultă metadate și apoi deschide cererea cunoaște sarcina înainte de a exista conexiunea. Un proxy cooperant poate aplica politici la nivel de cerere sau poate stoca răspunsul în cache fără să pretindă că este router.

Dacă răspunsul este „gateway-ul“, lista a eșuat deja. Un gateway poate clasifica fluxurile cunoscute după destinație, marcaj sau segment de client și le poate trimite pe o cale definită încă de la primul pachet, ceea ce este adesea suficient pentru un actualizator aprobat și niciodată suficient pentru o dimensiune necunoscută a răspunsului.

Verificarea 2: ce vă spun de fapt metadatele?

Dirijarea conștientă de aplicație este doar atât de bună cât câmpurile pe care le citește. Regulile privind lungimea răspunsului din semantica HTTP permit cazuri în care lungimea nu este disponibilă la început, iar codificările de conținut fac oricum numărul de octeți transferați diferit de dimensiunea reprezentării. De aceea o politică ce schimbă calea când un antet trece un prag se va comporta inconsecvent, și mai ales exact la transferurile mari pe care trebuia să le prindă.

Ce pot susține metadatele aplicației este o decizie despre o sarcină: acest flux de lucru este o sincronizare masivă, acesta este interactiv, acesta este o actualizare de software dintr-o sursă cunoscută. Aceasta este o politică scrisă în termeni de intenție și este suficient de stabilă pentru a fi testată. „Acest răspuns va fi mai mare de patruzeci de megabaiți“ nu este acel tip de politică.

Verificarea 3: fluxul există deja?

Rutarea se poate schimba pentru un flux fără a schimba identitatea conexiunii, iar această distincție merită păstrată clar. O conexiune TCP este identificată prin adresele și porturile capetelor sale, iar pachetele pot lua altă cale dacă tabela de rutare se schimbă dedesubt. Ce nu se poate schimba invizibil este starea de traducere a adreselor de rețea: mutarea traficului pe altă ieșire de obicei schimbă tuplul sursă public, iar capătul îndepărtat va vedea alt partener fără stare corespunzătoare.

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

Așadar regula practică este că o mutare la mijlocul conexiunii de la o ieșire la alta este o relație nouă, nu o migrare. Dacă proiectul cere ca aceeași conexiune să continue, decizia trebuia luată înainte de primul SYN, iar nicio regulă de pachete adăugată ulterior nu o poate reconstrui curat.

Verificarea 4: cerința reală este latența, nu ieșirea?

Foarte multe cereri de a „trimite traficul masiv în altă parte“ sunt de fapt plângeri că un transfer mare face munca interactivă să pară lentă. Aceasta este o problemă de planificare și are un răspuns de planificare: o coadă corectă sau o politică de lățime de bandă susținută pe calea existentă împiedică un flux masiv să înfometeze un mesaj de chat fără a muta niciunul dintre ele.

tc qdisc replace dev eth0 root cake bandwidth 100mbit

Abordarea simptomului astfel păstrează decizia de ieșire acolo unde a pus-o politica de securitate și este reversibilă cu o singură comandă. Schimbarea ieșirii pentru o întreagă clasă de trafic este o schimbare de politică cu consecințe pentru autentificare, jurnalizare și reguli de acces, așa că nu ar trebui să fie primul instrument la o plângere despre latență.

Dacă cerința este într-adevăr o altă ieșire de internet, spuneți-o cu acele cuvinte și implementați-o la o graniță susținută: o conexiune nouă dintr-un flux de lucru aprobat sau o aplicație care își deschide propria cerere printr-o ieșire aleasă. Apoi înregistrați ce sarcini folosesc ce ieșire, ca următoarea persoană să nu fie nevoită să deducă asta dintr-un tabel de rutare.

Păstrați lista de verificare în înregistrarea schimbării: punctul de decizie, câmpul sau sarcina care îl conduce, dacă fluxul există deja și dacă simptomul măsurat a fost latență sau ieșire. Patru întrebări, iar o politică ce răspunde la toate patru este una pe care o puteți opera în loc să o apărați.