Spotify strömning av musik. Fredrik Rosenqvist, Henrik Andersson Linköpings universitet Linköping

Transkript

1 Spotify strömning av musik Fredrik Rosenqvist, Henrik Andersson Linköpings universitet Linköping

2

3 Sammanfattning Denna rapport behandlar streamingtjänsten Spotifys uppbyggnad ur ett dataöverföringsperspektiv. Rapporten presenterar lösningar för överföring av ljud genom att delvis fokusera på användningen av olika kommunikations- och transportprotokoll som UDP, SCTP och TCP. Huvuddelen handlar om Spotifys strömningskonstruktion samt tillämpningar av transportprotokollet TCP. Dessutom behandlas uppbyggnaden av Spotifys nätverk som på ett smidigt och pålitligt sätt levererar musik till tjänstens användare. Rapporten presenterar strömningsbegreppet samt olika lösningar för detta på ett övergripligt plan medan det tekniska djupet i rapporten riktar fokus på Spotifys utnyttjande av TCP(Transmission Control Protocol). Spotify har löst problemen som TCP kan föra med sig, som t.ex. lång väntetid jämfört med andra transportprotokoll. Detta har gjorts genom att bl.a. använda ett peer-to-peer-nätverk ovanpå sitt klient-server-nätverk för att få ut maximal kapacitet av protokollet.

4 Innehållsförteckning 1. Inledning Syfte Metod och källor Avgränsningar Streaming Spotifys streaming Streamingkonstuktionen Kontakten med andra användare Anslutning till andra Peers UDP SCTP RTSP HTTP Livestreaming Transmission Control Protocol (TCP) Handskakningsfunktionen Congestion Control Skillnader mellan TCP och UDP Diskussion och slutsats Fördelar/nackdelar med TCP istället för UDP Referenser...16

5 1. Inledning Spotify är en musiktjänst som med hjälp av streaming erbjuder användare musik från ett musikregister på över 8 miljoner musikstycken. Spotify finns i flera versioner. Det finns två gratisversioner, Spotify Open och Spotify Free. Dessutom finns en betalversion av tjänsten, Spotify Premium, som erbjuder bland annat bättre ljudkvalitet [1]. Tjänsten är uppbyggd genom en fördelning av streamingtrafiken mellan ett serverklient-nätverk samt ett peer-to-peer-nätverk. Vidare är tjänsten uppbyggd på ett sätt som ger kort väntetid mellan dess att en låt väljs och att den börjar spelas upp [1]. I denna rapport behandlas dels streaming i allmänhet men Spotifys streaming i synnerhet. Då det finns många olika lösningar för överföring av ljud så ska vi undersöka dels vilka som finns men framförallt fördjupa oss i Spotifys lösning och utreda varför de har valt just den. Vi kommer även jämföra och utreda fördelar och nackdelar med olika protokoll för streaming av ljud Syfte Anledningen till att vi valt ämnet är för att få en djupare insikt i begreppet streaming, och kunna få en ökad kunskap om hur tjänster som Spotify och liknande fungerar. Vi tror att genom undersökning av streaming kommer vi få en djupare insikt i hur olika protokoll fungerar och då få en ökad förståelse för övriga moment i kursen. Utifrån dessa kunskaper ska vi även försöka hitta lösningar på de problem som kan uppstå Metod och källor Spotify är en proprietär tjänst. Detta innebär bl.a. att vissa av deras metoder för att överföra media är skyddade för att hindra risken för plagiat. Då detta gör det svårt att studera tjänstens funktioner genom t.ex. Wireshark är den huvudsakliga metoden som använts för denna rapport en litteraturstudie av olika slag. Kontakt har tagits med Spotifys kundtjänst för att få ta del av information kring uppbyggnaden av tjänsten. Vi har även undersökt streaming mer allmänt både genom att söka litteratur i skolans bibliotek samt via undersökning av olika protokoll som är vanliga vid streaming. Tack vare en djupare uppfattning om de olika protokollen har vi kunnat dra egna slutsatser om olika tjänster som tillhandahåller streaming Avgränsningar För att på ett begripligt sätt kunna beskriva Spotifys strömning av musik så har vi på en djupare teknisk nivå valt att beskriva hur tjänsten använder sig av TCP vid överföring av ljud. Vi har valt att avgränsa oss till endast TCP då övriga protokoll som används av tjänsten är skyddade i upphovsrättssyfte. För att få insikt i hur Spotifys strömningstjänst skiljer sig jämfört med andra finner vi det relevant att även ge en beskrivning av hur övrig vanligt förekommande streaming går till. Här har vi valt att avgränsa oss till att endast övergripande beskriva denna streaming för att kunna skapa en insikt om skillnader mellan tjänsterna.

6 2. Streaming Streaming eller strömning är multimedia som ständigt tas emot och presenteras för en slutanvändare efter leverans från en källa. Namnet syftar alltså till själva mottagandet av strömmen snarare än distributionen som kan se mycket olika ut. De flesta strömningstjänsterna idag använder sig av någon form av webb-baserad mediaspelare som exempelvis Adobe Flash eller liknande. De använder också oftast en ren server till klient-applikation utan peer-to-peer komponenter [2]. Strömning kan i sin tur ske antingen på begäran (On Demand) eller levande (live), så kallad True Streaming. True Streaming skickar all information direkt till klienten som spelar upp innehållet utan att först lagra det någonstans. Detta ska inte förväxlas med progressive streaming som först lagrar filen på hårddisken men som samtidigt har möjlighet att spela upp den del av filen som är nedladdad. Detta är egentligen en form av nedladdning som On Demand-tjänster använder sig av [2]. Själva strömningen är egentligen bara leveransen av tjänsten men det är flera steg som måste uträttas för att göra strömningen möjlig. Först och främst så måste ljud filen vara komprimerad till en ljud-codec, t.ex. MP3 samt videofilen till en videocodec, t.ex. H.264 eller WebM. Kodade och komprimerade mediafiler samlas i sin tur i en bitström som kan levereras till klienten med hjälp av ett transportprotokoll t.ex. UDP eller TCP. Klienten kan sedan interagera med den strömmande källan genom ett kommunikationsprotokoll (även kallat control protocol) som kan hantera den skickade mediaströmmen. Vanliga protokoll för detta ändamål är RTCP och HTTP- Livestreaming. Vissa protokoll fungerar både som transportprotokoll och control protocol [3]. Vad som också är gemensamt för alla strömningstjänster är att man använder sig av ett content delivery network (CDN) för att distribuera och leverera innehållet. CDN som kan se mycket olika ut är en tjänst som erbjuds kommersiellt av bland annat cdn.com och edgecast.com. Det används för att upprätthålla största möjliga bandbredd för användarna i nätverket genom att låta kopior av data vara placera på flera ställen i nätverket. Klienten kan på så sätt hämta data från närmaste möjliga källa istället för direkt från huvudservern [4]. CDN består alltså av ett antal noder (markerade med nummer 2 i figur 1) strategiskt utplacerade för att kunna både leverera information samt för att kunna omdirigera förfrågningar för att sprida belastningen i nätverket. Om alla klienter istället strömmar direkt från huvudkällan (markerad med nummer 1 i figur 1) så är risken för flaskhalsar stor vilket minskar bandbredden och begränsar antalet användare (markerade med nummer 3 i figur 1). Risken för överbelastning blir också överhängande [5]. 6

7 Figur 1.[6] Bilden visar uppbyggnaden av ett content delivery network. 1: Huvudserver 2: Utplacerade noder 3: Klienter. Själva distributionen och uppbyggnaden av fungerande nätverk har visat sig vara en stor marknad för kommersiella aktörer då problemen som ofta kan uppstå är komplexa och svåra att lösa. Det finns därför många företag som riktar in sig på att sälja in sina strömningslösningar till exempelvis TV-bolag som allt mer övergår till att sända digitalt och erbjuda On-Demand-tjänster [5]. 3. Spotifys streaming Till skillnad från den streaming som beskrivits ovan använder sig Spotify av en annorlunda metod för att kunna erbjuda sina klienter en (vad de anser är) mer optimal streaminglösning. Streamingtjänsten Spotify är uppbyggd delvis av ett klient-server nätverk, men också av ett peer-to-peer-nätverk. Mellan dessa är användarnas trafik fördelad på ett sätt som optimerar streamingtjänsten ur ett tidsperspektiv genom att väntetiden mellan att en låt väljs och att den börjar spela är kort. Spotifys streaming är konstruerad att lägga en stor del av sin internettrafik på peer-to-peer-nätverket för att på ett uppfinningsrikt sätt kunna distribuera musik snabbare [1] Streamingkonstuktionen Precis som genom den streaming som beskrevs tidigare är får en användare som skickat en förfrågan efter en specifik låt tillbaka en ström av musiken från en källa. Då många steamingtjänster använder sig av UDP för att kunna hålla nere fördröjningstider använder sig Spotify istället av TCP som tjänstens transportprotokoll [1]. Detta görs av tre anledningar: 1. Då dataströmmen är pålitlig underlättar detta hanteringen av filen av resten av tjänsten. 2. P.g.a. TCPs congestion control är protokollet mer vänligt mot nätverket och strömmar av media riskerar inte att sätta helt stopp i nätverket. 7

8 3. Då den strömmade median delas i peer-to-peer-nätverket underlättar protokollet för återförfrågningar efter eventuellt försvunna paket. En signifikant del av Spotifys streamingkonstruktion är uppdelningen av dataströmmen. Delvis delas dataströmmen upp i block (1,2,3,4 i figur 2.). Detta är med anledning av att tjänsten använder sig av TCP protokollet och då inte klarar av att skicka hela mediefiler på en gång p.g.a. deras storlek. Dessutom delar Spotify upp varje block i ett antal delströmmar (A1,B1,C1,D1, osv. i figur 2) [1]. Figur 2.[7] Syftet med uppdelningen är att en användare snabbare ska kunna hämta hem ett specifikt block. Detta genomförs genom att en användare kan hämta de olika delarna av ett specifikt block från olika källor och på så sätt endast behöver använda en mindre del av bandbredden till att hämta varje del. Samtidigt kan varje del hämtas från den källan med bäst uppladdningshastighet. Då alla delar av ett block hämtats sammanflätas dessa till ett helt block som kan spelas upp av användarens mjukvara. Detta är en av fördelarna med TCP jämförd med UDP. Med UDP skickas en fil från en klient i rätt ordning men hos mottagaren finns ingen kontroll av vilken ordning de paket som kommer har. Detta gör att hela filen måste laddas ner och sorteras innan filen garanterat kan spelas upp i rätt ordning. TCP använder istället en kontrollfunktion som undersöker vilken ordning blocken kommer till mottagaren. Då detta sker kan t.ex. en ljudfil börja spelas upp redan då första blocket tagits emot av användaren [1]. Då en låt har spelats upp av användaren kodas den om och varje block delas upp i delar igen. Därefter lagras filen i användarens dator. Lagringen görs delvis för att användaren ska kunna spela upp låten direkt från minnet vid ett senare tillfälle. Detta minskar trafiken på nätverket då en användare inte behöver ladda ner samma låt flera gånger. Det bör nämnas att minnet för den lagrade musiken inte är oändligt. Då minneskapaciteten är fylld rensas den äldsta och minst återanvända musiken ut då ny musik lagras. Då musiken lagras på användarens dator kan det tyckas att musiken borde kunna spelas upp även om användaren är offline. Detta är endast möjligt i en av Spotifys tre versioner (Premium-versionen) även att alla tre tillämpas samma lagringsprincip. För de övriga två versionerna krävs en anslutning till Spotifys server. Detta beror på att Spotify använder sig av DRM (digital rights management) vilket är en teknik för att kontrollera spridningen av bl.a. musik. Denna teknik kräver att en användare som vill spela upp en låt från sitt minne måste skicka en förfrågan till Spotifys server om att få spela upp låten. Endast då ett godkännande kommer tillbaka från servern kan Spotify spela upp låten. Dock kan användaren genom att betala extra för Spotify få Premium-versionen där offline-spellistor kan synkroniseras [1]. 8

9 En annan anledning till att musikfiler lagras på en användares hårddisk är att det öppnar upp ytterligare en möjlighet för distribution av musiken. Spotify har designats så att varje användare kan vidaredistribuera den musik som han/hon tidigare laddat hem via tjänsten. Dessa användare kan precis som Spotifys server ta emot förfrågningar efter filer och då skicka en eller flera delar av block till någon annan användare. Detta minskar belastningen på Spotifys server och gör systemet mer redundant då det ökar tillgängligheten av varje fil på nätverket. Serverns får istället en understödjande roll där den hjälper till med distribution då delar av ett block saknas eller då en användare inte tar emot block tillräckligt snabbt. Det senare kan bero på låg uppladdningshastighet hos den distribuerande användaren [1]. För att hålla koll på detta har Spotify ett system som registrerar hur stor del av en fil som finns i en användares buffert på väg att spelas upp. Spotify håller koll på de inkomna paketen genom att ha två signalnivåer implementerade i uppspelningsbufferten, LÅG och HÖG. Om andelen nedladdade blockdelar från en peer understiger LÅG-nivån (Se figur 3,a) växlar Spotify nedladdningen av just den blockdelen till att hämta denna från Spotifyservern. Spotify servern har en garanterad bandbredd till skillnad från användare där ned och uppladdningshastigheten kan variera. Spotifys server fortsätter att förse användaren med blockdelen till dess att antalet av nedladdade blockdelar överstiget HÖG-nivån (Se figur 3,b). Då detta sker växlar nedladdningen från servern till en peer i peer-to-peer-nätverket i syfte att behålla maximal bandbredd hos servern [1]. Figur 3,a [7] Figur 3,b [7] 3.2. Kontakten med andra användare Då en användare loggar in på Spotify upprättas automatiskt en TCP anslutning med vissa av tjänstens servrar. Bland annat skapas en anslutning till en s.k. Tracker (liknande Bittorrents tracker) [1]. En tracker är en server som har till uppgift att hålla koll på vilka datorer som inloggade på ett specifikt nätverk. Trackern kan dessutom hålla koll på vilka filer en specifik användare har att erbjuda och sedan vidarebefordra den informationen till andra användare [8]. Då en Spotifyanvändare är på jakt efter en låt används två principer för att hitta låten och hämta hem den till användaren. Delvis skickas en förfrågan till Spotifys tracker 9

10 efter användare som har den specifika låten. Trackern svarar då med en lista på max 10 sådana användare (om mediefilen finns hos några användare förstås). Därefter väljer användarens mjukvara ut en eller flera användare dit en förfrågan efter låten skickas. Själva valet av användare är bl.a. baserat på uppladdningshastighet hos källan samt hur många andra som källan distribuerar musik till [1]. Spotifys andra sätt att hitta en låt är genom att skicka ut förfrågningar till sina s.k. grannar. Då en användare söker efter en låt med hjälp av trackern, hittar användare och laddar ner låtar från dessa kommer användarens Spotify ihåg dessa användare. Användarna blir då grannar med varandra. Då en användare senare är på jakt efter en ny låt skickas den nya förfrågningen till både Spotifys tracker samtidigt som förfrågningen skickas till alla grannar. Användarna som får förfrågan undersöker delvis om de själva har låten men skickar också vidare förfrågan till sina grannar. Denna metod kan generera ett sänkt tidsintervall mellan att förfrågan skickas och en användare hittas som har låten i jämförelse med att skicka frågan till trackern [2] Anslutning till andra Peers Peer-to-peer-nätverket använder sig av TCP som transport protokoll. Då en peer vill ansluta sig till en annan peer i syfte att ladda ner en låt sker detta i två steg. Först skickas en förfrågan från peer 1 som vill ansluta genom Spotifys server till peer 2 som önskas ansluta till. Förfrågan ber peer 2 att försöka skapa en TCP anslutning med peer 1 som skickat förfrågan. Samtidigt används UPNP protokollet (Universal plug n play) för att be routern hos peer 1 om en port som kan ta emot anslutningar [1]. UPNP är et protokoll som används för att enheter ska kunna ansluta sig till ett nätverk och används vanligtvis för att underlätta för implementation av ett nätverk i hem eller på arbetsplatser [9]. När sedan förfrågan om TCP-anslutning kommer från peer 2, returnerar peer 1 svar till peer 2 med uppgifter om bl.a. anslutningsport. TCP-anslutningen är upprättad och förfrågan om filer kan börja strömma in [1]. Detta kan tyckas vara ett krångligt sätt att ansluta på men det har sina skäl. Eftersom många användare idag använder sig av brandväggar försvårar detta för anslutning mellan två peers. En säkerhetsåtgärd som brandväggar erbjuder är att kontrollera behörighet på den på trafik som vill ansluta till t.ex. ett hemnätverk [10]. Om den som vill ansluta inte har någon behörighet nekas denna anslutning. För att kunna ta sig runt detta i Spotify skickar istället den peer som vill ansluta sin förfrågan via Spotifys server. Spotifys server har en redan upprättad anslutning till den peer som önskas anslutas till vilket gör att denna peer accepterar trafik från servern. Under tiden skapar den peer som vill ansluta en behörighet för en kommande anslutningsförfrågan. 4. Vanligt förekommande protokoll för strömning Nedan följer en presentation av de vanligast förekommande protokollen för strömning av media. Vi har här valt att utelämna TCP här och istället ta upp det i ett eget kapitel UDP Det vanligast förekommande transportprotokollet för strömning av media är UDP (User Datagram Protocol). Den främsta orsaken till detta är att det är ett enkelt och effektivt sätt att leverera paket. Nackdelen är att det inte finns någon mekanism som 10

11 garanterar att alla paket kommer fram. Det är istället upp till klienten att upptäcka när data gått förlorad och skicka en ny begäran till servern vilket kan märkas genom att media hackar eller har störningar. UDP är ett förbindelselöst protokoll som låter information flöda i en riktning från servern till klienten. Det sker alltså ingen verifikation av att mottagaren är beredd att ta emot informationen. UDP lägger alltså över det kvalitativa ansvaret på klienten [11]. Spotify har löst det här problemet genom att använda TCP (Transport Control Protocol) som är ett förbindelseorienterat protokoll för sin transport. Till skillnad från UDP sker TCPs kommunikation mellan två noder i ett nätverk lite annorlunda. Detta presenteras lite mer ingående i nästa kapitel [11] SCTP Ett vanligt återkommande protokoll för livestreaming är SCTP (Stream Control Transmission Protocol) som är skräddarsytt för strömning genom att den utgör en kombination av TCP och UDP. SCTP låter likt UDP dela upp strömmen i mindre mer lätthanterliga bitar men säkerställer ändå likt TCP att paketen kommer fram med hjälp av congestion control. En annan lösning för att hindra förlusten av paket är att SCTP använder sig av flera IP-adresser för att upprätta flera anslutningar till ändpunkterna. Detta gör att om en anknytning förloras så kan överföringen fortsätta på en alternativ väg [12] RTSP RTSP (Real Time Streaming Protocol) används för att kontrollera media mellan två ändstationer. Det är designat för att hantera kommunikationssystem och underlätta kontrollen av strömmande mediaservrar. Protokollet låter bland annat klienten pausa och spola i den strömmande median vilket gör det väldigt likt vanligt filmtittande. Protokollet sköter inte själva transporten av median utan använder sig vanligtvis av transportprotokollet RTP (Real-time Transport Protocol) [13] HTTP Livestreaming HTTP-Livestreaming (HLS) är ett http-baserat mediastreamings kommunikationsprotokoll från Apple Inc. Tekniken låter dela upp dataströmmen i en sekvens av små http-segment. Varje segment laddar i sin tur en liten del av en potentiellt sett obegränsad transportström [14]. Då varje efterfrågan som skickas är av en standardtyp för HTTP-transaktioner så är detta fördelaktigt då alla brandväggar kommer behandla det som vanlig HTTP-trafik till skillnad mot användning av UDP-baserade protokoll. Detta underlättar även genomförandet för CDN [14]. 11

12 5. Transmission Control Protocol (TCP) Transmission Control Protocol eller TCP är ett av de protokoll som används i Spotifytjänsten. TCP är ett protokoll som tillhör transportlagret och är ett av de mest använda transportprotokollen på internet. Ett transportprotokolls roll är att upprätta kontakt mellan noder i ett nätverk. Dessutom ansvarar transportprotokolet för att erbjuda en dataström av paket mellan dessa noder. TCP kan beskrivas som ett pålitligt, förbindelseorienterat transportprotokoll [11]. Nedan förklaras vad som menas med pålitligt och förbindelseorienterat. Dessutom presenteras några vanligt förekommande funktioner hos TCP samt vad som skiljer protokollet från andra transportprotokoll Handskakningsfunktionen Anledningen till att TCP beskrivs som ett förbindelseorienterat transportprotokoll är eftersom protokollet kräver att en förbindelse har upprättats mellan två noder innan dataöverföring kan ske. Därför inleds alltid en dataöverföring där TCP används med en hanskakning mellan de två noderna överföringen ska ske mellan. Det är i detta momentet som förbindelsen skapas [11]. Handskakningsfunktionen kan beskrivas i tre steg. 1. Den nod som vill ansluta skicka ett paket till den nod som ska anslutas till. Paketet innehåller en s.k. synkroniseringsflagga som gör mottagaren uppmärksam på att en ny anslutning ska skapas och att avsändaren är redo att ansluta [11]. 2. Om mottagaren godkänner anslutning skickas ett svar på synkroniseringsflaggan. Mottagaren skickar då tillbaka ett paket med en dels en synkroniseringsflagga och dessutom en s.k. acknowledgementflagga till avsändaren. Acknowledgementflaggan innebär att mottagaren mottagit paketet med synkroniseringsflaggan. Synkroniserigsflaggan som också skickas med innebär att mottagaren också vill upprätta en anslutning och är redo för detta [11]. 3. Den nod som ville ansluta från början skickar som en avslutning på handskakningen tillbaka ett paket med en acknowledgementflagga som en konfirmation på att meddelandet är mottaget. Nu är båda noderna redo att skicka information mellan varandra [11]. Bilden nedan kan illustrera hela handskakningsprocessen. Figur 4. [15] 12

13 5.2. Congestion Control Då mycket information skickas över internet kan det ibland hända att ett paket som en klient skickar iväg försvinner på vägen. Detta kan bero på att trafik som kommer till en router i nätverket kommer i större mängd än vad routern klarar av att hantera. Resultatet blir att de paket som kommer till routern hamnar i en kö som växer och växer. Routern klarar av att hålla en viss mängd paket i kön men då kön blir för lång börjar routern att dumpa paket för att klara av delar av trafiken [11]. Då en klient använder sig av TCP som transport protokoll innefattar detta att klienten som skickar ett paket får ett svar från destinationen om paketet kommit fram. Svaret som klienten får är ett paket med en ACK-flagga samt information om vilket paket som kommit fram [11]. Om en situation skulle uppstå där en klient inte får tillbaka någon konfirmation på att det skickade paketet kommit fram, väntar klienten en viss tid på att svar ska komma. Om det fortfarande saknas svar efter den tiden anses paketet som försvunnet och ett nytt likadant skickas. Detta är en del av TCPs pålitlighet [11]. I många fall finns ett behov hos klienter/servrar att kunna uppnå en optimal hastighet för informationsöverföringen och samtidigt kunna säkra att informationen kommer fram. För att kunna tillhandahålla detta har TCP en funktion som kallas Congestion Control [11]. Tanken bakom funktionen är just att se till att paket levereras så fort som möjligt och samtidigt försöka att undvika att paket försvinner. I processen ingår tre delar [11]: Slow-start Congestion avoidance Fast recovery Slow-start är den inledande delen av funktionen. Då en klient/server vill skicka en mängd paket finns något som heter Maximum segment-size (MSS). Detta är ett mått på hur många paket som får skickas samtidigt. I början av en överföring är ofta MSS = 1. Klienten/Servern skickar ett paket till mottagaren. Då klienten får ett ACK (paketet har kommit fram) från mottagaren ökas MSS på enligt formeln MSS = 2*MSS. Alltså skickas nu istället två paket samtidigt. Då ACK kommer för dessa skickas nästa gång fyra paket och så vidare. Denna exponentiella ökning fortsätter till dess att ett paket försvinner vilket märks av genom att klienten/servern helt enkelt inte får nått ACK för ett paket. Det som sker då är att MSS registreras och en tröskel skapas vid halva MSS (Om MSS är 8 skapas tröskeln vid 4). Därefter återställs MSS till 1 igen. Nu börjar processen med exponentiellt ökande mängd skickade paket till dess att MSS når tröskelnivån. Då detta sker, sker en övergång från Slowstart till Congestion avoidance [11]. Då Congestion avoidance inleds över går ökningen av MSS till formeln MSS = MSS+1. Detta gör att mängden skickade paket ökar linjärt istället från denna punkt. Detta görs för att kunna komma närmare den maximala nivån för hur många paket som kan skickas samtidigt. Processen fortsätter till dess att ett nytt paket försvinner. Då detta sker registreras på samma sätt som tidigare MSS och en tröskel skapas 13

14 precis som tidigare. Därefter sker en övergång från Congestion avoidance till Fast recovery [11]. Fast recovery är en funktion som implementerats i den senaste versionen av TCP (TCP Reno). I den tidigare versionen (TCP Tahoe) återgick Congestion control till Slow-start varje gång ett paket försvann. Fast recovery är istället ett sätt att snabbare återgå till en optimal överföringshastighet. Funktionen triggas då tre ACKs för fel paket har kommit tillbaka till avsändaren. Då paket skickas med TCP hållet protokollet koll på vilket paket som skickades först. Det då svaren kommer tillbaka från mottagaren kommer dessa vanligtvis i samma ordning som paketen skickades ut. På så sätt kan protokollet hålla koll på om paket försvunnit. Anledningen till att det är just tre ACKs som inväntas är att det kan inträffa att ordningen på paket ändras om under tiden de skickas över nätverket. Detta kan göra att ett eller två ACK kommer tillbaka i fel ordning till avsändaren. Dock anses att det finns stor risk för att ett paket försvunnit då tre eller fler ACK för fel paket kommer tillbaka. Då detta sker börjar minskar MSS till tröskelnivån (MSS/2) istället för till 1. Fast recovery börjar alltså skicka fler paket på än gång än tidigare. Då detta sker över går Fast recovery fasen tillbaka till Congestion avoidance därifrån [11] Skillnader mellan TCP och UDP Idag finns många transportprotokoll, men de två vanligast förekommande protokollen är TCP och UDP. Dock finns väsentliga skillnader mellan de två protokollen som kan avgöra om det ena eller andra passar bäst för ett visst ändamål [11]. TCP erbjuder en pålitlig dataström genom en kontroll av vilka paket som skickats över nätverket, vilka paket som inte skickats och vilka paket som kommit fram. Detta gör att om ett paket inte kommit fram kan en ny efterfrågan efter just detta paket skickas. UDP däremot har ingen sådan funktion. Detta göra att då en fil skickas finns ingen garanti för att denna kommer fram [11]. TCP erbjuder congestion control vilket delvis innebär att protokollet strävar mot att uppnå en optimas överföringshastighet med så liten risk för att paket försvinner som möjligt. Detta sker genom slow-start, congestion avoidance, samt fast recovery. Funktionerna minskar risken för att routrar på nätverket dumpar paket. UDP däremot har inte dessa funktioner vilket gör att de paket som skickas med en så maximal överföringshastighet på nätverket som kan uppnås. Detta göra att stora delar av paketen riskerar att dumpas av en router om kö har skapats vid denna [11]. Den tid det tar att överföra filer kan skilja sig mellan de två protokollen. Då TCP bl.a. har många funktioner som ska garantera att hela filer kommer fram påverkar detta överföringstiden. UDP däremot kan minska tiden det tar att överföra en fil genom att inte ha dessa funktioner. Detta gör att de två protokollen lämpar sig bäst i olika arbetsområden. TCP är ofta använt där stor relevans finns för att all information i de filer som skickas kommer fram. Detta applikationer där detta är relevant är t.ex. e- mail eller nedladdning av filmfiler. Applikationer där detta däremot inte är livestreaming eller onlinespel. I dessa fall finns istället större krav på att information når användaren snabbt [11]. 14

15 6. Diskussion och slutsats Spotify är ett system som även att det använder TCP lyckas att strömma musik med en mycket låg väntetid. Systemet är uppbyggt på ett sätt som effektivt avlastar Spotifys server från onödig trafik och samtidigt gör systemet redundant genom att förvara filer hos användare. Tjänsten erbjuder flera möjligheter till att optimera både väntetid på en fil samt nedladdningshastighet. Detta bl.a. genom att de strömmade blocken kan delas upp i delblock som kan hämtas från de användare som har bäst uppladdningsförutsättningar. För att sammanfatta Spotify kan man säga att tjänsten genom sin sina funktioner har tagit strömning av ett steg framåt i utvecklingen mot den optimala strömningsfunktionen. I detta kapitel ska vi försöka reda ut varför Spotify har valt lösningarna som de gjort. Bland annat utreder vi varför Spotifys lösning av tillhandahållande av strömning av musik har blivit mer populär än konkurrenters. Vi ska även ta upp varför de har valt att använda TCP som transportprotokoll och jämföra det med det vanligaste transportprotokollet för streaming UDP Fördelar/nackdelar med TCP istället för UDP Som vi har beskrivit ovan har Spotify genom sina funktioner lyckats att använda sig av TCP protokollet och fortfarande lyckas erbjuda relativt kort väntetid. En annan av de fördelar TCP erbjuder är möjligheten att snabbt kunna upptäcka om någon av den informationen som skickas inte kommer fram. Det är då enkelt att skicka en ny förfrågan för just denna information och snabbt kunna rätta till problemet. UDP är ett protokoll som kan anses ytterligare förkorta väntetiden tills ett musikstycke kan laddas hem. Detta eftersom funktioner så som att sätta upp en anslutning till mellan klient och källa samt att hålla koll på paketens ordning o.s.v. saknas. Dock kan detta påverka kvaliteten på den strömmade musiken då UDP inte ger någon garanti på att hela de strömmade filerna kommer fram. Dessutom skulle inte den konstruktion som Spotify bygger på idag kunna använda sig av UDP. Detta eftersom tjänsten är uppbyggd för att de block som hämtats hem ska kunna spelas upp direkt. Om ingen garanti finns för att ordningen på de block som kommer är i rätt ordning kan detta leda till stora hopp i låtarna. Detta sänker kvaliteten. En annan av fördelarna med TCP är den optimering av överföringshastigheten som han göras tack vare TCPs congestion control. Denna motverkar samtidigt att paket försvinner vid överföring över nätverket. 15

16 Referenser [1]. Patent och registreringsverket. (2009) Beskrivning. Hämtad 8/ från [PDF]< >. [2]. Grant and Meadows. (2009) Communication Technology Update and Fundamentals, 11th Edition. pp.114 [3]. ISO. (2011). Streaming. Hämtad från [www]< [4]. Saltzer. JH, Reed. DP, Clark. DD. (1984) End-to-End Argument System Design, ACM Transactions on Communications, 2 (4) [5]. Hofmann, Markus; Leland R. Beaumont (2005) Content Networking: Architecture, Protocols, and Practice. [6]. Content delivery network CND. Hämtad från [JPG]< [7]. Patent och registreringsverket. (2009) Ritning. Hämtad 08/ från [PDF]< [8]. Wikipedia. (2010) Bittorrent-tracker. Hämtad från [www]< [9]. Wikipedia. (2010) UPnP. Hämtad från [www]< [10]. Wikipedia. (2011) Brandvägg. Hämtat från [www]< [11]. J. Kurose, K. Ross. (2010) Computer Networking A top down approach, fifth edition. [12]. Strewart. R. (2007) RFC 4960 Steam control transmission protocol, Hämtat 22/ från [www]< [13]. Schulzrinne. H, Columbia. U, Rao. A, Lanphier. R (1998) RFC 2326 Real time streaming protocol, Hämtat 22/ från [www]< [14]. GravityLab Multimedia. (2010) HTTP livestream Hämtad från [www]< [15]. IBM (2006) 3-way handshake. Hämtad 19/ från [www]< 16