Webtide

Category: SPDY

  • HTTP/2 Push Demo

    I have recently presented “HTTP/2 and Java: Current Status” at a few conferences (slides below).

    The HTTP/2 protocol has two big benefits over HTTP/1.1: Multiplexing and HTTP/2 Push.
    The first feature, Multiplexing, gives an edge to modern web sites that perform ~100 requests per page to one or more domains.
    With HTTP/1.1 these web sites had to open 6-8 connections to a domain, and then send only 6-8 requests at a time.
    With a network roundtrip of 150ms, it takes ~15 roundtrips to perform ~100 requests, or 15 * 150ms = 2250ms, in the best conditions and without taking into account the download time.
    With HTTP/2 Multiplexing, those ~100 requests can be sent all at once to the server, reducing the roundtrip time from 2250ms to ideally just 150ms.
    The second feature, HTTP/2 Push, allows the server to preemptively push to clients not only the primary resource that has been requested (typically an HTML page), but also secondary resources associated with it (typically CSS files, JavaScript files, image files, etc.).
    HTTP/2 Push complements Multiplexing by saving the roundtrips needed to fetch all resources required to render a page.
    The net result of these two features is a vastly improved web site performance which, following well known studies, can be directly related to more page views, and eventually to more revenue for your business.
    The Jetty Project first implemented these features in SPDY in 2012, and improved them in HTTP/2.
    We are now promoting this work to become part of the Servlet 4.0 specification.
    If you are interested in speeding up your web site (even if it is in PHP – Jetty can host any PHP site, including WordPress), contact us.
    The presentation I gave at conferences includes a demo that shows an example of HTTP/2 versus HTTP/1.1, available at GitHub.

  • Last NPN & ALPN Update for JDK 7

    As you may know already, Oracle has announced that OpenJDK 7, with its last 7u80 release, has reached end of life as of today.
    In March 2012, the Jetty project announced that it had implemented the SPDY protocol and, along with it, the first pure Java NPN implementation that was required to implement SPDY.
    Because the NPN implementation required to modify OpenJDK classes, we maintained the NPN implementation for every JDK release, importing OpenJDK changes when required into a new release of the NPN library.
    NPN has been superseded by ALPN, for which the Jetty project also created a pure Java implementation, required to implement HTTP/2.
    Like NPN, also the ALPN implementation modifies OpenJDK classes and the ALPN library needs to be matched with the corresponding OpenJDK version.
    With the end of public OpenJDK 7 releases, the Jetty project will therefore stop updating the NPN and ALPN implementations for OpenJDK 7.
    Only ALPN (and not NPN) will be maintained for OpenJDK 8 releases.
    If you need support for ALPN or NPN beyond OpenJDK 7u80, please contact us.
    As for the future, ALPN is scheduled to be part of OpenJDK 9 (JEP 244), so we will eventually phase out the Jetty ALPN implementation in favour of OpenJDK 9’s one. OpenJDK 9 is scheduled for the end of 2016, so expect the Jetty ALPN library for OpenJDK 8 to be alive and updated for a while.

  • Phasing out SPDY support

    Now that the HTTP/2 specification is in its final phases of approval, big players announced that they will remove support for SPDY in favor of long term support of HTTP/2 (Chromium blog). We expect others to follow soon.
    Based on this trend and feedback from users the Jetty Project is announcing that it will drop support for SPDY in Jetty 9.3.x, replacing its functionalities with HTTP/2.  We have milestone builds available for Jetty 9.3.0 now if you would like to try them out, they can be downloaded through Maven Central now.  A new milestone release will be released shortly followed by a full release once the specification is finalized.
    The SPDY protocol will remain supported in the Jetty 9.2.x series, but no further work will be done on it unless it is sponsored by a client.  This will allow us to concentrate fully on a first class quality implementation of HTTP/2.
    Along these same lines, Jetty 9.3 will drop support for NPN (the TLS Next Protocol Negotiation Extension), replacing its functionalities with ALPN (the TLS Application Layer Protocol Negotiation Extension, RFC 7301). NPN should remain supported in the Jetty 9.2.x series, and updated as new JDK 7 versions will be released.
    Contact us if you are interested in migrating your existing SPDY solutions to HTTP/2.

  • HTTP/2 draft 14 is live !

    Greg Wilkins (@gregwilkins) and I (@simonebordet) have been working on implementing HTTP/2 draft 14 (h2-14), which is the draft that will probably undergo the “last call” at the IETF.

    We will blog very soon with our opinions about HTTP/2 (stay tuned, it’ll be interesting!), but for the time being Jetty proves once again to be a trailblazer when it comes with new web technologies and web protocols.

    Jetty started to innovate with Jetty Continuations, that were standardized (with improvements) into Servlet 3.0.

    Jetty was one of the first Java server to offer support for asynchronous I/O back in 2006 with Jetty 6.

    In 2012 we were the first Java server to implement SPDY, we have written libraries that provide support for NPN in Java (that are now used by many other Java servers that provide SPDY support). We also were the first to implement a completely automatic way of leveraging SPDY Push, that can boost your web site performance.

    Today, to my knowledge, we are again the first Java server exposing the implementation of the HTTP/2 protocol, draft 14, live on our own website.

    Along with HTTP/2 support, that will be coming in Jetty 9.3, we have also implemented a library that provides support for ALPN in Java (the successor of NPN), allowing every Java application (client or server) to implement HTTP/2 over SSL. This library is already available in the Jetty 9.2.x series. We want other implementers (client and server) to test our HTTP/2 implementation in order to generate feedback about HTTP/2 that can be reported at the IETF.

    As of today, both Mozilla Firefox and Google Chrome only support HTTP/2 draft 13 (h2-13). They are keeping the pace at implementing new drafts, so expect both browsers to offer draft 14 support in matter of days (in their nightly/unstable versions). When that will happen, you will be able to use those browsers to connect to our HTTP/2 enabled website.

    The Jetty project offers not only a server, but a HTTP/2 client as well. You can take a look at how it’s used to connect to a HTTP/2 server here.

    Where is it ? https://webtide.com.

    Lastly, contact us for any news or information about what Jetty can do for you in the realms of async I/O, PubSub over the web (via CometD), SPDY and HTTP/2.

  • Jetty 9.1.4 Open Sources FastCGI Proxy

    I wrote in the past about the support that was added to Jetty 9.1 to proxy HTTP requests to a FastCGI server.
    A typical configuration to serve PHP applications such as WordPress or Drupal is to put Apache or Nginx in the front and have them proxy the HTTP requests to, typically, php-fpm (a FastCGI server included in the PHP distribution), which in turn runs the PHP scripts that generate HTML.
    Jetty’s support for FastCGI proxying has been kept private until now.
    With the release of Jetty 9.1.4 it is now part of the main Jetty distribution, released under the same license (Apache License or Eclipse Public License) as Jetty.
    Since we like to eat our own dog food, Jetty is currently serving the pages of this blog (which is WordPress) using Jetty 9.1.4 and the newly released FastCGI module.
    And it is doing so via SPDY, rather than HTTP, allowing you to serve Java EE Web Applications and PHP Web Applications from the same Jetty instance and leveraging the benefits that the SPDY protocol brings to the Web.
    For further information and details on how to use this new module, please check the Jetty FastCGI documentation.
    Enjoy !

  • WordPress & Jetty: perfect fit

    I posted a while back about the capability of Jetty 9.1’s HttpClient to speak HTTP over different transports: by default HTTP, but we also provide a SPDY implementation, where the HTTP requests and responses are carried using the SPDY transport rather than the HTTP transport.
    Another transport that is able to carry HTTP requests and responses is FastCGI.
    The neat feature about FastCGI is that it is the default way to deploy PHP applications: fire up a proxy server (usually Apache or Nginx) in the front and proxy requests/responses to the FastCGI server (usually the PHP FastCGI Process Manager, or php-fpm).
    In this way you can deploy the most used PHP frameworks like WordPress, Drupal and others.
    And you are not limited to PHP: FastCGI allows you to easily deploy other dynamic web languages and frameworks such as Django (Python-based), Rails (Ruby-based) and others.
    We are happy to announce that Jetty 9.1 can now proxy to FastCGI, enabling deployment of PHP frameworks.
    Why this is good, and how different it is from having – say – Apache or Nginx in the front instead of Jetty ?
    The first and foremost reason is that Jetty is the only server that supports SPDY Push.
    SPDY Push is the biggest performance improvement you can make to your website, without a single change to the application being served, be it a Java web application or WordPress.
    Watch our video that shows how the SPDY Push feature that Jetty provides makes a big performance difference.
    The second reason is that SPDY version 2 is being deprecated really fast in favor of SPDY version 3 or greater.
    Browsers will not speak SPDY/2 anymore, basically reverting your website to HTTPS behaviour, losing all the SPDY benefits if your server does not support SPDY 3 or greater.
    As of the time of this writing, only servers like Apache or Jetty implement SPDY version 3 or later of the SPDY protocol, while Nginx only implements SPDY version 2.
    At the Jetty Project we like to eat our own dogfood, so the blog site you are reading is WordPress served via Jetty.
    If you’re using Firefox or Chrome, just open the browser network console, and you will see something like this:
    jetty-wordpress
    As you can see from the response headers, the response is served by Jetty (Server: Jetty(9.1.0.v20131115)) from PHP (X-Powered-By: PHP/5.5.3-1ubuntu2).
    Of course, since both Jetty 9.1’s server and HttpClient are fully asynchronous, you have a very scalable solution for your PHP-enabled website: currently the JVM that runs this very website only uses 25 MiB of heap.
    And of course you get all the SPDY performance improvements over HTTP, along with Jetty’s unique SPDY Push features.
    This is good for cloud vendors too, since they can run Jetty and expose PHP applications with a minimal amount of resources, high scalability, and unique features like SPDY Push.
    FastCGI for Jetty is sponsored by Intalio. If you are interested in knowing more about how Jetty can speed up your website or how to setup your PHP web application in Jetty, contact us or send an email to Jesse McConnell.

  • Pluggable Transports for Jetty 9.1's HttpClient

    In Jetty 9, the HttpClient was completely rewritten, as we posted a while back.
    In Jetty 9.1, we took one step forward and we made Jetty’s HttpClient polyglot. This means that now applications can use the HTTP API and semantic (“I want to GET the resource at the http://host/myresource URI”) but can now choose how this request is carried over the network.
    Currently, three transports are implemented: HTTP, SPDY and FastCGI.
    The usage is really simple; the following snippet shows how to setup HttpClient with the default HTTP transport:

    // Default transport uses HTTP
HttpClient httpClient = new HttpClient();
httpClient.start();

    while the next snippet shows how to setup HttpClient with the SPDY transport:

    // Using the SPDY transport in clear text
// Create the SPDYClient factory
SPDYClient.Factory spdyClientFactory = new SPDYClient.Factory();
spdyClientFactory.start();
// Create the SPDYClient
SPDYClient spdyClient = spdyClientFactory.newSPDYClient(SPDY.V3);
// Create the HttpClient transport
HttpClientTransport transport = new HttpClientTransportOverSPDY(spdyClient);
// HTTP over SPDY !
HttpClient httpSPDYClient = new HttpClient(transport, null);
httpSPDYClient.start();
// Send request, receive response
ContentResponse response = httpSPDYClient.newRequest("http://host/path")
        .method("GET")
        .send();

    This last snippet allows the application to still use the HTTP API, but have the request and the response transported via SPDY, rather than HTTP.
    Why this is useful ?
    First of all, more and more websites are converting to SPDY because it offers performance improvements (and if you use Jetty as the server behind your website, the performance improvements can be stunning, check out this video).
    This means that with a very simple change in the HttpClient configuration, your client application connecting to servers can benefit of the performance boost that SPDY provides.
    If you are using HttpClient for server-to-server communication, you can use SPDY in clear text (rather than encrypted) to achieve even more efficiency because there is no encryption involved. Jetty is perfectly capable of speaking SPDY in clear text, so this could be a major performance win for your applications.
    Furthermore, you can parallelize HTTP requests thanks to SPDY’s multiplexing rather than opening multiple connections, saving network resources.
    I encourage you to try out these features and report your feedback here in the comments or on the Jetty mailing list.

  • Jetty SPDY push improvements

    After having some discussions on spdy-dev and having some experience with our current push implementation, we’ve decided to change a few things to the better.
    Jetty now sends all push resources non interleaved to the client. That means that the push resources are being sent sequentially to the client one after the other.
    The ReferrerPushStrategy which automatically detects which resources need to be pushed for a specific main resource. See SPDY – we push! for details. Previously we’ve just send the push resources in random order back to the client. However with the change to sequentially send the resources, it’s best to keep the order that the first browser client requested those resources. So we changed the implementation of ReferrerPushStrategy accordingly.
    This all aims at improving the time needed for rendering the page in the browser by sending the data to the browser as the browser needs them.

  • Jetty SPDY to HTTP Proxy

    We have SPDY to SPDY and HTTP to SPDY proxy functionality implemented in Jetty for a while now.
    An important and very common use case however is a SPDY to HTTP proxy. Imagine a network architecture where network components like firewalls need to inspect application layer contents. If those network components are not SPDY aware and able to read the binary protocol you need to terminate SPDY before passing the traffic through those components. Same counts for other network components like loadbalancers, etc.
    Another common use case is that you might not be able to migrate your legacy application from an HTTP connector to SPDY. Maybe because you can’t use Jetty for your application or your application is not written in Java.
    Quite a while ago, we’ve implemented a SPDY to HTTP proxy functionality in Jetty. We just didn’t blog about it yet. Using that proxy it’s possible to gain all the SPDY benefits where they really count…on the slow internet with high latency, while terminating SPDY on the frontend and talking plain HTTP to your backend components.
    Here’s the documentation to setup a SPDY to HTTP proxy:
    http://www.eclipse.org/jetty/documentation/current/spdy-configuring-proxy.html#spdy-to-http-example-config

  • Jetty, SPDY, PHP and WordPress

    Having discussed the business case for Jetty 9 and SPDY, this blog presents a simple tutorial for runing PHP web applications like WordPress on Jetty with SPDY.

    Get Jetty

    First you’ll need a distribution of Jetty, which you can download, unpack and run with the following (I use wget to download from the command line, or you can just download with a browser from here):

    wget -U none http://repo1.maven.org/maven2/org/eclipse/jetty/jetty-distribution/9.0.2.v20130417/jetty-distribution-9.0.2.v20130417.zip
unzip jetty-distribution-9.0.2.v20130417.zip
cd jetty-distribution-9.0.2.v20130417
java -jar start.jar

    You can point your browser at http://localhost:8080/ to verify that Jetty is running (Just ctrl-C jetty when you want to stop it).

    Configure SPDY

    Next you’ll need to download NPN (for SPDY protocol negotiation) from  here and save in the lib directory:

    wget -O lib/npn-boot-1.1.5.v20130313.jar
-U none
http://repo1.maven.org/maven2/org/mortbay/jetty/npn/npn-boot/1.1.5.v20130313/npn-boot-1.1.5.v20130313.jar

    To configure SPDY create the file start.d/spdy.ini with the following content:

    --exec
-Xbootclasspath/p:lib/npn-boot-1.1.5.v20130313.jar
OPTIONS=spdy
jetty.spdy.port=8443
jetty.secure.port=8443
etc/jetty-ssl.xml
etc/jetty-spdy.xml

    Restart jetty (java -jar start.jar) and you can now verify that you are running SPDY by pointing a recent Chrome or Firefox browser at https://localhost:8443/.  You may have to accept the security exception for the self signed certificate that is bundled with the jetty distro.    FF indicates that they are using SPDY with a little green lightening symbol in the address bar.

    Enable PHP

    There are several ways to PHP enable Jetty, but the one I’m using for this demonstration is php-java-bridge, which you can download in a complete WAR file from here.   To install and test in a context ready for wordpress:

    mkdir webapps/wordpress
cd webapps/wordpress
unzip /tmp/JavaBridgeTemplate621.war
cd ../..
java -jar start.jar

    You can then test that PHP is working by browsing to http://localhost:8080/wordpress/test.php and you can test that PHP is working under SPDY by browsing https://localhost:8443/wordpress/test.php.

    Install WordPress

    You now have a Jetty SPDY server serving PHP, so let’s install WordPress as an example of PHP webapplication. You can download WordPress from here and install it as follows:

    cd webapps
rm index.php
unzip /tmp/wordpress-3.5.1.zip
cd ..
java -jar start.jar

    You can browse to WordPress at http://localhost:8080/wordpress/ where you should see a screen inviting you to “Create a Configuration File”.   You’ll need a MYSQL database instance to proceed and 2 screens later you are running WordPress over HTTP.

    You’ll note that if you try immediately to access wordpress with SPDY, you get badly redirected back to the 8080 port with the https protocol!  This is just WordPress being a bit dumb when it comes to SSL and I suggest you google WordPress SSL and have a read of some of the configuration and plugin options available. Take special note of how you can easily lock yourself out of the admin pages!  Which you will do if you simply update the wordpress URL under general settings to https://localhost:8443/wordpress.   You’ll also need to read up on running WordPress on non standard ports, but this is not a blog about wordpress, so I wont go into the options here, other than to say that difficulties with the next few steps are the SPDY as they are for SSL (and that the wordpress guys should really read up on using the host header)!  If you want a quick demonstration, just change the home URI in general settings and you’ll be able to see the main site under SPDY at https://localhost:8443/wordpress/,  but will be locked out of the admin pages.

    Conclusion

    That’s it! A few simple steps are all you need to run a complex PHP site under Jetty with SPDY!        Of course if you want help with setting this up and tuning it, then please consider the Intalio’s migration, performance and/or production support services.