The Web and network applications

Picture two things you do before lunch. You open a KFUPM page in a browser. Then your mail program hands a message to the KFUPM mail server over SMTP. Both need the Internet. Only the first one is the Web. Getting this distinction right is the first step to thinking clearly about applications.

Infrastructure and the services built on it

The Internet is the infrastructure: the TCP/IP stack, the routers and the providers that carry packets. The World Wide Web (WWW) is one application built on top of that infrastructure. What makes something "the Web" is that it fetches linked resources using HTTP. MDN puts it plainly: "The Internet is an infrastructure, whereas the Web is a service built on top of the infrastructure."

History makes the order of events obvious. The Internet was carrying remote logins, email and file transfers for years before anyone had heard of a web page.

What counts as a network application

Once the Web is seen as one application among many, the natural next question is what the whole family looks like. Open HungerStation on your phone and order dinner. The app on your phone (the Client) sends the order across the Internet to the company's backend (the Server), which passes it to the restaurant and a courier. Without the network the app is just a menu picture.

The lecture's definition of a Network application is broad on purpose: any application that uses the Internet as its transport medium. That phrase has a precise meaning in the stack you met in part 03. The application hands its messages to the Transport layer through the Socket API, and everything below that line is someone else's job. What the messages mean is decided by the application.

Familiar apps hide an interesting mix. Some run inside a browser, some are native programs, and one exchanges its files with other users instead of a company server. Try sorting them yourself before reading the table.

uTorrent is the odd one out. It speaks the BitTorrent protocol, where the specification says that when many people download the same file at once, "the downloaders upload to each other". Each copy of the program acts as a client and a server at the same time. This arrangement is called peer-to-peer, and it returns in the next concept when we ask what decentralized means.

The protocol decides the circle

A useful picture, adapted from Connolly and Hoar's Fundamentals of Web Development, draws the Internet as a large circle with several smaller circles inside it: the Web, email, online gaming and FTP.

The rule for deciding which circle an application belongs to is its Application layer Protocol. If it speaks HTTP to fetch web resources, it is in the Web circle. If it speaks SMTP to move mail between servers, FTP to move files, or a custom game protocol, it sits in a sibling circle. Siblings share the Internet but not the Web. The circle sizes are illustrative only; they make no claim about traffic shares.

Email is a good exam trap. When you read Gmail in a browser tab, your browser talks HTTP to Google, which is the Web. When Google then delivers your message to a KFUPM mail server, the two mail servers speak SMTP, which is not the Web. One everyday "email" experience touches two circles.

Take one calculator and build it three ways. First, a desktop calculator: one program on one machine. Second, a browser page that sends "2+3" over HTTP to a separate server program, which sends back 5. Third, the same service, but the server's work and data are spread over several machines, with addition on one node and the history database on another.

By the lecture's definitions, the first build is neither decentralized nor distributed. The second is a Decentralized application: the application is split into two standalone components (Client and Server), usually on different machines, that talk through a Protocol using sockets. It is also a Distributed application in the lecture's sense, because computation is shared between client and server and state lives on both. The third build pushes distribution further: the server's own computation and data are spread over several machines.

Keep these two questions apart, because they become the two axes of the design space in the next concept: decentralization is the vertical axis, distribution the horizontal one.

The lecture's examples fit. BitTorrent and Bitcoin have no single controlling center: the Bitcoin paper opens with the goal of sending payments "directly from one party to another without going through a financial institution". Google Cloud is one provider that spreads computation and state across its own machines in many regions and zones around the world.

So far "the server" has been a single word. Look inside the calculator's server side and it turns out to be several separate pieces, and that discovery is what makes edge computing possible: separate pieces can live in separate places.

The server side is a set of components

Follow one request. The Client sends "multiply 6 by 7". It does not know or care how the server side is organized. It simply knocks on one door. That door is the API gateway, a single entry point that receives every client request and routes it to the right service. AWS describes its own gateway product as a "front door" for applications to reach backend services. Behind it sit four operation services (Add, Sub, Mul, Div), each exposing its own Interface, like a small Web API, and each able to read or write a Database.

Everything except the client forms the Server layer, typically hosted in the Cloud. But nothing forces those components to live together. Because each one is a separate program with its own interface, Mul could run close to the user while the Database stays in a large data center. The question becomes: can we assign server components to different layers, and if so, how do we describe and justify the assignment?

Two coordinates for every component

The answer is a grid that works like a seating chart. "Mul sits on Layer 1 using Compute 1." "The Database sits on Layer 3 using Compute 2 plus Storage." Every component gets two coordinates.

The two-dimensional design space separates two independent decisions about each Component, and they are exactly the two questions from the previous concept. Moving a box up or down changes its Layer: that is the decentralization axis, how far the server side is split across layers. Moving a box left or right changes the resource it uses on that layer: Compute 1, or Compute 2, which can also offer storage (only the Database uses it). That is the distribution axis, how computation and state are spread across resources.

A column is a type, each layer has its own instance

One subtlety makes the grid precise. A column names a resource type, not a machine. Each layer has its own copies of those types, and the lecture marks them with suffixes: Compute 2_a + Storage_a on the Database, Compute 1_b on Add, and Compute 2_b on Sub. The letter tells you which layer's copy: _a belongs to Layer 3 and _b belongs to Layer 2. So Add and Sub share a layer, but run on two different instances.

This is what makes the application a Distributed application in practice: the same kind of resource exists as several instances in different places, and the application's computation and state are spread across them. "Compute 2" could be a virtual machine type in a Cloud region, a server in a Fog micro data center, or a box at the Edge.

Criteria for assigning components to layers

The grid tells you how to write a placement down. It does not tell you which placement is good. For that the lecture asks: what criteria decide which layer a component goes on? There is no single right answer, only trade-offs. Each criterion pushes a component in a direction.

The evidence behind the table comes from the edge computing literature. Satyanarayanan writes that "reliance on a cloud datacenter is not advisable for applications that require end-to-end delays to be tightly controlled to less than a few tens of milliseconds." NIST adds that Fog computing "minimizes the request-response time" by working close to end devices. So a time-critical component moves toward the Edge, lowering Latency and Response time (RT).

The pull goes the other way too. Heavy computation and durable, shared data need resources that shrink as you go down the layers, which is why the Database sits on the top layer. Satyanarayanan also notes that analyzing raw data near its source cuts the bandwidth sent to the cloud, that a nearby cloudlet "can enforce the privacy policies of its owner prior to release of the data to the cloud", and that local resources give the "ability to mask transient cloud outages". Google Cloud, for its part, sells regions partly so data can stay resident inside a country's borders.

Placing components on layers only works because they can talk to each other across a network. So zoom in on one conversation. Open the calculator in a browser and press equals. The front-end JavaScript sends GET /add?a=2&b=3. A Node.js back-end reads that request from its socket, computes 5, and writes the response back. Along the way the bytes travel through routers you will never see.

Three levels in one conversation

At the top is the application conversation: an HTTP request and response. In the middle are the endpoints, the sockets. At the bottom is the network path through the Internet. The Frontend runs in the browser, and the Backend runs in Node.js.

RFC 9110, the HTTP standard, defines the roles by behavior. A Client "is a program that establishes a connection to a server for the purpose of sending one or more HTTP requests". A Server "is a program that accepts connections in order to service HTTP requests by sending HTTP responses". And HTTP itself "is a stateless request/response protocol for exchanging messages across a connection".

Sockets are endpoints, connections are pairs

A socket is named by an IP address plus a Port number. The connection is the pair of sockets, one at each end, as in this example using documentation addresses:

The HTTP arrow is logical, the bytes move vertically

Protocol pictures usually draw a dashed arrow between the two HTTP boxes, as if browser and server talked to each other directly. They do, but only logically. No HTTP byte ever travels sideways along that arrow.

The real journey is vertical. The browser writes an HTTP message. It goes down through TCP on the client and the Socket, into the TCP/IP network (the "pipe"), and back up through TCP on the server until Node.js reads it. This is Encapsulation from part 03: each layer wraps the data on the way down and unwraps it on the way up. Peer layers "talk" to each other only through that round trip.

The same picture also shows who owns what. The Application layer (AL) is the web application, written by developers: HTML, CSS and JavaScript in the Frontend, and Node.js in the Backend. The Transport layer (TL), Network layer (NL), Data link layer (DLL) and Physical layer (PL) are infrastructure, provided by the operating system, network cards, cables and routers. That split is the same line that defined a network application in the first concept: the app owns meaning, the infrastructure owns delivery.

Step back from a single message to the rhythm of the whole exchange. Your browser asks the calculator for a result. The server wakes up, spends processor time computing it, reads and writes the history, and sends bytes back. Then it waits for the next request. It never phones you first.

That cycle is the Request-response loop. The Client initiates, and the Server only responds. RFC 9110 builds HTTP around exactly this pattern: a client sends a request message, and a server answers it with a response message.

Every response has a price

This is where the part comes full circle. Preparing each response costs the server three resources. Compute is the processor time, which you will later measure as Processing time (PT). Storage is reading and writing data. Communication is sending the response back over the network. For one user that is trivial. Multiply it by, say, 10,000 users pressing equals at once, and those three costs decide where each component in the design space should live.

It is also why placement matters to users. The time a user waits, the Response time (RT), is the trip to the server, the processing, and the trip back. NIST describes Fog computing as a way to minimize the request-response time. Moving the right component closer shortens the loop.