Android Developers Blog

Ideas you will meet

HTTP and QUIC

HTTP versions, QUIC, caching headers and web performance.

What we already know about this

Our own lessons on these ideas. Read them here before you start, so it makes sense.

• Core Concepts: How Things Actually Work · 7 minHTTP/1.1, HTTP/2 and HTTP/3What changed between HTTP versions and why it makes pages faster.Read hereClose

  HTTP/1.1

  • One request at a time per connection (responses come back in order).
  • To fetch many resources, browsers open about six connections per host.
  • Each request repeats large text headers.
  • A slow response blocks those behind it: head-of-line blocking.
  • Keep-alive lets a connection be reused, saving handshakes.

  HTTP/2

  • Multiplexing: many requests and responses share one connection at the same time, interleaved as separate streams.
  • Header compression removes the repeated cost.
  • Binary framing is more efficient to parse than text.
  • Server push existed but is rarely used and is being phased out.
  • Still runs over TCP, so if one packet is lost, TCP holds back all streams until it is resent (head-of-line blocking at the transport layer).

  Before: HTTP/1.1: many connections

  100%

  After: HTTP/2: one shared connection

  100%

  What changed

  • One connection carries many requests at once
  • Headers are compressed
  • Old tricks like domain sharding stop helping

  HTTP/3

  • Runs over QUIC, built on UDP, with encryption (TLS 1.3) included.
  • Independent streams: a lost packet only delays its own stream.
  • Faster connection setup: fewer round trips, and resuming a previous connection can send data immediately.
  • Connection migration: a phone moving from Wi-Fi to mobile data can keep the connection, because it is identified by an ID, not an IP address.

  100%

  Figure SDA-CORE-04-1 · HTTP/3 · © forcsguy.com

  100%

  Figure SDA-CORE-04-2 · What one lost packet does in each version · © forcsguy.com

  What this means for you

  • Use HTTPS everywhere. Browsers only use HTTP/2 and 3 over TLS.
  • Serve through a CDN or server that supports HTTP/2 and 3; clients negotiate automatically and fall back if needed.
  • Do not over-optimise for HTTP/1.1 any more. Keep requests cacheable and compressed.

  More on this site

  Related reading

  • Chrome Developers BlogGoogle engineers · GoogleBlogs
  • Android Developers BlogGoogle engineers · GoogleBlogs
  • Julia Evans' BlogJulia Evans · jvns.caBlogs
  • RFC 9000: QUICIETFDocumentation

  Show 6 moreShow fewer

  • Web VitalsGoogle web.dev · GoogleDocumentation
  • Cloudflare EngineeringCloudflare engineers · CloudflareBlogs
  • Square BlogBlock (Square) engineers · Block (Square)Blogs
  • PlanetScale BlogPlanetScale engineers · PlanetScaleBlogs
  • Quora BlogQuora engineers · QuoraBlogs
  • Twilio BlogTwilio engineers · TwilioBlogs

  Open this lesson with its quiz and exercise

• Real-World Systems · 10 minHow a browser turns a URL into a pageFrom the address bar to pixels: navigation, parsing, the render pipeline, JavaScript, and what makes pages fast or slow.Read hereClose

  From address bar to HTML

  When you press Enter on https://example.com/page:

  1. The browser decides if it is a URL or a search, and checks its caches (HTTP cache, service worker).
  2. DNS turns the name into an IP address; a TCP connection and TLS handshake follow (with HTTP/3, QUIC does both at once). See the networking lessons.
  3. It sends an HTTP request and receives the HTML response, streaming in as it arrives.

  A multi-process program

  Modern browsers run as several processes for speed and safety:

  • a browser process (address bar, tabs, navigation),
  • a renderer process per site or tab (parsing, JavaScript, layout, painting),
  • a network process, and a GPU process for drawing.

  A crashing or malicious page is isolated in its own renderer and cannot read other sites' data.

  The rendering pipeline

  100%

  Figure SDA-RWS-11-1 · Browser rendering pipeline · © forcsguy.com

  1. Parse HTML into the DOM (a tree of elements). Parsing is incremental: the browser starts working before the whole file arrives.
  2. Parse CSS into the CSSOM. Rendering waits for CSS, because showing unstyled content then restyling would flash. CSS is render-blocking.
  3. Combine into the render tree (only visible elements, with computed styles).
  4. Layout works out the size and position of every box.
  5. Paint draws the boxes into layers.
  6. Composite: the GPU assembles layers into the final image. Animating a layer's transform or opacity only needs this last step.

  JavaScript on the main thread

  • JavaScript runs on the renderer's main thread, one task at a time in an event loop, alongside parsing, layout and input handling. A long script blocks everything, and the page feels frozen.
  • A normal <script> is parser-blocking: parsing stops until it downloads and runs. Use defer (run after parsing, in order) or async (run as soon as available) for scripts not needed to build the first view.
  • Changing the DOM or styles can trigger reflow (layout again) and repaint. Reading layout values in a loop right after writing styles forces repeated layout (layout thrashing): batch reads and writes.

  What makes pages fast

  Goal	Techniques
  Less to download	Compression (brotli, gzip), image optimisation and modern formats, remove unused JavaScript
  Fewer round trips	CDN, HTTP/2 and 3, preconnect, caching with long lifetimes and versioned names
  Less blocking	Inline critical CSS, defer scripts, avoid huge CSS and fonts blocking text
  Smooth interaction	Break up long tasks, move heavy work to web workers, animate with transform and opacity
  Load only what is visible	Lazy-load images and routes

  Browsers also cache, preload likely navigations, and can run offline logic with service workers.

  Measuring

  Use the Core Web Vitals: LCP (when the main content appears), INP (responsiveness to input) and CLS (unexpected layout shifts). Check both lab tests and real-user data, because real devices and networks are slower and more varied than a developer laptop.

  Real-world reading

  Related reading

  • Chrome Developers BlogGoogle engineers · GoogleBlogs
  • Android Developers BlogGoogle engineers · GoogleBlogs
  • The Road to QUICCloudflareBlogs
  • Julia Evans' BlogJulia Evans · jvns.caBlogs

  Show 6 moreShow fewer

  • Cloudflare BlogCloudflare engineers · CloudflareBlogs
  • RFC 9000: QUICIETFDocumentation
  • Cloudflare EngineeringCloudflare engineers · CloudflareBlogs
  • Web VitalsGoogle web.dev · GoogleDocumentation
  • Curalate Engineering BlogCuralate engineers · CuralateBlogs
  • Zapier Engineering BlogZapier engineers · ZapierBlogs

  Open this lesson with its quiz and exercise

• Networking and Web Security Deep Dive · 12 minNetwork layers, TCP, UDP, ports and socketsHow data travels: the layered models, what TCP and UDP promise, how ports and sockets let programs talk, and why this matters for design.Read hereClose

  Layers: why networks are divided

  Networking is split into layers, each using the one below and hiding its details. Two models are used: the 7-layer OSI model (a teaching reference) and the 4-layer TCP/IP model (what the internet actually uses).

  TCP/IP layer	OSI layers	What it does	Examples
  Application	5 to 7 (session, presentation, application)	Protocols programs speak	HTTP, DNS, SMTP, TLS
  Transport	4	Delivery between programs	TCP, UDP, QUIC
  Internet	3 (network)	Addressing and routing between networks	IP, ICMP
  Link	1 and 2 (physical, data link)	Moving frames on one local network	Ethernet, Wi-Fi

  100%

  Figure SDA-NSD-01-1 · Layers wrapping a web request · © forcsguy.com

  Each layer adds its own header on the way down (encapsulation) and removes it on the way up. Routers work at the internet layer (they look at IP addresses); switches at the link layer; load balancers and proxies at transport or application (see the load balancing lesson).

  IP, in short

  • IP address identifies a network interface; IPv4 has 32 bits (about 4.3 billion addresses, now scarce, hence NAT) and IPv6 has 128 bits.
  • Packets are routed hop by hop; each router decides the next hop. IP is best effort: packets can be lost, duplicated or reordered. Higher layers fix that if needed.
  • A subnet is a block of addresses sharing a prefix (for example 10.0.1.0/24), the basis of private networks and cloud network design.
  • DNS maps names to addresses (covered in the networking lesson of the foundations course).

  TCP: reliable streams

  TCP gives a reliable, ordered byte stream:

  100%

  Figure SDA-NSD-01-2 · TCP connection life · © forcsguy.com

  • Handshake costs a round trip before data (a reason connection reuse and HTTP keep-alive matter; TLS adds more).
  • Sequence numbers and acknowledgements let it retransmit lost data and reorder.
  • Flow control (receive window) stops a fast sender overwhelming a slow receiver.
  • Congestion control slows down when the network is congested; a new connection starts slowly (slow start), so short connections to far servers are slow.
  • Head-of-line blocking: one lost segment stalls everything behind it on that connection. HTTP/3 over QUIC addresses this (see the HTTP evolution lesson).

  UDP: just datagrams

  UDP sends independent datagrams with no connection, ordering or retransmission. It is lightweight and low latency, used for DNS, voice and video, games, and as the base of QUIC, which rebuilds reliability and encryption on top of UDP with per-stream independence. Choose UDP when the application can tolerate loss or wants its own reliability rules.

  Ports and sockets

  A port (0 to 65535) identifies a program on a machine: HTTP 80, HTTPS 443, SSH 22, DNS 53, PostgreSQL 5432, Redis 6379. A socket is the endpoint a program uses: an IP address plus a port plus a protocol. A TCP connection is uniquely identified by the four values source IP, source port, destination IP, destination port; that is why one server port can serve thousands of clients.

  import net from "node:net";
  const server = net.createServer((socket) => {         // one socket per connected client
    socket.on("data", (buf) => socket.write(`echo: ${buf}`));
  });
  server.listen(9000);                                   // listening socket on port 9000
  

  Operating systems limit open sockets (file descriptors) and ephemeral ports; heavy services tune these and reuse connections.

  Why designers care

  • Latency is dominated by round trips: handshakes, DNS, TLS. Reuse connections, use CDNs, keep data close.
  • Bandwidth versus latency: a fat pipe does not make a round trip shorter (see the latency lesson).
  • Packet loss hurts TCP throughput; mobile networks need resilient protocols.
  • Choosing a transport: TCP for most request/response work, UDP/QUIC for real-time or when you need per-stream independence.
  • Debugging: ping and traceroute for reachability and path, dig for DNS, curl -v for HTTP and TLS, ss or netstat for sockets, tcpdump or Wireshark for packets.

  Real-world reading

  Related reading

  • Cloudflare BlogCloudflare engineers · CloudflareBlogs
  • Chrome Developers BlogGoogle engineers · GoogleBlogs
  • Android Developers BlogGoogle engineers · GoogleBlogs
  • The Road to QUICCloudflareBlogs

  Show 6 moreShow fewer

  • Julia Evans' BlogJulia Evans · jvns.caBlogs
  • RFC 9000: QUICIETFDocumentation
  • Web VitalsGoogle web.dev · GoogleDocumentation
  • Active-Active for Multi-Regional ResiliencyNetflix Engineering · NetflixCase Studies
  • IBM developerWorks Engineering BlogIBM developerWorks engineers · IBM developerWorksBlogs
  • Quora Engineering BlogQuora engineers · QuoraBlogs

  Open this lesson with its quiz and exercise