<div dir="ltr">Hi<div><br></div><div>To say more, I may need your comment on my understanding of Nginx</div><div><br></div><div>1. Is the reason that I cannot receive the response headers frame because the response headers are stored in the SSL buffer?</div><div><br></div><div>2.Nginx will fetch the blocked request in the queue when receiving a window update frame (is the request order in the queue the same as my sending order?)</div><div><br></div><div>3.Then Nginx will handle the request one by one in a non-block mode. I noticed that when the requested file is small, nginx will create all the data frames, push the data frames into out frames queue and sent it out. ( the handling order is the same as my sending request order) When the requested file is large(say 10Mb), nginx will create only a part of data frames and then create some other data frames (the handling order is related to the dependency tree). So:</div><div><br></div><div>- when a file is large, how many data frames to be generated once before generating the other frames, is it related to the SSL buffer size and the maximum frame size? and when Nginx are going to send out the frames and start a new SSL buffer.</div><div>- I dig the debug log and noticed the real process to reflect the priority handling is the order to generate the data frames and connect those data frames before sending then out. I cannot find the handling process related to priority when generating the data frames and connect them together. It would be great if you can tell me the strategy or locate the source code.<br></div><div>- Like the case I mentioned above. when the requested file is small, clients can not get the expected receiving response order. How large a file should be then nginx can handle them concurrently. I think in the real environment, many js , css file are not so big. So Nginx can not give priority mechanism in those cases. I suggest that Nginx should change the request queue order(Here I noticed the request queue is the same as the receiving order) rather than handling priority when generating data frames, it would be too late. So that even the files is small, the response order will also follows the dependency tree.</div><div><br></div><div>Best Regards</div><div>Muhui Jiang</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-05-10 22:33 GMT+08:00 Valentin V. Bartenev <span dir="ltr"><<a href="mailto:vbart@nginx.com" target="_blank">vbart@nginx.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tuesday 10 May 2016 22:12:59 Muhui Jiang wrote:<br>
> Hi<br>
><br>
> >You've misread the source code. HTTP/2 windows are handled in<br>
> >ngx_http_v2_send_chain(), which is only called for response body<br>
> >data.<br>
><br>
> when the window is blocked, Nginx logs that the headers frame has been sent<br>
> out, however I cannot receive any response headers. The same client tried<br>
> on h2o and I can receive the response headers.<br>
><br>
<br>
</span>In addition, nginx uses SSL buffer to optimize record sizes.<br>
<br>
You can tune it using the "ssl_buffer_size" directive:<br>
<a href="http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_buffer_size" rel="noreferrer" target="_blank">http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_buffer_size</a><br>
<span class=""><br>
<br>
> >The prioritization has effect when there is concurrency for<br>
> >connection. In your case from nginx point of view there was<br>
> >only one stream in processing at any moment. The previous<br>
> >stream was completed before the new one has been received.<br>
><br>
> Let me explain my strategy in detail. I used some requests(stream id 1-15)<br>
> to consume the window (65535) And then block the window without sending any<br>
> window update frame(I have sent a very large stream update before). Then I<br>
> send the next 6 streams with different priorities. At this moment, the 6<br>
> streams should be blocked. Nginx should have enough time to handle the<br>
> priority. Then I send a very large window update frame, but nginx will<br>
> process the stream one by one with no priority observation. What I want to<br>
> say is, only when the file is really large then the priority can be<br>
> observed. But I have give enough time to Nginx by block the request. Nginx<br>
> should handle the priority though the file is really small. If you need<br>
> more information, please tell me. Many Thanks<br>
><br>
</span>[..]<br>
<br>
Ok, now I understand your case. You are right, currently in this<br>
particular case priorities aren't handled.<br>
<div class="HOEnZb"><div class="h5"><br>
wbr, Valentin V. Bartenev<br>
<br>
_______________________________________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org">nginx@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx" rel="noreferrer" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx</a><br>
</div></div></blockquote></div><br></div>