Statika IP en GCP kontraŭ VPN-rapideco: tri variabloj, unu testo

La transigo plirapidiĝis post kiam la adreso estis rezervita, kaj la konkludo skribiĝis mem. Sed la sama ŝanĝo ankaŭ ŝaltis la tunelon de UDP al TCP, movis la teston al alia vespero kaj eble surteriĝis sur VM en alia zono. Rezervi eksteran adreson solvas vivociklan problemon: ĝi tenas la finpunkton sama tra restartoj. Ĝi havas neniun mekanismon, kiu akcelus pakaĵojn, do la rapideca diferenco en tiu eksperimento apartenas al la aliaj variabloj, kaj la decido antaŭ vi estas kiun testi poste.

Kion rezervita adreso efektive aĉetas

Compute Engine distingas efemerajn adresojn, atribuitajn kaj liberigitajn kun la instanco, de statikaj adresoj, kiujn vi rezervas kaj tenas. Tiu diferenco temas pri retenado kaj fakturado, ne pri la vojo, kiun pakaĵo prenas. Stabila finpunkto vere utilas por DNS-rikordoj, profiloj de fora aliro, partneraj permeslistoj kaj fajroŝirmilaj reguloj, kiuj ne devus ŝanĝiĝi kiam VM restartiĝas.

Tiuj estas bonaj kialoj rezervi unu. Neniu el ili estas trapa kialo.

Tenu tavolon, adreson kaj transporton kiel tri variablojn

Google Cloud ankaŭ vendas la retservajn tavolojn Premium kaj Standard, kaj ambaŭ sekvas malsamajn vojojn al la interreto kun malsama funkciodisponebleco. Statika adresado estas ortogonala al ambaŭ, do traktu statikan kaj Premium kiel neligitajn faktojn pri VM, ne kiel sinonimojn. Notu la realan tavolon, la regionon kaj ajnan interkonekton aŭ aldonaĵon en uzo, ĉar ili priskribas la vojon tiel, kiel la adresa etikedo neniam faros.

Tri variabloj, tri apartaj eksperimentoj, alie la rezulto estas rakonto, ne mezuro.

Projektu teston, kiu respondas unu demandon

Tenu VM, adreson, klientan lokon, celon kaj laborkvanton fiksaj dum vi komparas aprobitajn UDP- kaj TCP-profilojn. Necesas kaj servila aŭskultanto por ĉiu transporto kaj kongruaj fajroŝirmilaj reguloj; ŝanĝi klientan ŝlosilvorton kaj lasi la aŭskultanton senŝanĝa testas nur vian paciencon. Uzu ripeteblan transigon kaj notu direkton, daŭron, unuopajn kontraŭ paralelaj fluoj kaj la unuojn, ĉar MB/s kaj Mb/s diferencas per faktoro de ok.

Observu ankaŭ la CPU de la VM, ĉar malgranda instanco saturiĝas je ĉifrado aŭ softirq-laboro longe antaŭ la reto, kaj tiu plafono aspektos precize kiel limo de provizanto.

Retranssendaj kaj perdkalkuliloj de la VM kaj la kliento apartigas vojproblemon de transportproblemo, kaj progresbreto tion ne povas. Uzebla sinsekvo kun iperf3 daŭras ĉirkaŭ dek minutojn por transporto. Startigu la servilon ĉe la malproksima flanko, lasu la klienton kuri tridek sekundojn en ĉiu direkto kaj ripetu ĉiun direkton tri fojojn. Forĵetu la unuan kuron de ĉiu serio, poste komparu sendan kaj ricevan indicojn kune kun la retranssendokvanto, kiun presas la TCP-kuroj.

Kial UDP kaj TCP mekanike diferencas

OpenVPN super UDP portas datagramojn kaj lasas al la propra transporto de la aplikaĵo trakti perdon. Super TCP, la fidinda fluo de la tunelo kuŝas sub jam fidinda aplikaĵa fluo, do unu perdita segmento haltigas ĉion malantaŭ ĝi dum la ekstera konekto retranssendas laŭ sia propra horaro. Tiu konduto ĉe la kapo de la vico estas eco de tunelado de TCP ene de TCP, ne politiko de provizanto. Ankaŭ la traktado de MTU kaj MSS diferencas inter la du reĝimoj, kio ŝanĝas fragmentiĝan konduton sur la sama vojo.

Pli rapida TCP-provo do pruvas, ke TCP estis pli rapida tiun tagon sur tiu vojo, kaj nenion pli ĝeneralan.

Skribu la rezulton tiel, ke ĝi postvivos revizion

Defendebla konkludo havas formon: ĉi tiu profilo, sur ĉi tiu maŝingrandeco, sur ĉi tiu reta tavolo, tenis ĉi tiun mezuritan laborkvanton en ĉi tiu direkto sub ĉi tiuj kondiĉoj. Io pli larĝa bezonas pli da kuroj ol unu vespero povas doni. Se la pli malrapida kazo restas neklarigita, konservu ĝin kiel observon kun ĝiaj pakaĵaj kaj rimedaj pruvoj anstataŭ inventi limigon, kiun neniu dokumento de provizanto priskribas.

Adresa stabileco kaj transiga rapideco povas ambaŭ gravi por la sama deplojo, kaj la utila decido estas kiun el ili vi aĉetas per ĉiu ŝanĝo.