Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85616
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.178 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <71.20.19097.3D1AA155@pb1.pair.com>
References: <71.20.19097.3D1AA155@pb1.pair.com>
Date: Wed, 1 Apr 2015 06:11:18 +0700
Message-ID: <CAEZPtU6NvYs=dTqkYcrXG-dKVhe7XueZ51E4JSBqTkpGiJ0uQg@mail.gmail.com>
To: =?UTF-8?Q?Gr=C3=A9gory_Planchat?= <gregory@luni.fr>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] HTTP/2 and Websocket support in 7.x versions
From: pierre.php@gmail.com (Pierre Joye)

hi,

On Tue, Mar 31, 2015 at 8:31 PM, Gr=C3=A9gory Planchat <gregory@luni.fr> wr=
ote:
> Hi,
>
> I've been reading about PHP7 RFC ans I did not see anything about HTTP/2
> support in any threads on internals nor the wiki. I'm aware that HTTP is =
the
> responsibility of the underlying web server, but there are new *important=
*
> features to consider.
>
> I know the feature list for PHP7 is now frozen, but this is an important
> feature for upcomimg 7.x versions, as long as this *IS* the future of the
> web.
>
> 1. HTTP/2 multiplexing
>
> HTTP/2 comes with document and resources multiplexing on one unique TCP
> connection stream [1]. Support is coming quickly in web servers[2][3],
> by late 2015 Apache and Nginx should support natively or via a module
> HTTP/2, just at the time PHP7 should be released.
>
> To set the context, currently with HTTP/1.x the images, css, js, and othe=
r
> resources are just referenced in the HTML and then loaded by the HTTP cli=
ent
> once the HTML has been requested and loaded, but there is no explicit lin=
k
> between documents on the server side. As a result, each resource consumes
> one TCP stream.
>
> Some optimisations exists like Connection: keep-alive, but it just save s=
ome
> TCP handshakes, the client still waits the loading of the HTML *BEFORE*
> requesting the js/css/images/resources. There is also a data:// protocol =
for
> small size resources, but it is not practical at all and suffers from
> partial support in the browsers.
>
> How would one specify which resources should be sent *WITH* the generated
> HTML? Is there anything in the FastCGI protocol to support these sort of
> features (via header or metadata or something else)? Alongside, is there
> something equivalent that would be possible to do in the PHP/Apache modul=
e?
>
> 2. HTTP/2 response push and WebSocket
>
> 2.1 State of the art and Native HTTP server
>
> Another important feature is the push feature. How would it be possible t=
o
> implement in further versions of PHP, without having to reimplement the H=
TTP
> server like the ReactPHP[4] project?
>
> Considering the fact that there is no enterprise-ready and performant
> application loop manager integrated natively in PHP core (using either
> forked or asynchronous), like Node.js's libuv, these solutions are destin=
ed
> for very small APIs and applications.
>
> Since PHP 5.3, there is the -S option for starting an internal HTTP serve=
r.
> Isn't there any plans to map this server to an userland API? This server =
has
> in fact all the logic needed by applications like ReactPHP[4], which has =
to
> reimplement it(!).
>
> Shouldn't there any other solution planned in PHP 7.x?
>
> 2.2. Solution 1: Implementing server from the ground with OS abstraction =
and
> application loops
>
> Solution of implmeenting from the ground the HTTP server is what ReactPHP
> did and is for now the most used solution. Some would say that these issu=
es
> should be kept in the userland, but please, read to the end.
>
> Furthermore, integrating in the core an OS-abtracted API for process
> management and asynchronous I/O could be a big performance jump, with an
> extension being to ext/pcntl what PDO has been to ext/mysqli in PHP 5.x.
>
> As I wrote previously, Node.js has libuv which started as an abstraction
> layer for Node's to libev and Windows and became a full featured OS
> abstraction layer for process and I/O management.
>
> Shuhei Tanuma (with the help of other contributors) has implmented an
> experimental binding named ext/uv[5] that could be a start to implment a
> similar feature set in PHP. I used it for a while in a personal and
> experimental project, it is functional despite of some (very rare) crashe=
s
> (and IMO a missing OOP-style API, which is more a personal taste than an
> issue).
>
> In the same vein, we have pcntl[6], eio[7], ev[8], libevent[9],
> pthreads[10], working in their own way but no uniform API, some use
> functional style, others are OOP style and there is maybe interoperabilit=
y
> issues and feature overlapping (I did not test all of them in a single
> project). Some even aren't integrated in the standard release and are
> availiable on PECL only.
>
> As long as all these features are currently in extensions or in a SAPI, w=
hy
> wouldn't it be integrated in an unique extension/API?
>
> The changes in the SI architecture between PHP and the web server would b=
e
> to transform the CGI interconnections to classical HTTP proxy connections=
.
>
> 2.3. Solution 2 : Define some other way, extending the SAPIs and/or the C=
GI
> API
>
> I can't tell if it is even possible to implment this, as long as the curr=
ent
> architecture depends on the underlying layer sollicitations (HTTP
> server/CLI/ect...).
>
> Currently, PHP itself doesn't decide to send some data to the client such=
 as
> push features, it must wait for its caller to be invoked, or manage the f=
ull
> application stack. Maybe it is all the request lifecycle that has to be
> rethought from the ground as an application of 2015 is radically differen=
t
> from a 1995 application (or even from 2005).
>
> 3. Conclusion
>
> Maybe there are other solutions. HTTP/2 has been released and a massive
> migration is about to come in the next 2 years. PHP has to move forward a=
nd
> implement new features or other platforms will be preferred on medium to
> large scale projects (including Node.js, Python and Ruby).
>
> I know some of you are working on large web companies like Google, Facebo=
ok
> or Twitter and you may be more aware about their plans for migrations tha=
n
> me. All I can tell about official statements is that they are planning to
> migrate, if it isn't already done.

Some notes:

As other said already there is no plan yet for http2 support in php
(7.0). It is not an easy task.

I like the curl's approach as an attempt to make it as transparent as
possible for our users. I would also try to avoid to re-implement
everything ourselves, at least for the 1st shots.

I am surprised that your mail do not mention https://nghttp2.org/,
which is the de facto standard implementation for http2. I did not
manage to sit on it but that was my plan for 7.0 when we discussed the
TODOs, more 7.1+ now. Supporting multiple requests at the same time,
be with nghttp2 or other is possible, we already do that. Talking
about client side http2 only obviously :)

I did not think yet about how PHP could be better to actually allow
multiple requests, server side, first gut feeling is that it is not
really PHP job to deal with that but one layer higher.

Cheers,
--=20
Pierre

@pierrejoye | http://www.libgd.org