SPDY in Apache httpd

Who is supporting SPDY?

• Clients: Chrome, Firefox, Opera, Android Browser


• Servers: Apache (with mod_spdy), nginx, Jetty, node.js


• Sites: Google, Akamai, Facebook, Twitter, Wordpress, and more...

The future of SPDY

• Next version, SPDY/4, is coming soon


• HTTP/2.0 is in the works, and the IETF is using SPDY as a starting point


• This is the future of the web!

mod_spdy

• Free Software, Apache 2 License
• First launched April 2012
• Full support for SPDY/2 and SPDY/3
• Drop-in module, works with your existing server config
• Available in source or binary form

Critical SPDY features

• Next Protocol Negotiation (NPN)


• Framing layer and header compression


• Stream multiplexing


• Server push

Critical SPDY features

• Next Protocol Negotiation (NPN)


• Framing layer and header compression


• Stream multiplexing


• Server push

Next Protocol Negotiation (NPN)

Next Protocol Negotiation (NPN)

Next Protocol Negotiation (NPN)

Next Protocol Negotiation (NPN)

NPN in httpd

• Our patched version of mod_ssl provides two NPN-related hooks:
• Add protocols to be advertised
• Report which protocol the client selected


• Other modules can use these hooks too!

NPN in httpd

NPN in httpd

NPN in httpd

NPN in httpd

NPN in httpd

NPN in httpd

NPN in httpd

NPN in httpd

NPN in httpd

• These hooks have been committed to mod_ssl trunk


• For older server installations, the mod_spdy binary package installs an updated mod_ssl

Critical SPDY features

• Next Protocol Negotiation (NPN)


• Framing layer and header compression


• Stream multiplexing


• Server push

Framing layer and header compression

• Inserts filters to translate from SPDY frames to equivalent HTTP data, and back


• Do this at the connection (not request) level, to maintain header compression state


• This approach allows existing modules to be oblivious of mod_spdy.

Critical SPDY features

• Next Protocol Negotiation (NPN)


• Framing layer and header compression


• Stream multiplexing


• Server push

How httpd normally works

How httpd normally works

How httpd normally works

How httpd normally works

How httpd normally works

How httpd normally works

How httpd normally works

How httpd normally works

How httpd normally works

How httpd normally works

How httpd normally works

Limitations on multiplexing

1. Once a request handler takes over, it does not return control until the request is finished.

Limitations on multiplexing

1. Once a request handler takes over, it does not return control until the request is finished.


2. Httpd assumes one thread per connection; the core data structures are not thread-safe.

Limitations on multiplexing

1. Once a request handler takes over, it does not return control until the request is finished.


2. Httpd assumes one thread per connection; the core data structures are not thread-safe.

So we can't be event-driven, but we can't be multithreaded either!

How mod_spdy works

How mod_spdy works

How mod_spdy works

How mod_spdy works

How mod_spdy works

How mod_spdy works

How mod_spdy works

How mod_spdy works

How mod_spdy works

How mod_spdy works

How mod_spdy works

How mod_spdy works

How mod_spdy works

How mod_spdy works

How mod_spdy works

Critical SPDY features

• Next Protocol Negotiation (NPN)


• Framing layer and header compression


• Stream multiplexing


• Server push

Server push

• Each mod_spdy stream thread looks for an X-Associated-Content response header with URL(s) to push


• For each URL, send a SPDY SYN_STREAM push frame with minimal headers


• Signal master connection thread to initiate pushed streams

Server push

• When pushing a stream, we synthesize HTTP request data to imagine that the client sent us.


• mod_spdy allows httpd to respond to the request normally, on a new mod_spdy stream thread.


• As the response is generated, we transliterate it into SPDY frames, as normal.

Critical SPDY features

• Next Protocol Negotiation (NPN)


• Framing layer and header compression


• Stream multiplexing


• Server push

Benefits of mod_spdy's approach

• It works!


• No need for loop-back fetches (which have their own problems)


• No need to rewrite existing modules


• No need to change existing configuration (mostly)

Minor drawbacks of mod_spdy

• Requires updated mod_ssl


• Some overhead for transliteration/double-parsing


• Slight breach of abstraction (uses private core functions)


• Breaks non-thread-safe modules

Major drawbacks of mod_spdy

• Confuses mod_ssl; SPDY streams appear not to be over SSL


• Requires many threads


• Cannot share MPM's thread pool


• MPM scoreboard is unaware of SPDY streams

HTTP/2.0

• IETF is currently hashing out a standard for HTTP/2.0


• SPDY is being used as a starting point


• HTTP/2.0 will feature SPDY-like multiplexing!


• Going forward, how can httpd support HTTP/2.0 well, without rewriting it from scratch or breaking existing modules?

Multiple requests per connection

• Need to be able to have multiple concurrent requests associated with the same connection object


• Problem: Existing modules assume that each request has a dedicated connection object.

Multiple requests per connection

• Proposal: sub-connection objects


• A sub-connection object would have an associated parent connection object, but would have no socket.


• A sub-connection would have a thread-safe bucket brigade (or something similar) to communicate back to master thread.

Multiple requests per connection

Problems this solves:

• Each request still has a dedicated connection object, but it might be a sub-connection. Most modules don't need to know the difference.


• Legit way to associate multiple concurrent requests with one TCP connection, without breaking abstractions.


• mod_ssl would treat sub-connections of secure connections as secure.

Cooperating with the MPM

• Modules need to be able to run a concurrent sub-request (using a sub-connection) on a separate thread.


• Problem: MPMs do not provide a way to hook into their thread pool.

Cooperating with the MPM

• Proposal: Allow MPMs to provide an hook to run a concurrent sub-connection.


• Prefork might not be able to support this feature (unless we use IPC), but maybe that's okay?

Cooperating with the MPM

Problems this solves:

• Back to a single point (the MPM) managing threads.


• MPM scoreboard is now aware of concurrent subrequests.


• New future protocol modules can use this, instead of each one reimplementing mod_spdy's hacks.

Potential benefits

• Cleaner/better support for SPDY and HTTP/2.0


• Parallelism for modules that make multiple sub-requests (e.g. mod_dir, mod_include, mod_pagespeed, etc.)


• Opens up new possibilities for modules

</slides>

• Binaries:
  https://developers.google.com/speed/spdy/mod_spdy/


• Source:
  https://code.google.com/p/mod-spdy/


• Mailing list:
  mod-spdy-discuss@googlegroups.com