Statická IP adresa v GCP versus rychlost VPN: tři proměnné, jeden test

Přenos se po rezervaci adresy zrychlil a závěr se napsal sám. Jenže stejná změna také přepnula tunel z UDP na TCP, přesunula test na jiný večer a možná ho umístila na VM v jiné zóně. Rezervace externí adresy řeší problém životního cyklu: udržuje koncový bod stejný napříč restarty. Nemá žádný mechanismus, který by zrychlil pakety, takže rozdíl v rychlosti v tom experimentu patří ostatním proměnným a rozhodnutí před vámi je, kterou testovat příště.

Co rezervovaná adresa skutečně kupuje

Compute Engine rozlišuje efemérní adresy, přidělované a uvolňované s instancí, od statických adres, které rezervujete a držíte. Tento rozdíl se týká udržení a fakturace, ne cesty, kterou paket jde. Stabilní koncový bod je opravdu užitečný pro DNS záznamy, profily vzdáleného přístupu, seznamy povolených partnerů a pravidla firewallu, která by se při restartu VM neměla měnit.

To jsou dobré důvody jednu rezervovat. Žádný z nich není důvodem propustnosti.

Držte vrstvu, adresu a transport jako tři proměnné

Google Cloud prodává také Premium a Standard Network Service Tiers a obě jdou k internetu různými cestami s různou dostupností funkcí. Statické adresování je vůči oběma ortogonální, takže statickou adresu a Premium berte jako nesouvisející fakta o VM, ne jako synonyma. Zapište skutečnou vrstvu, region a jakékoli propojení či attachment ve hře, protože ty popisují cestu způsobem, jakým štítek adresy nikdy nebude.

Tři proměnné, tři samostatné experimenty, jinak je výsledek příběh, a ne měření.

Navrhněte test, který odpovídá na jednu otázku

Držte VM, adresu, polohu klienta, cíl a zátěž pevně, zatímco porovnáváte schválené profily UDP a TCP. Potřebujete jak naslouchající server pro každý transport, tak odpovídající pravidla firewallu; upravit klíčové slovo v klientovi a nechat naslouchající stranu beze změny testuje jen vaši trpělivost. Použijte opakovatelný přenos a zaznamenejte směr, trvání, jednotlivé versus paralelní toky a jednotky, protože MB/s a Mb/s se liší osminásobně.

Sledujte také CPU VM, protože malá instance se na šifrování nebo práci softirq nasytí dávno před sítí a tento strop bude vypadat přesně jako limit poskytovatele.

Počítadla retransmisí a ztrát z VM a klienta oddělují problém cesty od problému transportu a ukazatel průběhu to nedokáže. Použitelná posloupnost s iperf3 trvá zhruba deset minut na transport. Spusťte server na vzdálené straně, nechte klienta běžet třicet sekund v každém směru a každý směr opakujte třikrát. První běh každé série zahoďte, potom porovnejte rychlosti odesílatele a příjemce společně s počtem retransmisí, který vypisují běhy TCP.

Proč se UDP a TCP mechanicky liší

OpenVPN přes UDP nese datagramy a nechává vlastnímu transportu aplikace, aby se vypořádal se ztrátami. Přes TCP leží spolehlivý tok tunelu pod už spolehlivým tokem aplikace, takže jeden ztracený segment zastaví vše za ním, zatímco vnější spojení retransmituje podle svého vlastního rozvrhu. Toto chování na čele fronty je vlastností tunelování TCP uvnitř TCP, nikoli politikou poskytovatele. Zpracování MTU a MSS se mezi oběma režimy také liší, což mění chování fragmentace na stejné cestě.

Rychlejší pokus s TCP tedy dokazuje, že TCP ten den na té cestě bylo rychlejší, a nic obecnějšího.

Napište výsledek tak, aby přežil recenzi

Obhajitelný závěr má tvar: tento profil na této velikosti stroje, na této síťové vrstvě udržel tuto změřenou zátěž v tomto směru za těchto podmínek. Cokoli širšího vyžaduje více běhů, než jeden večer nabídne. Pokud pomalejší případ zůstane nevysvětlený, ponechte ho jako pozorování s důkazy o paketech a zdrojích, místo abyste si vymýšleli omezení, které žádný dokument poskytovatele nepopisuje.

Stabilita adresy a rychlost přenosu mohou být pro stejné nasazení důležité obě a užitečné rozhodnutí je, kterou z nich každou změnou kupujete.