Descàrregues grans contra la VPN: trieu el camí a la petició

«Envia les descàrregues grans per fora de la VPN i mantén les respostes petites per dins» sona com una política d'encaminament, i no ho és. Un encaminador decideix amb la informació disponible en aquell moment: adreces, ports, protocol, marques de firewall, un flux identificat. La mida final d'una resposta no és en aquest conjunt, perquè encara no ha arribat, i quan l'encaminador podria mesurar els bytes ja els està transportant. Si voleu dirigir per tasca, la decisió ha de moure's a un punt que conegui la tasca, i la llista de comprovació de sota és com esbrinar si el vostre disseny té aquest punt.

Per què un encaminador no pot mesurar una resposta

En el moment en què un paquet necessita una ruta, l'encaminador ha vist com a molt els primers paquets d'un flux. Pot dir qui parla amb qui, per quin protocol, amb quina marca i quants bytes han passat fins ara. Els bytes fins ara descriuen el passat. La mida de la resposta és una propietat d'una resposta que encara no s'ha generat, i en respostes fragmentades o en streaming potser mai no es pot saber per endavant.

Fins i tot les metadades del mateix protocol són més febles del que semblen. HTTP permet respostes la longitud de les quals no s'anuncia abans del cos, i una sola acció de l'usuari pot produir moltes peticions el cost combinat de les quals no s'assembla a cap valor de capçalera. Tractar una capçalera com la mida d'una tasca és un error de modelatge abans que un error d'encaminament.

Comprovació 1: hi ha un punt de decisió que pugui triar un camí?

Anomeneu el component que farà la tria, i després digueu què sap en el moment de triar. Un actualitzador que baixa d'un conjunt documentat d'amfitrions coneix el seu propòsit abans que comenci la transferència. Un servei de descàrrega que consulta metadades i després obre la petició coneix la tasca abans que existeixi la connexió. Un proxy col·laborador pot aplicar polítiques a nivell de petició o fer memòria cau de la resposta sense fer veure que és un encaminador.

Si la resposta és «la passarel·la», la llista de comprovació ja ha fallat. Una passarel·la pot classificar fluxos coneguts per destinació, marca o segment de client i enviar-los per un camí definit des del primer paquet, cosa que sovint n'hi ha prou per a un actualitzador aprovat i mai no n'hi ha prou per a una mida de resposta desconeguda.

Comprovació 2: què us diuen realment les metadades?

El direccionament conscient de l'aplicació és tan bo com els camps que llegeix. Les regles de longitud de resposta de la semàntica d'HTTP permeten casos en què la longitud no està disponible a l'inici, i les codificacions de contingut fan que el recompte de bytes transferits sigui diferent de la mida de la representació. Per tant, una política que canvia de camí quan una capçalera travessa un llindar es comportarà de manera inconsistent, i sobretot justament en les transferències grans que havia de detectar.

El que les metadades de l'aplicació poden suportar és una decisió sobre una tasca: aquest flux de treball és una sincronització massiva, aquest és interactiu, aquest és una actualització de programari d'un origen conegut. Això és una política escrita en termes d'intenció, i és prou estable per provar-la. «Aquesta resposta serà més gran de quaranta megabytes» no és aquest tipus de política.

Comprovació 3: el flux ja existeix?

L'encaminament pot canviar per a un flux sense canviar la identitat de la connexió, i aquesta és una distinció que val la pena mantenir clara. Una connexió TCP s'identifica per les adreces i els ports dels extrems, i els paquets poden prendre un camí diferent si la taula d'encaminament canvia sota seu. El que no pot canviar invisiblement és l'estat de traducció d'adreces de xarxa: moure el trànsit a una altra sortida normalment canvia la tupla d'origen pública, i l'altre extrem veurà un parell diferent sense estat coincident.

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

Així, la regla pràctica és que un moviment a mig camí d'una connexió d'una sortida a una altra és una relació nova, no una migració. Si el disseny requereix que la mateixa connexió continuï, la decisió s'havia de prendre abans del primer SYN, i cap regla de paquets afegida després no la pot reconstruir netament.

Comprovació 4: el requisit real és latència, no sortida?

Moltíssimes peticions de «enviar el trànsit massiu a un altre lloc» són en realitat queixes que una transferència gran fa que el treball interactiu sembli lent. Això és un problema de planificació, i té una resposta de planificació: una cua justa o una política d'amplada de banda suportada al camí existent evita que un flux massiu deixi sense recursos un missatge de xat sense moure cap dels dos.

tc qdisc replace dev eth0 root cake bandwidth 100mbit

Abordar el símptoma així manté la decisió de sortida allà on la va posar la política de seguretat, i és reversible amb una ordre. Canviar la sortida per a tota una classe de trànsit és un canvi de política amb conseqüències d'autenticació, registre i regles d'accés, així que no hauria de ser la primera eina a la qual es recorre per a una queixa de latència.

Si el requisit és realment una sortida d'Internet diferent, digueu-ho amb aquestes paraules i implementeu-ho en una frontera suportada: una connexió nova des d'un flux de treball aprovat, o una aplicació que obre la seva pròpia petició per una sortida triada. Després registreu quines tasques fan servir quina sortida, perquè la propera persona no ho hagi d'inferir d'una taula d'encaminament.

Manteniu la llista de comprovació al registre del canvi: el punt de decisió, el camp o la tasca que el mou, si el flux ja existeix i si el símptoma mesurat era latència o sortida. Quatre preguntes, i una política que respongui a les quatre és una que podeu operar en lloc de defensar.