This post is based on the textbook Computer Networking: A Top-Down Approach (6th Edition) by James Kurose and Keith Ross.

1. Network Application Architectures

1.1 Client-Server Architecture

Always-on server (fixed IP)

^v

+------+------+

| Client 1 |

| Client 2 | (intermittent connection, dynamic IP possible)

| Client 3 |

+-------------+

Characteristics:

- Server is always running with a fixed IP address

- Clients do not communicate directly with each other

- **Data centers** are used for scaling

1.2 P2P Architecture

Peer1 <-----> Peer2

^v ^v

Peer3 <-----> Peer4

Every peer is both a client and a server

Characteristics:

- No (or minimal) always-on server

- **Self-scalability**: Service capacity grows as more peers join

- Examples: BitTorrent, Skype, Bitcoin

1.3 Process Communication

Network applications consist of communication between **processes** running on different end systems.

- **Client process**: The process that initiates communication

- **Server process**: The process that waits for incoming connections

- Processes access the network through **sockets**

+--------------+ +--------------+

| Application | | Application |

| Process | | Process |

| | | | | |

| Socket(door)| | Socket(door)|

+------+-------+ +------+-------+

| Transport | | Transport |

| | | <-- Internet --> | | |

| ... | | ... |

+--------------+ +--------------+

Client Server

2. HTTP Overview

2.1 What Is HTTP

**HTTP (HyperText Transfer Protocol)** is the Web's application-layer protocol.

- Follows the client-server model

- **Client**: Web browser (requests and displays web objects)

- **Server**: Web server (responds with objects)

2.2 Web Pages and Objects

Web page structure:

+-- Base HTML file

+-- JPEG image (referenced object)

+-- JavaScript file

+-- CSS stylesheet

+-- Video file

Each object is identified by a single URL.

URL structure:

http://www.example.com/path/page.html

--+-- ------+------ -----+-------

Protocol Host name Path name

2.3 Characteristics of HTTP

- Uses **TCP**: Ensures reliable delivery

- **Stateless protocol**: The server does not retain information about previous client requests

HTTP communication process:

1. Client initiates TCP connection to server port 80 (or 443)

2. TCP connection established (3-way handshake)

3. HTTP messages exchanged

4. TCP connection closed

3. Non-Persistent vs Persistent Connections

3.1 Non-Persistent HTTP

Each request/response pair is sent over a **separate TCP connection**.

Requesting a page with base HTML + 10 images:

1. TCP setup -> base HTML request/response -> TCP close

2. TCP setup -> image 1 request/response -> TCP close

3. TCP setup -> image 2 request/response -> TCP close

...

11. TCP setup -> image 10 request/response -> TCP close

-> 11 TCP connections required!

Response Time Analysis

RTT (Round-Trip Time): The time for a packet to travel from client

to server and back

Time for one object request:

Client Server

|-- SYN -------->|

|<- SYN+ACK ----| <- 1 RTT (TCP connection setup)

|-- GET -------->|

|<- File transfer| <- 1 RTT + file transfer time

| |

Total time = 2 RTT + file transfer time

3.2 Persistent HTTP

The server **keeps the TCP connection open** after sending a response.

Persistent connection:

1. TCP connection setup <- 1 RTT

2. Base HTML request/response <- 1 RTT

3. Image 1 request/response (same conn) <- 1 RTT

4. Image 2 request/response (same conn) <- 1 RTT

...

-> TCP connection is reused, reducing overhead

Pipelining

A technique where requests are sent **consecutively without waiting** for responses on a persistent connection.

Without pipelining: With pipelining:

Request 1 --> Request 1 -->

<-- Response 1 Request 2 -->

Request 2 --> Request 3 -->

<-- Response 2 <-- Response 1

Request 3 --> <-- Response 2

<-- Response 3 <-- Response 3

Total: 3 RTTs Total: approx. 1 RTT

In HTTP/1.1, **persistent connections are the default**.

4. HTTP Message Format

4.1 HTTP Request Message

GET /somedir/page.html HTTP/1.1

Host: www.example.com

Connection: close

User-Agent: Mozilla/5.0

Accept-Language: ko-KR

Request Message Structure

+----------------------------------------+

| Request line |

| Method SP URL SP Version CR LF |

+----------------------------------------+

| Header lines |

| Header-field: value CR LF |

| Header-field: value CR LF |

| ... |

| CR LF (blank line = end of headers) |

+----------------------------------------+

| Entity body |

| Used with POST method |

+----------------------------------------+

Main HTTP Methods

| Method | Purpose | Has Body |

| ------ | ------------------------------------ | -------- |

| GET | Request an object | No |

| POST | Submit form data | Yes |

| HEAD | Same as GET but returns headers only | No |

| PUT | Upload an object to a specific URL | Yes |

| DELETE | Delete an object at a specific URL | No |

4.2 HTTP Response Message

HTTP/1.1 200 OK

Connection: close

Date: Thu, 19 Mar 2026 12:00:00 GMT

Server: Apache/2.4

Content-Length: 6821

Content-Type: text/html

(data...)

Major Status Codes

| Code | Meaning | Description |

| ---- | -------------------------- | -------------------------- |

| 200 | OK | Request succeeded |

| 301 | Moved Permanently | Object permanently moved |

| 304 | Not Modified | Cached version can be used |

| 400 | Bad Request | Request format error |

| 404 | Not Found | Requested object not found |

| 505 | HTTP Version Not Supported | Unsupported HTTP version |

5. Cookies

HTTP is a stateless protocol, but websites need to identify users. **Cookies** are used for this purpose.

5.1 Four Components of Cookies

1. Set-Cookie header in HTTP response messages

2. Cookie header in HTTP request messages

3. Cookie file stored on the client (browser)

4. Back-end database on the website

5.2 How Cookies Work

First visit:

Client Server

|-- GET /index.html -->|

| | Generate cookie ID 1678

|<-- Set-Cookie: 1678 --|

| | Store record for 1678 in DB

| Browser saves cookie |

Return visit:

|-- GET /cart |

| Cookie: 1678 ---> |

| | Look up 1678 in DB

|<-- Personalized resp -|

6. Web Caching

6.1 Proxy Server

A **web cache** (or **proxy server**) is a network entity that responds to HTTP requests on behalf of the origin server.

Client --> Proxy server --> Origin server

|

Cache storage

6.2 How It Works

1. Client sends request to proxy server

2. Does the proxy have the object in cache?

+-- YES -> Return cached object to client

+-- NO -> Request from origin server -> Cache response -> Return to client

6.3 Benefits of Web Caching

Example: Institution network -> Internet access link (15 Mbps) -> Internet

Request rate: 15 requests/sec, average object size: 1 Mbit

Total request traffic: 15 Mbps

Access link utilization = 15/15 = 100% -> Queuing delay explodes!

Solution 1: Upgrade access link (100 Mbps) -> High cost

Solution 2: Install web cache (assuming 40% hit rate)

-> Access link traffic = 15 * 0.6 = 9 Mbps

-> Utilization = 9/15 = 60% -> Delay reduced!

| Solution | Access Link Utilization | Cost |

| ------------------------ | ----------------------- | --------- |

| Link upgrade (100 Mbps) | 15% | Very high |

| Web cache (40% hit rate) | 60% | Low |

7. Conditional GET

A mechanism to verify whether a cached object is up to date.

7.1 How It Works

Initial request:

Proxy -- GET /fruit.gif -----------> Server

Proxy <-- 200 OK -- Server

Last-Modified: Wed, 9 Mar 2026

Cache validation (Conditional GET):

Proxy -- GET /fruit.gif -----------> Server

If-Modified-Since:

Wed, 9 Mar 2026

Case 1: Not modified

Proxy <-- 304 Not Modified --------- Server

(No object body! Bandwidth saved)

Case 2: Modified

Proxy <-- 200 OK ------------------- Server

(New object body included)

A 304 response contains no object body, thus **saving bandwidth**.

8. HTTP Version Evolution

HTTP/1.0 (1996):

- Non-persistent connections

- GET, POST, HEAD

HTTP/1.1 (1997):

- Persistent connections (default)

- Pipelining

- Host header required

- PUT, DELETE added

HTTP/2 (2015):

- Binary framing

- Multiplexing (parallel requests/responses over a single connection)

- Header compression

- Server push

HTTP/3 (2022):

- Based on QUIC protocol (UDP)

- Solves HOL blocking

- Faster connection setup

9. Summary

HTTP Key Summary:

+-- TCP-based, stateless protocol

+-- Request-response model

+-- Non-persistent/persistent connections (persistent is default since HTTP/1.1)

+-- State management via cookies

+-- Web cache (proxy) reduces delay and saves bandwidth

+-- Conditional GET validates cache freshness

10. Review Questions

**11**. One for the base HTML file + 10 for the referenced objects = 11 TCP connections total. Each TCP connection requires 2 RTTs (1 RTT for connection setup + 1 RTT for request/response), so 22 RTTs are needed in total.

By using **cookies**. The server sends a unique identifier via a `Set-Cookie` header, the browser stores it and includes it in subsequent requests via the `Cookie` header. The server uses this cookie value to look up user information in its back-end database.

It is used to verify whether a cached object is up to date. By including an `If-Modified-Since` header in the request, the server responds with `304 Not Modified` **without the object body** if the object has not changed. This reduces unnecessary data transfer and saves bandwidth.