The Little Server That Could
summary
Builds a tiny Ruby web server that answers curl requests by opening an Inet TCP socket, parsing HTTP (notes C parsers like Zed Shaw’s ragel/state-machine approach), and calling a Rack app to return status headers body. Demonstrates blocking external calls with a 5s sleep that serializes clients, shows concurrency via socket.accept creates a new socket for each client and via fork + close parent FD or hit too many open files, and explains how Ruby 2 GC enables copy-on-write and why SIGKILL cannot be trapped.
AI-written summary · about
chapters (22)
- 0:00Start
- 1:56Abstractions are
- 3:16Servers are an Abstraction
- 3:38Servers are not Magic
- 5:19How is it different?
- 5:384.68 Billion Indexed Web Pages
- 6:08How is this possible?
- 6:18C Worldwide Web Consortium
- 6:29HTTP as an API
- 7:15Zero or more header lines 3. Blank line 4. Message body (optional)
- 10:06How does it communicate?
- 13:15Defining our Socket: 1. Addressing Format 2. Kind of socket
- 13:43TCP Three-Way Handshake
- 16:27Listen for requests
- 18:17Parser
- 20:18Rack Interface
- 23:36Forking
- 26:11Wait...won't fork double my memory that I'm consuming?
- 27:23Garbage Collection
- 29:51Benefits of Threading: - Uses less memory -Threads die with process - Much faster to communicate
- 32:15Why use a multi-threaded server with MRI?
- 32:46Downsides of Threading: - Your code has to be thread safe - Your gems have to be thread safe
related talks
35mThe little server that could
35mLet's build a simple HTTP server with Ruby
29mRuby Systems Programming
26mTCP Sockets Programming in Ruby
36mBuilding a Ruby web app using the Ruby Standard Library
18mThere is no Magic: Write your own HTTP server, and then stop
37mRuby on Rack: The Magic Between Request and Response
26mConcurrency in Ruby: From fork() to Fiber