# Websocket Protocol

Socket Programming with a FastAPI real-time demo chat app

Amirhossein Khalili • Morteza Khanbabaie • Alireza Khosravi

Open with the project name and explain that the presentation focuses on WebSocket concepts through a simple chatroom implementation.

## WebSocket History Timeline

The communication model evolved from simple request/response to persistent real-time channels.

Classic HTTP 1991
Polling 1995+
Long Polling 2006
WebSocket 2011
Real-time Web 2010s+
Use this slide to name the major approaches only. The next slides explain how each mechanism works and what it costs.

## HTTP

A short-lived request/response cycle with no native live push.

Mechanism

- One request returns one response
- The connection closes after the exchange

Cost

- Every update needs a new HTTP cycle
- The server cannot push live data by itself

HTTP is excellent for normal pages, forms, and APIs. Its basic model is not optimized for continuous server-to-client updates.

## Polling

The browser repeatedly asks the server for new data.

Mechanism

- The client checks on a fixed timer
- The server answers even when nothing changed

Cost

- Many empty requests waste network work
- Latency depends on the timer interval

Polling is simple but wasteful. Short intervals improve latency but increase server and network cost.

## Long Polling

The server holds the request until an update is available.

Mechanism

- The server keeps the request open
- The client reconnects after each response

Cost

- Open requests consume server state
- Reconnect and timeout handling is required

Long Polling reduces empty responses compared with Polling, but it still works through repeated HTTP request cycles.

## WebSocket

An HTTP Upgrade creates one persistent Full-duplex channel.

Mechanism

- HTTP Upgrade switches the protocol
- Frames move both ways on one socket

Cost

- Each client keeps a live connection
- Scaling needs connection-aware design

This is the key WebSocket slide. The browser starts with HTTP, upgrades the connection, and then both client and server can send frames whenever needed.

## WebSocket in the OSI Model

Application semantics at Layer 7, reliable byte delivery through TCP/IP.

WebSocket is an application-layer protocol. It uses TCP for reliable transport and IP for routing. The lower layers do not know what a chat message or room is.

## HTTP Versions in WebSocket

Different HTTP versions start WebSocket connections differently.

HTTP/1.1 Upgrade + 101 Switching Protocols

- The browser sends a normal GET request with `Upgrade: websocket`.
- The server replies `101 Switching Protocols` if it accepts.
- After that, the same TCP connection carries WebSocket frames both ways.
- This is the classic and easiest model to understand.

HTTP/2 Extended CONNECT over a Stream

- HTTP/2 does not use the old connection-level Upgrade flow.
- It uses Extended CONNECT, so WebSocket traffic lives inside one HTTP/2 stream.
- Other HTTP/2 streams can share the same underlying connection.
- Support depends more on servers, clients, and proxies.

HTTP/3 CONNECT over QUIC

- HTTP/3 runs on QUIC over UDP instead of TCP.
- WebSocket uses a CONNECT-based mapping similar in idea to HTTP/2.
- QUIC streams reduce transport-level head-of-line blocking.
- It is modern, but the demo is easier to explain with HTTP/1.1.

The project is best explained with HTTP/1.1 Upgrade. HTTP/2 and HTTP/3 support WebSocket through different mechanisms.

## Project Architecture

Browsers connect to one WebSocket endpoint; ConnectionManager groups sockets by room.

Explain the code structure: FastAPI serves the frontend, the WebSocket endpoint accepts connections, and the manager stores active clients by room before broadcasting messages.

## Keynotes and Takeaways

The essential points to remember from the project.

HTTP is request/response

- Simple
- Stateless
- Not ideal for live push

Polling simulates real-time

- Easy
- Wasteful
- Interval-based latency

WebSocket keeps a channel

- Persistent
- Full-duplex
- Low latency

Server design matters

- Connection state
- Disconnect handling
- Scaling strategy

End with the central idea: WebSocket is useful when real-time bidirectional communication matters, but it moves responsibility to the server to manage long-lived connections.
1 / 10
Left / Right to move - N for notes - F for fullscreen