Application Layer

Application Architectures

Network applications can be classified in terms of their architecture. The three most common architectures are client-server, peer-to-peer (P2P), and hybrid (a combination of client-server and P2P).

Processes

As we mentioned several sections ago, when we say that a node communicates to another node, what we really mean is that a process one system communicates to a process on another system. A process is a program running within a system — Chrome, Firefox, Spotify, Windows Update, the Apple App Store, etc.

When a process communicates with a process in the same system, we call that communication an interprocess communication. For example, if we download a PDF file from Chrome and Adobe Acrobat opens after a complete download, we have an interprocess communication between two programs on the same system. Namely, Chrome and Adobe Acrobat. The link between these two programs is the operating system.

When a process communicates with a process on a different system, we call that communication a message. For example, if we enter cnn.com in Safari and an HTML file loads, there is a message transmitted between our laptop and the server that hosts the HTML file. In this case, there are two processes communicating with one another: a client process (the tab open in Safari) and a server process (perhaps some Apache program that's constantly waiting for, and processing requests).

Sockets

As we know, we can write programs that take user input. We can also write write programs that send data to another program. Some parts of the program only take input. These are called entry points. Other parts of the program only return outputs, and we call these exit points. However, there may also be parts of the program where data can enter and exit. We call these access points.

Network applications use a special kind of access point called a socket. Sockets are characterized by the use of a particular protocol — at the application layer, a set of rules and procedures that impose requirements for entry and exit.

One such requirement is addressing. Data can only get to a process if the operating system knows which process to send it to. And data can only get to an operating system if the sending node knows which system to send it to. And data can only get to the sending node if the router knows which router to send it to. Thus, we can only transmit data to and from different systems if we have a way to address all these different entities. This is where protocols come in.

To identify a process, we give each process a port number. Once we give a process that port number, we say that the process listens at that port number. For example, an HTTP server process (e.g., the program that processed our CNN.com request) listens at port number 80. A mail server process (e.g., the Gmail program that process our sent and received emails), listens at port number 25. Which numbers go to which process is determined by an addressing protocol.

Addressing protocols take care of locating. But there's also the issue of message formatting. Becauses processes live on potentially entirely different systems with entirely different implementations, it's unlikely that the raw data coming out of a sending process can be understood by the receiving the process. RFCs (Requests for Comments) provide a common format by establishing rules on the following points:

1. What are the types of messages exchanged? E.g., request and response.
2. What is the message syntax? I.e., what fields must the data contain, and how are they delineated?
3. What are the message semantics? I.e., how should the receiver/sender interpret the data in those fields.
4. What do I do if ${x}$ happens? These are rules about how a process should request and respond to messages.

Examples of RFCs include HTTP and SMTP (more on this later). We have rules for locating and rules for formatting. What else do we need? Well, we also need rules for message transport.

Network programs are built to provide some sort of network application, and those applications vary. Some applications are tolerant of small amounts of data loss (e.g., music streaming; there's only so much the human ear can pick up). Other applications have zero tolerance (e.g., file sharing). Some applications are tolerant of delays (e.g., emailing), others are intolerant (e.g., live online gaming).

A third parameter separate from loss and timing is bandwidth. Some applications use very little bandwidth (Internet telephony), and others use whatever bandwidth they can get their hands on (often called elastic applications; think Dropbox and OneDrive). As we've seen repeatedly, data loss and timing are often tradeoffs of one another. Bandwidth, however, is an entirely separate matter. To illustrate, consider the following scenario:

Devin, a TikTok addict, is looking for an internet service provider. Two companies, A and B approach her. A says, "We can give you 1000 bits per second." B says, "We can give you 1 millisecond packet latency." Should Devin go with A or B?

Devin should go with B. Why? Because B's offer is a much stronger guarantee than A's. A guarantee of 1 millisecond packet latency automatically implies that, when Devin receives data, she will get all 1000 bits in one second. I.e., 1000 bits per second. A's guarantee of 100 bits per second, however, does not make nearly as strong of a guarantee that all 100 bits will arrive in one second.

Why? Let's consider an alternative hypothetical. Developer Devin is comparing two different, somewhat unusual, job offers from two companies, X and Y. X says, "We provide 1 vacation per year, as long as the vacations are 1 year apart." Y says, "We provide 10 vacations for 10 years." These are two different statements. One is "1 vacation per year", the other is "10 vacations for 10 years." Setting aside potential labor law issues, Company Y might require Devin to work for a little over 9 years without seeing a vacation. Company X, however, guarantees that Devin will get 1 vacation for each year.

The same idea applies to the two ISP offers. B's offer guarantees that Devin will get 1000 packets every second. For applications like video sharing, this is desirable. The video plays as bits come in. A's offer, however, does not make nearly as strong of a guarantee — it could be the case that 1000 bits arrive at the very last second, and the videos Devin wants to watch must buffer before they start playing.

Below is a comparison of some common applications:

A developer can ensure their application's requirements are met by ensuring that its dependencies conform to a particular transport protocol. The two most common being TCP and UDP:

Now that we have a general idea of how the application layer works, let's look at some of the most common web applications.

Web Browsing

To help our discussion, let's define a few terms upfront. A web page is a collection of data objects. Crudely, we can think of it like a struct in C. The data objects inside this struct are references (weak pointers) to data. What we're analogizing to as a struct is a base HTML file.

index.html {
	text,
	image,
	text,
	image,
	video,
	audio,
	javascript code
}

Each object in the web page can be identified with an address, called its URL.

www.foobar.com/hello.jpeg

In the URL above, www.foobar.com is the webpage's host name, and everything thereafter is called the path name. The applications that request, receive, and display web page objects are called web browsers. The applications that send these objects in response to the browser requests are called web servers. Below are some examples.

Both web browsers and web servers follow the HTTP protocol in communicating with one another. The requests for data sent by the browser are called HTTP requests, and the responds sent by the web server are called HTTP responses.

The HTTP protocol is built on top of the TCP protocol. To establish communication, a process on the client system first creates a socket. This socket will serve as the access point for the data to be transferred. Next, the process initiates a TCP connection to the server. This is done by sending a request to establish the connection. If the server accepts, the connection is established, and HTTP messages are then exchanged between the two processes. Once the data transmission concludes, the TCP connection is closed.

Under the HTTP protocol, the server does not store data about past client requests. Thus, serves that follow the HTTP protocol (called HTTP servers) are often characterized as stateless. Even if a client process ${P}$ asks for weather.com at 8 A.M. every day, to the server, each request appears as if the user is asking for weather.com for the first time. In fact, it runs even deeper than that — it's as if the server is encountering ${P}$ for the very first time.

Why are they stateless? This question is best answered by considering what might happen if they weren't stateless. I.e., if they were stateful. A stateful server would be incredibly complicated. It needs sophisticated garbage collection to help manage its memory usage, methods of ensuring the client and itself are on the same page in the event it crashes, and methods for balancing its resources between processing requests and managing state. All but the most resource-laden applications can afford to implement and maintain stateful servers.

Browser Workflow

Let's take a closer look at a typical browser workflow for loading a website. Let's say user ${C}$ wants to visit the website www.site.com. The user inputs a string value site.com and hits enter. Implicitly, the input is actually: http://www.site.com (or, more commonly today, https://www.site.com). This string value is called a URL (Uniform Resource Locator), and it consists of certain parts:

Each of these parts communicates a particular piece of information: The scheme communicates the protocol used to get the data (in this case, the HTTP protcol). The hostname communicates where the data exists (a system named www.site.com). And the path communicates what data we're asking for from that system.

Receiving the string, the browser splits the string into the aforementioned parts. This can be as simple as using a string split method, or a more complicated parsing method. E.g., in pseudocode:

function request(string url) {
	assert(url.starts_with("http://"))

	let url        = url.substring("http://")
	let host, path = url.split_at("/")
	let path       = "/" + path
}

Above, our hypothetical browser uses a function called request that takes a string argument (the URL entered by the user). This function is called when the user hits enter.

Once the input string is parsed, the browser must execute a system call — a request to the operating system (OS) — to establish a TCP connection with the server named www.site.com. To do so, the browser must instantiate a socket. Sockets are generally provided by some socket library (e.g., Python's socket library). The code might look something like:

import socketLib

function request(string url) {
	let socket = socketLib.socket(
		family   = socketLib.AF_INET,
		type     = socketLib.SOCK_STREAM,
		protocol = socketLib.IPPROTO_TCP.
	)

	assert(url.starts_with("http://"))

	let url        = url.substring("http://")
	let host, path = url.split_at("/")
	let path       = "/" + path
}

Again, this is just pseudocode. How a browser creates its sockets entirely depends on its implementation language and the libraries it uses, if any. That said, many of the socket APIs will look similar to the pseudocode above.

All sockets have an address family, which indicates how a machine can be found. In the code above, we've indicated AF_INET, the address family for IPv4 addresses. Other address families include AF_INET6 (for IPv6 addreses) and AF_BLUETOOTH (for Bluetooth addresses).

Sockets also have a type. This indicates what kind of data format will be transmitted. In this case, we've indicated SOCK_STREAM, which corresponds to the TCP protocol data ("the data will be transmitted as packets"). There's also SOCK_DGRAM, corresponding to the UDP protocol ("the data will be transmitted as datagrams").

Finally, sockets have a transport protocol, as we know. This indicates the transport protocol for trasmitting the data. Above, we've indicated IPPROTO_TCP (another protocol options might be IPPROTO_UDP).

Once the socket is instantiated, it makes a call to the operating system:

import socketLib

function request(string url) {
	let socket = socketLib.socket(
		family   = socketLib.AF_INET,
		type     = socketLib.SOCK_STREAM,
		protocol = socketLib.IPPROTO_TCP.
	)

	assert(url.starts_with("http://"))

	let url        = url.substring("http://")
	let host, path = url.split_at("/")
	let path       = "/" + path

	socket.connect(host, 80)
}

Receiving the system call, the OS sends the host name to a DNS (Domain Name System) server. This is a web application elsewhere that converts the host name into a destination IP address (perhaps something like 159.89.245.44). The DNS looks up the host name in its directory, and sends the corresponding IP address back to the OS. We can actually see this at work with the dig command:

$ dig +short sublimis.com
159.89.245.44

Above, the sublimis.com reduces to the IP address 159.89.245.44.

Once the operating system receives the IP address, it must make a decision: Should I use to establish a wired or wireless connection with this IP address? The OS makes this decision by examining a routing table. Again, the details behind this routing table are complex and left to a later chapter, but in short, this table provides information that allows the operating system to determine the fastest way to get signals to the destination IP address.

Let's say the OS goes with wireless. The OS prepares a request to establish a TCP connection. Using its device drivers, the bits comprising this data are eventually transformed to signals and emitted over the air. Those signals are picked up by a nearby access point (e.g., a WiFi receiver), which transforms them back into data. That receiver sees the IP address, and sends forwards them to next system along the route, all the way to the server's IP address. As we saw earlier, once this message gets to the server, it must either agree or disagree to establishing a TCP connection.

Let's say it agrees. The server sends back its "Ok" response to the OS, and the OS sends its response to the browser: "You're now connected to 159.89.245.44". One program we can use to see this process at work is Telnet (installation may be required).

$ telnet sublimis.com
Trying 159.89.245.44...
Connected to sublimis.com.

GET /dir/index.html HTTP/1.1
Host: www.site.com
User-agent: Mozilla/10.4
Connection: open
Accept-Language:en-us, en
Accept-Encoding: gzip,deflate
Accept-Chaset: utf-8
Keep-alive: 300
Connection: keep-alive

import socketLib

function request(string url) {
	let socket = socketLib.socket(
		family   = socketLib.AF_INET,
		type     = socketLib.SOCK_STREAM,
		protocol = socketLib.IPPROTO_TCP.
	)

	assert(url.starts_with("http://"))

	let url        = url.substring("http://")
	let host, path = url.split_at("/")
	let path       = "/" + path

	socket.connect(host, 80)

	socket.send("GET {} HTTP/1.0\r\n".format(path).encode("utf8") + 
				"Host: {}\r\n\r\n".format(host).encode("utf8"))
}

POST /dir/register.asp HTTP/1.1
Host: www.site.com
User-agent: Mozilla/10.0
Accept-text/xml,text/html,text/plain,image/jpeg
Accept-Language:en-us,en
Accept-Encoding:gzip,deflate 
Accept-Charset:utf-8,
Connection:close

import socketLib

function post(string url) {
	let socket = socketLib.socket(
		family   = socketLib.AF_INET,
		type     = socketLib.SOCK_STREAM,
		protocol = socketLib.IPPROTO_TCP.
	)
	// user enters URL
	assert(url.starts_with("http://"))

	let url        = url.substring("http://")
	let host, path = url.split_at("/")
	let path       = "/" + path

	socket.connect(host, 80)

	socket.send("POST {} HTTP/1.1\r\n".format(path).encode("utf8") + 
				"Host: {}\r\n\r\n".format(host).encode("utf8"))
}

let response = socket.makefile("r", encoding="utf8", newline="\r\n");

import socketLib

function request(string url) {
	let socket = socketLib.socket(
		family   = socketLib.AF_INET,
		type     = socketLib.SOCK_STREAM,
		protocol = socketLib.IPPROTO_TCP.
	)

	assert(url.starts_with("http://"))

	let url        = url.substring("http://")
	let host, path = url.split_at("/")
	let path       = "/" + path

	socket.connect(host, 80)

	socket.send("GET {} HTTP/1.0\r\n".format(path).encode("utf8") + 
				"Host: {}\r\n\r\n".format(host).encode("utf8"))

	let response = socket.makefile("r", encoding="utf8", newline="\r\n")
	let statusline = response.readline()
	let version, status, reason = statusline.split(" ", 2)
	if (status === "200") {
		let headers = new hash_table()
		while true:
		let line = response.readline()
		if line === "\r\n" {
			break
		}
		let header = line.split(":", 1)
		let value = line.split(":", 1)
		headers.insert(header, value)
	} else {
		switch(status):
			case "301":
				handle_301_error()
			case "400":
				handle_400_error()
			...
	}
}

// inside the request() function

let body = response.read()
socket.close()

<title>site.com</title><meta charset="utf-8"> ...

Cookies

Earlier, we mentioned that under the HTTP protocol, servers are essentially stateless. Having state, however, would be extremely useful: It allows user to pick up where they left off the last time they used the network application. While server-side state isn't feasible for extremely large applications, such applications can achieve a similiar beneft through cookies.

Generally, a cookie is a key-value pair, where the key is a host name, and the value is some integer. The cookies are kept in some container with fast read and write times — e.g., a hash table — colloquially called a cookie jar. We can imagine it as looking something like:

let COOKIE_JAR = {
	amazon: 1678,
	youtube: 8731,
	netflix: 3191
}

When the user sends an HTTP request, the server sends an HTTP response as usual. If the site uses cookies, however, the HTTP response will contain a special header called Set-Cookie. When the browser reads the response headers with its socket, it updates the cookie jar. For example, the browser might have some function that looks like:

function request() {
	...
	let url        = url.substring("http://")
	let host, path = url.split_at("/")
	let path       = "/" + path
	...

	let headers = new hash_table()
	...
	if headers.has("set-cookie") {
		let cookie = headers.get_value("set-cookie")
		COOKIE_JAR[host] = cookie
	}
}

The cookie jar is maintained, as long as the user doesn't clear it (e.g., when clearing Chrome's browser history, there's an option to clear "Cookies and other site data").

Using the example cookie jar above, let's say the site is Amazon. The user puts some items in the cart and leaves without purchasing. The next time the user visits Amazon, the browser will send an HTTP request with Cookie header:

"GET ... cookie: 1678 \n ... "

When Amazon receives this cookie, it sees the cookie field and looks up the value in its database. If it finds the value, it retrieves the user's associated data (e.g., what product number was last left in their cart). If Amazon doesn't see the cookie, it assumes that the client is an entirely new user and creates a new cookie for the user. Each time the server receives HTTP requests, it updates the data associated with the user.

Cookies make the web feel seamless and personalized. They allow developers to implement subtle and convenient features that we often take for granted — watching a YouTube video or Netflix movie right where we left off, keeping things in our shopping cart, getting suggestions in Google search, ensuring the webpage is rendered according to user preferences (e.g., executing optimizations for blind users or rendering the page according to the user's spoken language), and many others.

On the other hand, cookies also raise numerous privacy concerns. It's not always clear what data a network application tracks or shares with other applications. In 2011, the European Union enacted the General Data Protection Regulation (colloquially called the EU Cookie Law), which requires data controllers (entities that gather data from EU residents) to ask for consent before using cookies. Given how many end users there are in the EU, this has led to what's steadily becoming the Internet's bumpersticker: "We use cookies to improve your experience on our site and to show you relevant advertising."

Web Caches

As we know from computer architecture, a cache is a region of memory ${R_n}$ that serves as a larger storage area for a region ${R_{n+1}}$ closer to the processor. The closer we store data to the processor, the faster it is for the processor to process the data. This same idea extends to networking: If a particular data object is being requested so often, a typical modern server will store the data object in its cache. For example, if a server at MIT notices that some UIUC professor's lecture notes page is constantly being accessed, the MIT server will likely cache that page. This has several benefits: (1) It gives the users faster access time, and (2) it allows the server to focus on traffic that must go out beyond its LAN.