Webtide

Tag: 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.

  • HTTP/2 Support for HttpClient

    Jetty’s HttpClient is a fast, scalable, asynchronous implementation of a HTTP client.
    But it is even more.
    Jetty’s HttpClient provides a high level API with HTTP semantic. This means that your applications will be able to perform HTTP requests and receive HTTP responses with a rich API. For example, you can use HttpClient to perform REST requests from the client or from within your web application to third party REST services.
    Jetty’s HttpClient provides also pluggable transports. This means that the concept of a HTTP request and response is translated by HttpClient to SPDY, FastCGI, HTTP/1.1 or other protocols and transported over the network in SPDY, FastCGI and HTTP/1.1 formats, in a way that is totally transparent for the application, which will only see a high level HTTP request and a response.
    Applications will get improved performance when using more performant transports.
    The new addition in Jetty 9.3 is a HTTP/2 transport for HttpClient, replacing the SPDY transport.
    This means that now HttpClient can talk to a regular HTTP/1.1 server, or to a FastCGI server that serves PHP pages, or to a HTTP/2 server transparently.
    The HTTP/2 specification is in its final phases, so the HTTP/2 protocol is now stable and well supported: Firefox, Chrome, Internet Explorer 11 already supports HTTP/2, and as the time passes they will be enabling HTTP/2 by default (some already have).
    And it’s not only browsers and servers such as Google, Twitter, etc.: also tools and libraries such as curl and nghttp2, among many others.
    The Jetty project implemented HTTP/2 since June 2014 and this very website has been served using Jetty’s HTTP/2 implementation for now over 6 months, helping to finalize the interoperability among different implementations.
    You are probably already reading this blog entry served via HTTP/2, if you are using a recent browser.
    Contact us if you are interested in deploying HTTP/2 in your infrastructure and benefit from the performance improvements that it brings.

  • 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 and HAProxy

    The SPDY protocol will be the next web revolution.
    The HTTP-bis working group has been rechartered to use SPDY as the basis for HTTP 2.0, so network and server vendors are starting to update their offerings to include SPDY support.
    Jetty has a long story of staying cutting edge when it is about web features and network protocols.

    • Jetty first implemented web continuations (2005) as a portable library, deployed them successfully for years to customers, until web continuations eventually become part of the Servlet 3.0 standard.
    • Jetty first supported the WebSocket protocol within the Servlet model (2009), deployed it successfully for years to customers, and now the WebSocket APIs are in the course of becoming a standard via JSR 356.

    Jetty is the first and today practically the only Java server that offers complete SPDY support, with advanced features that we demonstrated at JavaOne (watch the demo if you’re not convinced).
    If you have not switched to Jetty yet, you are missing the revolutions that are happening on the web, you are probably going to lose technical ground to your competitors, and lose money upgrading too late when it will cost (or already costs) you a lot more.
    Jetty is open source, released with friendly licenses, and with full commercial support in case you need our expertise about developer advice, training, tuning, configuring and using Jetty.
    While SPDY is now well supported by browsers and its support is increasing in servers, it is still lagging a bit behind in intermediaries such as load balancers, proxies and firewalls.
    To exploit the full power of SPDY, you want not only SPDY in the communication between the browser and the load balancer, but also between the load balancer and the servers.
    We are actively opening discussion channels with the providers of such products, and one of them is HAProxy. With the collaboration of Willy Tarreau, HAProxy mindmaster, we have recently been able to perform a full SPDY communication between a SPDY client (we tested latest Chrome, latest Firefox and Jetty’s Java SPDY client) through HAProxy to a Jetty SPDY server.
    This sets a new milestone in the adoption of the SPDY protocol because now large deployments can leverage the goodness of HAProxy as load balancer *and* leverage the goodness of SPDY as well as provided by Jetty SPDY servers.
    The HAProxy SPDY features are available in the latest development snapshots of HAProxy. A few details will probably be subject to changes (in particular the HAProxy configuration keywords), but SPDY support in HAProxy is there.
    The Jetty SPDY features are already available in Jetty 7, 8 and 9.
    If you are interested in knowing how you can use SPDY in your deployments, don’t hesitate to contact us. Most likely, you will be contacting us using the SPDY protocol from your browser to our server 🙂

  • Jetty 9 – Features

    Jetty 9 milestone 0 has landed! We are very excited about getting this release of jetty out and into the hands of everyone. A lot of work as gone into reworking fundamentals and this is going to be the best version of jetty yet!

    Anyway, as promised a few weeks back, here is a list of some of the big features in jetty-9. By no means an authoritative list of things that have changed, these are many of the high points we think are worthy of a bit of initial focus in jetty-9. One of the features will land in a subsequent milestone releases (pluggable modules) as that is still being refined somewhat, but the rest of them are largely in place and working in our initial testing.
    We’ll blog in depth on some of these features over the course of the next couple of months. We are targeting a November official release of Jetty 9.0.0 so keep an eye out. The improved documentation is coming along well and we’ll introduce that shortly. In the meantime, give the initial milestones a whirl and give us feedback on the mailing lists, on twitter (#jettyserver hashtag pls) or directly at some of the conferences we’ll be attending over the next couple of months.
    Next Generation Protocols – SPDY, WebSockets, MUX and HTTP/2.0 are actively replacing the venerable HTTP/1.1 protocol. Jetty directly supports these protocols as equals and first class siblings to HTTP/1.1. This means a lighter faster container that is simpler and more flexible to deal with the rapidly changing mix of protocols currently being experienced as HTTP/1.1 is replaced.
    Content Push – SPDY v3 supporting including content push within both the client and server. This is a potentially huge optimization for websites that know what a browser will need in terms of javascript files or images, instead of waiting for a browser to ask first.
    Improved WebSocket Server and Client

    • Fast websocket implementation
    • Supporting classic Listener approach and @WebSocket annotations
    • Fully compliant to RFC6455 spec (validated via autobahn test suite http://autobahn.ws/testsuite)
    • Support for latest versions of Draft WebSocket extensions (permessage-compression, and fragment)

    Java 7 – We have removed some areas of abstraction within jetty in order to take advantage of improved APIs in the JVM regarding concurrency and nio, this leads to a leaner implementation and improved performance.
    Servlet 3.1 ready – We actively track this developing spec and will be with support, in fact much of the support is already in place.
    Asynchronous HTTP client – refactored to simplify API, while retaining the ability to run many thousands of simultaneous requests, used as a basis for much of our own testing and http client needs.
    Pluggable Modules – one distribution with integration with libraries, third party technologies, and web applications available for download through a simple command line interface
    Improved SSL Support – the proliferation of mobile devices that use SSL has manifested in many atypical client implementations, support for these edge cases in SSL has been thoroughly refactored such that support is now understandable and maintainable by humans
    Lightweight – Jetty continues its history of having a very small memory footprint while still being able to scale to many ten’s of thousands of connections on commodity hardware.
    Eminently Embeddable – Years of embedding support pays off in your own application, webapp, or testing. Use embedded jetty to unit test your web projects. Add a web server to your existing application. Bundle your web app as a standalone application.