Cryptography COS 461: Computer Networks Princeton University 1.
COS 461: Computer Networks Midterm Revie · COS 461: Computer Networks Midterm Review Spring 2011...
74
COS 461: Computer Networks Midterm Review Spring 2011 Mike Freedman h@p://www.cs.princeton.edu/courses/archive/spr11/cos461/ 1
Transcript of COS 461: Computer Networks Midterm Revie · COS 461: Computer Networks Midterm Review Spring 2011...
COS461:ComputerNetworksMidtermReview
Spring2011
MikeFreedman
h@p://www.cs.princeton.edu/courses/archive/spr11/cos461/
1
2
Internetlayering:Message,Segment,Packet,andFrame
HTTP
TCP
IP
Ethernet interface
HTTP
TCP
IP
Ethernet interface
IP IP
Ethernet interface
Ethernet interface
SONET interface
SONET interface
host host
router router
HTTP message
TCP segment
IP packet IP packet IP packet
Ethernet frame Ethernet frame SONET frame 2
Topics• Linklayer(Sl.4)
– Sharingalink:TDMA,FDMA
– EthernetandCSMA/CD
– WirelessandCSMA/CA– Spanningtreeandswitching– TranslaQngaddrs:DHCP/ARP
• Networklayer(Sl.25)– IPv4andaddressing– IPforwarding– Middleboxes:NATs,firewalls,tunneling
• Transportlayer(Sl.38)– Socketinterface– UDP– TCP
• Reliability• CongesQonControl• InteracQonsw/AcQveQueueManagement
• ApplicaQonlayer(Sl.68)– TranslaQngnames:DNS– HTTPandCDNs– Overlaynetworks
3
LinkLayer
4
Link‐LayerServices• Encoding
– RepresenQngthe0sand1s
• Framing– EncapsulaQngpacketintoframe,addingheaderandtrailer
– UsingMACaddresses,ratherthanIPaddresses
• ErrordetecQon– Errorscausedbysignala@enuaQon,noise.– ReceiverdetecQngpresenceoferrors
5
MulQpleAccessProtocol• Singlesharedbroadcastchannel
– AvoidhavingmulQplenodesspeakingatonce– Otherwise,collisionsleadtogarbleddata
• MulQpleaccessprotocol– Distributedalgorithmforsharingthechannel– Algorithmdetermineswhichnodecantransmit
• Classesoftechniques– ChannelparQQoning:dividechannelintopieces
– Time‐divisionmulQplexing,frequencydivisionmulQplexing– Takingturns:passingatokenforrighttotransmit– Randomaccess:allowcollisions,andthenrecover
6
KeyIdeasofRandomAccess• CarrierSense(CS)
– Listenbeforespeaking,anddon’tinterrupt– Checkingifsomeoneelseisalreadysendingdata– …andwaiQngQlltheothernodeisdone
• CollisionDetecQon(CD)– Ifsomeoneelsestartstalkingatthesame7me,stop– Realizingwhentwonodesaretransmiangatonce– …bydetecQngthatthedataonthewireisgarbled
• Randomness– Don’tstarttalkingagainrightaway– WaiQngforarandomQmebeforetryingagain
7
CSMA/CDCollisionDetecQon8
MediumAccessControlin802.11• Collisionavoidance,notdetecQon
– Firstexchangecontrolframesbeforetransmiangdata• Senderissues“RequesttoSend”(RTS),includinglengthofdata
• Receiverrespondswith“CleartoSend”(CTS)– IfsenderseesCTS,transmitsdata(ofspecifiedlength)– IfothernodeseesCTS,willidleforspecifiedperiod– IfothernodeseesRTSbutnotCTS,freetosend
• Link‐layeracknowledgmentandretransmission– CRCtodetecterrors– ReceivingstaQonsendsanacknowledgment
– SendingstaQonretransmitsifnoACKisreceived
– Givingupacerafewfailedtransmissions
9
ScalingtheLinkLayer• EthernettradiQonallylimitedbyfadingsignalstrengthinlongwires– IntroducQonofhubs/repeaterstorebroadcast
• SQllamaximum“length”foraEthernetsegment– Otherwise,twonodesmightbetoofarforcarriersensetodetectconcurrentbroadcasts
• Further,toomanynodesinshorterEthernetcanyieldlowtransmissionsrates– Constantlyconflictwithoneanother
10
Bridges/Switches:TrafficIsolaQon
• SwitchbreakssubnetintoLANsegments
• Switchfilterspackets– Frameonlyforwardedtothenecessarysegments– Segmentscansupportseparatetransmissions
hub hub hub
switch/bridge
segment segment
segment
11
ComparingHubs,Switches,Routers
Hub/
Repeater
Bridge/
Switch
Router
Traffic isolation no yes yes
Plug and Play yes yes no
Efficient routing no no yes
Cut through yes yes no
12
SelfLearning:BuildingtheTable• Whenaframearrives
– InspectthesourceMACaddress
– Associatetheaddresswiththeincominginterface
– Storethemappingintheswitchtable
– UseaQme‐to‐livefieldtoeventuallyforgetthemapping
A
B
C
D
Switch learns how to reach A
13
SoluQon:SpanningTrees• Ensurethetopologyhasnoloops
– Avoidusingsomeofthelinkswhenflooding– …toavoidformingaloop
• Spanningtree– Sub‐graphthatcoversallverQcesbutcontainsnocycles– Linksnotinthespanningtreedonotforwardframes
14
EvoluQonTowardVirtualLANs
Red VLAN and Orange VLAN Switches forward traffic as needed
R O
RO
R
R
R
O O O R O R R R
O
O
O
15
Group users based on organizational structure, rather than the physical
layout of the building.
Wireless
16
CSMA:CarrierSense,MulQpleAccess
• MulQpleaccess:channelissharedmedium– StaQon:wirelesshostoraccesspoint– MulQplestaQonsmaywanttotransmitatsameQme
• Carriersense:sensechannelbeforesending– StaQondoesn’tsendwhenchannelisbusy– Topreventcollisionswithongoingtransfers– But,detecQngongoingtransfersisn’talwayspossible
17
A B
C A B C
A’s signal strength
space
C’s signal strength
CA:CollisionAvoidance,NotDetecQon• CollisiondetecQoninwiredEthernet
– StaQonlistenswhiletransmiang– Detectscollisionwithothertransmission– Abortstransmissionandtriessendingagain
• Problem#1:cannotdetectallcollisions– Hiddenterminalproblem– Fading
18
CA:CollisionAvoidance,NotDetecQon• CollisiondetecQoninwiredEthernet
– StaQonlistenswhiletransmiang– Detectscollisionwithothertransmission– Abortstransmissionandtriessendingagain
• Problem#1:cannotdetectallcollisions– Hiddenterminalproblem– Fading
• Problem#2:listeningwhilesending– Strengthofreceivedsignalismuchsmaller– Expensivetobuildhardwarethatdetectscollisions
• So,802.11doescollisionavoidance,notdetecQon
19
HiddenTerminalProblem
• AandCcan’tseeeachother,bothsendtoB
• Occursb/c802.11reliesonphysicalcarriersensing,whichissuscepQbletohiddenterminalproblem
20
CBA
Virtualcarriersensing• Firstexchangecontrolframesbeforetransmiangdata– Senderissues“RequesttoSend”(RTS),incl.lengthofdata
– Receiverrespondswith“CleartoSend”(CTS)
• IfsenderseesCTS,transmitsdata(ofspecifiedlength)
• IfothernodeseesCTS,willidleforspecifiedperiod
• IfothernodeseesRTSbutnotCTS,freetosend
21
HiddenTerminalProblem
• AandCcan’tseeeachother,bothsendtoB
• RTS/CTScanhelp– BothAandCwouldsendRTSthatBwouldseefirst– BonlyrespondswithoneCTS(say,echo’ingA’sRTS)– CdetectsthatCTSdoesn’tmatchandwon’tsend
22
CBA
ExposedTerminalProblem
• BsendingtoA,CwantstosendtoD• AsCreceivesB’spackets,carriersensewouldpreventitfromsendingtoD,eventhoughwouldn’tinterfere
• RTS/CTScanhelp– ChearsRTSfromB,butnotCTSfromA– Cknowsit’stransmissionwillnotinterferewithA
– CissafetotransmittoD
23
CBA D
ImpactonHigher‐LayerProtocols• WirelessandmobilitychangepathproperQes
– Wireless:higherpacketloss,notfromcongesQon– Mobility:transientdisrupQons,andchangesinRTT
• Logically,impactshouldbeminimal…– Best‐effortservicemodelremainsunchanged– TCPandUDPcan(anddo)runoverwireless,mobile
• But,performancedefinitelyisaffected– TCPtreatspacketlossasasignofcongesQon– TCPtriestoesQmatetheRTTtodriveretransmissions– TCPdoesnotperformwellunderout‐of‐orderpackets
• Internetnotdesignedwiththeseissuesinmind
24
NetworkLayer
25
IPPacketStructure
4-bit Version
4-bit Header Length
8-bit Type of Service
(TOS) 16-bit Total Length (Bytes)
16-bit Identification 3-bit Flags 13-bit Fragment Offset
8-bit Time to Live (TTL) 8-bit Protocol 16-bit Header Checksum
32-bit Source IP Address
32-bit Destination IP Address
Options (if any)
Payload
26
SourceAddress:WhatifSourceLies?• Sourceaddressshouldbethesendinghost
– But,who’schecking,anyway?– Youcouldsendpacketswithanysourceyouwant
• Whywouldsomeonewanttodothis?– Launchadenial‐of‐servicea@ack
• SendexcessivepacketstothedesQnaQon• …tooverloadthenode,orthelinksleadingtonode
– EvadedetecQonby“spoofing”• But,thevicQmcouldidenQfyyoubythesourceaddress• So,youcanputsomeoneelse’ssourceaddressinpackets
– Also,ana@ackagainstthespoofedhost• Spoofedhostiswronglyblamed• Spoofedhostmayreceivereturntrafficfromreceiver
27
HierarchicalAddressing:IPPrefixes• IPaddressescanbedividedintotwoporQons
– Network(lec)andhost(right)• 12.34.158.0/24isa24‐bitprefix
– Whichcovers28addresses(e.g.,upto255hosts)
28
00001100 00100010 10011110 00000101
Network (24 bits) Host (8 bits)
12 34 158 5
ClassfulAddressing• Intheoldendays,onlyfixedallocaQonsizes
– ClassA:0*• Verylarge/8blocks(e.g.,MIThas18.0.0.0/8)
– ClassB:10*• Large/16blocks(e.g,.Princetonhas128.112.0.0/16)
– ClassC:110*• Small/24blocks(e.g.,AT&TLabshas192.20.225.0/24)
– ClassD:1110*• MulQcastgroups
– ClassE:11110*• Reservedforfutureuse
• Thisiswhyfolksusedo@ed‐quadnotaQon!
29
CIDR:HierarchalAddressAllocaQon30
12.0.0.0/8
12.0.0.0/16
12.254.0.0/16
12.1.0.0/16 12.2.0.0/16 12.3.0.0/16
: : :
12.3.0.0/24 12.3.1.0/24
: :
12.3.254.0/24
12.253.0.0/19 12.253.32.0/19 12.253.64.0/19 12.253.96.0/19 12.253.128.0/19 12.253.160.0/19
: : :
• Prefixes are key to Internet scalability – Address allocated in contiguous chunks (prefixes) – Routing protocols and packet forwarding based on prefixes – Today, routing tables contain ~200,000 prefixes (vs. 4B)
Twotypesofaddresses• Providerindependent(fromIANA)
• Providerallocated(fromupstreamISP)
• ProviderallocatedaddressesseemtooffermorepotenQalforaggregaQon(andreducingrouQngtablesize),butnotalwaysso…
31
Scalability:AddressAggregaQon32
Provider is given 201.10.0.0/21
201.10.0.0/22 201.10.4.0/24 201.10.5.0/24 201.10.6.0/23
Provider
RoutersinrestofInternetjustneedtoknowhowtoreach201.10.0.0/21.ProvidercandirectIPpackets
toappropriatecustomer.
But,AggregaQonNotAlwaysPossible33
201.10.0.0/21
201.10.0.0/22 201.10.4.0/24 201.10.5.0/24 201.10.6.0/23
Provider 1 Provider 2
Mul7‐homedcustomer(201.10.6.0/23)hastwoproviders.OtherpartsoftheInternetneedtoknow
howtoreachthesedesQnaQonsthroughbothproviders.
CIDRMakesPacketForwardingHarder• Forwardingtablemayhavemanymatches
– E.g.,entriesfor201.10.0.0/21and201.10.6.0/23– TheIPaddress201.10.6.17wouldmatchboth!
– UseLongestPrefixMatching
• CanleadtorouQngtableexpansion– TosaQfyLPM,needtoannounce/23fromboth1and2
34
201.10.0.0/21
201.10.0.0/22 201.10.4.0/24 201.10.5.0/24 201.10.6.0/23
Provider 1 Provider 2
Internet‐wideInternetRouQng• AS‐leveltopology
– DesQnaQonsareIPprefixes(e.g.,12.0.0.0/8)– NodesareAutonomousSystems(ASes)– EdgesarelinksandbusinessrelaQonships
35
1
2
3 4
5
6 7
Client Web server
Middleboxes• Middleboxesareintermediaries
– Interposedin‐betweenthecommunicaQnghosts
– OcenwithoutknowledgeofoneorbothparQes
• Myriaduses– Networkaddresstranslators– Firewalls– Tunnelendpoints– Trafficshapers
– IntrusiondetecQonsystems
– TransparentWebproxycaches
– ApplicaQonaccelerators
36
“AnabominaQon!”– ViolaQonoflayering– Hardtoreasonabout– Responsibleforsubtlebugs
“ApracQcalnecessity!”– Solvereal/pressingproblems
– Needsnotlikelytogoaway
Port‐TranslaQngNAT
• Mapoutgoingpackets– ReplacesourceaddresswithNATaddress– Replacesourceportnumberwithanewportnumber
– Remotehostsrespondusing(NATaddress,newport#)
• MaintainatranslaQontable– Storemapof(srcaddr,port#)to(NATaddr,newport#)
• Mapincomingpackets– ConsultthetranslaQontable– MapthedesQnaQonaddressandportnumber
– Localhostreceivestheincomingpacket
37
TransportLayer
38
TwoBasicTransportFeatures• Demul0plexing:portnumbers
• Errordetec0on:checksums
39
Web server (port 80)
Client host
Server host 128.2.194.242
Echo server (port 7)
Service request for 128.2.194.242:80
(i.e., the Web server) OS Client
IP payload
detect corruption
UserDatagramProtocol(UDP)• Datagrammessagingservice
– DemulQplexingofmessages:portnumbers– DetecQngcorruptedmessages:checksum
• LightweightcommunicaQonbetweenprocesses– Sendmessagestoandreceivethemfromasocket
– Avoidoverheadanddelaysofordered,reliabledelivery
40
SRC port DST port
checksum length
DATA
TransmissionControlProtocol(TCP)• Stream‐of‐bytesservice
– Sendsandreceivesastreamofbytes,notmessages
• Reliable,in‐orderdelivery– Checksumstodetectcorrupteddata– Sequencenumberstodetectlossesandreorderdata– Acknowledgments&retransmissionsforreliabledelivery
• ConnecQonoriented– Explicitset‐upandtear‐downofTCPsession
• Flowcontrol– Preventoverflowofthereceiver’sbufferspace
• CongesQoncontrol– AdapttonetworkcongesQonforthegreatergood
41
EstablishingaTCPConnecQon
• Three‐wayhandshaketoestablishconnecQon– HostAsendsaSYNchronize(open)tothehostB– HostBreturnsaSYNACKnowledgment(SYNACK)– HostAsendsanACKtoacknowledgetheSYNACK
42
SYN
SYN ACK
ACK Data
A B
Data
Each host tells its ISN to the other host.
TCP“StreamofBytes”Service43
Byte 0
Byte 1
Byte 2
Byte 3
Byte 0
Byte 1
Byte 2
Byte 3
Host A
Host B
Byte 80
Byte 80
…EmulatedUsingTCP“Segments”44
Byte 0
Byte 1
Byte 2
Byte 3
Byte 0
Byte 1
Byte 2
Byte 3
Host A
Host B
Byte 80
TCP Data
TCP Data
Byte 80
Segmentsentwhen:1. Segmentfull(MaxSegmentSize),2. Notfull,butQmesout,or3. “Pushed”byapplicaQon.
Reliability:TCPAcknowledgments45
Host A
Host B
TCP Data
TCP Data
TCP HDR
TCP HDR
ISN (initial sequence number)
Sequence number = 1st byte
ACK sequence number = next expected byte
DetecQnglosses46
Packet
Tim
eout
Packet
ACK
Tim
eout
Packet
Tim
eout
Packet
ACK
Tim
eout
Packet
ACK
Tim
eout
Packet
ACK
Tim
eout
ACK lost DUPLICATE
PACKET
Packet lost Early timeout DUPLICATE PACKETS
Flowcontrol:Slidingwindow• Allowalargeramountofdata“inflight”
– Allowsendertogetaheadofthereceiver– …thoughnottoofarahead
47
Sending process Receiving process
Last byte ACKed
Last byte sent
TCP TCP
Next byte expected
Last byte written Last byte read
Last byte received
WhereCongesQonHappens:Links• SimpleresourceallocaQon:FIFOqueue&drop‐tail
• Accesstothebandwidth:first‐infirst‐outqueue– Packetstransmi@edintheordertheyarrive
• Accesstothebufferspace:drop‐tailqueuing– Ifthequeueisfull,droptheincomingpacket
48
TCPCongesQonWindow• EachTCPsendermaintainsacongesQonwindow
– Maximumnumberofbytestohaveintransit– I.e.,numberofbytessQllawaiQngacknowledgments
• AdapQngthecongesQonwindow– Decreaseuponlosingapacket:backingoff– Increaseuponsuccess:opQmisQcallyexploring– Alwaysstrugglingtofindtherighttransferrate
• Bothgoodandbad– Pro:avoidshavingexplicitfeedbackfromnetwork– Con:under‐shooQngandover‐shooQngtherate
49
LeadstotheTCP“Sawtooth”50
t
Window
halved
Loss
But, could take a long time to get started!
SlowStartandtheTCPSawtooth51
t
Window
halved
Loss
Exponential “slow start”
Duplicate ACK
RepeaQngSlowStartAcerTimeout52
t
Window
halved
Loss
Slow start in operation until it reaches half of
previous cwnd.
Timeout
Extensions
• TaildropinroutersleadtoburstylossandsynchronizaQonofsenders– LedtoRandomEarlyDetecQon(RED)
• Packetsdroppedandretransmissionwhenunnecessary– LedtoExplicitCongesQonNoQficaQon(ECN)
53
Problemswithtaildrop• UnderstablecondiQons,queuealmostalwaysfull– Leadstohighlatencyforalltraffic
• Possiblyunfairforflowswithsmallwindows– Largerflowsmayfastretransmit(detecQnglossthroughTripDupACKs),smallflowsmayhavetowaitforQmeout
• WindowsynchronizaQon– Moreonthislater…
54
✗
FairQueuing(FQ)• Maintainsseparatequeueperflow
• Ensuresnoflowconsumesmorethanits1/nshare– VariaQon:weightedfairqueuing(WFQ)
• Ifallpacketsweresamelength,wouldbeeasy
• Ifnon‐work‐conserving(resourcescangoidle),alsowouldbeeasy,yetloweruQlizaQon
55
RoundRobinService
Egress Link
Flow 1
Flow 2
Flow 3
Flow 4
FairQueuingBasics
• TrackhowmuchQmeeachflowhasusedlink
– ComputeQmeusedifittransmitsnextpacket
• Sendpacketfromflowthatwillhavelowestuseifittransmits– Whynotflowwithsmallestusesofar?
– Becausenextpacketmaybehuge!
56
FQAlgorithm• ImagineclockQckperbit,thentxQme~length
FinishQmeFi=max(Fi‐1,ArriveQmeAi)+LengthPi
• CalculateesQmatedFiforallqueuedpackets
• TransmitpacketwithlowestFinext
57
FQAlgorithm(2)• Problem:Can’tpreemptcurrenttxpacket
• Result:InacQveflows(Ai>Fi‐1)arepenalized– Standardalgorithmconsidersnohistory
– Eachflowgetsfairshareonlywhenpacketsqueued
58
FQAlgorithm(3)
• Approach:givemorepromptnesstoflowsuQlizinglessbandwidthhistorically
• BidBi=max(Fi‐1,Ai–δ)+Pi– IntuiQon:withlargerδ,schedulingdecisionscalculatedbylasttxQmeFi‐1morefrequently,thuspreferringslowerflows
• FQachievesmax‐minfairness– Firstpriority:maximizetheminimumrateofanyacQveflows
– Secondpriority:maximizethesecondminrate,etc.
59
Usesof(W)FQ• Scalability
– #queuesmustbeequalto#flows
– But,canbeusedonedgerouters,lowspeedlinks,orsharedendhosts
• (W)FQcanbeforclassesoftraffic,notjustflows– UseIPTOSbitstomark“importance”
– Partof“DifferenQatedServices”architecturefor“Quality‐of‐Service”(QoS)
60
BurstyLossFromDrop‐TailQueuing
• TCPdependsonpacketloss– PacketlossisindicaQonofcongesQon– AndTCPdrivesnetworkintolossbyaddiQverateincrease
• Drop‐tailqueuingleadstoburstyloss– Iflinkiscongested,manypacketsencounterfullqueue– Thus,losssynchronizaQon:
• Manyflowsloseoneormorepackets• Inresponse,manyflowsdividesendingrateinhalf
61
SlowFeedbackfromDropTail• Feedbackcomeswhenbufferiscompletelyfull
– …eventhoughthebufferhasbeenfillingforawhile
• Plus,thefillingbufferisincreasingRTT– …makingdetecQonevenslower
• Mightbebe@ertogiveearlyfeedback– Andget1‐2connecQonstoslowdownbeforeit’stoolate
62
RandomEarlyDetecQon(RED)• BasicideaofRED
– RouternoQcesthatqueueisgeangbacklogged– …andrandomlydropspacketstosignalcongesQon
• Packetdropprobability– Dropprobabilityincreasesasqueuelengthincreases– Else,setdropprobabilityasfuncQonofavgqueuelengthandQmesincelastdrop
63
Average Queue Length
Dro
p Pr
obab
ility
0
1
ProperQesofRED• Dropspacketsbeforequeueisfull
– Inthehopeofreducingtheratesofsomeflows
• DropspacketinproporQontoeachflow’srate– High‐rateflowshavemorepackets– …and,hence,ahigherchanceofbeingselected
• DropsarespacedoutinQme– WhichshouldhelpdesynchronizetheTCPsenders
• TolerantofbursQnessinthetraffic– Bybasingthedecisionsonaveragequeuelength
64
ProblemsWithRED• Hardtogettunableparametersjustright
– Howearlytostartdroppingpackets?– Whatslopeforincreaseindropprobability?– WhatQmescaleforaveragingqueuelength?
• REDhasmixedadopQoninpracQce– Ifparametersaren’tsetright,REDdoesn’thelp– Hardtoknowhowtosettheparameters
• ManyothervariaQonsinresearchcommunity– Nameslike“Blue”(self‐tuning),“FRED”…
65
Feedback:FromlosstonoQficaQon
• Earlydroppingofpackets– Good:givesearlyfeedback– Bad:hastodropthepackettogivethefeedback
• ExplicitCongesQonNoQficaQon– RoutermarksthepacketwithanECNbit– SendinghostinterpretsasasignofcongesQon
66
ExplicitCongesQonNoQficaQon• Mustbesupportedbyrouter,sender,ANDreceiver
– End‐hostsdetermineifECN‐capableduringTCPhandshake
• ECNinvolvesallthreeparQes(and4headerbits)1. Sendermarks“ECN‐capable”whensending
2. Ifroutersees“ECN‐capable”andexperiencingcongesQon,routermarkspacketas“ECNcongesQonexperienced”
3. Ifreceiversees“congesQonexperienced”,marks“ECNecho”flaginresponsesunQlcongesQonACK’d
4. Ifsendersees“ECNecho”,reducescwndandmarks“congesQonwindowreduced”flaginnextTCPpacket
• WhyextraECNflag?CongesQoncouldhappenineitherdirecQon,wantsendertoreacttoforwarddirecQon
• WhyCRWACK?ECN‐echocouldbelost,butweideallyonlyrespondtocongesQoninforwarddirecQon
67
ApplicaQonlayer
DNSHTTPandCDNs
P2PandDHTs
68
ThreeHierarchicalAssignmentProcesses
• Hostname:www.cs.princeton.edu– Domain:registrarforeachtop‐leveldomain(e.g.,.edu)– Hostname:localadministratorassignstoeachhost
• IPaddresses:128.112.7.156– Prefixes:ICANN,regionalInternetregistries,andISPs– Hosts:staQcconfiguraQon,ordynamicusingDHCP
• MACaddresses:00‐15‐C5‐49‐04‐A9– Blocks:assignedtovendorsbytheIEEE– Adapters:assignedbythevendorfromitsblock
69
MappingBetweenIdenQfiers• DomainNameSystem(DNS)
– Givenahostname,providetheIPaddress– GivenanIPaddress,providethehostname
• DynamicHostConfiguraQonProtocol(DHCP)– GivenaMACaddress,assignauniqueIPaddress– …andtellhostotherstuffabouttheLocalAreaNetwork– Toautomatetheboot‐strappingprocess
• AddressResoluQonProtocol(ARP)– GivenanIPaddress,providetheMACaddress– ToenablecommunicaQonwithintheLocalAreaNetwork
DHCPandARPuseL2broadcast….DNSisapp‐layerprotocol
70
Recursivevs.IteraQveQueries• Recursivequery
– Askservertogetanswerforyou
– E.g.,request1andresponse8
• IteraQvequery– Askserverwhotoasknext
– E.g.,allotherrequest‐responsepairs
71
requesting host cis.poly.edu
root DNS server
local DNS server dns.poly.edu
1
2 3
4 5
6
authoritative DNS server dns.cs.umass.edu
7 8
TLD DNS server
Onepage,lotsofobjects
• DynamicHTML: 19.6KB
• StaQccontent: 6.2MB• 1flashmovie• 18images
• 5stylesheets• 3scripts
TCPInteracQon:ShortTransfers• MulQpleconnecQonsetups
– Three‐wayhandshakeeachQme
• Round‐tripQmeesQmaQon– MaybelargeatthestartofaconnecQon(e.g.,3seconds)– LeadstolatencyindetecQnglostpackets
• CongesQonwindow– SmallvalueatbeginningofconnecQon(e.g.,1MSS)– Maynotreachahighvaluebeforetransferisdone
• DetecQngpacketloss– Timeout:slow– DuplicateACK
• Requiresmanypacketsinflight• Whichdoesn’thappenforveryshorttransfers 73
PersistentHTTPNon‐persistentHTTPissues:• Requires2RTTsperobject• OSmustallocateresources
foreachTCPconnecQon
• ButbrowsersocenopenparallelTCPconnecQonstofetchreferencedobjects
PersistentHTTP:• ServerleavesconnecQon
openacersendingresponse
• SubsequentHTTPmessagesbetweensameclient/serveraresentoverconnecQon
Persistentwithoutpipelining:• Clientissuesnewrequestonly
whenpreviousresponsehasbeenreceived
• OneRTTforeachobject
Persistentwithpipelining:• DefaultinHTTP/1.1
• Clientsendsrequestsassoonasitencountersreferencedobject
• Asli@leasoneRTTforallthereferencedobjects
74
