Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Message-ID: <1425130500.31145.11.camel@apache.org>
Subject: HTTP/2 support: my initial thoughts (in random order)
From: Oleg Kalnichevski <olegk@apache.org>
To: dev@hc.apache.org
Date: Sat, 28 Feb 2015 14:35:00 +0100
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

(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