Optimala inställningar för MTU vid filöverföring

Transkript

1 Examensarbete i Datavetenskap B-uppsats Optimala inställningar för MTU vid filöverföring En utredning i Linuxmiljö baserad på protokoll och filstorlek Författare: Anton Roskvist Filip Roskvist Handledare: Marcus Wilhelmsson Termin: VT12 Kurskod: 1DV41E

2 Abstrakt Denna uppsats behandlar ämnet filöverföring i ett nätverk. Fokus för arbetet har varit att undersöka MTU:ns inverkan på överföringshastigheten vid filöverföringar baserat på vilket protokoll som används och storleken på filerna som överförs. I arbetet har ett flertal experiment genomförts som syftat till att utreda detta, samt att finna vilket protokoll som överlag presterar bäst baserat på omständigheterna för överföringen. Olika filöverföringsprotokoll, fildistributionsprotokoll, MTU:er samt filstorlekar har testats för att finna vad som resulterar i högst överföringshastighet vid filöverföring över ett Ethernetnätverk. Resultaten visar på att en hög MTU uppnår högst överföringshastighet vid överföring av stora filer, men att en standard- MTU fungerar bättre för att överföra mycket små filer. Nyckelord: MTU, Filöverföring, Filöverföringshastighet, Filöverföringsprotokoll, Fildistributionsprotokoll Abstract This report concerns the subject of file transfer. The focal point of the report is to study the effect that the MTU has on the speed of file transfers based on the protocol used and the size of the transferred files. During the course of the work, several experiments have been performed in order to determine this, as well as to find which protocol gives the overall best result based on the circumstances of the file transfers. Various file transfer protocols, file distribution protocols, MTUs and file sizes have been tested in order to find what results in the best file transfer speed over an Ethernet based network. The results show that a high MTU has the best performance when transferring large files, while a standard MTU gives better results for transferring very small files. Keywords: MTU, File transfer, File transfer speed, File transfer protocol, File distribution protocol I

3 Innehåll 1. Introduktion Problembeskrivning Målgrupp Avgränsningar 2 2. Teoretisk Bakgrund MTU TCP Filöverföringsprotokoll Fildistributionsprotokoll RAMdisk Ubuntu Wireshark 5 3. Metod Laborationsmiljö Mjukvara Genomförande Metoddiskussion Resultat Nätverkstest med netperf Filöverföring med stora filer Filöverföring med små filer Diskussion Slutsats Fortsatt forskning Referenser Bilaga 22 II

4 1. Introduktion Det här är ett arbete som syftat till att undersöka hur förändring av MTU:n kan förbättra eller försämra hastighet vid filöverföring och därigenom möjligen också kunna finna inställningar för att uppnå snabbare överföring av filer i ett nätverk. Detta är intressant, då möjligheten att flytta filer över nätverken på effektiva sätt är av betydelse i såväl små som stora nätverk. I små nätverk, kanske för att distribuera filer mellan ett antal hemanvändare och i stora kanske för att flytta backupdata från hela datorsystemet till en backupserver. Under arbetets gång undersöks MTU:ns inverkan på filöverföringshastigheten tillsammans med flera protokoll för filöverföring för att se hur pass den kan skilja sig från protokoll till protokoll. Såväl rena filöverföringsprotokoll som fildistributionsprotokoll testas under experimentens gång. MTU:ns inverkan undersöks även baserat på storleken av filerna vid överföringen, då test utförs både med stora filer och små filer. Resultatet som förväntas av arbetet är att fastställa vilken MTU som ger bäst resultat beroende på omständigheterna för filöverföringen som genomförs, samt att se vilket protokoll som ger snabbast filöverföring överlag. En tidigare undersökning av överföringshastighet mellan flera fildistributionsprotokoll har genomförts, där det visade sig vara en stor skillnad mellan flertalet av dessa [1]. Studien fokuserade på en Windows-miljö och lämnar utrymme för vidare forskning inom andra plattformar, såsom en Linux-miljö. Effekten av alternering på MTU har också studerats tidigare, i syfte för optimering av trådlös videokommunikation [2]. Medan denna undersökning behandlar MTU:n så rör den inte generell filöverföring. 1.1 Problembeskrivning Målet med arbetet är att genomföra tester med olika inställningar för MTU:n, för att på så vis finna vad för inställningar som ger bäst snabbast resultat vid filöverföringar. Detta ska undersökas med tester baserade på filöverföringsprotokoll och storleken på filer som överförs. Arbetet syftar till att undersöka huruvida olika protokoll fungerar bättre med olika inställningar av MTU:n, samt att finna hur förhållandet mellan hastighet och MTU skiftar beroende på om det är stora filer som överförs eller mycket små filer. Små filer i detta sammanhang syftar på filer vars storlek ligger i spannet mellan den största och den minsta MTU:n som testas. För att kunna fastställa detta så ska test utföras i en kontrollerad miljö där flera MTU:er testas mot olika filöverföringsprotokoll i tidtagna filöverföringar. 1

5 Följande frågor ämnas besvaras i arbetet; Hur stor MTU:ns inverkan är för hastigheten av en filöverföring Hur MTU:ns inverkan skiljer sig mellan olika protokoll Huruvida storleken av filerna i överföringen har betydelse för vilken MTU som ger bäst resultat Vilket protokoll som överlag ger bäst resultat vid filöverföring 1.2 Målgrupp Arbetet riktar sig främst till IT-tekniker med kunskap och ansvar för nätverksutrustning, alternativt IT-kunniga hemanvändare, och har förhoppningar om att vara till nytta för just dessa personer. Rapporten kommer då därför inte att förklara de mest grundläggande termerna och koncepten som inte är direkt relaterade till arbetet som genomförs, då det görs ett antagande att läsaren har en viss mån av kunskap i förhand. 1.3 Avgränsningar Alla tester kommer att utföras inom en Linuxbaserad miljö. Att genomföra testerna för samtliga relevanta plattformar skulle göra arbetet allt för omfattande för att kunna slutföras inom tidsramen och Linux är en plattform där samtliga protokoll som ämnas undersökas har stöd, samt är fritt tillgängliga. Vidare så kommer endast TCP-baserade filöverföringsprotokoll att ingå i testerna för att hålla antalet tester nere. TCP valdes framför UDP då det har möjlighet att kontrollera att överförda filer är intakta, alternativt finna om något paket försvann på vägen och vid behov återsända paket efter överföring, något som UDP-protokollet inte kan göra [3]. Detta innebär att TCP är mer tillförlitligt vid ren filöverföring, och därmed är att föredra. Gällande MTU finns det tusentals möjliga storlekar som kan väljas, så för att få detta till en hanterbar storlek så kommer endast ett fåtal tydligt separerade storlekar att användas för att kunna utläsa en trend och göra en analys av detta. Enligt [4] måste alla nätverkskort som vill använda IP, kunna behandla en MTU på minst 576 Byte. En MTU på 600 ansågs därför vara ett rimligt lägsta testvärde. På samma sätt valdes MTU 9000 som högsta testvärde, eftersom att det är det högsta värde som så kallade Jumbo Frames sträcker sig till [5]. En MTU på 4000 användes även för att få ett test på en MTU mellan standardvärdet 1500 och maxvärdet betraktades rent proportionellt som ett lämpligt värde att använda, då steget mellan varje MTU då blir ungefär lika stort procentuellt. 2

6 2. Teoretisk Bakgrund Nedan följer en rad korta beskrivningar av alla olika teknologier, protokoll, applikationer och system som har kommit till användning under experimentets gång. 2.1 MTU För att få sändas ut genom ett interface så måste ett IP-paket vara begränsat till en viss förutbestämd storlek. Detta kallas för MTU, eller Maximum Transmission Unit. Inom Ethernet så sätts detta som standard till 1500 Byte, men kan sättas högre än så [6]. En fördel med en större MTU är att mer data skickas per paket, vilket innebär färre paket och mindre metadata som behövs i form av headers för de olika protokollen som paketet skickas igenom. En nackdel är att det finns medier och enheter som inte stödjer så stor MTU, och vid paketförlust tar det även längre tid att återsända ett paket. I arbetet manipuleras MTU till större och mindre värden än standard för att observera effekten detta har på filöverföringshastighet. 2.2 TCP Transmission Control Protocol är ett förbindelsebaserat transportprotokoll, vars jobb det är att transportera trafik över internet. Att det är förbindelsebaserat innebär att en session initieras innan någon data skickas istället för att bara skicka ut data mot angiven destination utan att försäkra sig om att det finns någon mottagare där. Initieringen sker genom en trevägshandskakning, där klienten skickar ett paket till servern, servern skickar tillbaka en bekräftelse om att det kom fram, och klienten skickar en bekräftelse av att serverns meddelande kom fram. TCP erbjuder pålitligt kommunikation, där ett paket alltid kommer att återsändas om det inte når sitt mål, för att försäkra sig om att ingen dataförlust sker under sändningen [7]. 2.3 Filöverföringsprotokoll Filöverföringsprotokoll är ursprungligen designade med ett mål i åtanke, vilket är att flytta data från en plats till en annan över ett nätverk. Det har sedan protokollens ursprungliga tillverkning tillkommit en hel del extra funktioner i protokollen i sig, så som till exempel autentisering, men protokollens ursprungliga syfte var som sagt att endast flytta data [8] FTP File Transfer Protocol är ett standardiserat nätverksprotokoll, vilket används för att flytta filer från en maskin till en annan över en TCP-session. Detta kan uppnås på såväl LAN som på Internet. Användare kan autentisera sig mot en server, eller om servern tillåter det, ansluta sig anonymt. 3

7 När FTP utvecklades användes uteslutande textbaserade klienter, alltså där man i en terminal eller liknande skickade textkommandon till servern för hand, medan det idag finns väldigt många implementationer av FTP som använder sig av grafiska gränssnitt. Oavsett vilket, så ser det bakomliggande protokollet ut på samma sätt [9] FTPS FTPS, eller FTP Secure är en förlängning av FTP protokollet. Vad som lagts till i FTPS är krypteringsfunktionalitet i form av Transport Layer Security (TLS) och Secure Sockets Layer (SSL). Tillägget av denna funktionalitet medför att man kan kommunicera över osäkra medium på ett säkert sätt, då den trafik som genereras vid en filöverföringssession är oläslig för alla utom avsändaren och mottagaren, vilka har tillgång till dekrypteringsnycklarna [10] SCP Secure Copy är ett nätverksprotokoll som är byggt ovanpå Remote Copy-protokollet (RCP), vilket stöder filöverföringar mellan två maskiner över ett nätverk. SCP, till skillnad från RCP, använder Secure Shell (SSH) för att säkra dataöverföringen, och detta görs helt i enlighet med SSH-standarden. Det innebär att det finns stöd för alla autentiseringsmetoder i SCP som det finns i SSH. En klient kan såväl hämta som ladda upp data till SSH-servern. Liksom för RCP, så finns ingen RFC som definierar SCP. Precis som i fallet med FTPS, så är fördelen med SCP att data-överföringen kan ske över ett osäkert medium utan risk för att någon kan läsa av originaldata [11]. 2.4 Fildistributionsprotokoll Dessa protokoll påminner en del om filöverföringsprotokollen, men har istället som ursprungligt syfte att dela ut eller distribuera filer, vilka användare sedan ska kunna nå över nätverket. Här flyttar man alltså inte en fil från en punkt till en annan som huvudsaklig funktion, utan man gör en volym tillgänglig på nätverket på ett sådant sätt att andra användare sedan kan ansluta mot utdelningen och själva ta del av vad som finns där. Att man sedan kan överföra filerna som finns på utdelningen är den funktion som har legat i fokus för detta experiment. NFS var det första fildistributionsprotokollet, och fildistributionsprotokollens natur avhandlas i [12] CIFS/SMBv1 CIFS är ett distribuerat filsystem som primärt används på Microsoft-plattformar, men även har stöd för plattformar som till exempel Linux-kärnan och OSX. Det används för att dela ut filer och skrivare över nätverk. En CIFS-utdelning behöver inte monteras på en klientdator, utan kan istället kommas åt via globala katalognamn, dock så kan utdelningen fortfarande monteras om det önskas [13]. 4

8 2.4.2 NFSv4 NFSv4, definierat i [14] är ett distribuerat filsystem som används för att dela ut filer över ett nätverk. Som mål har NFS att vara oberoende av transportprotokoll och operativsystem, att vara högpresterande samt att göra filer lättåtkomliga. NFS fungerar enligt en klient/server-modell, där en server skapar en utdelning, vilken sedan kan kommas åt av en klient genom att skapa en lokal montering av utdelningen, som sedan kan behandlas som en vanlig katalog. Detta med restriktioner för rättigheter som är satta genom servern. 2.5 RAMdisk En RAMdisk är essentiellt en del av datorns arbetsminne som man dedikerat till sekundärlagring. För att uttrycka det enkelt, så kan man säg att datorn behandlar en RAMdisk likadant som en hårddisk. Med detta följer ett antal för och nackdelar. Den stora nackdelen med detta är att RAM är flyktigt minne, vilken innebär att allt som lagras där kommer att raderas när maskinen startar om. En annan stor nackdel är att RAM-minne i förhållande till hårddiskar är väldigt dyrt. Vad man vinner på är dock att RAM-minnen är oerhört mycket snabbare än hårddiskar [15]. 2.6 Ubuntu Ubuntu är ett Linuxbaserat operativsystem som bygger på distributionen Debian. Ubuntu saluförs som kostnadsfri Open Source-mjukvara. Operativsystemet är namngivet efter den Sydafrikanska filosofin med samma namn: Ubuntu, vilket ungefär översätts till Medmänsklighet. Ubuntu är huvudsakligen utvecklats som ett operativsystem för hemanvändning, men en serverversion existerar också. Den största skillnaden mellan de båda är att hemversionen kommer levererad med ett grafiskt gränssnitt, vilket serverversionen inte gör. Den är textbaserad [16]. 2.7 Wireshark Wireshark är en gratis, Open Source-baserad paketanalyserare. Dess användningsområden är bland annat felsökning i nätverk, hjälpmedel till utveckling av mjukvara och kommunikationsprotokoll, utbildning och för analys av nätverkstrafik. I detta fallet har Wireshark använts för paketanalys. Programmet fungerar genom att fånga upp alla in och utgående paket som passerar angiven nätverksadapter, vilka sedan formateras och presenteras grafiskt [17]. 3. Metod I arbetet appliceras en kvantitativ metod för att samla in data från testerna som utförs [18]. Varje test genomförs flera gånger och medelvärdet av resultaten är vad som kommer att användas i presentationen av resultaten. Eftersom att testen är beroende 5

9 av flera variabler så används ett förutbestämt system för att testen ska bli identiskt utformade och systematiskt genomförda. Innebörden av detta är att resultaten blir konsekventa och kan jämföras med varandra på ett meningsfullt sätt. Den insamlade data sammanställs och presenteras i diagram för att förtydliga jämförelsen mellan de olika resultaten. 3.1 Laborationsmiljö I testmiljön användes två Dell Poweredge 1850-servrar, som båda kördes med operativsystemet Ubuntu Den ena användes som server och den andra som klient i alla filöverföringar. De båda datorerna kopplades samman med en dedikerad Ethernetlänk på 1Gbit/s. Båda datorerna monterade vars en RAMDisk, vilka användes som start och slutdestination för alla filöverföringar för att undvika flaskhalsar för läs och skrivhastighet. De båda maskinerna styrdes sedan genom SSH från en fjärransluten dator. Denna anslutning gjordes på ett sekundärt nätverkskort på båda servrarna, för att undvika störningar i testerna från utomstående nätverkstrafik. Figur 3.1 Laborationsmiljö 3.2 Mjukvara För att ha en möjlighet att få ett konsekvent och upprepningsbart resultat från experimenten har specifik mjukvara använts, och den har använts till samtliga upprepningar av de olika testen. Som grundsystem har Ubuntu - Precise Pangolin 12.04, med Linux kernel generic använts. Denna mjukvara införskaffades direkt ifrån Ubuntus hemsida 1. Den här mjukvaran är gemensam för både servern och klienten

10 Några av de programm som används fanns redan förinstallerade i systemen, däribland time , vilket används för att mäta tiden det tar för ett kommando att utföras och SCP 1.5.9, som används för att överföra filer med SCP. Som servermjukvara har programmet vsftpd använts för att kunna agera FTP server, vilket valdes då det är en välanvänd FTP server som fyllde de funktionerna som krävdes för testerna. samba och nfs-kernel-server användes för att skapa utdelningar för CIFS respektive NFS, och valdes då de är de enda alternativen för att skapa sådana utdelningar. Till klienten installerades programmen samba-common och nfs-common som motsvarighet till serverprogrammen för CIFS och NFS, för att kunna hantera utdelningarna på klienten. ftp-ssl installerades som klient för att överföra filer med FTP. Denna klient valdes då den kan hantera både FTP och FTPS, samt att den återger tider för överföringar med två decimalers precision, något som var viktigt för precisionen av testresultaten. Vidare så installerades Wireshark 1.6.7, som användes för att fånga upp och inspektera paket från filöverföringar och netperf 2.5.0, vilet är ett verktyg som används för att mäta överföringshastigheten på en länk mellan två nätverksenheter. Wireshark kördes endast på klienten medan netperf behöver vara installerat på både servern och klienten för att fungera. Slutligen så installerades Openssh-server på både servern och klienten, och användes för att kunna fjärransluta till datorerna. Samtlig mjukvara är vald då det är den senaste tillgängliga i Ubuntus repositories, datum 04/ Förutom själva operativsystemet så har all mjukvara som installerats hämtats med apt-get install. 3.3 Genomförande PowerEdge-servrarna kopplades samman enligt figur 3.1 och utrustades med all mjukvara som specificerats i kapitel 3.2 Mjukvara. Både servern och klienten monterade en RAMdisk på 1152MB med filsystemet ext4 på platsen /mnt. På servern skapades två utdelningar av /mnt. En utdelning med NFSv4 och en utdelning med CIFS, som sedan monterades av klienten. NFS monterades i /home/user/nfs, och CIFS monterades i /home/user/cifs. För att förbereda SCP skapades ett certifikat som delades ut mellan datorerna vilket möjliggjorde filöverföring utan autentisering via lösenord. På servern konfigurerades vsftpd att använda /mnt som standardkatalog, och det förberedes med ett certifikat för kryptering som användes vid överföringar med FTPS. Servern konfigurerades med en MTU på 9000 på nätverkskortet där länken mellan servern och klienten var kopplad. Genom att konstant ha serverns MTU satt till 9000 så behövdes denna inte ändras under testerna, utan klientens MTU blev vad som 7

11 begränsade paketen som skickades över länken. Detta testades och bekräftades genom köra tester med netperf. På servern skapades sedan en fil på Byte vid namn big som placerades i /mnt, vilken användes för den första omgången med filöverföringar. För den andra omgången filöverföringar skapades filer på 2500 Byte, samt en extra fil som fyllde ut den totala storleken av filerna till Byte. Anledningen till att det inte skapades tillräckligt många små filer för att utgöra hela storleken var att detta överskred det maximala antalet filer som kunde placeras på RAMdisken. Samtliga filer skapades med verktyget dd. Kommandot som användes för att skapa den stora filen var följande: dd if=/dev/zero of=big bs= count=1000 För att fastställa överföringshastighet på länken mellan datorerna kördes även tester med netperf. Ett test genomfördes med netperf 10 gånger för varje av de aktuella MTU:erna Överföring med en stor fil Klientens MTU sattes till 600 för att starta testerna, varpå överföringar med samtliga av de 5 protokoll som testades genomfördes. Den första överföringen gjordes med NFS, och utfördes med följande kommando: sudo time -f %E -o /log/nfs.big.600.log -a cp /home/user/nfs/big /mnt/big Kommandot initierar en överföring av filen big i /mnt på servern till /mnt på klienten. Tiden för överföringen loggas av time och placeras i en fil vid namn nfs.big.600.log. Syntaxen -f %E för time ser till att endast realtiden för utförandet av kommandot loggas. Kommandot placerades i en loop som upprepades 10 gånger, och raderade filen big mellan varje genomförande. Samma procedur upprepades med CIFS och SCP, där följande kommandon användes för att initiera överföringarna: sudo time -f %E -o /log/cifs.big.600.log -a cp /home/user/cifs/big /mnt/big sudo time -f %E -o /log/scp.big.600.log -a scp -q user@ :/mnt/big big Växeln -q användes för SCP för att protokollet inte ska ge någon egen output under tiden som överföringarna genomförs. Om växeln inte används så skrivs varje filöverföring som påbörjas och avslutas ut. Detta sågs som något som potentiellt 8

12 kunde inverka på tiden för att genomföra kommandot, i synnerhet när ett stort antal små filer överfördes. Överföringarna med FTP genomfördes genom att ansluta till servern med kommandorads-klienten ftp-ssl, varpå filen hämtades med följande kommando: get big /mnt/big När överföringen slutförts så anger klienten den tid det tog att överföra filen med två decimalers precision. Detta värde skrevs ner manuellt till en logfil för FTP. Filen raderades sedan och överföringen upprepades sedan tills den genomförts 10 gånger. Innan överföringarna med FTPS startades så konfigureras vsftpd på servern om till att tillåta SSL-kryptering, varpå tjänsten startades om. För att bekräfta att data som skickades med FTP nu krypterades gjordes nu en testöverföring som fångades upp och inspekterades med Wireshark. Efter att ha bekräftat att trafiken krypterades upprepades samma procedur som genomfördes med vanlig FTP. Efter att alla protokoll testats med en MTU på 600 så ändrades den till 1500, sedan 4000 och till sist Varje gång en ny MTU sattes så genomfördes och loggades 10 överföringar per protokoll innan den ändrades igen Överföring med små filer På servern raderades filen big från /mnt, och de andra filerna som tidigare skapades lades nu in i en mapp i /mnt, vilken döptes till smallfiles. MTU:n på klienten sattes tillbaka till 600 och sedan började nya överföringar genomföras. Överföringarna med NFS, CIFS och SCP genomfördes på samma vis som vid överföringen av en stor fil, med enda skillnad att växeln -r var tvungen att användas då det är kataloger som överförs denna gång. Överföringarna initierades med följande kommandon: sudo time -f %E -o /log/nfs.small.600.log -a cp -r /home/user/nfs/smallfiles smallfiles sudo time -f %E -o /log/cifs.small.600.log -a cp -r /home/user/cifs/smallfiles smallfiles sudo time -f %E -o /log/scp.small.600.log -a scp -q -r user@ :/mnt/smallfiles Varje överföring genomfördes åter igen 10 gånger. För att mäta överföringstiderna med FTP var överföringarna tvungna att skriptas, varpå time-kommandot applicerades för att mäta tiden det tog att genomföra hela skriptet. Detta var nödvändigt eftersom att FTP-klienten endast anger tiden för varje överförd fil, och inte tiden det tar att genomföra hela överföringen sammanlagt. Följande skript skapades för att initiera överföringen: 9

13 ftp-ssl -n <<END_SCRIPT quote USER anonymous quote PASS anonymous prompt mget files/ /mnt/files/ quit END_SCRIPT Kommandot prompt behöver anges för att FTP-klienten inte ska fråga för att starta varje ny filöverföring, och mget används för att flytta en hel katalog istället för en enskild fil. För att sedan köra och ta tiden för skriptet användes följande kommando: sudo time -f %E -o /log/ftp.small.600.log -a./script Samma procedur upprepades med FTPS efter att ha slagit igång SSL i vsftpd. Därefter ökades MTU:n för klienten, och alla protokoll testades sedan på nytt Insamling av sekundär data För att få en översikt av beteendet hos överföringarna gjordes insamlingar med Wireshark av skickad data för varje protokoll med var och en av de testade MTU:erna. Det gjordes två överföringar per protokoll och MTU, en med en stor fil och en med många små filer. För att hålla storleken av insamlingarna i Wireshark nere minskades storleken av överföringarna till 1MB, det vill säga 1 fil på 1MB eller 400 filer på 2.5KB. Det genomfördes även ett test för varje protokoll där processoranvändningen monitorerades med verktyget top på både klient och server, för att kunna avgöra om vissa resultat påverkades av hårdvaran. 3.4 Metoddiskussion För att eliminera så många felkällor som möjligt användes en klinisk miljö där inga utomstående källor kunde orsaka störningar. Alla överföringar genomfördes på en länk som var kopplad direkt mellan de två datorerna, och RAMdiskar användes för att se till att överföringarna inte begränsades av läs/skriv-hastighet. För att säkerställa att ingen onödig trafik gick över länken mellan servrarna gjordes en uppfångst med Wireshark under flera minuter, där det noterades att endast enstaka paket från de distribuerade filsystemen passerade över länken när inga överföringar var på gång. Testen med netperf visade även att hastigheten på länken mellan maskinerna var som förväntad. De begränsningar som kvarstår borde endast vara hastigheten på länken mellan datorerna, och hårdvaran i maskinerna, där processorn skulle kunna bli en flaskhals vid krypterade överföringar. Eftersom att det inte fanns någon annan hårdvara att tillgå var det dock inte möjligt att göra något åt detta. Genom att medelvärdet av 10 10

14 genomförda test är vad som beräknas och presenteras så minskas även åverkan av slumpmässig variation i resultaten. En fördel med denna typ av miljö är jämnare och pålitligare testresultat. En nackdel är dock att det inte tar i åtanke hur olika miljöer kan påverka filöverföringshastigheten för olika protokoll, och om dessa protokoll skalas olika bra för större miljöer med mer störningar. Testerna ämnar dock jämföra protokollens rena prestanda gällande överföringshastighet, vilket är varför en mer omfattande miljö valdes bort. Det diskuterades huruvida något program specifikt tillämpat för prestandatest skulle användas. Detta gjordes dock inte då något program som passade testen som genomfördes inte hittades, samt att fokus lades på att ha så få extra program körandes som kunde dra prestanda. Det var från början tänkt att även AFP skulle testas, som ett tredje fildistributionsprotokoll, men klientsidan för detta protokoll hade inget bra stöd i Linux, och gick helt enkelt inte att få fungerande, varför det fick väljas bort. RCP var även tänkt att testas, som en okrypterad version av SCP, men eftersom att SCP har tagit över RCP i den grad att kommandot RCP helt enkelt översätts till SCP i Ubuntu valdes även det bort 11

15 4. Resultat Resultaten av testerna som genomförts följer nedan. Värdena som presenteras är genomsnittet av 10 genomförda tester. 4.1 Nätverkstest med netperf De första resultaten som presenteras är från testen med netperf. Dessa tester genomfördes med samtliga av de aktuella MTU:erna för att få en bild över hur snabb ren TCP-överföring var över länken mellan datorerna baserat på MTU. Netperf , ,35 MTU ,64 989, Mbit/s Figur 4.1 Nätverkstest med netperf Figur 4.1 visar att hastigheten över länken växer stadigt tillsammans med MTU:n, men att vinsten i förbättringen av överföringshastigheten blir mindre mellan de större MTU:erna. Mellan 600 och 1500 är det en skillnad på 82 Mbit/s, vilket är en ökning på ungefär 10% i fördel för den större MTU:n. Mellan 4000 och 9000 är skillnaden endast 12 Mbit/s, vilket ger en ökning på knappt 1.3%. Vid en MTU på 9000 är hastigheten relativt nära den teoretiska kapaciteten på länken, 1Gbit/s. 12

16 4.2 Filöverföring med stora filer Nästföljande resultat som presenteras är för testerna som genomfördes med en filöverföring av en fil på Byte. NFS - Stor fil 600 9, ,57 MTU ,26 8,14 7 7,5 8 8,5 9 9,5 10 Överföringstid i sekunder Figur 4.2 Överföring av stor fil med NFS Figur 4.2 visar att överföringen med NFS blev gradvis snabbare vid ökande av MTU. Överföringstiden minskade med ungefär 10% mellan 600 och 1500, och 1.5% mellan 4000 och 9000, vilket är mycket nära den förbättring som visade sig vid testet med netperf. Cifs - Stor fil , ,69 MTU ,29 9,25 8,5 9 9, ,5 11 Överföringstid i sekunder Figur 4.3 Överföring av stor fil med CIFS Enligt figur 4.3 så var CIFS överlag strax över 1 sekund långsammare än NFS i samtliga jämförelser, och den totala förbättringen från MTU 600 till 9000 var även något mindre, 12% jämfört med 14.5%. Mönstret av förbättring vid ökning av MTU liknar dock fortfarande de tidigare testerna. 13

17 Scp - Stor fil , ,45 MTU ,72 23, , , , , ,5 27 Överföringstid i sekunder Figur 4.4 Överföring av stor fil med SCP Överföringarna med SCP tar som förväntat betydligt längre tid eftersom att dessa krypteras. Vad som kan utläsas av Figur 4.4 är att förbättringen vid ökning av MTU är något mindre än med tidiga protokoll, då den totalt förbättringen endast är ungefär 10.5%. Rent proportionerligt är dock förbättringarna likvärdigt fördelade som med tidigare protokoll. FTP - Stor fil ,85 MTU ,5 8,19 8, Överföringstid i sekunder Figur 4.5 Överföring av stor fil med FTP Figur 4.5 visar att FTP ligger väldigt nära resultaten för NFS när MTU:n är 1500 och över, då det är strax under 0.1 sekunder snabbare överlag. En förbättring på ungefär 22% äger rum mellan MTU 600 och 1500, jämfört med mellan 7-10% för tidigare protokoll, medan skillnaderna mellan 1500 och uppåt är liknande tidigare protokoll. 14

18 FTPS - Stor fil , ,45 MTU , ,49 15,1 15,2 15,3 15,4 15,5 15,6 15,7 15,8 15,9 Överföringstid i sekunder Figur 4.6 Överföring av stor fil med FTPS FTPS är det enda protokollet vars överföringstid inte blev bäst med en MTU på Skillnaden överlag är även mycket mindre än med andra protokoll, endast 3% mellan bästa och sämsta resultat. En mätning av processoranvändningen under en överföring med FTPS genomfördes, och visade att den låg på 100%. FTPS var det enda protokoll som vid fick processoranvändningen att nå upp till 100%. 4.2 Filöverföring med små filer Följande resultat är från de överföringar som genomfördes med små filer. Överföringarna bestod av filer på 2500 Byte samt en större fil som fyllde ut den totala storleken på överföringarna till Byte. NFS - Små filer ,16 50,43 MTU ,95 70, Överföringstid i sekunder Figur 4.7 Överföring av små filer med NFS Till skillnad från testerna med en stor fil uppnåddes inte snabbast resultat med en stor MTU. Figur 4.7 visar att tiden för överföringen ökar med över 40% när MTU:n överstiger Data som fångades upp med Wireshark visar att en större MTU inte gör någon nytta under överföringarna, eftersom att storleken på paketen som kan skickas begränsas av filstorleken. Med en större MTU tog det enligt Wireshark även längre tid mellan varje skickat paket, även om paketen hade samma storlek 15

19 Cifs - Små filer ,76 43,14 MTU ,12 63, Överföringstid i sekunder Figur 4.8 Överföring av små filer med CIFS Överföringstiderna för CIFS följer samma mönster som med NFS, där överföringstiden blir betydligt långsammare när MTU:n blir större än filen som skickas. Vad som dock kan noteras är att överföringarna är ungefär 7-8 sekunder snabbare överlag, även fast CIFS visade sämre resultat än NFS vid överföringarna med en stor fil. I det data som fångades upp av Wireshark visade det sig även att färre paket behöver skickas för att starta och stänga varje separat filöverföring jämfört med NFS. Scp - Små filer ,67 47,96 MTU ,62 60, Överföringstid i sekunder Figur 4.9 Överföring av små filer med SCP Figur 4.9 visar att SCP presterar nära de tidigare protokollen, vilket är intressant då det tog över dubbelt så lång tid vid överföringar med en stor fil. Skillnaden mellan de små och de stora MTU:erna är även betydligt mindre, ungefär 26% jämfört med över 40% för CIFS och NFS. Det visade sig även i Wireshark att SCP skickade ännu färre paket mellan varje filöverföring jämfört med NFS och CIFS. 16

20 FTP - Små filer , ,01 MTU ,15 68, Överföringstid i sekunder Figur 4.10 Överföring av små filer med FTP Till skillnad från de tidigare protokollen så får FTP bäst resultat med en större MTU även vid överföring av små filer, med en ökning på strax under 5% från 1500 till Uppsamlingen med Wireshark visar att tiden mellan varje enskild överföring till synes inte ökar med en högre MTU, vilket har varit fallet för tidigare protokoll. Därför uppstår inte den förminskning av överföringshastighet som uppenbarar sig vid stora MTU:er för övriga protokoll. FTPS - Små filer , ,48 MTU , , Överföringstid i sekunder Figur 4.11 Överföring av små filer med FTPS Figur 4.11 visar att överföringarna av små filer med FTPS var många gånger långsammare än med något annat protokoll. Skillnaden mellan bästa och sämsta resultat är också mycket liten, och ligger på ungefär 0.2%. De 10 individuella resultaten för varje MTU visar att samtliga MTU:er har givit resultat som både ligger flera sekunder över 28 minuter, och flera sekunder under, vilket innebär att ingen MTU presterar tydligt bättre eller sämre än någon annan i detta fallet. 17

21 5. Diskussion Resultaten för de genomförda testen visar överlag en tydlig ökning av överföringshastigheten vid användandet av en större MTU för överföringar av stora filer. Förbättringen från en MTU på 1500 och en på 9000 låg ungefär runt 4-5%, vilket är en betydande skillnad vid långa överföringar. En MTU på 600 visade sig överlag vara betydligt långsammare än 1500, mellan 7-10% för NFS, CIFS och SCP. FTP upplevde en ännu större försämring när MTU:n sattes ned till 600, då resultaten blev nära på 22% långsammare. En specifik anledning till detta är svår att fastslå, då en jämförelse i Wireshark mellan överföringar i FTP inte visar på att något oväntat sker vid överföringen med MTU 600. Paketen för FTP-data verkar helt enkelt inte fungera särskilt bra med en mycket liten MTU. FTPS hade mycket mindre avvikelse på resultaten jämfört med övriga protokoll, vilket förklaras av att det begränsades av hårdvaran i datorerna som användes för testerna, då 100% av processorkraften användes under överföringarna. Skillnaden på överföringshastigheterna för MTU är under 1%, och det är därför inte direkt möjligt att nämna en MTU som bättre än en annan, då små variationer baserat på slump kan utgöra i princip hela skillnaden. Sammantaget för överföringarna med en stor fil gav FTP och NFS med max-mtu klart bäst resultat, då de var över 10% snabbare än CIFS. Av de två protokollen som krypterades presterade FTPS betydligt bättre än SCP, vilket dock kan vara beroende av hårdvara. Vid testen som genomfördes med små filer visade det sig att standard-mtu:n på 1500 genererade bäst resultat överlag, och användandet av större MTU:er gav markant sämre resultat. NFS, SCP och CIFS upplevde samtliga en stor ökning i överföringstiden när MTU:n sattes högre än Detta orsakades sannolikt då storleken på filerna som skickades gjorde så att en större MTU inte kunde utnyttjas till fullo, och att en större MTU orsakade en större tid mellan varje skickat paket, även när paketen hade samma storlek. FTP tjänade på att använda en större MTU även i detta fall, men presterade i det hela sämre än SCP, NFS och CIFS i dessa tester. En anledning till varför FTP inte fick sämre resultat med en större MTU i detta fall likt de andra protokollen är svår att fastslå. Eftersom att FTP inte upplevde samma ökade fördröjning mellan varje paket vid en högre MTU som uppstod med NFS, CIFS och SCP är det dock klart varför den inte får lägre överföringshastighet. En större MTU:n hjälper även vid flytten av den större utfyllnadsfilen. Att FTP ändå presterade sämre än NFS, CIFS och SCP berodde antagligen på att ett betydligt större antal paket skickades mellan varje enskilt filöverföring jämfört med dessa protokoll. 18

22 FTPS presterade inte alls bra vid dessa tester, då det tog hela 35 gånger längre tid att genomföra överföringen jämfört med SCP som också krypterade sin trafik. Överlag för överföringarna med små filer presterade CIFS bäst, följt av SCP som var snabbare än NFS trots kryptering. Samtliga av dessa protokoll fick bäst resultat med en standard-mtu. Tidigt under arbetets gång fanns det tankar om att göra en betydligt djupare analys av hur nätverkstrafiken påverkas av MTU:n, vilket potentiellt är något som skulle kunna vara intressant. Detta skulle dock inte bli möjligt att realistiskt genomföra utan att begränsa testområdet betydligt, vilket ledde till att det valdes bort i förmån för en mer kvantitativt inriktad analys och endast en ytlig analys av nätverkstrafiken. Något som diskuterades var att utföra flera tester med olika filstorlekar. Vad som i synnerhet skulle vara intressant är ett test med filer av en storlek på 15-20KB, alltså fortfarande mycket små men ändå större än alla MTU:er. Det är fullt möjligt att ett sådant test skulle visa på att en större MTU är fördelaktigt även vid överförandet av mindre filer, så länge som de inte är mindre än MTU:n. Om mer tid hade funnits att tillgå hade detta varit ett logiskt steg i vidareutvecklingen av arbetet. Initialt var det även tänkt att fler MTU:er skulle testas, för att få en mer finkornig utveckling av överföringstiderna, men i mån av tid beslutades det efter diskussion att 4 var tillräckligt för att få resultat som var tydliga nog. Att döma av resultaten så stämde till synes detta, då dessa oftast följde ett ganska tydligt mönster. 5.1 Slutsats Överlag så har det visat sig genom tester att en högre MTU leder till snabbare filöverföringar, och att en maximerad MTU kan ge resultat som är uppåt 5% snabbare än med en standard-mtu. Dessa resultat har visat sig för alla protokoll utom ett, som istället begränsades av hårdvara vid överföring. Filstorleken visade sig ha en viktig betydelse för MTU:ns inverkan. Vid överföring av många små filer presterade en större MTU:er sämre, och en standard-mtu gav istället bäst resultat. På det hela taget gav FTP bäst resultat vid en överföring av en stor fil, medan CIFS gav bäst resultat när många små filer överfördes. 5.2 Fortsatt forskning Eftersom att samtliga test har utförts i en ren Linux-miljö finns det utrymme för test inom andra plattformar. Det saknas även test utförda inom en större topologi, där nätverkstrafiken skulle behöva passera genom fler nätverksenheter. Något sådant skulle kunna påverka resultaten, och därför vara intressant att studera. Vidare så finns det möjlighet för en mer kvalitativ analys av resultaten baserat på nätverkstrafiken, vilket skulle kunna styrka eller motsätta sig resultaten som framstått inom detta arbete. 19

23 6. Referenser [1] M. Hagberg et al., Jämförelse av nätverksfilsystemsprotokoll i Windowsmiljö, Independent thesis Basic level, School of Communication and Design, Univ. Kalmar, [2] C. Kodikara et al., Optimal settings of maximum transfer unit (MTU) for efficient wireless video communications, IEEE Proceedings Communications, vol. 152, Issue 5, pp , Okt, [3] J. Postel. (1980, Augusti 28). User Datagram Protocol (RFC 768) [Online]. Tillgänglig: [4] J. Postel. (1981, September). Internet Protocol (RFC 791) [Online]. Tillgänglig: [5] P. Dykstra. (1999, December 20). Gigabit Ethernet Jumbo Frames And why you should care [Online]. Tillgänglig: [6] M. A. Dye et al., Glossary, I Network Fundamentals - CCNA Exploration Companion Guide. Indianapolis, Indiana : Cisco Press, 2007, sek. maximum transmission unit (MTU), pp [7] M. A. Dye et al., OSI Transport Layer, I Network Fundamentals - CCNA Exploration Companion Guide. Indianapolis, Indiana : Cisco Press, 2007, sek. TCP: Communicating with Reliability, pp [8] A. Bhushan. (1971, April 16). A File Transfer Protocol (RFC 114) [Online]. Tillgänglig: [9] J. Postel och J. Reynolds. (1985, Oktober). File Transfer Protocol (RFC 959.) [Online]. Tillgänglig: [10] P. Ford-Hutchinson. (2005, Oktober). Securing FTP with TLS (RFC 4217) [Online]. Tillgänglig: [11] T. Rinne och T. Ylonen (2011, November 6). scp Linux man page. [Online]. Tillgänglig: [12] Sun Microsystems, Inc. (1989, Mars) NFS: Network File System Protocol Specification (RFC 1094) [Online]. Tillgänglig: 20

24 [13] Microsoft TechNet. Common Internet File System [Online]. Tillgänglig: [14] S. Shepler, et al., (2003, April) Network File System (NFS) version 4 Protocol (RFC 3530) [Online] Tillgänglig: [15] S. Mueller et al. Memory, I Upgrading and Repairing Servers [16] Cannonical Ltd. (Läst: 2012, Maj 10) About Ubuntu [Online]. Tillgänglig: [17] B. M. Febrero. (2011 Februari) Traffic Analysis With Wireshark [Online]. Tillgänglig: wireshark.pdf [18] Nationalencyklopedin. (Läst: 2012, Maj 10) Kvantitativ metod [Online]. Tillgänglig: 21

25 7. Bilaga Filen data.zip bifogas, och innehåller samtlig insamlad data, samt alla Wiresharkcaptures. 22