Skip to content

02. Application Layer

$\gdef \N{\mathbb{N}} \gdef \Z{\mathbb{Z}} \gdef \Q{\mathbb{Q}} \gdef \R{\mathbb{R}} \gdef \C{\mathbb{C}} \gdef \setcomp#1{\overline{#1}} \gdef \sseq{\subseteq} \gdef \pset#1{\mathcal{P}(#1)} \gdef \covariant{\operatorname{Cov}} \gdef \of{\circ} \gdef \p{^{\prime}} \gdef \pp{^{\prime\prime}} \gdef \ppp{^{\prime\prime\prime}} \gdef \pn#1{^{\prime\times{#1}}} $

What is a network app?

  • It runs on different end systems
  • It communicates over the network
  • It is not directly managing the network internals (routing, transmitting, host resolving, etc)

Client-Server Paradigm
The server is

  • always on and connected to the network
  • given a permanent IP address (not really required, but a real pain if you don’t have this)
  • waiting for clients to make requests
  • often found in data centers
    The client
  • initiates contact with the server
  • may be intermittently connected
  • may have a dynamic IP
  • does not directly communicate with other clients
    Examples
  • HTTP
  • IMAP
  • FTP

Peer to Peer Paradigm

  • It’s a decentralized paradigm
  • No “always on” server
  • arbitrary end systems directly communicate (unlike clients in a client-server network)
  • Network is self scaling – the capacity of the network is directly proportional to the number of peers, which is directly proportional to the demand on the network. (new peers bring both demand and supply to the network)
  • Peers are intermittently connected and change IP’s
    Example: P2P File Sharing (BitTorrent)

Messages

Processes

A process is a program running within a host.
Processes in different hosts communicate by exchanging messages

Important Word Alert

A message is the name of what is sent between processes communicating on different hosts. It is specific to the Application Layer.

A client process is the process that initiates the communication, and a server process is a process that waits to be contacted. Even applications with P2P architecture have client and server processes.

Sockets

A process will receive/send messages from its socket.
A socket is analogous to a door

  • The ‘sending’ process will put a message though the door/socket
  • The processes rely on transport infrastructure between doors to deliver the message
  • The ‘receiving’ process will (if everything worked properly) receive the message at its door.
    Note, there are two sockets involved here, one for each host.
    The host device has a 32-bit (theoretically) unique IP address.
    To receive a message, a process must have an identifier, which includes the IP address and the port number associated with the process on the host.

Application Layer Protocol

An A.L.P. defines the

  • Types of messages exchanged
    • Eg. request, response
  • Message syntax
    • what fields are allowed, and how fields are delineated
  • Message semantics
    • what each field means
  • Rules for when and how messages are transmitted

Open protocols are defined in RFCs, and everyone has access to the protocol definition. This allows for interoperability and extensibility. Examples of this are HTTP, SMTP.

Proprietary protocols are not publicly defined. Examples of this are Skype, iMessage, Zoom.

Transport Service requirements

Different applications have different requirements for the handling of the data transmission. There are four primary categories:

  • Data Integrity
    • The data must be 100% reliable
    • Required by file transfers, web transactions
    • Not (always) required by audio, can tolerate compression or very minor corruption
  • Timing
    • The data must be delivered very quickly
    • Required by online multiplayer games
    • Not required for file transfers
  • Throughput
    • The system must have a certain bandwidth
    • Required by audio/video streaming
    • Not required by email
  • Security
    • The data is sensitive and must be encrypted, and must not be modified

Internet Transport Protocol Services

The TCP service offers

  • Reliable transport between processes
  • Flow control so the receiver isn’t overwhelmed by the sender
  • Congestion control so the sender will be throttled if the network is overloaded
  • Connection orientated communication – There’s a procedure for initiating communication between client and server
    But does not provide timing, minimum throughput guarantee, or security
    The UDP service offers unreliable data transfer between processes.
    UDP does not provide reliability, flow control, congestion control, timing, throughput guarantee, security, or connection orientation.
Securing TCP

Regular TCP/UDP packets have no encryption. This means that cleartext passwords sent into a socket traverse the Internet in cleartext!

The Transport Layer Security (TLS) provides encrypted TCP connections, data integrity, and end-point authentication.
TLS is implemented in the application layer. Apps use TLS libraries, so when they send cleartext into a ‘socket’ through the TLS library, it is automatically encrypted before actually going out the socket.

HTTP

  • Web pages consist of objects, each of which can be stored on different web servers.
  • Objects can be HTML files, JPEG images, Java applets, audio files, etc.
  • A web page consists of a base HTML file, which include several referenced objects, each of which are addressable by a URL:
\[\underbrace{\text{www.domain.com}}_{\text{host name}}\underbrace{\text{/somePath/image.png}}_{\text{path name}}\]
HTTP Overview
  • HTTP stands for HyperText Transfer Protocol
  • It is the web’s application-layer protocol
  • Uses the client-server paradigm
    • client is a browser that requests, receives and renders web objects
    • server is a process that sends objects in response to requests
  • The flow is:
    • Client initializes TCP connection (creates socket) to server on port 80
    • The server accepts TCP connection from client
    • HTTP messages (application layer) are exchanged between browser and server
    • TCP connection closed
  • HTTP is “stateless”, meaning that there is no “memory” of old requests that affect the next request
Persistent and Non-Persistent HTTP

There are two types of HTTP connections:

  • Persistent HTTP
    • TCP connection opened to server
    • Multiple objects can be sent over a single TCP connection between client and server
    • TCP connection closed
  • Non Persistent HTTP
    • TCP connection established
    • At most one object sent over TCP connection
    • TCP connection closed
    • Downloading multiple objects requires multiple connections

RTT (Round Trip Time) is the time for a packet to travel from a client to a server and back again.
HTTP Response Time (per object) is the cumulative time for opening a TCP connection, making a request, and receiving an object. HTTP RT = \(2\cdot RTT+\) File Transmission Time.
Pasted image 20240117155612.png
Problems with Non-Persistent HTTP:

  • It requires 2 RTTs per object
  • OS overhead for each new TCP connection
  • Browsers often open multiple parallel TCP connections to fetch referenced objects in parallel

Persistent HTTP:

  • Server leaves connection open after sending response
  • Subsequent HTTP messages between a client/server session are sent over the open connection
  • Client sends requests as soon as it encounters a referenced object
  • As little as one RTT for each referenced object, cutting the response time in half
HTTP Messages

There are two types of HTTP messages:

  • Request
  • Response

HTTP request message is sent in ASCII, and is comprised of a Request Line, Header Lines, and a terminating \r\n carriage return and newline to indicate the end of the request.

Excalidraw Excalidraw

Other HTTP Request Messages
  • POST
    • For submitting forms, usually contains user input
    • Data sent in the entity body of the POST request
  • GET
    • Data is sent in the URL of the GET request
    • http://www.somesite.com/animalsearch?monkeys&banana
  • HEAD
    • It’s the same as a GET request, but it asks the server to strip the entity body from the response (the server only sends back the headers of the reply)
  • PUT
    • Uploads a new object to the server
HTTP Response Statuses
Code Meaning
200 OK
301 Moved Permanently
400 Bad Request
404 Not Found
505 HTTP Version Not Supported
Maintaining State – Cookies

Since HTTP is stateless, if we want to preserve data between sessions, we use cookies. (For example, this will let a user stay authenticated between multiple HTTP Requests)

There are four components of such a setup:

  1. The cookie header in the response from the server to the client, after the first request
  2. The cookie header in the next HTTP request from the client
  3. The cookie is stored locally on the user’s host (usually managed by the browser)
  4. A cookie database managed by the backend to validate session cookies
    Pasted image 20240129162733.png