I dagens hets för att snabba upp webbplatsernas laddningstid, är varje millisekund viktig. Teamet på Kinsta testade och studerade webbplatshastighetes effekt på försäljning, konverteringar, användarupplevelse och användarengagemang.
Men det finns en varning. Även om optimering av webbplatser är viktigt för förbättrad hastighet, är det inte den enda aspekten vi bör titta på. Hårdvaru- och nätverksinfrastrukturen som stöder vår webbplats och ansluter den till våra besökare spelar roll.
Idag diskuterar vi varför Googles investera en massa pengar i sin nätverksinfrastruktur, och några av skillnaderna mellan Google Cloud Platforms premiumnätverk och standardnätverk.
Bandbredd och Latens (nyckelkriterier för Hosting-infrastrukturens prestanda)
Innan vi dyker ner i detaljerna om Google Clouds nätverk, är det viktigt att först förstå följande två begrepp: bandbredd och latens.
Bandbredd är genomströmningskapaciteten i nätverket, mätt i Mbps; medan latens är förseningen eller summan av alla förseningar som olika routrar längs vägen lägger till våra webbförfrågningar och svar.
Bildligt talat kan bandbredd eller genomströmning avbildas som en vattenslangs kapacitet för att tillåta en viss volym vatten strömma fram per sekund. Latens kan jämföras med fördröjningen från det ögonblick som vattenröret öppnas tills det börjar flöda igenom.
På grund av den lilla overheaden för att upprätta anslutningen mellan olika routrar, lägger varje ”hopp” längs vägen till en liten mängd latens till de slutliga förfrågningarna och svaren.
Så ju större distans mellan besökaren och servern där webbplatsen är hostad, desto större blir latensen. Och ju mer fragmenterat nätverket är, desto större latens.
Vi kan föreställa oss detta genom att använda ett verktyg som heter traceroute, eller tracert på windows. I följande skärmdumpar använde vi det för att inspektera routingförseningar av två förfrågningar, gjorda från Europa. Specifikt:
en till weibo.com:
och en annan till bbc.co.uk:
Som vi förväntade oss är antalet hopp till webbplatsen i Kina nästan 2x större än för den europeiska. Så det är den extra latensen jämfört med en begäran till en webbplats hostad i Storbritannien.
De tre kolumnerna som tracert visar representerar tre roundtrips (RTT). Varje rad representerar olika routrar eller hopp längs vägen. De har ofta webbadresser som hjälper oss att avgöra var den specifika routern finns.
Roundtrip-tiden till routrar i Kina / Hong Kong tar nära en tredjedel av en sekund.
Vi använde pingdom-verktyg för att ladda en webbplats hostad i London från Pingdoms Australien-plats, för att försöka fastställa den andel som nätverket har i de totala laddningstiderna för en webbplats.
Detta är data för en liten CSS-fil som laddas i detta testscenario. Anslutningsdelen har den högsta andelen i att ladda den här resursen, följt av SSL och väntetiden. Hela tiden upp till, och inklusive väntetiden, tillsammans, är också känd som time to first byte (TTFB), vilket inkluderar nätverkslatens.
När Internetleverantörer annonserar Internetanslutningens hastighet annonserar de vanligtvis sin bandbredd (”slangens bredd”, kommer du ihåg?) vilket verkligen inte är ett mått på hastighet. Att öka rörets bredd kan bara öka webbplatsens hastighet till en viss grad. Det är mer användbart om vi behöver skicka en stor mängd data per sekund, som när vi strömmar HD-videoinnehåll. Men för användare som spelar multiplayer-spel online i realtid, kommer latens att betyda mycket mer.
Mike Belshe, en av samförfattarna i HTTP/2-specifikationen och SPDY-protokollet, gjorde en analys av effekten av ökad bandbredd på webbplatsladdningshastighet vs effekten av minskad latens på webbplatsladdningshastigheten.
Här är Belshes resultat i ett fint diagram :
Det bör vara tydligt att förbättra webbplatsens hastighet genom att öka bandbredden inte är det mest effektiva sättet att nå bättre prestanda. Å andra sidan, genom att minska RTT (roundtrip-tiden) eller latens, kan vi se konsekventa förbättringar av sidladdningstiden.
Nätverk vs Internet Peering vs Transit
För att förstå vårt ämne lite bättre måste vi förklara grunderna i Internettopologi. I sin kärna består det globala internet av flera globala, regionala och lokala nätverk.
Räknat 2018 finns det mer än 60 000 AS (autonoma system). Dessa nätverk tillhör regeringar, universitet, Internetleverantörer.
Bland dessa skiljer vi Nivå 1, Nivå 2 och Nivå 3-nätverk åt. Dessa nivåer representerar varje nätverks oberoende av internet som helhet.
- Nivå 1-nätverk är oberoende i den meningen att de inte behöver betala för att ansluta till någon annan punkt på internet.
- Nivå 2-nätverk har peering-avtal med andra Internetleverantörer, men de betalar också för transit.
- Nivå 3-nätverk, den lägsta nivån, ansluter till resten av internet genom att köpa transit från högre nivåer. De är som konsumenter som måste betala för att få tillgång till internet.
Peering-förhållande innebär att två nätverk utbyter trafik på lika villkor, så att ingen av dem betalar den andra för transit, och returnerar samma tjänst gratis.
Den största fördelen med peering är drastiskt lägre latens.
I bilden ovan ser vi ett klassiskt scenario, där webbförfrågan går igenom det hierarkiska nätverket av Internetleverantörer på nivå 1, nivå 2 och nivå 3 för att hämta en webbplats hostad i ett datacenter på en avlägsen plats.
Pilar representerar webbförfrågans resa. Streckade pilar representerar transitanslutningarna, och linjerade pilar representerar peeringanslutningar.
När Nivå 1-leverantören har nåtts är dess förhållande till en annan leverantör på samma nivå ett peer-förhållande. Nivå 1-nätverk ansluter till andra och vidarebefordrar deras önskemål uteslutande genom peering-partners. De kan nå alla andra nätverk på internet utan att betala för transit.
Vi kan också se ett alternativt scenario, där två Nivå 2-leverantörer har ett peering-avtal, betecknat med turkosfärg. Antalet hopp i detta scenario är lägre och webbplatsen tar mycket mindre tid att ladda.
Border Gateway Protocol
BGP är ett protokoll som det sällan talas om, utom i mycket tekniska sammanhang. Detta protokoll sitter dock i själva kärnan av internet som vi känner till det i dag. Det är grundläggande för vår förmåga att få tillgång till nästan allt på internet och det är en av de sårbara länkarna i internetprotokollstacken.
Border Gateway Protocol definieras i IETFs begäran om kommentarer #4271 från 2006 och har sedan dess haft flera uppdateringar. Som RFCn säger:
”Den primära funktionen för ett BGP-talsystem är att byta ut nätverksnåbarhetsinformation med andra BGP-system.”
För att uttrycka det enkelt är BGP ett protokoll som ansvarar för att bestämma den exakta vägen för en nätverksförfrågan, över hundratusentals möjliga noder till sin destination.
Vi kan avbilda varje nod som ett autonomt system eller ett nätverk som skulle bestå av flera noder eller routrar, servrar och system som är anslutna till det.
I BGP-protokollet finns det ingen automatisk upptäckt algoritm (en mekanism eller ett protokoll genom vilket varje nyansluten nod kan upptäcka intilliggande noder att anslutas genom), istället måste varje BGP-peer ha sina peers specificerade manuellt. När det gäller sökvägsalgoritmen, för att citera en Cisco-expert:
”BGP har inte ett enkelt mått för att bestämma vilken väg som är bäst. Istället annonserar den en omfattande uppsättning attribut med varje rutt och använder en komplex algoritm som består av upp till 13 steg för att bestämma vilken väg som är bäst”.
Autonoma system överför routingdata till sina peers, men det finns inga hårda regler som måste följas när det gäller valet av sökväg. BGP är ett system som är implicit baserat på förtroende och detta kan vara en av de största säkerhetsbristerna i dagens internet. En stöld år 2018, när MyEtherWallet.com-trafiken kapades, och mer än 200 Ether stals (värd $152,000) exponerade denna sårbarhet.
I själva verket resulterar denna svaghet i BGP oftare i olika nätverk (AS) som avger BGP-data med andra intressen i åtanke än effektiviteten och hastigheten för slutanvändarna. Dessa kan vara kommersiella intressen, som betald transit eller till och med politiska eller säkerhetsmässiga överväganden.
Utvecklingen av Cloud-beräkning, CDN och Edge-marknaden
På grund av IT-marknadens växande behov, från webbindustrin, onlinespel, till Internet of Things och annat, blev marknadsutrymmet för tjänsteleverantörer och produkter som löser latensproblemet uppenbart.
År efter år ser vi fler molnbaserade produkter som cachar statiska resurser nära besökarna (Innehållsleveransnätverk) eller för den faktiska beräkningen närmare slutanvändarna. En sådan produkt är Cloudflares Workers som exekverar V8 javascript-motorkompatibel kod på Cloudflares nätverk av edge-noder. Detta innebär att även WebAssembly eller GO-kod kan exekveras mycket nära besökaren.
Lambda@Edge från Amazon är ett annat exempel på denna trend, liksom Intel och Alibaba Cloud-partnerskap för att leverera Joint Edge Computing Platform som riktar sig mot IoT-marknaden.
En annan värt att nämna är Googles globala nätverk av cachningsnoder som fungerar både som ett CDN och som ett videocachning & leveransnätverk för dess dotterbolag YouTube.
För att illustrera hur raffinerad och avancerad molnindustrin har blivit, och hur mycket den har lyckats minska nätverkets latens för slutanvändare, låt oss ta en titt på GaaS.
GaaS är kort för Spel som en tjänst (Gaming as a Service) Det är ett molnerbjudande som ger användarna möjlighet att spela spel som hostas och exekveras i molnet.
Alla som någonsin har köpt TV eller en videoprojektor för spel, eller spenderat lite tid med att konfigurera Miracast eller annan castinganslutning mellan en TV och en annan enhet, kommer att veta hur kritisk latensen är. Ändå finns det GaaS-leverantörer som nu erbjuder spel som streamas på 4k-upplösning och 60Hz uppdateringsfrekvens… och spelarna behöver inte investera i hårdvara.
Dramatiken i det senaste Huawei-förbudet från USA uppmärksammade frågan om 5G-nätverk och det brådskande behovet av en tydlig väg för att uppgradera världens nätverksinfrastruktur.
Sensorer som förmedlar stora mängder information i realtid, med minimal latens, för att samordna smarta städer, smarta hus, autonoma fordon kommer att bero på täta nätverk av edge-enheter. Latens är det nuvarande taket för saker som självkörande bilar, med olika sensorers information, LIDAR-data, att bearbeta dessa data vs data från andra fordon.
Innehållsleveransnätverk och Molnlagrings-leverantörer ligger i framkanten av denna tävling. Vi har redan pratat om QUIC/HTTP3-protokollet som branschledarna lanserar och som kan kontrollera förfrågan-svarscykeln.
Hur löser molnleverantörer latensproblemet?
AWS kan vara den största molnleverantören efter marknadsandelar. I 2016 investerade de i Hawaiki Transpacific Submarine Cable System som syftar till att ge större bandbredd och minska latensen mellan Hawaii, Australien och Nya Zeeland, vilket var deras första investering i underhavsinfrastruktur. Det gick live 2018.
Vid den tiden var Google redan långt före sin konkurrens i att lägga basen under havet. Ett år före Amazons första investering publicerade ITWorld en artikel med titeln: ”Googles datacenter växer för fort för normala nätverk, så de bygger sitt eget”.
I själva verket var det 2005 som en teknisk journalist, Mark Stephens, aka Robert X Cringely skrev i sin krönika för PBS.org, och kommenterade Googles intensiva spendering på den mörka fibern (utlagd men oanvänd fiberoptisk infrastruktur):
”Detta är mer än en till Akamai eller till och med en Akamai på steroider. Detta är en dynamiskt driven, intelligent, termonukleär Akamai med en dedikerad bak-kanals och applikationsspecifik hårdvara. Det kommer att finnas Internet, och sedan kommer det att finnas Googles Internet, ovanpå det ”.
År 2010, i en artikel om zdnet.com, säger Tom Foremski:
”Google är ett av de företag som äger en stor bit av Internet”, och fortsätter: ”Google har fokuserat på att bygga den mest effektiva, lägsta kostnaden för att driva ett privat Internet. Denna infrastruktur är nyckeln till Google, och det är nyckeln till att förstå Google.”
Vid den tiden tog Cringleys artikel upp några farhågor om att Google försökte ta över internet men sakerna blev tydligare när företaget lanserade Google Fiber, Googles försök att erövra ISP-marknaden i de största amerikanska städerna. Projektet har sedan dess avtagit, så mycket att TechRepublic publicerade en post-mortem av projektet 2016, men investeringar i infrastrukturen, nu på global nivå, har inte saktat ner.
Googles senaste investering, som kommer gå live i år är en ryggrad som förbinder Los Angeles i USA och Valparaiso i Chile, med en gren för framtida anslutning till Panama.
”Internet beskrivs vanligen som ett moln. I verkligheten är det en serie våta, bräckliga rör, och Google håller på att äga ett alarmerande antal av dem.” – VentureBeat
Varför investerar Google så mycket i sin nätverksinfrastruktur?
Vi vet alla att Google är sökmotorn nummer ett men dessutom:
- Äger de den största videoplattformen
- Är de den största e-postleverantören (Gmail och Google Workspace)
- Tjänar de en hel del pengar på sina molnberäkningsprodukter (årlig inkomst på över $8 miljarder dollar)
Därför behöver det den minsta möjliga latens och maximal bandbredd. Google vill också äga den faktiska infrastrukturen, eftersom dess ”omättliga hunger” för mer bandbredd och latens sätter Google och dess konkurrenter bland storskaliga företag som Amazon eller Microsoft, i en position där de behöver komma med helt anpassade hårdvaru-och mjukvarulösningar.
Points of Presence, eller edge PoP-noder, ligger i framkanten av Googles globala privata kabelnätverk. Där fungerar de som inmatnings- och utgångspunkter för trafik som ansluter till Googles datacenter.
Moores lag är en observation av Gordon Moore, medgrundare av Intel, som säger att vartannat år kommer antalet transistorer vi kan sätta på en integrerad krets att fördubblas. I årtionden var denna förväntan sann, men nu är dataindustrin på väg att utsätta Moores lag för ett hårt test som kanske leder till dess slut inom en nära framtid. NVIDIAs VD förklarade Moores lag död tidigare i år.
Så hur relaterar detta till molnindustrin och Googles nätverksinfrastruktur?
Vid Open Networking Foundation Connect-evenemanget i December 2018 erkände Googles Vice ordförande och TechLead for Networking, Amin Vahdat, slutet på Moores lag och förklarade företagets problem:
”Vår beräkningsefterfrågan fortsätter att växa i en häpnadsväckande takt. Vi kommer att behöva acceleratorer och tätare kopplade beräkningar. Nätverket kommer att spela en avgörande roll för knyta ihop dessa två”.
Ett sätt för molnleverantörer att hålla jämna steg med den ökande efterfrågan på beräkningskraft är klustring. Klustring, för att uttrycka det enkelt, innebär att man sätter ihop flera datorer för att arbeta med ett enda problem, för att exekvera processer hos en enda applikation. Självklart är en förutsättning för att dra nytta av en sådan konfiguration låg latens eller seriöst god nätverkskapacitet.
När Google började designa sin egen hårdvara, tänkte nätverkshårdvaruleverantörer 2004 i termer av gäller lådor, och routrar och switchar behövde hanteras individuellt via kommandoraden. Fram till dess köpte Google kluster av switchar från leverantörer som Cisco och spenderade en förmögenhet för varje switch. Men utrustningen kunde fortfarande inte hålla jämna steg med tillväxten.
Google behövde en annan nätverksarkitektur. Efterfrågan på Googles infrastruktur växte exponentiellt (en forskningsrapport från Google från 2015 hävdar att deras nätverkskapacitet växte 100x på tio år) och deras tillväxt var så snabb att kostnaden för att köpa den befintliga hårdvaran också uppmanade dem att skapa egna lösningar. Google började bygga anpassade switchar från kiselchips, och antog en annan nätverkstopologi som var mer modulär.
Googles ingenjörer började bygga på en gammal telefonnätverksmodell som heter Clos Network, vilket minskar antalet portar som krävs per switch:
”Fördelen med Clos Network är att du kan använda en uppsättning identiska och billiga enheter för att skapa trädet och få hög prestanda och motståndskraft som annars skulle kosta måste mer att bygga.”— Clos Networks: Vad som är gammalt blir som nytt igen, Network World
För denna nya modulära maskinvara måste Googles team också omdefiniera befintliga protokoll och bygga ett anpassat nätverksoperativsystem. Utmaningen de stod inför var att ta ett stort antal switchar och routrar och driva dem som om de var ett enda system.
Den anpassade nätverksstacken tillsammans med behovet av omdefinierade protokoll ledde Google till att vända sig till Software Defined Networking (SDN). Här är en keynote från Amin Vahdat, Google Vice President, Engineering Fellow och nätverksinfrastruktur-teamledare, från 2015, som förklarar alla utmaningar och lösningar de kom fram till:
För de mest nyfikna är detta intressanta blogginlägg värt att läsa.
Espresso
Espresso är den senaste pelaren i Googles SDN. Det gör att Googles nätverk kan gå utöver de begränsningar som fysiska routrar har i att lära och samordna trafiken som kommer in och går ut till Googles peering-partners.
Espresso gör det möjligt för Google att mäta anslutningarnas prestanda i realtid, och basera beslutet för den bästa Point of Presence för en viss besökare på realtidsdata. På så sätt kan Googles nätverk reagera dynamiskt på olika kongestioner, avmattningar eller avbrott i sina peering/ISP-partners.
Dessutom gör Espresso det möjligt att använda Googles distribuerade datorkraft för att analysera alla sina peers nätverksdata. All routingkontroll och logik finns inte längre i enskilda Routrar och Border Gateway Protocol utan överförs istället till Googles datornätverk.
”Vi utnyttjar vår storskaliga datorinfrastruktur och signaler från själva applikationen för att lära oss hur enskilda flöden fungerar, vilket avgörs av slutanvändarens uppfattning om kvalitet.”— Espresso gör Google Cloud snabbare, 2017
Hur är detta relevant för Google Cloud Network?
Vad vi hittills täckt är för att lyfta fram alla problem och utmaningar (både hårdvaru- och mjukvarubaserade) Google gick igenom för att skapa det som förmodligen är det bästa globala privata nätverket tillgängligt idag.
När det gäller marknadsandel är Google Cloud Platform den tredje globala leverantören (efter marknadsandel för AWS och Microsofts marknadsandel för Azure). Men när det gäller dess privata premium-nätverksinfrastruktur lämnar den sina konkurrenter långt efter, som dessa uppgifter från BroadBand Now visar:
2014 publicerade GigaOM en artikel som jämförde AWS och Google Cloud Platform men bara en vecka senare publicerade de en annan med titeln: “What I missed in the Google vs. Amazon cloud debate — fiber!” där de erkänner att Google är flera år i förväg när det gäller infrastruktur.
”Att ha stora, snabba rör tillgängliga för din- och dina kunders trafik – är en stor grej.”— Barb Darrow, GIGAOM
Googles Premium vs Standardnivå-nätverk
Google Cloud Platform erbjuder två olika nätverksnivåer som skiljer sig både i pris och prestanda.
Google Premiumnivå-nätverk
Med Googles premiumnivå-nätverk kan användarna dra nytta av det globala fibernätet, med globalt distribuerade Points of Presence. All inkommande trafik från kunden till Googles datacenter dirigeras till närmaste Point of Presence, vilka distribuerats globalt och sedan dirigeras begäran 100% över Googles privata ryggrad. Som vi nämnde i en tidigare artikel kan det innebära 30% förbättrad latens eller 50% bättre bandbredd.
På vägen tillbaka dirigeras alla data som skickas från datacentret till besökaren med hjälp av Cold Potato-policyn. I motsats till Hot Potato-routing, som används på Standardnivå-nätverket, där trafiken så tidigt som möjligt överlämnas (eller tappas) till andra ISP, innebär Premiumnivå-routing att avgångstrafiken hålls så länge som möjligt på Googles egen fiber, och ges över till peers eller transit ISP så nära besökaren som möjligt.
För att uttrycka det i lekmannatermer. Premiumnivå-paket spenderar mer tid på Googles nätverk, med mindre hopp omkring och presterar därmed bättre (men kostar mer).
För sci-fi-fansen bland oss kan det jämföras med ett kosmiskt maskhål som överför vår trafik direkt till vår destination utan att resa runt via internet.
På Kinsta använder vi Google Clouds Premiumnivå-nätverk med alla våra hostingplaner Detta minimerar avstånd och hopp, vilket resulterar i snabbare och säkrare global transport av dina data.
Google Standardnivå-nätverk
Å andra sidan använder standardnivå-nätverket Points of presence nära datacentret där vårt innehåll eller webbapp befinner sig. Detta innebär att våra besökares trafik kommer att resa genom många olika nätverk, autonoma system, Internetleverantörer och genom många hopp tills den når sin destination. I detta scenario offras hastigheten.
Innehåll som reser på standardnivån kommer inte att kunna dra full nytta av Googles SDN och den enorma datorkraften för att beräkna de bästa rutterna dynamiskt. Trafiken kommer att omfattas av BGP-policyer för alla system mellan Google och besökaren.
För att uttrycka det i lekmannatermer. Standardnivåpaket spenderar mindre tid på Googles nätverk, och mer tid på att hoppa runt på offentliga nätverk, och presterar därmed sämre (men kostar mindre).
Dessutom använder Premiumnivån Global lastbalansering, medan standardnivån endast erbjuder Regional lastbalansering, vilket ger mer komplexitet och mer ”fotarbete” för kunder på Standardnivån.
Premiumnivå-nätverket erbjuder ett globalt Service Level Agreement (SLA), vilket innebär att Google accepterar avtalsenligt ansvar för att leverera en viss servicenivå. Det är som ett tecken på kvalitetsgaranti. Standardnivå-nätverk erbjuder inte denna nivå av SLA.
För dem som vill ta reda på mer, finns det en ganska omfattande jämförelse och dokumentation av de två nivåerna på Google Clouds webbplats. De ger även ett praktiskt diagram som hjälper dig att lättare avgöra vilken nätverksnivå du ska använda:
Sammanfattning
I åratal har Google investerat i att skapa en global nätverksinfrastruktur, distribuera sina egna protokoll och anpassade hårdvaru- och programvarunätverksstackar. I tider då Moores lag verkar bli svagare år efter år, gör Googles infrastruktur att företaget kan hålla jämna steg med den ständigt växande efterfrågan på molnresurser.
Även om marknadsandelen fortfarande ligger bakom Amazon Cloud och Microsofts Azure Cloud, har Google fått en avgörande fördel för både fibern den äger, liksom i de avancerade hårdvaru- och mjukvarulösningarna som dess ingenjörer distribuerade.
Vi kan förvänta oss att Google spelar en nyckelroll i IoT, smarta städer, förarlösa bilar och att efterfrågan på edge-beräkning fortsätter att växa.
Google Cloud Networks Premiumnivå är den första produkten som använder Googles innovativa nätverksprestationer. Det gör det möjligt för kunder att dra nytta av Googles nätverk och hela stacken för att leverera innehåll med premiumhastighet. Med Googles garantier om latens.
Kinsta är dedikerade till att tillhandahålla den bästa prestandan för applikationshosting, databashosting och hanterad WordPress-hosting på global skala. Det är därför som Kinsta drivs av Google Cloud-hosting och vi använder Googles Premiumnivånätverk för alla våra hosting-planer.
Tonino är en entreprenör, Linux- och OSS-entusiast, utvecklare och teknisk utbildare. Han har över tio års erfarenhet av utveckling och har varit i blockchain-området i 3+ år. När han inte kodar skriver han för SitePoint och Alibaba Cloud, tittar på de senaste skönlitterära verken på Netflix och utforskar nya resmål.
Lämna ett svar