hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: HTTP/2 support: my initial thoughts (in random order)
Date Tue, 03 Mar 2015 17:41:47 GMT
On Mon, 2015-03-02 at 17:43 +0100, Francois-Xavier Bonnet wrote:
> Hi,
> 
> ALPN implementation from Jetty does not require Java 8 but it requires
> OpenJDK (not Oracle and at least OpenJDK 1.7.0u40), in addition there is a
> specific version of ALPN for each minor version of OpenJDK, and it has to
> be in the boot classpath of the jvm.
> I don't think we need to rush to Java 8 because of HTTP/2. We can do just
> like Jetty which still works on Java 7 and only checks at runtime for
> OpenJDK and ALPN when you want to turn on SPDY or HTTP/2
> 

Hi Francois-Xavier

Thanks for pointing that out. I am not going to upgrade the trunk to
Java 7 for now. 

Cheers

Oleg 

> 
> 2015-02-28 14:35 GMT+01:00 Oleg Kalnichevski <olegk@apache.org>:
> 
> > (1) HTTP/2 multiplexing is simply impossible to implement efficiently
> > with classic (blocking) I/O. A single HTTP/2 connection now represents
> > multiple full duplex streams of data. The connection can simply not
> > block doing just one thing, like writing out a lengthy message content
> > body in one stream while completely blocking out all other streams.
> > While I cannot completely rule out the idea of implementing just a
> > subset of HTTP/2 with blocking I/O at some point, it does look like we
> > should focus on exclusively on non-blocking code and seriously consider
> > getting rid of blocking components at some point.
> >
> > (2) HTTP/2 invalidates a lot of previous design decisions
> >
> > (*) Given that data is now being transferred in fairly small chunks for
> > multiple independent streams it is no longer important or even desirable
> > to let non-blocking protocol handlers have direct access to the
> > underlying connection channel. This pretty much invalidates the entire
> > design of the I/O reactor layer. The I/O reactor layer is likely to
> > require a complete re-design and rewrite.
> >
> > (*) Multiplexing and TLS encryption makes zero-copy transfer mode pretty
> > much impossible and irrelevant terms of performance optimization.
> >
> > (3) Fully compliant deployments of HTTP/2 are _required_ to negotiate
> > supported protocols using TLS Application-Layer Protocol Negotiation
> > Extension (RFC 7301) which is not even supported by Java at the moment
> > [1] and likely to become available in Java 9 only. There is a hack of
> > sort developed by Jetty folks that make this extension somehow work with
> > Java 8 but I have not looked at it yet. Regardless, it looks like we
> > have to upgrade to Java 8 no matter what.
> >
> > This, again, poses a difficult question whether we should rush HC 5.0
> > with HTTP/1.1 only and introduce HTTP/2 in HC 6.0. This would enable us
> > to delay inevitable upgrade to Java 8/9 for those folks who are only
> > interested in HTTP/1.1.
> >
> > (4) We might need introduce logging support at HttpCore level simply
> > because the transport logic is massively more complex now. Back to
> > logging wars.
> >
> > (5) Client side connection pooling becomes much, much less relevant.
> > Probably even irrelevant. This eliminates a considerable advantage HC
> > have over competing client side HTTP implementations.
> >
> > (6) We should be able to re-use all existing protocol handling code with
> > HTTP/2.
> >
> > The good news is that HTTP/2 is conceptually elegant and very flexible.
> > It addresses pretty much all short-comings of HTTP/1.1 I can think of.
> >
> > Oleg
> >
> > PS: There likely to be other thoughts I would want to share as my work
> > progresses. More posts to come.
> >
> > PPS: I am working on HTTP/2 frame handling code at the moment (the low
> > level data frame transport stream multiplexer code will be based upon).
> > If anyone wants to see early code please let me know
> >
> > [1] https://bugs.openjdk.java.net/browse/JDK-8062848
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > For additional commands, e-mail: dev-help@hc.apache.org
> >
> >



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message