Chapter 2 Application Layer PDF

Chapter 2 Application Layer A note on the use of these PowerPoint slides: We’re making these slides freely available to all (faculty, students, readers). They’re in PowerPoint form so you see the animations; and can add, modify, and delete slides (including this one) and slide content to suit your n...

Chapter 2 Application Layer A note on the use of these PowerPoint slides: We’re making these slides freely available to all (faculty, students, readers). They’re in PowerPoint form so you see the animations; and can add, modify, and delete slides (including this one) and slide content to suit your needs. They obviously represent a lot of work on our part. In return for use, we only ask the following:  If you use these slides (e.g., in a class) that you mention their source (after all, we’d like people to use our book!) Computer  If you post any slides on a www site, that you note that they are adapted from (or perhaps identical to) our slides, and note our copyright of this material. Networking: A Top- For a revision history, see the slide note for this page. Down Approach Thanks and enjoy! JFK/KWR 8th edition n Jim Kurose, Keith Ross All material copyright 1996-2023 Pearson, 2020 J.F Kurose and K.W. Ross, All Rights Reserved Application Layer: 2-1 Application layer: overview  P2P applications  Principles of network  socket programming applications with UDP and TCP  Web and HTTP  E-mail, SMTP, IMAP  The Domain Name System DNS Application Layer: 2-2 Application layer: overview Our goals:  learn about protocols by  conceptual and examining popular application-layer protocols implementation and infrastructure aspects of application- HTTP layer protocols SMTP, IMAP transport-layer DNS video streaming systems, service models CDNs client-server  programming network paradigm applications peer-to-peer socket API paradigm Application Layer: 2-3 Some network apps  social networking  voice over IP (e.g.,  Web Skype)  text messaging  real-time video  conferencing (e.g., e-mail Zoom)  multi-user network  Internet search games  remote login  streaming stored video (YouTube, Hulu, Netflix) … Q: your favorites?  P2P file sharing Application Layer: 2-4 Creating a network app application write programs that: transport network mobile network data link physical  run on (different) end systems national or global ISP  communicate over network  e.g., web server software communicates with browser software local or regional ISP no need to write software home network content for network-core devices application transport provider network network datacenter  network-core devices do not data link physical application network transport network run user applications data link physical  applications on end systems enterprise allows for rapid app network development, propagation Application Layer: 2-5 Client-server paradigm server: mobile network  always-on host national or global ISP  permanent IP address  often in data centers, for scaling local or clients: regional ISP  contact, communicate with home network content server provider network datacenter  may be intermittently network connected  may have dynamic IP enterprise network addresses  do not communicate directly Application Layer: 2-6 Peer-peer architecture  no always-on server mobile network  arbitrary end systems directly national or global ISP communicate  peers request service from other peers, provide service in return to other peers local or self scalability – new peers bring regional ISP new service capacity, as well as home network content new service demands provider network datacenter  peers are intermittently network connected and change IP addresses enterprise complex management network  example: P2P file sharing Application Layer: 2-7 Processes communicating process: program clients, servers running within a host client process: process that initiates  within same host, two communication processes server process: communicate using process that waits to inter-process be contacted communication  note: applications (defined by OS) with P2P architectures have  processes in different client processes & hosts communicate by server processes exchanging messages Application Layer: 2-8 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 two sockets involved: one on each side application application socket controlled by process process app developer transport transport network network controlled by OS link Internet link physical physical Application Layer: 2-9 Addressing processes  to receive messages,  identifier includes both IP process must have address and port numbers identifier associated with process on  host device has unique host. 32-bit IP address  example port numbers:  Q: does IP address of HTTP server: 80 host on which process mail server: 25 runs suffice A: no, many for  to send HTTP message to identifying processesthecanprocess? be gaia.cs.umass.edu web running on same server: host IP address: 128.119.245.12 port number: 80  more shortly… Application Layer: 2-10 An application-layer protocol defines:  types of messages open protocols: exchanged,  defined in RFCs, e.g., request, response everyone has access  message syntax: to protocol definition what fields in messages  allows for & how fields are interoperability delineated  e.g., HTTP, SMTP  message semantics proprietary protocols: meaning of information  e.g., Skype, Zoom in fields  rules for when and how processes send & respond Application Layer: 2-11 What transport service does an app need? data integrity throughput  some apps (e.g., file  some apps (e.g., transfer, web multimedia) require transactions) require minimum amount of 100% reliable data throughput to be transfer “effective”  other apps (e.g., audio)  other apps (“elastic can tolerate some loss timing apps”) make use of whatever throughput  some apps (e.g., Internet security they get telephony, interactive  encryption, data games) require low delay to integrity, … be “effective” Application Layer: 2-12  Transport service requirements: common apps applicationdata loss throughput time sensitive? file transfer/downloadno loss elastic e-mailno loss elastic no Web documentsno loss elastic no real-time audio/videoloss-tolerant audio: 5Kbps- no 1Mbps yes, 10’s msec streaming audio/videoloss-tolerant video:10Kbps- interactive gamesloss-tolerant 5Mbps yes, few secs text messagingno loss same as above yes, 10’s msec Kbps+ yes and no Application Layer: 2-13 Internet transport protocols services TCP service: UDP service:  reliable transport between  unreliable data transfer sending and receiving process between sending and  flow control: sender won’t receiving process overwhelm receiver  does not provide:  congestion control: throttle reliability, flow control, sender when network congestion control, overloaded timing, throughput guarantee, security, or  connection-oriented: setup connection setup. required between client and Q: why bother? server processes Why is there a  does not provide: timing, UDP? Application Layer: 2-14  Internet applications, and transport protocols application application layer protocol transport protocol file transfer/download FTP [RFC 959] TCP e-mail SMTP [RFC 5321] TCP Web documents HTTP [RFC 7230, TCP Internet telephony 9110] TCP or UDP SIP [RFC 3261], RTP streaming audio/video [RFC 3550], or TCP interactive games proprietary HTTP UDP or TCP [RFC 7230], DASH WOW, FPS Application Layer: 2-15 Securing TCP Vanilla TCP & UDP sockets: TLS implemented in  no encryption application layer  cleartext passwords sent into  apps use TLS socket traverse Internet in libraries, that use TCP cleartext (!) in turn Transport Layer Security  cleartext sent into (TLS) “socket” traverse  provides encrypted TCP Internet encrypted connections  more: Chapter 8  data integrity  end-point authentication Application Layer: 2-16 Application layer: overview  P2P applications  Principles of network  socket programming applications with UDP and TCP  Web and HTTP  E-mail, SMTP, IMAP  The Domain Name System DNS Application Layer: 2-17 Web and HTTP First, a quick review…  web page consists of objects, each of which can be stored on different Web servers  object can be HTML file, JPEG image, Java applet, audio file,…  web page consists of base HTML-file which includes several referenced objects, each www.someschool.edu/someDept/pic.gif addressable by a URL, e.g., host name path name Application Layer: 2-18 HTTP overview HTTP: hypertext transfer protocol  Web’s application-layer HT TP req ues PC running H protocol Firefox browser TTP res t  client/server model: pon se client: browser that es t u requests, receives, (using req e T TP o ns server running H p HTTP protocol) and TP res Apache Web T server “displays” Web objects H server: Web server sends iPhone running (using HTTP protocol) Safari browser objects in response to requests Application Layer: 2-19 HTTP overview (continued) HTTP uses TCP: HTTP is “stateless”  client initiates TCP  server maintains no connection (creates socket) information about past to server, port 80 client requests  server accepts TCP aside connection from client protocols that maintain  HTTP messages “state” are complex!  past history (state) must (application-layer protocol be maintained messages) exchanged  if server/client crashes, between browser (HTTP their views of “state” may client) and Web server be inconsistent, must be (HTTP server) reconciled  TCP connection closed Application Layer: 2-20 HTTP connections: two types Non-persistent HTTP Persistent HTTP 1. TCP connection  TCP connection opened opened to a server 2. at most one object  multiple objects can sent over TCP be sent over single connection TCP connection 3. TCP connection between client, and closed that server  TCP connection downloading multiple closed objects required Application Layer: 2-21  Non-persistent HTTP: example User enters URL: www.someSchool.edu/someDepartment/home.index (containing text, references to 10 jpeg images) 1a. HTTP client initiates TCP connection to HTTP server 1b. HTTP server at host (process) at www.someSchool.edu waiting for www.someSchool.edu on port TCP connection at port 80 80 “accepts” connection, notifying 2. HTTP client sends HTTP client request message (containing URL) into 3. HTTP server receives request TCP connection socket. message, forms response time Message indicates that message containing requested client wants object object, and sends message into someDepartment/home.inde its socket Application Layer: 2-22  Non-persistent HTTP: example (cont.) User enters URL: www.someSchool.edu/someDepartment/home.index (containing text, references to 10 jpeg images) 4. HTTP server closes 5. HTTP client receives TCP connection. response message containing html file, displays html. Parsing html file, finds 10 referenced jpeg objects 6. Steps 1-5 repeated for each of 10 jpeg time objects Application Layer: 2-23 Non-persistent HTTP: response time RTT (definition): time for a small packet to travel from initiate TCP client to server and back connection RTT HTTP response time (per object): request file  one RTT to initiate TCP RTT time to transmit connection file  one RTT for HTTP request and file received first few bytes of HTTP response to return time time  object/file transmission time Non-persistent HTTP response time = 2RTT+ file transmission time Application Layer: 2-24 Persistent HTTP (HTTP 1.1) Non-persistent HTTP Persistent HTTP (HTTP1.1): issues:  server leaves connection  requires 2 RTTs per object open after sending response  OS overhead for each TCP  subsequent HTTP messages connection between same client/server  browsers often open sent over open connection multiple parallel TCP  client sends requests as connections to fetch soon as it encounters a referenced objects in referenced object parallel  as little as one RTT for all the referenced objects (cutting response time in half) Application Layer: 2-25  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, GET /index.html HTTP/1.1\r\n POST, Host: www-net.cs.umass.edu\r\n HEAD commands) User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:80.0) Gecko/20100101 Firefox/80.0 \r\n header Accept: text/html,application/xhtml+xml\r\n lines Accept-Language: en-us,en;q=0.5\r\n Accept-Encoding: gzip,deflate\r\n Connection: keep-alive\r\n \r\n carriage return, line feed at start of line indicates end of * Check out the online interactive exercises for more header lines examples: http://gaia.cs.umass.edu/kurose_ross/interactive/ Application Layer: 2-26 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 Application Layer: 2-27 Other HTTP request messages POST method: HEAD method:  web page often includes  requests headers (only) form input that would be returned if  user input sent from client specified URL were to server in entity body of requested with an HTTP HTTP POST request GET method. message PUT method:  uploads new file (object) to GET method (for sending data to server server):  completely replaces file  include user data in URL field of that exists at specified URL HTTP GET request message www.somesite.com/animalsearch?monkeys&banana with content in entity body (following a ‘?’): of POST HTTP request message Application Layer: 2-28 HTTP response message status line (protocol HTTP/1.1 200 OK status code status Date: Tue, 08 Sep 2020 00:53:20 GMT phrase) Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips PHP/7.4.9 mod_perl/2.0.11 Perl/v5.16.3 header Last-Modified: Tue, 01 Mar 2016 18:57:50 GMT lines ETag: "a5b-52d015789ee9e" Accept-Ranges: bytes Content-Length: 2651 Content-Type: text/html; charset=UTF-8 \r\n data, e.g., requested data data data data data... HTML file * Check out the online interactive exercises for more examples: h ttp://gaia.cs.umass.edu/kurose_ross/interactive/ Application Layer: 2-29 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 message 301 Moved Permanently requested object moved, new location specified later in this message (in Location: field) 400 Bad Request request msg not understood by server 404 Not Found requested document not found on this server 505 HTTP Version Not Supported Application Layer: 2-30  Trying out HTTP (client side) for yourself 1. netcat to your favorite Web server:  opens TCP connection to port 80 (default % nc -c -v gaia.cs.umass.edu 80 (for Mac) HTTP server port) at gaia.cs.umass.edu. >ncat –C gaia.cs.umass.edu 80 (for Windows)  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! to look at captured HTTP request/response) (or use Wireshark Application Layer: 2-31 Maintaining user/server state: cookies a stateful protocol: client Recall: HTTP makes two changes to X, GET/response interaction or none at all is stateless X  no notion of multi-step lock dat record X a X exchanges of HTTP messages up d a t e OK to complete a Web X’ X X’ “transaction” t’ up d a t e OK X no need for client/server to X’’ X’ OK track “state” of multi-step unlock X ’ exchange OK X’’ all HTTP requests are time time independent of each other Q: what happens if network no need for client/server to connection or client crashes at t’ ? “recover” from a partially- Application Layer: 2-32 Maintaining user/server state: cookies Web sites and client browser Example: use cookies to maintain  Susan uses browser on laptop, visits specific e- some state between commerce site for first transactions time  when initial HTTP four components: requests arrives at site, 1) cookie header line of HTTP site creates: response message unique ID (aka 2) cookie header line in next “cookie”) HTTP request message entry in backend 3) cookie file kept on user’s database for ID host, managed by user’s subsequent HTTP browser requests from Susan to this site will contain Application Layer: 2-33 Maintaining user/server state: cookies client Amazon server ebay 8734 usual HTTP request Amazon server cookie file msg creates ID usual HTTP 1678 for user create backend ebay 8734 response entry database amazon set-cookie: 1678 1678 usual HTTP request msg cookie- access cookie: 1678 specific usual HTTP response action msg one week later: access ebay 8734 usual HTTP request amazon msg cookie- 1678 cookie: 1678 specific usual HTTP response action time msg time Application Layer: 2-34 HTTP cookies: comments aside What cookies can be used cookies and privacy: for:  cookies permit sites  authorization to learn a lot about  shopping carts you on their site.  third party persistent  recommendations cookies (tracking  user session state (Web e-mail) cookies) allow common identity Challenge: How to keep (cookie value) to be state? tracked across  at protocol endpoints: maintain multiple web sites state at sender/receiver over multiple transactions  in messages: cookies in HTTP messages carry state Application Layer: 2-35 ookies: tracking a user’s browsing behavior Cookies can be used to:  track user behavior on a given website (first party cookies)  track user behavior across multiple websites (third party cookies) without user ever choosing to visit tracker site (!)  tracking may be invisible to user: rather than displayed ad triggering HTTP GET to tracker, could be an invisible link third party tracking via cookies:  disabled by default in Firefox, Safari browsers  to be disabled in Chrome browser in 2023 DPR (EU General Data Protection Regulation) and cookies “Natural persons may be associated with online identifiers […] such as internet protocol addresses, cookie identifiers or other identifiers […]. This may leave traces which, in particular when combined with unique identifiers and other information received by the servers, may be used to create profiles of the natural persons and identify them.” GDPR, recital 30 (May 2018) User has explicit when cookies can identify an control over whether or individual, cookies are considered not cookies are allowed personal data, subject to GDPR personal data regulations Web caches Goal: satisfy client requests without involving origin server  user configures browser to point to a (local) Web HT TP req cache Web u e st req cache HT client TP ues t HTT P o n se res pon res p origin P  browser sends all HTTP se t HT T server u es requests to cache P req nse HT T po if object in cache: T Pr e s HT cache returns object to client client else cache requests object from origin server, caches Application Layer: 2-38 Web caches (aka proxy servers)  Web cache acts as Why Web caching? both client and server  reduce response time for server for original requesting client client request client to origin server cache is closer to client  reduce traffic on an  server tells cache about object’s institution’s access link allowable caching in  Internet is dense with response header: caches enables “poor” content providers to more effectively deliver content Application Layer: 2-39 Caching example Scenario:  access link rate: 1.54 Mbps origin  RTT from institutional router to servers server: 2 sec public Internet  web object size: 100K bits  average request rate from browsers to origin servers: 15/sec 1.54 Mbps  avg data rate to browsers: 1.50 access link Performance: Mbps problem: large  access link utilization =.97 institutional queueing network  LAN utilization:.0015 delays at high 1 Gbps LAN  end-end delay = Internet utilization! delay + access link delay + LAN delay = 2 sec + minutes + usecs Application Layer: 2-40  Option 1: buy a faster access link Scenario: 154  access link rate: 1.54 Mbps Mbps origin  RTT from institutional router to servers server: 2 sec public Internet  web object size: 100K bits  average request rate from browsers to origin servers: 15/sec 154 Mbps 1.54 Mbps  avg data rate to browsers: 1.50 access link Performance: Mbps  access link utilization =.97 institutional.0097 network  LAN utilization:.0015 1 Gbps LAN  end-end delay = Internet delay + access link delay + LAN delay msec = 2 sec + minutes Cost: faster access link (expensive!) + usecs Application Layer: 2-41  Option 2: install a web cache Scenario:  access link rate: 1.54 Mbps origin  RTT from institutional router to servers server: 2 sec public Internet  web object size: 100K bits  average request rate from browsers to origin servers: 15/sec 1.54 Mbps  avg data rate to browsers: 1.50 access link Cost: web Mbps cache (cheap!) institutional network Performance: 1 Gbps LAN  LAN utilization:.? How to compute link  access link utilizationutilization, =? delay?  average end-end delay = ? local web cache Application Layer: 2-42  Calculating access link utilization, end-end delay with cache: suppose cache hit rate is 0.4:  40% requests served by cache, with origin servers low (msec) delay public  60% requests satisfied at origin Internet rate to browsers over access link = 0.6 * 1.50 Mbps =.9 Mbps access link utilization = 0.9/1.54 1.54 Mbps access link =.58 means low (msec) queueing institutional delay atend-end  average access delay: link network 1 Gbps LAN = 0.6 * (delay from origin servers) + 0.4 * (delay when satisfied at cache) local web cache = 0.6 end-end lower average (2.01) + delay 0.4 (~msecs) = 154 than with ~ 1.2 Mbps link (and cheaper too!) secs Application Layer: 2-43 Application layer: overview  P2P applications  Principles of network  socket programming applications with UDP and TCP  Web and HTTP  E-mail, SMTP, IMAP  The Domain Name System DNS Application Layer: 2-44 E-mail user agent Three major components: mail user  user agents server agent  mail servers SMTP mail user  simple mail transfer protocol: SMTP server agent SMTP user User Agent SMTP agent mail  a.k.a. “mail reader” server user  composing, editing, reading mail agent messages user agent  e.g., Outlook, iPhone mail client outgoing message queue  outgoing, incoming messages user mailbox stored on server Application Layer: 2-45 E-mail: mail servers user agent mail servers: mail user server  mailbox contains incoming agent messages for user SMTP mail user server agent  message queue of outgoing SMTP (to be sent) mail messages user SMTP agent SMTP protocol between mail server mail servers to send user agent email messages user  client: sending mail server agent outgoing  “server”: receiving mail message queue user mailbox server Application Layer: 2-46 SMTP RFC (5321) “client” “server” SMTP server SMTP server  uses TCP to reliably transfer email initiate TCP message from client (mail server connection initiating connection) to server, RTT port 25 TCP connection initiated  direct transfer: sending server (acting like client) to receiving server 22  three phases of transfer SMTP 0 HEL handshakin SMTP handshaking (greeting) g O 250 SMTP transfer of messages Hello SMTP closure SMTP  command/response interaction transfers (like HTTP) time commands: ASCII text Application Layer: 2-47 Scenario: Alice sends e-mail to Bob 1) Alice uses UA to compose e- 4) SMTP client sends Alice’s mail message “to” message over the TCP [email protected] connection 2) Alice’s UA sends message 5) Bob’s mail server to her mail server using places the message SMTP; message placed in in Bob’s mailbox message queue 3) client side of SMTP at mail 6) Bob invokes his server opens TCP connection user agent to read with Bob’s mail server message 1 user mail user mail agent agent server server 2 3 6 4 5 Alice’s mail server Bob’s mail server Application Layer: 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 Application Layer: 2-49 SMTP: observations comparison with HTTP:  SMTP uses  HTTP: client pull persistent connections  SMTP: client push  SMTP requires  both have ASCII message (header & command/response body) to be in 7-bit interaction, status codes ASCII  SMTP server uses  HTTP: each object CRLF.CRLF to encapsulated in its own determine end of response message message  SMTP: multiple objects sent in multipart message Application Layer: 2-50 Mail message format SMTP: protocol for exchanging e-mail messages, defined in RFC 5321 (like RFC 7231 defines HTTP) RFC 2822 defines syntax for e-mail message itself (like HTML defines syntax for web documents)  header lines, e.g., header To: blank line From: Subject: these lines, within the body of the body email message area different from SMTP MAIL FROM:, RCPT TO: commands!  Body: the “message” , ASCII Application Layer: 2-51  Retrieving email: mail access protocols user e-mail access user SMTP SMTP protocol agent agent (e.g., IMAP, HTTP) sender’s e-mail receiver’s e-mail server server  SMTP: delivery/storage of e-mail messages to receiver’s server  mail access protocol: retrieval from server IMAP: Internet Mail Access Protocol [RFC 3501]: messages stored on server, IMAP provides retrieval, deletion, folders of stored messages on server  HTTP: gmail, Hotmail, Yahoo!Mail, etc. provides web-based Application Layer: 2-52 Application Layer: Overview  P2P applications  Principles of network  socket programming applications with UDP and TCP  Web and HTTP  E-mail, SMTP, IMAP  The Domain Name System DNS Application Layer: 2-53 DNS: Domain Name System people: many identifiers: Domain Name System SSN, name, passport (DNS): #  distributed database Internet hosts, routers: implemented in hierarchy of IP address (32 bit) - used many name servers for addressing datagrams  application-layer protocol: “name”, e.g., hosts, DNS servers cs.umass.edu - used by humans communicate to resolve names (address/name Q: how to map between translation) IP address and name, and vice versa ? note: core Internet function, implemented as application- layer protocol Application Layer: 2-54 DNS: services, structure DNS services: Q: Why not centralize  hostname-to-IP-address DNS? translation  single point of failure  host aliasing  traffic volume canonical, alias names  distant centralized database  mail server aliasing A: doesn‘t scale!  maintenance  load distribution  Comcast DNS servers replicated Web servers: alone: 600B DNS many IP addresses queries/day correspond to one name  Akamai DNS servers alone: 2.2T DNS queries/day Application Layer: 2-55 Thinking about the DNS humongous distributed database:  ~ billion records, each simple handles many trillions of queries/day:  many more reads than writes  performance matters: almost every Internet transaction interacts with DNS organizationally, - msecs physically count! decentralized:  millions of different organizations responsible for their records “bulletproof”: reliability, security Application Layer: 2-56  DNS: a distributed, hierarchical database Root DNS Servers Root … ….com DNS servers.org DNS servers.edu DNS servers Top Level Domain … … … … yahoo.com amazon.com pbs.org nyu.edu umass.edu DNS servers DNS servers DNS servers DNS servers DNS servers Authoritative Client wants IP address 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 Application Layer: 2-57 DNS: root name servers  official, contact-of-last- resort by name servers that can not resolve name Application Layer: 2-58 DNS: root name servers  official, contact-of-last- resort by name servers 13 logical root name “servers” worldwide each “server” that can not resolve name replicated many times (~200  incredibly important servers in US) Internet function Internet couldn’t function without it! DNSSEC – provides security (authentication, message integrity)  ICANN (Internet Corporation for Assigned Names and Numbers) manages root DNS domain Application Layer: 2-59 Top-Level Domain, and authoritative servers Top-Level Domain (TLD) servers:  responsible for.com,.org,.net,.edu,.aero,.jobs,.museums, and all top-level country domains, e.g.:.cn,.uk,.fr,.ca,.jp  Network Solutions: authoritative registry for.com,.net TLD  Educause:.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 Application Layer: 2-60 Local DNS name servers  when host makes DNS query, it is sent to its local DNS server Local DNS server returns reply, answering: from its local cache of recent name-to-address translation pairs (possibly out of date!) forwarding request into DNS hierarchy for resolution each ISP has local DNS name server; to find yours: MacOS: % scutil --dns Windows: >ipconfig /all  local DNS server doesn’t strictly belong to hierarchy Application Layer: 2-61 DNS name resolution: iterated query root DNS server Example: host at engineering.nyu.edu wants IP 2 address for gaia.cs.umass.edu 3 TLD DNS server Iterated query: 1 4  contacted server 8 5 replies with name requesting host at local DNS server of server to contact engineering.nyu.edu dns.nyu.edu gaia.cs.umass.edu  “I don’t know this 7 6 name, but ask this server” authoritative DNS server dns.cs.umass.edu Application Layer: 2-62 DNS name resolution: recursive query root DNS server Example: host at engineering.nyu.edu wants IP 2 3 address for gaia.cs.umass.edu 7 6 Recursive query: 1 TLD DNS server  puts burden of 8 name resolution requesting host at local DNS server 5 4 engineering.nyu.edu dns.nyu.edu on contacted gaia.cs.umass.edu name server  heavy load at authoritative DNS server upper levels of dns.cs.umass.edu hierarchy? Application Layer: 2-63 Caching DNS Information  once (any) name server learns mapping, it caches mapping, and immediately returns a cached mapping in response to a query caching improves response time cache entries timeout (disappear) after some time (TTL) TLD servers typically cached in local name servers  cached entries may be out-of-date if named host changes IP address, may not be known Internet-wide until all TTLs expire! best-effort name-to-address translation! Application Layer: 2-64 DNS records DNS: distributed database storing resource recordsRR(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  www.ibm.com is really type=NS servereast.backup2.ibm.com  value is canonical name  name is domain (e.g., foo.com) type=MX  value is hostname of  value is name of SMTP mail authoritative name server server associated with name for this domain Application Layer: 2-65 DNS protocol messages DNS query and reply messages, both have same format: 2 bytes 2 bytes identification flags message header:  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 answers (variable # of RRs) recursion desired recursion available authority (variable # of RRs) reply is authoritative additional info (variable # of RRs) Application Layer: 2-66 DNS protocol messages DNS query and reply messages, both have same format: 2 bytes 2 bytes identification flags # questions # answer RRs # authority RRs # additional RRs name, type fields for a questions (variable # of questions) query RRs in response to query answers (variable # of RRs) records for authoritative authority (variable # of RRs) servers additional “ helpful” info additional info (variable # of RRs) that may be used Application Layer: 2-67 Getting your info into the 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 NS, A RRs into.com TLD server: (networkutopia.com, dns1.networkutopia.com, NS) (dns1.networkutopia.com, 212.212.212.1, A)  create authoritative server locally with IP address 212.212.212.1 type A record for www.networkuptopia.com type MX record for networkutopia.com Application Layer: 2-68 DNS security DDoS attacks Spoofing attacks  bombard root servers  intercept DNS queries, with traffic returning bogus replies not successful to date  DNS cache poisoning  RFC 4033: DNSSEC traffic filtering authentication services local DNS servers cache IPs of TLD servers, allowing root server bypass  bombard TLD servers potentially more dangerous Application Layer: 2-69 Application Layer: Overview  P2P applications  Principles of network  socket programming applications with UDP and TCP  Web and HTTP  E-mail, SMTP, IMAP  The Domain Name System DNS Application Layer: 2-70 Peer-to-peer (P2P) architecture  no always-on server mobile network  arbitrary end systems directly national or global ISP communicate  peers request service from other peers, provide service in return to other peers local or regional self scalability – new peers bring ISP new service capacity, and new home network content service demands provider network datacenter  peers are intermittently network connected and change IP addresses enterprise complex management network  examples: P2P file sharing Application Layer: 2-71 File distribution: client-server vs P2P Q: how much time to distribute file (size F) from one server to N peers? peer upload/download capacity is limited resource us: server upload capacity di: peer i file, size F u1 d1 u2 download us d2 server capacity di uN network (with abundant bandwidth) ui dN ui: peer i upload capacity Introduction: 1-72 File distribution time: client-server  server transmission: must sequentially send (upload) N file copies: F us time to send one copy: F/us di time to send N copies: NF/us network ui  client: each client must download file copy dmin = min client download rate min client download time: F/dmin time to distribute F to N clients using Dc-s > max{NF/us,,F/dmin} client-server approach increases linearly in N Introduction: 1-73 File distribution time: P2P  server transmission: must upload at least one copy: time to send one copy: F/us F us  client: each client must di network download file copy ui min client download time:  clients: F/dmin as aggregate must download NF bits max upload rate (limiting max download rate) is us + Sui time to distribute F to N clientsDusing > max{F/us,,F/dmin,,NF/(us + Sui)} P2P P2P approach increases linearly in N … … but so does this, as each peer brings service capacity Application Layer: 2-74 Client-server vs. P2P: example client upload rate = u, F/u = 1 hour, us = 10u, dmin 3.5 ≥ us P2P Minimum Distribution Time 3 Client-Server 2.5 2 1.5 1 0.5 0 0 5 10 15 20 25 30 35 N Application Layer: 2-75 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 Application Layer: 2-76 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 Application Layer: 2-77 BitTorrent: requesting, sending file chunks Requesting chunks: Sending chunks: tit-for-tat  at any given time,  Alice sends chunks to those different peers have four peers currently sending different subsets of file her chunks at highest rate chunks other peers are choked by Alice  periodically, Alice asks (do not receive chunks from each peer for list of her) chunks that they have re-evaluate top 4 every10 secs  Alice requests missing  every 30 secs: randomly chunks from peers, rarest select another peer, starts first sending chunks “optimistically unchoke” this peer newly chosen peer mayApplication join Layer: 2-78  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 ! Application Layer: 2-79 Application Layer: Overview  P2P applications  Principles of network  socket programming applications with UDP and TCP  Web and HTTP  E-mail, SMTP, IMAP  The Domain Name System DNS Application Layer: 2-80 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 by OS link Internet link physical physical Application Layer: 2-81 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 Application Layer: 2-82 Socket programming with UDP UDP: no “connection” between client and server:  no handshaking before sending data  sender explicitly attaches IP destination address and port # to each packet  receiver extracts sender IP UDP: transmitted address datafrom and port# may be lost or received out-of- order received packet Application viewpoint:  UDP provides unreliable transfer of groups of bytes (“datagrams”) between client and server processes Application Layer: 2-83 Client/server socket interaction: UDP server (running on serverIP) client create socket: create socket, port= x: clientSocket = serverSocket = socket(AF_INET,SOCK_DGRAM) socket(AF_INET,SOCK_DGRAM) Create datagram with serverIP address And port=x; send datagram via read datagram from clientSocket serverSocket write reply to serverSocket read datagram from specifying clientSocket client address, port number close clientSocket Application Layer: 2-84  Example app: UDP client Python UDPClient include Python’s socket library from socket import * serverName = 'hostname' serverPort = 12000 create UDP socket clientSocket = socket(AF_INET, SOCK_DGRAM) get user keyboard input message = input('Input lowercase sentence:') attach server name, port to message; send into socket clientSocket.sendto(message.encode(), (serverName, serverPort)) read reply data (bytes) from socket modifiedMessage, serverAddress = clientSocket.recvfrom(2048) print out received string and close socket print(modifiedMessage.decode()) clientSocket.close() Note: this code update (2023) to Python 3 Application Layer: 2-85  Example app: UDP server Python UDPServer from socket import * serverPort = 12000 create UDP socket serverSocket = socket(AF_INET, SOCK_DGRAM) bind socket to local port number 12000 serverSocket.bind(('', serverPort)) print('The server is ready to receive') loop forever while True: Read from UDP socket into message, getting message, clientAddress = serverSocket.recvfrom(2048) client’s address (client IP and port) modifiedMessage = message.decode().upper() send upper case string back to this client serverSocket.sendto(modifiedMessage.encode(), clientAddress) Note: this code update (2023) to Python 3 Application Layer: 2-86 Socket programming with TCP Client must contact server  when contacted by client,  server process must first be server TCP creates new running socket for server process to  server must have created communicate with that socket (door) that welcomes particular client client’s contact allows server to talk with multiple clients Client contacts server by: client source port # and IP  Creating TCP socket, address used to distinguish specifying IP address, port Application clients (moreviewpoint TCP provides inreliable, Chap 3)in- number of server process order  when client creates socket: byte-stream transfer client TCP establishes (“pipe”) connection to server TCP between client and server processes Application Layer: 2-87 Client/server socket interaction: TCP server (running on hostid) client create socket, port=x, for incoming request: serverSocket = socket() wait for incoming create socket, connection request TCP connect to hostid, port=x connectionSocket = connection setup clientSocket = socket() serverSocket.accept() send request using read request from clientSocket connectionSocket write reply to connectionSocket read reply from clientSocket close connectionSocket close clientSocket Application Layer: 2-88  Example app: TCP client Python TCPClient from socket import * serverName = 'servername' serverPort = 12000 create TCP socket for server, clientSocket = socket(AF_INET, SOCK_STREAM) remote port 12000 clientSocket.connect((serverName,serverPort)) sentence = input('Input lowercase sentence:') clientSocket.send(sentence.encode()) No need to attach server name, port modifiedSentence = clientSocket.recv(1024) print ('From Server:', modifiedSentence.decode()) clientSocket.close() Note: this code update (2023) to Python 3 Application Layer: 2-89  Example app: TCP server Python TCPServer from socket import * serverPort = 12000 create TCP welcoming socket serverSocket = socket(AF_INET,SOCK_STREAM) serverSocket.bind(('',serverPort)) server begins listening for incoming TCP requests serverSocket.listen(1) print('The server is ready to receive') loop forever while True: server waits on accept() for incoming connectionSocket, addr = serverSocket.accept() requests, new socket created on return read bytes from socket (but sentence = connectionSocket.recv(1024).decode() not address as in UDP) capitalizedSentence = sentence.upper() connectionSocket.send(capitalizedSentence. encode()) close connection to this client (but not connectionSocket.close() welcoming socket) Note: this code update (2023) to Python 3 Application Layer: 2-90 Chapter 2: Summary our study of network application layer is now  complete! application architectures  specific protocols: client-server HTTP P2P SMTP, IMAP  application service DNS requirements: P2P: BitTorrent reliability, bandwidth, delay  socket programming:  Internet transport service TCP, UDP sockets model connection-oriented, reliable: TCP unreliable, datagrams: UDP Application Layer: 2-91 Chapter 2: Summary Most importantly: learned about protocols!  typical request/reply important themes: message exchange:  centralized vs. client requests info or service decentralized server responds with data,  stateless vs. stateful status code  scalability  message formats:  reliable vs. unreliable headers: fields giving info message transfer about data data: info(payload) being  “complexity at communicated network edge” Application Layer: 2-92