1 / 61

TODO

TODO. Intro to Application Level Protocols Two specific application level protocols 1 that uses TCP - HTTP 1 that uses UDP - DNS HTTP, 1.0 vs 1.1, telnet examples DNS, Bind IP addresses RIPE, APNIC, ARIN US Govt, Network solutions Needs of different applications. Internet protocol stack.

oshin
Télécharger la présentation

TODO

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. TODO • Intro to Application Level Protocols • Two specific application level protocols • 1 that uses TCP - HTTP • 1 that uses UDP - DNS • HTTP, 1.0 vs 1.1, telnet examples • DNS, Bind • IP addresses • RIPE, APNIC, ARIN • US Govt, Network solutions • Needs of different applications 2: Application Layer

  2. Internet protocol stack users network Application HTTP, SMTP, FTP, TELNET, DNS, … Transport TCP, UDP. Network IP Physical Point-to-point links, LANs, radios, ... 2: Application Layer

  3. Protocol stack user X English user Y e-mail client e-mail server SMTP TCP server TCP server TCP IP server IP IP server IEEE 802.3 standard ethernet driver/card ethernet driver/card electric signals 2: Application Layer

  4. Network Applications Drive Network Design • Important to remember that network applications are the reason we care about building a network infrasturucture • Applications range from text based command line ones popular in the 1980s (like telnet, ftp, news, chat, etc) to multimedia applications (Web browsers, audio and video streaming, realtime videoconferencing, etc.) 2: Application Layer

  5. Application: communicating, distributed processes running in network hosts in “user space” exchange messages to implement app e.g., email, file transfer, the Web Application-layer protocols one “piece” of an app define messages exchanged by apps and actions taken user services provided by lower layer protocols application transport network data link physical application transport network data link physical application transport network data link physical Applications and application-layer protocols 2: Application Layer

  6. Typical network app has two pieces: client and server request reply application transport network data link physical application transport network data link physical Client-server paradigm Client: • initiates contact with server (“speaks first”) • typically requests service from server, • for Web, client is implemented in browser; for e-mail, in mail reader Server: • Running first (always?) • provides requested service to client e.g., Web server sends requested Web page, mail server delivers e-mail 2: Application Layer

  7. API: application programming interface defines interface between application and transport layer socket: Internet API two processes communicate by sending data into socket, reading data out of socket Q: how does a process “identify” the other process with which it wants to communicate? IP address of host running other process “port number” - allows receiving host to determine to which local process the message should be delivered How do clients and servers communicate? … more on this later. 2: Application Layer

  8. Sockets Specify Transport Services • Sockets define the interfaces between an application and the transport layer • Applications choose the type of transport layer by choosing the type of socket • UDP Sockets – called DatagramSocket in Java, SOCK_DGRAM in C • TCP Sockets – called Socket/ServerSocket in Java, SOCK_STREAM in C • Client and server agree on the type of socket, the server port number and the protocol 2: Application Layer

  9. Roadmap • We will look at two application level protocols • HTTP runs on TCP • DNS usually runs on UDP (sometimes on TCP) 2: Application Layer

  10. TCP service: connection-oriented: setup required between client, server reliable transport between sending and receiving process flow control: sender won’t overwhelm receiver congestion control: throttle sender when nework overloaded does not providing: timing, minimum bandwidth guarantees UDP service: unreliable data transfer between sending and receiving process does not provide: connection setup, reliability, flow control, congestion control, timing, or bandwidth guarantee Q: why bother? Why is there a UDP? Services provided by Internet transport protocols 2: Application Layer

  11. http: hypertext transfer protocol Web’s application layer protocol client/server model client: browser that requests, receives, “displays” Web objects server: Web server has access to storage containing a set of Web documents; sends copies in response to requests http1.0: RFC 1945 http1.1: RFC 2068 The Web: the http protocol http request PC running Explorer http response http request Server running NCSA Web server http response Mac running Navigator 2: Application Layer

  12. Uniform Resource Locator (URL) • protocol://authority:port/p/a/th/item_name?query • protocol = http • authority = server machine • Port = 80 by default • /p/a/th/item_name = specifies a file to be returned or possibly a program to be executed to produce the file to be returned 2: Application Layer

  13. http: TCP transport service: client initiates TCP connection (creates socket) to server, port 80 server accepts TCP connection from client http messages (application-layer protocol messages) exchanged between browser (http client) and Web server (http server) TCP connection closed http is “stateless” server maintains no information about past client requests The http protocol: more aside Protocols that maintain “state” are complex! • past history (state) must be maintained • if server/client crashes, their views of “state” may be inconsistent, must be reconciled 2: Application Layer

  14. Suppose user enters URL www.someSchool.edu/someDepartment/home.index 1a. http client initiates TCP connection to http server (process) at www.someSchool.edu. Port 80 is default for http server. http example (contains text, references to 10 jpeg images) 1b.http server at host www.someSchool.edu waiting for TCP connection at port 80. “accepts” connection, notifying client 2.http client sends http request message (containing URL) into TCP connection socket 3.http server receives request message, forms response message containing requested object (someDepartment/home.index), sends message into socket time 2: Application Layer

  15. 5. http client receives response message containing html file, displays html. Parsing html file, finds 10 referenced jpeg objects http example (cont.) 4.http server closes TCP connection. 6.Steps 1-5 repeated for each of 10 jpeg objects time 2: Application Layer

  16. http message format: request • two types of http messages: request, response • http request message: • ASCII (human-readable format) request line (GET, POST, HEAD commands) GET /somedir/page.html HTTP/1.0 User-agent: Mozilla/4.0 Accept: text/html, image/gif,image/jpeg Accept-language:fr (extra carriage return, line feed) header lines Carriage return, line feed indicates end of message 2: Application Layer

  17. http request message: general format 2: Application Layer

  18. http message format: response status line (protocol status code status phrase) HTTP/1.0 200 OK Date: 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 ... header lines data, e.g., requested html file 2: Application Layer

  19. 200 OK request succeeded, requested object later in this message 301 Moved Permanently requested object moved, new location specified later in this message (Location:) 400 Bad Request request message not understood by server 404 Not Found requested document not found on this server 505 HTTP Version Not Supported http response status codes In first line in server->client response message. A few sample codes: 2: Application Layer

  20. HTML overview • Markup language give general layout guidelines - not exact placement or format- so browsers may display the same document differently • Free form (i.e. Spaces don’t matter) • Embedded tags give guidelines • Tags often appear in pairs • beginning <TAGNAME> • ending </TAGNAME> 2: Application Layer

  21. HTTP vs HTML • HTML format is highly specified but is just considered the data or body of an HTTP message • HTML is not part of the HTTP protocol • Example of layering: each layer speaks to a peer layer in an agreed upon language or protocol • In this case, both are processed by the web browser. The web broswer is both an HTTP client and an HTML parser. 2: Application Layer

  22. Static vs Dynamic vs Active Web Pages • Static: Stored in a file and unchanging • Dynamic: Formed by server on demand in response to a request • Output from a program (e.g. Common Gateway Interface (CGI) ) • Active: Executed at the client! • Computer program (not just output) that can interact with user (e.g. Java applet) 2: Application Layer

  23. Non-persistent HTTP/1.0 server parses request, responds, and closes TCP connection 2 RTTs to fetch each object Each object transfer suffers from slow start Persistent default for HTTP/1.1 on same TCP connection: server, parses request, responds, parses new request,.. Client sends requests for all referenced objects as soon as it receives base HTML. Fewer RTTs and less slow start. Non-persistent and persistent connections But most 1.0 browsers use parallel TCP connections. Do 1.1 browsers do this?  2: Application Layer

  24. Features in HTTP 1.1 • Persistent Connections • Hostname Identification • Allows one physical web server to serve content for multiple logical servers • Content Negotiation • Allows client to request a specific version of a resource • Chunked Transfers • For dynamic content, server needn’t specify all characteristics like size ahead of time • Byte Ranges • Clients can ask for small pieces of documents • Support for Proxies and Caches 2: Application Layer

  25. 1. Telnet to your favorite Web server: Trying out http (client side) for yourself Opens TCP connection to port 80 (default http server port) at www.eurecom.fr. Anything typed in sent to port 80 at www.eurecom.fr telnet www.eurecom.fr 80 2. Type in a GET http request: By typing this in (hit carriage return twice), you send this minimal (but complete) GET request to http server GET /~ross/index.html HTTP/1.0 3. Look at response message sent by http server! 2: Application Layer

  26. Authentication goal: control access to server documents stateless: client must present authorization in each request authorization: typically name, password authorization: header line in request if no authorization presented, server refuses access, sends WWW authenticate: header line in response usual http request msg + Authorization:line usual http request msg + Authorization:line usual http response msg usual http response msg time User-server interaction: authentication server client usual http request msg 401: authorization req. WWW authenticate: Browser caches name & password so that user does not have to repeatedly enter it. 2: Application Layer

  27. server sends “cookie” to client in response mst Set-cookie: 1678453 client presents cookie in later requests cookie: 1678453 server matches presented-cookie with server-stored info authentication remembering user preferences, previous choices usual http request msg cookie: # usual http request msg cookie: # usual http response msg usual http response msg User-server interaction: cookies server client usual http request msg usual http response + Set-cookie: # cookie- spectific action cookie- spectific action 2: Application Layer

  28. Goal: don’t send object if client has up-to-date stored (cached) version client: specify date of cached copy in http request If-modified-since: <date> server: response contains no object if cached copy up-to-date: HTTP/1.0 304 Not Modified http response HTTP/1.0 304 Not Modified User-server interaction: conditional GET server client http request msg If-modified-since: <date> object not modified http request msg If-modified-since: <date> object modified http response HTTP/1.1 200 OK … <data> 2: Application Layer

  29. user sets browser: Web accesses via web cache client sends all http requests to web cache if object at web cache, web cache immediately returns object in http response else requests object from origin server, then returns http response to client Web Caches (proxy server) Goal: satisfy client request without involving origin server origin server Proxy server http request http request client http response http response http request http request http response http response client origin server 2: Application Layer

  30. Assume: cache is “close” to client (e.g., in same network) smaller response time: cache “closer” to client decrease traffic to distant servers link out of institutional/local ISP network often bottleneck Why Web Caching? origin servers public Internet 1.5 Mbps access link institutional network 100 Mbps LAN institutional cache 2: Application Layer

  31. People: many identifiers: SSN, name, Passport # Internet hosts, routers: IP address (32 bit) - used for addressing datagrams “name”, e.g., gaia.cs.umass.edu - used by humans Q: map between IP addresses and name ? Domain Name System: distributed database implemented in hierarchy of many name servers application-layer protocol host, routers, name servers to communicate to resolvenames (address/name translation) note: core Internet function implemented as application-layer protocol complexity at network’s “edge” DNS: Domain Name System 2: Application Layer

  32. Names and addresses:why both? • Name: www.cs.cornell.edu • IP address: 128.84.154.132 • (Also Ethernet or other link-layer addresses.) • IP addresses are fixed-size numbers. • 32 bits. 128.153.4.24 = 10000000.10001111.00000100.00001110 • Names are memorizable, flexible: • Variable-length • Many names for a single IP address. • Change address doesn’t imply change name. • iPv6 addresses are 128 bit – even harder to memorize! 2: Application Layer

  33. Mapping Not 1 to 1 • One name may map to more than one IP address • IP addresses are per network interface • Multihomed machines have more than one network interface - each with its own IP address • Example: routers must be like this • One IP address may map to more than one name • One server machine may be the web server (www.foo,com), mail server (mail.foo.com)etc. 2: Application Layer

  34. How to get names and numbers? • Acquistion of Names and numbers are both regulated • Why? 2: Application Layer

  35. How to get a name? • First, get a domain name then you are free to assign sub names in that domain • How to get a domain name coming up • Before you ask for a domain name though • Should understand domain name structure… • Know that you are responsible for providing authoritative DNS server (actually a primary and one or more secondary DNS servers) for that domain and registration information through “whois” 2: Application Layer

  36. Domain name structure root (unnamed) ... ... com edu gov mil net org fr gr us uk ccTLDs gTLDs lucent cornell ustreas second level (sub-)domains gTLDs= Generic Top Level Domains ccTLDs = Country Code Top Level Domains 2: Application Layer

  37. Top-level Domains (TLDs) • Generic Top Level Domains (gTLDs) • .com - commercial organizations • .org - not-for-profit organizations • .edu - educational organizations • .mil - military organizations • .gov - governmental organizations • .net - network service providers • New: .biz, .info, .name, … • Country code Top Level Domains (ccTLDs) • One for each country 2: Application Layer

  38. How to get a domain name? • In 1998, non-profit corporation, Internet Corporation for Assigned Names and Numbers (ICANN), was formed to assume responsibility from the US Government • ICANN authorizes other companies to register domains in com, org and net and new gTLDs • Network Solutions is largest and in transitional period between US Govt and ICANN had sole authority to register domains in com, org and net 2: Application Layer

  39. How to get an IP Address? • Answer 1: Normally, answer is get an IP address from your upstream provider • This is essential to maintain efficient routing! • Answer 2: If you need lots of IP addresses then you can acquire your own block of them. • IP address space is a scarce resource - must prove you have fully utilized a small block before can ask for a larger one and pay $$ (Jan 2002 - $2250/year for /20 and $18000/year for a /14) 2: Application Layer

  40. How to get lots of IP Addresses? Internet Registries RIPE NCC (Riseaux IP Europiens Network Coordination Centre) for Europe, Middle-East, Africa APNIC (Asia Pacific Network Information Centre )for Asia and Pacific ARIN(American Registry for Internet Numbers) for the Americas, the Caribbean, sub-saharan Africa Note: Once again regional distribution is important for efficient routing! Can also get Autonomous System Numnbers (ASNs from these registries 2: Application Layer

  41. Checkpoint • Now you know both how to get a machine name and how to get an IP address • Now back to DNS – how to map from one to the other! 2: Application Layer

  42. People: many identifiers: SSN, name, Passport # Internet hosts, routers: IP address (32 bit) - used for addressing datagrams “name”, e.g., gaia.cs.umass.edu - used by humans Q: map between IP addresses and name ? Domain Name System: distributed database implemented in hierarchy of many name servers application-layer protocol host, routers, name servers to communicate to resolvenames (address/name translation) note: core Internet function implemented as application-layer protocol complexity at network’s “edge” DNS: Domain Name System 2: Application Layer

  43. Name server: process running on a host that processes DNS requests local name servers: each ISP, company has local (default) name server host DNS query first goes to local name server authoritative name server: can perform name/address translation for a specific domain or zone How could we provide this service? Why not centralize DNS? single point of failure traffic volume distant centralized database maintenance doesn’t scale! no server has all name-to-IP address mappings DNS name servers 2: Application Layer

  44. irs Zone: subtree with common administration authority. www Name Server Zone Structure root com gov edu mil net org fr gr us uk lucent Structure based on administrative issues. ustreas 2: Application Layer

  45. ustreas customs irs Root NS Ustreas NS IRS NS Lucent NS www Name Servers (NS) root com gov edu ... lucent cornell 2: Application Layer

  46. Name Servers (NS) • NSs are duplicated for reliability. • Each domain must have a primary and secondary. • Anonymous ftp from: • ftp.rs.internic.net, netinfo/root-server.txt • gives the current root NSs (about 10). • Each host knows the IP address of the local NS. • Each NS knows the IP addresses of all root NSs. 2: Application Layer

  47. contacted by local name server that can not resolve name root name server: Knows the authoritative name server for main domain ~ dozen root name servers worldwide DNS: Root name servers 2: Application Layer

  48. host surf.eurecom.fr wants IP address of gaia.cs.umass.edu 1. Contacts its local DNS server, dns.eurecom.fr 2.dns.eurecom.fr contacts root name server, if necessary 3. root name server contacts authoritative name server, dns.umass.edu, if necessary(what might be wrong with this?) local name server dns.eurecom.fr Simple DNS example root name server 2 4 3 5 authorititive name server dns.umass.edu 1 6 requesting host surf.eurecom.fr gaia.cs.umass.edu 2: Application Layer

  49. Root name server: may not know authoritative name server may know intermediate name server: who to contact to find authoritative name server local name server dns.eurecom.fr intermediate name server dns.umass.edu DNS example root name server 6 2 3 7 5 4 1 8 authoritative name server dns.cs.umass.edu requesting host surf.eurecom.fr gaia.cs.umass.edu 2: Application Layer

  50. recursive query: puts burden of name resolution on contacted name server heavy load? iterated query: contacted server replies with name of server to contact “I don’t know this name, but ask this server” Takes burden off root servers local name server dns.eurecom.fr intermediate name server dns.umass.edu DNS: iterated queries root name server iterated query 2 3 4 7 5 6 1 8 authoritative name server dns.cs.umass.edu requesting host surf.eurecom.fr gaia.cs.umass.edu 2: Application Layer

More Related