Descargas grandes fronte á VPN: escolla a ruta na petición

«Manda as descargas grandes pola beira da VPN e mantén as respostas pequenas nela» soa a política de enrutamento, e non o é. Un enrutador decide coa información dispoñible nese momento: enderezos, portos, protocolo, marcas de firewall, un fluxo identificado. O tamaño final dunha resposta non está nese conxunto, porque aínda non chegou, e cando o enrutador podería medir os bytes xa os está transportando. Se quere dirixir por tarefa, a decisión debe trasladarse a un punto que coñeza a tarefa, e a lista de comprobación de abaixo serve para saber se o seu deseño ten ese punto.

Por que un enrutador non pode medir unha resposta

No momento en que un paquete necesita unha ruta, o enrutador viu como moito os primeiros paquetes dun fluxo. Pode dicir quen fala con quen, por que protocolo, con que marca e cantos bytes pasaron ata agora. Os bytes ata agora describen o pasado. O tamaño da resposta é unha propiedade dunha resposta que aínda non se xerou, e en respostas fragmentadas ou en streaming pode que nunca se coñeza de antemán.

Mesmo os metadatos do propio protocolo son máis febles do que parecen. HTTP permite respostas cuxa lonxitude non se anuncia antes do corpo, e unha soa acción do usuario pode producir moitas peticións cuxo custo combinado non se parece a ningún valor de cabeceira. Tratar unha cabeceira como o tamaño dunha tarefa é un erro de modelado antes que un erro de enrutamento.

Comprobación 1: hai un punto de decisión que poida escoller unha ruta?

Nomee o compoñente que fará a escolla, e despois nomee que sabe no momento de escoller. Un actualizador que descarga dun conxunto documentado de hosts coñece o seu propósito antes de que comece a transferencia. Un servizo de descarga que consulta metadatos e logo abre a petición coñece a tarefa antes de que exista a conexión. Un proxy colaborador pode aplicar políticas a nivel de petición ou cachear a resposta sen finxir ser un enrutador.

Se a resposta é «a pasarela», a lista xa fallou. Unha pasarela pode clasificar fluxos coñecidos por destino, marca ou segmento de cliente e envialos por unha ruta definida desde o primeiro paquete, o que a miúdo abonda para un actualizador aprobado e nunca abonda para un tamaño de resposta descoñecido.

Comprobación 2: que lle din realmente os metadatos?

O direccionamento consciente da aplicación é tan bo como os campos que le. As regras de lonxitude de resposta de a semántica de HTTP permiten casos nos que a lonxitude non está dispoñible no inicio, e as codificacións de contido fan que a conta de bytes transferidos sexa distinta do tamaño da representación de todos os xeitos. Por iso unha política que cambia de ruta cando unha cabeceira cruza un limiar comportarase de forma inconsistente, e sobre todo xusto nas transferencias grandes que debía detectar.

O que os metadatos da aplicación si poden sustentar é unha decisión sobre unha tarefa: este fluxo de traballo é unha sincronización masiva, este é interactivo, este é unha actualización de software dunha orixe coñecida. Iso é unha política escrita en termos de intención, e é abondo estable para probala. «Esta resposta será maior de corenta megabytes» non é ese tipo de política.

Comprobación 3: o fluxo xa existe?

O enrutamento pode cambiar para un fluxo sen cambiar a identidade da conexión, e esa distinción convén mantela clara. Unha conexión TCP identifícase polos enderezos e portos dos seus extremos, e os paquetes poden tomar outra ruta se a táboa de enrutamento cambia por baixo. O que non pode cambiar de forma invisible é o estado de tradución de enderezos de rede: mover o tráfico a outra saída adoita cambiar a tupla de orixe pública, e o extremo remoto verá outro par sen estado coincidente.

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

Así que a regra práctica é que un cambio a metade da conexión dunha saída a outra é unha relación nova, non unha migración. Se o deseño esixe que a mesma conexión continúe, a decisión tiña que tomarse antes do primeiro SYN, e ningunha regra de paquetes engadida despois pode reconstruíla limpiamente.

Comprobación 4: o requisito real é latencia, non saída?

Moitísimas peticións de «manda o tráfico masivo a outro sitio» son en realidade queixas de que unha transferencia grande fai que o traballo interactivo pareza lento. Iso é un problema de planificación, e ten unha resposta de planificación: unha cola xusta ou unha política de ancho de banda soportada na ruta existente evita que un fluxo masivo deixe sen recursos unha mensaxe de chat sen mover ningún dos dous.

tc qdisc replace dev eth0 root cake bandwidth 100mbit

Abordar o síntoma así mantén a decisión de saída onde a puxo a política de seguridade, e é reversible cun só comando. Cambiar a saída para toda unha clase de tráfico é un cambio de política con consecuencias de autenticación, rexistro e regras de acceso, así que non debería ser a primeira ferramenta á que se recorre ante unha queixa de latencia.

Se o requisito é de verdade unha saída de Internet distinta, diga iso con esas palabras e implémenteo nunha fronteira soportada: unha conexión nova desde un fluxo de traballo aprobado, ou unha aplicación que abre a súa propia petición por unha saída escollida. Despois rexistre que tarefas usan que saída, para que a seguinte persoa non teña que inferilo dunha táboa de enrutamento.

Manteña a lista de comprobación no rexistro do cambio: o punto de decisión, o campo ou a tarefa que o impulsa, se o fluxo xa existe e se o síntoma medido era latencia ou saída. Catro preguntas, e unha política que responde ás catro é unha que pode operar en lugar de defender.