[Libwebsockets] Do we have plan to support web socket over http2 client on libwebsockets.
andy at warmcat.com
Wed Sep 19 00:39:36 CEST 2018
On 19/09/2018 00:40, zhang guojun wrote:
> Hi Andy,
> Thanks for the quickly reply and very detail explanation.
> In my case, there is a manage server to manage various network device. Right now we are using websocket as the transport tunnel, but as we know, we can see head-of-line-blocking issue.
I know what that is, but what do you mean by it?
Actually you can't properly solve that without QUIC... but since you
talk about a non-h2 ws solution these are presumably individual tcp
connections... one can't block the other.
TCP itself can block itself where there is packet loss due to its
requirement to deliver in-order... if that's what you mean h2 won't
solve it since it's also on top of TCP. QUIC is designed on top of UDP
transport and to the extent its packets are formed from content from one
stream, loss + retry does not block packets containing content from
You should clarify exactly where the blocking you think makes trouble is
coming from, because h2 won't necessarily solve it.
> So I consider the websocket over h2, in this way, we can reuse some of the existing code. We may loss a little bit bandwidth compare to raw websocket, but it still can acceptable.
> I go through the ws-over-h2 draft, the technology is flawless and you already implement server side code. In your perspective, what’s the reason the draft haven’t been a RFC?
It's simply going through the process, which takes time. The author is
one of the Great and Good from Mozilla, and the proposal is very
reasonable and limited in scope.
> I’m also considering to use H2 directly.
By default what flows on DATA is understood to be http. What happens
without a content-length on both sides and unlimited DATA in both
directions depends on the implementation... this isn't in the h2 spec
and the compliance tools don't test for it. ws-over-h2 upgrades the
connection so it is logically no longer http protocol on the stream.
> BTW, does libwebsockets support SERVER PUSH and POST?
There's no lws api to use PUSH_PROMISE. I proposed on httpbis that
ws-over-h2 support PUSH_PROMISE, because this would allow what was
originally a "GET index.html" to have sent the first data on a ws link
index.html will want to open before the client has finished receiving
index.html... instead of a RTT setting up the ws link much later it
could have delivered the first data before the browser realized it
wanted the ws link: instant ws data as soon as the JS opened the ws
without any network activity. But it was told it complicated the spec
For me I don't have a need to implement PUSH_PROMISE without that.
PUSH_PROMISE on http traffic has the internal contradiction the server
doesn't know what the client has in its private cache. So if it starts
setting up and partially sending CSS, JS, IMG or whatever, after the
first time if the private cache policy is reasonable, that is just
complete waste and the client will ignore the streams every time since
it has them in private cache already. So PUSH_PROMISE is kind of
Lws h2 supports POST (including multipart / file upload), CGI
(translating headers from the h1-only CGI) and proxying h2 <-> h1,
including on unix domain sockets.
>> On Sep 14, 2018, at 5:57 PM, Andy Green <andy at warmcat.com> wrote:
>> On 15/09/2018 02:10, zhang guojun wrote:
>>> Dear libwebsockets developers.
>>> I’m glad to see libwebsocket support websocket over http2 server, do we have any plan to support web socket over HTTP2 client?
>> Yeah, but not immediately. H2 client is working (including multi client stream coalescing into one h2 connection) for HTTP GET already, just not the ws-over-h2.
>> - I don't personally need it atm. There's a really big benefit implementing server side as lws already has, if your client is a browser with it implemented. Once the TLS + h2 is up for fetching html / css / js, an additional ws connection can be established inside the h2 connection, and start sending data, in just one RTT. It only benefits clients that are opening multiple streams on the server... if the client just opens the one ws connection, it still has to do the TLS and start the h2 connection from scratch, so there's no advantage for that case.
>> - It's not a small subproject... it interacts with both h1, h2 and ws roles / parsers and h2 needs all stream tx initiated from the h2 round-robin scheduler.
>> - Aside from the Chrome browser developers who contacted me while we mutually used each other's implementation for testing, IIRC you're the first person to acknowledge the existence of even the server work.
>> - Although the draft RFC is small and unlikely to change, it's not offical yet (it seems just a matter of time though)
>> - Implementation status outside of Chrome (it's in Canary 67+ if you enable special flags) is opaque. I asked twice on httpbis and just got ignored. I guess they won't enable it by default until the RFC is formally accepted. If you know the server has it and your non-browser client has it, you don't care about browser status though.
>> Of course if someone wants to pay my consultancy rate for the couple of weeks it would take I could get religion about it.
>>> Libwebsockets mailing list
>>> Libwebsockets at ml.libwebsockets.org
More information about the Libwebsockets