SMUCSE 4344 application layer
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 includes other components, such as mail servers, user mailboxes, mail readers
SMUCSE 4344 DNS – Domain Name System DNS maps ASCII host names (e.g., marge.engr.smu.edu) & addresses (e.g., to IP addresses resolver procedure queries DNS name server with ASCII name parameter, gets back resource record numeric IP addresses used for Internet routing domains are hierarchical
SMUCSE 4344 zones DNS name space comprises zones each zone has its own name server(s) authoritative record vs. cached record
SMUCSE 4344 DNS zones Part of the DNS name space showing the division into zones.
SMUCSE 4344 DNS lookup illustration a resolver looks up host linda.cs.yale.edu recursive query
SMUCSE 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)
SMUCSE message format – RFC 822 RFC 822 header fields related to message transport
SMUCSE 4344 RFC 822 more RFC 822 message header fields
SMUCSE 4344 MIME headers MIME defines encoding rules for non-ASCII, using five additional RFC 822-compliant headers
SMUCSE 4344 message transfer SMTP: Simple Mail Transfer Protocol –TCP over well- known port 25 –ASCII protocol
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)
SMUCSE 4344 POP3 vs. IMAP
SMUCSE 4344 World Wide Web (WWW) architectural overview HTTP – HyperText Transfer Protocol performance enhancements
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
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
SMUCSE 4344 architectural overview
SMUCSE 4344 WWW clients URL: Uniform Resource Locator hyperlinks are based on URLs – :// / – WWW services at well-known port 80 HyperText Markup Language: HTML
SMUCSE 4344 URLs – Uniform Resource Locaters Some common URLs.
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;...
SMUCSE 4344 web servers multi-threaded Web server with front end and processing modules
SMUCSE 4344 server farm
SMUCSE 4344 caching Hierarchical caching with three proxies.
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
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
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
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
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
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)