Application Layer

Created

Layer Responsibilities

Elaborating on the 4 layer internet model, who's responsible for what.

L4 Application

L3 Transport

  • packets should not exhaust the network
  • packets must retain their orders

L2 Network

  • packets must be delivered between networks for global delivery

L1 Link

  • bits arrive on wire
  • packets must be delivered across links and local networks

Client-Server Paradigm

The client-server paradigm is a model of interactions between the client and the server.

Server is the computer or application that responds to requests from clients.

  • always-on host
  • permanent IP address
  • often in data centers, for scaling

Clients are the user or application that initiates requests from a server.

  • make contact, communicate with server, takes initiative
  • may have dynamic IP addresses
  • do not communicate directly with each other

Examples:

  • in a web-based application, the user's browser is the client and it requests web pages from a web server
  • email clients retrieve emails from mail servers

Peer-peer Architecture

Peer-to-peer arcitecture (P2P) is a decentralized network model where individual nodes ("peers") communicate and share resources directly with each other without a central server. Each peer can act as a client and a server.

Some characteristics include:

  • server is not always on
  • arbitrary end systems directly communicate
  • peers request service from other peers, who provide service in return.
  • they are self scalable, meaning that new peers bring new service capacity and new service demands.

Example:

  • P2P file sharing.

Hypertext Transport Protocol:

HTTP is the protocol for exchanging information in the web. It's characteristics include:

  • client-server architecture, meaning that the server is always on and well known and the clients initiate contact to the server
  • synchronous request/reply protocol. It runs over TCP on Port 80.
  • stateless

HTTP Messages

The steps in HTTP request/response in timeline:

  1. client establishes connection with the server
    1. Client sends TCP SYN message to the server
    2. Server sends TCP SYN + ACK message back to client
  2. Client sends a request through a TCP ACK (marks the end of three way handshake) + HTTP GET (starts the data transmission)
  3. Server responds to the request
  4. Connection is closed at the end

Request method types in HTTP 1.1 are

  • GET, HEAD
  • POST (send information)
  • PUT (upload file to path)
  • DELETE (delete file in URL field)

The HTTP Request message is composed of:

  • request line: the method, resource, and protocol version.
  • request headers: provide information or modify request
  • carriage return line feed to indicate the end of the message
  • body: optional data (e.g., to "POST" data to server) (comes after the carriage return line)
GET /somedir/page.html HTTP/1.1
User-agent: Mozilla/4.0
Connection: close
Accept-language: fr
(blank line)
data data data data...

The HTTP Response Message has:

  • status line: protocol version, status code, status phrase
  • response headers: provide information blank line
  • body: optional data (like the requested HTML file)
HTTP/1.1 200 OK
Date: Thu, 06 Jan 2017 12:00:15 GMT
Server: Apache/1.3.0 (Unix)
Last-Modified: Mon, 22 Jun 2006
Content-Length: 6821
Content-Type: text/html
(blank line)
data data data data...

Cookies

HTTP being stateless means that each request-response is treated independently. The server does not need to maintain state.

  • Pros: improves scalability on the server-side because it's easier to handle failure, it can handle higher rate of requests, order is irrelevant
  • Cons: some applications need persistent state because you need to uniquely identify user or store temporary information (e.g., shopping cart, user profile, usage tracking)

To maintain client-side state in this stateless protocol, you can use cookies.

  • Client stores small state on behalf of server and sends the state in the future request to the server.
  • Can be used to provide authentication.
  • The timeline is as follows: 1) the user makes a request 2) the server responds with a message with Set-Cookie: XYZ 3) in future requests, the header will include Cookie: XYZ.
  • Cookies can be abused because they provide a lot of personal information, like your preferences and viewing history, which is excellent for marketing opportunities but very concerning for privacy.

Performance Goals

Performance goals and their potential solutions:

  • user should experience fast downloads and high availability
    • can be done by improving networking protocols including HTTP, TCP, etc.
    • can be done with caching and replication
  • content providers make happy users and has cost-effective infrastructure
    • exploit economies of scale like web hosting, CDNs, and data centers.
  • network (secondary) should avoid overload.
    • can be done with caching and replication

Naively, most web pages have multiple objects, so to retrieve, you could get one item at a time. This means a new TCP connection per object, which can be a lot!

So what exactly is the response time of an object request? Round-trip time (RTT) and describes the time it takes for a small packet to travel from client to server and back. It takes in total = 2RTT + Transmission time because of the following steps:

  • 1 RTT for TCP setup (TCP SYN and TCP SYN+ACK)
  • 1 RTT for HTTP request (TCP ACK + HTTP GET) and first few bytes
  • Transmission time

Here are a few strategies related to HTTP performance, named the three "P"s

Using parallel or concurrent requests and responses.

  • Pro: It would improve HTTP performance because there would be multiple connections in parallel
  • Con: It would use a lot of network and you wouldn't maintain the order of responses.
  • Good for client and content provider, bad for network

Persistent connections means to maintain a TCP connection across multiple requests.

  • Pro: allow underlying layers (e.g., TCP) to learn about RTT and bandwidth characteristics
  • Con: head-of-line (HOL) blocking and retransmitting lost TCP segments stalls object transmission
    • Head of line blocking occurs when a packet at the front or head of a queue experiences delays, so all the packets behind it in the queue are also delayed.

Pipelined requests and responses: batch requests and responses to reduce the number of packets

  • multiple requests can be contained in one TCP segment.

Linked from Computer Networks, Content Distribution Networks