Slide 1Slide 2Slide 3Slide 4Slide 5Slide 6Slide 7Slide 8Slide 9Slide 10Slide 11Slide 12Slide 13Slide 14Slide 15Slide 16Slide 17Slide 18Slide 19Slide 20Slide 21Slide 22Slide 23Slide 24Slide 25Slide 26Slide 27Slide 28Slide 29Slide 30Slide 31Slide 32Slide 33Slide 34Slide 35Slide 36Slide 37Slide 38Slide 39Slide 40Slide 41Slide 42Slide 43Slide 44Slide 45Slide 46Slide 47Slide 48Slide 491Lecture 3Design Philosophy &ApplicationsDavid AndersenSchool of Computer ScienceCarnegie Mellon University15-441 Computer Networks2Lecture OverviewLast time:»Protocol stacks and layering»OSI and TCP/IP models»Application requirements from transport protocolsInternet ArchitectureApplication examples.»ftp»httpApplication requirements.»“ilities”»Sharing3Internet ArchitectureBackground»“The Design Philosophy of the DARPA Internet Protocols” (David Clark, 1988).Fundamental goal: Effective network interconnectionGoals, in order of priority:1. Continue despite loss of networks or gateways2. Support multiple types of communication service3. Accommodate a variety of networks»Permit distributed management of Internet resources»Cost effective»Host attachment should be easy»Resource accountability4PrioritiesThe effects of the order of items in that list are still felt today»E.g., resource accounting is a hard, current research topicLet’s look at them in detail5SurvivabilityIf network disrupted and reconfigured»Communicating entities should not care!»No higher-level state reconfiguration»Ergo, transport interface only knows “working” and “not working.” Not working == complete partition.How to achieve such reliability?»Where can communication state be stored?Network HostFailure handing Replication “Fate sharing”Net Engineering Tough SimpleSwitches Maintain state StatelessHost trust Less More6Fate SharingLose state information for an entity if (and only if?) the entity itself is lost.Examples:»OK to lose TCP state if one endpoint crashes–NOT okay to lose if an intermediate router reboots»Is this still true in today’s network?–NATs and firewallsSurvivability compromise: Heterogenous network -> less information available to end hosts and Internet level recovery mechanismsConnection State StateNo State7Types of ServiceRecall from last time TCP vs. UDP»Elastic apps that need reliability: remote login or email»Inelastic, loss-tolerant apps: real-time voice or video»Others in between, or with stronger requirements»Biggest cause of delay variation: reliable delivery–Today’s net: ~100ms RTT–Reliable delivery can add seconds.Original Internet model: “TCP/IP” one layer»First app was remote login…»But then came debugging, voice, etc.»These differences caused the layer split, added UDPNo QoS support assumed from below»In fact, some underlying nets only supported reliable delivery–Made Internet datagram service less useful!»Hard to implement without network support»QoS is an ongoing debate…8Varieties of NetworksDiscussed a lot of this last time - »Interconnect the ARPANET, X.25 networks, LANs, satellite networks, packet networks, serial links…Mininum set of assumptions for underlying net»Minimum packet size»Reasonable delivery odds, but not 100%»Some form of addressing unless point to pointImportant non-assumptions:»Perfect reliability»Broadcast, multicast»Priority handling of traffic»Internal knowledge of delays, speeds, failures, etc.Much engineering then only has to be done once9The “Other” goalsManagement»Today’s Internet is decentralized - BGP»Very coarse tools. Still in the “assembly language” stageCost effectiveness»Economies of scale won out»Internet cheaper than most dedicated networks»Packet overhead less important by the yearAttaching a host»Not awful; DHCP and related autoconfiguration technologies helping. A ways to go, but the path is thereBut…10AccountabilityHuge problem.Accounting»Billing? (mostly flat-rate. But phones are moving that way too - people like it!)»Inter-provider payments–Hornet’s nest. Complicated. Political. Hard.Accountability and security»Huge problem.»Worms, viruses, etc.–Partly a host problem. But hosts very trusted.»Authentication–Purely optional. Many philosophical issues of privacy vs. security.11FTP: The File Transfer ProtocolTransfer file to/from remote hostClient/server model»Client: side that initiates transfer (either to/from remote)»Server: remote hostftp: RFC 959ftp server: port 21file transferFTPserverFTPuserinterfaceFTPclientlocal filesystemremote filesystemuser at host12Ftp: Separate Control, Data ConnectionsFtp client contacts ftp server at port 21, specifying TCP as transport protocolTwo parallel TCP connections opened:»Control: exchange commands, responses between client, server.“out of band control”»Data: file data to/from serverFtp server maintains “state”: current directory, earlier authenticationFTPclientFTPserverTCP control connectionport 21TCP data connectionport 2013Ftp Commands, ResponsesSample Commands:sent as ASCII text over control channelUSER usernamePASS passwordLIST return list of files in current directoryRETR filename retrieves (gets) fileSTOR filename stores (puts) file onto remote hostSample Return Codesstatus code and phrase331 Username OK, password required125 data connection already open; transfer starting425 Can’t open data connection452 Error writing file14HTTP BasicsHTTP layered over bidirectional byte stream»Almost always TCPInteraction»Client sends request to server, followed by response from server to client»Requests/responses are encoded in textStateless»Server maintains no information about past client requests15How to Mark End of Message?Size of message Content-Length»Must know size of transfer in advanceDelimiter MIME style Content-Type»Server must “escape” delimiter in contentClose connection»Only server can do this16HTTP Request17HTTP RequestRequest line»Method–GET – return URI–HEAD – return headers only of GET response–POST – send data to the server (forms, etc.)»URI–E.g. http://www.intel-iris.net/index.html with a proxy–E.g. /index.html if no proxy»HTTP version18HTTP RequestRequest headers»Authorization – authentication info»Acceptable document types/encodings»From – user
View Full Document
Unlocking...