Accelerering av filhämtning

Accelerering av filhämtning Undersökning av inställningar i Windows för optimerad nedladdning Markus Fridolfsson Mikael Malmström TDTS09 Datornät och internetprotokoll Linköpings universitet Linköpings 2011-02-20

Sammanfattning I rapporten undersöker vi vilka inställningar man kan göra för att påverka sin nedladdning. Då Transmission Control Protocol (TCP) är det mest använda protokollet i det så kallade transportlagret (enligt five layer protocol stack, boken sid 77) börjar vi med att gå igenom hur olika inställningar i TCP kan förbättra nedladdningen. Vi berör TCP-fönstret, congestion control och Explicit Congestion Notification (ECN). Därefter går vi in på de två stora arkitekturerna, client-server och peer-to-peer (decentralicerad). Under client-server tar vi upp parallell-tcp och dess för- och nackdelar samt ett protokoll som behandlar de baksidor parallell-tcp innebär, såsom missbruket av TCP-fairness. Under peer-to-peer så tar vi upp det stora protokollet som använder den arkitekturen, nämligen BitTorrent. Genom en undersökning av hur protokollet hanterar TCP-kopplingar och prioritering av vilken kilent man kommer att välja att försöka hämta ifrån och vem man låter ansluta till sig själv, så kan vi se hur man kan påverka hur snabbare kan ladda hem filer med hjälp av BitTorrent

Innehållsförteckning 1 Inledning... 4 1.1 Syfte... 4 1.2 Metod och källor... 4 1.3 Avgränsningar... 4 2 Transmission Control Protocol... 5 2.1 Så fungerar TCP... 5 2.1..1 Three-way handshake... 5 2.1..2 Slow start... 5 2.1..3 Congestion avoidance & control... 5 2.1..4 Fast Retransmit... 6 2.2 Optimering av TCP... 6 2.2..1 Advertised Window... 6 2.2..2 Congestion control... 7 2.2..3 Explicit Congestion Notification... 7 3 Server-Client... 8 3.1 Parallell TCP... 8 3.1..1 Problematik... 8 4 Peer-to-peer... 8 4.1 BitTorrent... 9 5 Diskussion och slutsatser... 10 5.1 BitTorrent... 10

1 Inledning Det blir allt vanligare att man laddar ner stora filer från nätet, ex köper spel och programvara eller hyr filmer. Detta leder till att det ställs högre krav på våra nedladdningshastigheter, även om det inte har någon betydelse för funktionaliteten så vill generellt inte människor vänta längre tid än att det tar att gå till butiken och införskaffa varan. Vi har valt att titta närmre på hur man som privatperson kan öka sin egen prestanda genom att undersöka hur protokollen fungerar och därmed möjligheten att optimera sin klient för att accelerera sin fil-nedladdning. De två vanligaste sätten att hämta hem filer; antingen direkt från en server (Server-Client) eller genom decentraliserad Peer-to-peer (P2P), då man hämtar små segment av filen direkt från mängder av olika klienter (ex BitTorrent). Gemensamt för båda är att de använder sig av Transmission Control Protocol (TCP) för att skapa en kontakt med den önskade sändaren. Vi kommer först beskriva hur TCP fungerar för att senare gå in närmare på Server-Client och P2P (Kurose & Ross, 2010). 1.1 Syfte Då majoriteten av all trafik på internet använder sig av TCP har vi valt att undersöka hur TCP fungerar. Vi vill även se hur man kan påverka sin egen nedladdningshastighet utifrån de inställningar man kan göra själv som påverkar TCP och BitTorrent protokollen. Vi vill även ta en liten titt på några av de problem som kan uppkomma vid manipulation av protokollen. 1.2 Metod och källor Vi har undersökt och analyserat olika hjälpguider, Request For Comments dokument (RFC), litterära verk och rapporter för att skapa oss en djupare förståelse om vad det är som påverkar hastigheten på nedladdningen av filer via internet. Därigenom så kan vi skapa oss en uppfattning om vad man som användare kan göra för att accelerera sin filhämtning. 1.3 Avgränsningar Vi har valt att begränsa oss till vad man som slutanvändare kan göra för att påverka sin nedladdningshastighet. Vi har även valt att begränsa oss till Windows OS av praktiska skäl. Hur serverns protokoll och hur ISPerna sköter sin trafik har vi valt att inte behandla då det är något vi inte kan påverka själva. 4

2 Transmission Control Protocol TCP protokollet bygger på Leonard Kleinrocks ARPANet som var världens första packet switching network framtaget för amerikanska militären i början på 70-talet. Vinton Cerf och Robert Kahn jobbade sedan vidare på idén och tog i början av 80-talet fram Internet Protocol Suite, en samling protokoll för nätverkstrafik även känt som TCP/IP. ARPANet var främst inriktat mot militära användningsområden men i och med TCP/IP blivit väl utbrett över hela internet. Protokollet har sedan tidigt 80-tal inte förändrats särskilt mycket. Några tillägg för att förbättra och anpassa sig till ny teknik finns men i stort sett är ser det likadant ut idag. Vi ser till några av dessa längre fram men först beskriver vi grundstommen i TCP (Kurose, 2010, wikipedia). 2.1 Så fungerar TCP TCP är det protokoll i transportlagret som används mest vid filöverföring på internet. När man surfar på internet så förlitar sig HTTP protokollet sig på TCP. Likaså då man skickar information via FTP eller använder SMTP för att läsa sin e-post. TCP använder sig i sin tur av IP (Internet Protocol) för att guida paketen till rätt mottagare, man refererar ofta till dessa två protokoll tillsammans TCP/IP (Kurose, 2010). 2.1..1 Three-way handshake En TCP-koppling börjar alltid med en så kallad threeway handshake vilket innebär att klienten skickar iväg ett paket med ett önskemål om att synkronisera (en SYN-flagga satt i TCP-headern) till den önskade servern. Servern svarar då med att godkänna uppkopplingen och samtidigt vilja synkronisera med klienten (SYNACK-flagga). Slutligen svara klienten med att godkänna servern med en ACK. När kontakten är etablerad så kan båda parterna skicka data till varandra (RFC 793). 2.1..2 Slow start För att inte chocka mottagaren med data har man infört en uppstart som börjar långsamt och sedan ökar successivt. För varje segment som skickas från servern svarar klienten med en ACK för att berätta att paketet kommit fram. Under en slow start situation kommer servern att skicka två nya paket för varje ACK som mottagits. Det man har gjort är att införa något som kallas för congestion window hos sändaren. När en ny kontakt skapas sätter man cwnd till ett och för varje mottaget ACK så ökas congestion window med ett. Då mottagaren inte alltid skickar ett ACK för varje paket som mottagits utan kan ibland godkänna flera paket i ett svep så blir inte tillväxtkurvan på fönstret riktigt exponentiellt men nära (Stewens 1997). 2.1..3 Congestion avoidance & control När klienten skickar sin första ACK i uppstarten meddelar denna även hur mycket data (i bytes) som kan tas emot (advertised window) samt en gräns för när slow start ska sluta och algoritmen för congestion control ska sättas in. Den här gränsen kallas slow start threshhold size (ssthresh) (Stewens, 1997). I och med advertised window vet servern hur mycket data som kan skickas utan att behöva vänta på en ACK. Den här bufferten avläses varje gång ett paket tas emot och i ACK:en som svarar för det paketet meddelas den nuvarande buffertstorleken. Detta förhindrar att servern skickar mer data än vad klienten kan ta emot. 5

För att minimera antalet borttappade paket och minska köbildning anammar TCP en congestion avoidance algoritm; Additive Increase/Multiplicative Decrease (AIMD). Detta innebär att så länge ACK:ar kommer fram som de ska så växer congestion window linjärt och blir större. När man stöter på någon form av paketförlust så minskar congestion window till hälften av vad den var när förlusten inträffade (Hayder mfl 2008). På så sätt minskar man drastiskt trafiken över routern där förlusten uppstod. Beroende på om om halveringen minskar congestion window under ssthresh eller inte kommer antingen slow start algoritmen eller AIMD sättas i bruk. 2.1..4 Fast Retransmit Då datorer har blivit allt kraftfullare och bandbredden har ökat markant sedan TCP skrevs har både advertised window och congestion window blivit allt större. Detta har fört med sig att man idag har många fler paket i omlopp. För att undvika onödig väntan på att en ACK implementerade man i början på 90-talet en algoritm för att motverka detta. Om ett paket försvinner på vägen och efterföljande paket når fram kommer klienten att svara på det paketet med en kopia av den ACK som senast skickades. När servern får två (ibland tre) likadana ACK:ar i rad reagerar den som om en paketförlust uppstått och halverar congestion window (Stewens, 1997). 2.2 Optimering av TCP Här ska vi se till vilka inställningar som finns att göra i TCP/IP för att optimera sin nedladdning. Windows Vista och Windows 7 har möjligheten att ignorera alla ändringar man gör om man inte aktivt stänger av det. Alla kommandon måste göras i command-promten i administratör läge. För att stänga av Windows override används kommandot: netsh int tcp set heuristics diabled 2.2..1 Advertised Window Advertised Window är en av de viktigaste parametrarna när man vill förbättra sin TCP/IP anslutning. Det man vill åstadkomma är att skapa en jämn ström mellan noderna. Med ett för litet fönster (buffert) kommer sändaren vänta onödigt länge innan nästa paket skickas, däremot med ett för stort fönster riskerar man att förlora paket pga trafikstockningar på vägen. I tidigare Windows OS (före XP) så hade man ett statiskt Advertised Window medan de senare versionerna har en dynamisk tillskrivning av bufferten, där den växer och krymper efter behov. Här fokuserar vi på de nyare versionerna och vad de olika inställningarna gör. Kommandot: netsh int tcp set global autotuninglevel= följt av: disabled stänger av den automatiska fluktuationen och använder ett fast värde, max 64 KB highlyrestricted låter fönstret växa men väldigt konservativt restricted låter fönstret växa men fortfarande relativt konservativt normal default inställningen, detta passar de allra flesta experimental tillåter fönstret att växa till extrema storlekar över 16 MB De allra flesta tjänar mest på att ställa in sitt Advertised Window till normal, men om man sitter bakom en brandvägg eller en NAT-router kan man få problem då de inte klarar av en snabbt ökande trafik och därmed förlora en stor mängd paket. Då kan restricted eller highlyrestricted vara att föredra och ge en bättre prestanda då det blir en jämnare ström. Även då man sitter på långlivade uppkopplingar riskerar TCP fönstret att bli väldigt stort och då kan en mer konservativ inställning 6

vara att föredra. För den som till största del använder sig av peer-to-peer nätverk för att hämta hem filer (exempelvis BitTorrent klienter som utorrent eller Vuze) kan få en ökad prestanda av att stänga av autotuninglevel helt (Jacobson mfl). 2.2..2 Congestion control Slow start algoritmen är framtagen då internetuppkopplingarna bestod av 56.6k modem och då fyllde den sin funktion. Idag när vi har 100 MB uppkopplingar och betydligt större buffertstorlekar så ökar inte slow start algoritmen TCP-fönstret så fort som dagens utrustning klarar av och därmed inte utnyttjar bredbandets fulla potential (Stevens 1997). I Windows Vista och nyare OS har en förbättrad congestion control algoritm implementerats, Compound TCP (CTCP), denna är dock inte aktiv per default. Den adresserar visserligen inte uppstarten men när man träffar på en kö i trafiken så istället för att halvera fönstret som slow-start gör har CTCP en mer dynamisk approach. CTCP algoritmen utnyttjar slow start (Congestion Window, cwnd) men tillför även en delay-baserad del (Delay Window, dwnd) så att TCP fönstret ökar till den minsta av: 1. Summan av cwnd+dwnd 2. Max av vad mottagaren kan ta emot Delay Window algoritmen sätts från början till noll och känner av hur fort ACKarna kommer tillbaka och ökar eller minskar dwnd efter behov. På så sätt erhålls ett större genomsnittligt TCP fönster och därmed en högre throughput. CTCP aktiveras genom kommandot: netsh int tcp set global congestionprovider=ctcp Det finns fler congestion control algoritmer som är mer aggressiva än CTCP men de missbrukar ofta den rättvisa (TCP-fairness) man försöker upprätthålla på nätet genom att inte minska ner fönstret mycket nog (om än alls) när en kö uppstår. 2.2..3 Explicit Congestion Notification Vanligtvis så indikerar TCP/IP nätverk köer genom att tappa paket, det ECN (Explicit Congestion Notification, RFC 3168) gör är att routrar som använder detta system kan indikera en kö genom att markera detta i IP-headern. När paketet når fram så reagerar mottagaren som om ett paket har tappats och minskar ner sitt TCP-fönster (Ramakrishnan, K. 2001). ECN gör sig bäst då man har kortlivade anslutningar såsom HTTP-requests och då med routrar som stöder det. Om man oftast laddar ner större mängder data och har långlivade TCP-kopplingar så är det att föredra att ha ECN avslaget. Än så länge är det här systemet inte så spritt vilket gör att man kan stöta på oönskade resultat även vid vanlig surf på nätet. I Windows Vista och nyare OS så är ECN avslaget per default, för att slå på den så används kommandot: netsh int tcp set global ecncapability=enabled 7

3 Server-Client I en client-server struktur har man en centraliserad källa med data som flera olika klienter kan skicka requests till och därmed hämta data, detta sker via TCP-kopplingar. Fördelar med client-server är att det är lätt att kontrollera vem som får tillgång till servrarna och då datan är samlad på en eller ett fåtal servrar så är den lätt att uppdatera och underhålla. Dessa attribut gör att det passar sig bra för företag som säljer sina produkter online och lagringsplats. Dock skapar detta en enkelriktad trafik som ställer höga krav på server-sidan i fråga om bandbredd och tillgänglighet. 3.1 Parallell TCP Ett problem som server-client står inför är köbildningar, då man förlitar sig på en enda uppkoppling blir denna extremt beroende av dess throughput. Skapar vi istället fler (n-antal)tcp-anslutningar till källan minskar vi betydelsen av en köbildning. En enkel kalkyl på hur skillnaden blir med en 10 Mbs uppkoppling som lider av 50 %-igt bortfall: 10 Mbs * 50 % = 5 Mbs bortfall En TCP-uppkoppling 10 / 5 * 50 % = 1 Mbs bortfall 5 uppkopplingar varav 1 med 50% bortfall Man kommer även få en jämnare ström av data, vanligtvis vid paketförlust minskas TCP-fönstret till hälften. Med ännu fler mindre fönster blir minskningen bara en bråkdel av detta (Dunigan, 2005). 3.1..1 Problematik En bieffekt av parallell TCP är att de flesta routrarna hanterar alla paket lika oavsett vart de kommer ifrån och därmed kommer vi få en större del av kakan och bättre throughput än andra som trafikeras genom samma router vilket strider mot TCP-fairness. Det största problemet är dock att om alla skulle tillämpa detta skulle det bli för mycket trafik över nätet och vissa routrar skulle överbelastas och därmed motverka sitt syfte (Hacker mfl, 2004). 4 Peer-to-peer Peer-to-peer(P2P) arkitekturen är ett abstrakt nätverk som implementeras i applikations lagret. Det finns två typer av P2P strukturer i det första typen så finns all information om vem som har vilka filer lagrade på en central server, vilket resulterar i någon for av hybrid mellan P2P struktur och server-client struktur. Detta resulterar till att det är mycket lätt att söka på den servern efter de filer man vill ha och sedan ansluta till de andra användare som har den filen och lada hem den själv. Men då mycket av de filer som cirkulerade i sådana nätverk var upphovsrätts skyddad. Så blev den centrala punkten med all information om vem som hade vad en mycket känslig punkt ur lagliga perspektiv och den typen av P2P struktur dog ut. Det finns även en struktur som inte har en central punkt som håller koll på vart alla olika filer, men det kan finnas servrar som hjälper till med anslutningen mellan två olika peer:s. (Wikipedia peer-to-peer, 2011) 8

4.1 BitTorrent BitTorrent är ett ganska nytt protokoll som kom i sin första implementation den 2 juli 2001, och är framtaget av programeraren Bram Cohen. Vars idé var att man kan bryta ner en större fil i mindre bitar för att sedan kunna ansluta till ett P2P nätverk och hämta hem de olika bitarna från olika användare. För att då slippa använda en TCP-anslutning för hela filen så kan man använda ett mycket större antal för att då kunna öka hastigheten.(james F. Kurose & Keith W. Ross. 2010) Det BitTorrent protokollet gör är att det bryter ner filen i minder bitar vanligen 256 kb. Så när man sedan öppnar sin BitTorrent klient så kommer den att söka på Internet, med hjälp av så kallade trackers, efter andra användare som har de olika delarna av filen som man letar efter. BitTorrent klienten kommer att försöka ansluta till de andra användarna som har bäst anslutning till internet. När man har skapat en anslutning så kommer sin klient att börja fråga efter de segment som är ovanligast först. Detta för att göra segmentet mindre ovanligt men även för att förhindra att ett visst segment inte går att få tag på då alla användare som har det segmentet har stängt ner sina klienter. (James F. Kurose & Keith W. Ross. 2010) En nödvändighet för att BitTorrent-klienten ska kunna fungera är att man har så kallade.torrent filer. En.torrent fil är den filen som innehåller information så som trackerns URL, hur långa alla bitar är, vilka bitar som finns och i vilken ordning man ska sätta ihop dem igen och den totala längden bland annat. Denna fil är nödvändig både för att kunna sätta upp TCP-kopplingar till andra användare men även för att kunna kontrollera så att det inte har blivit några fel på filen på vägen mellan de olika användarna och kunna sätta ihop filen igen.(wikipedia torrent file, 2011) Då det i BitTorrent protokollet finns för definierat på vilka portar som man ska försöka skapa anslutningarna på. Så är det möjligt för internet leverantören att övervaka dessa portar och prioritera den trafiken lägre än trafik som trafikerar andra portar. Dessa portar som finns definierade i BitTorrent protokollet är 6881 och om den används till annat så kommer den att prova port 6882 också vidare tills den har provat 6889(Bram Cohen, 2008). Detta för att BitTorrent försöker skapa nya TCP-anslutningar och försöker hålla de som redan är öppnade vid liv. Men detta kan skapa en obalans mellan de olika användarnas antal TCP-anslutningar. Då TCP jobbar för att fördela trafiken lika mellan de olika anslutningarna så blir det lätt orättvist om vi som använder BitTorrent har flera gånger så många TCP-anslutningar öppna samtidigt och då roffa åt oss en större del av bandbredden. Så för att motverka detta så kan internet leverantören kolla av de anslutningar som går igenom deras routrar och ställa trafiken som använder de klassiska BitTorrent portarna i en separat lägre prioriterad kö.(erik Carlborg, m.fl, 2006) Då det i IP huvudet finns information om vilket protokoll som används i applikations lagret så är det även möjligt för internet leverantörerna att läsa av i IP huvudet och sedan se om det är ett paket som använder sig av BitTorrent och även då ställa det paketet i en lägre prioriterad kö. För att motverka detta så har man försökt att implementera kryptering av den informationen som talar om att det är ett paket som använder sig av BitTorrent. Men detta stöds ännu ej av alla de olika BitTorent-kilenterna som finns ute på marknaden i dag. (Erik Carlborg, m.fl, 2006) 9

5 Diskussion och slutsatser I rapporten kommer vi fram till att Windows TCP-inställningar inte alltid är konfigurerade för personlig bästa nedladdning utan för att internet som stort ska fungera så bra som möjligt. Genom att själv modifiera bland annat RWIN så kan man ibland få en snabbare filnedladdning. Dock beror det på hur resten av hemnätverket ser ut och en ändring kan lika gärna motverka den önskade effekten. Om man inte upplever några problem bör man lämna inställningarna som de är då de nyare operations systemen använder sig av bra dynamiska algoritmer som är optimerade för ett rättvist och bra fungerande internet för alla. 5.1 BitTorrent För att öka sin nedladdnings hastighet om man användersig av en BitTorrent klient så ska man tänka på att man inte tar bort några.torrent filerna när man har laddat hem filen till sin dator då detta kommer att resultera att inga andra andvändare kommer att kunna ladda hem den filen ifrån ens egna klient. Om man gör så på alla.torrent filer så kommer man att bara ladda upp till andra användare som tar hem samma filer som man själv håller på att ta hem just då. Detta kommer då troligt vis att minska den mängd data som man själv laddar upp och om man inte har spesielt hör uppladnings hastig het så kommer de andra användarna att prioritera att ladda upp till dem som har en bättre uppladdnings hastighet. Då TCP jobbar för att alla anslutningar ska få lika mycket sänd kapacitet genom de olika routrarna och BitTorrent använder sig väldigt många parallella anslutningar, så kommer en användare som har nio av tio anslutningar som passerar en vis router att få 90 % av den routerns kapacitet medans den andra användaren bara kommer att få 10 % vilket inte är speciellt rättvist. Så därför så gör vissa internet leverantörer så att de försöker undersöka användarnas sickade packet för att se vilka som innehåller data som sickas med BitTorrent protokollet. Om internet leverantören upptäcker sådan trafik så kan de ställa de paketen i en speciell kö som har lägre prioritet. Det finns generellt två sätt som internet leverantören kan upptäcka om det är BitTorrent trafik som kommer till deras router och det ena är att kolla efter vilken port som paketet är adresserat till och om det är något av de klassiska BitTorrent portarna så ställs de i den lägre prioriterade kön. Med detta i åtanke så kan man gå in i inställningarna för sin BitTorrent klient och ändra vilka portar som den ska använda sig av för att leta reda på nya uppkopplingar. Det andra sättet som internet leverantörerna kan se om det är BitTorrent trafik är genom att kolla i IP huvudet där det finns specificerat till vilket protokoll som kan använda det här paketets data. Om då internet leverantören ser att det är Bittorrent trafik genom avläsning i IP huvudet så kan de också ställa paketet i en läger prioriterad kö. Men det finns flera olika Bittorrent klienter som stödjer kryptering då främst av delar i IP huvudet exempel på sådana klienter är utorrent och Azureus. Men det är inte aktiverat i grund inställningarna utan man måste manuellt gå in i inställningarna och ändra om så att ens egen klient använder sig av kryptering. Det finns lite olika alternativ som man kan ha inställt och de olika alternativen är: Inaktiverat betyder att sin klient inte försöker använda sig av kryptering Aktiverat betyder att klienten försöker använda sig av kryptering men om mottagaren inte accepterar krypterade meddelande så kommer klienten inte att kryptera. Tvingat betyder samma som aktiverat med undantaget att om mottagaren inte accepterar krypterade meddelande så kommer man försöka ansluta till någon annan istället. 10

Det sistnämnda är inte att rekommendera då det finns flera klienter som inte kan hantera krypterade meddelanden och på så vis blir helt omöjliga att koppla upp sig emot och man eliminerar då möjliga användare som man kanske annars hade kunnat ladda ner ifrån. I de flesta klienterna så finns det färdiga inställningar som man kan använda beroende på vad man har för uppkoppling och de är mycket bra framtagna så det kan vara en bra början att göra ett par mätningar mot en mätserver för att få reda på hur snabbt man egentligen har för uppladdnings och nedladdnings hastigheter för att se vilka för inställningar som passar just en själv. Då det är bra att ha sådana inställningar så klienten begränsar max uppladdning och max nedladdning för att om man låter de gå upp till sitt max så finns det risk för att det kommer ta utrymme i routern och på så vis hindra den andra vägen av data flöde. Vilket resulterar i att man får väldigt opålitliga TCP anslutningar då man i en stund laddar upp en massa och de andra klienterna som man är ansluten till kommer då oka på sin trafik till en, men då så kommer den trafiken att trycka bort den utgående trafiken varpå då de klienterna som man är ansluten till stryper sina anslutningar. Lämpliga max mängder brukar säjas vara 70 % av sin maximala uppladdnings kapacitet och 95 % av sin maximala nedladdnings kapacitet. 11

Referenser Tryckt (1981). Transmission Control Protocol: DARPA internet Program Protocol Specification. Request for Comments: 793. Allman (1999) TCP Congestion Control. Request for Comments: 2581. Hacker, T.J.; Noble, B.D.; Athey, B.D. (2004). Improving throughput and maintaining fairness using parallel TCP. Center for Adv. Comput., Michigan Univ., Ann Arbor, MI, USA. ISBN: 0-7803-8355-9 Hayder Natiq Jasem, Zuriati Ahmad Zukarnain, Mohamed Othman, Shamala Subramaniam (2008) The TCP-Based New AIMD Congestion Control Algorithm. IJCSNS International Journal of Computer Science and Network Security, VOL.8 No.10. Jacobson, V.; Braden, R.; Borman, D. (1992). TCP Extensions for High Performance. Request for Comments: 1323. Kurose & Ross (2010). Computer networking: a top-down approach. Pearson, ISBN: 9780131365483 Ramakrishnan, K. (2001). The Addition of Explicit Congestion Notification (ECN) to IP. Request for Comments: 3168. Stewens. W. (1997). TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms. Request for Comments: 2001. Digitalt Erik Carlborg Fröberg, André Eriksson, Polly Yeung. 2006. BitTorrent och traffic shaping. [Elektronisk] Kungliga tekniska högskolan, Tillgänglig: <http://www.ict.kth.se/courses/ik1550/sample-papers/2g1305- BitTorrent_av_Andre_Erik_and_Polly-BitTorrent-revised-20061026.pdf>(2011-02-23) Bram Cohen. 2008. The BitTorrent protocol specification. [Elektronisk] BitTorrent.org, Tillgänglig: <http://www.bittorrent.org/beps/bep_0003.html#to-start-downloading-a-user-does-thefollowing>.(2011-02-20) Dunigan, Tom. (senast uppdaterad 2005-11-03) Parallel TCP. Tillgänglig: <http://www.csm.ornl.gov/~dunigan/netperf/parallel.html> (2011-02-17) The Cable Guy: TCP Receive Window Auto-Tuning (2009). [Elektronisk] TechNet Magazine, januari. Tillgänglig: <http://technet.microsoft.com/sv-se/magazine/2007.01.cableguy(en-us).aspx> (2011-02-18). Wikipedia (senast uppdaterad 2011-02-14). ARPANET. Tillgänglig: <http://en.wikipedia.org/wiki/arpanet> (2011-02-19). Wikipedia (senast uppdaterad 2010-12-31). Leonard Kleinrock. Tillgänglig: <http://en.wikipedia.org/wiki/leonard_kleinrock> (2011-02-19). Wikipedia (senast uppdaterad 2011-02-05). Slow-start. Tillgänglig: <http://en.wikipedia.org/wiki/slow-start> (2011-02-19). Wikipedia (senast uppdaterad 2011-01-08). TCP tuning. Tillgänglig: <http://en.wikipedia.org/wiki/tcp_tuning> (2011-02-15). Wikipedia (senast uppdaterad 2011-0216). Peer-to-peer. Tillgänglig: <http://en.wikipedia.org/wiki/peer-to-peer>(2011-02-21) Wikipedia (senast uppdaterad 2011-01-30). Torrent file. Tillgänglig: <http://en.wikipedia.org/wiki/torrent_file>(2011-02-22)