Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85588
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.180 as permitted sender)
MIME-Version: 1.0
References: <CAH8MpnknSgzZEpsgqwfNMq5h8C5eM5RVREjvLwCA5YxLhMKc6Q@mail.gmail.com>
 <551AAB20.6060100@luni.fr>
In-Reply-To: <551AAB20.6060100@luni.fr>
Date: Tue, 31 Mar 2015 14:40:15 +0000
Message-ID: <CAH8MpnnxmD5+cd1jmndBTV7XA5TQTseXVE-p-D0tsqMh7=ZfDw@mail.gmail.com>
To: =?UTF-8?Q?Gr=C3=A9gory_Planchat?= <gregory@luni.fr>, 
	internals@lists.php.net, Daniel Lowrey <rdlowrey@php.net>
Content-Type: multipart/alternative; boundary=bcaec51b1be9affb4a0512969309
Subject: Re: HTTP/2 and Websocket support in 7.x versions
From: rdlowrey@php.net (Daniel Lowrey)

--bcaec51b1be9affb4a0512969309
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Mar 31, 2015 at 10:11 AM Gr=C3=A9gory Planchat <gregory@luni.fr> wr=
ote:

> Le 31/03/2015 15:56, Daniel Lowrey a =C3=A9crit :
> > HTTP/2 is entirely outside the scope of the PHP web SAPI as it currentl=
y
> > exists. The protocol impacts the actual HTTP server and has nothing to =
do
> > with the SAPI runtime which is simply handed information about the HTTP
> > request once the server parses it. The protocol used to communicate tho=
se
> > details between the client and the HTTP server does not concern the web
> > SAPI. There is no need for any sort of "support for h2" in PHP; it's th=
e
> > web server's concern. Apache and nginx will add support for h2 and PHP
> will
> > continue working as it always has.
> >
> > That said, the php web SAPI derives exceedingly little benefit from the
> > advent of HTTP/2.0. h2 is designed to allow multiplexing of many reques=
ts
> > over the same TCP connection but the PHP web SAPI still has the same
> > bottleneck it had before h2: one thread/process per request.
> >
> > As for websockets, you *can* do that using the web SAPI right now if yo=
u
> > wished but this would be inadvisable because long-lived connections wil=
l
> > quickly fill the bottleneck in every PHP web application (concurrent
> > threads/processes for each "request").
> >
> > Instead, the appropriate solution for websockets would be to implement =
a
> > socket server directly in the CLI that speaks the websocket protocol.
> >
> > Would it be useful to have raw incremental parsing functionality for
> > HTTP/1.1, HTTP/1.2 and websocket protocols available in userland? Sure,
> but
> > this falls more in the realm of an extension than anything else as few
> > people are implementing full-blown http and websocket servers in the CL=
I
> > right now.
> >
>
> Hi Daniel,
>
> Your message is focusing on the solution I can find today in the wild,
> not about the need mys previous message was about, namely multiplexing
> and message push.
>
> Anyway I'm aware of this and I understand your point, but why should'nt
> we be able, natively, to exploit HTTP/2 enhancements, particurlarly
> resources multiplexing and data push?
>
> Why woud we restrain to exploit 20 years old protocol features,
> deliberately omitting new ones that are already implemented on other
> platforms?
>
> Gr=C3=A9gory
>

You're right -- I was addressing the status quo.

The issue here is this: the web SAPI is historically the most stable thing
about PHP. Supporting things like message push and multiplexing would
require a fundamental change in what the web SAPI is. You would have to
junk the entire model and create something completely new. It wouldn't be
PHP anymore because you couldn't use the thread/process per-request model;
users could no longer rely on the ease and simplicity of every function
call being a simple synchronous operation.

This kind of major paradigm shift is something that couldn't remotely be
considered for PHP7. Even if it were possible you have to consider the web
SAPI's target demographic. This demographic knows nothing about
non-blocking IO and multitasking.

I used to be a proponent of integrating things like this directly into the
core of PHP. However I no longer consider this to be a good idea. Why?
Because all of the functionality needed to implement these things yourself
is available in extensions *right now.* I've personally worked on a
closed-source userland non-blocking HTTP+websocket server over the last
couple of years that clears 80,000 requests per second with 10,000
simultaneous clients running PHP7 on a single box with an i2600K cpu.

Instead of massively changing the fundamental nature of the PHP web SAPI I
believe we should focus on improving PHP as a language and not a web
framework. By doing so we make it increasingly possible to implement things
like this directly in userland with good performance. This can be
accomplished right now by simply focusing on extension development (like
php-uv which you mentioned and I've contributed to myself).

Would I personally prefer to re-implement everything in PHP on top of libuv
and bake non-blocking and threaded concurrency directly into the language
with async functions and promises? Absolutely. But you're talking about a
massive amount of work here. In standard internet parlance ... ain't no one
got time for that.

--bcaec51b1be9affb4a0512969309--