hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Francois-Xavier Bonnet <francois-xavier.bon...@centraliens.net>
Subject Re: HTTP/2 support: my initial thoughts (in random order)
Date Mon, 02 Mar 2015 16:43:54 GMT
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


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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message