Grote downloads versus de VPN: kies het pad bij het verzoek

„Stuur de grote downloads langs de VPN en houd de kleine antwoorden erop“ klinkt als een routingbeleid, en dat is het niet. Een router beslist met informatie die op dat moment beschikbaar is: adressen, poorten, protocol, firewallmarkeringen, een geïdentificeerde stroom. De uiteindelijke omvang van een antwoord zit niet in die set, want het is nog niet aangekomen, en tegen de tijd dat de router de bytes kan meten, vervoert hij ze al. Wie op taak wil sturen, moet de beslissing naar een punt verplaatsen dat de taak kent, en de checklist hieronder laat zien of uw ontwerp zo'n punt heeft.

Waarom een router een antwoord niet kan meten

Op het moment dat een pakket een route nodig heeft, heeft de router hooguit de eerste paar pakketten van een stroom gezien. Hij kan zeggen wie met wie praat, via welk protocol, met welke markering, en hoeveel bytes er tot nu toe zijn gepasseerd. Bytes tot nu toe beschrijven het verleden. De omvang van het antwoord is een eigenschap van een antwoord dat nog niet is gegenereerd, en bij opgesplitste of streamende antwoorden is die misschien nooit vooraf bekend.

Zelfs de metadata van het protocol zelf is zwakker dan het lijkt. HTTP staat antwoorden toe waarvan de lengte niet vóór de body wordt aangekondigd, en één gebruikersactie kan veel verzoeken opleveren waarvan de gecombineerde kosten op geen enkele headerwaarde lijken. Een header behandelen als de omvang van een taak is een modelleringsfout voordat het een routingfout is.

Controle 1: is er een beslispunt dat een pad kan kiezen?

Benoem het onderdeel dat de keuze maakt, en benoem dan wat het weet op het moment van de keuze. Een updater die van een gedocumenteerde set hosts haalt, kent zijn doel voordat de overdracht begint. Een downloaddienst die metadata raadpleegt en dan het verzoek opent, kent de taak voordat de verbinding bestaat. Een samenwerkende proxy kan beleid op verzoekniveau toepassen of het antwoord cachen zonder zich voor te doen als een router.

Is het antwoord „de gateway“, dan is de checklist al mislukt. Een gateway kan bekende stromen classificeren op bestemming, markering of clientsegment en ze vanaf het eerste pakket over een gedefinieerd pad sturen, wat vaak genoeg is voor een goedgekeurde updater en nooit genoeg voor een onbekende antwoordomvang.

Controle 2: wat vertellen de metadata u werkelijk?

Applicatiebewust sturen is zo goed als de velden die het leest. De regels voor antwoordlengte in de semantiek van HTTP staan gevallen toe waarin de lengte bij de start niet beschikbaar is, en inhoudcoderingen maken het aantal overgedragen bytes sowieso anders dan de omvang van de weergave. Een beleid dat van pad wisselt wanneer een header een drempel overschrijdt, gedraagt zich dus inconsistent, en meestal juist bij de grote overdrachten die het moest opvangen.

Wat applicatiemetadata kunnen ondersteunen, is een beslissing over een taak: deze workflow is een bulk-synchronisatie, deze is interactief, deze is een software-update van een bekende bron. Dat is een beleid in termen van bedoeling, en het is stabiel genoeg om te testen. „Dit antwoord wordt groter dan veertig megabyte“ is niet dat soort beleid.

Controle 3: bestaat de stroom al?

Routing kan voor een stroom veranderen zonder de identiteit van de verbinding te veranderen, en dat onderscheid is de moeite waard om scherp te houden. Een TCP-verbinding wordt geïdentificeerd door de adressen en poorten van zijn uiteinden, en de pakketten kunnen een ander pad nemen als de routingtabel eronder verandert. Wat niet onzichtbaar kan veranderen, is de toestand van netwerkadresvertaling: verkeer naar een andere uitgang verplaatsen verandert meestal de openbare brontuple, en de verre kant ziet een andere peer zonder passende toestand.

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

De praktische regel is dus dat een verplaatsing halverwege de verbinding van de ene uitgang naar de andere een nieuwe relatie is, geen migratie. Als het ontwerp vereist dat dezelfde verbinding doorgaat, moest de beslissing vóór de eerste SYN vallen, en geen enkele later toegevoegde pakketregel kan die netjes reconstrueren.

Controle 4: is de echte eis latentie, niet de uitgang?

Heel veel verzoeken om „bulkverkeer ergens anders heen te sturen“ zijn eigenlijk klachten dat een grote overdracht interactief werk traag laat voelen. Dat is een planningsprobleem, en het heeft een planningsantwoord: eerlijke wachtrijen of een ondersteund bandbreedtebeleid op het bestaande pad houdt een bulkstroom ervan af een chatbericht uit te hongeren zonder een van beide te verplaatsen.

tc qdisc replace dev eth0 root cake bandwidth 100mbit

Het symptoom zo aanpakken laat de uitgangsbeslissing waar het beveiligingsbeleid die heeft neergezet, en het is met één opdracht terug te draaien. De uitgang wijzigen voor een hele verkeersklasse is een beleidswijziging met gevolgen voor authenticatie, logging en toegangsregels, dus het zou niet het eerste gereedschap moeten zijn bij een klacht over latentie.

Als de eis werkelijk een andere internetuitgang is, zeg dat dan in die woorden en implementeer het bij een ondersteunde grens: een nieuwe verbinding vanuit een goedgekeurde workflow, of een applicatie die haar eigen verzoek via een gekozen uitgang opent. Leg daarna vast welke taken welke uitgang gebruiken, zodat de volgende persoon het niet uit een routingtabel hoeft af te leiden.

Houd de checklist in het wijzigingsrecord: het beslispunt, het veld of de taak die het stuurt, of de stroom al bestaat, en of het gemeten symptoom latentie of uitgang was. Vier vragen, en een beleid dat alle vier beantwoordt, is er een die u kunt bedienen in plaats van verdedigen.