Chapter_2-SKJ1063.pdf

Chapter 2: Application Layer our goals: ▪ learn about protocols by ▪ conceptual, examining popular implementation aspects application-level of network application protocols protocols HTTP transport-layer FTP...

Chapter 2: Application Layer our goals: ▪ learn about protocols by ▪ conceptual, examining popular implementation aspects application-level of network application protocols protocols HTTP transport-layer FTP service models SMTP / POP3 / IMAP DNS client-server paradigm ▪ creating network applications peer-to-peer paradigm socket API content distribution networks SKJ1063 SEM II 2023/2024 2-3 Some network apps ▪ e-mail ▪ voice over IP (e.g., ▪ web Skype) ▪ text messaging ▪ real-time video ▪ remote login conferencing ▪ P2P file sharing ▪ social networking ▪ multi-user network ▪ search games ▪ … ▪ streaming stored ▪ … video (YouTube, Hulu, Netflix) SKJ1063 SEM II 2023/2024 2-4 Creating a network app application transport network data link physical write programs that: ▪ run on (different) end systems ▪ communicate over network ▪ e.g., web server software communicates with browser software no need to write software application transport network for network-core devices data link physical application transport network ▪ network-core devices do not data link physical run user applications ▪ applications on end systems allows for rapid app development, propagation SKJ1063 SEM II 2023/2024 2-5 Application Architectures Possible structure of applications: ▪ client-server ▪ peer-to-peer (P2P) SKJ1063 SEM II 2023/2024 2-6  Client-server Architecture server: ▪ always-on host ▪ permanent IP address ▪ data centers for scaling clients: ▪ communicate with server client/server ▪ may be intermittently connected ▪ may have dynamic IP addresses ▪ do not communicate directly with each other SKJ1063 SEM II 2023/2024 2-7 P2P Architecture ▪ no always-on server peer-peer ▪ arbitrary end systems directly communicate ▪ peers request service from other peers, provide service in return to other peers self scalability – new peers bring new service capacity, as well as new service demands ▪ peers are intermittently connected and change IP addresses complex management SKJ1063 SEM II 2023/2024 2-8 Processes Communicating process: program running clients, servers within a host client process: process that ▪ within same host, two initiates communication processes communicate server process: process that using inter-process waits to be contacted communication (defined by OS) ▪ processes in different hosts communicate by exchanging ▪ aside: applications with P2P messages architectures have client processes & server processes SKJ1063 SEM II 2023/2024 2-9 Sockets ▪ process sends/receives messages to/from its socket ▪ socket analogous to door sending process shoves message out door sending process relies on transport infrastructure on other side of door to deliver message to socket at receiving process application application socket controlled by process process app developer transport transport network network controlled link by OS link Internet physical physical SKJ1063 SEM II 2023/2024 2-10 Addressing Processes ▪ to receive messages, ▪ identifier includes both IP process must have identifier address and port numbers ▪ host device has unique 32- associated with process on bit IP address host. ▪ Q: does IP address of host ▪ example port numbers: on which process runs HTTP server: 80 suffice for identifying the mail server: 25 process? ▪ to send HTTP message to ▪ A: no, many processes gaia.cs.umass.edu web can be running on same server: host IP address: 128.119.245.12 port number: 80 ▪ more shortly… SKJ1063 SEM II 2023/2024 2-11 App-layer protocol defines ▪ types of messages open protocols: exchanged, ▪ defined in RFCs e.g., request, response ▪ allows for interoperability ▪ message syntax: ▪ e.g., HTTP, SMTP what fields in messages proprietary protocols: & how fields are delineated ▪ e.g., Skype ▪ message semantics meaning of information in fields ▪ rules for when and how processes send & respond to messages SKJ1063 SEM II 2023/2024 2-12 What transport service does an app need? data integrity throughput ▪ some apps (e.g., file transfer, ▪ some apps (e.g., web transactions) require multimedia) require 100% reliable data transfer minimum amount of ▪ other apps (e.g., audio) can throughput to be tolerate some loss “effective” ▪ other apps (“elastic apps”) timing make use of whatever ▪ some apps (e.g., Internet throughput they get telephony, interactive security games) require low delay ▪ encryption, data integrity, to be “effective” … SKJ1063 SEM II 2023/2024 2-13  Transport service requirements: common apps application data loss throughput time sensitive file transfer no loss elastic no e-mail no loss elastic no Web documents no loss elastic no real-time audio/video loss-tolerant audio: 5kbps-1Mbps yes, 100’s video:10kbps-5Mbps msec stored audio/video loss-tolerant same as above interactive games loss-tolerant few kbps up yes, few secs text messaging no loss elastic yes, 100’s msec yes and no SKJ1063 SEM II 2023/2024 2-14 Internet transport protocols services TCP service: UDP service: ▪ reliable transport between ▪ unreliable data transfer sending and receiving between sending and process receiving process ▪ flow control: sender won’t ▪ does not provide: reliability, overwhelm receiver flow control, congestion ▪ congestion control: throttle control, timing, sender when network throughput guarantee, overloaded security, or connection ▪ does not provide: timing, setup, minimum throughput guarantee, security Q: why bother? Why is ▪ connection-oriented: setup there a UDP? required between client and server processes SKJ1063 SEM II 2023/2024 2-15 Internet apps: application, transport protocols application underlying application layer protocol transport protocol e-mail SMTP [RFC 2821] TCP remote terminal access Telnet [RFC 854] TCP Web HTTP [RFC 2616] TCP file transfer FTP [RFC 959] TCP streaming multimedia HTTP (e.g., YouTube), TCP or UDP RTP [RFC 1889] Internet telephony SIP, RTP, proprietary (e.g., Skype) TCP or UDP SKJ1063 SEM II 2023/2024 2-16 Securing TCP TCP & UDP SSL is at app layer ▪ no encryption ▪ apps use SSL libraries, that ▪ cleartext passwds sent into “talk” to TCP socket traverse Internet in SSL socket API cleartext ▪ cleartext passwords sent SSL into socket traverse ▪ provides encrypted TCP Internet encrypted connection ▪ see Chapter 8 ▪ data integrity ▪ end-point authentication SKJ1063 SEM II 2023/2024 2-17 Chapter 2: outline 2.1 principles of network 2.5 P2P applications applications 2.6 video streaming and 2.2 Web and HTTP content distribution 2.3 electronic mail networks SMTP, POP3, IMAP 2.7 socket programming 2.4 DNS with UDP and TCP SKJ1063 SEM II 2023/2024 2-18 Web and HTTP First, a review… ▪ web page consists of objects ▪ object can be HTML file, JPEG image, Java applet, audio file,… ▪ web page consists of base HTML-file which includes several referenced objects ▪ each object is addressable by a URL, e.g., www.someschool.edu/someDept/pic.gif host name path name SKJ1063 SEM II 2023/2024 2-19 HTTP overview HTTP: hypertext transfer protocol ▪ Web’s application layer protocol PC running Firefox browser ▪ client/server model client: browser that requests, receives, (using HTTP protocol) server and “displays” Web running objects Apache Web server: Web server server sends (using HTTP protocol) objects in iPhone running response to requests Safari browser SKJ1063 SEM II 2023/2024 2-20 HTTP overview (continued) uses TCP: HTTP is “stateless” ▪ client initiates TCP ▪ server maintains no connection (creates socket) information about to server, port 80 past client requests ▪ server accepts TCP connection from client aside ▪ HTTP messages protocols that maintain (application-layer protocol “state” are complex! messages) exchanged ▪ past history (state) must be between browser (HTTP maintained client) and Web server ▪ if server/client crashes, their (HTTP server) views of “state” may be inconsistent, must be ▪ TCP connection closed reconciled SKJ1063 SEM II 2023/2024 2-21 HTTP connections non-persistent HTTP persistent HTTP ▪ at most one object ▪ multiple objects can sent over TCP be sent over single connection TCP connection connection then between client, server closed ▪ downloading multiple objects required multiple connections SKJ1063 SEM II 2023/2024 2-22  Non-persistent HTTP suppose user enters URL: (contains text, www.someSchool.edu/someDepartment/home.index references to 10 jpeg images) 1a. HTTP client initiates TCP connection to HTTP server (process) at 1b. HTTP server at host www.someSchool.edu on port www.someSchool.edu waiting 80 for TCP connection at port 80. “accepts” connection, notifying 2. HTTP client sends HTTP request client message (containing URL) into TCP connection socket. 3. HTTP server receives request Message indicates that client message, forms response wants object message containing requested someDepartment/home.index object, and sends message into its socket time SKJ1063 SEM II 2023/2024 2-23  Non-persistent HTTP (cont.) 4. HTTP server closes TCP connection. 5. HTTP client receives response message containing html file, displays html. Parsing html file, finds 10 referenced jpeg objects time 6. Steps 1-5 repeated for each of 10 jpeg objects SKJ1063 SEM II 2023/2024 2-24 Non-persistent HTTP: response time RTT (definition): time for a small packet to travel from client to server and back HTTP response time: initiate TCP connection ▪ one RTT to initiate TCP connection RTT request ▪ one RTT for HTTP request file and first few bytes of HTTP RTT time to response to return transmit file ▪ file transmission time file received ▪ non-persistent HTTP response time = time time 2RTT+ file transmission time SKJ1063 SEM II 2023/2024 2-25 Persistent HTTP non-persistent HTTP issues: persistent HTTP: ▪ requires 2 RTTs per object ▪ server leaves connection ▪ OS overhead for each TCP open after sending connection response ▪ browsers often open ▪ subsequent HTTP parallel TCP connections to messages between same fetch referenced objects client/server sent over open connection ▪ client sends requests as soon as it encounters a referenced object ▪ as little as one RTT for all the referenced objects SKJ1063 SEM II 2023/2024 2-26  HTTP request message ▪ two types of HTTP messages: request, response ▪ HTTP request message: ASCII (human-readable format) carriage return character line-feed character request line (GET, POST, GET /index.html HTTP/1.1\r\n HEAD commands) Host: www-net.cs.umass.edu\r\n User-Agent: Firefox/3.6.10\r\n Accept: text/html,application/xhtml+xml\r\n header Accept-Language: en-us,en;q=0.5\r\n lines Accept-Encoding: gzip,deflate\r\n carriage return, Accept-Charset: ISO-8859-1,utf-8;q=0.7\r\n line feed at start Keep-Alive: 115\r\n Connection: keep-alive\r\n of line indicates \r\n end of header lines * Check out the online interactive exercises for more examples: http://gaia.cs.umass.edu/kurose_ross/interactive/ SKJ1063 SEM II 2023/2024 2-27 HTTP request message: general format method sp URL sp version cr lf request line header field name value cr lf header ~ ~ ~ ~ lines header field name value cr lf cr lf ~ ~ entity body ~ ~ body SKJ1063 SEM II 2023/2024 2-28 Uploading form input POST method: ▪ web page often includes form input ▪ input is uploaded to server in entity body URL method: ▪ uses GET method ▪ input is uploaded in URL field of request line: www.somesite.com/animalsearch?monkeys&banana SKJ1063 SEM II 2023/2024 2-29 Method types HTTP/1.0: HTTP/1.1: ▪ GET ▪ GET, POST, HEAD ▪ POST ▪ PUT ▪ HEAD uploads file in entity asks server to leave body to path specified requested object out in URL field of response ▪ DELETE deletes file specified in the URL field SKJ1063 SEM II 2023/2024 2-30  HTTP response message status line (protocol status code HTTP/1.1 200 OK\r\n status phrase) Date: Sun, 26 Sep 2010 20:09:20 GMT\r\n Server: Apache/2.0.52 (CentOS)\r\n Last-Modified: Tue, 30 Oct 2007 17:00:02 GMT\r\n header ETag: "17dc6-a5c-bf716880"\r\n Accept-Ranges: bytes\r\n lines Content-Length: 2652\r\n Keep-Alive: timeout=10, max=100\r\n Connection: Keep-Alive\r\n Content-Type: text/html; charset=ISO-8859- 1\r\n data, e.g., \r\n requested data data data data data... HTML file * Check out the online interactive exercises for more examples: http://gaia.cs.umass.edu/kurose_ross/interactive/ SKJ1063 SEM II 2023/2024 2-31 HTTP response status codes ▪ status code appears in 1st line in server-to- client response message. ▪ some sample codes: 200 OK request succeeded, requested object later in this msg 301 Moved Permanently requested object moved, new location specified later in this msg (Location:) 400 Bad Request request msg not understood by server 404 Not Found requested document not found on this server 505 HTTP Version Not Supported SKJ1063 SEM II 2023/2024 2-32 Trying out HTTP (client side) for yourself 1. Telnet to your favorite Web server: telnet gaia.cs.umass.edu 80 opens TCP connection to port 80 (default HTTP server port) at gaia.cs.umass. edu. anything typed in will be sent to port 80 at gaia.cs.umass.edu 2. type in a GET HTTP request: GET /kurose_ross/interactive/index.php HTTP/1.1 Host: gaia.cs.umass.edu by typing this in (hit carriage return twice), you send this minimal (but complete) GET request to HTTP server 3. look at response message sent by HTTP server! (or use Wireshark to look at captured HTTP request/response) SKJ1063 SEM II 2023/2024 2-33 User-server state: cookies example: many Web sites use cookies ▪ Susan always access Internet four components: from PC 1) cookie header line of ▪ visits specific e-commerce HTTP response site for first time message ▪ when initial HTTP requests 2) cookie header line in arrives at site, site creates: next HTTP request unique ID message entry in backend 3) cookie file kept on database for ID user’s host, managed by user’s browser 4) back-end database at Web site SKJ1063 SEM II 2023/2024 2-34  Cookies: keeping “state” (cont.) client server ebay 8734 usual http request msg Amazon server cookie file creates ID usual http response 1678 for user create backend ebay 8734 set-cookie: 1678 entry database amazon 1678 usual http request msg cookie: 1678 cookie- access specific usual http response msg action one week later: access ebay 8734 usual http request msg amazon 1678 cookie: 1678 cookie- specific usual http response msg action SKJ1063 SEM II 2023/2024 2-35 Cookies (continued) aside what cookies can be used cookies and privacy: for: ▪ authorization ▪ cookies permit sites to learn a lot about you ▪ shopping carts ▪ recommendations ▪ you may supply name and ▪ user session state (Web e-mail to sites e-mail) how to keep “state”: ▪ protocol endpoints: maintain state at sender/receiver over multiple transactions ▪ cookies: http messages carry state SKJ1063 SEM II 2023/2024 2-36 Web caches (proxy server) goal: satisfy client request without involving origin server ▪ user sets browser: Web accesses via cache ▪ browser sends all HTTP proxy requests to cache server object in cache: cache client origin returns object server else cache requests object from origin server, then returns object to client client origin server SKJ1063 SEM II 2023/2024 2-37 More about Web caching ▪ cache acts as both why Web caching? client and server ▪ reduce response time server for original for client request requesting client client to origin server ▪ reduce traffic on an ▪ typically cache is institution’s access link installed by ISP ▪ Internet dense with (university, company, caches: enables “poor” residential ISP) content providers to effectively deliver content (so too does P2P file sharing) SKJ1063 SEM II 2023/2024 2-38 Caching example: assumptions: ▪ avg object size: 100K bits origin ▪ avg request rate from browsers to servers origin servers:15/sec public ▪ avg data rate to browsers: 1.50 Mbps Internet ▪ RTT from institutional router to any origin server: 2 sec ▪ access link rate: 1.54 Mbps 1.54 Mbps access link consequences: ▪ LAN utilization: 15% problem! institutional network ▪ access link utilization = 99% 1 Gbps LAN ▪ total delay = Internet delay + access delay + LAN delay = 2 sec + minutes + usecs SKJ1063 SEM II 2023/2024 2-39 Caching example: fatter access link assumptions: ▪ avg object size: 100K bits origin ▪ avg request rate from browsers to servers origin servers:15/sec public ▪ avg data rate to browsers: 1.50 Mbps Internet ▪ RTT from institutional router to any origin server: 2 sec ▪ access link rate: 1.54 Mbps 154 Mbps 1.54 Mbps 154 Mbps access link consequences: ▪ LAN utilization: 15% institutional ▪ access link utilization = 99% 9.9% network 1 Gbps LAN ▪ total delay = Internet delay + access delay + LAN delay = 2 sec + minutes + usecs msecs Cost: increased access link speed (not cheap!) SKJ1063 SEM II 2023/2024 2-40 Caching example: install local cache assumptions: ▪ avg object size: 100K bits origin ▪ avg request rate from browsers to servers origin servers:15/sec public ▪ avg data rate to browsers: 1.50 Mbps Internet ▪ RTT from institutional router to any origin server: 2 sec ▪ access link rate: 1.54 Mbps 1.54 Mbps access link consequences: ▪ LAN utilization: 15% institutional access link utilization = 100% network ▪ ? 1 Gbps LAN ▪ ? total delay = Internet delay + access delay + LAN delay local web How to compute link = 2 sec + minutes + usecs cache utilization, delay? Cost: web cache (cheap!) SKJ1063 SEM II 2023/2024 2-41 Caching example: install local cache Calculating access link utilization, delay with cache: origin ▪ suppose cache hit rate is 0.4 servers 40% requests satisfied at cache, public 60% requests satisfied at origin Internet ▪ access link utilization: ▪ 60% of requests use access link ▪ data rate to browsers over access link 1.54 Mbps access link = 0.6*1.50 Mbps =.9 Mbps institutional ▪ utilization = 0.9/1.54 =.58 network 1 Gbps LAN ▪ total delay ▪ = 0.6 * (delay from origin servers) +0.4 local web * (delay when satisfied at cache) cache ▪ = 0.6 (2.01) + 0.4 (~msecs) = ~ 1.2 secs ▪ less than with 154 Mbps link (and cheaper too!) SKJ1063 SEM II 2023/2024 2-42 Conditional GET client server ▪ Goal: don’t send object if cache has up-to-date cached version HTTP request msg object If-modified-since: no object transmission not delay modified lower link utilization HTTP response before HTTP/1.0 ▪ cache: specify date of 304 Not Modified cached copy in HTTP request If-modified-since: HTTP request msg ▪ server: response contains If-modified-since: object modified no object if cached copy after HTTP response is up-to-date: HTTP/1.0 200 OK HTTP/1.0 304 Not Modified SKJ1063 SEM II 2023/2024 2-43 Chapter 2: outline 2.1 principles of network 2.5 P2P applications applications 2.6 video streaming and 2.2 Web and HTTP content distribution 2.3 electronic mail networks SMTP, POP3, IMAP 2.7 socket programming 2.4 DNS with UDP and TCP SKJ1063 SEM II 2023/2024 2-44 Electronic mail outgoing message queue user mailbox Three major components: user agent ▪ user agents ▪ mail servers mail user server agent ▪ simple mail transfer protocol: SMTP SMTP mail user server agent User Agent SMTP ▪ a.k.a. “mail reader” SMTP user agent ▪ composing, editing, reading mail server mail messages user ▪ e.g., Outlook, Thunderbird, agent iPhone mail client user agent ▪ outgoing, incoming messages stored on server SKJ1063 SEM II 2023/2024 2-45 Electronic mail: mail servers mail servers: user agent ▪ mailbox contains incoming messages for user mail user server agent ▪ message queue of outgoing (to be sent) mail messages SMTP mail user ▪ SMTP protocol between server agent mail servers to send email SMTP messages client: sending mail SMTP user agent mail server server user “server”: receiving mail agent server user agent SKJ1063 SEM II 2023/2024 2-46 Electronic Mail: SMTP [RFC 2821] ▪ uses TCP to reliably transfer email message from client to server, port 25 ▪ direct transfer: sending server to receiving server ▪ three phases of transfer handshaking (greeting) transfer of messages closure ▪ command/response interaction (like HTTP) commands: ASCII text response: status code and phrase ▪ messages must be in 7-bit ASCI SKJ1063 SEM II 2023/2024 2-47 Scenario: Alice sends message to Bob 1) Alice uses UA to compose 4) SMTP client sends Alice’s message “to” message over the TCP [email protected] connection 2) Alice’s UA sends message 5) Bob’s mail server places the to her mail server; message message in Bob’s mailbox placed in message queue 6) Bob invokes his user agent 3) client side of SMTP opens to read message TCP connection with Bob’s mail server 1 user mail user mail agent agent server server 2 3 6 4 5 Alice’s mail server Bob’s mail server SKJ1063 SEM II 2023/2024 2-48 Sample SMTP interaction S: 220 hamburger.edu C: HELO crepes.fr S: 250 Hello crepes.fr, pleased to meet you C: MAIL FROM: S: 250 [email protected]... Sender ok C: RCPT TO: S: 250 [email protected]... Recipient ok C: DATA S: 354 Enter mail, end with "." on a line by itself C: Do you like ketchup? C: How about pickles? C:. S: 250 Message accepted for delivery C: QUIT S: 221 hamburger.edu closing connection SKJ1063 SEM II 2023/2024 2-49 Try SMTP interaction for yourself: ▪ telnet servername 25 ▪ see 220 reply from server ▪ enter HELO, MAIL FROM, RCPT TO, DATA, QUIT commands above lets you send email without using email client (reader) SKJ1063 SEM II 2023/2024 2-50 SMTP: final words ▪ SMTP uses persistent comparison with HTTP: connections ▪ HTTP: pull ▪ SMTP requires message (header & body) to be in ▪ SMTP: push 7-bit ASCII ▪ both have ASCII ▪ SMTP server uses command/response CRLF.CRLF to interaction, status codes determine end of message ▪ HTTP: each object encapsulated in its own response message ▪ SMTP: multiple objects sent in multipart message SKJ1063 SEM II 2023/2024 2-51 Mail message format SMTP: protocol for exchanging email messages header blank RFC 822: standard for text line message format: ▪ header lines, e.g., To: body From: Subject: different from SMTP MAIL FROM, RCPT TO: commands! ▪ Body: the “message” ASCII characters only SKJ1063 SEM II 2023/2024 2-52 Mail access protocols user mail access user SMTP SMTP protocol agent agent (e.g., POP, IMAP) sender’s mail receiver’s mail server server ▪ SMTP: delivery/storage to receiver’s server ▪ mail access protocol: retrieval from server POP: Post Office Protocol [RFC 1939]: authorization, download IMAP: Internet Mail Access Protocol [RFC 1730]: more features, including manipulation of stored messages on server HTTP: gmail, Hotmail, Yahoo! Mail, etc. SKJ1063 SEM II 2023/2024 2-53 POP3 protocol S: +OK POP3 server ready C: user bob authorization phase S: C: +OK pass hungry ▪ client commands: S: +OK user successfully logged on user: declare username pass: password C: list S: 1 498 ▪ server responses S: 2 912 +OK S:. -ERR C: retr 1 transaction phase, client: S: S:. ▪ list: list message numbers C: dele 1 ▪ retr: retrieve message by C: retr 2 number S: ▪ dele: delete S:. ▪ quit C: dele 2 C: quit S: +OK POP3 server signing off SKJ1063 SEM II 2023/2024 2-54 POP3 (more) and IMAP more about POP3 IMAP ▪ previous example uses ▪ keeps all messages in one POP3 “download and place: at server delete” mode ▪ allows user to organize Bob cannot re-read e- messages in folders mail if he changes ▪ keeps user state across client sessions: ▪ POP3 “download-and- names of folders and keep”: copies of messages mappings between on different clients message IDs and folder ▪ POP3 is stateless across name sessions SKJ1063 SEM II 2023/2024 2-55 Chapter 2: outline 2.1 principles of network 2.5 P2P applications applications 2.6 video streaming and 2.2 Web and HTTP content distribution 2.3 electronic mail networks SMTP, POP3, IMAP 2.7 socket programming 2.4 DNS with UDP and TCP SKJ1063 SEM II 2023/2024 2-56 DNS: domain name system people: many identifiers: Domain Name System: SSN, name, passport # ▪ distributed database Internet hosts, routers: implemented in hierarchy of IP address (32 bit) - many name servers used for addressing ▪ application-layer protocol: hosts, datagrams name servers communicate to “name”, e.g., resolve names (address/name www.yahoo.com - translation) used by humans note: core Internet function, Q: how to map between IP implemented as application- layer protocol address and name, and vice versa ? complexity at network’s “edge” SKJ1063 SEM II 2023/2024 2-57 DNS: services, structure DNS services why not centralize DNS? ▪ hostname to IP address ▪ single point of failure translation ▪ traffic volume ▪ host aliasing ▪ distant centralized database canonical, alias names ▪ maintenance ▪ mail server aliasing ▪ load distribution A: doesn‘t scale! replicated Web servers: many IP addresses correspond to one name SKJ1063 SEM II 2023/2024 2-58 DNS: a distributed, hierarchical database Root DNS Servers … … com DNS servers org DNS servers edu DNS servers pbs.org poly.edu umass.edu yahoo.com amazon.com DNS servers DNS serversDNS servers DNS servers DNS servers client wants IP for www.amazon.com; 1st approximation: ▪ client queries root server to find com DNS server ▪ client queries.com DNS server to get amazon.com DNS server ▪ client queries amazon.com DNS server to get IP address for www.amazon.com SKJ1063 SEM II 2023/2024 2-59  DNS: root name servers ▪ contacted by local name server that can not resolve name ▪ root name server: contacts authoritative name server if name mapping not known gets mapping returns mapping to local name server c. Cogent, Herndon, VA (5 other sites) d. U Maryland College Park, MD k. RIPE London (17 other sites) h. ARL Aberdeen, MD j. Verisign, Dulles VA (69 other sites ) i. Netnod, Stockholm (37 other sites) e. NASA Mt View, CA m. WIDE Tokyo f. Internet Software C. (5 other sites) Palo Alto, CA (and 48 other sites) a. Verisign, Los Angeles CA 13 logical root name (5 other sites) b. USC-ISI Marina del Rey, CA “servers” worldwide l. ICANN Los Angeles, CA each “server” replicated (41 other sites) g. US DoD Columbus, many times OH (5 other sites) SKJ1063 SEM II 2023/2024 2-60 TLD, authoritative servers top-level domain (TLD) servers: responsible for com, org, net, edu, aero, jobs, museums, and all top-level country domains, e.g.: uk, fr, ca, jp Network Solutions maintains servers for.com TLD Educause for.edu TLD authoritative DNS servers: organization’s own DNS server(s), providing authoritative hostname to IP mappings for organization’s named hosts can be maintained by organization or service provider SKJ1063 SEM II 2023/2024 2-61 Local DNS name server ▪ does not strictly belong to hierarchy ▪ each ISP (residential ISP, company, university) has one also called “default name server” ▪ when host makes DNS query, query is sent to its local DNS server has local cache of recent name-to-address translation pairs (but may be out of date!) acts as proxy, forwards query into hierarchy SKJ1063 SEM II 2023/2024 2-62 DNS name root DNS server resolution example 2 ▪ host at cis.poly.edu 3 TLD DNS server wants IP address for 4 gaia.cs.umass.edu 5 local DNS server iterated query: dns.poly.edu ▪ contacted server 7 6 1 8 replies with name of server to contact authoritative DNS server ▪ “I don’t know this dns.cs.umass.edu name, but ask this requesting host cis.poly.edu server” gaia.cs.umass.edu SKJ1063 SEM II 2023/2024 2-63 DNS name root DNS server resolution example 2 3 7 recursive query: 6 ▪ puts burden of name TLD DNS server resolution on contacted name local DNS server server dns.poly.edu 5 4 ▪ heavy load at upper 1 8 levels of hierarchy? authoritative DNS server dns.cs.umass.edu requesting host cis.poly.edu gaia.cs.umass.edu SKJ1063 SEM II 2023/2024 2-64 DNS: caching, updating records ▪ once (any) name server learns mapping, it caches mapping cache entries timeout (disappear) after some time (TTL) TLD servers typically cached in local name servers thus root name servers not often visited ▪ cached entries may be out-of-date (best effort name-to-address translation!) if name host changes IP address, may not be known Internet-wide until all TTLs expire ▪ update/notify mechanisms proposed IETF standard RFC 2136 SKJ1063 SEM II 2023/2024 2-65 DNS records DNS: distributed database storing resource records (RR) RR format: (name, value, type, ttl) type=A type=CNAME ▪ name is hostname ▪ name is alias name for some ▪ value is IP address “canonical” (the real) name type=NS ▪ www.ibm.com is really name is domain (e.g., servereast.backup2.ibm.com foo.com) ▪ value is canonical name value is hostname of authoritative name type=MX server for this domain ▪ value is name of mailserver associated with name SKJ1063 SEM II 2023/2024 2-66 DNS protocol, messages ▪ query and reply messages, both with same message format 2 bytes 2 bytes message header identification flags ▪ identification: 16 bit # for # questions # answer RRs query, reply to query uses # authority RRs # additional RRs same # ▪ flags: questions (variable # of questions) ▪ query or reply ▪ recursion desired answers (variable # of RRs) ▪ recursion available ▪ reply is authoritative authority (variable # of RRs) additional info (variable # of RRs) SKJ1063 SEM II 2023/2024 2-67 DNS protocol, messages 2 bytes 2 bytes identification flags # questions # answer RRs # authority RRs # additional RRs name, type fields questions (variable # of questions) for a query RRs in response answers (variable # of RRs) to query records for authority (variable # of RRs) authoritative servers additional “helpful” additional info (variable # of RRs) info that may be used SKJ1063 SEM II 2023/2024 2-68 Inserting records into DNS ▪ example: new startup “Network Utopia” ▪ register name networkuptopia.com at DNS registrar (e.g., Network Solutions) provide names, IP addresses of authoritative name server (primary and secondary) registrar inserts two RRs into.com TLD server: (networkutopia.com, dns1.networkutopia.com, NS) (dns1.networkutopia.com, 212.212.212.1, A) ▪ create authoritative server type A record for www.networkuptopia.com; type MX record for networkutopia.com SKJ1063 SEM II 2023/2024 2-69 Attacking DNS DDoS attacks redirect attacks ▪ bombard root servers ▪ man-in-middle with traffic Intercept queries not successful to date ▪ DNS poisoning traffic filtering ▪ Send bogus relies to local DNS servers cache DNS server, which IPs of TLD servers, caches allowing root server exploit DNS for DDoS bypass ▪ bombard TLD servers ▪ send queries with spoofed source potentially more dangerous address: target IP ▪ requires amplification SKJ1063 SEM II 2023/2024 2-70 Chapter 2: outline 2.1 principles of network 2.5 P2P applications applications 2.6 video streaming and 2.2 Web and HTTP content distribution 2.3 electronic mail networks SMTP, POP3, IMAP 2.7 socket programming 2.4 DNS with UDP and TCP SKJ1063 SEM II 2023/2024 2-71 Pure P2P architecture ▪ no always-on server ▪ arbitrary end systems directly communicate ▪ peers are intermittently connected and change IP addresses examples: file distribution (BitTorrent) Streaming (KanKan) VoIP (Skype) SKJ1063 SEM II 2023/2024 2-72 P2P file distribution: BitTorrent ▪ file divided into 256Kb chunks ▪ peers in torrent send/receive file chunks tracker: tracks peers torrent: group of peers participating in torrent exchanging chunks of a file Alice arrives … … obtains list of peers from tracker … and begins exchanging file chunks with peers in torrent SKJ1063 SEM II 2023/2024 2-73 P2P file distribution: BitTorrent ▪ peer joining torrent: has no chunks, but will accumulate them over time from other peers registers with tracker to get list of peers, connects to subset of peers (“neighbors”) ▪ while downloading, peer uploads chunks to other peers ▪ peer may change peers with whom it exchanges chunks ▪ churn: peers may come and go ▪ once peer has entire file, it may (selfishly) leave or (altruistically) remain in torrent SKJ1063 SEM II 2023/2024 2-74 BitTorrent: requesting, sending file chunks requesting chunks: sending chunks: tit-for-tat ▪ at any given time, different ▪ Alice sends chunks to those peers have different subsets four peers currently sending her of file chunks chunks at highest rate ▪ periodically, Alice asks each other peers are choked by Alice peer for list of chunks that (do not receive chunks from her) they have re-evaluate top 4 every10 secs ▪ Alice requests missing ▪ every 30 secs: randomly select chunks from peers, rarest another peer, starts sending first chunks “optimistically unchoke” this peer newly chosen peer may join top 4 SKJ1063 SEM II 2023/2024 2-75 BitTorrent: tit-for-tat (1) Alice “optimistically unchokes” Bob (2) Alice becomes one of Bob’s top-four providers; Bob reciprocates (3) Bob becomes one of Alice’s top-four providers higher upload rate: find better trading partners, get file faster ! SKJ1063 SEM II 2023/2024 2-76 Chapter 2: outline 2.1 principles of network 2.5 P2P applications applications 2.6 video streaming and 2.2 Web and HTTP content distribution 2.3 electronic mail networks (CDNs) SMTP, POP3, IMAP 2.7 socket programming 2.4 DNS with UDP and TCP SKJ1063 SEM II 2023/2024 2-77 Video Streaming and CDNs: context ▪ video traffic: major consumer of Internet bandwidth Netflix, YouTube: 37%, 16% of downstream residential ISP traffic ~1B YouTube users, ~75M Netflix users ▪ challenge: scale - how to reach ~1B users? single mega-video server won’t work (why?) ▪ challenge: heterogeneity ▪ different users have different capabilities (e.g., wired versus mobile; bandwidth rich versus bandwidth poor) ▪ solution: distributed, application-level infrastructure SKJ1063 SEM II 2-78 2023/2024 Streaming multimedia: DASH ▪ DASH: Dynamic, Adaptive Streaming over HTTP ▪ server: divides video file into multiple chunks each chunk stored, encoded at different rates manifest file: provides URLs for different chunks ▪ client: periodically measures server-to-client bandwidth consulting manifest, requests one chunk at a time chooses maximum coding rate sustainable given current bandwidth can choose different coding rates at different points in time (depending on available bandwidth at time) SKJ1063 SEM II 2-79 2023/2024 Streaming multimedia: DASH ▪ DASH: Dynamic, Adaptive Streaming over HTTP ▪ “intelligence” at client: client determines when to request chunk (so that buffer starvation, or overflow does not occur) what encoding rate to request (higher quality when more bandwidth available) where to request chunk (can request from URL server that is “close” to client or has high available bandwidth) SKJ1063 SEM II 2-80 2023/2024  CDN content access: a closer look Bob (client) requests video http://netcinema.com/6Y7B23V ▪ video stored in CDN at http://KingCDN.com/NetC6y&B23V 1. Bob gets URL for video http://netcinema.com/6Y7B23V from netcinema.com web page 2. resolve http://netcinema.com/6Y7B23V 2 via Bob’s local DNS 1 6. request video from 5 Bob’s KINGCDN server, local DNS streamed via HTTP server 3. netcinema’s DNS returns URL 4&5. Resolve netcinema.com 4 http://KingCDN.com/NetC6y&B23 http://KingCDN.com/NetC6y&B23V via KingCDN’s authoritative DNS, 3 which returns IP address of KingCDN server with video netcinema’s authoratative DNS KingCDN.com KingCDN authoritative DNS SKJ1063 SEM II 2-81 2023/2024  Case study: Netflix Amazon cloud upload copies of multiple versions of video to CDN servers CDN server Netflix registration, accounting servers 3. Manifest file 2. Bob browses returned for CDN Netflix video 2 requested video server 3 1 1. Bob manages Netflix account CDN server 4. DASH streaming SKJ1063 SEM II 2-82 2023/2024 Chapter 2: outline 2.1 principles of network 2.5 P2P applications applications 2.6 video streaming and 2.2 Web and HTTP content distribution 2.3 electronic mail networks SMTP, POP3, IMAP 2.7 socket programming 2.4 DNS with UDP and TCP SKJ1063 SEM II 2023/2024 2-83 Socket programming goal: learn how to build client/server applications that communicate using sockets socket: door between application process and end- end-transport protocol application application socket controlled by process process app developer transport transport network network controlled link by OS link Internet physical physical SKJ1063 SEM II 2023/2024 2-84  Socket programming Two socket types for two transport services: UDP: unreliable datagram TCP: reliable, byte stream-oriented Application Example: 1. client reads a line of characters (data) from its keyboard and sends data to server 2. server receives the data and converts characters to uppercase 3. server sends modified data to client 4. client receives modified data and displays line on its screen SKJ1063 SEM II 2023/2024 2-85 Socket programming with UDP UDP: no “connection” between client & server ▪ no handshaking before sending data ▪ sender explicitly attaches IP destination address and port # to each packet ▪ receiver extracts sender IP address and port# from received packet UDP: transmitted data may be lost or received out-of-order Application viewpoint: ▪ UDP provides unreliable transfer of groups of bytes (“datagrams”) between client and server SKJ1063 SEM II 2023/2024 2-86 SKJ1063 SEM II 2023/2024 2-87 SKJ1063 SEM II 2023/2024 2-88 SKJ1063 SEM II 2023/2024 2-89 Socket programming with TCP client must contact server ▪ when contacted by client, ▪ server process must first be server TCP creates new socket running for server process to ▪ server must have created communicate with that socket (door) that particular client welcomes client’s contact allows server to talk with multiple clients client contacts server by: source port numbers used ▪ Creating TCP socket, to distinguish clients specifying IP address, port (more in Chap 3) number of server process ▪ when client creates socket: application viewpoint: client TCP establishes TCP provides reliable, in-order connection to server TCP byte-stream transfer (“pipe”) between client and server SKJ1063 SEM II 2023/2024 2-90 Chapter 2: summary our study of network apps now complete! ▪ application architectures ▪ specific protocols: client-server HTTP P2P SMTP, POP, IMAP ▪ application service requirements: DNS reliability, bandwidth, delay P2P: BitTorrent ▪ Internet transport service ▪ video streaming, CDNs model ▪ socket programming: connection-oriented, TCP, UDP sockets reliable: TCP unreliable, datagrams: UDP SKJ1063 SEM II 2023/2024 2-91 Chapter 2: summary most importantly: learned about protocols! ▪ typical request/reply important themes: message exchange: ▪ control vs. messages client requests info or service in-band, out-of-band server responds with ▪ centralized vs. decentralized data, status code ▪ stateless vs. stateful ▪ message formats: ▪ reliable vs. unreliable message headers: fields giving info about data transfer data: info(payload) ▪ “complexity at network being communicated edge” SKJ1063 SEM II 2023/2024 2-92