computer networking michaelmas/lent term m/w/f 11:00-12:00 ... · computer networking...
TRANSCRIPT
ComputerNetworking
Michaelmas/LentTermM/W/F11:00-12:00LT1inGatesBuilding
SlideSet6
Evangelia [email protected]
2017-2018
1
Topic6– Applications
• Overview
• InfrastructureServices(DNS)
• TraditionalApplications(web)
• MultimediaApplications(SIP)
• P2PNetworks2
3
Client-serverarchitectureserver:
– always-onhost– permanentIPaddress– serverfarmsforscaling
clients:– communicatewithserver– maybeintermittentlyconnected– mayhavedynamicIPaddresses– donotcommunicatedirectly
witheachother
client/server
4
PureP2Parchitecture
• no always-onserver• arbitraryendsystems
directlycommunicate• peersareintermittently
connectedandchangeIPaddresses
Highlyscalablebutdifficulttomanage
peer-peer
5
Hybridofclient-serverandP2PSkype
– voice-over-IPP2Papplication– centralizedserver:findingaddressofremoteparty:
– client-clientconnection:direct(notthroughserver)
Instantmessaging– chattingbetweentwousersisP2P– centralizedservice:clientpresencedetection/location
• userregistersitsIPaddresswithcentralserverwhenitcomesonline
• usercontactscentralservertofindIPaddressesofbuddies
6
Addressingprocesses• toreceivemessages,
processmusthaveidentifier
• hostdevicehasunique32-bitIPaddress
• Q: doesIPaddressofhostonwhichprocessrunssufficeforidentifyingtheprocess?– A: No,many processescanberunningonsamehost
• identifier includesbothIPaddress andportnumbersassociatedwithprocessonhost.
• Exampleportnumbers:– HTTPserver:80– Mailserver:25
• tosendHTTPmessagetoyuba.stanford.edu webserver:– IPaddress: 171.64.74.58– Portnumber: 80
• moreshortly…
Recall:Multiplexingisaserviceprovidedby(each)layertoo!
DemultipexingMultiplexing
Lower channelApplication:oneweb-servermultiplesetsofcontentHost:onemachinemultipleservicesNetwork:onephysicalboxmultipleaddresses(likevns.cl.cam.ac.uk)….
UNIX:/etc/protocols=examplesofdifferenttransport-protocolsontopofIP
UNIX:/etc/services=examplesofdifferent(TCP/UDP)services– byport(Thesefilesareanexampleofa(static)
approachtonameservices)7
8
App-layerprotocoldefines• Typesofmessages
exchanged,– e.g.,request,response
• Messagesyntax:– whatfieldsinmessages&
howfieldsaredelineated
• Messagesemantics– meaningofinformationin
fields
• Rulesforwhenandhowprocessessend&respondtomessages
Public-domainprotocols:• definedinRFCs• allowsforinteroperability• e.g.,HTTP,SMTPProprietaryprotocols:• e.g.,Skype
9
Whattransportservicedoesanappneed?
Dataloss• someapps(e.g.,audio)can
toleratesomeloss• otherapps(e.g.,filetransfer,
telnet)require100%reliabledatatransfer
Timing• someapps(e.g.,Internet
telephony,interactivegames)requirelowdelaytobe“effective”
Throughput❒ someapps(e.g.,multimedia)require
minimumamountofthroughputtobe“effective”
❒ otherapps(“elasticapps”)makeuseofwhateverthroughputtheyget
Security❒ Encryption,dataintegrity,…
MysterioussecretofTransport• Thereismorethansortoftransport layer
Shocked?Iseriouslydoubtit…
RecallthetwomostcommonTCPandUDP
Naming• Internethasoneglobalsystemofaddressing:IP
– Byexplicitdesign
• Andoneglobalsystemofnaming:DNS– Almostbyaccident
• Atthetime,onlyitemsworthnamingwerehosts– Amistakethatcausesmanypainfulworkarounds
• Everythingisnownamedrelativetoahost– Contentismostnotableexample(URLstructure)
10
LogicalStepsinUsingInternet• Humanhasnameofentityshewantstoaccess
– Content,host,etc.
• Invokesanapplicationtoperformrelevanttask– Usingthatname
• AppinvokesDNStotranslatenametoaddress
• Appinvokestransportprotocoltocontacthost– Usingaddressasdestination
11
Addressesvs Names• Scopeofrelevance:
– App/userisprimarilyconcernedwithnames– Networkisprimarilyconcernedwithaddresses
• Timescales:– Namelookuponce(orgetfromcache)– Addresslookuponeachpacket
• Whenmovingahosttoadifferentsubnet:– Theaddresschanges– Thenamedoesnotchange
• Whenmovingcontenttoadifferentlynamedhost– Nameandaddressbothchange!
12
13
Relationship Between Names&Addresses
• Addressescanchangeunderneath– Movewww.bbc.co.uk to212.58.246.92– Humans/Appsshouldbeunaffected
• NamecouldmaptomultipleIPaddresses– www.bbc.co.uk tomultiplereplicasoftheWebsite– Enables
• Load-balancing• Reducinglatencybypickingnearbyservers
• Multiplenamesforthesameaddress– E.g.,aliaseslikewww.bbc.co.uk andbbc.co.uk– Mnemonicstablename,anddynamiccanonicalname
• Canonicalname=actualnameofhost
MappingfromNamestoAddresses• Originally:per-hostfile/etc/hosts
– SRI(MenloPark)keptmastercopy– Downloadedregularly– Flatnamespace
• Singleservernotresilient,doesn’tscale– Adoptedadistributedhierarchicalsystem
• Twointertwinedhierarchies:– Infrastructure:hierarchyofDNSservers– Namingstructure:www.bbc.co.uk
14
15
Domain Name System (DNS)• Topofhierarchy:Root
– Locationhardwiredintootherservers
• NextLevel:Top-leveldomain(TLD)servers– .com,.edu,etc.– .uk,.au,.to,etc.– Managedprofessionally
• BottomLevel:AuthoritativeDNSservers– Actuallydothemapping– Canbemaintainedlocallyorbyaserviceprovider
16
Distributed Hierarchical Database
com edu org ac uk zw arpa
unnamed root
bar
west east
foo my
ac
cam
cl
in-addr
generic domains country domains
my.east.bar.edu cl.cam.ac.uk
Top-Level Domains (TLDs)
17
DNS Root• LocatedinVirginia,USA• Howdowemaketherootscale?
Verisign,Dulles,VA
18
DNS Root Servers• 13rootservers(seehttp://www.root-servers.org/)
– LabeledAthroughM• Doesthis scale?
BUSC-ISIMarinadelRey,CALICANNLosAngeles,CA
ENASAMtView,CAFInternetSoftwareConsortiumPalo Alto,CA
IAutonomica, Stockholm
KRIPELondon
MWIDETokyo
AVerisign,Dulles,VACCogent,Herndon,VADUMarylandCollegePark,MDGUSDoD Vienna,VAHARLAberdeen,MDJVerisign
19
DNS Root Servers• 13rootservers(seehttp://www.root-servers.org/)
– LabeledAthroughM• Replicationviaany-casting (localizedroutingforaddresses)
BUSC-ISIMarinadelRey,CALICANNLosAngeles,CA
ENASAMtView,CAFInternetSoftwareConsortium,Palo Alto,CA(and37otherlocations)
IAutonomica, Stockholm(plus29otherlocations)
KRIPELondon(plus16otherlocations)
MWIDETokyoplusSeoul,Paris,SanFrancisco
AVerisign,Dulles,VACCogent,Herndon,VA(alsoLosAngeles,NY,Chicago)DUMarylandCollegePark,MDGUSDoD Vienna,VAHARLAberdeen,MDJVerisign (21locations)
20
Using DNS• Twocomponents
– LocalDNSservers– Resolversoftwareonhosts
• LocalDNSserver(“defaultnameserver”)– Usuallyneartheendhosts thatuseit– Localhostsconfiguredwithlocalserver(e.g.,/etc/resolv.conf)orlearnserverviaDHCP
• Clientapplication– Extractservername(e.g.,fromtheURL)– Dogethostbyname()totriggerresolvercode
localDNSserverdns.cam.ac.uk
21
requestinghostcl.cam.ac.uk www.stanford.edu
rootDNSserver
1
23
4
5
6
authoritativeDNSserverdns.stanford.edu
78
TLDDNSserver
How Does Resolution Happen?(Iterative example)
Hostatcl.cam.ac.ukwantsIPaddressforwww.stanford.edu
iterated query:❒ Host enquiry is delegated
to local DNS server❒ Consider
transactions 2 – 7 only❒ contacted server replies
with name of next server to contact
❒ “I don’t know this name, but ask this server”
22
requesting hostcl.cam.ac.uk
www.stanford.edu
root DNS server
local DNS serverdns.cam.ac.uk
1
2
45
6
authoritative DNS serverdns.stanford.edu
7
8
TLD DNS server
3recursive query:❒ puts burden of name
resolution on contacted name server
❒ heavy load?
DNSnameresolutionrecursive example
23
Recursive and Iterative Queries - Hybrid case• Recursive query
– Askservertogetanswerforyou
– E.g.,requests1,2andresponses9,10
• Iterative query– Askserverwhotoasknext
– E.g.,allotherrequest-responsepairs
requestinghostmy-host.cl.cam.ac.uk
rootDNSserver
34
5
6
7
authoritativeDNSserverdns.stanford.edu
8
TLDDNSserver
SiteDNSserverdns.cam.ac.uk
2 9
1 10
SiteDNSserverdns.cam.ac.uk
24
DNS Caching• Performingallthesequeriestakestime
– Andallthisbefore actualcommunicationtakesplace– E.g.,1-secondlatencybeforestartingWebdownload
• Caching cangreatlyreduceoverhead– Thetop-levelserversveryrarelychange– Popularsites(e.g.,www.bbc.co.uk)visitedoften– LocalDNSserveroftenhastheinformationcached
• HowDNScachingworks– DNSserverscacheresponsestoqueries– Responsesincludea“timetolive” (TTL)field– ServerdeletescachedentryafterTTLexpires
25
Negative Caching
• Rememberthingsthatdon’twork– Misspellingslikebbcc.co.uk andwww.bbc.com.uk– Thesecantakealongtimetofailthefirsttime– Goodtorememberthattheydon’twork– …sothefailuretakeslesstimethenexttimearound
• But:negativecachingisoptional– Andnotwidelyimplemented
26
Reliability• DNSserversarereplicated(primary/secondary)
– Nameserviceavailableifatleastone replicaisup– Queriescanbeload-balancedbetweenreplicas
• Usually,UDPusedforqueries– Needreliability:mustimplementthisontopofUDP– SpecsupportsTCPtoo,butnotalwaysimplemented
• Tryalternateserversontimeout– Exponentialbackoff whenretryingsameserver
• Sameidentifierforallqueries– Don’tcarewhichserverresponds
DNSandSecurity• Nowaytoverifyanswers
– OpensupDNStomanypotentialattacks– DNSSECfixesthis
• Mostobviousvulnerability:recursiveresolution– Usingrecursiveresolution,hostmusttrustDNSserver– WhenatStarbucks,serverisundertheircontrol– Andcanreturnwhatevervaluesitwants
• Moresubtleattack:Cachepoisoning– Those“additional”recordscanbeanything!
27
Why is the web so successful?• Whatdotheweb,youtube,facebook,tumblr,twitter,flickr,
…..haveincommon?– Theabilitytoself-publish
• Self-publishingthatis easy,independent,free
• Nointerestincollaborativeandidealisticendeavor– Peoplearen’tlookingforNirvana(orevenXanadu)– Peoplealsoaren’tlookingfortechnicalperfection
• Wanttomaketheirmark,andfindsomethingneat– Twosidesofthesamecoin,createssynergy– “Performance”moreimportantthandialogue….
28
29
Web Components• Infrastructure:
– Clients– Servers– Proxies
• Content:– Individualobjects(files,etc.)– Websites(coherentcollectionofobjects)
• Implementation– HTML:formattingcontent– URL:namingcontent– HTTP:protocolforexchangingcontent
AnycontentnotjustHTML!
30
HTML: HyperText MarkupLanguage
• AWebpage has:– BaseHTMLfile– Referencedobjects(e.g.,images)
• HTMLhasseveralfunctions:– Formattext– Referenceimages– Embedhyperlinks (HREF)
31
URL Syntaxprotocol://hostname[:port]/directorypath/resource
protocol http,ftp,https,smtp,rtsp,etc.
hostname DNSname,IPaddress
port Defaultstoprotocol’sstandardporte.g. http:80https:443
directorypath Hierarchical,reflectingfilesystem
resource Identifiesthedesiredresource
Canalsoextendtoprogramexecutions:http://us.f413.mail.yahoo.com/ym/ShowLetter?box=%40B%40Bulk&MsgId=2604_1744106_29699_1123_1261_0_28917_3552_1289957100&Search=&Nhead=f&YY=31454&order=down&sort=date&pos=0&view=a&head=b
32
HyperText Transfer Protocol (HTTP)
• Request-responseprotocol• Relianceonaglobalnamespace• Resourcemetadata• Stateless• ASCIIformat
$ telnet www.cl.cam.ac.uk 80GET /~awm22/win HTTP/1.0<blankline,i.e.,CRLF>
Steps in HTTP Request• HTTPClientinitiatesTCPconnectiontoserver
– SYN– SYNACK– ACK
• ClientsendsHTTPrequesttoserver– CanbepiggybackedonTCP’sACK
• HTTPServerrespondstorequest• Clientreceivestherequest,terminatesconnection• TCPconnectionterminationexchange
HowmanyRTTsforasinglerequest?
33
34
Client-ServerCommunication
• twotypesofHTTPmessages:request,response• HTTPrequestmessage:(GETPOSTHEAD….)
GET /somedir/page.html HTTP/1.1Host: www.someschool.eduUser-agent: Mozilla/4.0Connection: close Accept-language:fr
(extracarriagereturn,linefeed)
requestline(GET,POST,
HEADcommands)
headerlines
Carriagereturn,linefeed
indicatesendofmessage
HTTP/1.1 200 OK Connection closeDate: Thu, 06 Aug 1998 12:00:15 GMT Server: Apache/1.3.0 (Unix) Last-Modified: Mon, 22 Jun 1998 …... Content-Length: 6821 Content-Type: text/html
data data data data data ...
statusline(protocolstatuscode
statusphrase)
headerlines
data,e.g.,requestedHTMLfile
HTTPresponsemessage
35
Different Forms of Server Response
• Returnafile– URLmatchesafile(e.g., /www/index.html)– Serverreturnsfileastheresponse– Servergeneratesappropriateresponseheader
• Generateresponsedynamically– URLtriggersaprogramontheserver– Serverrunsprogramandsendsoutputtoclient
• Returnmeta-datawithnobody
36
HTTP Resource Meta-Data• Meta-data
– Infoabout aresource,storedasaseparateentity
• Examples:– Sizeofresource,lastmodificationtime,typeofcontent
• Usageexample:ConditionalGETRequest– Clientrequestsobject“If-modified-since”– Ifunchanged,“HTTP/1.1 304 Not Modified”– Nobodyintheserver’sresponse,onlyaheader
37
HTTP is Stateless
• Eachrequest-responsetreatedindependently– Serversnot requiredtoretainstate
• Good:Improvesscalabilityontheserver-side– Failurehandlingiseasier– Canhandlehigherrateofrequests– Orderofrequestsdoesn‘tmatter
• Bad:Someapplicationsneed persistentstate– Needtouniquelyidentifyuserorstoretemporaryinfo– e.g.,Shoppingcart,userprofiles,usagetracking,…
38
State in a Stateless Protocol:
Cookies• Client-side statemaintenance
– Clientstoressmall(?) stateonbehalfofserver– Clientsendsstateinfuturerequeststotheserver
• Canprovideauthentication
Request
ResponseSet-Cookie: XYZ
RequestCookie: XYZ
39
HTTP Performance• MostWebpageshavemultipleobjects
– e.g., HTMLfileandabunchofembeddedimages
• Howdoyouretrievethoseobjects(naively)?– Oneitematatime
• Putstuffintheoptimalplace?– Whereisthatprecisely?
• EntertheWebcacheandtheCDN
40
Fetch HTTP Items: Stop & WaitClient Server
Finish;displaypage
Startfetchingpage Tim
e
≥2RTTsperobject
41
Improving HTTP Performance:
Concurrent Requests & Responses
• Usemultipleconnectionsinparallel
• Doesnotnecessarilymaintainorderofresponses
• Client=J
• Server=J
• Network=LWhy?
R1R2 R3
T1
T2 T3
42
Improving HTTP Performance:
Pipelined Requests & Responses• Batch requestsandresponses
– Reduceconnectionoverhead– Multiplerequestssentinasingle
batch– Maintainsorderofresponses– Item1alwaysarrivesbeforeitem2
• Howisthisdifferentfromconcurrentrequests/responses?– SingleTCPconnection
Client Server
Improving HTTP Performance:
Persistent Connections
• Enablesmultipletransfersperconnection– MaintainTCPconnectionacrossmultiplerequests– Includingtransferssubsequenttocurrentpage– Clientorservercanteardownconnection
• Performanceadvantages:– Avoidoverheadofconnectionset-upandtear-down– AllowTCPtolearnmoreaccurateRTTestimate– AllowTCPcongestionwindowtoincrease– i.e.,leveragepreviouslydiscoveredbandwidth
• DefaultinHTTP/1.1
43
HTTPevolution
• 1.0– oneobjectperTCP:simplebutslow• Parallelconnections- multipleTCP,oneobjecteach:wastesb/w,maybesvr limited,outoforder
• 1.1pipelining– aggregateretrievaltime:ordered,multipleobjectssharingsingleTCP
• 1.1persistent– aggregateTCPoverhead:loweroverheadintime,increaseoverheadatends(e.g.,whenshould/doyouclosetheconnection?)
44
Scorecard:GettingnSmallObjects
Timedominatedbylatency
• One-at-a-time:~2nRTT• Persistent:~(n+1)RTT• Mconcurrent:~2[n/m]RTT• Pipelined:~2RTT• Pipelined/Persistent:~2RTTfirsttime,RTTlater
45
Scorecard:GettingnLargeObjects
Timedominatedbybandwidth
• One-at-a-time:~nF/B• Mconcurrent:~[n/m]F/B
– assumingsharedwithlargepopulationofusers• Pipelinedand/orpersistent:~nF/B
– Theonlythingthathelpsisgettingmorebandwidth..
46
47
Improving HTTP Performance:
Caching• Manyclientstransfersameinformation
– Generatesredundant serverandnetworkload
– Clientsexperienceunnecessary latency
Server
Clients
BackboneISP
ISP-1 ISP-2
48
Improving HTTP Performance:
Caching: How
• ModifiertoGETrequests:– If-modified-since – returns“notmodified” ifresourcenotmodifiedsincespecifiedtime
• Responseheader:– Expires – howlongit’ssafetocachetheresource– No-cache – ignoreallcaches;alwaysgetresourcedirectlyfromserver
49
Improving HTTP Performance:
Caching: Why
• Motiveforplacingcontentclosertoclient:– Usergetsbetterresponsetime– Contentprovidersgethappierusers
• Timeismoney,really!– Networkgetsreducedload
• Whydoescachingwork?– Exploitslocalityofreference
• Howwelldoescachingwork?– Verywell,uptoalimit– Largeoverlapincontent– Butmanyuniquerequests
50
Improving HTTP Performance:
Caching on the Client
Example:ConditionalGETRequest• Returnresourceonlyifithaschangedattheserver
– Saveserverresources!
• How?– Clientspecifies“if-modified-since” timeinrequest– Servercomparesthisagainst“lastmodified” timeofdesiredresource– Serverreturns“304NotModified” ifresourcehasnotchanged– ….ora“200OK” withthelatestversionotherwise
GET /~awm22/win HTTP/1.1Host: www.cl.cam.ac.ukUser-Agent: Mozilla/4.03If-Modified-Since: Sun, 27 Aug 2006 22:25:50 GMT<CRLF>
Requestfromclienttoserver:
51
Improving HTTP Performance:
Caching with Reverse ProxiesCachedocumentsclosetoserver
à decreaseserverload• Typicallydonebycontentproviders
• Onlyworksforstatic(*) content(*)staticcanalsobesnapshotsofdynamiccontent
Clients
BackboneISP
ISP-1 ISP-2
Server
Reverseproxies
52
Improving HTTP Performance:
Caching with Forward ProxiesCachedocumentsclosetoclients
à reducenetworktrafficanddecreaselatency• TypicallydonebyISPsorcorporateLANs
Clients
BackboneISP
ISP-1 ISP-2
Server
Reverseproxies
Forwardproxies
53
Improving HTTP Performance:
Caching w/ Content Distribution Networks
• Integrateforwardandreversecachingfunctionality– Oneoverlaynetwork(usually)administeredbyoneentity– e.g., Akamai
• Providedocumentcaching– Pull: Directresultofclients’ requests– Push:Expectationofhighaccessrate
• Alsodosomeprocessing– Handledynamic webpages– Transcoding– Maybedosomesecurityfunction– watermarkIP
54
Improving HTTP Performance:
Caching with CDNs (cont.)
Clients
ISP-1
Server
Forwardproxies
BackboneISP
ISP-2
CDN
55
Improving HTTP Performance:
CDN Example – Akamai
• Akamaicreatesnewdomainnamesforeachclientcontentprovider.– e.g.,a128.g.akamai.net
• TheCDN’sDNSserversareauthoritativeforthenewdomains
• TheclientcontentprovidermodifiesitscontentsothatembeddedURLsreferencethenewdomains.– “Akamaize” content– e.g.:http://www.bbc.co.uk/popular-image.jpgbecomes
http://a128.g.akamai.net/popular-image.jpg
• RequestsnowsenttoCDN’sinfrastructure…
56
Hosting: Multiple Sites Per Machine
• MultipleWebsitesonasinglemachine– HostingcompanyrunstheWebserveronbehalfofmultiplesites(e.g.,www.foo.com andwww.bar.com)
• Problem:GET /index.html– www.foo.com/index.html orwww.bar.com/index.html?
• Solutions:– Multipleserverprocessesonthesamemachine
• HaveaseparateIPaddress(orport)foreachserver– IncludesitenameinHTTPrequest
• SingleWebserverprocesswithasingleIPaddress• Clientincludes“Host” header(e.g., Host: www.foo.com)• Requiredheader withHTTP/1.1
57
Hosting: Multiple Machines Per Site• ReplicatepopularWebsiteacrossmanymachines
– Helpstohandletheload– Placescontentclosertoclients
• Helpswhencontentisn’tcacheable
• Problem:Wanttodirectclienttoparticularreplica– Balanceloadacrossserverreplicas– Pairclientswithnearbyservers
58
Multi-Hosting at Single Location• SingleIPaddress,multiplemachines
– RunmultiplemachinesbehindasingleIPaddress
– EnsureallpacketsfromasingleTCPconnectiongotothesamereplica
Load Balancer64.236.16.20
59
Multi-Hosting at Several Locations• Multipleaddresses,multiplemachines
– Samenamebutdifferentaddressesforallofthereplicas– ConfigureDNSservertoreturnclosest address
Internet64.236.16.20
173.72.54.131
12.1.1.1
CDNexamplesround-up
• CDNusingDNSDNShasinformationonloading/distribution/location
• CDNusinganycastsameaddressfromDNSnamebutlocalroutes
• CDNbasedonrewritingHTMLURLs(akami examplejustcovered– akami usesDNStoo)
60
SIP– SessionInitiationProtocol
61
Session?
AnyonesmellanOSI/ISOstandardsdocumentburning?
SIP- VoIP
EstablishingcommunicationthroughSIPproxies.
62
SIP?• SIP– bringingthefun/complexityoftelephonytotheInternet–Userlocation–Useravailability–Usercapabilities– Sessionsetup– Sessionmanagement
• (e.g.“callforwarding”)
63
H.323– ITU
• Whyhaveonestandardwhenthereareatleasttwo….
• ThefullH.323ishundredsofpages– Theprotocolisknownforitscomplexity– anITUhallmark
• SIPisnotmuchbetter
– IETFgrewupandbecametheITU….
64
MultimediaApplications
MessageflowforabasicSIPsession
65
The(still?)missingpiece:ResourceAllocationforMultimediaApplications
Ican‘differentiate’VoIPfromdatabut…IcanonlycontroldatagoingintotheInternet
66
MultimediaApplications• ResourceAllocationforMultimediaApplications
Admissioncontrolusingsessioncontrolprotocol.
67
ResourceAllocationforMultimediaApplications
Sowheredoesithappen?Insidesingleinstitutionsordomainsofcontrol…..
(Universities,Hospitals,bigcorp…)
WhataboutmyaDSL/CABLE/etc itcombinesvoiceanddata?Phonecompanycontrols themultiplexingontheline
andthroughouttheirownnetworktoo……
Co-ordinationofSIPsignalingandresourcereservation.
Comingsoon…19952000
2010whoarewekidding??
68
P2P– efficientnetworkusethatannoystheISP
69
70
PureP2Parchitecture
• no always-onserver• arbitraryendsystems
directlycommunicate• peersareintermittently
connectedandchangeIPaddresses
• Threetopics:– Filedistribution– Searchingforinformation– CaseStudy:Skype
peer-peer
71
FileDistribution:Server-Clientvs P2PQuestion :HowmuchtimetodistributefilefromoneservertoNpeers?
usu2d1 d2
u1
uN
dN
Server
Network(withabundantbandwidth)
File,sizeF
us: serveruploadbandwidth
ui: peeri uploadbandwidth
di: peeri downloadbandwidth
72
Filedistributiontime:server-client
usu2d1 d2
u1
uN
dN
Server
Network(withabundantbandwidth)
F• serversequentiallysendsNcopies:– NF/us time
• clienti takesF/ditimetodownload
increaseslinearlyinN(forlargeN)
=dcs =max{ NF/us,F/min(di) }i
TimetodistributeFtoN clientsusing
client/serverapproach
73
Filedistributiontime:P2P
usu2d1 d2
u1
uN
dN
Server
Network(withabundantbandwidth)
F• servermustsendonecopy:F/us time
• clienti takesF/ditimetodownload
• NFbitsmustbedownloaded(aggregate)❒ fastestpossibleuploadrate:us +Sui
dP2P =max{ F/us,F/min(di) ,NF/(us +Sui) }i
74
0
0.5
1
1.5
2
2.5
3
3.5
0 5 10 15 20 25 30 35
N
Min
imum
Dis
tribu
tion
Tim
e P2PClient-Server
Server-clientvs.P2P:example
Clientuploadrate=u,F/u=1hour,us =10u,dmin ≥us
75
Filedistribution:BitTorrent**ratheroldBitTorrent
tracker: trackspeersparticipatingintorrent
torrent: groupofpeersexchangingchunksofafile
obtainlistofpeers
tradingchunks
peer
❒ P2Pfiledistribution
76
BitTorrent (1)• filedividedinto256KBchunks.• peerjoiningtorrent:
– hasnochunks,butwillaccumulatethemovertime– registerswithtrackertogetlistofpeers,connectstosubsetofpeers(“neighbors”)
• whiledownloading,peeruploadschunkstootherpeers.• peersmaycomeandgo• oncepeerhasentirefile,itmay(selfishly)leaveor
(altruistically)remain
77
BitTorrent (2)PullingChunks• atanygiventime,different
peershavedifferentsubsetsoffilechunks
• periodically,apeer(Alice)askseachneighborforlistofchunksthattheyhave.
• Alicesendsrequestsforhermissingchunks– rarestfirst
SendingChunks:tit-for-tat❒ Alicesendschunkstofourneighbors
currentlysendingherchunksatthehighestratev re-evaluatetop4every10secs
❒ every30secs:randomlyselectanotherpeer,startssendingchunksv newlychosenpeermayjointop4v “optimisticallyunchoke”
78
BitTorrent:Tit-for-tat(1)Alice“optimisticallyunchokes” Bob(2)AlicebecomesoneofBob’stop-fourproviders;Bobreciprocates(3)BobbecomesoneofAlice’stop-fourproviders
Withhigheruploadrate,canfindbettertradingpartners&getfilefaster!
DistributedHashTable(DHT)
• DHT=distributedP2Pdatabase• Databasehas(key,value)pairs;
– key:ss number;value:humanname– key:contenttype;value:IPaddress
• Peersquery DBwithkey– DBreturnsvaluesthatmatchthekey
• Peerscanalsoinsert (key,value)peers
79
DistributedHashTable(DHT)
• DHT=distributedP2Pdatabase• Databasehas(key,value)pairs;
– key:ss number;value:humanname– key:contenttype;value:IPaddress
• Peersquery DBwithkey– DBreturnsvaluesthatmatchthekey
• Peerscanalsoinsert (key,value)peers
80
DHTIdentifiers
• Assignintegeridentifiertoeachpeerinrange[0,2n-1].– Eachidentifiercanberepresentedbynbits.
• Requireeachkeytobeanintegerinsamerange.• Togetintegerkeys,hashoriginalkey.
– eg,key=h(“GameofThronesseason4”)– Thisiswhytheycallitadistributed“hash” table
Howtoassignkeystopeers?
• Centralissue:– Assigning(key,value)pairstopeers.
• Rule:assignkeytothepeerthathastheclosest ID.
• Conventioninlecture:closestistheimmediatesuccessorofthekey.
• Ex:n=4;peers:1,3,4,5,8,10,12,14;– key=13,thensuccessorpeer=14– key=15,thensuccessorpeer=1
1
3
4
5
810
12
15
CircularDHT(1)
• Eachpeeronly awareofimmediatesuccessorandpredecessor.
• “Overlaynetwork”
CircleDHT(2)
0001
0011
0100
0101
10001010
1100
1111
Who’srespforkey1110?
Iam
O(N)messagesonavgtoresolvequery,whenthereareNpeers
1110
1110
1110
1110
1110
1110
Defineclosestasclosestsuccessor
CircularDHTwithShortcuts
• EachpeerkeepstrackofIPaddressesofpredecessor,successor,shortcuts.
• Reducedfrom6to2messages.• PossibletodesignshortcutssoO(logN)neighbors,O(logN)
messagesinquery
1
3
4
5
810
12
15
Who’srespforkey1110?
PeerChurn
• Peer5abruptlyleaves• Peer4detects;makes8itsimmediatesuccessor;asks8
whoitsimmediatesuccessoris;makes8’simmediatesuccessoritssecondsuccessor.
• Whatifpeer13wantstojoin?
1
3
4
5
810
12
15
•Tohandlepeerchurn,requireeachpeertoknowtheIPaddressofitstwosuccessors.• Eachpeerperiodicallypingsitstwosuccessorstoseeiftheyarestillalive.
87
P2PCasestudy:Skype(pre-Microsoft)
• inherentlyP2P:pairsofuserscommunicate.
• proprietaryapplication-layerprotocol(inferredviareverseengineering)
• hierarchicaloverlaywithSNs
• IndexmapsusernamestoIPaddresses;distributedoverSNs
Skypeclients(SC)
Supernode(SN)
Skypeloginserver
88
Peersasrelays• ProblemwhenbothAlice
andBobarebehind“NATs”.– NATpreventsanoutsidepeer
frominitiatingacalltoinsiderpeer
• Solution:– UsingAlice’sandBob’sSNs,
Relayischosen– Eachpeerinitiatessession
withrelay.– Peerscannowcommunicate
throughNATsviarelay
Summary.• Appsneedprotocolstoo
• Wecoveredexamplesfrom– TraditionalApplications(web)– ScalingandSpeedingtheweb(CDN/Cachetricks)
• InfrastructureServices(DNS)– CacheandHierarchy
• MultimediaApplications(SIP)– Extremelyhardtodobetterthanworst-effort
• P2PNetworkexamples89