The Application Layer

The Application Layer Chapter 7

The Application Layer • The layers below the application layer are there to provide reliable transport, but they do not do real work for users. • In this chapter we will study some real network applications. • However, even in the application layer there is a need for support protocols, to allow the applications to function.

DNS—The Domain Name System Although programs theoretically could refer to hosts, mailboxes, and other resources by their network (e.g., IP) addresses, these addresses are hard for people to remember. sending e-mail to tana@128.111.24.41 means that if Tana's ISP or organization moves the mail server to a different machine with a different IP address, her e-mail address has to change. Consequently, ASCII names were introduced to decouple machine names from machine addresses.

DNS—The Domain Name System Way back in the ARPANET, there was simply a file, hosts.txt, that listed all the hosts and their IP addresses. Every night, all the hosts would fetch it from the site at which it was maintained. The size of the file would become too large To solve these problems, DNS (the Domain Name System) was invented.

DNS—The Domain Name System • Very briefly, the way DNS is used is as follows. • To map a name onto an IP address, an application program calls a library procedure called the resolver, passing it the name as a parameter. • The resolver sends a UDP packet to a local DNS server, which then looks up the name and returns the IP address to the resolver, which then returns it to the caller. • The program can then establish a TCP connection with the destination or send it UDP packets.

DNS – The Domain Name System • Conceptually, the Internet is divided into over 200 top-level domains, where each domain covers many hosts. • Each domain is partitioned into subdomains, and these are further partitioned, and so on. All these domains can be represented by a tree, as shown in Fig. 7-1.

The DNS Name Space (1) Fig. 7-1 A portion of the Internet domain name space.

The DNS Name Space (2) Generic top-level domains

Cont. The top-level domains come in two flavors: generic and countries. In general, getting a second-level domain, such as name-of-company.com, is easy. It merely requires going to a registrar for the corresponding top-level domain (com in this case) to check if the desired name is available and not somebody else's trademark. If there are no problems, the requester pays a small annual fee and gets the name. Domain names are case insensitive, so edu, Edu, and EDU mean the same thing.

Cont. • To create a new domain, permission is required of the domain in which it will be included. • For example, if a VLSI group is started at Yale and wants to be known as vlsi.cs.yale.edu, it has to get permission from whoever manages cs.yale.edu. • Similarly, if a new university is chartered, say, the University of Northern South Dakota, it must ask the manager of the edu domain to assign it unsd.edu. • In this way, name conflicts are avoided. Once a new domain has been created and registered, it can create subdomains, such as cs.unsd.edu, without getting permission from anybody higher up the tree.

Resource Records • Every domain, whether it is a single host or a top-level domain, can have a set of resource records associated with it. • For a single host, the most common resource record is just its IP address, but many other kinds of resource records also exist. • When a resolver gives a domain name to DNS, what it gets back are the resource records associated with that name. • Thus, the primary function of DNS is to map domain names onto resource records.

Resource Records A resource record is a five-tuple. Domain_name Time_to_live Class Type Value The Domain_name tells the domain to which this record applies. Normally, many records exist for each domain. The Time_to_live field gives an indication of how stable the record is. Information that is highly stable is assigned a large value, such as 86400 (the number of seconds in 1 day). Information that is highly volatile is assigned a small value, such as 60 (1 minute). The third field of every resource record is the Class. For Internet information, it is always IN.

Domain Resource Records The Type field tells what kind of record this is. The most important types are listed above

Domain Resource Records (2) A portion of a possible DNS database for cs.vu.nl.

Name Servers (1) Part of the DNS name space divided into zones (which are circled).

Name Servers (2) Example of a resolver looking up a remote name in 10 steps.

Electronic Mail • Architecture and services • The user agent • Message formats • Message transfer • Final delivery

Architecture and Services (1) Architecture of the email system

Architecture and Services (2) Envelopes and messages. (a) Paper mail. (b) Electronic mail.

The User Agent Typical elements of the user agent interface

Message Formats (1) RFC 5322 header fields related to message transport.

Message Formats (2) Some fields used in the RFC 5322 message header.

Message Formats (3) Message headers added by MIME.

Message Formats (4) MIME content types and example subtypes.

Message Transfer (1) . . . A multipart message containing HTML and audio alternatives.

Message Transfer (2) . . . A multipart message containing HTML and audio alternatives.

Message Transfer (3) . . . Sending a message from alice@cs.washington.edu to bob@ee.uwa.edu.au.

Message Transfer (4) . . . Sending a message from alice@cs.washington.edu to bob@ee.uwa.edu.au.

Message Transfer (5) Some SMTP extensions.

Final Delivery (1) . . . IMAP (version 4) commands.

Final Delivery (2) . . . IMAP (version 4) commands.

The World Wide Web • Architectural overview • Static web pages • Dynamic web pages, web applications • The hypertext transfer protocol • The mobile web • Web search

Architectural Overview (1) Architecture of the Web.

Architectural Overview (2) Three questions had to be answered before a selected page could be displayed: • What is the page called? • Where is the page located? • How can the page be accessed?

Architectural Overview (3) Steps that occur when link is selected: • Browser determines the URL • Browser asks DNS for the IP address of the server • DNS replies • The browser makes a TCP connection • Sends HTTP request for the page • Server sends the page as HTTP response • Browser fetches other URLs as needed • The browser displays the page • The TCP connections are released

Architectural Overview (4) Some common URL schemes.

Architectural Overview (5) (a) A browser plug-in. (b) A helper application.

Architectural Overview (6) Steps server performs in main loop • Accept a TCP connection from client • Get path to page, name of file requested. • Get the file (from disk). • Send contents of the file to the client. • Release the TCP connection.

Architectural Overview (7) A multithreaded Web server with a front end and processing modules.

Architectural Overview (8) A processing module performs a series of steps: • Resolve name of Web page requested. • Perform access control on the Web page. • Check the cache. • Fetch requested page from disk or run program • Determine the rest of the response • Return the response to the client. • Make an entry in the server log.

Architectural Overview (9) Some examples of cookies

Static Web Pages (1) The HTML for a sample Web page.

Static Web Pages (2) The formatted page.

Static Web Pages (3) Some differences between HTML versions.

Static Web Pages (4) The HTML for an order form.

Static Web Pages (5) The formatted page.

Dynamic Web Pages, Web Applications (1) Dynamic pages

Dynamic Web Pages, Web Applications (2) (a) (c) (b) (a) A Web page containing a form. (b) A PHP script for handling the output of the form. (c) Output from the PHP script when the inputs are ‘‘Barbara’’ and ‘‘32’’, respectively.

Dynamic Web Pages, Web Applications (3) Use of JavaScript for processing a form.

Dynamic Web Pages, Web Applications (4) • Server-side scripting with PHP. • Client-side scripting withJavaScript.

The Application Layer