[Libwebsockets] http client: seeing delayed SSL connection

Andy Green andy at warmcat.com
Sat Mar 4 20:42:28 CET 2017



On March 4, 2017 9:40:19 PM GMT+08:00, Joel Winarske <joel.winarske at gmail.com> wrote:
>I had time to look at this last night.  I figured out my problem. Every
>other GET was failing due to the path getting clipped from an
>undersized
>buffer!

Great.

>I see at least 25 back-to-back pipelined transactions happen.  I'm
>moving
>forward to the next issue.
>
>http2 client...  Any thoughts on best scheme to add a http2 client?

Well note first, http/2 deliberately doesn't support ws, due to snobbery afaict on the part of the guys who define h2.  Eg last time it was discussed defining ws transport in http/2, the leader of the group did not believe there were any non-browser usecases for ws and wanted the discussion off his list.  So they are unfortunately in some kind of bubble and have mentally isolated ws as the one thing from http/1 in modern browsers they will ignore for http/2.

For a library called "libwebsockets" it makes h2 a bit disappointing.

Lws has a circa 80%-complete server implementation including the HPACK and huffman pieces, and ALPN integration if your openssl is new enough, it's enough to serve transactions on one stream (mux is not working).  So the framing parser etc is there.

Client h2 could probably ignore mux, since he can just enforce one stream per connection.  I don't know how much of HPACK and the framing parser you can re-use.... from memory h2 supports dumbed-down carriage of headers in h1 explicit style, not sure if it's legal to carry well-known headers that have more efficient / complex ways to carry then in HPACK defined but you could check.  But I think the server will respond with full HPACK including dynamic huffman encoding etc.

https://github.com/warmcat/libwebsockets/blob/master/lib/hpack.c

It's doable but it's not in the same ballpark as h1, have a read of RFC7450 first

https://tools.ietf.org/html/rfc7540

Ws == h1.  So h1 servers will be with us alongside h2 for the foreseeable future.

-Andy

>
>-Joel
>
>
>On Wed, Feb 22, 2017 at 2:22 AM Joel Winarske <joel.winarske at gmail.com>
>wrote:
>
>> I need to do more characterizing before I come up with a minimal repo
>> case.  Later this week.
>>
>> On Tue, Feb 21, 2017 at 5:27 PM, Andy Green <andy at warmcat.com> wrote:
>>
>>
>>
>> On February 22, 2017 10:16:36 AM GMT+09:00, Joel Winarske <
>> joel.winarske at gmail.com> wrote:
>> >Well I'm calling it a delay, but I suspect it's just the expected
>> >behavior
>> >of the "service loop".  Given http client is not a single
>synchronous
>> >function call.
>>
>> It depends what kind of delay, but name resolution takes network
>> roundtrips as does establishing the tcp connection.  But those should
>be no
>> different than say wget doing the same thing.
>>
>> >The scenario is loading the "site".  Which is around 275 server
>> >requests on
>> >initial load.  Of which only the second occurring Method: POST
>> >'/rest/send'
>> >is "refused"/or "pending".  I never see the incoming request in the
>> >log.
>>
>> Hm if this is lws it sounds like keepalive pipelining probs.
>>
>> >Chrome doesn't always report the transaction "refused".  Most of the
>> >time
>>
>> Mmm I dunno that is related at all to the canonical "Connection
>Refused"
>> at tcp level.  It seems to feel an individual transaction was not
>processed.
>>
>> >it says "pending", which in Wireshark - the server doesn't respond. 
>So
>> >the
>> >pattern is every other POST '/rest/send', of which calls the http
>> >client
>> >code.
>>
>> If we ignore "Connection Refused", we know from your earlier log
>chrome is
>> pipelining because it's logged when it handles the transaction
>complete.
>>
>> Personally I never tried two back-back POSTs pipelined, and this
>> encompasses the behaviour of your POST callbacks as well as lws
>itself.
>>
>> Is there a way I can reproduce it without a big effort?
>>
>> -Andy
>>
>> >
>> >On Tue, Feb 21, 2017 at 3:00 PM, Andy Green <andy at warmcat.com>
>wrote:
>> >
>> >>
>> >>
>> >> On February 22, 2017 7:46:12 AM GMT+09:00, Joel Winarske <
>> >> joel.winarske at gmail.com> wrote:
>> >> >lwsws on Windows, so libuv.
>> >>
>> >> Right.
>> >>
>> >> >Timing wise the refused request happens during
>> >> >lws_ssl_client_connect2().
>> >>
>> >> If we believe it really is a "connection refused" specifically,
>and
>> >not
>> >> something else that falls into the general category of "my
>connection
>> >was
>> >> not accepted", it's more interesting to understand the state of
>the
>> >server
>> >> part at that time.  We are spamming it with connections? 
>Something
>> >else?
>> >>
>> >> >Also how do I get rid of the delay between
>> >lws_client_connect_via_info
>> >> >and
>> >> >lws_ssl_client_connect2()?
>> >>
>> >> ... what delay?
>> >>
>> >> -Andy
>> >>
>> >>
>> >>
>>
>>
>>



More information about the Libwebsockets mailing list