NetKernel News Volume 3 Issue 32

July 20th 2012

What's new this week?

• Repository Updates
• Towards HTTP/2.0 via SPDY
• How to make NetKernel SPDYier...

Catch up on last week's news here

Repository Updates

There following updates are available in both the NKEE and NKSE repositories...

• kernel-1.27.1
  • Classloading enhanced to distinguish module versions for active:java
  • Dependency cost accumulation linearised
  • exclude-dependencies captures the cost of the excluded dependency as a cache weighting factor
  • Fixed Utils.expiryToString() to correctly format time period string if period falls between "day and week".
• layer0-1.88.1
  • IHDSNode.equals() does intelligent comparison through the tree
• layer1-1.38.1
  • active:java classloading distinguishes superstack for legacy generations of the same class in different modules.
• module-standard-1.54.1
  • file: endpoint now implements DELETE
• nkse-dev-tools-1.47.1
  • Physical endpoint error reporting enhancement
  • Feed fetch for news data eliminates duplicate request
• nkse-visualizer-1.20.1
  • Visualizer now has advanced display of a representation's cost determinants
• system-core-0.32.1
  • Physical endpoint error reporting enhancement

Details

We've shipped the updated kernel which has been available for preview for the last few weeks. The main change was to support the classloader superstack version requirements for the enhanced active:java runtime in layer1. In addition we took the opportunity to tune the dependency cost accumulation algorithm, firstly making it more linear when going through layered overlays and secondly to ensure that the cost of a resource is not omitted even if the exclude-dependencies header is used.

This latter change will mean that resources requested from out-bound systems can still have their caching semantics overridden but the cost is not lost and therefore still provides a contribution to the relative weighting in the cache. Which is a long winded way of saying: refetching something is a cost that should be accounted for in the relative value of local state.

One other useful tweak is to the IHDSNode representation in layer0. It now has a more sophisticated equality check that looks more deeply at the value-tree structure to decide if two HDS's are equivalent. HDS is our default resource model for the NK tools and for important resources like the httpRequest:/xxxx - it therefore means more reusable state is going to get discovered and be reused. Which is a long winded way of saying, less code gets executed and things are faster.

Finally, as an advanced diagnostics tool, the visualizer now has the ability to display a representation's cost determinants.

All our production systems are running these updates so fill your boots.

Towards HTTP/2.0 via SPDY

The ball has begun to roll on a new HTTP/2.0 standard process. With the leading candidate for standardisation being the Google developed SPDY protocol.

The headline feature of SPDY is that rather than having the browser negotiate a new connection for every referenced page resource, it instead negotiates a single connection which is then used to multiplex many requests back to the origin server. The connection is kept-alive for as long as the page needs resources from the server. In addition, the potentially verbose HTTP header traffic is minimized through header compression. The upshot of SPDY is that the high level browser web model is unchanged but for typical modern web-pages, which are composite resources consisting of potentially 10s to 100s of separate resource requests, the network gain translates to a very significant performance boost.

SPDY support was first available in Chrome but is now provided in Firefox. If a server offers SPDY then the client can seamlessly negotiate that the connection be upgraded. The upgrade is negotiated through the use of TLS Next-Protocol-Negotiation (NPN). This requirement means that SPDY mandates TLS encrypted transports (the implications of which are discussed below).

So, while we wait for the HTTP/2.0 process to crank up, and it will no doubt be a couple of years before we get to the RFC, we thought it would be pretty interesting to try SPDY with NetKernel...

How to make NetKernel SPDYier...

Here's a snapshot release of the tpt.http module, its updated to provide the most recent Jetty 8.1.5 and its ongoing development SPDY extensions...

urn.org.netkernel.tpt.http-20120720-SPDY.jar

To get SPDY up and running requires a small amount of work, mainly due to the requirements for TLS/SSL. But now we've worked out the recipe (which took a couple of days) it is pretty simple... so follow these steps...

1. Make sure you're running Java 7

Jetty's SPDY source code is using some of Java 7's new features (most notably strings in case statements) so you'll have to make sure you're running on a Java 7 JRE/JDK.

2. Get a TLS Certificate and Keystore

You will need a TLS certificate in a keystore. The details of how to install an official certificate (or for development, just create a self-signed certificate) are documented here...

http://docs.codehaus.org/display/JETTY/How+to+configure+SSL

The thing to take care of is that the certificate alias is jetty. If you're using a CA you'll also need to make sure you have the necessary certificate signing chain in the keystore - in my experience this is the most likely cause of problems in setting up TLS/SSL.

3. NPN Boot

Java 7 doesn't understand the NPN feature in its TLS implementation so you must provide this capability. You will need this library...

npn-boot-8.1.2.v20120308.jar

and, unfortunately for modularity(!!), you need to register it in the low-level Java classloader. You can do this by setting an extension in your NK install's bin/jvmsettings.cnf

Add the following:

-Xbootclasspath/p:/the/directory/path/where/you/put/npn-boot-8.1.2.v20120308.jar

(jvmsettings.cnf is a single line of switches to the java process - so keep it all on one line)

4. Tell Jetty to use a SPDY connector

All you now have to do is configure Jetty with a SPDY connector. Find your Frontend Fulcrum (FEF) module in modules/urn.org.netkernel.fulcrum.frontend-x.x.x/ and edit etc/HTTPServerConfig.xml

You'll see that by default the FEF has an existing SSL connector example which is commented out. Ignore that one but add the following additional connector...

You'll obviously have to point to your TLS keystore - the current working directory of NK is its install location - so the easiest thing to do is put your keystore in the etc/ directory.

You will now have a TLS connector running on port 8443. So URLs like https://localhost:8443/xxxx will use this connector (note the s on https).

5. Testing

If you've got an application deployed to the FEF it will now "just work" when you request it down the https://localhost:8443/xxxx path. Fortunately there are absolutely no consequences in using SPDY to an existing application at either client or server-side. If your browser supports it - your page requests will get multiplexed, if it doesn't then you'll be on plain old HTTP/1.1. In either case the server-side logical ROC requests will arrive with exactly the same context as before.

One thing to note is that, because SPDY is a low level protocol update, your browser's developer tools such as Firebug will not show any difference in the HTTP network request view (other than speed!). So how the heck do you know if you've got it set up right?

Fortunately Chrome has a built-in SPDY diagnostics tool. Open up a tab and paste this URL in...

chrome://net-internals/#spdy

Example

To show that this is for real, here's proof that NetKernel is now SPDY, this is a snapshot of the Chrome diagnostics when we run the NK portal with SPDY...

Comments

It took a couple of days to work out and debug this solution. Partly this involved finding out what was needed, but we were also unlucky to hit a spinning thread bug in the Jetty implementation when we tried to serve a large resource that exceeded the 32kB default response buffer.

When you're working in the dark, it wasn't certain whether this was the NK classloader representation, Jetty or the SPDY impl. Fortunately after hacking at the Jetty sources we figured out it was nothing to do with NK but a real low-level bug in the SPDY impl. Not wanting to give up since we were close to a full solution, we hacked the Jetty source and were able to implement a workaround, only to discover by coincidence the Jetty team had posted an update with a fix for this very bug about 2 hours earlier!

We're not quite out of the woods, it looks like the latest SPDY library requires an updated NPN library since periodically you'll see these non-critical errors...

java.lang.NoSuchMethodError
org.eclipse.jetty.npn.NextProtoNego.remove(Ljavax/net/ssl/SSLEngine;)

Which suggests we need to find a newer version of the NPN library when/if its been published.

However, these teething issues aside, things look promising. Fundamentally Jetty with SPDY is working just fine. The existing resource-oriented HTTP stack is completely unaffected. Existing applications (like the NK portal) run perfectly and are noticeably snappier.

Implications

SPDY clearly has benefits for applications and is already being adopted by the Gorillas of the Web industry. Its instructive to read Facebook's response to the HTTP/2.0 call for feedback.

But as it stands the requirement to mandate TLS has deep implications. While TLS adds a very small server computation overhead, these days it is in the noise and not relevant. More significantly is that TLS certificate management adds a layer of grit to setting up a web stack - you can't just throw up a server out of the box, or for the web-of-things, it could exclude embedded webservers. Can users be expected to trust self-signed certificates when their browsers scream about security and trust?

Even more significantly, moving to SPDY on wholesale basis has deep implications for the web infrastructure. In the short term its going to mean much larger volumes of origin traffic - at least until the CDN's work out the plumbing to enable transparent proxying of the TLS encrypted payloads - but then presumably this is something that any standards process will have its work cut out to solve.

We'll obviously keep an eye on the evolution of the standard and undoubtedly the Jetty SPDY library will mature quite rapidly - especially if people like us, the ROC community, give it a good kicking. So what are you waiting for? GodSPDY ROCers...

Reference

• For Jetty SPDY details http://wiki.eclipse.org/Jetty/Feature/SPDY (don't copy their config use the one shown above as it works)
• For the NPN details http://wiki.eclipse.org/Jetty/Feature/NPN