Zo nu en dan worden er grote stappen gezet richting instant content delivery. Begin dit jaar hebben de goeroes bij Google een methode voorgesteld om de snelheid van het internetverkeer te verhogen door het verbeteren van veel gebruikte internetprotocollen zoals SSL, http en zelfs Transmission Control Protocol (TCP). Voor deze set van experimentele updates werd de naam 'SPDY' bedacht, geen acroniem, maar het woord 'speedy' zonder klinkers.
Eerst even kort kijken hoe dit in zijn werk gaat. Voordat data, bijvoorbeeld de inhoud van een website, daadwerkelijk via een netwerk verzonden kan worden moeten de client en de server met elkaar praten. In dit proces wisselen de twee verschillende berichten met elkaar uit. TCP is een soort 'taal' die wordt gebruikt door clients en servers om met elkaar te kunnen communiceren. Elke keer als er een bericht wordt verzonden door een van beide partijen, ontvangt de ander het met enige vertraging. Het antwoord dat wordt teruggestuurd naar de oorspronkelijke afzender wordt ook weer met enige vertraging afgeleverd. Sinds de introductie van het TCP-protocol in 1974 beschikken we inmiddels over een miljoen keer meer bandbreedte, maar deze vertraging, oftewel latency, blijft min of meer hetzelfde. Er zijn slechts enkele kleine verbeteringen geboekt.
SPDY is een reeks wijzigingen aan verschillende internetprotocollen, allen gericht op het verlagen van de laadtijden van webpagina's. Het idee achter de voorgestelde wijziging voor TCP is, zoals alle goede ideeën, heel eenvoudig: reorganiseer de taal waarin de clients en servers met elkaar praten, waardoor de responstijd afneemt. Natuurlijk is dit in werkelijkheid zeer ingewikkeld, alleen al vanwege de grote hoeveelheid verschillende apparaten dat is aangesloten op het internet.
Niet sneller
Hoewel Google een performanceverbetering van 50 procent meende waar te nemen bij het gebruik van SPDY (en de updates zijn reeds geïmplementeerd in Chrome, Firefox 13 en Apache), riepen een aantal recente benchmark-tests vragen op over de praktische uitvoering van SDPY. Webperformance-onderzoeker en Chief Product Architect bij Akamai, Guy Podjarny, voerde een test uit onder de top vijfhonderd websites (volgens Alexa) waarbij hij voor deze sites een reverse proxy opzette. De proxy kon het gebruik van SPDY aan- en uitzetten, zodat hij de resultaten van deze methode om de snelheid van internetverkeer te verhogen kon vergelijken.
Bij het testen van deze websites, zag Guy niet de tijdswinst terug waar velen van ons aanvankelijk zo enthousiast over waren. Zijn tests laten zien dat SPDY slechts marginaal sneller is dan https en zelfs langzamer dan http. De conclusie die hij hieruit kon trekken: SPDY maakt http beter, maar voor de meeste websites is http niet het probleem.
Podjarny concludeert dat 'SPDY een stap in de goede richting is' en dat zijn onderzoek en de daaruit voortkomende conclusies niet betekenen 'dat we moeten stoppen met het werken aan SPDY, maar dat we hier juist meer aan moeten werken en het nog sneller moeten maken.'
Problemen aanpakken
Hoe nu verder? Helaas zal het nog een tijdje duren voordat het SPDY-project klaar is, maar bij mijn werkgever houden we het project nauwlettend in de gaten. Website-beheerders wordt geadviseerd om te werken aan het verminderen van het aantal domeinnamen op hun pagina's en aan andere knelpunten om het meeste uit SPDY te halen. Andere deelnemers aan de SPDY-gemeenschap wordt geadviseerd om meer energie te steken in het aanpakken van de onderliggende problemen.
Een belangrijk aspect dat moet worden aangepakt is bijvoorbeeld de manier waarop de performance geoptimaliseerd kan worden door het verspreiden van content via een aantal domeinnamen, omdat dit het principe van multiplexing bij SPDY tegenwerkt. Uiteindelijk moeten we als gemeenschap ook naar andere knelpunten van high-speed content delivery kijken, om de vooruitgang in performance die met SPDY wordt beoogd te ondersteunen.
Grzegorz Janoszka, network design engineer bij LeaseWeb
Grzegorz,
Inderdaad heeft Google, een bedrijf dat trouwens wel vaker met veel rumoer dingen naar buiten brengt die later weer stilletjes verdwijnen, SPDY of HTTP-bis als applicatie protocol voorgesteld bij IETF. Maar de concurrent van Google, Microsoft heeft echter met Speed & Mobility (S&M) ook voorstellen ingediend voor verbetering van HTPP-1.1. En juist in het laatste, de mobiliteit zit misschien wel de meest interessante winst omdat sommige websites als ‘dikke stront door een dunne trechter’ gaan op mijn tablet of telefoon.
Backward compatibility vraagt om offers, ook bij de Internet protocollen. Een update wordt dus noodzakelijk. er is een RFC bij het IETF ingediend voor HTTP 2.0, als opvolger van de meer dan 12 jaar oude HTTP 1.1 standaard. In HTTP 2.0 zijn de SPDY en S&M samengevoegd en zijn er ook meer toevoegingen om tot versnelling te komen samengebracht.
De werkgroep IETF HTTPbis zal hierover een besluit moeten gaan nemen.
In een “greenfield situatie” waarop het Internet nog gespecificeerd zou moeten worden zou je alles waarschijnlijk alles aanpassen aan de huidige technologie en snelheden. Dit is niet het geval. Ik hoop dat niet de fout wordt gemaakt zoals bij IPv4 en IPv6 het geval is en je start met een nieuw protocol in plaats van een aanpassing voorwaarts.
In het licht van dit artikel vraag ik me af of er wel eens gekeken is naar hoeveel “overhead” er in de gemiddelde webpagina zit.
Ik zie vaak allerlei stylesheets, java-applets etc standaard geladen worden, terwijl er maar 10% van gebruikt wordt.
Kijk ik naar sommige html pagina’s (vooral die gemaakt zijn met bijv. ms word; ja ik weet dat dit niet daarvoor gemaakt is, maar het komt voor) zie ik zoveel extra statements over fonts, kleuren, layout enz. dat 70% van de pagina bijzaak is, en 30% (of minder) de inhoud.
Als je door hier kritisch naar te kijken, de hoeveelheid data kunt reduceren (en ook het aantal ack’s kunt terugbrengen) dan ga je veel minder last krijgen van de latency zoals genoemd is.
@ PaVaKe
de spijker op zijn kop.
Ik heb in de afgelopen tijd enkele oude websites overgenomen en opnieuw opgebouwd.
1 voorbeeld wil ik hier vermelden. Voor ik begon had ik 485 KB kode, nadat ik alle overbodige rotzooi weggehaald had, bleef er 95 Kb kode over en de website zag er nog precies zo uit, met het verschil dat ik nu valide kode had. Een reduktie tot 20% van het origineel.
Het web barst van de websites die door generatoren of door (oude) frontpage gemaakt zijn, dat krijg je als iedere amateur zich “webdesigner” noemt en gekozen wordt omdat die zo goedkoop is.