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
other resources are just referenced in the HTML and then loaded by the
HTTP client once the HTML has been requested and loaded, but there is no
explicit link 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
some 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 module?
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
to implement in further versions of PHP, without having to reimplement
the HTTP 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
destined for very small APIs and applications.
Since PHP 5.3, there is the -S option for starting an internal HTTP
server. 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 issues 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)
crashes (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
interoperability 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,
why wouldn't it be integrated in an unique extension/API?
The changes in the SI architecture between PHP and the web server would
be to transform the CGI interconnections to classical HTTP proxy
connections.
2.3. Solution 2 : Define some other way, extending the SAPIs and/or the
CGI API
I can't tell if it is even possible to implment this, as long as the
current 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 full application stack. Maybe it is all the request lifecycle
that has to be rethought from the ground as an application of 2015 is
radically different 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
and 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,
Facebook or Twitter and you may be more aware about their plans for
migrations than me. All I can tell about official statements is that
they are planning to migrate, if it isn't already done.
Grégory Planchat
[1] https://http2.github.io/faq/#what-are-the-key-differences-to-http1x
[2] http://nginx.com/blog/how-nginx-plans-to-support-http2/
[3] https://icing.github.io/mod_h2/
[4] http://reactphp.org/
[5] https://github.com/chobie/php-uv
[6] http://php.net/manual/en/ref.pcntl.php
[7] http://php.net/manual/en/book.eio.php
[8] http://php.net/manual/en/book.ev.php
[9] http://php.net/manual/en/book.libevent.php
[10] http://php.net/manual/en/book.pthreads.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
