1. SMUCSE 4344 application layer

2. SMUCSE 4344 application vs. application-layer protocols application-layer protocol is just one piece –how the end hosts communicate example: World Wide Web –HyperText Transfer Protocol (HTTP) is protocol –but the Web includes other components, such as document formats (HTML), Web browsers, servers, … example: electronic mail –Simple Mail Transfer Protocol (SMTP) is protocol –but e-mail includes other components, such as mail servers, user mailboxes, mail readers

3. SMUCSE 4344 DNS – Domain Name System DNS maps ASCII host names (e.g., marge.engr.smu.edu) & email addresses (e.g., donm@engr.smu.edu) to IP addresses donm@engr.smu.edu resolver procedure queries DNS name server with ASCII name parameter, gets back resource record numeric IP addresses used for Internet routing domains are hierarchical

4. SMUCSE 4344 zones DNS name space comprises zones each zone has its own name server(s)‏ authoritative record vs. cached record

5. SMUCSE 4344 DNS zones Part of the DNS name space showing the division into zones.

6. SMUCSE 4344 DNS lookup illustration a resolver looks up host linda.cs.yale.edu recursive query

7. SMUCSE 4344 email: architecture and services user agent mail transfer agent (daemon)‏ basic application functions –composition addresses, other header fields, text body –transfer (MX to MX)‏ –reporting (bounced, delivered, still trying)‏ –displaying (folders, messages)‏ status: unread, read, answered, deleted text, attachments –disposition (delete, save, organize, recycle)‏

8. SMUCSE 4344 email message format – RFC 822 RFC 822 header fields related to message transport

9. SMUCSE 4344 RFC 822 more RFC 822 message header fields

10. SMUCSE 4344 MIME headers MIME defines encoding rules for non-ASCII, using five additional RFC 822-compliant headers

11. SMUCSE 4344 message transfer SMTP: Simple Mail Transfer Protocol –TCP over well- known port 25 –ASCII protocol

12. SMUCSE 4344 final delivery -Post Office Protocol v. 3 (POP3): client downloads messages (port 110)‏ - Internet Message Access Protocol (IMAP): msgs stay on server (port 143)‏

13. SMUCSE 4344 POP3 vs. IMAP

14. SMUCSE 4344 World Wide Web (WWW)‏ architectural overview HTTP – HyperText Transfer Protocol performance enhancements

15. SMUCSE 4344 WWW origins hypertext, Vannevar Bush, M.I.T., 1945 Tim Berners-Lee, CERN, 1989 –proposal: networked “web” of hyperlinked documents Marc Andreessen, U Illinois –Mosaic graphical browser, 1993 –Netscape, 1994 World Wide Web Consortium (W3C)‏ –CERN, M.I.T. –standardization effort –director, Tim Berners-Lee

16. SMUCSE 4344 WWW architecture web pages and hyperlinks web servers host web pages client software: web browser basic operation –user selects a hyperlink –browser requests IP address from DNS –browser requests hyperlink-identified web page –web server sends new web page –browser “renders” new web page –only whole pages sent

17. SMUCSE 4344 architectural overview

18. SMUCSE 4344 WWW clients URL: Uniform Resource Locator hyperlinks are based on URLs – :// / –http://engr.smu.edu/~donm/4344.htmlhttp://engr.smu.edu/~donm/4344.html WWW services at well-known port 80 HyperText Markup Language: HTML

19. SMUCSE 4344 URLs – Uniform Resource Locaters Some common URLs.

20. SMUCSE 4344 display of non-HTML content plug-ins extend the browsers capabilities helpers are independent processes dynamic content: PHP, JSP, ASP, perl, javascript Wireless Application Protocol (WAP); i-mode;...

21. SMUCSE 4344 web servers multi-threaded Web server with front end and processing modules

22. SMUCSE 4344 server farm

23. SMUCSE 4344 caching Hierarchical caching with three proxies.

24. SMUCSE 4344 caching vs. replication motivations for moving content close to users –reduce latency for user –reduce load on network and server caching –replicating content “on demand” after request –storing response message locally for future use replication –planned replication of content in multiple locations –updating of resources is handled outside of HTTP –can replicate scripts that create dynamic responses

25. SMUCSE 4344 caching vs. replication caching first seen as very important in HTTP –many additions to HTTP to support caching in particular, cache validation deployment of caching proxies in the 1990s –service providers & enterprises deployed proxies –… to cache content across a community of users –sometimes, gains were not very dramatic then, content distribution networks emerged –companies (like Akamai) that replicate Web sites –host all (or part) of a Web site for a content provider –place replicas all over world on many machines

26. SMUCSE 4344 TCP interaction: multiple transfers most Web pages have multiple objects –e.g., HTML file, multiple embedded images serializing the transfers is not efficient –sending images one at a time introduces delay –cannot retrieve another image until first arrives parallel connections –browser opens multiple TCP connections … and retrieves a single image on each connection performance trade-offs –multiple downloads share same network links –unfairness to other traffic traversing the links

27. SMUCSE 4344 TCP interaction: short transfers HTTP transfers are short –very small request message (e.g., a few hundred bytes)‏ –small response message (e.g., a few kilobytes)‏ TCP overhead may be big –three-way handshake to establish connection –four-way handshake to tear down the connection time to transmit file initiate TCP connection RTT request file RTT file received time

28. SMUCSE 4344 TCP interaction: persistent connections handle multiple transfers per connection –added to HTTP after Web became very popular –maintain TCP connection across multiple requests –either client or server can tear down the connection performance advantages –avoid overhead of connection set-up and tear-down –allow TCP to learn a more accurate RTT estimate –allow the TCP congestion window to increase further enhancement: pipelining –send multiple requests one after the other … before receiving the first response

29. SMUCSE 4344 reflecting on application-layer protocols protocols are tailored to applications –each protocol is customized to a specific need protocols have many key similarities –each new protocol was influenced by the previous ones –new protocols commonly borrow from the older ones protocols depend on same underlying substrate –Domain Name System (DNS)‏ –e.g., ordered reliable stream of bytes (i.e., TCP)‏ relevance of the protocol standards process –important for interoperability across implementations –yet, not necessary if same party writes all of the software …which is increasingly common (e.g., P2P software)‏