Stalled requests due to chrome's h2 concurrent streams limit

[Jitendra Kotamraju]

Chrome seems to limit max concurrent streams to 256 even though server advertises a high number in h2 SETTINGS frame. When I execute the following snippet, 

var ev = [];

for (i = 0; i < 300; i++) {

    ev[i] = new EventSource("https://foo.example.com/" + i);

    console.log(ev[i]);

}

I see that 256 requests go through the h2 connection and rest of the requests are stalled. Since the requests are long lived in this case (tomorrow websocket as h2 stream), the rest of the requests don't make any progress. The following events are observed in chrome://net-internals

t=26600 [st=  58]    HTTP2_SESSION_RECV_SETTING

                    --> id = "3 (SETTINGS_MAX_CONCURRENT_STREAMS)"

                    --> value = 1000

t=26600 [st=  58]    HTTP2_SESSION_UPDATE_STREAMS_SEND_WINDOW_SIZE

                    --> delta_window_size = -65535

t=26600 [st=  58]    HTTP2_SESSION_RECV_SETTING

                    --> id = "4 (SETTINGS_INITIAL_WINDOW_SIZE)"

                    --> value = 0

t=26621 [st=  79]    HTTP2_SESSION_STALLED_MAX_STREAMS

                    --> max_concurrent_streams = 256

                    --> num_active_streams = 0

                    --> num_created_streams = 256

                    --> num_pushed_streams = 0

                    --> url = "https://foo.example.com/441"

I see that safari, and firefox don't have that restriction. I think that limiting to 256 is arbitrary esp when server setting allows 1000 concurrent streams. Do you consider this as chrome's bug ? Is there a workaround ?

[Ryan Hamilton]

I don't believe we consider this a bug. There are various places where Chrome imposes restrictions in order to limit the resources allocated. For example, with HTTP/1.1 we limit the number of sockets that we'll have open to a server. This is a similar restriction. If there were no client-specified limit here, then a misbehaving server could set the limit to a huge number and start that many requests which would each consume some non-trivial amount of memory. This would allow the server to exhaust Chrome's memory which seems sad.

Cheers,

Ryan

--
--
Chromium Discussion mailing list: chromium...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-discuss

[Jitendra Kotamraju]

I disagree. While you think an application is working fine all along (on all browsers) and suddenly you would run into this kind of internal chrome restriction which functionally breaks the application on chrome. It forces developers to modify applications and even go back to http/1.1 practices. Server clearly indicating max concurrent streams it allows/needs in settings and chrome just doesn't follow it. I also think that streams are light-weight (when compared to connections) so resource usage is not an issue here . I will be happy to hear your thoughts on this. Thanks.