WebSocket eller Ajax i Webbapplikationer

Transkript

1 Examensarbete WebSocket eller Ajax i Webbapplikationer - Är WebSockets prestanda tillräcklig för att ersätta Ajax? Svensson Martin Ämne: Examensarbete i Datavetenskap Nivå: G1E Kurskod: 1DV40E

2 Abstrakt Denna rapport behandlar prestandaskillnader vid överföringar med Ajax och WebSocket, samt webbläsares kompabilitet med WebSocket. Ämnet kändes relevant då fler och fler webbsidor börjar använda sig av dessa tekniker för att hämta och skicka data i realtid. Undersökningen genomfördes genom att en testapplikation skapades där data kunde överföras med respektive teknik, varpå tidsåtgången för överföringen mättes och presenterades. Resultatet visar att WebSocket har klara fördelar mot Ajax när små mängder data överförs, samtidigt som Ajax visade sig vara snabbare vid upprepade överföringar av större mängder data. Undersökningen visade även att stöd för WebSocket saknas i flera webbläsare, varför WebSocket ännu inte är redo att användas fullt ut. Abstract This report deals with differences in performance in transmissions with Ajax and WebSocket, and web browsers compatibility with WebSocket. The subject felt relevant because more and more web sites are starting to use these technologies to send and receive data in real time. The study was conducted by creating a test application where data could be transferred with respective technology, whereupon the transfer time was measured and presented. The result show that WebSocket has a clear advantage over Ajax when small amounts of data is transferred, while Ajax showed to be faster when repeatedly transferring larger amounts of data. The study also showed that support for WebSocket is missing in multiple web browsers, and that WebSocket therefore isn t fully ready to be used.

3 Förord Arbetet genomfördes som examensarbete inom Webbprogrammerar-utbildningen på Linnéuniversitetet i Kalmar, och pågick under 10 veckor. Ämnet för arbetet valdes på grund av att det behandlade moderna tekniker och intressanta lösningar. Jag vill tacka min handledare John Häggerud för den hjälp han har gett mig under arbetets gång.

4 Innehållsförteckning Innehåll 1. Bakgrund Introduktion Ajax Push Comet WebSocket Problemformulering Avgränsningar Tidigare arbete Metod Ajax-Klient Ajax-Server WebSocket-Klient WebSocket-Server Tester Metoddiskussion Resultat kB 20 gånger med 0 sekunders mellanrum kB 100 gånger med 0 sekunders mellanrum kB gånger med 0 sekunders mellanrum kB 20 gånger med 0 sekunders mellanrum kB 100 gånger med 0 sekunders mellanrum kB gånger med 0 sekunders mellanrum kB 20 gånger med 5 sekunders mellanrum kB 100 gånger med 5 sekunders mellanrum kB gånger med 5 sekunders mellanrum MB 10 gånger med 0 sekunders mellanrum MB 100 gånger med 0 sekunders mellanrum MB gånger med 0 sekunders mellanrum... 19

5 3.13 1MB 10 gånger med 5 sekunders mellanrum MB 100 gånger med 5 sekunders mellanrum MB 10 gånger med 20 sekunders mellanrum överföringar från klient till server i Chrome överföringar från klient till server i Firefox överföringar från server till klient i Chrome överföringar från server till klient i Firefox överföringar i Chrome från klient till server överföringar i Chrome från server till klient överföringar i Firefox från klient till server överföringar i Firefox från server till klient Slutsats Överföringar från klient till server Överföringar från server till klient Webbläsarprestanda med WebSocket Webbläsarprestanda med Ajax Diskussion Fortsatt arbete Rekommendationer Källförteckning Elektroniska källor... 28

6 1. Bakgrund 1.1 Introduktion När en webbläsare efterfrågan en webbsida sker det genom att webbläsaren skickar en förfrågan till webbsidans server som returnerar efterfrågad data[1]. Denna överföringsmodell grundar sig i att HTTP-protokollet, som används för att överföra webbsidor på internet[1], bygger på överföringsmodellen request/response ( förfrågan/svar ), som innebär att klienten alltid måste skicka en förfrågan för att få data till svar[2], en princip även kallad pull (trycka)[3]. Servern behöver då inte hålla anslutningen mot klienten öppen, vilket gör att servern istället kan han hantera anslutningar från andra klienter. En ny anslutning måste dock upprättas varje gång en förfrågan ska ske, vilket tar upp tid och överföringskapacitet. Bild 1.1 Illustration över pull-modellen Då klienten inte kan skicka förfrågningar konstant får klienten inte senaste data när det finns tillgängligt, utan först när en förfrågan sker.[4] På grund av att vissa typer av applikationer kräver uppdateringar med en väldigt låg tidsfördröjning, exempelvis finansapplikationer och applikationer där exakt tidsmätning krävs, lämpar sig inte pull-tekniker för dessa applikationer. Detta eftersom att antalet förfrågningar då skulle behöva vara väldigt högt och då ta upp mycket bandbredd och processorkraft[5]. Ett exempel på hur pull-teknik fungerar i praktiken är en chattapplikation där klienten med ett visst tidsintervall måste kontrollera med servern ifall några nya meddelanden åt klienten finns, varpå servern måste skicka ett svar, oavsett om nya meddelanden till klienten finns eller inte. 1.2 Ajax För att möjliggöra att data hämtas och skickas utan att användaren behöver ladda om en sida utvecklades tekniker för att, med JavaScript, hämta data i bakgrunden. Denna teknik kallas 1

7 Ajax(Asynchronous JavaScript and XML) och används idag av bland annat Googles mail-tjänst Gmail och videotjänsten YouTube.[6]. Ajax används för HTTP-överföringar via XMLHttpRequest, ett API (Application programming interface) implementerat i alla stora webbläsare, för att hämta data från en server[7]. API:t grundar sig i teknik utvecklad av Microsoft på slutet av 1990-talet och möjliggör för JavaScript-kod att hämta data från, och skicka data till, en webbserver utan att webbläsaren behöver ladda om hela sidan. Data som sedan används för att manipulera webbsidans struktur och innehåll med nytt innehåll[8]. Då XMLHttpRequest använder HTTP för dataöverföringar medföljer de problem som pullmodellen medför när den används i dataintensiva applikationer. Bland annat att klienten måste ofta måste göra förfrågningar för att få uppdaterad data vilket medför hög resursanvändning [Se 1.1]. 1.3 Push Under början av 2000-talet började nya sorters webbsidor dyka upp där besökaren presenterades med ny data kontinuerligt, utan att manuellt behöva uppdatera sidan. Nutida exempel på denna typ av sidor är Facebook, där användarna kontinuerligt kan chatta med, och få statusuppdateringar från vänner, och Twitter, där besökare i realtid kan få utvalda användares meddelandes presenterade för sig. Ökningen av, och populäriteten hos, webbapplikationer som förser besökarna med direktuppdaterad data har gett upphov till fenomenet real-time web (realtidswebben) där data skickas och tas emot i realtid hos användare[9]. På grund av det ökade användandet av realtidswebben (mars 2012 hade Twitter 140 miljoner användare[10]) har också behovet av tekniker anpassade för realtidswebben ökat[9]. Webbplatser som använder Ajax för realtidsuppdateringar blir dock påverkade av de problem som kommer med användandet av HTTP gällande att data inte nödvändigtvis är helt ny och att förfrågningar måste göras ofta [3]. För att komma till rätta med dessa problem började tekniker utvecklas på slutet av 1990-talet, för att skicka data till klienter, genom att en anslutning upprättas varpå servern startar en överföring när ny data finns. På så sätt behöver inte klienten skicka förfrågningar för att servern ska kunna skicka data, en modell som kommit att kallas push (trycka)[3]. Bild 1.2 Illustration över push-modellen 2

8 Ett exempel på hur en applikation som använder push-teknik är en chattapplikation, där klienten först ansluter till en server, som sedan skickar nya meddelanden till klienten när de blir tillgängliga, istället för att klienten ska behöva efterfråga dem själv, som i en pull-applikation Comet Problemen som kommer med användandet av pull-modellen som HTTP implementerar kan dock lösas med användandet av en samling tekniker kallade Comet. Comet är ett samlingsnamn för olika tekniker för att i webbapplikationer använda HTTP på ett sådant sätt så att webbläsaren inte konstant behöver göra nya förfrågningar efter uppdateringar, utan att servern istället pushar data när det behövs[11]. Comet kan använda sig av två olika sätt för att åstadkomma detta: I HTTP 1.1 finns möjligheten att hålla den tcp-anslutning som används för överföringen öppen till dess att webbläsaren eller webbservern avbryter den, eller tills en förutbestämd tidsgräns passerat. Detta görs genom att Connection -värdet i HTTP-headern sätts till keep-alive, varpå någon part sätter värdet till Close när anslutningen ska stängas[11]. På så sätt minskas den datamängd som behöver överföras varje gång, på grund av att ingen ny anslutning behöver upprättas, vilket även resulterar i att överföringstiden minskas[13]. På grund av att servern måste använda en instruktionssekvens (tråd[14]) per anslutning innebär det dock att servern snabbt kan blir upptagen med att hantera öppna anslutningar. Det andra sättet är long-polling, vilket innebär att webbläsaren skapar en anslutning mot en webbserver och sedan håller anslutningen öppen till dess att servern har skickat data. Nackdelen med denna teknik är att HTTP-anslutningen som hålls öppen tar upp anslutningsplatser hos både webbläsare och server, vilket i sin tur kan försämra prestandan[4]. Comet-tekniker kan dock, beroende på teknik, vara omständiga att implementera och vara olämpliga att använda på grund av att mellanliggande mjukvara, exempelvis proxy-servrar, inte är konfigurerade för att tillåta denna typ av överföringar.[11] 1.4 WebSocket För att göra det möjligt att på ett standardiserat sätt använda push-kommunikation mellan en webbläsare och en webbserver skapades tekniken WebSocket. Tekniken skapades och utvecklas av IETF (Internet Engineering Task Force) 2007, och förväntas blir standardiserad av W3C (World Wide Web Consortium) som en del av HTML5-standarden[15]. WebSocket kommunicerar asynkront, vilket innebär att det kan skicka meddelanden i båda riktningar, oberoende av varandra. Med WebSocket kan en klient och en server, efter att en anslutning har skapats, kommunicera med varandra via en enstaka TCP-anslutning helt utan att HTTP används, och undviker på så sätt den överflödiga datamängd som kommunikation med HTTP medför.[15] För att säkerställa att endast data från önskade källor tas emot inleds anslutningen med att klienten skickar ett handskakningsmeddelande till servern[se bild 1.3], som sedan svarar[se bild 1.4]. Om ingen handskakning gjordes och data istället togs emot från alla källor skulle det innebära en säkerhetsrisk då mottagen data skulle kunna vara skickad av någon med uppsåt att exempelvis utnyttja en säkerhetsbrist i webbläsaren[16]. 3

9 Bild 1.3 Handskakningsmeddelande från klient till server Bild 1.4 Handskakningsmeddelande från server till klient För att göra det möjligt att använda WebSocket över nätverk som tillåter HTTP-trafik är WebSocket första meddelande från klienten utformat som ett HTTP-Upgrade-meddelande. HTTP-Upgrade-meddelandet är egentligen utvecklat för att i HTTP 1.1 informera den ena parten om att en annan version av HTTP ska använda. Den används dock i WebSocket för att mjukvara som hanterar överföringen, exempelvis proxy-servrar, ska kunna hantera meddelandet, och sedan låta WebSocket-trafiken gå över samma port som HTTP-trafik, vanligtvis port 80[15]. Bild 1.5 Illustration över WebSocket-anslutning Efter att anslutningen är genomförd kan båda parter börja skicka meddelanden till varandra. Meddelanden innehåller antingen UTF-8-textsträngar eller binär data för att på så sätt kunna innehålla alla sorters data, exempelvis bilder.[15] 4

10 Ett stort problem med WebSocket är att stödet för det idag är bristande, då flera stora webbläsare ännu inte har fullständigt stöd för det, bland annat webbläsaren Opera och den senaste stabila versionen av Internet Explorer.[17] De webbläsare som ( ) har stöd för den senaste versionen av WebSocket, RFC6455, är: Internet Explorer (testversion) Mozilla Firefox 11.0 Google Chrome Safari 5.2 (testversion) 1.5 Problemformulering Ajax används av flera webbplatser med höga användarantal[9] vilket medför de problem som kommer med att HTTP använder sig av pull-modellen. Exempel på dessa är långa svarstider och ett behov av att ofta göra nya förfrågningar, och Ajax är därför nödvändigtvis inte den mest lämpade tekniken för att överföra data i bakgrunden på webbsidor. En möjlig lösning till dessa problem är att ersätta Ajax med WebSocket, som förväntas bli ett standardiserat protokoll som ska erbjuda bättre prestanda och lättare implementation.[15] Studier kommer därför göras där det undersöks om WebSocket har bättre prestanda än Ajax och om WebSocket därför är redo att ersätta Ajax. 1.6 Avgränsningar Undersökningen kommer endast använda sig av det senaste utkastet av WebSocket, RFC6455, och inte jämföra skillnader mot tidigare versioner, vilket innebär att inga tester kommer göras med webbläsare som endast stödjer tidigare versioner av WebSocket. Inga undersökningar kommer att göras angående hur data som ska överföras kan optimeras för att minska bandbreddsanvändning. På grund av att det då kan uppstå problem med att avgöra huruvida det är WebSocket eller andra optimeringar som är orsaken till eventuell förändring i överföringstiden. Undersökningen kommer inte heller ta hänsyn till hur lång utvecklings- och inlärningstiden är mellan Ajax och WebSocket. Endast en server per överföringsteknik kommer att testas då eventuella prestandaskillnader annars skulle kunna bero på skillnader mellan servermjukvaror och inte mellan tekniker. 1.7 Tidigare arbete Mathieu Carbou (2011) visar att WebSocket kan lösa de problem som Comet-tekniker medför, så som problem med proxy-servrar och det faktum att Comet inte är en standardiserad teknik. Carbou påpekar att stödet för WebSocket i webbläsare och servrar i dagsläget är ofullständigt, vilket innebär att utvecklaren i många fall måste förlita sig på externa lösningar. [15] Bengtsson, Peter (2012)[18] gör jämförande testet mellan Ajax och WebSocket där data skickas till en server, med respektive teknik, varpå servern returnerar data och klienten mäter tidsåtgången för överföringen. 5

11 Baserat på resultatet från undersökningen uppskattar Bengtsson att WebSocket är 10-20% snabbare än Ajax, men visar att resultatet varierar beroende på antal anslutningar som görs mot en server samtidigt där Ajax har en fördel mot WebSocket vid få anslutningar samtidigt som WebSocket är mer effektiv vid fler än 10 samtidiga anslutningar. Bengtsson gör dock inga tester på hur datastorlek påverkar överföringen och undersöker inte heller hur pauser mellan varje överföring påverkar tidsåtgången. 6

12 2. Metod För att undersöka eventuella prestandaskillnader med att överföra data i bakgrunden med Ajax respektive WebSocket, skapas en applikation där data kan föras över från klient till server och från server till klient. Data kan sedan överföras ett godtyckligt antal gånger, och med ett valt tidsintervall mellan varje överföring. Genom att både server och klient körs på samma maskin och därför har samma systemtid, används den för att beräkna överföringstiden. Anropet från klient till server, eller vice versa, innehåller utöver bestämd mängd data även systemtiden och applikationen kan därför, efter slutförd överföring, beräkna hur lång tid det tog att slutföra anropet. Överföringstiden presenteras då i applikationen. I undersökningarna används den senaste versionen av webbläsaren Google Chrome( m) samt den senaste versionen av Mozilla Firefox(11.0), som båda har stöd för den senaste WebSocket-specifikationen.[19,20]. Två olika webbläsare används för att undersöka ifall tidsåtgången för dataöverföringar skiljer sig webbläsarna emellan. 2.1 Ajax-Klient För att hantera Ajax-anslutningar i en webbläsare valdes JavaScript-ramverket jquery, vilket underlättar utvecklingen av en testapplikation då ramverket erbjuder metoder för att arbeta med Ajax i alla vanligt förekommande webbläsare[17]. Genom att jquery använder webbläsarens egen XMLHTTPRequest-implementation[21] sker ingen prestandaförlust jämfört med om egenskriven kod använts. Data som överförs formateras som JSON (JavaScript Object Notation), ett dataformat baserat på notationen hos JavaScript[22]. Bild 2.1 Klient-kod för Ajax-överföring från klient till server 7

13 Bild Klient-kod för Ajax-överföring från server till klient 2.2 Ajax-Server För att svara på Ajax-anrop används på serversidan webbservern Apache, som har stöd för bl.a. språket PHP, vilket kommer att användas för att hantera dataöverföringarna på serversidan.[23] Bild 2.3 Serverkod som returnerar lokal tid i millisekunder Bild 2.4 Serverkod som returnerar ett meddelande av en viss storlek tillsammans med lokal tid 8

14 2.3 WebSocket-Klient För att använda WebSocket i webbläsaren används webbläsarnas inbyggda stöd för WebSocket för att upprätta en WebSocket-anslutning som används för alla överföringarna. Data överförs mellan klienten och servern, och sedan beräknas och presenteras tidsåtgången för överföringen. Bild 2.5 Klientkod som skickar WebSocket-meddelande Bild 2.6 Klientkod som skickar WebSocket-meddelande med information om storlek, tidsintervall och antal upprepningar, tar emot svar från server, och beräknar överföringstid. 9

15 2.4 WebSocket-Server Efter att flera WebSocket-servrar hade undersökts (se kapitel 2.6) och testats valdes den Pythonbaserade servern pywebsocket. En WebSocket-server som antingen kan användas som ett tillägg till Apache, eller användas helt fristående. Servern stödjer den senaste WebSocket-specifikationen, RFC 6455, vilket var en förutsättning för att den skulle kunna användas. På grund av att servern är skriven i Python, kan den användas på alla plattformar som har stöd för Python-språket.[24] Bild 2.7 Serverkod för att returnera lokal tid efter att ett WebSocket-meddelande har tagits emot. Bild 2.8 Serverkod för att ta emot ett WebSocket-meddelande innehållande instruktioner för hur returdata ska se ut, och för att returnera detta. 10

16 2.5 Tester Testerna som används för att undersöka prestandan utformades för att mäta hur överföringstiden påverkades av datastorlek, tidsintervall, och upprepningar och är skapade för att återspegla hur överföring i webbapplikationer vanligtvis fungerar. Datamängden varierar från 1kB till 1MB för att simulera de datamängder som överförs då webbsidor uppdateras med olika typer av innehåll. En chattapplikation överförs troligtvis små mängder data flera gånger samtidigt som en bildvisningsapplikation troligtvis för över en större mängd data. De fall där överföringarna sker utan tidsuppehåll utformades för att undersöka hur webbläsarna hanterar flera samtidiga överföringar. Följande tester genomfördes 1. 1kB data skickas från klient till server med 0 sekunders mellanrum 20 gånger 2. 1kB data skickas från klient till server med 0 sekunders mellanrum 100 gånger 3. 1kB data skickas från klient till server med 0 sekunders mellanrum 1000 gånger kB data skickas från klient till server med 0 sekunders mellanrum 20 gånger kB data skickas från klient till server med 0 sekunders mellanrum 100 gånger kB data skickas från klient till server med 0 sekunders mellanrum 1000 gånger kB data skickas från klient till server med 5 sekunders mellanrum 20 gånger kB data skickas från klient till server med 5 sekunders mellanrum 100 gånger kB data skickas från klient till server med 5 sekunders mellanrum 1000 gånger 10. 1MB data skickas från klient till server med 0 sekunders mellanrum 10 gånger 11. 1MB data skickas från klient till server med 0 sekunders mellanrum 100 gånger 12. 1MB data skickas från klient till server med 0 sekunders mellanrum 1000 gånger 13. 1MB data skickas från klient till server med 5 sekunders mellanrum 10 gånger 14. 1MB data skickas från klient till server med 5 sekunders mellanrum 100 gånger 15. 1MB data skickas från klient till server med 20 sekunders mellanrum 10 gånger Samma tester genomfördes sedan, där data istället skickades från servern till klienten. 2.6 Metoddiskussion Valet av pywebsocket som WebSocket-server gjordes efter att flera olika WebSocket-servar hade övervägts. De servrar som undersöktes var: jwebsocket WebSocket-for-Python node.ws.js Nugget Socket.IO WebSocket-Node ws4py pywebsocket Först sorterades de servrar som inte hade stöd för det senaste WebSocket-protokollet bort, varpå de servrar som inte gick att använda som tillägg till Apache, eller inte gick att använda som fristående servrar. Valet föll därför på pywebsocket, då den hade stöd för RFC 6455, och gick att använda fristående från en webbserver. Då det var beslutat att den senaste versionen av WebSocket-protokollet skulle användas vid undersökningar krävdes det att webbläsare med stöd för RFC6455 användes. 11

17 De webbläsare som ( ) hade stöd för den senaste versionen av WebSocket, RFC6455, var: Internet Explorer (testversion) Mozilla Firefox 11.0 Google Chrome Safari 5.2 (testversion) Då den senaste versionen av Internet Explorer 10 inte fanns tillgänglig för Windows 7, valdes Internet Explorer bort. Eftersom att endast testversion av webbläsaren Safari har stöd för RFC 6455 valdes den bort, då det var ett bättre alternativ att använda webbläsare som i stabila versioner har stöd för RFC Valet föll därför på de då senaste versionerna av Google Chrome och Mozilla Firefox. Eftersom WebSocket-servern är skriven i python och Ajax-servern använder PHP kan detta eventuellt påverka prestandan hos servern, vilket är svårt att mäta. PHP valdes för Ajax-delen då kunskap om PHP-servern redan fanns. Firefox och Chrome tillåter båda, med standardinställningar, att max 6 HTTP-anslutningar hålls öppna mot en och samma server[25], vilken kan tänkas påverka testresultatet. Inga ändringar kommer göras i webbläsarnas standardinställningar då det är som mest intressant att veta hur webbläsarna presterar i den konfiguration som användare oftast arbetar med. Ajax-klienten överför data formaterat som JSON. Detta bör dock inte påverka prestandan då det endast är ett värde som läggs in i JSON-objektet. 12

18 3. Resultat När alla tester genomförts skapades diagram för att på ett översiktligt sätt undersöka resultatet. Bild visar den genomsnittliga överföringstiden per test och bild visar den genomsnittliga överföringstiden per plattform och överföringsriktning kB 20 gånger med 0 sekunders mellanrum Bild 3.1. Genomsnittlig överföringstid, i millisekunder, då 1kB överförts 20 gånger med 0 sekunders mellanrum. 13

19 3.2 1kB 100 gånger med 0 sekunders mellanrum Bild Genomsnittlig överföringstid, i millisekunder, då 1kB överförts 100 gånger med 0 sekunders mellanrum kB gånger med 0 sekunders mellanrum Bild Genomsnittlig överföringstid, i millisekunder, då 1kB överförts gånger med 0 sekunders mellanrum. 14

20 kB 20 gånger med 0 sekunders mellanrum Bild Genomsnittlig överföringstid, i millisekunder, då 100kB överförts 20 gånger med 0 sekunders mellanrum kB 100 gånger med 0 sekunders mellanrum Bild Genomsnittlig överföringstid, i millisekunder, då 100kB överförts 100 gånger med 0 sekunders mellanrum. 15

21 kB gånger med 0 sekunders mellanrum Bild Genomsnittlig överföringstid, i millisekunder, då 100kB överförts gånger med 0 sekunders mellanrum kB 20 gånger med 5 sekunders mellanrum Bild Genomsnittlig överföringstid, i millisekunder, då 100kB överförts 20 gånger med 5 sekunders mellanrum. 16

22 kB 100 gånger med 5 sekunders mellanrum Bild Genomsnittlig överföringstid, i millisekunder, då 100kB överförts 100 gånger med 5 sekunders mellanrum kB gånger med 5 sekunders mellanrum Bild Genomsnittlig överföringstid, i millisekunder, då 100kB överförts gånger med 5 sekunders mellanrum. 17

23 3.10 1MB 10 gånger med 0 sekunders mellanrum Bild Genomsnittlig överföringstid, i millisekunder, då 1MB överförts 10 gånger med 0 sekunders mellanrum MB 100 gånger med 0 sekunders mellanrum Bild Genomsnittlig överföringstid, i millisekunder, då 1MB överförts 100 gånger med 0 sekunders mellanrum. 18

24 3.12 1MB gånger med 0 sekunders mellanrum Bild Genomsnittlig överföringstid, i millisekunder, då 1MB överförts gånger med 0 sekunders mellanrum. Server kraschade när Chrome skickade data från klient till server, varför stapeln för det saknas MB 10 gånger med 5 sekunders mellanrum Bild Genomsnittlig överföringstid, i millisekunder, då 1MB överförts 10 gånger med 5 sekunders mellanrum. 19

25 3.14 1MB 100 gånger med 5 sekunders mellanrum Bild Genomsnittlig överföringstid, i millisekunder, då 1MB överförts 100 gånger med 5 sekunders mellanrum MB 10 gånger med 20 sekunders mellanrum Bild Genomsnittlig överföringstid, i millisekunder, då 1MB överförts 10 gånger med 20 sekunders mellanrum. 20

26 överföringar från klient till server i Chrome Bild Trenddiagram över överföringstid vid 1 00 överföringar i Chrome överföringar från klient till server i Firefox Bild Trenddiagram över överföringstid vid 1 00 överföringar i Firefox 21

27 överföringar från server till klient i Chrome Bild Trenddiagram över överföringstid vid 100 överföringar i Chrome överföringar från server till klient i Firefox Bild Trenddiagram över överföringstid vid 100 överföringar i Firefox 22

28 överföringar i Chrome från klient till server Bild 3.20 Trenddiagram över överföringstid vid överföringar i Chrome. Server kraschade när Chrome skickade 1MB data från klient till server, varför värde för WebSocket saknas överföringar i Chrome från server till klient Bild Trenddiagram över överföringstid vid överföringar i Chrome 23

29 överföringar i Firefox från klient till server Bild 3.21 Trenddiagram över överföringstid vid överföringar i Firefox överföringar i Firefox från server till klient Bild 3.22 Trenddiagram över överföringstid vid överföringar i Firefox 24

30 4. Slutsats 4.1 Överföringar från klient till server Testresultaten visar tidigt att WebSocket presterar bättre än Ajax vid överföring av 1kB mängder data[se Bild ], samt när en paus görs mellan varje överföring[se bild , ]. WebSocket presterar dock sämre än Ajax vid situationer där 100kB data, eller mer överförs flera gånger utan någon paus mellan överföringarna[se bild , ]. I de testfall där överföringar på 100kB och mer inleddes samtidigt var den genomsnittliga överföringstiden mellan 300 % och 764 %[Se bild 3.22] längre med WebSocket än med Ajax. Utifrån detta kan man dra slutsatsen att WebSocket uppnår kortare överföringstider där klienten inte behöver ha flera överföringar igång samtidigt under en längre tid då det medför att den genomsnittliga överföringstiden blir väsentligt längre än om Ajax används. Detta var inte väntat, då den datamängd som överförs vid en WebSocket-överföring är mindre än datamängden vid en Ajax-överföring. Utifrån resultaten kan man dra slutsatsen att applikationer som med korta mellanrum för över små mängder data kan dock dra nytta av att använda WebSocket istället för Ajax. Exempelvis chattapplikationer och webbsidor där endast delar av webbsidan uppdateras med ny data. Att överföringstiden med WebSocket gick upp till över ms [Se bild 3.12] visar dock på att WebSocket inte är redo att användas i situationer där stora mängder data ska föras över från klient till server, exempelvis videoapplikationer. Att Chrome, vid överföring av 1MB, gånger utan uppehåll, resulterade i att WebSocketservern kraschade[se bild 3.12], något som inte inträffade när Firefox användes för samma test, pekar även på att Chromes WebSocket-implementation inte är redo att användas fullt ut. 4.2 Överföringar från server till klient Vid överföring av 1kB data med WebSocket från server till klient visar resultatet att skillnaden i tidsåtgång skiljer sig mellan Chrome och Firefox, där Chrome är mellan 184% och 1008% snabbare än Firefox[Se bild ]. Skillnaden i tidsåtgång skiljer sig dock väldigt lite mellan PHP/Ajax i Firefox och PHP/Ajax i Chrome[Bild 3.21,3.23]. Skillnaden i överföringstid mellan WebSocket i Chrome och Ajax i Chrome kan bero på att WebSocket överför mindre data än Ajax, på grund av att Ajax vid varje överföring måste överföra HTTP-information. Detta förklarar dock inte varför WebSocket i Firefox är långsammare än Ajax i Firefox. På grund av skillnaderna mellan Chrome och Firefox är det svårt att avgöra om WebSocket eller PHP/Ajax snabbast överför 1kB data. När istället 100kB överförs från server till klient visar testresultatet att WebSocket är % snabbare än PHP/Ajax, och sedan % snabbare när 1MB överförs[se bild 3.21,3.23]. Denna trend visar på att WebSocket, vid överföringar från server till klient, för över data snabbare än PHP/Ajax, och att skillnaderna ökar, till WebSockets fördel, desto större datamängd som överförs. 25

31 4.3 Webbläsarprestanda med WebSocket Överföringstiden skiljer sig väldigt lite mellan Chrome och Firefox upp till och med att 1kB data överförs från webbläsaren till server 100 gånger med 0 sekunder mellanrum [Se bild ] men ökar till Chromes fördel när data istället överförs från server till klient[se 4.2]. När sedan 100kB förs över gånger är den genomsnittliga överföringstiden mindre än hälften så lång i Firefox som i Chrome[Se bild 3.6]. Detta kan bero på att Chromes WebSocket-implementation arbetar långsammare än Firefox motsvarighet. När data förs över från server till klient är Chrome till en början runt 10 gånger så snabbt som Firefox[Se bild ], vilket tyder på att Chrome bättre hanterar överföringar med väldigt små datamängder, än Firefox. Överföringstiderna skiljer sig sedan väldigt lite mellan webbläsarna [Se bild ]. Resultaten från tester där 1MB överförs från server till klient[se bild ] visar att Firefox, oavsett antal överföringar och pauser, har kortare överföringstider än Chrome. 4.4 Webbläsarprestanda med Ajax Då Firefox och Chrome båda tillåter att max 6 HTTP-anslutningar hålls öppna mot en och samma server[24] beror skillnaderna i överföringstid[se bild 3.13] troligtvis inte på att det maximala antalet anslutningar nås snabbare i endera webbläsaren. Detta bör då inte heller påverka den genomsnittliga överföringstiden. Skillnaderna beror troligtvis istället på olikheter i hur respektive webbläsare hanterar testapplikationens JavaScript-kod. 4.5 Diskussion Resultatet i undersökningen skiljer sig från resultatet i Bengtssons undersökning[18] där WebSocket konstant presterar bättre än Ajax när både server och testapplikation körs på samma maskin. Vid användning av en extern server är dock Ajax snabbare än WebSocket vid 10 överföringar samtidigt som skillnaderna vid 100 och överföringar är mindre än vid användandet av en lokal server. Detta tyder på att svarstiden har en tydlig påverkan på överföringstiden, och är troligtvis en av anledningarna till att resultaten från den egna undersökningen skiljer sig från resultatet i Bengtssons undersökning i. Detta förklarar dock inte varför resultatet skiljer sig från Bengtssons resultat i de fall där lokal server använts. På grund av skillnaderna mellan undersökningarnas resultat kan man resonera om huruvida metoden som använts i den egna undersökningen medför att WebSocket inte används på ett optimalt sätt. Exempelvis så hade möjligtvis överföringstiderna minskat om flera WebSocketanslutningar hade öppnats i de testfall där en anslutning hölls upptagen med en överföring under en längre tid. 26

32 4.6 Fortsatt arbete För att ytterligare undersöka prestandan hos WebSocket kan tester göras där en WebSocket-server får hantera överföringar från flera klienter där ingen av klienterna körs på samma dator som WebSocket-servern. På så sätt skulle testresultaten även visa till vilken grad svarstid och klientantal påverkar överföringstiden. Då endast en server-mjukvara användes i undersökningen, skulle det även vara intressant att genomföra tester med andra servrar, för att undersöka eventuella prestandaskillnader mellan dessa. 4.7 Rekommendationer Resultaten från testerna visar att det finns situationer där överföringar med WebSocket går betydligt snabbare än med Ajax[Se bild ] samtidigt som det i andra är tydligt att överföringarna går snabbare med Ajax[Se bild 3.6]. På grund av att resultaten tyder på att WebSocket snabbare överför små mängder data, flera gånger, än Ajax, kan det i applikationen som ofta skickar små mängder data vara lämpligt att ersätta Ajax med WebSocket. Detta kan innebära att WebSocket lämpar sig bättre i webbapplikationer i realtidswebben då dessa oftast endast hämtar mindre data att uppdatera innehållet med och inte data för hela sidor. Exempel på detta är chattapplikationer där användare ofta skickar mindre meddelanden, som då innehåller en mindre mängd data, och webbsidor där innehållet ofta uppdateras med ny data. Däremot kan Ajax vara mer lämpat att använda i applikationer där stora mängder data överförs från klient till server, exempelvis vid filöverföring. Utvecklare måste därför undersöka vilken teknik som bäst lämpar sig för den applikation som ska utvecklas, samt ta hänsyn till att stöder för WebSocket fortfarande inte är fullständigt(se kapitel 2.6). Ajax och WebSocket kommer troligtvis existera tillsammans under flera år framöver till dess att WebSocket har fått ett bredare stöd och utvecklare lär sig i vilka situationer respektive teknik bör användas. 27

33 5. Källförteckning 5.1 Elektroniska källor [1] HTTP Made Really Easy [Online] Tillgänglig [Hämtad: 23:e maj, 2012]. [2] HTTP Operational Model and Client/Server Communication [Online] Tillgänglig: m [Hämtad 23:e maj, 2012]. [3] J. Escobar, Push Technology is the Core of the Real Time Web [Online] Tillgänglig: [Hämtad: 19:e april, 2012]. [4] S. Malik, Implement a real-time server push in Ajax applications using socket-based RIA technologies [Online] Tillgänglig: [Hämtad 15:e april, 2012]. [5] M. Carbou, Reverse Ajax, Part 2: WebSockets [Online] Tillgänglig: [Hämtad: 23:e april, 2012]. [6] AJAX Introduction [Online] Tillgänglig: [Hämtad: 12:e april, 2012]. [7] AJAX Browser Support [Online] Tillgänglig: [Hämtad: 31:a maj, 2012]. [8] XMLHttpRequest object [Online] Tillgänglig: [Hämtade: 23:e maj, 2012] [9] K. Fromm, The Real-Time Web: A Primer, Part 1 [Online] Tillgänglig [Hämtad: 14:e april, 2012]. [10] Twitter Says It Has 140 Million Users [Online] Tillgänglig: [Hämtad: 23:e maj, 2012]. [11] E. Burckart, Comment lines: Erik Burckart: The allure of Comet [Online] Tillgänglig: rckart.html [Hämtad:16:e april, 2012]. [12] Hypertext Transfer Protocol -- HTTP/1.1 [Online] Tillgänglig: [Hämtad: 23:e maj, 2012] 28

34 [13] [Online] V. Sharovatov, HTTP persistent connections, pipelining and chunked encoding Tillgänglig: [Hämtad: 10:e maj, 2012]. [14] Processer och trådar [Online] Tillgänglig: [Hämtad: 22:a juni, 2012]. [15] IETF, The WebSocket Protocol [Online] Tillgänglig: [Hämtad: 15:e april, 2012]. [16] Understanding WebSocket handshake [Online] Tillgänglig: [Hämtad: 23:e maj, 2012] [17] JQuery [Online] Tillgänglig: [Hämtad: 25:e april, 2012]. [18] P. Bengtsson, Are WebSockets faster than AJAX?...with latency in mind? [Online] Tillgänglig: [Hämtad: 28:e april, 2012]. [19] Web Platform Status Tillgänglig: [20] WebSockets [Online] Tillgänglig: [Hämtad: 23:e april, 2012]. [Hämtad: 21:a maj, 2012] [21] jquery.ajax() [Online] Tillgänglig: [Hämtad: 17:e april, 2012]. [22] Introducing JSON [Online] Tillgänglig: [Hämtad: 23:e maj, 2012] [23] Apache 2.x on Microsoft Windows [Online] Tillgänglig: [Hämtad: 23:e maj, 2012]. [24] pywebsocket [Online] Tillgänglig: [Hämtad: 12:e april, 2012]. [25] Browserscope [Online] Tillgänglig: [Hämtad: 9: maj, 2012]. 29