79:T456,Every HTTP/2 frame follows a precise binary structure. Understanding this structure is essential for grasping how HTTP/2 achieves its performance characteristics. **The Fixed Frame Header:** Every HTTP/2 frame begins with a 9-byte header: ``` +-----------------------------------------------+ | Length (24 bits) | +---------------+---------------+---------------+ | Type (8) | Flags (8) | +-+-------------+---------------+-------------------------------+ |R| Stream Identifier (31) | +=+=============================================================+ | Frame Payload (0 to 2^24-1 bytes) | +---------------------------------------------------------------+ ``` This fixed structure is the key to HTTP/2's parsing efficiency. Upon receiving data, a parser knows immediately: - **Bytes 0-2 (Length)**: Exactly how many payload bytes follow - **Byte 3 (Type)**: What kind of frame this is - **Byte 4 (Flags)**: Type-specific control bits - **Bytes 5-8 (Stream ID)**: Which logical stream this frame belongs to7a:T40a,**HEADERS Frames (0x1):** HEADERS frames carry HTTP headers—both request headers (method, path, authority) and response headers (status code, content-type). Headers are compressed using HPACK. ``` +---------------+ |Pad Length? (8)| +-+-------------+-----------------------------------------------+ |E| Stream Dependency? (31) | +-+-------------+-----------------------------------------------+ | Weight? (8) | +-+-------------+-----------------------------------------------+ | Header Block Fragment (*) | +---------------------------------------------------------------+ | Padding (*) | +---------------------------------------------------------------+ ``` Critical flags: - **END_STREAM**: No more data follows (complete request, or response with no body) - **END_HEADERS**: This frame completes the header block (no CONTINUATION follows) - **PRIORITY**: Stream dependency and weight fields are present7b:T7d4,**Stream Lifecycle:** Every stream progresses through a well-defined state machine: ``` +--------+ send PP | | recv PP ,--------+ idle +--------.___ / | | v +--------+ v +----------+ | +----------+ | | | send H / | | ,------+ reserved | | recv H | reserved +-----. | | (local) | | | (remote) | | | +----------+ v +----------+ | | | +--------+ | | | | recv ES | | send ES | | | send H | ,-------+ open +-------. | recv H | | | / | | \ | | | v v +--------+ v v | | +----------+ | +----------+ | | | half | | | half | | | | closed | | send R / | closed | | | | (remote) | | recv R | (local) | | | +----------+ | +----------+ | | | | | | | | send ES / | recv ES / | | | | send R / v send R / | | | | recv R +--------+ recv R | | | send R / `----------->| |<-----------' send R /| | recv R | closed | recv R | `----------------------->| |<----------------------' +--------+ ``` Key states: - **idle**: Initial state; stream hasn't been used - **open**: Both sides can send frames - **half-closed**: One side has finished sending - **closed**: Stream is complete; resources can be reclaimed7c:T639,Binary framing isn't just a performance optimization—it's the **foundation** that enables every other HTTP/2 feature. Let's trace how each major feature depends on the frame structure: **1. Multiplexing (enabled by Stream Identifiers)** The Stream Identifier in every frame header allows frames from different requests to interleave on a single connection. Without binary framing, demultiplexing would require complex parsing of text message boundaries—exactly the problem HTTP/1.1 pipelining couldn't solve. **2. Header Compression (enabled by HEADERS/CONTINUATION frames)** HPACK compression depends on a well-defined header block boundary. HEADERS and CONTINUATION frames provide this: the decompressor knows exactly which bytes constitute the compressed header block, enabling stateful compression across requests. **3. Server Push (enabled by PUSH_PROMISE frames)** Server push requires reserving stream IDs and sending request headers for resources the client hasn't requested. The PUSH_PROMISE frame type provides this exactly—the binary format ensures unambiguous communication of the pushed request. **4. Flow Control (enabled by WINDOW_UPDATE frames)** Precise flow control requires communicating exact byte counts. WINDOW_UPDATE frames carry 31-bit window increments—impossible to express efficiently in text format without ambiguity. **5. Stream Prioritization (enabled by PRIORITY information)** Priority dependencies and weights are numeric values that influence frame scheduling. The binary encoding in HEADERS and PRIORITY frames communicates these precisely.71:{"json":{"id":"seed_25e15499c67bf54b86bb4bc91f136ab1","slug":"http2","category":"Computer Networks","topic":"HTTP/2","title":"HTTP/2: The Modern Web Protocol","description":"Master HTTP/2, the major revision of the HTTP protocol that revolutionized web communication through binary framing, multiplexing, header compression, server push, and stream prioritization. Understand how HTTP/2 solves HTTP/1.1's fundamental limitations and enables dramatically faster web experiences.","difficulty":"INTERMEDIATE","estimatedMinutes":90,"pages":[{"id":"seed_d99a6081805144bc375b362f8827c0aa","title":"Binary Framing: The Foundation of HTTP/2","order":0,"content":[{"id":"opening-hook","title":"The Protocol Revolution","content":[{"data":{"content":"In 2015, the web underwent one of its most significant transformations since the introduction of HTTP/1.1 in 1997. After nearly two decades of incremental improvements and workarounds, HTTP/2 emerged with a radical architectural change: the replacement of HTTP's text-based protocol with a **binary framing layer**.\n\nThis wasn't merely a technical optimization—it was a fundamental reimagining of how web browsers and servers communicate. The binary framing layer is the foundation upon which every other HTTP/2 improvement is built: multiplexing, header compression, server push, and stream prioritization all depend on this architectural shift.\n\nTo truly understand HTTP/2, you must first understand binary framing. Every decision, every performance gain, and every implementation detail traces back to this core innovation."},"type":"text"},{"data":{"icon":"Target","title":"What You Will Learn","content":"By the end of this page, you will understand: (1) Why HTTP/1.1's text-based protocol became a fundamental bottleneck, (2) How binary framing transforms HTTP messages into structured frames, (3) The complete anatomy of HTTP/2 frames including headers, types, and flags, (4) How the binary layer enables all other HTTP/2 features, and (5) The practical implications for web performance and security.","variant":"info"},"type":"callout"}]},{"id":"http11-bottleneck","title":"The HTTP/1.1 Bottleneck","content":[{"data":{"content":"To appreciate binary framing, we must first understand why HTTP/1.1's text-based approach became problematic. HTTP/1.1 was designed in an era when web pages contained a handful of resources, connections were expensive, and simplicity was paramount.\n\n**The Text-Based Protocol:**\n\nHTTP/1.1 messages are human-readable text. A typical request looks like:\n\n```\nGET /index.html HTTP/1.1\\r\n\nHost: example.com\\r\n\nUser-Agent: Mozilla/5.0...\\r\n\nAccept: text/html\\r\n\nAccept-Language: en-US\\r\n\nConnection: keep-alive\\r\n\n\\r\n\n```\n\nThis text-based format was intentional. Early protocol designers valued debuggability—you could literally read HTTP traffic with tools like `telnet` or `netcat`. But this simplicity came with severe costs that weren't apparent until web complexity exploded."},"type":"text"},{"data":{"items":["**Head-of-Line Blocking** — Each connection can process only one request-response pair at a time. Even with pipelining, responses must return in order, so a slow response blocks everything behind it.","**Parsing Complexity** — Text parsing requires scanning for delimiters (CRLF sequences), handling variable-length headers, and managing edge cases in character encoding. This is computationally expensive and error-prone.","**Ambiguous Message Boundaries** — Determining where one message ends and another begins requires parsing Content-Length or Transfer-Encoding headers, with multiple fallback rules for malformed messages.","**Header Redundancy** — Every request repeats identical headers (cookies, user-agent, accept headers). A typical page might send 100+ requests, each carrying kilobytes of duplicate header data.","**Connection Limits** — Browsers limit concurrent connections per domain (typically 6). Developers invented workarounds like domain sharding, which add latency and complexity."],"title":{"icon":"AlertCircle","text":"Fundamental HTTP/1.1 Limitations","type":"icon","color":"destructive","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"icon":"AlertCircle","title":"The Scale Problem","content":"Modern web pages average 70+ resources (scripts, stylesheets, images, fonts, API calls). With HTTP/1.1's connection limits and head-of-line blocking, loading these resources efficiently requires complex workarounds: connection pooling, domain sharding, resource inlining, sprite sheets, and concatenation. Each workaround adds development complexity and often makes caching less effective.","variant":"warning"},"type":"callout"},{"data":{"content":"**The Parsing Tax:**\n\nConsider what happens when a server processes an HTTP/1.1 request:\n\n1. **Read bytes until CRLF** — Find the request line boundary\n2. **Parse request method** — Scan characters until space\n3. **Parse URI** — Scan until space, handle percent-encoding\n4. **Parse HTTP version** — Scan until CRLF\n5. **Parse headers** — Loop: read until CRLF, split on colon, handle line folding, repeat until empty line\n6. **Determine body presence** — Check method, Content-Length, Transfer-Encoding\n7. **Read body** — Either fixed-length or chunked encoding\n\nEach step involves string operations, buffer management, and careful handling of edge cases. At scale, this text parsing becomes a measurable CPU cost. More importantly, the variable-length nature of text makes it impossible to divide a stream into independent, parallel-processable units—which is exactly what binary framing solves."},"type":"text"}],"titleType":"number","titleNumber":1},{"id":"binary-framing-layer","title":"The Binary Framing Layer","content":[{"data":{"content":"HTTP/2's binary framing layer solves HTTP/1.1's fundamental problems by introducing a structured binary format between the application (HTTP semantics) and the transport (TCP). This layer doesn't change what HTTP means—GET, POST, headers, and bodies remain conceptually identical—but completely transforms how messages are encoded and transmitted.\n\n**The Key Insight:**\n\nInstead of sending HTTP messages as monolithic text blobs, HTTP/2 breaks them into small **frames** with fixed headers and well-defined boundaries. This simple change enables massive improvements:\n\n- **Frames are self-describing** — Fixed-size headers tell you exactly how many bytes to read\n- **Frames are independent** — Each frame can be processed without reference to others\n- **Frames can be interleaved** — Multiple requests/responses share one connection simultaneously\n- **Frames enable efficient encoding** — Binary representations are compact and fast to parse"},"type":"text"},{"data":{"height":"400px","mermaidSyntax":"flowchart TB\n subgraph HTTP1[\"HTTP/1.1: Text Protocol\"]\n REQ1[\"GET /index.html HTTP/1.1\nHost: example.com\nUser-Agent: Mozilla...\nAccept: text/html\n\n\"]\n REQ2[\"GET /style.css HTTP/1.1\nHost: example.com\n...\"]\n end\n \n subgraph HTTP2[\"HTTP/2: Binary Framing\"]\n F1[\"Frame: HEADERS\n9 bytes fixed header\n+ compressed headers\"]\n F2[\"Frame: DATA\n9 bytes fixed header\n+ body chunk\"]\n F3[\"Frame: HEADERS\n9 bytes fixed header\n+ compressed headers\"]\n F4[\"Frame: DATA\n9 bytes fixed header\n+ body chunk\"]\n end\n \n REQ1 --> |\"Entire message\nmust complete\nbefore next\"| REQ2\n F1 --> F3\n F2 --> F4\n F1 -.-> |\"Interleaved\non same\nconnection\"| F2\n F3 -.-> F4"},"type":"mermaid-excalidraw"},{"data":{"icon":"Lightbulb","title":"Binary ≠ Unreadable","content":"HTTP/2's binary format doesn't mean you can't debug it. Tools like Wireshark, Chrome DevTools, and nghttp2 decode frames into readable representations. The 'binary' designation refers to the wire format—the structured byte layout that enables efficient parsing and multiplexing. HTTP semantics (methods, headers, status codes) remain identical to HTTP/1.1.","variant":"tip"},"type":"callout"},{"data":{"content":"**The Layering Architecture:**\n\nHTTP/2 introduces a clean separation of concerns:\n\n```\n┌─────────────────────────────────────┐\n│ HTTP Semantics (Application) │\n│ GET, POST, Headers, Status Codes │\n├─────────────────────────────────────┤\n│ Binary Framing Layer (HTTP/2) │\n│ Frames, Streams, Flow Control │\n├─────────────────────────────────────┤\n│ Transport Layer (TCP/TLS) │\n│ Reliable, Ordered Byte Stream │\n└─────────────────────────────────────┘\n```\n\nThis layering means that application developers continue using familiar HTTP concepts—request methods, headers, response codes—while the binary framing layer handles efficient transmission transparently. The transition from HTTP/1.1 to HTTP/2 requires no changes to application logic, only infrastructure updates."},"type":"text"}],"titleType":"number","titleNumber":2},{"id":"frame-structure","title":"Frame Structure and Anatomy","content":[{"data":{"content":"$79"},"type":"text"},{"data":{"rows":[["Length","24 bits","Length of the frame payload (excluding the 9-byte header)","Max 16,384 bytes by default; can be increased via SETTINGS"],["Type","8 bits","Defines the format and semantics of the frame","10 defined types (0x0-0x9); unknown types must be ignored"],["Flags","8 bits","Boolean flags specific to the frame type","Undefined flags must be ignored; preserves extensibility"],["R (Reserved)","1 bit","Reserved for future use","Must be 0; receivers ignore this bit"],["Stream Identifier","31 bits","Unique identifier for the stream this frame belongs to","0 for connection-level frames; odd=client-initiated, even=server-initiated"]],"caption":"HTTP/2 Frame Header Fields","headers":["Field","Size","Description","Constraints"]},"type":"table"},{"data":{"content":"**Why This Structure Matters:**\n\nThe fixed 9-byte header provides several critical properties:\n\n1. **Predictable Parsing** — No scanning for delimiters. Read 9 bytes, extract fields with bit operations, read `Length` payload bytes. Done.\n\n2. **Stream Demultiplexing** — The Stream Identifier allows frames from different requests/responses to be interleaved. A single TCP connection can carry thousands of concurrent streams.\n\n3. **Efficient Buffering** — Knowing the exact payload length before reading allows optimal buffer allocation—no over-allocation or reallocation during parsing.\n\n4. **Protocol Extensibility** — Unknown frame types and flags must be ignored, allowing the protocol to evolve without breaking existing implementations.\n\n5. **Connection vs. Stream Frames** — Stream ID 0 indicates connection-level frames (SETTINGS, PING, GOAWAY), while non-zero IDs indicate stream-specific frames."},"type":"text"},{"data":{"icon":"Info","title":"The 16KB Default Limit","content":"By default, frame payloads are limited to 16,384 bytes (16KB). This limit balances efficiency (larger frames reduce header overhead) against interleaving fairness (smaller frames allow finer-grained multiplexing). The SETTINGS frame allows endpoints to negotiate larger limits, up to 16MB (2^24-1 bytes), though most implementations use conservative values.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":3},{"id":"frame-types","title":"Frame Types in Detail","content":[{"data":{"content":"HTTP/2 defines ten frame types, each serving a specific purpose in the protocol. Understanding these types reveals how HTTP semantics map to the binary layer.\n\n**Core Frame Types:**"},"type":"text"},{"data":{"rows":[["DATA","0x0","Carries request/response body data","Subject to flow control; can be split across multiple frames"],["HEADERS","0x1","Carries HTTP headers (request/response)","Compressed with HPACK; may include priority information"],["PRIORITY","0x2","Specifies stream priority","Deprecated in favor of HEADERS priority; rarely used now"],["RST_STREAM","0x3","Immediately terminates a stream","Contains error code; enables fast error recovery"],["SETTINGS","0x4","Configuration parameters for connection","Must be acknowledged; sent in both directions"],["PUSH_PROMISE","0x5","Initiates server push","Contains promised request headers; reserves stream ID"],["PING","0x6","Connection liveness and RTT measurement","8-byte opaque data; must be echoed back"],["GOAWAY","0x7","Graceful connection shutdown","Contains last processed stream ID and error code"],["WINDOW_UPDATE","0x8","Flow control window adjustment","Increments available window for stream or connection"],["CONTINUATION","0x9","Continues a HEADERS or PUSH_PROMISE","Used when headers exceed frame size limit"]],"caption":"HTTP/2 Frame Types","headers":["Type","ID","Purpose","Key Details"]},"type":"table"},{"data":{"content":"**DATA Frames (0x0):**\n\nDATA frames carry the actual content being transferred—the response body for a webpage, the file being downloaded, or the JSON payload of an API response.\n\n```\n+---------------+\n|Pad Length? (8)|\n+---------------+-----------------------------------------------+\n| Data (*) |\n+---------------------------------------------------------------+\n| Padding (*) |\n+---------------------------------------------------------------+\n```\n\nKey characteristics:\n- Subject to flow control (both stream-level and connection-level)\n- END_STREAM flag indicates this is the final data for the stream\n- Optional padding for security (obscures message length)\n- Can be split across multiple frames for better multiplexing"},"type":"text"},{"data":{"content":"$7a"},"type":"text"},{"data":{"icon":"Lightbulb","title":"CONTINUATION Frames","content":"When headers are too large to fit in a single frame (after HPACK compression), CONTINUATION frames carry the remaining header block fragments. Between a HEADERS frame without END_HEADERS and the final CONTINUATION with END_HEADERS, no other frames for that stream may be interleaved—this ensures the header block can be decompressed correctly.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":4},{"id":"streams-identifiers","title":"Streams and Stream Identifiers","content":[{"data":{"content":"The Stream Identifier in each frame header enables HTTP/2's most revolutionary feature: **multiplexing**. A stream represents a single request-response exchange, and multiple streams share a single TCP connection.\n\n**Stream Identifier Rules:**"},"type":"text"},{"data":{"rows":[["Client","Odd numbers","1, 3, 5, 7, ..."],["Server","Even numbers","2, 4, 6, 8, ..."],["Connection-level","0","SETTINGS, PING, GOAWAY"]],"headers":["Initiator","Stream IDs","Example"]},"type":"table"},{"data":{"content":"This simple numbering scheme eliminates coordination—clients and servers can independently create streams without risk of ID collision."},"type":"text"},{"data":{"content":"$7b"},"type":"text"},{"data":{"items":["**send H / recv H**: Sending or receiving HEADERS frame transitions from idle to open","**send ES / recv ES**: END_STREAM flag transitions to half-closed state","**send R / recv R**: RST_STREAM immediately transitions to closed","**send PP / recv PP**: PUSH_PROMISE creates reserved streams for server push"],"title":{"icon":"Target","text":"Stream Lifecycle Events","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"icon":"AlertCircle","title":"Stream Limits","content":"The SETTINGS_MAX_CONCURRENT_STREAMS parameter limits active streams per connection (default: unlimited, recommended: 100). Stream identifiers are never reused—once a stream closes, its ID is permanently retired. This prevents confusion when delayed frames arrive for closed streams. After exhausting 2^31-1 stream IDs, a new connection must be established.","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":5},{"id":"parsing-advantages","title":"Binary Parsing Advantages","content":[{"data":{"content":"The binary framing layer provides dramatic parsing efficiency improvements over HTTP/1.1's text format. These improvements compound at scale, making HTTP/2 significantly more efficient for high-traffic servers.\n\n**Parsing Comparison:**"},"type":"text"},{"data":{"left":[{"data":{"items":["Scan bytes for CRLF delimiters","Handle variable-length fields","Parse ASCII characters to values","Manage buffer reallocations","Handle line folding edge cases","Multiple parsing state machines","Character encoding validation","Vulnerability to parsing exploits"],"title":{"icon":"XCircle","text":"HTTP/1.1 Text Parsing","type":"icon","color":"destructive","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"right":[{"data":{"items":["Read fixed 9 bytes","Extract fields with bit masks","Read exactly 'Length' payload bytes","Pre-allocate exact buffer size","No edge cases in frame structure","Single, simple state machine","Binary values—no encoding issues","Constrained format limits exploits"],"title":{"icon":"CheckCircle","text":"HTTP/2 Binary Parsing","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}]},"type":"two-column"},{"data":{"content":"**Performance Implications:**\n\nThe binary format enables several optimizations:\n\n1. **Zero-Copy Parsing**: Frame boundaries are known immediately—no scanning required. Parsers can work directly on the receive buffer without copying data.\n\n2. **Parallelizable Processing**: Once frames are demultiplexed by stream ID, they can be processed in parallel. HTTP/1.1's sequential nature prevents this.\n\n3. **Reduced Syscalls**: Knowing exact frame sizes means fewer `read()` calls with precise buffer sizes, reducing kernel/user-space transitions.\n\n4. **Hardware Acceleration**: Fixed-length binary formats are amenable to SIMD instructions and hardware offloading—important for high-performance servers.\n\n5. **Predictable Memory**: Fixed header sizes and known payload lengths allow optimal memory allocation strategies, reducing GC pressure in managed runtimes."},"type":"text"},{"data":{"fileName":"http2_frame_parsing.c","languages":[{"code":"// HTTP/2 frame header parsing - remarkably simple\ntypedef struct {\n uint32_t length; // 24 bits\n uint8_t type;\n uint8_t flags;\n uint32_t stream_id; // 31 bits (R bit ignored)\n} http2_frame_header_t;\n\nint parse_frame_header(const uint8_t *buf, http2_frame_header_t *hdr) {\n // Extract 24-bit length (big-endian)\n hdr->length = (buf[0] << 16) | (buf[1] << 8) | buf[2];\n \n // Single byte fields\n hdr->type = buf[3];\n hdr->flags = buf[4];\n \n // Extract 31-bit stream ID (ignore R bit)\n hdr->stream_id = ((buf[5] & 0x7F) << 24) | \n (buf[6] << 16) | \n (buf[7] << 8) | \n buf[8];\n \n // Validate length against settings\n if (hdr->length > max_frame_size) {\n return FRAME_SIZE_ERROR;\n }\n \n return SUCCESS;\n}","label":"C","value":"c"}],"showLineNumbers":true},"type":"code"},{"data":{"icon":"Info","title":"Network Byte Order","content":"HTTP/2 uses big-endian (network byte order) for all multi-byte fields. This is consistent with TCP/IP conventions and ensures interoperability across different CPU architectures. Modern compilers provide efficient byte-swapping intrinsics (like __builtin_bswap32) that compile to single CPU instructions on little-endian machines.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":6},{"id":"connection-preface","title":"Connection Preface","content":[{"data":{"content":"Every HTTP/2 connection begins with a **connection preface**—a specific sequence that confirms both endpoints support HTTP/2 and establishes initial settings. This handshake ensures protocol compatibility before any frames are exchanged.\n\n**Client Connection Preface:**\n\nThe client sends:\n\n1. A 24-byte magic string (ASCII + binary marker):\n```\nPRI * HTTP/2.0\\r\n\\r\nSM\\r\n\\r\n\n```\n\n2. Immediately followed by a SETTINGS frame\n\nThe magic string serves multiple purposes:\n- It's deliberately invalid HTTP/1.1, ensuring HTTP/1.1 servers reject it gracefully\n- It contains 'HTTP/2.0' for easy protocol identification in traffic analysis\n- The 'SM' portion creates binary bytes that can't appear in valid HTTP/1.1"},"type":"text"},{"data":{"fileName":"connection_preface.txt","languages":[{"code":"// Client connection preface (hex representation)\n0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a\n// Decoded: \"PRI * HTTP/2.0\\r\n\\r\nSM\\r\n\\r\n\"\n\n// Followed immediately by SETTINGS frame:\n0x000000 // Length: 0 (empty settings = use defaults)\n0x04 // Type: SETTINGS (4)\n0x00 // Flags: none\n0x00000000 // Stream ID: 0 (connection-level)","label":"Binary","value":"text"}],"showLineNumbers":true},"type":"code"},{"data":{"content":"**Server Connection Preface:**\n\nThe server responds with its own SETTINGS frame. This SETTINGS frame may include:\n\n- **SETTINGS_HEADER_TABLE_SIZE** (0x1): Maximum size of header compression table\n- **SETTINGS_ENABLE_PUSH** (0x2): Whether server push is allowed\n- **SETTINGS_MAX_CONCURRENT_STREAMS** (0x3): Maximum parallel streams\n- **SETTINGS_INITIAL_WINDOW_SIZE** (0x4): Initial flow control window size\n- **SETTINGS_MAX_FRAME_SIZE** (0x5): Maximum frame payload size\n- **SETTINGS_MAX_HEADER_LIST_SIZE** (0x6): Maximum uncompressed header size\n\nBoth sides must acknowledge received SETTINGS with a SETTINGS frame with the ACK flag set. Until acknowledgment, the sender must respect the receiver's previous settings."},"type":"text"},{"data":{"rows":[["HEADER_TABLE_SIZE","0x1","4096","0 to 2^32-1","HPACK dynamic table size"],["ENABLE_PUSH","0x2","1 (enabled)","0 or 1","Allow server push"],["MAX_CONCURRENT_STREAMS","0x3","unlimited","0 to 2^31-1","Maximum active streams"],["INITIAL_WINDOW_SIZE","0x4","65535","0 to 2^31-1","Flow control window"],["MAX_FRAME_SIZE","0x5","16384","16384 to 2^24-1","Maximum frame payload"],["MAX_HEADER_LIST_SIZE","0x6","unlimited","0 to 2^32-1","Maximum header size"]],"caption":"HTTP/2 Settings Parameters","headers":["Setting","ID","Default","Range","Purpose"]},"type":"table"},{"data":{"icon":"Lightbulb","title":"Protocol Negotiation","content":"In practice, HTTP/2 is negotiated during TLS handshake using ALPN (Application-Layer Protocol Negotiation). The client advertises 'h2' in its ClientHello, and the server confirms support. This allows protocol selection before any HTTP data is exchanged, avoiding extra round trips. Clear-text HTTP/2 (h2c) uses HTTP Upgrade instead, but is rarely deployed given security concerns.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":7},{"id":"enabling-features","title":"Enabling Advanced Features","content":[{"data":{"content":"$7c"},"type":"text"},{"data":{"height":"350px","mermaidSyntax":"flowchart TB\n BF[Binary Framing Layer]\n \n BF --> M[Multiplexing]\n BF --> HC[Header Compression]\n BF --> SP[Server Push]\n BF --> FC[Flow Control]\n BF --> PR[Prioritization]\n \n M --> |\"Stream IDs in\neach frame\"| PERF[Performance]\n HC --> |\"HEADERS frames\nwith HPACK\"| PERF\n SP --> |\"PUSH_PROMISE\nframes\"| PERF\n FC --> |\"WINDOW_UPDATE\nframes\"| PERF\n PR --> |\"Priority in\nHEADERS\"| PERF\n \n PERF --> WEB[Faster Web Experience]"},"type":"mermaid-excalidraw"},{"data":{"icon":"CheckCircle","title":"The Foundational Layer","content":"Every HTTP/2 optimization—from multiplexing to header compression—is made possible by the binary framing layer. This is why understanding frames is essential: you cannot truly understand HTTP/2's performance characteristics without understanding how data is structured at the wire level. The following pages in this module will build on this foundation, exploring each feature in detail.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":8},{"id":"security-implications","title":"Security Implications","content":[{"data":{"content":"Binary framing affects security in several important ways:\n\n**Attack Surface Reduction:**\n\nHTTP/1.1's text format enabled numerous parsing-based attacks:\n- Request smuggling via header injection\n- Response splitting via CRLF injection\n- Buffer overflows from unbounded text fields\n- Ambiguous parsing between proxies and servers\n\nHTTP/2's binary format constrains these attacks:\n- Fixed-length headers prevent overflow\n- Frame boundaries are unambiguous\n- No text delimiters to inject\n- Strict parsing rules reduce interpretation differences"},"type":"text"},{"data":{"items":["**No CRLF Injection** — Frames don't use text delimiters, eliminating header injection attacks","**Length-Prefix Safety** — Known payload lengths prevent buffer overflows from malicious input","**Strict Parsing** — Binary format has less ambiguity than text, reducing proxy/server disagreement exploits","**Padding Support** — DATA and HEADERS frames support padding to obscure message lengths (traffic analysis defense)","**Protocol Enforcement** — Invalid frame sequences trigger connection errors, preventing protocol confusion"],"title":{"icon":"CheckCircle","text":"Security Benefits of Binary Framing","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"icon":"AlertCircle","title":"New Attack Vectors","content":"While binary framing reduces some attacks, HTTP/2's complexity introduces new concerns: HPACK compression creates state-based attacks, flow control can be abused for DoS, and implementation bugs in complex state machines have led to vulnerabilities. HTTP/2 servers must implement strict frame validation and resource limits to prevent abuse.","variant":"warning"},"type":"callout"},{"data":{"content":"**Practical Requirement: TLS**\n\nWhile HTTP/2 technically supports clear-text operation (h2c), all major browsers require TLS for HTTP/2. This effectively makes HTTP/2 always encrypted in practice, providing:\n\n- Confidentiality: Frame content is encrypted\n- Integrity: Frames cannot be modified in transit\n- Authentication: Server identity is verified\n\nThe binary format works harmoniously with TLS—both are designed for efficient processing of structured byte streams. The protocol negotiation via ALPN integrates cleanly, establishing HTTP/2 during the TLS handshake without additional round trips."},"type":"text"}],"titleType":"number","titleNumber":9},{"id":"summary","title":"Summary: Binary Framing as Foundation","content":[{"data":{"content":"Binary framing represents a fundamental shift in how HTTP messages are structured and transmitted. This architectural change enables every other HTTP/2 improvement."},"type":"text"},{"data":{"type":"ordered","items":["**Binary replaces text** — HTTP/2 uses a structured binary format instead of HTTP/1.1's human-readable text, enabling efficient parsing and precise message boundaries.","**Fixed 9-byte frame headers** — Every frame begins with Length (24 bits), Type (8 bits), Flags (8 bits), and Stream Identifier (31 bits), providing predictable parsing.","**Ten frame types** — DATA, HEADERS, PRIORITY, RST_STREAM, SETTINGS, PUSH_PROMISE, PING, GOAWAY, WINDOW_UPDATE, and CONTINUATION serve specific protocol functions.","**Stream multiplexing** — Stream IDs in frame headers allow multiple requests/responses to share a single connection without head-of-line blocking.","**Connection preface** — HTTP/2 connections begin with a magic string and SETTINGS exchange, ensuring both endpoints agree on protocol parameters.","**Foundation for features** — Multiplexing, header compression, server push, flow control, and prioritization all depend on the binary framing structure.","**Security improvements** — Binary format reduces parsing-based attacks while requiring TLS in practice adds encryption and authentication."],"title":{"icon":"CheckCircle","text":"Key Takeaways","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**What's Next:**\n\nWith binary framing understood, we can now explore how HTTP/2 leverages this foundation. The next page examines **Multiplexing**—how multiple requests and responses interleave on a single connection, solving HTTP/1.1's head-of-line blocking problem and dramatically reducing page load times."},"type":"text"},{"data":{"icon":"CheckCircle","title":"Page Complete","content":"You now understand HTTP/2's binary framing layer—the architectural foundation that enables all other protocol improvements. The fixed frame structure, well-defined frame types, and stream identification system form the infrastructure upon which modern web performance is built.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":10}],"isLocked":false},{"id":"seed_e06f16bf337538a4a147e3d5bf913236","title":"Multiplexing: Concurrent Streams on a Single Connection","order":1,"content":null,"isLocked":true},{"id":"seed_0e634c3494e52f6ec2601067b88e40d2","title":"Header Compression: HPACK Algorithm Deep Dive","order":2,"content":null,"isLocked":true},{"id":"seed_622a1b23a00dea695ea8da25a2c76183","title":"Server Push: Proactive Resource Delivery","order":3,"content":null,"isLocked":true},{"id":"seed_0e37cf7ccd44e693b4b99471559da7b2","title":"Stream Prioritization: Intelligent Resource Scheduling","order":4,"content":null,"isLocked":true}]}}