Då HTTP/2 bygger på en närmre anknytning till TCP för att öka utnyttjande graden av länken mellan klient och server, betyder det även att om det skulle uppstå problem med TCP kommer hela HTTP-sessionen att påverkas. I tidigare version 1.1 när det upprätthölls tre till sex TCP-sessioner per domän beroende på vilken webbläsare som används, betyder det att om det skulle uppstå paketförluster i en av dem sessionerna kommer endast den sessionen att behöva genomföra en slow-start igen. Om det skulle inträffa paketförluster för HTTP/2 skulle hela anslutningen i helhet bli långsammare men förhoppningsvis ta återuppta hastighet omgående.
I testet där laddningstider dokumenterades användes en nyutvecklad webserver som heter H2O, för att skapa en HTTP/2 server som kunde genomföra dem lokala prestandatesterna. Denna mjukvara kan vara dåligt gjord och leda till sämre prestanda jämförelsevis om en mer välkänd eller enterprise mjukvara hade använts, så som F5 eller nghttp2. Enterprise mjukvaror är mjukvara som utvecklas av företag som tar betalt för användandet utav mjukvaran och därför ställs höga krav på mjukvaran så att den blir välutvecklad. Även brukar de företag som erbjuder enterprisemjukvaror erbjuda testande av det senaste så som HTTP/2.
Anledningen till att H2O valdes var för H2O använder sig även av en relativt uppdaterad version av HTTP/2 (draft 14). Cory Benfield, nämner även denna server under PyCon 2015, vilket gjorde att valet kändes säkert då ledande utvecklare i världen rekommenderade
24 | ANALYS OCH DISKUSSION
denna. Även för att det redan fanns guider på internet om konfiguration av H2O för att få den att fungera omgående.
Resultatet visade att en HTTP/2 server presterar bättre än de tidigare versionerna genom att ta ett medelvärde på 20 försök i en webbläsare. Hade det funnits mer tid hade det genomförts fler tester samt i olika klienter för att dra fram ett så brett resultat som möjligt. Enligt data från Swedbank visar statistik att det är flest användare som använder Google Chrome mot deras webbsidor, näst mest använd var Firefox. I testet som genomföres användes Chrome för att samla laddningstider och Firefox/Firebug för att analysera data. Vid vidarearbete av tester bör olika HTTP/2 servrar testats för att bli mer kritisk mot servermjukvaran, samt för att samla mätvärden från servern. Enligt ett epostmeddelande från Ilya Grigorik[8] ska det framgå på servern att den inte belastas lika mycket vid användning av HTTP/2, då den inte behöver bearbeta lika mycket data tack vare HPACK samt det nya binära ramlagret.
I rapporten skulle det genomföras en prestandaanalys på en så låg nivå som möjligt. Vid användning av Wireshark för att avlyssna trafik och göra en analys utifrån det, märktes tidigt att detta inte skulle gå utan installation och konfiguration av en proxyserver som har stöd för HTTP/2. Anledningen till det är för att HTTP/2 använder sig i dagsläget alltid av TLS och kräver certifikat. Det leder till att all trafik som Wireshark plockar upp kommer vara krypterad och oläsbar utan någon typ av bearbetning. De HTTP/2 servrar som finns i dagsläget har inte implementerat någon typ av proxyfunktion och det ledde till en omöjlighet att avlyssna trafiken på lågnivå. När RFC’n för HTTP/2 är bestämd och publicerad kommer det med hög sannolikhet komma ut verktyg för att genomföra alla dessa tester.
Därför var det väldigt svårt att genomföra välplanerade tester av prioritetsflaggan som har implementerats i HTTP/2. Hade det funnits en mer lättanvänd proxy skulle det finnas möjligheter att läsa av förfrågningar samt svar, på så sätt skulle det synas vad prioritetsvärdet på vissa resurser är. Med hjälp av den informationen skulle det gå att bygga upp en hemsida där tester körs genom att placera ut olika resurser i olika ordningar och skapa olika beroende för att sedan se hur prioriteten av resurser styr.
Ett exempel på detta är om en hemsida är beroende av en bild och HTTP/2 anser att bilder är lågt prioriterade. Då måste klienten vänta enda tills hela sidan har renderats för att få se denna bild, även om det var önskat att den visades bland dem första resurserna vid rendering.
Då HTTP/2 endast använder en TCP-uppkoppling så kommer det märkas markant på mobila enheter att hemsidor till exempel laddar mycket snabbare jämförelsevis med när HTTP/1.x användes. Anledningen till att det kommer upplevas snabbare är för att mobila enheter använder trådlösa lösningar för att sända data. När trådlös teknik används innebär det i många fall att det tar längre tid att upprätthålla TCP-sessioner. Men då HTTP/2 endast använder sig av en jämförelsevis med HTTP/1.x där webbläsare(klienter) använder tre till sex TCP-sessioner.
Tester på mobila enheter kan inte genomföras i dagsläget då det inte finns någon webbläsare utvecklad för någon av de populära mobila plattformarna så som Iphone eller
25 | ANALYS OCH DISKUSSION
Android. Vilket innebar att den enda metoden för att återskapa en liknande mobil miljö är att införskaffa en mobil accesspunkt med 3G eller 4G uppkoppling som en bärbar dator ansluter sig till.
När HTTP/2 blir standardiserad samt fått sin RFC kommer företag med hög sannolikhet att sträva efter att övergå till den senaste versionen. Detta då HTTP/2 kommer att lösa många av de problem som stora företag kan uppleva inom webtjänster, så som belastningar och omkostnader för drivning av servrar.
Då HTTP/2 har sitt binära ramlager krävs det inte lika mycket serverkraft för att bearbeta den trafik som servern tar emot av klienter, samt kommer klienterna få snabbare svar då servern inte behöver skicka lika mycket överflöde som i tidigare versioner. Detta tack vare HPACK och det binära ramlagret som minskar paketen samt gör de lättare att skicka via strömmar som upprätthålls mellan klient och server.
När företag har övergått helt till HTTP/2 kommer dem med hög sannolikhet se att servrarna inte belastas lika mycket som när HTTP/1.1 användes. Det innebär att de inte kommer belastas lika mycket med bearbetning och nätverkstrafik, men det krävas troligen mer RAM-minne om det är många klienter som ska ha en gemensam tabell mellan servern med de resurser som skickats, samt anslutningsinformation om länken. I helhet borde detta leda till minskad strömkonsumtion och mer effektiva servrar.
Prestandamätningar av HTTP/2 servrar genomfördes inte i detta arbete men är något som det bör genomföras studier inom när RFC’n för HTTP/2 är publicerad och standardiserad. Det är först då opensource mjukvaror kommer uppdateras och det släpps en stabil version av servermjukvaran. Det är även först då som de tidigare nämnde enterprisemjukvarorna kommer våga skicka ut en stabil uppdatering till deras produktionsservrar(de servrar som används mot kunder).
Facebook, Google och Twitter är dem tre större hemsidorna på internet som har installerat SPDY på sina servrar och kommer troligen implementera en lösning med HTTP/2 omgående när RFC’n blivit godkänd. Facebook har även skapat presentationsmaterial som använts i olika syften, bland annat för olika företag där dem presenterar de stora fördelarna med att använda SPDY samt presenterar dem hur mycket bättre det kommer bli med HTTP/2. Den information som de delar med sig av är den information som rapporten går igenom under kapitel 2.4.
27 | SLUTSATSER
5 Slutsatser
Testerna som har genomförts för att testa dem olika delarna av HTTP/2 har visat ett resultat över hur HTTP/2 kommer att förbättra laddningstider på Swedbank’s hemsida med 44% utan fördjupande konfiguration. Detta tack vare det nya binära ramlagret som tillfördes på applikationsnivå, samt multiplexing som gör att TCP utnyttjas på ett betydligt bättre sätt jämfört med de tidigare versionerna. Efter att ha genomfört förstudien framgår det även att dagens websidor ligger långt före i utvecklingen jämfört med vad HTTP/1.1 var planerat för.
Resultatet visar vad Swedbank bör fokusera på vid framtida utveckling av webbapplikationer. Det är att placera de resurser som behövs tidigt vid rendering av hemsidan tidigt i koden. Detta för att HTTP/2 skall kunna läsa av dokumentet och skapa en prioritet, samt använda cache-push för att skicka de resurser som klienten anses behöva. När Swedbank använder detta vid framtida tjänster kommer det binära ramlagret, kombinerat med multiplexering och protokollhuvudkomprimering(HPACK) att använda TCP på ett mer optimalt sätt som leder till snabbare laddningstider och därav ge sina användare en bättre upplevelse.
29 | FRAMTIDA ARBETE
6 Framtida arbete
Ska ett vidarearbete genomföras inom HTTP/2 bör det finnas en ordentligt uppsatt testmiljö där trafik skickas genom en proxyserver och gör trafiken läsbar för nätverksanalysverktyg så som Wireshark. Detta för att kunna bekräfta de teorier som tagits upp på en djupare och mer detaljerat nivå. Då kommer det även gå att genomföra fördjupande tester så som att koda en hemsida där det placeras ut olika typer av filer i olika delar av hemsidan.
Det bör även läggas ner mycket tid på att testa olika HTTP/2 servrar beroende på när arbetet utförs då det i dagsläget inte finns något officiellt och de som finns är dem som utvecklats av internetentusiaster. Resultatet kan därför skiljas mellan ett litet projekt som byggts upp för att testa HTTP/2-versionen som är aktiv, eller en HTTP/2 server som är mer robust som nämndes i kapitel 4.2.
Om arbetet utförs när RFC’n blivit publik bör även HTTP/2 servrarna testas och genomföras prestandatester mot för att se hur stor prestandaskillnad det är ur serverns perspektiv, inte bara från klientens. Med informationen som samlas in från testerna kommer det gå att jämföra de tidigare HTTP servrar med den nya och där kunna se om HTTP/2 reducerar belastningen på servern. Då går det även att granska den hållbarautvecklingen på ett bättre sätt då hela världen har blivit beroende av servrar som i sin tur kan belastas av HTTP.
31 | KÄLLFÖRTECKNING
Källförteckning
[1] Tobias Ericsson, ”Front-end website performance optimisation”, Uppsala Universitetet2013, IT 13 062
[2] T. Berners-Lee m.f, “RFC 1945, HTTP/1.0”, https://www.ietf.org/rfc/rfc1945.txt, Publicerad 1996-05, Hämtad 2015-04
[3] T. Berners-Lee m.f, “RFC 2068, HTTP/1.1”, https://www.ietf.org/rfc/rfc2068.txt, Publicerad 1997-01, Hämtad 2015-04
[4] Illya Grigorik, “High Performance Browser Networking”, September 2013, http://shop.oreilly.com/product/0636920028048.do Hämtad 2015-04-30
[5] http archive, “HTTP archive trends”, http://httparchive.org/trends.php, Updaterad 2015-05-01, Hämtad 2015-05-10
[6] IETF, “HTTP/2”, https://http2.github.io/faq/#why-revise-http, Updaterad 2015-05-14, Hämtad 2015-05-15
[7] nghttp2, “How Dependency Based Prioritization Works”,
https://nghttp2.org/blog/2014/04/27/how-dependency-based-prioritization-works/, Public-erad 2014-04-27, Hämtad 2015-05-01
[8] Illya Grigorik, https://www.igvita.com/, hämtad 2015-05
[9] HTTrack. Xavier Roche & other contributors, ver. 3.48-21. https://www.httrack.com/, hämtad 2015-05
[10] Debian, ”Debian”, ver. 7.8, https://www.debian.org/, Updaterad 2014-04-30, hämtad 2015-05
[11]Mozilla, “Firebug”, ver. 2.0.9, http://getfirebug.com/, Publicerad 2015-04-09, hämtad 2015-05
[12] Kazuho Oku, “HTTP/2 is much faster than SPDY thanks to
dependency-prioritization”, http://blog.kazuhooku.com/2015/04/dependency-based-prioritization-makes.html, Publicerad 2015-04-16, Updaterad 2015-04-17, hämtad 2015-05
[13] Kazuho Oku, ”H2O”, commit: 111926c9c665d83b0ea32b95e4142570572cf832 https://github.com/h2o/h2o, hämtad 2015-05
[14] InternetLiveStats, ”Number of Website”, http://www.internetlivestats.com/total-number-of-websites/, Hämtad: 2015-05-25
32 | KÄLLFÖRTECKNING
[15] Chromium Blog, ”Hello HTTP/2, Goodbye SPDY”,
http://blog.chromium.org/2015/02/hello-http2-goodbye-spdy-http-is_9.html, Publicerad 2015-0209, Hämtad 2015-05-27
[16] W3, ”Network Performance Effects of HTTP/1.1, CSS1, and PNG”,
http://www.w3.org/Protocols/HTTP/Performance/Pipeline.html, Publicerad 1997-06-21, Hämtad 2015-05-27
[17] Jitendra Padhye och Henrik Frystyk Nielsen, ”A comparison of SPDY and HTTP per-formance”,
http://research.microsoft.com/pubs/170059/A%20comparison%20of%20SPDY%20and%2 0HTTP%20performance.pdf, Publicerad 2012-07-26, Hämtad 2015-05-27
[18] Pingdom, “Pingdom Website Speed Test”, http://tools.pingdom.com/, Hämtad 2015-05-28
[19] LoadImpact, “Write code that scales”, https://loadimpact.com/, Hämtad 2015-05-28 [20] Chromium, “SPDY: An experimental protocol for a faster web”,
33 | KÄLLFÖRTECKNING
Bilagor
[1] golang HTTP/2
Bilaga 1: I bilden kan man se hur alla förfrågningar utom en upprätthålls samtidigt(parallellt) i en HTTP/2 anslutning. Det första som sker är att den väntar på TCP-uppkopplingen och sedan väntar alla resurser samtidigt. När uppkopplingen är etablerad laddas alla resurser nästan samtidigt, det skiljer som högst 40ms mellan resursernas väntetid. Totaltiden att ladda in dem 180 bilderna tog 651 millisekunder.
34 | KÄLLFÖRTECKNING
[2] golang HTTP/1.1
Bilaga 2: I bilden ser man hur HTTP/1.1 hämtar en resurs i taget. Det syns väldigt tydligt i bilden hur varje resurs väntar på den tidigare och därför skapas detta trappliknande mönster. Anledningen till att det ser ut som att resurserna laddas in snabbare här jämfört med HTTP/2 är för att den totala tiden för att hämta dem 180 resurserna tog 4870 millisekunder vilket ledde till en nedskalning på bilden.