こんにちは。PHPの裏側で動いているZendエンジンや、OSのシステムコールが奏でるハーモニーに魅せられた君なら、きっと今日のテーマも面白がってもらえるはずです。
他のモダンな言語、例えばNode.jsやGoの並行処理モデルに触れたことがある人ほど、PHPに対して「リクエストごとにプロセスがフォークして同期的に動く、昔ながらの言語なんでしょ？」というイメージを抱きがちですよね。もちろん、伝統的なApache + mod_phpの時代や、素朴なFPM構成であればその通りです。
けれど、近年のPHP――特にSwoole、ReactPHP、Ampといった非同期ランタイムが台頭し、さらにネイティブでFiber（ファイバー）が導入された現代のPHPにおいて、その景色は一変しています。
今回は、PHPのストリームが裏側でどのようにOSの`epoll`や`kqueue`といったイベント駆動機構と連携し、あの重厚長大に見えるZend VM上でノンブロッキングな並行処理を実現しているのか。その核心に迫っていきましょう。ここを理解すると、PHPの裏側がまるで一枚の美しい絵画のように綺麗に見えてきますよ。
—
1. 伝統的なブロッキングI/Oの壁と、PHPストリームの正体
私たちが普段何気なく使っている `fopen()` や `stream_socket_client()`。これらは実は、単なるラッパー関数ではありません。PHPのストリーム（Streams API）は、ファイル、ネットワークソケット、プロセス間通信など、あらゆるI/Oリソースを統一されたインターフェースで抽象化するためのZendエンジンの心臓部です。
デフォルトでは、これらのストリームはブロッキングモードで動作します。例えば、遠隔のAPIにHTTPリクエストを投げたとしましょう。PHPスクリプトから見ると、コードはたった1行の記述です。
// ブロッキングモードでのソケット読み込み
$fp = fsockopen(“api.example.com”, 80, $errno, $errstr, 30);
fwrite($fp, “GET / HTTP/1.1\r\nHost: api.example.com\r\n\r\n”);
// ここでOSのカーネル空間からのデータ到着を待つ（CPUはスリープ、プロセスはブロック）
$response = fread($fp, 1024);
fclose($fp);
この `fread()` が実行された瞬間、PHPの実行プロセス（Zend VM）はOSに対して `read()` システムコールを発行します。カーネルはネットワークカードからデータが到着するまで、そのプロセスを「待ち状態（Sleep）」にします。もし相手のレスポンスが200ミリ秒遅れれば、CPUコアはそのプロセスに対して何も仕事を割り当てられず、ただ時間をドブに捨てることになります。
1つのリクエストを処理するだけならこれでも動きますが、数千の同時接続をさばくAPIサーバーを作ろうとした途端、この「待ち時間」がシステムのボトルネックとして牙を剥くわけです。
—
2. 非同期の要：`stream_set_blocking($fp, false)` と `epoll/kqueue`
ここで登場するのが、ノンブロッキングI/Oとイベントループの組み合わせです。ストリームを非同期モードに切り替えるには、おなじみのあの関数を使います。
$fp = stream_socket_client(“tcp://api.example.com:80”, $errno, $errstr, 30);
// ストリームをノンブロッキングモードに設定する
stream_set_blocking($fp, false);
この瞬間、何が起きるでしょうか？
Zend VMを介して底层のC言語レベル（PHPのソースコードで言うところの `main/streams/` や `ext/standard/streams.c`）では、ソケットのファイルディスクリプタ（FD）に対して `O_NONBLOCK` フラグが立ちます。
この状態で `fread()` や `fwrite()` を呼んでも、カーネルはデータを待たずに即座に制御をPHPに返します。「まだデータ来てないよ（`EWOULDBLOCK` または `EAGAIN` エラー）」というサインと共に。
では、データが来ていないのにどうやって処理を進めるのでしょうか？
そこで真価を発揮するのが、Linuxの `epoll` や macOSの `kqueue` といった、OSカーネルレベルのI/O多重化（Multiplexing）機構です。
イベントループと `stream_select` の内部挙動
ReactPHPやAmpのようなイベント駆動型ライブラリの核心には、必ず「イベントループ」が存在します。彼らは裏側で、PHPの `stream_select()` という関数（あるいは拡張モジュールによる直接の `epoll_wait` 呼び出し）を巧みに利用しています。
// 読み込み可能になるのを監視するストリームの配列
$read = [$fp1, $fp2, $fp3];
$write = [];
$except = [];
// OSに対して「このソケットたちに変化（データ到着など）があったら教えてくれ」と頼む
// 第5引数のタイムアウトを [0, 0] にすればポーリング、適度な値を設定すればその間だけブロック
$numChanged = stream_select($read, $write, $except, 0, 200000);
if ($numChanged > 0) {
// 準備ができたストリームだけを安全に読み込む
foreach ($read as $stream) {
$data = fread($stream, 1024);
// 非同期処理のコールバックへ…
}
}
この `stream_select()` の内部では、PHPはOSの `select()` や `poll()`、そして現代的なLinux環境であれば `epoll_create` / `epoll_ctl` / `epoll_wait` のシステムコールを呼び出しています。
`epoll` の何が優れているかというと、監視対象のファイルディスクリプタが数万個に増えても、OSカーネルが効率的に「イベントが発生したFDのリスト」だけをピンポイントでPHP側に返してくれる点です。これにより、O(N)のループ探索コストから解放され、爆発的なスケーラビリティが手に入ります。
—
3. Zend VMとFiberが生んだ、美しすぎる「協調的マルチタスク」
「でもさ、イベントループを書くたびにコールバック地獄（Callback Hell）になるし、コードが追いにくくなるよね」
そう思ったそこのあなた、非常に鋭い。かつてのPHPの非同期プログラミングは、まさにその泥臭さと戦う歴史でした。
しかし、PHP 8.1で導入された Fiber（ファイバー） によって、この世界は劇的に美しく進化しました。Fiberを使えば、「見かけ上は同期的なコード（上から下に流れるコード）」を書きながら、裏側では完全にノンブロッキングな非同期I/Oを回すという、エンジニアの理想郷が手に入ります。
実際のイメージを、極限までシンプルにした疑似コードで見てみましょう。
// Fiberを使った非同期HTTPクライアントのイメージ
function asyncGet(string $url): Fiber
{
return new Fiber(function () use ($url) {
$fp = stream_socket_client(“tcp://…”, $errno, $errstr, 30);
stream_set_blocking($fp, false);
// リクエスト送信
fwrite($fp, “GET {$url} HTTP/1.1\r\n\r\n”);
// イベントループのマネージャーに「ここから先はデータが来るまで中断してくれ」と伝える
// Fiber::suspend() で一度、Zend VMの実行コンテキストを親（イベントループ）に返す
$response = Fiber::suspend($fp);
return $response;
});
}
// イベントループ側
$fiber = asyncGet(“/api/v1/user”);
$socket = $fiber->start(); // ファイバー開始、stream_socketが返される
// イベントループがepollでソケットの読み込み可能を検知したら…
// ファイバーの中にデータを注入して再開（resume）する
$data = fread($socket, 4096);
$fiber->resume($data);
ここで行われている魔法をZend VMの視点から解説します。
1. `Fiber::suspend()` が呼ばれた瞬間、Zend VMは現在の実行スタックフレームをメモリ（Heap上の構造体）に退避させます。
2. コントロールはイベントループ（メインの処理系）に戻り、他のリクエストや別のFiberの処理を進めます（CPUが無駄死にしない！）。
3. OSの `epoll` が「データが届いたよ」と教えてくれたら、イベントループは `Fiber::resume()` を叩き、退避させていたZend VMのスタックフレームを復元します。
4. 止まっていた行（`$response = Fiber::suspend(…)` の右側）から、まるで何事もなかったかのように処理が再開されます。
この仕組みにより、開発者は複雑なコールバックの連鎖を書く必要がなくなり、PHPの強力な制御構文（`try-catch` やループ）をそのまま活かしながら、裏側ではC10K問題（1万台の同時接続）を軽々とクリアできる非同期エンジンを構築できるのです。
—
4. アーキテクトとして知っておくべき実務上の注意点
ここまでPHPのストリームと非同期I/Oの美しさを語ってきましたが、実務の現場に立つアーキテクトとして、一つだけ現実的な注意点を共有しておきます。
PHPの標準関数（例えば `file_get_contents()` や通常のPDOによるデータベース接続など）の多くは、依然としてブロッキングI/Oを前提として作られています。これらをうっかり非同期イベントループの中で呼び出してしまうと、その瞬間にプロセス全体のZend VMがフリーズし、他のすべての並行処理がブロックされてしまいます。
だからこそ、モダンな非同期PHPを書く際は、以下のような専用のドライバを選択する必要があります。
- データベースなら、従来のPDOではなく、非同期ストリームベースで作られたドライバ（AmpのMySQLクライアントなど）
- HTTPクライアントなら、非同期ストリームをラップしたCurlMultiやAmp/Httpなど
これらはすべて、内部で今日解説した `stream_set_blocking($fp, false)` と `stream_select()`（またはext-evなどのlibevバインディング）、そしてFiberのコンテキストスイッチを泥臭く、しかし美しく組み合わせて実装されています。
—
最後に：裏側を知れば、PHPはもっと自由になる
「PHPは遅い」「設計の自由度が低い」――そんな風潮は、過去の遺物になりつつあります。
Zend VMのメモリ管理、ストリームという名の洗練されたI/O抽象化、そしてOSカーネルの `epoll` や `kqueue` がどのように手を結んでいるのか。その低レイヤの構造さえ見えてしまえば、PHPという言語が持つポテンシャルの高さに、きっと改めて驚かされるはずです。
「ここを理解すれば、PHPの裏側が綺麗に見えますよ」
その言葉の通り、コードの向こう側にあるOSとエンジンの息吹を感じながら、ぜひ次のアーキテクチャ設計に挑んでみてください。君の作るシステムが、軽やかに、そして美しくスケールすることを応援しています。