146 lines
9.3 KiB
HTML
146 lines
9.3 KiB
HTML
<!doctype html>
|
|
<html lang="en" dir="ltr">
|
|
<head>
|
|
<meta charset="utf-8" />
|
|
<meta name="viewport" content="width=device-width, initial-scale=1" />
|
|
<title>WebSocket Protocol</title>
|
|
<link rel="stylesheet" href="styles.css" />
|
|
</head>
|
|
<body>
|
|
<main class="deck" id="deck">
|
|
<section class="slide active center-slide" data-title="Title">
|
|
<div class="center-content">
|
|
<h1>Websocket Protocol</h1>
|
|
<p class="subtitle">Socket Programming with a FastAPI real-time demo chat app</p>
|
|
<p class="members">Amirhossein Khalili • Morteza Khanbabaie • Alireza Khosravi</p>
|
|
</div>
|
|
<aside class="notes">Open with the project name and explain that the presentation focuses on WebSocket concepts through a simple chatroom implementation.</aside>
|
|
</section>
|
|
|
|
<section class="slide" data-title="Timeline">
|
|
<h2>WebSocket History Timeline</h2>
|
|
<p class="subtitle">The communication model evolved from simple request/response to persistent real-time channels.</p>
|
|
<div class="timeline-only glass-panel">
|
|
<div class="timeline-method"><span>Classic HTTP</span><small>1991</small></div>
|
|
<div class="timeline-method"><span>Polling</span><small>1995+</small></div>
|
|
<div class="timeline-method"><span>Long Polling</span><small>2006</small></div>
|
|
<div class="timeline-method"><span>WebSocket</span><small>2011</small></div>
|
|
<div class="timeline-method"><span>Real-time Web</span><small>2010s+</small></div>
|
|
</div>
|
|
<aside class="notes">Use this slide to name the major approaches only. The next slides explain how each mechanism works and what it costs.</aside>
|
|
</section>
|
|
|
|
<section class="slide protocol-slide" data-title="HTTP">
|
|
<h2>HTTP</h2>
|
|
<p class="subtitle">A short-lived request/response cycle with no native live push.</p>
|
|
<div class="protocol-layout">
|
|
<div class="protocol-visual glass-panel">
|
|
<img src="assets/http-mechanism.svg" alt="HTTP request response mechanism" />
|
|
</div>
|
|
<div class="protocol-points glass-panel">
|
|
<article><b>Mechanism</b><ul><li>One request returns one response</li><li>The connection closes after the exchange</li></ul></article>
|
|
<article><b>Cost</b><ul><li>Every update needs a new HTTP cycle</li><li>The server cannot push live data by itself</li></ul></article>
|
|
</div>
|
|
</div>
|
|
<aside class="notes">HTTP is excellent for normal pages, forms, and APIs. Its basic model is not optimized for continuous server-to-client updates.</aside>
|
|
</section>
|
|
|
|
<section class="slide protocol-slide" data-title="Polling">
|
|
<h2>Polling</h2>
|
|
<p class="subtitle">The browser repeatedly asks the server for new data.</p>
|
|
<div class="protocol-layout">
|
|
<div class="protocol-visual glass-panel">
|
|
<img src="assets/polling-mechanism.svg" alt="Polling repeated request mechanism" />
|
|
</div>
|
|
<div class="protocol-points glass-panel">
|
|
<article><b>Mechanism</b><ul><li>The client checks on a fixed timer</li><li>The server answers even when nothing changed</li></ul></article>
|
|
<article><b>Cost</b><ul><li>Many empty requests waste network work</li><li>Latency depends on the timer interval</li></ul></article>
|
|
</div>
|
|
</div>
|
|
<aside class="notes">Polling is simple but wasteful. Short intervals improve latency but increase server and network cost.</aside>
|
|
</section>
|
|
|
|
<section class="slide protocol-slide" data-title="Long Polling">
|
|
<h2>Long Polling</h2>
|
|
<p class="subtitle">The server holds the request until an update is available.</p>
|
|
<div class="protocol-layout">
|
|
<div class="protocol-visual glass-panel">
|
|
<img src="assets/long-polling-mechanism.svg" alt="Long Polling held request mechanism" />
|
|
</div>
|
|
<div class="protocol-points glass-panel">
|
|
<article><b>Mechanism</b><ul><li>The server keeps the request open</li><li>The client reconnects after each response</li></ul></article>
|
|
<article><b>Cost</b><ul><li>Open requests consume server state</li><li>Reconnect and timeout handling is required</li></ul></article>
|
|
</div>
|
|
</div>
|
|
<aside class="notes">Long Polling reduces empty responses compared with Polling, but it still works through repeated HTTP request cycles.</aside>
|
|
</section>
|
|
|
|
<section class="slide protocol-slide" data-title="WebSocket">
|
|
<h2>WebSocket</h2>
|
|
<p class="subtitle">An HTTP Upgrade creates one persistent Full-duplex channel.</p>
|
|
<div class="protocol-layout">
|
|
<div class="protocol-visual glass-panel">
|
|
<img src="assets/websocket-handshake.svg" alt="HTTP Upgrade Handshake" />
|
|
</div>
|
|
<div class="protocol-points glass-panel">
|
|
<article><b>Mechanism</b><ul><li>HTTP Upgrade switches the protocol</li><li>Frames move both ways on one socket</li></ul></article>
|
|
<article><b>Cost</b><ul><li>Each client keeps a live connection</li><li>Scaling needs connection-aware design</li></ul></article>
|
|
</div>
|
|
</div>
|
|
<aside class="notes">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.</aside>
|
|
</section>
|
|
|
|
<section class="slide image-slide" data-title="OSI">
|
|
<h2>WebSocket in the OSI Model</h2>
|
|
<p class="subtitle">Application semantics at Layer 7, reliable byte delivery through TCP/IP.</p>
|
|
<div class="single-visual glass-panel">
|
|
<img src="assets/websocket-osi.svg" alt="WebSocket in OSI model" />
|
|
</div>
|
|
<aside class="notes">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.</aside>
|
|
</section>
|
|
|
|
<section class="slide" data-title="HTTP Versions">
|
|
<h2>HTTP Versions in WebSocket</h2>
|
|
<p class="subtitle">Different HTTP versions start WebSocket connections differently.</p>
|
|
<div class="version-row point-cards detailed-version-row">
|
|
<article><span>HTTP/1.1</span><b>Upgrade + 101 Switching Protocols</b><ul><li>The browser sends a normal GET request with <code>Upgrade: websocket</code>.</li><li>The server replies <code>101 Switching Protocols</code> if it accepts.</li><li>After that, the same TCP connection carries WebSocket frames both ways.</li><li>This is the classic and easiest model to understand.</li></ul></article>
|
|
<article><span>HTTP/2</span><b>Extended CONNECT over a Stream</b><ul><li>HTTP/2 does not use the old connection-level Upgrade flow.</li><li>It uses Extended CONNECT, so WebSocket traffic lives inside one HTTP/2 stream.</li><li>Other HTTP/2 streams can share the same underlying connection.</li><li>Support depends more on servers, clients, and proxies.</li></ul></article>
|
|
<article><span>HTTP/3</span><b>CONNECT over QUIC</b><ul><li>HTTP/3 runs on QUIC over UDP instead of TCP.</li><li>WebSocket uses a CONNECT-based mapping similar in idea to HTTP/2.</li><li>QUIC streams reduce transport-level head-of-line blocking.</li><li>It is modern, but the demo is easier to explain with HTTP/1.1.</li></ul></article>
|
|
</div>
|
|
<aside class="notes">The project is best explained with HTTP/1.1 Upgrade. HTTP/2 and HTTP/3 support WebSocket through different mechanisms.</aside>
|
|
</section>
|
|
|
|
<section class="slide image-slide" data-title="FastAPI Architecture">
|
|
<h2>Project Architecture</h2>
|
|
<p class="subtitle">Browsers connect to one WebSocket endpoint; ConnectionManager groups sockets by room.</p>
|
|
<div class="single-visual glass-panel">
|
|
<img src="assets/chatroom-architecture.svg" alt="WebSocket chatroom architecture" />
|
|
</div>
|
|
<aside class="notes">Explain the code structure: FastAPI serves the frontend, the WebSocket endpoint accepts connections, and the manager stores active clients by room before broadcasting messages.</aside>
|
|
</section>
|
|
|
|
<section class="slide" data-title="Takeaways">
|
|
<h2>Keynotes and Takeaways</h2>
|
|
<p class="subtitle">The essential points to remember from the project.</p>
|
|
<div class="takeaway-grid point-cards">
|
|
<article><b>HTTP is request/response</b><ul><li>Simple</li><li>Stateless</li><li>Not ideal for live push</li></ul></article>
|
|
<article><b>Polling simulates real-time</b><ul><li>Easy</li><li>Wasteful</li><li>Interval-based latency</li></ul></article>
|
|
<article><b>WebSocket keeps a channel</b><ul><li>Persistent</li><li>Full-duplex</li><li>Low latency</li></ul></article>
|
|
<article><b>Server design matters</b><ul><li>Connection state</li><li>Disconnect handling</li><li>Scaling strategy</li></ul></article>
|
|
</div>
|
|
<aside class="notes">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.</aside>
|
|
</section>
|
|
</main>
|
|
|
|
<div class="controls" aria-hidden="true">
|
|
<button id="prev" title="Previous"><</button>
|
|
<span id="counter">1 / 10</span>
|
|
<button id="next" title="Next">></button>
|
|
</div>
|
|
<div class="hint">Left / Right to move - N for notes - F for fullscreen</div>
|
|
<div class="progress"><span id="progressBar"></span></div>
|
|
<div class="speaker-notes" id="speakerNotes"></div>
|
|
<script src="script.js"></script>
|
|
</body>
|
|
</html>
|