HTTP2 Multiplexing
Muhui Jiang
jiangmuhui at gmail.com
Wed May 4 10:50:44 UTC 2016
Hi
>Nginx allows multiple request and responses in multiple connections using
>HTTP/1.x as well. HTTP/2 changes nothing here (except it uses only one
>connection, but it's not important from the basic architecture point of
>view).
If so, it seems there is no difference or improvement of the implementation
on the feature of multiplexing compared with Http/1.1 pipeline.
How do you solve the problem Head-of-line blocking occurred in Http/1.1.
Best Regards
Muhui Jiang
2016-05-04 18:19 GMT+08:00 Valentin V. Bartenev <vbart at nginx.com>:
> On Wednesday 04 May 2016 11:25:11 Muhui Jiang wrote:
> > Hi
> >
> > Different from HTTP1.1 pipeline, HTTP2 allows multiple request and
> response
> > messages to be in flight at the same time. I was wondering what the
> > strategy Nginx adopt to implement this main feature.
>
> Nginx allows multiple request and responses in multiple connections using
> HTTP/1.x as well. HTTP/2 changes nothing here (except it uses only one
> connection, but it's not important from the basic architecture point of
> view).
>
>
> >
> > Is every single stream correspond to a thread. If not, how can Nginx
> > provide multiple parallel requests handling. If you can locate the
> > correspond code for me, that would be great
> >
>
> No, nginx uses asynchronous non-blocking event-driven architecture
> instead of mapping requests into separate threads.
>
> It have used multiplexing of requests handling in single process many
> years before HTTP/2 was invented.
>
> A more detailed explanation can be found here:
>
> https://www.nginx.com/blog/inside-nginx-how-we-designed-for-performance-scale/
>
> wbr, Valentin V. Bartenev
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20160504/a13811a4/attachment.html>
More information about the nginx
mailing list