Pārsūtīšana kļuva ātrāka pēc tam, kad adrese tika rezervēta, un secinājums pats sevi uzrakstīja. Tikai tā pati izmaiņa arī pārslēdza tuneli no UDP uz TCP, pārcēla testu uz citu vakaru un, iespējams, nolaidās uz VM citā zonā. Ārējas adreses rezervēšana atrisina dzīves cikla problēmu: tā saglabā galapunktu to pašu starp pārstartēšanām. Tam nav nekāda mehānisma, kas paātrinātu paketes, tāpēc ātruma atšķirība šajā eksperimentā pieder citiem mainīgajiem, un lēmums jūsu priekšā ir, kuru testēt nākamo.

Ko rezervēta adrese patiešām nopērk

Compute Engine atšķir efemēras adreses, kas tiek piešķirtas un atbrīvotas kopā ar instanci, no statiskām adresēm, kuras jūs rezervējat un paturat. Šī atšķirība attiecas uz saglabāšanu un norēķiniem, nevis uz ceļu, pa kuru iet pakete. Stabils galapunkts patiešām ir noderīgs DNS ierakstiem, attālinātās piekļuves profiliem, partneru atļauju sarakstiem un ugunsmūra noteikumiem, kuriem nevajadzētu mainīties, kad VM tiek pārstartēta.

Tie ir labi iemesli rezervēt vienu. Neviens no tiem nav caurlaidības iemesls.

Turiet līmeni, adresi un transportu kā trīs mainīgos

Google Cloud pārdod arī Premium un Standard tīkla pakalpojumu līmeņus, un abi iet dažādus ceļus uz internetu ar atšķirīgu funkciju pieejamību. Statiskā adresēšana ir ortogonāla abiem, tāpēc statisko un Premium uztveriet kā nesaistītus faktus par VM, nevis kā sinonīmus. Pierakstiet faktisko līmeni, reģionu un jebkuru interconnect vai attachment, kas ir spēlē, jo tie apraksta ceļu tā, kā adreses etiķete nekad neaprakstīs.

Trīs mainīgie, trīs atsevišķi eksperimenti, citādi rezultāts ir stāsts, nevis mērījums.

Izstrādājiet testu, kas atbild uz vienu jautājumu

Turiet VM, adresi, klienta atrašanās vietu, galamērķi un darba slodzi fiksētus, kamēr salīdzināt apstiprinātos UDP un TCP profilus. Nepieciešams gan servera klausītājs katram transportam, gan atbilstoši ugunsmūra noteikumi; klienta atslēgvārda maiņa un klausītāja atstāšana nemainītā pārbauda tikai jūsu pacietību. Izmantojiet atkārtojamu pārsūtīšanu un pierakstiet virzienu, ilgumu, atsevišķas pret paralēlām plūsmām un mērvienības, jo MB/s un Mb/s atšķiras astoņas reizes.

Vērojiet arī VM procesoru, jo maza instance piesātinās šifrēšanas vai softirq darbā daudz agrāk nekā tīkls, un šie griesti izskatīsies tieši kā pakalpojumu sniedzēja ierobežojums.

VM un klienta retransmisijas un zudumu skaitītāji atdala ceļa problēmu no transporta problēmas, un progresa josla to nevar. Strādājoša secība ar iperf3 aizņem apmēram desmit minūtes uz transportu. Sāciet serveri tālajā pusē, laidiet klientu trīsdesmit sekundes katrā virzienā un atkārtojiet katru virzienu trīs reizes. Izmetiet katras sērijas pirmo palaidienu, pēc tam salīdziniet sūtītāja un uztvērēja ātrumus kopā ar retransmisiju skaitu, ko izdrukā TCP palaidiens.

Kāpēc UDP un TCP mehāniski atšķiras

OpenVPN pār UDP nes datagrammas un atstāj pašas lietotnes transportam rīkoties ar zudumiem. Pār TCP tuneļa uzticamā plūsma atrodas zem jau uzticamas lietotnes plūsmas, tāpēc viens pazaudēts segments aptur visu aiz tā, kamēr ārējais savienojums pārsūta pēc sava grafika. Šī rindas galvas uzvedība ir TCP tunelēšanas TCP iekšienē īpašība, nevis pakalpojumu sniedzēja politika. Arī MTU un MSS apstrāde atšķiras starp diviem režīmiem, kas maina fragmentācijas uzvedību tajā pašā ceļā.

Tāpēc ātrāks TCP mēģinājums pierāda tikai to, ka TCP tajā dienā tajā ceļā bija ātrāks, un neko vispārīgāku.

Rakstiet rezultātu tā, lai tas pārdzīvotu pārskatīšanu

Aizstāvams secinājums ir ar formu: šis profils, šajā mašīnas izmērā, šajā tīkla līmenī, noturēja šo izmērīto darba slodzi šajā virzienā šajos apstākļos. Viss plašāks prasa vairāk palaidienu, nekā viens vakars var dot. Ja lēnākais gadījums paliek neizskaidrots, paturiet to kā novērojumu ar tā pakešu un resursu pierādījumiem, nevis izdomājiet ierobežojumu, ko neapraksta neviens pakalpojumu sniedzēja dokuments.

Adreses stabilitāte un pārsūtīšanas ātrums var būt svarīgi abi vienai ieviešanai, un noderīgais lēmums ir, kuru no tiem jūs pērkat ar katru izmaiņu.

Saistītie raksti