Okay, here is the abstract and summary for the provided text on HTTP/2.
Abstract:
This document, "http2 explained" by Daniel Stenberg (creator of curl), provides a comprehensive technical overview of the HTTP/2 protocol (RFC 7540). It details the background, outlining the limitations of HTTP/1.1 (latency sensitivity, head-of-line blocking, inefficient TCP usage, workarounds like spriting and sharding) that motivated the new protocol. The document explains the core concepts and features of HTTP/2, including its binary nature, multiplexed streams over a single connection, stream prioritization, header compression via HPACK, server push, and flow control. It discusses the influence of Google's SPDY, protocol negotiation methods (Upgrade header for cleartext, ALPN for TLS), implementation status across browsers and servers (as of the document's writing), common critiques, the potential impact on web development, and briefly looks towards future developments like QUIC and HTTP/3.
Summary of HTTP/2 Explained:
(Intro & Background): The document, authored by Daniel Stenberg, aims to explain the HTTP/2 protocol (RFC 7540), its history, concepts, and implementation details. It originates from a presentation and aims to be a detailed technical resource.
(2. HTTP Today - The Problems with HTTP/1.1):
HTTP/1.1 became complex and large (RFC 2616: 176 pages, updated RFC 7230 series even larger).
Suffers from high latency sensitivity, especially on mobile networks.
Inefficient TCP usage due to Head-of-Line (HOL) blocking, where a slow response blocks subsequent requests on the same connection. HTTP Pipelining, intended to mitigate this, remains largely disabled due to implementation issues.
Web pages require increasing numbers of resources (average >100 objects, >1.9MB) leading to performance bottlenecks.
(3. HTTP/1.1 Workarounds): To combat HTTP/1.1 limitations, developers use techniques that HTTP/2 aims to make unnecessary:
Spriting: Combining small images into one large file.
Inlining: Embedding resources (like images) directly into CSS/HTML using data URIs.
Concatenation: Combining multiple CSS/JavaScript files into single large files.
Sharding: Spreading resources across multiple hostnames to bypass the per-host connection limit (often leading to 40+ connections per site).
(4. Updating HTTP - The Road to HTTP/2):
Developed within the IETF HTTPbis working group.
Heavily influenced by Google's SPDY protocol, which proved the viability of concepts like multiplexing and header compression. HTTP/2 started from the SPDY/3 draft.
Goals included maintaining HTTP semantics (methods, headers, URIs), fixing HOL blocking, reducing latency sensitivity, and better utilizing TCP.
(5. HTTP/2 Concepts & Negotiation):
Must work with existing http:// and https:// schemes.
https:// Negotiation: Uses the TLS extension ALPN (Application Layer Protocol Negotiation) to agree on HTTP/2 during the TLS handshake. NPN (Next Protocol Negotiation) was an earlier SPDY mechanism also supported by early implementations. Most major browsers only support HTTP/2 over TLS. Requires TLS 1.2+ with certain cipher restrictions.
http:// Negotiation: Uses the HTTP/1.1 Upgrade: header. If the server supports it, it responds with 101 Switching Protocols and begins speaking HTTP/2. This costs an extra network round-trip. Browser support is minimal, but tools like curl support it.
(6. The HTTP/2 Protocol - Key Features):
Binary Protocol: Uses binary framing instead of plaintext, making parsing deterministic and less error-prone. Frames have a standard structure (Length, Type, Flags, Stream ID, Payload).
Multiplexing: Allows multiple requests and responses to be interleaved over a single TCP connection, each within its own logical "stream". This eliminates HOL blocking at the HTTP level.
Streams: Independent, bi-directional sequences of frames within a connection, identified by a Stream Identifier.
Priorities & Dependencies: Streams can be assigned weights and dependencies (PRIORITY frame), allowing clients to indicate which resources are more important (e.g., render-blocking CSS vs. images lower down the page).
Header Compression (HPACK): Uses HPACK (RFC 7541) specifically designed to compress repetitive HTTP headers efficiently and safely, mitigating vulnerabilities (like CRIME/BREACH) associated with generic compression on headers.
Server Push: Allows servers to proactively send resources (e.g., CSS, JS linked by an HTML page) to the client's cache before explicitly requested. Must be allowed by the client and can be cancelled (RST_STREAM).
Flow Control: Per-stream and per-connection mechanisms prevent a sender from overwhelming a receiver, using WINDOW_UPDATE frames to manage credit.
(8. An http2 World - Impact & Implementations):
User Impact: Expected faster page loads and more responsive websites due to reduced latency, multiplexing, and prioritization.
Web Development Impact: Requires re-evaluating HTTP/1.1 workarounds like spriting, inlining, concatenation, and excessive sharding, as these may hinder HTTP/2 performance.
Implementations (as of doc writing): Growing list including Firefox, Chrome, IE (preview), Safari, Opera; Servers like Nginx, Apache httpd (mod_http2), H2O, LiteSpeed; Tools like curl and Wireshark. (Note: Deployment is now widespread).
Critiques Addressed: Denies claims of Google control (IETF standard), acknowledges initial browser focus but potential for other apps, refutes "big sites only" idea, discusses TLS overhead vs. benefits, justifies binary format, and accepts some legacy holdovers for compatibility.
(9-11. Specific Implementations): Details on enabling and observing HTTP/2 in Firefox, Chrome, and curl, noting browser TLS-only policies and curl's flexibility (TLS via ALPN/NPN, cleartext via Upgrade:, multiplexing control).
(12. After http2 / Future):
Discusses Google's QUIC (Quick UDP Internet Connections) experiment as a potential next step, aiming to reduce connection latency further and improve loss handling using UDP.
Introduces HTTP/3 as the standardized version of HTTP running over the IETF's QUIC protocol (different from Google's original QUIC).